documented order schedule requirements

docs/refactor/menu.md

@@ -201,6 +201,6 @@ Manager
 
 ## Открытые вопросы
 
-1. Когда будет передано отдельное ТЗ на `График заказов`?
+1. Какие правила обмена с 1С и неоднозначные поля нового ТЗ на `График заказов` утвердит заказчик?
 2. Будет ли отдельное ТЗ на `Калькуляции` и какую архитектуру оно определит?
 3. Где находятся актуальные исходные данные старого калькулятора?

docs/refactor/plan.md

@@ -85,8 +85,8 @@
 | 6. Склад: ядро | Реализован и проверен | Ядро склада принято после пользовательской проверки. Цены относятся к общему каталогу; для склада остаётся отдельной задачей только PDF-экспорт после согласования шаблона. |
 | 7. Техническое описание | Реализован и проверен | Данные встроены в общий каталог, вид цены выбирается администратором (по умолчанию `проект`), одиночный DOCX и массовый DOCX/ZIP приняты по результатам пользовательской проверки. |
 | 8. Калькуляции | Исходник изучен, ожидается отдельное ТЗ | Восстановлены сущности, формулы и экспорты `calc.stroyprofit.com`; финальная архитектура, формулы и сценарии не фиксируются до ТЗ. Рабочая база источника сейчас не содержит расчётных данных. |
-| 9. Графики заказов и доставок | Исходная система изучена, ожидается отдельное ТЗ | Найдены старый график и фактический формат обмена с 1С. Нормализация принята как архитектурный принцип, но финальные поля, статусы и правила уточнит заказчик. |
-| 10. Рекламации из графика заказов | Готово только после графика заказов | Сценарий согласован, но точка входа зависит от карточки заказа в графике. |
+| 9. Графики заказов и доставок | Новое ТЗ получено и проанализировано | Требования от 20.08.2026 сопоставлены со старым графиком и текущей CRM; до проектирования нужно согласовать идентификаторы 1С, правила синхронизации и неоднозначные поля. |
+| 10. Рекламации из графика заказов | ТЗ получено, реализация после основы графика | Подтверждены выбор отдельных МАФ и тип `Прочее`, но новая связь рекламации зависит от моделей заказа и его экземпляров. |
 
 ## Этап 1. Реорганизация меню и заглушки
 
@@ -245,7 +245,7 @@
 
 ## Этап 9. Графики заказов и доставок
 
-Статус: **исходная система и обмен с 1С изучены, ожидается отдельное ТЗ**.
+Статус: **ТЗ от 20.08.2026 получено и проанализировано; ожидаются ответы на блокирующие вопросы перед проектированием**.
 
 Старый `График отгрузок` является источником существующих данных и сценариев, но не переносится одной таблицей. Архитектура нового модуля должна оставаться нормализованной и расширяемой под дополнительные требования заказчика.
 
@@ -253,15 +253,23 @@
 - [x] Описать найденный HTTP-обмен с 1С и состав текущего payload.
 - [x] Проанализировать существующие статусы, ручные поля, вложения и несколько доставок по заказу.
 - [x] Зафиксировать обязательную нормализацию заказов, позиций, доставок и загрузок 1С.
-- [ ] Получить и согласовать отдельное ТЗ на `График заказов`.
+- [x] Получить отдельное ТЗ на `График заказов`.
+- [x] Конвертировать ТЗ в `tz-order-schedule.md`, сохранить значимый референс карточки и сопоставить требования с планом и текущим кодом.
+- [ ] Согласовать открытые вопросы ТЗ и зафиксировать финальную редакцию требований.
 - [ ] Уточнить стабильный внешний идентификатор заказа и передачу артикула каждой позиции из 1С.
 - [ ] Согласовать принадлежность полей источнику или ручному редактированию, чтобы повторная загрузка не уничтожала плановые данные.
+- [ ] Согласовать календарь рабочих дней и значения полей дат отгрузки.
+- [ ] Решить, является ли `Водитель` отдельной ролью доступа или должностью/признаком пользователя.
 - [ ] Спроектировать нормализованные таблицы и связи после получения ТЗ.
 - [ ] Спроектировать загрузку данных через 1С.
 - [ ] Реализовать безопасный идемпотентный импорт с журналом запусков и ошибок.
 - [ ] Реализовать `График заказов` без прямого копирования устаревшей таблицы `graf1`.
 - [ ] Подготовить отдельную миграцию исторических данных старого Manager с отчётом о конфликтах и дублях.
 - [ ] Добавить карточку заказа с выбором одного или нескольких МАФ.
+- [ ] Добавить ручное создание заказа, файлы, фотографии, чат, паспорт каждого МАФ и журнал действий.
+- [ ] Добавить статусы, типы исполнения, цветовую индикацию и настраиваемые уведомления.
+- [ ] Реализовать импорт/экспорт списка заказов и экспорт МАФ одного заказа.
+- [ ] Реализовать пакеты документов для монтажа, доставки и технической документации.
 - [ ] Добавить создание рекламации из заказа через текущую форму.
 - [ ] Получить и согласовать требования к `Графику доставок`, если они не войдут в ТЗ графика заказов.
 - [ ] Реализовать `График доставок` в виде недельного списка.
@@ -271,7 +279,7 @@
 
 ## Этап 10. Рекламации из графика заказов
 
-Статус: **готово после этапа 9**.
+Статус: **ТЗ получено; реализация после базовых моделей этапа 9**.
 
 - [ ] Реализовать создание рекламации из графика заказов по выбранным МАФ с типом `other` (`Прочее`).
 - [ ] В карточке заказа дать выбор одного или нескольких МАФ.
@@ -293,7 +301,7 @@
 
 ## Открытые вопросы
 
-- [ ] Когда будет передано отдельное ТЗ на `График заказов` и какие новые требования добавит заказчик?
+- [ ] Какие ответы даст заказчик на вопросы нового ТЗ по идентификаторам 1С, повторной синхронизации, датам отгрузки и роли водителя?
 - [ ] Передаёт ли 1С стабильный GUID заказа и артикулы позиций, либо формат обмена нужно расширить?
 - [ ] Будет ли отдельное ТЗ на `Калькуляции` и выберет ли оно внутренний расчёт в Laravel или интеграцию?
 - [ ] Где находится актуальная резервная копия или исходные Excel-данные `calc.stroyprofit.com`?

docs/refactor/tz-order-schedule.md

@@ -0,0 +1,271 @@
+# ТЗ: График заказов от 20.08.2026
+
+Источник: `ТЗ 20.08 График заказов.docx`.
+
+Статус: **получено и проанализировано; перед проектированием обмена с 1С и графиков доставок/монтажей требуются уточнения**.
+
+Связанные документы:
+
+- [План реорганизации](plan.md)
+- [ТЗ: Модуль Графики](tz-schedules.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. Вопросы для согласования
+
+### Блокирующие проектирование и обмен с 1С
+
+1. Какой стабильный GUID заказа передаёт 1С? Уникален ли номер заказа без года?
+2. Передаёт ли 1С артикул общего каталога и стабильный идентификатор каждого экземпляра/строки МАФ?
+3. Какие поля 1С являются первичными, а какие локальные изменения администратора должны сохраняться при повторной синхронизации?
+4. Что должна делать повторная команда `Перенести в график`: создать новую версию, обновить существующий заказ или отклонить конфликт?
+5. Как определяется календарь рабочих дней для расчёта плановой отгрузки: только понедельник–пятница или производственный календарь с праздниками и переносами?
+
+### Требуют уточнения до соответствующей части реализации
+
+6. `Дата отгрузки`, `Дата отгрузки по заявке`, `Плановая дата отгрузки` и `Дата отгрузки с фабрики` — какие именно даты соответствуют друг другу в карточке и списке?
+7. Допускаются ли несколько доставок и несколько монтажных этапов по одному заказу? Можно ли переносить только выбранные МАФ?
+8. Нужен ли новый системный тип пользователя/роль `Водитель`, или водитель — должность/признак пользователя, независимый от роли доступа?
+9. Кто, кроме администратора, может редактировать адрес, примечание, доставку, монтаж, заводской номер и дату производства?
+10. Какие события, получатели и каналы должны быть доступны в настройках уведомлений?
+11. Какие действия обязательно входят в аудит помимо статуса и переноса в графики? Требуется ли показывать старое и новое значения?
+12. Как выглядит XLSX для импорта/экспорта: только строки заказов или отдельный лист с экземплярами МАФ?
+13. Должен ли ручной импорт XLSX обновлять заказы, и по какому ключу выполняется сопоставление?
+14. Требуется ли отдельный шаблон паспорта или в строку МАФ загружается готовый скан?
+15. Необходимо предоставить шаблон заявки на доставку.
+16. Что означает «5 функциональных кнопок» в исходном ТЗ, если в перечне указано семь верхних действий?
+17. Подтвердить, что рекламации типа `Прочее` не участвуют только в отчётах ДКР, но могут иметь собственную отчётность.
+
+## 13. Рекомендуемая последовательность реализации
+
+1. Согласовать открытые вопросы по идентификаторам 1С, принадлежности полей и календарю рабочих дней.
+2. Спроектировать нормализованные таблицы заказов, экземпляров МАФ, доставок, монтажей, загрузок и аудита.
+3. Реализовать справочники, права и базовую карточку с ручным созданием заказа.
+4. Реализовать идемпотентный API обмена с 1С и журнал загрузок.
+5. Добавить документы, фотографии, чат, паспорт МАФ и техническую документацию.
+6. Реализовать экспорт/импорт, уведомления и аудит.
+7. Связать заказ с графиками доставок и монтажей.
+8. Реализовать рекламации типа `Прочее` по выбранным экземплярам МАФ.

docs/refactor/tz-schedules.md

@@ -4,6 +4,7 @@
 
 - [План реорганизации](plan.md)
 - [Карта нового меню](menu.md)
+- [ТЗ: График заказов от 20.08.2026](tz-order-schedule.md)
 - [ТЗ: Каталог общий](tz-catalog-common.md)
 - [ТЗ: Модуль ДКР](tz-dkr.md)
 
@@ -19,7 +20,7 @@
 
 ## 2. Статус
 
-Статус модуля: **частично реализован; исходная система графика заказов изучена, финальное ТЗ ожидается**.
+Статус модуля: **частично реализован; ТЗ на график заказов получено и проанализировано, до проектирования нужны уточнения по обмену с 1С и спорным правилам**.
 
 В текущей CRM реализован:
 
@@ -36,7 +37,6 @@
 
 - `График заказов`;
 - `График доставок`;
-- новую верхнюю группу меню `Графики`;
 - связи между графиками.
 
 После анализа `manager.stroyprofit.com` установлено:
@@ -46,7 +46,7 @@
 - payload содержит заказ, клиента, договор, оплату, доставку, менеджера и список позиций;
 - позиции сейчас не нормализуются, а сохраняются только в сформированный Excel-файл;
 - поддерживаются до трёх доставок через фиксированные колонки;
-- финальные требования нового `Графика заказов` будут переданы отдельным ТЗ и могут расширить существующие сценарии.
+- новое ТЗ от 20.08.2026 существенно расширяет сценарии: ручное создание, отдельные экземпляры МАФ, файлы и чат, документы, уведомления, аудит, импорт/экспорт и рекламации типа `Прочее`.
 
 ## 3. Место в меню
 
@@ -86,7 +86,9 @@
 
 ## 5. График заказов
 
-Статус: **исходная реализация изучена; проектирование и разработка начинаются после отдельного ТЗ**.
+Статус: **ТЗ от 20.08.2026 получено и проанализировано; проектирование начинается после ответа на блокирующие вопросы**.
+
+Полный состав требований и анализ: [ТЗ: График заказов от 20.08.2026](tz-order-schedule.md).
 
 Назначение:
 
@@ -103,7 +105,7 @@
 - связь с `Каталог общий`;
 - связь с `График монтажей`.
 
-Архитектурные требования, принятые до получения финального ТЗ:
+Архитектурные требования с учётом нового ТЗ:
 
 - не переносить таблицу `graf1` как есть;
 - хранить заказ, позиции заказа, доставки и загрузки 1С отдельными нормализованными сущностями;
@@ -143,13 +145,12 @@
 
 Открытые вопросы:
 
-- какой финальный состав полей и сценариев будет утверждён отдельным ТЗ;
 - может ли 1С передавать стабильный GUID заказа вместо ключа, собранного из номера и года;
-- может ли 1С передавать артикул позиции для связи с `Каталог общий`;
-- нужен ли ручной ввод/редактирование или график полностью загружается;
-- какие статусы производства должны отображаться;
+- может ли 1С передавать артикул общего каталога и идентификатор каждого экземпляра МАФ;
 - какие поля принадлежат 1С, а какие должны сохраняться при повторной синхронизации;
-- какие части старых заявок на доставку и монтаж нужно сохранить в новом модуле.
+- как трактовать даты отгрузки и какой календарь использовать для рабочих дней;
+- допускаются ли несколько доставок и монтажных этапов, в том числе только для выбранных МАФ;
+- является ли `Водитель` ролью доступа или отдельным признаком пользователя.
 
 ## 6. График доставок
 
@@ -247,16 +248,18 @@
 
 Для `График монтажей` использовать текущие модели и таблицы.
 
-Для `График заказов` и `График доставок` модели проектируются отдельно после получения финального ТЗ. Независимо от точных имён таблиц модель должна быть нормализована.
+Для `График заказов` и `График доставок` модели проектируются отдельно после уточнения требований нового ТЗ. Независимо от точных имён таблиц модель должна быть нормализована.
 
 Минимально потребуются сущности:
 
 - производственный заказ;
-- позиция производственного заказа со ссылкой на `Каталог общий`, когда сопоставление возможно;
+- отдельный экземпляр МАФ производственного заказа со ссылкой на `Каталог общий`, когда сопоставление возможно;
 - произвольное количество доставок по заказу;
+- произвольное количество монтажных этапов по заказу;
 - водитель или ответственный доставки;
-- журнал загрузок из 1С.
+- журнал загрузок из 1С;
 - журнал ошибок и результатов сопоставления;
+- журнал значимых изменений заказа;
 - безопасно сохранённый исходный payload или ссылка на него для диагностики.
 
 Запрещённые варианты модели:
@@ -269,9 +272,12 @@
 Открыто:
 
 - точные имена таблиц и моделей;
-- структура полей;
-- необходимость истории изменений;
-- связь с существующими `Order`, `Product`, `ProductSKU`;
+- стабильные идентификаторы заказа и экземпляров МАФ в 1С;
+- принадлежность синхронизируемых и локально редактируемых полей;
+- календарь рабочих дней и трактовка четырёх дат отгрузки;
+- роль или должность `Водитель`;
+- формат импорта/экспорта заказа и его экземпляров МАФ;
+- способ связи с существующими `Order`, `ProductSKU`, `Schedule` и `Reclamation` без смешивания с ДКР;
 - правила миграции дублей и некорректных дат старого `graf1`.
 
 ## 10. Первый этап реализации
@@ -310,7 +316,9 @@
 - [x] Проверить экспорт графика монтажей.
 - [x] Изучить старый график заказов/отгрузок и существующий обмен с 1С.
 - [x] Зафиксировать нормализованную модель как обязательный архитектурный принцип.
-- [ ] Получить отдельное ТЗ и составить по нему финальный список полей графика заказов.
+- [x] Получить отдельное ТЗ на график заказов.
+- [x] Конвертировать ТЗ от 20.08.2026 в Markdown, сохранить референс интерфейса и сопоставить требования с планом и кодовой базой.
+- [ ] Согласовать вопросы нового ТЗ и утвердить финальный список полей графика заказов.
 - [ ] Составить отдельный список полей для будущего графика доставок.
 - [ ] Реализовать карточку заказа с выбором одного или нескольких МАФ.
 - [ ] Добавить действие `Добавить рекламацию`.
@@ -333,11 +341,4 @@
 
 ## 13. Открытые вопросы
 
-- Какие дополнительные требования войдут в отдельное ТЗ графика заказов?
-- Передаёт ли 1С стабильный GUID заказа и артикулы позиций?
-- Какие поля должны отображаться в графике заказов по финальному ТЗ?
-- Нужен ли ручной ввод в графике заказов?
-- Где хранить список водителей для графика доставок?
-- Нужен ли отдельный модуль `Отгрузки`, или график доставок закрывает эту задачу?
-- Какие статусы нужны для доставок?
-- Как должна выглядеть связь между графиком заказов и графиком монтажей?
+Полный перечень сформирован в [разделе 12 нового ТЗ](tz-order-schedule.md#12-вопросы-для-согласования). Блокирующими являются стабильные идентификаторы 1С, правила повторной синхронизации, принадлежность редактируемых полей и календарь рабочих дней. До реализации соответствующих частей также нужно согласовать несколько доставок/монтажей, роль водителя, права на поля, формат XLSX, аудит и шаблон заявки на доставку.