strprfcrm/docs/refactor/tz-order-schedule-answers.md

Ответы на вопросы по ТЗ «График заказов»

Источник: ТЗ_20_08_График_заказов_ОТВЕТЫ_НА_ВОПРОСЫ.docx.

Дата получения: 27.08.2026.

Связанные документы:

• ТЗ: График заказов от 20.08.2026
• ТЗ: Модуль Графики
• План реорганизации
• шаблон templates/DeliveryRequest.xls

1. Ответы заказчика

1.1. Интеграция с 1С

1. Стабильный GUID заказа и уникальность номера

Состав данных 1С пока неизвестен, требуется подключить специалиста по 1С. Номер заказа без года не уникален. На фабрике используются номера вида 1015.26, 945.25; идентификатор в CRM желательно согласовать с этим форматом.

1. Артикул общего каталога и идентификатор экземпляра МАФ

Неизвестно, передаёт ли их 1С. Требуется уточнение у специалиста по 1С.

1. Первичные поля 1С и сохранение локальных изменений

Однозначное правило не сформулировано. При аннулировании заказа все позиции перемещаются на склад; при частичном изменении часть позиций перемещается на склад, остальные остаются в заказе. Изменения юридического лица допускается вносить вручную.

1. Повторное действие Перенести в график

Ожидается поведение по аналогии с ДКР: предложить заменить старую строку либо добавить новую запись в нужный день без удаления старой. Это описывает пользовательский сценарий графика, но не полностью определяет идемпотентность повторной загрузки заказа из 1С.

1.2. Даты и производственный календарь

1. Расчёт рабочих дней

Используется производственный календарь с праздниками и переносами, а не только понедельник–пятница.

1. Наименования дат отгрузки

Во всех представлениях должны остаться два одинаково названных поля:

• Дата отгрузки по договору — прежняя плановая дата отгрузки, рассчитываемая по дате оплаты и сроку поставки;
• Дата отгрузки по заявке — прежняя дата отгрузки с фабрики.

1.3. Доставки, монтажи и пользователи

1. Несколько доставок и этапов монтажа

Допускается несколько доставок и несколько этапов монтажа по одному заказу. Пользователь добавляет дополнительные строки кнопкой +, по аналогии с добавлением запчастей в рекламации. Для каждой доставки указываются дата и водитель; для каждого этапа монтажа — собственные параметры.

Добавление в график фиксируется в журнале карточки, например: Назначена доставка на 01.01.1990, водитель Сидоров А. А., изменил Тукалин М. В.

1. Роль водителя

Нужна отдельная роль Водитель. Пользователи этой роли выводятся в списке выбора водителя по аналогии с выбором бригадира в ДКР. Исходное ТЗ также допускает выбор пользователей роли Бригадир. Роль Водитель должна участвовать в текущей ролевой модели, чтобы администратор управлял её правами.

1. Редактирование ручных полей

Помимо администратора адрес, примечание, доставку, монтаж, заводской номер и дату производства может редактировать Помощник руководителя. Доступ к этим полям должен управляться текущим механизмом ролевой модели.

1.4. Уведомления и аудит

1. События уведомлений

   Настраиваемые события:

   • создан заказ;
   • изменён статус заказа;
   • добавлена доставка;
   • добавлена дата монтажа;
   • добавлена рекламация по адресу.

   Уведомления получают привязанные к заказу менеджер, водитель и бригадир, если событие и канал включены в настройках пользователя.

2. Состав аудита

   В журнал включаются только:

   • изменение статуса;
   • добавление в график доставок;
   • добавление в график монтажей.

   Изменение обычных полей, а также старые и новые значения в журнал не выводятся.

1.5. Импорт, экспорт и файлы

1. Экспорт списка заказов

   Используется подход экспорта площадок ДКР: одна строка на заказ, оборудование суммируется и выводится в одной колонке, выгружаются все поля заказа. Экспорт учитывает активные фильтры списка.

2. Обновление ручным импортом

   Заказ с заполненным внутренним ID обновляется. Пустой ID означает создание нового заказа. Если заполненный ID не найден, импорт строки завершается ошибкой без создания заказа.

   Экземпляры МАФ передаются на отдельном листе XLS и связываются с заказом через строку основного листа.

3. Паспорт МАФ

   В строку экземпляра МАФ загружается готовый скан паспорта по аналогии с площадками ДКР. Отдельный шаблон паспорта не требуется.

4. Шаблон заявки на доставку

   Получен файл Шаблон заявки на доставку 2026.xls, сохранённый в проекте как templates/DeliveryRequest.xls.

5. Количество функциональных кнопок

   Число 5 в исходном ТЗ ошибочно. Нужно реализовать все перечисленные действия карточки.

1.6. Рекламации и отчётность

1. Отчётность рекламаций

   Рекламации типов Прочее и ДКР должны иметь разные отчёты.

2. Разбор шаблона заявки на доставку

Файл содержит один лист TDSheet, печатную область B1:AG94 и две встроенные иллюстрации в памятке водителю. Справа от печатной области находятся пояснения заказчика по заполнению полей.

Данные из карточки заказа:

• дата создания заявки;
• номер и дата счёта;
• номер и дата договора;
• номер заказа;
• менеджер и его телефон;
• водитель;
• заказчик;
• доставка или самовывоз;
• адрес доставки;
• выбранная дата доставки;
• агрегированный список оборудования;
• примечание;
• дата и подпись менеджера.

Данные, вводимые в модальном окне при создании заявки:

• перевозчик;
• номер/дата заявки;
• время;
• примечание перевозчику;
• должность, Ф. И. О. и телефон контактного лица;
• желаемое время доставки;
• пропускная система;
• место выгрузки;
• необходимость и срок предварительного предупреждения;
• способ подписания документов;
• наличие паспортов и сертификатов;
• дополнительный комментарий.

Технические требования к реализации:

• исходный XLS сохраняется как шаблон, а заполненный результат формируется через очередь;
• пояснения за пределами B1:AG94 не должны попадать в печать/PDF;
• тест должен проверять сохранение печатной области, памятки и встроенных изображений;
• позиции заказа перед выводом агрегируются по артикулу и наименованию;
• отдельная заявка формируется для конкретной доставки, поскольку один заказ может иметь несколько доставок.

3. Что разблокировано

• нормализованная модель заказа и отдельных экземпляров МАФ;
• ручное создание и редактирование;
• два однозначно названных поля отгрузки;
• производственный календарь;
• модель один заказ — много доставок/монтажей;
• роль Водитель и исходные права помощника руководителя;
• события уведомлений и состав аудита;
• экспорт списка с учётом фильтров;
• правила XLS-импорта: обновление по ID, создание при пустом ID, ошибка при неизвестном ID;
• отдельный лист XLS для экземпляров МАФ;
• паспорт как готовый скан;
• генерация заявки на доставку по полученному шаблону;
• отдельная отчётность рекламаций типа Прочее.

4. Что осталось уточнить

Блокирует только интеграцию с 1С

1. Стабильный GUID/ключ заказа в payload.
2. Артикул общего каталога и идентификатор строки или экземпляра МАФ.
3. Полный payload и контракт API.
4. Правила повторной синхронизации, конфликтов, аннулирования и частичного изменения состава заказа.

Ручной XLS-импорт реализован по согласованным правилам. Открытые вопросы выше блокируют только интеграцию с 1С.