|
|
@@ -0,0 +1,187 @@
|
|
|
+# Ответы на вопросы по ТЗ «График заказов»
|
|
|
+
|
|
|
+Источник: `ТЗ_20_08_График_заказов_ОТВЕТЫ_НА_ВОПРОСЫ.docx`.
|
|
|
+
|
|
|
+Дата получения: **27.08.2026**.
|
|
|
+
|
|
|
+Связанные документы:
|
|
|
+
|
|
|
+- [ТЗ: График заказов от 20.08.2026](tz-order-schedule.md)
|
|
|
+- [ТЗ: Модуль Графики](tz-schedules.md)
|
|
|
+- [План реорганизации](plan.md)
|
|
|
+- шаблон `templates/DeliveryRequest.xls`
|
|
|
+
|
|
|
+## 1. Ответы заказчика
|
|
|
+
|
|
|
+### 1.1. Интеграция с 1С
|
|
|
+
|
|
|
+1. **Стабильный GUID заказа и уникальность номера**
|
|
|
+
|
|
|
+ Состав данных 1С пока неизвестен, требуется подключить специалиста по 1С. Номер заказа без года не уникален. На фабрике используются номера вида `1015.26`, `945.25`; идентификатор в CRM желательно согласовать с этим форматом.
|
|
|
+
|
|
|
+2. **Артикул общего каталога и идентификатор экземпляра МАФ**
|
|
|
+
|
|
|
+ Неизвестно, передаёт ли их 1С. Требуется уточнение у специалиста по 1С.
|
|
|
+
|
|
|
+3. **Первичные поля 1С и сохранение локальных изменений**
|
|
|
+
|
|
|
+ Однозначное правило не сформулировано. При аннулировании заказа все позиции перемещаются на склад; при частичном изменении часть позиций перемещается на склад, остальные остаются в заказе. Изменения юридического лица допускается вносить вручную.
|
|
|
+
|
|
|
+4. **Повторное действие `Перенести в график`**
|
|
|
+
|
|
|
+ Ожидается поведение по аналогии с ДКР: предложить заменить старую строку либо добавить новую запись в нужный день без удаления старой. Это описывает пользовательский сценарий графика, но не полностью определяет идемпотентность повторной загрузки заказа из 1С.
|
|
|
+
|
|
|
+### 1.2. Даты и производственный календарь
|
|
|
+
|
|
|
+5. **Расчёт рабочих дней**
|
|
|
+
|
|
|
+ Используется производственный календарь с праздниками и переносами, а не только понедельник–пятница.
|
|
|
+
|
|
|
+6. **Наименования дат отгрузки**
|
|
|
+
|
|
|
+ Во всех представлениях должны остаться два одинаково названных поля:
|
|
|
+
|
|
|
+ - `Дата отгрузки по договору` — прежняя плановая дата отгрузки, рассчитываемая по дате оплаты и сроку поставки;
|
|
|
+ - `Дата отгрузки по заявке` — прежняя дата отгрузки с фабрики.
|
|
|
+
|
|
|
+### 1.3. Доставки, монтажи и пользователи
|
|
|
+
|
|
|
+7. **Несколько доставок и этапов монтажа**
|
|
|
+
|
|
|
+ Допускается несколько доставок и несколько этапов монтажа по одному заказу. Пользователь добавляет дополнительные строки кнопкой `+`, по аналогии с добавлением запчастей в рекламации. Для каждой доставки указываются дата и водитель; для каждого этапа монтажа — собственные параметры.
|
|
|
+
|
|
|
+ Добавление в график фиксируется в журнале карточки, например: `Назначена доставка на 01.01.1990, водитель Сидоров А. А., изменил Тукалин М. В.`
|
|
|
+
|
|
|
+8. **Роль водителя**
|
|
|
+
|
|
|
+ Нужна отдельная роль `Водитель`. Пользователи этой роли выводятся в списке выбора водителя по аналогии с выбором бригадира в ДКР. Исходное ТЗ также допускает выбор пользователей роли `Бригадир`. Роль `Водитель` должна участвовать в текущей ролевой модели, чтобы администратор управлял её правами.
|
|
|
+
|
|
|
+9. **Редактирование ручных полей**
|
|
|
+
|
|
|
+ Помимо администратора адрес, примечание, доставку, монтаж, заводской номер и дату производства может редактировать `Помощник руководителя`. Доступ к этим полям должен управляться текущим механизмом ролевой модели.
|
|
|
+
|
|
|
+### 1.4. Уведомления и аудит
|
|
|
+
|
|
|
+10. **События уведомлений**
|
|
|
+
|
|
|
+ Настраиваемые события:
|
|
|
+
|
|
|
+ - создан заказ;
|
|
|
+ - изменён статус заказа;
|
|
|
+ - добавлена доставка;
|
|
|
+ - добавлена дата монтажа;
|
|
|
+ - добавлена рекламация по адресу.
|
|
|
+
|
|
|
+ Уведомления получают привязанные к заказу менеджер, водитель и бригадир, если событие и канал включены в настройках пользователя.
|
|
|
+
|
|
|
+11. **Состав аудита**
|
|
|
+
|
|
|
+ В журнал включаются только:
|
|
|
+
|
|
|
+ - изменение статуса;
|
|
|
+ - добавление в график доставок;
|
|
|
+ - добавление в график монтажей.
|
|
|
+
|
|
|
+ Изменение обычных полей, а также старые и новые значения в журнал не выводятся.
|
|
|
+
|
|
|
+### 1.5. Импорт, экспорт и файлы
|
|
|
+
|
|
|
+12. **Экспорт списка заказов**
|
|
|
+
|
|
|
+ Используется подход экспорта площадок ДКР: одна строка на заказ, оборудование суммируется и выводится в одной колонке, выгружаются все поля заказа. Экспорт учитывает активные фильтры списка.
|
|
|
+
|
|
|
+13. **Обновление ручным импортом**
|
|
|
+
|
|
|
+ Нужно предусмотреть обновление заказа из файла по внутреннему `ID` заказа.
|
|
|
+
|
|
|
+14. **Паспорт МАФ**
|
|
|
+
|
|
|
+ В строку экземпляра МАФ загружается готовый скан паспорта по аналогии с площадками ДКР. Отдельный шаблон паспорта не требуется.
|
|
|
+
|
|
|
+15. **Шаблон заявки на доставку**
|
|
|
+
|
|
|
+ Получен файл `Шаблон заявки на доставку 2026.xls`, сохранённый в проекте как `templates/DeliveryRequest.xls`.
|
|
|
+
|
|
|
+16. **Количество функциональных кнопок**
|
|
|
+
|
|
|
+ Число `5` в исходном ТЗ ошибочно. Нужно реализовать все перечисленные действия карточки.
|
|
|
+
|
|
|
+### 1.6. Рекламации и отчётность
|
|
|
+
|
|
|
+17. **Отчётность рекламаций**
|
|
|
+
|
|
|
+ Рекламации типов `Прочее` и `ДКР` должны иметь разные отчёты.
|
|
|
+
|
|
|
+## 2. Разбор шаблона заявки на доставку
|
|
|
+
|
|
|
+Файл содержит один лист `TDSheet`, печатную область `B1:AG94` и две встроенные иллюстрации в памятке водителю. Справа от печатной области находятся пояснения заказчика по заполнению полей.
|
|
|
+
|
|
|
+Данные из карточки заказа:
|
|
|
+
|
|
|
+- дата создания заявки;
|
|
|
+- номер и дата счёта;
|
|
|
+- номер и дата договора;
|
|
|
+- номер заказа;
|
|
|
+- менеджер и его телефон;
|
|
|
+- водитель;
|
|
|
+- заказчик;
|
|
|
+- доставка или самовывоз;
|
|
|
+- адрес доставки;
|
|
|
+- выбранная дата доставки;
|
|
|
+- агрегированный список оборудования;
|
|
|
+- примечание;
|
|
|
+- дата и подпись менеджера.
|
|
|
+
|
|
|
+Данные, вводимые в модальном окне при создании заявки:
|
|
|
+
|
|
|
+- перевозчик;
|
|
|
+- номер/дата заявки;
|
|
|
+- время;
|
|
|
+- примечание перевозчику;
|
|
|
+- должность, Ф. И. О. и телефон контактного лица;
|
|
|
+- желаемое время доставки;
|
|
|
+- пропускная система;
|
|
|
+- место выгрузки;
|
|
|
+- необходимость и срок предварительного предупреждения;
|
|
|
+- способ подписания документов;
|
|
|
+- наличие паспортов и сертификатов;
|
|
|
+- дополнительный комментарий.
|
|
|
+
|
|
|
+Технические требования к реализации:
|
|
|
+
|
|
|
+- исходный XLS сохраняется как шаблон, а заполненный результат формируется через очередь;
|
|
|
+- пояснения за пределами `B1:AG94` не должны попадать в печать/PDF;
|
|
|
+- тест должен проверять сохранение печатной области, памятки и встроенных изображений;
|
|
|
+- позиции заказа перед выводом агрегируются по артикулу и наименованию;
|
|
|
+- отдельная заявка формируется для конкретной доставки, поскольку один заказ может иметь несколько доставок.
|
|
|
+
|
|
|
+## 3. Что разблокировано
|
|
|
+
|
|
|
+- нормализованная модель заказа и отдельных экземпляров МАФ;
|
|
|
+- ручное создание и редактирование;
|
|
|
+- два однозначно названных поля отгрузки;
|
|
|
+- производственный календарь;
|
|
|
+- модель `один заказ — много доставок/монтажей`;
|
|
|
+- роль `Водитель` и исходные права помощника руководителя;
|
|
|
+- события уведомлений и состав аудита;
|
|
|
+- экспорт списка с учётом фильтров;
|
|
|
+- паспорт как готовый скан;
|
|
|
+- генерация заявки на доставку по полученному шаблону;
|
|
|
+- отдельная отчётность рекламаций типа `Прочее`.
|
|
|
+
|
|
|
+## 4. Что осталось уточнить
|
|
|
+
|
|
|
+### Блокирует только интеграцию с 1С
|
|
|
+
|
|
|
+1. Стабильный GUID/ключ заказа в payload.
|
|
|
+2. Артикул общего каталога и идентификатор строки или экземпляра МАФ.
|
|
|
+3. Полный payload и контракт API.
|
|
|
+4. Правила повторной синхронизации, конфликтов, аннулирования и частичного изменения состава заказа.
|
|
|
+
|
|
|
+### Нужно зафиксировать до импорта XLS
|
|
|
+
|
|
|
+5. Может ли импорт создавать новые заказы или только обновлять существующие по `ID`.
|
|
|
+6. Как обрабатывать пустой, неизвестный или принадлежащий другому окружению `ID`.
|
|
|
+7. Нужен ли отдельный лист с экземплярами МАФ при импорте, если экспорт содержит агрегированное оборудование в одной колонке.
|
|
|
+
|
|
|
+Эти вопросы не блокируют разработку ручного ядра графика заказов, доставок, монтажей, файлов, уведомлений, аудита и экспорта заявки на доставку.
|
