# Ответы на вопросы по ТЗ «График заказов» Источник: `ТЗ_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. Нужен ли отдельный лист с экземплярами МАФ при импорте, если экспорт содержит агрегированное оборудование в одной колонке. Эти вопросы не блокируют разработку ручного ядра графика заказов, доставок, монтажей, файлов, уведомлений, аудита и экспорта заявки на доставку.