ТЗ: График заказов от 20.08.2026

Источник: ТЗ 20.08 График заказов.docx.

Статус: получено, проанализировано и дополнено ответами заказчика от 27.08.2026; ручное ядро и внутренние сценарии готовы к реализации, интеграция с 1С требует отдельного согласования со специалистом 1С.

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

1. Поля заказа

№	Поле	Источник и правила
1	ID	Формируется базой данных.
2	Номер заказа	Передаётся из 1С; администратор может редактировать.
3	Заказчик	Передаётся из 1С; администратор может редактировать.
4	Адрес объекта	Передаётся из 1С; поле может редактироваться. Роль для редактирования в исходном ТЗ не уточнена.
5	№ счёта	Передаётся из 1С; администратор может редактировать.
6	№ договора	Передаётся из 1С; администратор может редактировать.
7	Дата оплаты	Передаётся из 1С; администратор может редактировать.
8	Срок поставки	Передаётся из 1С; администратор может редактировать.
9	Плановая дата отгрузки	Рассчитывается автоматически: дата оплаты + срок поставки в рабочих днях.
10	Дата отгрузки с фабрики	Передаётся из 1С; видна и редактируется администратором.
11	Статус заказа	Выбирается из фиксированного списка статусов.
12	Тип	Выбирается вручную из фиксированного списка типов исполнения.
13	Менеджер	Передаётся из 1С; администратор может выбрать пользователя с ролью `Менеджер`.
14	Примечание	Свободный текст.
15	Дата доставки	Плановая дата, после заполнения которой заказ может быть перенесён в график доставок.
16	Водитель	Выбирается среди пользователей с ролями `Водитель` и `Бригадир`.
17	Дата выхода на монтаж	Плановая дата, после заполнения которой заказ может быть перенесён в график монтажей.
18	Дней на монтаж	Плановая продолжительность монтажа в днях.
19	Бригадир	Выбирается среди пользователей с ролью `Бригадир`.

1.1. Статусы заказа

Размещен;
Готов на фабрике;
В пути;
Частичное поступление;
На складе;
Закрыт.

1.2. Типы исполнения заказа

Самовывоз;
Доставка;
Монтаж;
Доставка + Монтаж;
Доставка + Шеф-монтаж;
Шеф-монтаж.

2. Главная страница

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

Колонки списка:

ID.
Номер заказа.
Заказчик.
Адрес объекта.
№ счёта.
Дата оплаты.
Срок поставки.
Дата отгрузки.
Дата отгрузки по заявке — видна администратору.
Статус заказа.
Дата доставки.
Дата монтажа.
Менеджер.
Примечание.

3. Карточка заказа

Карточка строится по образцу карточки площадки ДКР:

слева — поля заказа из раздела 1;
справа — список оборудования;
отдельные блоки Документы, Фотографии и Чат площадки.

Каждая единица оборудования хранится и отображается отдельной строкой. Если заказано несколько одинаковых изделий, строка создаётся для каждого экземпляра, а не одна строка с количеством.

3.1. Таблица оборудования

Колонка	Правило
Чекбокс	Используется для удаления, переноса, создания рекламации и других групповых действий.
Картинка	Подгружается из общего каталога.
Номер заказа МАФ	При ручном создании вводится пользователем, при загрузке передаётся из 1С; администратор может редактировать.
Заводской номер	Изначально пустой, заполняется вручную.
Дата производства	Изначально пустая, заполняется вручную.
Паспорт	Галочка или крестик; к каждой позиции можно прикрепить скан паспорта.

3.2. Действия карточки

Редактировать — доступ определяется ролевой моделью; позволяет добавлять и удалять оборудование.
Экспорт МАФ — выгружает таблицу оборудования заказа; в шапке указываются заказчик, адрес, № счёта и № заказа.
Документы для монтажа — формирует архив по аналогии с площадкой ДКР: заполненная заявка на монтаж и документация по каждому МАФ.
Документы для доставки — формирует заявку на доставку оборудования. Шаблон будет предоставлен отдельным файлом.
Перенести в график монтажей — доступно при заполненных бригадире, дате монтажа и количестве дней монтажа.
Перенести в график доставок — доступно при заполненных водителе и дате доставки.
Назад — возвращает к общему списку.

Действия под таблицей оборудования:

Создать рекламацию — создаёт рекламацию по выбранным МАФ;
Скачать техдокументацию — формирует архив из технической документации выбранных МАФ по аналогии с карточкой площадки ДКР.

4. Создание заказа

4.1. Ручное создание

Обязательные исходные данные:

Номер заказа.
Заказчик.
Адрес объекта.
№ счёта.
Дата оплаты.
Срок поставки.
Статус заказа.
Тип.
Менеджер.
Позиции из общего каталога с количеством и номером заказа для каждой единицы МАФ.

4.2. Создание из 1С

В 1С используется действие Перенести в график. CRM должна создать или обновить заказ на основании переданных данных. Точный протокол, состав payload и правила повторной передачи в исходном ТЗ не описаны.

5. Импорт и экспорт

Нужны импорт и экспорт полного списка заказов. Формат должен соответствовать табличному представлению графика заказов.

6. Уведомления

Нужны настраиваемые уведомления пользователя о событиях от создания заказа до изменения статусов по аналогии с площадками ДКР.

7. Визуальное отображение статусов

строки заказов подсвечиваются разными цветами в зависимости от статуса;
закрытый заказ отображается полупрозрачным.

8. История действий

В карточке заказа отображается журнал действий только по этому заказу, в том числе:

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

9. Рекламации из графика заказов

Рекламация создаётся по выбранным экземплярам МАФ и получает тип Прочее:

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

Таблица оборудования рекламации:

Картинка.
МАФ (артикул).
Номер заказа МАФ.
Заводской номер.
Дата производства.

10. Сопоставление с текущим планом и кодовой базой

10.1. Что подтверждено

Заказ, экземпляры оборудования, доставки, монтажи и загрузки 1С нельзя объединять в одну таблицу старого формата graf1.
Оборудование должно ссылаться на common_catalog_items, а не на каталог ДКР.
Повторяющийся артикул представлен отдельными экземплярами МАФ. Это подтверждает необходимость отдельной сущности позиции/экземпляра, а не поля quantity как единственного представления состава заказа.
Данные 1С и ручные плановые данные должны быть разделены, чтобы повторная синхронизация не уничтожала дату доставки, водителя, монтаж, комментарии и ручные идентификаторы МАФ.
Создание рекламации типа Прочее по выбранным МАФ соответствует выделенному этапу 10 плана.

10.2. Что добавлено новым ТЗ

ручное создание и редактирование заказа наряду с загрузкой из 1С;
фиксированные справочники статусов и типов исполнения;
автоматический расчёт плановой даты отгрузки в рабочих днях;
карточка заказа по образцу площадки ДКР;
документы, фотографии и чат заказа;
паспорт для каждого экземпляра МАФ;
экспорт оборудования одного заказа и импорт/экспорт общего списка;
пакеты документов для монтажа и доставки;
скачивание технической документации выбранных МАФ;
настраиваемые уведомления;
цветовая индикация статусов;
журнал действий по заказу;
роли водителя, менеджера и бригадира в планировании;
явные действия переноса в графики доставок и монтажей.

10.3. Что можно переиспользовать

общий каталог, изображения и документы CommonCatalogItem;
механизм файлов, превью и приватных сгенерированных архивов;
генерацию монтажного пакета ДКР после адаптации под новый тип заказа;
чат площадки и рекламации после добавления связи с новым заказом;
пользовательские уведомления по браузеру, push и email;
ролевую модель и управление доступом к отдельным полям;
текущую форму и бизнес-логику рекламаций;
очередь импорта, экспорта и формирования документов.

10.4. Что нельзя переиспользовать без изменения модели

orders — это площадки ДКР с обязательными округом, районом и типом объекта, а не производственные заказы из нового ТЗ;
products_sku связан с каталогом ДКР products, тогда как новое ТЗ требует общий каталог;
schedules содержит сериализованное поле mafs и обязательные реквизиты ДКР, поэтому новую связь с производственным заказом нужно вводить явно;
reclamations.order_id сейчас обязательно ссылается на площадку ДКР, поэтому для рекламаций типа Прочее нужна отдельная нормализованная связь с новым заказом без создания фиктивной площадки ДКР;
в ролевой модели есть Менеджер и Бригадир, но отдельной роли Водитель сейчас нет.

11. Предлагаемая модель

Точные имена фиксируются на этапе проектирования. Минимально необходимы:

производственный заказ;
экземпляр МАФ заказа со ссылкой на common_catalog_items;
справочник или enum статусов заказа;
справочник или enum типов исполнения;
отдельные плановые записи доставки и монтажа;
журнал загрузок 1С с исходным payload и результатами сопоставления;
история значимых изменений заказа;
связи заказа и экземпляров МАФ с файлами, чатом и рекламациями.

Даже если интерфейс первого релиза показывает одну дату доставки и одну дату монтажа, модель доставок и монтажей не должна фиксировать лимит в одну запись: в старом Manager уже существовало до трёх доставок по одному заказу.

12. Результат согласования вопросов

Ответы заказчика и разбор полученного XLS зафиксированы отдельно: Ответы на вопросы по ТЗ.

Согласовано:

номер заказа без года не уникален; внешний формат должен учитывать год;
расчёт выполняется по производственному календарю с праздниками и переносами;
используются названия Дата отгрузки по договору и Дата отгрузки по заявке;
заказ может иметь несколько доставок и несколько этапов монтажа;
вводится отдельная роль Водитель;
помощник руководителя получает редактирование указанных полей через ролевую модель;
определены события уведомлений и их получатели;
аудит содержит изменения статуса и добавление в графики без диффа обычных полей;
экспорт учитывает фильтры и агрегирует оборудование в одной колонке;
импорт должен уметь обновлять заказ по его внутреннему ID;
паспорт загружается готовым сканом;
реализуются все перечисленные кнопки карточки;
рекламации Прочее и ДКР имеют разную отчётность;
получен шаблон заявки на доставку.

Остаются вопросы по 1С и точным правилам ручного импорта.

Блокирующие проектирование и обмен с 1С

Какой стабильный GUID/ключ заказа передаёт 1С?
Передаёт ли 1С артикул общего каталога и стабильный идентификатор каждого экземпляра/строки МАФ?
Какие поля 1С являются первичными, а какие локальные изменения должны сохраняться при повторной синхронизации?
Как обрабатывать повторную загрузку, аннулирование и частичное изменение состава заказа?

Требуют уточнения до реализации ручного импорта

Может ли XLS создавать новые заказы или только обновлять существующие по ID?
Как обрабатывать отсутствующий или неизвестный ID?
Как импортировать отдельные экземпляры МАФ, если оборудование в общем экспорте агрегировано в одной колонке?

13. Рекомендуемая последовательность реализации

Спроектировать нормализованные таблицы заказов, экземпляров МАФ, доставок, монтажей и аудита.
Реализовать ручное ядро независимо от будущего обмена с 1С.
Реализовать справочники, права и базовую карточку с ручным созданием заказа.
Добавить документы, фотографии, чат, паспорт МАФ и техническую документацию.
Реализовать доставки, монтажи, уведомления, аудит и заявку на доставку.
Реализовать экспорт с фильтрами; ручной импорт — после уточнения оставшихся правил.
Реализовать рекламации типа Прочее по выбранным экземплярам МАФ.
После контакта со специалистом 1С спроектировать и реализовать идемпотентный API обмена с журналом загрузок.

tz-order-schedule.md 22 KB Historik Rå