gorbenko.pavel
c5958c3348
Tests / frontend-test (push) Successful in 1m22s
Поле «Ревизия» — из бумажной формы, в электронной не нужно (нет параллельных версий заявки, при возврате на доработку правится тот же элемент). Убрано из модели, манифеста и load.ts. «Отдел» переименован в «Подразделение» (заголовок общего столбца сайта Department — у большинства форм он уже так называется) и теперь, как организация и должность, подставляется из карточки заявителя (Employee/ByEmail.section/departmentId) при выборе/загрузке — а не только вручную через DepartmentPicker. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: gorbenko.pavel <gorbenko.pavel@tansu.kz> Reviewed-on: http://git.tnsu.kz/timur.gorodetskiy/request-portal/pulls/19
Заявка на услуги (wh-service-request)
Назначение: электронный аналог бумажной Service Requisition Form ПТО — заявка на договор/услуги/работы (субподряд, поставка, аренда) по проекту.
Категория: Склад / Снабжение
Списки SP: «Заявка на услуги — данные», «Заявка на услуги — согласование»
RequestTypeId (внешний API маршрутов): резолвится в рантайме по pageUrl (см. docs/forms.md)
Маршрут
- Фазы: согласование (без фазы исполнения — договор дальше ведётся вне портала)
- Особенности: маршрут зависит от выбранного проекта (
ProjectId, oid изProjectPicker) — пока проект не выбран,resolveRouteотвечает 404, и матрица не резолвится (см.matrixReadyвServiceRequestForm.tsx, тот же приём, что вTmcTransferForm)
Особое поведение
- Подача за другого: заявитель —
PeopleField, по умолчанию текущий пользователь, можно выбрать любого — маршрут резолвится на ВЫБРАННОГО (см.handleRequesterChange). - Табличная часть «Приложения» (
Annexes) — описание документа + номер приложения + сам файл, прикреплённый прямо к строке (fileName, хранится как встроенное вложение элемента списка — см. shared/attachments). Отдельного общего блока «Вложения» у формы нет: каждый файл привязан к своей строке. - Табличная часть «Смета» (
Costs) — список групп (разделов работ), внутри каждой свои позиции; название группы необязательно. Сумма по позиции, по группе и общий итог считаются на лету (qty × rate, см.cost.ts), не хранятся в структуре — правка количества/цены не может их рассинхронизировать. - Под «Объём работ» (текстовое поле) — детализация по позициям в ТОМ ЖЕ формате, что и смета: группы/позиции/цена/сумма (
WorkVolumes, см.CostGroupsEditor.tsx— общий редактор, переиспользуется и в CostsSection, и здесь). Дополняет текст итоговыми цифрами, не заменяет его. Costs/WorkVolumesсериализуются в JSON-колонки (EstimateJson/WorkVolumesJson) ОБЪЕКТОМ{ groups, total }— готовый итог кладётся прямо в JSON рядом с группами (см.serializeGroups/parseGroupedJsonвcost.ts), а не отдельной числовой колонкой: он и так пересчитывается из groups при каждом сохранении, отдельная колонка была бы лишней схемой ради того же значения. Сама форма читает толькоgroups— total из хранилища не доверяет, всегда считает заново (costTotal);totalв JSON нужен тем, кто читает колонку напрямую (отчёты, sp-query), не поднимая форму.Annexesсериализуется вAnnexesJsonпросто массивом (без обёртки total — там считать нечего) — тот же приём, что вTmcTransfer(ItemsJson).- Продолжительность работ под датами «начало/окончание» — производная величина (считается на лету), в SharePoint не пишется.
- Фазы исполнения нет:
saveServiceRequestпишет маршрут с пустым списком исполнителей.
Секции формы
HeaderSection, ScopeSection, AnnexesSection, CostsSection, RemarksSection
Точки входа
- rptype:
wh-service-request - Режим согласующего (просмотр): есть (
ServiceRequestView) - «Создать на основе»: —