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

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

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

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

- [План реорганизации](plan.md)
- [ТЗ: Модуль Графики](tz-schedules.md)
- [Ответы заказчика от 27.08.2026](tz-order-schedule-answers.md)
- [ТЗ: Каталог общий](tz-catalog-common.md)
- [ТЗ: Рекламации](tz-reclamations.md)
- [ТЗ: Документация](tz-documents.md)

## 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. Главная страница

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

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

1. ID.
2. Номер заказа.
3. Заказчик.
4. Адрес объекта.
5. № счёта.
6. Дата оплаты.
7. Срок поставки.
8. Дата отгрузки.
9. Дата отгрузки по заявке — видна администратору.
10. Статус заказа.
11. Дата доставки.
12. Дата монтажа.
13. Менеджер.
14. Примечание.

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

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

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

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

![Референс карточки площадки ДКР](tz-order-schedule-card.png)

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

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

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

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

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

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

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

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

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

1. Номер заказа.
2. Заказчик.
3. Адрес объекта.
4. № счёта.
5. Дата оплаты.
6. Срок поставки.
7. Статус заказа.
8. Тип.
9. Менеджер.
10. Позиции из общего каталога с количеством и номером заказа для каждой единицы МАФ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## 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 зафиксированы отдельно: [Ответы на вопросы по ТЗ](tz-order-schedule-answers.md).

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

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

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

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

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

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

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

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

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