documented order schedule answers and delivery template

docs/refactor/menu.md

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

docs/refactor/plan.md

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

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

@@ -0,0 +1,187 @@
+# Ответы на вопросы по ТЗ «График заказов»
+
+Источник: `ТЗ_20_08_График_заказов_ОТВЕТЫ_НА_ВОПРОСЫ.docx`.
+
+Дата получения: **27.08.2026**.
+
+Связанные документы:
+
+- [ТЗ: График заказов от 20.08.2026](tz-order-schedule.md)
+- [ТЗ: Модуль Графики](tz-schedules.md)
+- [План реорганизации](plan.md)
+- шаблон `templates/DeliveryRequest.xls`
+
+## 1. Ответы заказчика
+
+### 1.1. Интеграция с 1С
+
+1. **Стабильный GUID заказа и уникальность номера**
+
+   Состав данных 1С пока неизвестен, требуется подключить специалиста по 1С. Номер заказа без года не уникален. На фабрике используются номера вида `1015.26`, `945.25`; идентификатор в CRM желательно согласовать с этим форматом.
+
+2. **Артикул общего каталога и идентификатор экземпляра МАФ**
+
+   Неизвестно, передаёт ли их 1С. Требуется уточнение у специалиста по 1С.
+
+3. **Первичные поля 1С и сохранение локальных изменений**
+
+   Однозначное правило не сформулировано. При аннулировании заказа все позиции перемещаются на склад; при частичном изменении часть позиций перемещается на склад, остальные остаются в заказе. Изменения юридического лица допускается вносить вручную.
+
+4. **Повторное действие `Перенести в график`**
+
+   Ожидается поведение по аналогии с ДКР: предложить заменить старую строку либо добавить новую запись в нужный день без удаления старой. Это описывает пользовательский сценарий графика, но не полностью определяет идемпотентность повторной загрузки заказа из 1С.
+
+### 1.2. Даты и производственный календарь
+
+5. **Расчёт рабочих дней**
+
+   Используется производственный календарь с праздниками и переносами, а не только понедельник–пятница.
+
+6. **Наименования дат отгрузки**
+
+   Во всех представлениях должны остаться два одинаково названных поля:
+
+   - `Дата отгрузки по договору` — прежняя плановая дата отгрузки, рассчитываемая по дате оплаты и сроку поставки;
+   - `Дата отгрузки по заявке` — прежняя дата отгрузки с фабрики.
+
+### 1.3. Доставки, монтажи и пользователи
+
+7. **Несколько доставок и этапов монтажа**
+
+   Допускается несколько доставок и несколько этапов монтажа по одному заказу. Пользователь добавляет дополнительные строки кнопкой `+`, по аналогии с добавлением запчастей в рекламации. Для каждой доставки указываются дата и водитель; для каждого этапа монтажа — собственные параметры.
+
+   Добавление в график фиксируется в журнале карточки, например: `Назначена доставка на 01.01.1990, водитель Сидоров А. А., изменил Тукалин М. В.`
+
+8. **Роль водителя**
+
+   Нужна отдельная роль `Водитель`. Пользователи этой роли выводятся в списке выбора водителя по аналогии с выбором бригадира в ДКР. Исходное ТЗ также допускает выбор пользователей роли `Бригадир`. Роль `Водитель` должна участвовать в текущей ролевой модели, чтобы администратор управлял её правами.
+
+9. **Редактирование ручных полей**
+
+   Помимо администратора адрес, примечание, доставку, монтаж, заводской номер и дату производства может редактировать `Помощник руководителя`. Доступ к этим полям должен управляться текущим механизмом ролевой модели.
+
+### 1.4. Уведомления и аудит
+
+10. **События уведомлений**
+
+    Настраиваемые события:
+
+    - создан заказ;
+    - изменён статус заказа;
+    - добавлена доставка;
+    - добавлена дата монтажа;
+    - добавлена рекламация по адресу.
+
+    Уведомления получают привязанные к заказу менеджер, водитель и бригадир, если событие и канал включены в настройках пользователя.
+
+11. **Состав аудита**
+
+    В журнал включаются только:
+
+    - изменение статуса;
+    - добавление в график доставок;
+    - добавление в график монтажей.
+
+    Изменение обычных полей, а также старые и новые значения в журнал не выводятся.
+
+### 1.5. Импорт, экспорт и файлы
+
+12. **Экспорт списка заказов**
+
+    Используется подход экспорта площадок ДКР: одна строка на заказ, оборудование суммируется и выводится в одной колонке, выгружаются все поля заказа. Экспорт учитывает активные фильтры списка.
+
+13. **Обновление ручным импортом**
+
+    Нужно предусмотреть обновление заказа из файла по внутреннему `ID` заказа.
+
+14. **Паспорт МАФ**
+
+    В строку экземпляра МАФ загружается готовый скан паспорта по аналогии с площадками ДКР. Отдельный шаблон паспорта не требуется.
+
+15. **Шаблон заявки на доставку**
+
+    Получен файл `Шаблон заявки на доставку 2026.xls`, сохранённый в проекте как `templates/DeliveryRequest.xls`.
+
+16. **Количество функциональных кнопок**
+
+    Число `5` в исходном ТЗ ошибочно. Нужно реализовать все перечисленные действия карточки.
+
+### 1.6. Рекламации и отчётность
+
+17. **Отчётность рекламаций**
+
+    Рекламации типов `Прочее` и `ДКР` должны иметь разные отчёты.
+
+## 2. Разбор шаблона заявки на доставку
+
+Файл содержит один лист `TDSheet`, печатную область `B1:AG94` и две встроенные иллюстрации в памятке водителю. Справа от печатной области находятся пояснения заказчика по заполнению полей.
+
+Данные из карточки заказа:
+
+- дата создания заявки;
+- номер и дата счёта;
+- номер и дата договора;
+- номер заказа;
+- менеджер и его телефон;
+- водитель;
+- заказчик;
+- доставка или самовывоз;
+- адрес доставки;
+- выбранная дата доставки;
+- агрегированный список оборудования;
+- примечание;
+- дата и подпись менеджера.
+
+Данные, вводимые в модальном окне при создании заявки:
+
+- перевозчик;
+- номер/дата заявки;
+- время;
+- примечание перевозчику;
+- должность, Ф. И. О. и телефон контактного лица;
+- желаемое время доставки;
+- пропускная система;
+- место выгрузки;
+- необходимость и срок предварительного предупреждения;
+- способ подписания документов;
+- наличие паспортов и сертификатов;
+- дополнительный комментарий.
+
+Технические требования к реализации:
+
+- исходный XLS сохраняется как шаблон, а заполненный результат формируется через очередь;
+- пояснения за пределами `B1:AG94` не должны попадать в печать/PDF;
+- тест должен проверять сохранение печатной области, памятки и встроенных изображений;
+- позиции заказа перед выводом агрегируются по артикулу и наименованию;
+- отдельная заявка формируется для конкретной доставки, поскольку один заказ может иметь несколько доставок.
+
+## 3. Что разблокировано
+
+- нормализованная модель заказа и отдельных экземпляров МАФ;
+- ручное создание и редактирование;
+- два однозначно названных поля отгрузки;
+- производственный календарь;
+- модель `один заказ — много доставок/монтажей`;
+- роль `Водитель` и исходные права помощника руководителя;
+- события уведомлений и состав аудита;
+- экспорт списка с учётом фильтров;
+- паспорт как готовый скан;
+- генерация заявки на доставку по полученному шаблону;
+- отдельная отчётность рекламаций типа `Прочее`.
+
+## 4. Что осталось уточнить
+
+### Блокирует только интеграцию с 1С
+
+1. Стабильный GUID/ключ заказа в payload.
+2. Артикул общего каталога и идентификатор строки или экземпляра МАФ.
+3. Полный payload и контракт API.
+4. Правила повторной синхронизации, конфликтов, аннулирования и частичного изменения состава заказа.
+
+### Нужно зафиксировать до импорта XLS
+
+5. Может ли импорт создавать новые заказы или только обновлять существующие по `ID`.
+6. Как обрабатывать пустой, неизвестный или принадлежащий другому окружению `ID`.
+7. Нужен ли отдельный лист с экземплярами МАФ при импорте, если экспорт содержит агрегированное оборудование в одной колонке.
+
+Эти вопросы не блокируют разработку ручного ядра графика заказов, доставок, монтажей, файлов, уведомлений, аудита и экспорта заявки на доставку.

docs/refactor/tz-order-schedule.md

@@ -2,12 +2,13 @@
 
 Источник: `ТЗ 20.08 График заказов.docx`.
 
-Статус: **получено и проанализировано; перед проектированием обмена с 1С и графиков доставок/монтажей требуются уточнения**.
+Статус: **получено, проанализировано и дополнено ответами заказчика от 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)
@@ -234,38 +235,49 @@
 
 Даже если интерфейс первого релиза показывает одну дату доставки и одну дату монтажа, модель доставок и монтажей не должна фиксировать лимит в одну запись: в старом Manager уже существовало до трёх доставок по одному заказу.
 
-## 12. Вопросы для согласования
+## 12. Результат согласования вопросов
+
+Ответы заказчика и разбор полученного XLS зафиксированы отдельно: [Ответы на вопросы по ТЗ](tz-order-schedule-answers.md).
+
+Согласовано:
+
+- номер заказа без года не уникален; внешний формат должен учитывать год;
+- расчёт выполняется по производственному календарю с праздниками и переносами;
+- используются названия `Дата отгрузки по договору` и `Дата отгрузки по заявке`;
+- заказ может иметь несколько доставок и несколько этапов монтажа;
+- вводится отдельная роль `Водитель`;
+- помощник руководителя получает редактирование указанных полей через ролевую модель;
+- определены события уведомлений и их получатели;
+- аудит содержит изменения статуса и добавление в графики без диффа обычных полей;
+- экспорт учитывает фильтры и агрегирует оборудование в одной колонке;
+- импорт должен уметь обновлять заказ по его внутреннему ID;
+- паспорт загружается готовым сканом;
+- реализуются все перечисленные кнопки карточки;
+- рекламации `Прочее` и `ДКР` имеют разную отчётность;
+- получен шаблон заявки на доставку.
+
+Остаются вопросы по 1С и точным правилам ручного импорта.
 
 ### Блокирующие проектирование и обмен с 1С
 
-1. Какой стабильный GUID заказа передаёт 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. Подтвердить, что рекламации типа `Прочее` не участвуют только в отчётах ДКР, но могут иметь собственную отчётность.
+3. Какие поля 1С являются первичными, а какие локальные изменения должны сохраняться при повторной синхронизации?
+4. Как обрабатывать повторную загрузку, аннулирование и частичное изменение состава заказа?
+
+### Требуют уточнения до реализации ручного импорта
+
+5. Может ли XLS создавать новые заказы или только обновлять существующие по `ID`?
+6. Как обрабатывать отсутствующий или неизвестный `ID`?
+7. Как импортировать отдельные экземпляры МАФ, если оборудование в общем экспорте агрегировано в одной колонке?
 
 ## 13. Рекомендуемая последовательность реализации
 
-1. Согласовать открытые вопросы по идентификаторам 1С, принадлежности полей и календарю рабочих дней.
-2. Спроектировать нормализованные таблицы заказов, экземпляров МАФ, доставок, монтажей, загрузок и аудита.
+1. Спроектировать нормализованные таблицы заказов, экземпляров МАФ, доставок, монтажей и аудита.
+2. Реализовать ручное ядро независимо от будущего обмена с 1С.
 3. Реализовать справочники, права и базовую карточку с ручным созданием заказа.
-4. Реализовать идемпотентный API обмена с 1С и журнал загрузок.
-5. Добавить документы, фотографии, чат, паспорт МАФ и техническую документацию.
-6. Реализовать экспорт/импорт, уведомления и аудит.
-7. Связать заказ с графиками доставок и монтажей.
-8. Реализовать рекламации типа `Прочее` по выбранным экземплярам МАФ.
+4. Добавить документы, фотографии, чат, паспорт МАФ и техническую документацию.
+5. Реализовать доставки, монтажи, уведомления, аудит и заявку на доставку.
+6. Реализовать экспорт с фильтрами; ручной импорт — после уточнения оставшихся правил.
+7. Реализовать рекламации типа `Прочее` по выбранным экземплярам МАФ.
+8. После контакта со специалистом 1С спроектировать и реализовать идемпотентный API обмена с журналом загрузок.

docs/refactor/tz-schedules.md

@@ -5,6 +5,7 @@
 - [План реорганизации](plan.md)
 - [Карта нового меню](menu.md)
 - [ТЗ: График заказов от 20.08.2026](tz-order-schedule.md)
+- [Ответы заказчика от 27.08.2026](tz-order-schedule-answers.md)
 - [ТЗ: Каталог общий](tz-catalog-common.md)
 - [ТЗ: Модуль ДКР](tz-dkr.md)
 
@@ -20,7 +21,7 @@
 
 ## 2. Статус
 
-Статус модуля: **частично реализован; ТЗ на график заказов получено и проанализировано, до проектирования нужны уточнения по обмену с 1С и спорным правилам**.
+Статус модуля: **частично реализован; ТЗ и ответы заказчика проанализированы, ручное ядро готово к проектированию и реализации, обмен с 1С ожидает отдельного согласования со специалистом 1С**.
 
 В текущей CRM реализован:
 
@@ -86,9 +87,9 @@
 
 ## 5. График заказов
 
-Статус: **ТЗ от 20.08.2026 получено и проанализировано; проектирование начинается после ответа на блокирующие вопросы**.
+Статус: **ТЗ и ответы заказчика получены; ручное ядро, доставки, монтажи, уведомления, аудит и документы готовы к реализации независимо от будущего обмена с 1С**.
 
-Полный состав требований и анализ: [ТЗ: График заказов от 20.08.2026](tz-order-schedule.md).
+Полный состав требований и анализ: [ТЗ: График заказов от 20.08.2026](tz-order-schedule.md), [ответы заказчика от 27.08.2026](tz-order-schedule-answers.md).
 
 Назначение:
 
@@ -148,9 +149,8 @@
 - может ли 1С передавать стабильный GUID заказа вместо ключа, собранного из номера и года;
 - может ли 1С передавать артикул общего каталога и идентификатор каждого экземпляра МАФ;
 - какие поля принадлежат 1С, а какие должны сохраняться при повторной синхронизации;
-- как трактовать даты отгрузки и какой календарь использовать для рабочих дней;
-- допускаются ли несколько доставок и монтажных этапов, в том числе только для выбранных МАФ;
-- является ли `Водитель` ролью доступа или отдельным признаком пользователя.
+- как 1С сообщает аннулирование и частичное изменение состава заказа;
+- может ли ручной XLS-импорт создавать новые заказы и как передавать в нём отдельные экземпляры МАФ.
 
 ## 6. График доставок
 
@@ -185,12 +185,15 @@
 
 Открытые вопросы:
 
-- где хранится список водителей;
-- нужна ли отдельная сущность `Водитель`;
 - какие статусы есть у доставки;
 - нужна ли связь с отдельным разделом `Отгрузки`;
-- требуется ли печатная форма или экспорт недельного списка;
-- как обрабатывать несколько доставок по одному заказу.
+- нужен ли отдельный экспорт недельного списка помимо полученного шаблона заявки на одну доставку.
+
+Согласовано:
+
+- водитель выбирается среди пользователей роли `Водитель` и, согласно исходному ТЗ, `Бригадир`;
+- один заказ может иметь несколько отдельных записей доставки;
+- получен шаблон печатной заявки на конкретную доставку `templates/DeliveryRequest.xls`.
 
 ## 7. График монтажей
 
@@ -248,7 +251,7 @@
 
 Для `График монтажей` использовать текущие модели и таблицы.
 
-Для `График заказов` и `График доставок` модели проектируются отдельно после уточнения требований нового ТЗ. Независимо от точных имён таблиц модель должна быть нормализована.
+Для `График заказов` и `График доставок` проектируются отдельные модели. Полученные ответы позволяют начинать проектирование ручного контура; модели интеграционных загрузок уточняются после согласования контракта с 1С. Независимо от точных имён таблиц модель должна быть нормализована.
 
 Минимально потребуются сущности:
 
@@ -274,9 +277,8 @@
 - точные имена таблиц и моделей;
 - стабильные идентификаторы заказа и экземпляров МАФ в 1С;
 - принадлежность синхронизируемых и локально редактируемых полей;
-- календарь рабочих дней и трактовка четырёх дат отгрузки;
-- роль или должность `Водитель`;
-- формат импорта/экспорта заказа и его экземпляров МАФ;
+- источник и обновление производственного календаря;
+- формат импорта отдельных экземпляров МАФ и обработка отсутствующего/неизвестного ID;
 - способ связи с существующими `Order`, `ProductSKU`, `Schedule` и `Reclamation` без смешивания с ДКР;
 - правила миграции дублей и некорректных дат старого `graf1`.
 
@@ -318,8 +320,12 @@
 - [x] Зафиксировать нормализованную модель как обязательный архитектурный принцип.
 - [x] Получить отдельное ТЗ на график заказов.
 - [x] Конвертировать ТЗ от 20.08.2026 в Markdown, сохранить референс интерфейса и сопоставить требования с планом и кодовой базой.
-- [ ] Согласовать вопросы нового ТЗ и утвердить финальный список полей графика заказов.
-- [ ] Составить отдельный список полей для будущего графика доставок.
+- [x] Получить и проанализировать ответы заказчика от 27.08.2026.
+- [x] Согласовать календарь, даты отгрузки, несколько доставок/монтажей, роль водителя, права, уведомления и аудит.
+- [x] Получить и разобрать шаблон заявки на доставку `templates/DeliveryRequest.xls`.
+- [ ] Согласовать со специалистом 1С контракт API, идентификаторы и правила повторной синхронизации.
+- [ ] Уточнить создание новых заказов и передачу экземпляров МАФ через ручной XLS-импорт.
+- [x] Составить базовый список полей для графика доставок.
 - [ ] Реализовать карточку заказа с выбором одного или нескольких МАФ.
 - [ ] Добавить действие `Добавить рекламацию`.
 - [ ] Открывать текущую форму рекламации с переданными заказом и выбранными МАФ.
@@ -341,4 +347,4 @@
 
 ## 13. Открытые вопросы
 
-Полный перечень сформирован в [разделе 12 нового ТЗ](tz-order-schedule.md#12-вопросы-для-согласования). Блокирующими являются стабильные идентификаторы 1С, правила повторной синхронизации, принадлежность редактируемых полей и календарь рабочих дней. До реализации соответствующих частей также нужно согласовать несколько доставок/монтажей, роль водителя, права на поля, формат XLSX, аудит и шаблон заявки на доставку.
+Актуальный перечень сформирован в [ответах заказчика](tz-order-schedule-answers.md#4-что-осталось-уточнить). Вопросы по 1С блокируют только интеграцию с 1С. Для ручного импорта отдельно нужно уточнить создание новых заказов, обработку неизвестного ID и передачу экземпляров МАФ.