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

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

Статус: получено и проанализировано; перед проектированием обмена с 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. Вопросы для согласования

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

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

Требуют уточнения до соответствующей части реализации

Дата отгрузки, Дата отгрузки по заявке, Плановая дата отгрузки и Дата отгрузки с фабрики — какие именно даты соответствуют друг другу в карточке и списке?
Допускаются ли несколько доставок и несколько монтажных этапов по одному заказу? Можно ли переносить только выбранные МАФ?
Нужен ли новый системный тип пользователя/роль Водитель, или водитель — должность/признак пользователя, независимый от роли доступа?
Кто, кроме администратора, может редактировать адрес, примечание, доставку, монтаж, заводской номер и дату производства?
Какие события, получатели и каналы должны быть доступны в настройках уведомлений?
Какие действия обязательно входят в аудит помимо статуса и переноса в графики? Требуется ли показывать старое и новое значения?
Как выглядит XLSX для импорта/экспорта: только строки заказов или отдельный лист с экземплярами МАФ?
Должен ли ручной импорт XLSX обновлять заказы, и по какому ключу выполняется сопоставление?
Требуется ли отдельный шаблон паспорта или в строку МАФ загружается готовый скан?
Необходимо предоставить шаблон заявки на доставку.
Что означает «5 функциональных кнопок» в исходном ТЗ, если в перечне указано семь верхних действий?
Подтвердить, что рекламации типа Прочее не участвуют только в отчётах ДКР, но могут иметь собственную отчётность.

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

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

tz-order-schedule.md 22 KB История Исходник