added refactoring documentation

docs/menu.md

@@ -0,0 +1,3 @@
+# Новое меню Manager
+
+Актуальная карта меню перенесена в [docs/refactor/menu.md](refactor/menu.md).

docs/refactor/menu.md

@@ -0,0 +1,203 @@
+# Новое меню Manager
+
+Документ фиксирует целевую древовидную структуру меню по ТЗ Manager 2.0 и текущий статус разделов в существующей Laravel CRM.
+
+## Легенда статусов
+
+- **Есть** — раздел уже реализован и имеет рабочие маршруты/страницы.
+- **Частично** — есть близкий текущий функционал, но его нужно переименовать, перенести в другую группу или доработать под новое ТЗ.
+- **Нужно реализовать** — раздела нет, на первом этапе нужна страница-заглушка "В разработке".
+- **Уточнить** — требуется продуктовая/архитектурная развилка перед реализацией.
+
+## Целевое верхнее меню
+
+```text
+Manager
+├── ДКР
+│   ├── Площадки
+│   ├── МАФ
+│   ├── Каталог
+│   ├── Отчеты
+│   ├── Ответственные
+│   └── Заказы МАФ
+├── Графики
+│   ├── График заказов
+│   ├── График доставок
+│   └── График монтажей
+├── Рекламации
+│   ├── Все
+│   └── ДКР
+├── Запчасти
+│   ├── Каталог
+│   ├── Заказы запчастей
+│   ├── Контроль наличия
+│   ├── Справочник расшифровок
+│   └── Справка
+├── Склад наличие
+│   ├── Наличие
+│   └── Заказы
+├── Каталог общий
+│   ├── Позиции
+│   └── Карточка позиции
+├── Документация
+├── Технич. описание
+├── Калькуляции
+└── Администратор
+    ├── Подрядчики
+    ├── Договоры
+    ├── Пользователи
+    ├── Роли и права
+    ├── Настройки
+    ├── Округа
+    ├── Районы
+    ├── Журнал уведомлений
+    ├── Импорт
+    ├── Экспорт/Импорт года
+    └── Удалить данные
+```
+
+## Детализация по разделам
+
+### ДКР
+
+Статус: **Есть**, требуется реорганизация меню.
+
+ДКР должен стать отдельной верхней группой. Текущие пункты верхнего меню нужно сгруппировать внутрь него без изменения действующей логики.
+
+| Пункт | Статус | Текущий маршрут | Комментарий |
+|---|---|---|---|
+| Площадки | Есть | `order.index` | Сейчас верхний пункт `Площадки`. |
+| МАФ | Есть | `product_sku.index` | Сейчас верхний пункт `МАФ`. В коде также помечен как склад МАФ. |
+| Каталог | Есть | `catalog.index` | Каталог ДКР. Это отдельная сущность, не `Каталог общий`. |
+| Отчеты | Есть | `reports.index` | Сейчас верхний пункт `Отчёты`. |
+| Ответственные | Есть | `responsible.index` | Сейчас верхний пункт `Ответственные`. |
+| Заказы МАФ | Есть | `maf_order.index` | Сейчас верхний пункт `Заказы МАФ`. |
+
+Принятое решение: `Каталог` ДКР и `Каталог общий` — разные сущности. Каталог ДКР остается внутри ДКР и продолжает работать по текущим маршрутам. `Каталог общий` реализуется отдельно как общий справочник платформы.
+
+### Графики
+
+Статус: **Частично**.
+
+Нужна новая верхняя группа `Графики`. На первом этапе недостающие пункты можно добавить как заглушки.
+
+| Пункт | Статус | Текущий маршрут | Комментарий |
+|---|---|---|---|
+| График заказов | Нужно реализовать | - | По ТЗ: производственный график, загрузка через 1С, связь с каталогом и монтажами. |
+| График доставок | Нужно реализовать | - | По ТЗ: недельный список, адреса из графика заказов, ручная занятость водителей. |
+| График монтажей | Есть | `schedule.index` | Сейчас верхний пункт `График монтажей`; нужно перенести внутрь группы `Графики`. |
+
+### Рекламации
+
+Статус: **Частично**.
+
+Текущий раздел рекламаций есть, но в новом меню должен иметь внутренние вкладки/подпункты `Все` и `ДКР`.
+
+| Пункт | Статус | Текущий маршрут | Комментарий |
+|---|---|---|---|
+| Все | Есть | `reclamations.index` | Текущий общий список рекламаций. |
+| ДКР | Частично | `reclamations.index` | Текущий список с предустановленным фильтром по источнику `ДКР`. |
+
+### Запчасти
+
+Статус: **Есть**, требуется реорганизация меню.
+
+Раздел уже вынесен отдельным верхним пунктом `Запчасти` и внутри имеет вкладки. В новом меню можно сохранить его как верхнюю группу и явно отразить существующие подпункты.
+
+| Пункт | Статус | Текущий маршрут | Комментарий |
+|---|---|---|---|
+| Каталог | Есть | `spare_parts.index` | Каталог запчастей. |
+| Заказы запчастей | Есть | `spare_part_orders.index` | Текущий маршрут заказов запчастей; в старом интерфейсе мог называться `Заказы деталей`. |
+| Контроль наличия | Есть | `spare_part_inventory.index` | Текущая вкладка контроля наличия запчастей. |
+| Справочник расшифровок | Есть | `pricing_codes.index` | Показывать всем пользователям с доступом к модулю `Запчасти`. |
+| Справка | Есть | `spare_parts.help` | Текущая справочная страница раздела. |
+
+### Склад наличие
+
+Статус: **Нужно реализовать**.
+
+Новый раздел по ТЗ. Должен быть реализован полностью по образцу раздела `Запчасти`: структура вкладок, карточки, заказы, контроль остатков, бронирование, списание, отмена брони, история движений, импорт/экспорт и права доступа берутся как базовая модель поведения и адаптируются под МАФ/позиции из `Каталог общий`.
+
+На первом этапе нужны страницы-заглушки, затем отдельное ТЗ на модуль с привязкой к существующей логике `Запчасти`.
+
+| Пункт | Статус | Текущий маршрут | Комментарий |
+|---|---|---|---|
+| Наличие | Нужно реализовать | - | Видно всем пользователям. Список МАФ/позиций с остатком на складе больше 0. |
+| Заказы | Нужно реализовать | - | Доступ только админу и роли `assistant_head`. Ручное добавление заказов или импорт. |
+
+Отдельно в разделе потребуется PDF-экспорт наличия по шаблону.
+
+Базовый функциональный ориентир:
+
+- `Наличие` соответствует логике контроля наличия/остатков в разделе `Запчасти`.
+- `Заказы` соответствует логике заказов деталей в разделе `Запчасти`.
+- Карточка позиции должна повторять подход карточки запчасти/заказа: остатки, активные брони, действия списания и отмены, история.
+- Расчет доступного остатка, запрет брони сверх доступного количества, списание с конкретных заказов и сохранение истории должны работать по той же логике, что и в `Запчасти`.
+- Отличие доменной модели: вместо запчастей используются МАФ/позиции из `Каталог общий`, а отображаемые поля позиции берутся из общего каталога.
+
+### Каталог общий
+
+Статус: **Частично**.
+
+По ТЗ это центральный справочник платформы. Это отдельная сущность, не каталог ДКР. Текущий `catalog.index` остается каталогом ДКР; для общего каталога используются маршруты с префиксом `common-catalog/...`, а таблицы и права получают техническое имя `common-catalog`.
+
+| Пункт | Статус | Текущий маршрут | Комментарий |
+|---|---|---|---|
+| Позиции | Нужно реализовать | - | Новый общий справочник. Нужны колонки по шаблону калькулятора, импорт/экспорт. |
+| Карточка позиции | Нужно реализовать | - | Центральная карточка общей позиции/МАФ. |
+| Фото МАФ | Нужно реализовать | - | Фото позиции общего каталога. |
+| Документы | Нужно реализовать | - | Сопутствующие документы позиции через текущий файловый механизм. |
+| Техническое описание | Уточнить / встроить | - | Вероятно поглощается общим каталогом как выгрузка/представление позиции в нужном формате. |
+| Калькуляция | Нужно реализовать | - | API-запрос по артикулу и отображение возвращенной калькуляции, если она есть. |
+
+### Документация
+
+Статус: **Нужно реализовать**.
+
+Новый раздел для папок и файлов: инструкции, прайсы, прочая документация. На первом этапе нужна заглушка.
+
+### Технич. описание
+
+Статус: **Уточнить / вероятно встроить в каталог**.
+
+По новым вводным это, вероятно, не отдельный модуль, а часть `Каталог общий`: по сути те же данные позиции, но с выгрузками в определенном формате. Есть готовый Laravel-модуль, из которого можно взять экспорт.
+
+### Калькуляции
+
+Статус: **Нужно реализовать позже**.
+
+Калькуляции работают через внешний API: запрос выполняется по артикулу, в ответ возвращается калькуляция, если она найдена. Подробное описание API будет предоставлено отдельно.
+
+### Администратор
+
+Статус: **Есть**, требуется переименование группы.
+
+Сейчас группа называется `Администрирование`. В новом меню по ТЗ целевое название — `Администратор`.
+
+| Пункт | Статус | Текущий маршрут | Комментарий |
+|---|---|---|---|
+| Подрядчики | Есть | `contractors.index` | Всегда показывать внутри группы `Администратор`; отдельным верхним пунктом не выводить. |
+| Договоры | Есть | `contract.index` | Сейчас внутри `Администрирование`. |
+| Пользователи | Есть | `user.index` | Сейчас внутри `Администрирование`. |
+| Роли и права | Есть | `admin.roles.index` | Сейчас внутри `Администрирование`. |
+| Настройки | Есть | `admin.settings.index` | Сейчас внутри `Администрирование`. |
+| Округа | Есть | `admin.district.index` | Сейчас внутри `Администрирование`. |
+| Районы | Есть | `admin.area.index` | Сейчас внутри `Администрирование`. |
+| Журнал уведомлений | Есть | `admin.notifications.log` | Сейчас внутри `Администрирование`. |
+| Импорт | Есть | `import.index` | Сейчас внутри `Администрирование`. |
+| Экспорт/Импорт года | Есть | `year-data.index` | Сейчас внутри `Администрирование`. |
+| Удалить данные | Есть | `clear-data.index` | Сейчас внутри `Администрирование`. |
+
+## Предлагаемый первый этап реализации
+
+1. Перестроить `resources/views/layouts/menu.blade.php` под верхние группы из этого документа.
+2. Для разделов без реализации добавить общую страницу-заглушку `В разработке`.
+3. Сохранить текущие права доступа для уже существующих пунктов.
+4. Для новых пунктов-заглушек открыть доступ всем авторизованным пользователям.
+5. Не менять бизнес-логику существующих модулей на этапе реорганизации меню.
+6. Для новых модулей не применять фильтрацию/ограничение по выбранному году.
+
+## Открытые вопросы
+
+1. Оставлять ли `Технич. описание` отдельным пунктом меню или полностью встроить в `Каталог общий`?
+2. Какой точный контракт внешнего API калькуляций?

docs/refactor/plan.md

@@ -0,0 +1,174 @@
+# План реорганизации Manager 2.0
+
+Рабочая папка рефакторинга: `docs/refactor/`.
+
+Связанные документы:
+
+- [Исходное ТЗ](source-tz.md)
+- [Карта нового меню](menu.md)
+- [ТЗ: ДКР](tz-dkr.md)
+- [ТЗ: Каталог общий](tz-catalog-common.md)
+- [ТЗ: Графики](tz-schedules.md)
+- [ТЗ: Рекламации](tz-reclamations.md)
+- [ТЗ: Запчасти](tz-spare-parts.md)
+- [ТЗ: Склад наличие](tz-stock-availability.md)
+- [ТЗ: Документация](tz-documents.md)
+- [ТЗ: Технич. описание](tz-technical-description.md)
+- [ТЗ: Калькуляции](tz-calculations.md)
+- [ТЗ: Администратор](tz-admin.md)
+
+## Цель
+
+Перевести текущую CRM в структуру Manager 2.0: реорганизовать верхнее меню, сохранить самостоятельный модуль ДКР с его собственным каталогом, добавить отдельный `Каталог общий`, добавить заглушки для новых модулей и подготовить отдельные ТЗ по каждому разделу перед глубокой разработкой.
+
+## Принятые решения
+
+- [x] ДКР остается самостоятельным модулем.
+- [x] Каталог ДКР и `Каталог общий` — разные сущности.
+- [x] Каталог ДКР остается внутри меню ДКР.
+- [x] `Каталог общий` реализуется отдельно как общий справочник платформы.
+- [x] `Запчасти` — общий модуль для всей платформы, включая ДКР.
+- [x] `Склад наличие` должен быть реализован полностью по образцу раздела `Запчасти`, с адаптацией под МАФ/позиции из `Каталог общий`.
+- [x] Новые модули на первом этапе получают страницы-заглушки `В разработке`.
+- [x] Основная карта меню хранится в [docs/refactor/menu.md](menu.md).
+- [x] Текущие рабочие маршруты оставляем без переименования.
+- [x] На первом этапе оставляем текущие права доступа.
+- [x] Реорганизацию меню делаем сразу общей для всей платформы Manager 2.0.
+- [x] Заглушки новых модулей показываем всем авторизованным пользователям.
+- [x] На новые модули выбранный год не влияет.
+- [x] `Технич. описание`, вероятно, будет поглощено модулем `Каталог общий`; готовый Laravel-модуль используем как источник экспорта.
+- [x] `Калькуляции` работают через внешний API: запрос по артикулу, возврат калькуляции при наличии.
+- [x] `Рекламации -> ДКР` реализуется как фильтр текущего списка.
+- [x] Источник рекламации хранится отдельным полем: при создании из площадки — `ДКР`, иначе `Прочее`.
+- [x] Маршруты `Каталог общий` используют префикс `common-catalog/...`.
+- [x] Таблицы и права `Каталог общий` используют техническое имя `common-catalog`.
+- [x] Техническое имя модуля `Склад наличие`: `stock`.
+- [x] Роль `помощник руководителя`: `assistant_head`.
+
+## Этап 0. Документация
+
+- [x] Изучить ТЗ Manager 2.0 и схему зависимостей.
+- [x] Составить карту нового меню.
+- [x] Перенести карту меню в `docs/refactor/menu.md`.
+- [x] Создать общий план реализации в `docs/refactor/plan.md`.
+- [x] Написать отдельное ТЗ для модуля `ДКР`: [tz-dkr.md](tz-dkr.md).
+- [x] Написать отдельное ТЗ для модуля `Каталог общий`: [tz-catalog-common.md](tz-catalog-common.md).
+- [x] Написать отдельное ТЗ для модуля `Графики`: [tz-schedules.md](tz-schedules.md).
+- [x] Написать отдельное ТЗ для модуля `Рекламации`: [tz-reclamations.md](tz-reclamations.md).
+- [x] Написать отдельное ТЗ для модуля `Запчасти`: [tz-spare-parts.md](tz-spare-parts.md).
+- [x] Написать отдельное ТЗ для модуля `Склад наличие`: [tz-stock-availability.md](tz-stock-availability.md).
+- [x] Написать отдельное ТЗ для модуля `Документация`: [tz-documents.md](tz-documents.md).
+- [x] Написать отдельное ТЗ для модуля `Технич. описание`: [tz-technical-description.md](tz-technical-description.md).
+- [x] Написать отдельное ТЗ для модуля `Калькуляции`: [tz-calculations.md](tz-calculations.md).
+- [x] Написать отдельное ТЗ для модуля `Администратор`: [tz-admin.md](tz-admin.md).
+
+## Этап 1. Реорганизация меню
+
+- [ ] Проверить текущие permissions для всех существующих пунктов меню.
+- [ ] Для новых пунктов-заглушек открыть доступ всем авторизованным пользователям.
+- [ ] Добавить общий механизм страницы `В разработке`.
+- [ ] Добавить маршруты для новых разделов-заглушек.
+- [ ] Перестроить `resources/views/layouts/menu.blade.php` под новую древовидную структуру.
+- [ ] Сгруппировать существующие пункты ДКР внутрь верхнего меню `ДКР`.
+- [ ] Оставить `Каталог` внутри меню `ДКР`.
+- [ ] Добавить отдельный верхний пункт `Каталог общий`.
+- [ ] Сгруппировать `График монтажей` внутрь верхнего меню `Графики`.
+- [ ] Добавить заглушки `График заказов` и `График доставок`.
+- [ ] Разложить `Рекламации` на `Все` и `ДКР`.
+- [ ] Оставить `Запчасти` отдельной верхней группой с текущими вкладками.
+- [ ] Добавить заглушки `Склад наличие -> Наличие` и `Склад наличие -> Заказы`.
+- [ ] Добавить заглушки `Документация`, `Каталог общий`, `Технич. описание`, `Калькуляции`.
+- [ ] Проверить, что выбранный год не скрывает и не фильтрует новые модули.
+- [ ] Переименовать группу `Администрирование` в `Администратор`.
+- [ ] Проверить отображение меню для основных ролей.
+
+## Этап 2. Каталог общий
+
+- [ ] Зафиксировать, что текущий `catalog.*` относится к каталогу ДКР.
+- [ ] Спроектировать маршруты с префиксом `common-catalog/...`, таблицы и права с техническим именем `common-catalog`.
+- [ ] Сверить текущую модель каталога ДКР с требованиями общего каталога как источник паттернов, без смешивания данных.
+- [ ] Определить недостающие поля по шаблону калькулятора.
+- [ ] Использовать текущий файловый механизм для хранения фото и документов позиции.
+- [ ] Доработать импорт/экспорт позиций.
+- [ ] Доработать карточку позиции.
+- [ ] Определить встраивание `Технич. описание` в карточку общего каталога.
+- [ ] Добавить интеграцию с `Калькуляции` через внешний API по артикулу.
+- [ ] Проверить связи с графиками, рекламациями и складом наличия.
+
+## Этап 3. Склад наличие
+
+- [ ] Разобрать текущую реализацию `Запчасти` как эталон.
+- [ ] Зафиксировать соответствие сущностей `Запчасти` -> `Склад наличие`.
+- [ ] Спроектировать таблицы/модели `stock` для заказов, остатков, броней, списаний и истории.
+- [ ] Реализовать подвкладку `Наличие`.
+- [ ] Реализовать подвкладку `Заказы`.
+- [ ] Реализовать карточку позиции.
+- [ ] Реализовать бронирование.
+- [ ] Реализовать списание с конкретных заказов.
+- [ ] Реализовать отмену брони.
+- [ ] Реализовать историю движений.
+- [ ] Реализовать импорт заказов/остатков.
+- [ ] Реализовать экспорт наличия в PDF по шаблону.
+- [ ] Настроить права: `Наличие` всем, `Заказы` админу и роли `assistant_head`.
+- [ ] Покрыть критичную логику расчетов тестами.
+
+## Этап 4. Графики
+
+- [ ] Описать источник данных для `График заказов`.
+- [ ] Спроектировать загрузку данных через 1С.
+- [ ] Реализовать или перенести `График заказов`.
+- [ ] Реализовать `График доставок` в виде недельного списка.
+- [ ] Добавить ручное планирование занятости водителей.
+- [ ] Связать доставки с адресами из графика заказов.
+- [ ] Перенести текущий `График монтажей` в новую группу без потери логики.
+- [ ] Проверить связи монтажей с ДКР-площадками и графиком заказов.
+
+## Этап 5. Рекламации
+
+- [ ] Разделить представление на `Все` и `ДКР`.
+- [ ] Реализовать `ДКР` как фильтр текущего списка.
+- [ ] Добавить отдельное поле источника рекламации: `ДКР` / `Прочее`.
+- [ ] Проверить создание рекламаций по площадкам ДКР.
+- [ ] Проверить связь рекламаций с графиком заказов.
+- [ ] Проверить формирование запросов на запчасти из рекламации.
+- [ ] Сохранить текущую рабочую логику рекламаций.
+
+## Этап 6. Запчасти
+
+- [ ] Перенести раздел в новую структуру меню без изменения бизнес-логики.
+- [ ] Проверить вкладки `Каталог`, `Заказы запчастей`, `Контроль наличия`, `Справочник расшифровок`, `Справка`.
+- [ ] Проверить, что `Запчасти` используются как общий модуль, включая ДКР.
+- [ ] Использовать реализацию раздела как эталон для `Склад наличие`.
+- [ ] После внедрения склада проверить, что логика запчастей не изменилась.
+
+## Этап 7. Информационные разделы
+
+- [ ] Реализовать модуль `Документация`: папки и файлы.
+- [ ] Изучить готовый Laravel-модуль техописаний.
+- [ ] Перенести/адаптировать экспорт техописаний в карточку общего каталога.
+- [ ] Подготовить заглушку для `Калькуляции`.
+- [ ] После получения подробного описания API калькуляций реализовать запрос из карточки позиции по артикулу.
+
+## Этап 8. Администратор
+
+- [ ] Переименовать меню `Администрирование` в `Администратор`.
+- [ ] Сохранить текущие пункты администрирования.
+- [ ] Проверить доступы для пользователей, ролей и настроек.
+- [ ] При необходимости добавить права для новых разделов Manager 2.0.
+
+## Этап 9. Проверка
+
+- [ ] Запустить `make test` внутри контейнеров.
+- [ ] Проверить меню в браузере под админом.
+- [ ] Проверить меню под пользователем с ограниченными правами.
+- [ ] Проверить, что существующие маршруты ДКР работают после перегруппировки меню.
+- [ ] Проверить, что текущий каталог доступен внутри ДКР.
+- [ ] Проверить, что `Каталог общий` открыт как отдельный новый раздел/заглушка.
+- [ ] Проверить, что все новые пункты-заглушки открываются у авторизованных пользователей и не дают 404/403.
+- [ ] Проверить, что выбранный год не влияет на новые модули.
+- [ ] Зафиксировать результат проверки в этом плане.
+
+## Открытые вопросы
+
+- [ ] Оставлять ли `Технич. описание` отдельным пунктом меню или полностью встроить в `Каталог общий`?
+- [ ] Какой точный контракт внешнего API калькуляций?

docs/refactor/source-tz.md

@@ -0,0 +1,269 @@
+**Техническое задание**
+
+**Разработка системы Manager**
+
+Версия 2.0 \| Июнь 2026
+
+# 1. Общая структура платформы
+
+Платформа состоит из следующих разделов верхнего уровня:
+
+- ДКР — самостоятельный модуль, не зависит от других вкладок
+
+- Графики — График заказов, График доставок, График монтажей
+
+- Рекламации — Все, ДКР
+
+- Запчасти — переносится из ДКР полностью как есть
+
+- Склад наличие — Наличие, Заказы
+
+- Каталог общий — центральный справочник всех позиций
+
+- Документация
+
+- Технич. описание
+
+- Калькуляции
+
+- Администратор
+
+Ключевые зависимости: Каталог общий является основой для Графиков, Склада наличие и Рекламаций. Вкладка ДКР (Площадки) используется в Рекламациях и Графике монтажей.
+
+# 2. Вкладка ДКР
+
+Самостоятельный модуль. Полностью реализован и функционирует. Не зависит от других вкладок платформы. Внутренние связи только между собственными подразделами.
+
+## 2.1 Подразделы ДКР
+
+- Площадки
+
+- МАФ
+
+- Каталог
+
+- Отчеты
+
+- Ответственные
+
+- Заказы МАФ
+
+Данные из «Площадок» используются в разделах: Рекламации (для формирования рекламаций по ДКР) и График монтажей.
+
+# 3. Каталог общий
+
+Центральный справочник платформы. Добавляется в общую платформу как отдельная вкладка «Каталог общий». На его основе строятся остальные разделы.
+
+## 3.1 Функционал
+
+- Импорт и экспорт позиций
+
+- Колонки: в соответствии с шаблоном калькулятора
+
+- Карточка товара (двойной клик → провал в позицию):
+
+  - Редактируемые поля
+
+  - Загрузка фото МАФ
+
+  - Поле «Документы» — подгрузка любых сопутствующих документов
+
+  - Кнопка «Техническое описание» — переход во вкладку тех. описания данной позиции
+
+  - Кнопка «Калькуляция» — переход по API на платформу калькуляций
+
+## 3.2 Связи
+
+- → Склад наличие (Наличие): картинка, артикул, наименование, характеристики, ед. изм.
+
+- → Графики (График заказов): данные по позициям
+
+- → Рекламации: данные по позициям
+
+# 4. Раздел «Графики»
+
+## 4.1 График заказов (производство)
+
+Таблица с графиком заказов на производстве. Переносится функционал «график отгрузок» из manager с адаптацией под текущие реалии. Загрузка данных через 1С.
+
+### Связи:
+
+- ← Каталог общий (данные о позициях)
+
+- ↔ График монтажей (взаимная связь)
+
+## 4.2 График доставок
+
+Выводится в виде недельного списка. Адреса добавляются автоматически из Графика заказов.
+
+### Функционал:
+
+- Руками вписывается занятость водителей: какой заказ и когда везут
+
+- Добавление через модальное окно
+
+- Возможна связь с вкладкой Отгрузки (уточнить)
+
+### Связи:
+
+- ← График заказов (список адресов)
+
+## 4.3 График монтажей
+
+Остаётся в текущем виде, переносится в общую платформу.
+
+### Связи:
+
+- ← График заказов
+
+- ← Площадки из ДКР
+
+# 5. Рекламации
+
+Список рекламаций в текущем виде. Рекламации имеют два типа: по ДКР и Прочее.
+
+## 5.1 Вкладки
+
+- Все — общий список
+
+- ДКР — рекламации по программе ДКР
+
+## 5.2 Связи
+
+- ← Площадки (ДКР) — при создании рекламации типа «ДКР»
+
+- ← График заказов — при создании рекламации
+
+- → Запчасти — из рекламации формируется запрос на запчасть
+
+# 6. Запчасти
+
+Раздел переносится полностью из вкладки ДКР как есть, со всеми подвкладками.
+
+## 6.1 Связи
+
+- ← Рекламации — получение запросов на запчасти
+
+# 7. Склад наличие
+
+Реализуется по образцу вкладки «Запчасти». Отображает список МАФ с остатком на складе \> 0.
+
+## 7.1 Права доступа
+
+- Наличие — видно всем пользователям
+
+- Заказы — видит только админ и помощник руководителя
+
+## 7.2 Экспорт
+
+Кнопка «Экспорт» — экспорт в PDF по шаблону всех позиций в наличии.
+
+Шаблон PDF: подготовить отдельно.
+
+## 7.3 Подвкладка «Наличие»
+
+Выводится список МАФ у которых есть хотя бы одна запись в подвкладке «Заказы».
+
+### Колонки таблицы:
+
+- Картинка — из Каталога общего
+
+- Артикул — из Каталога общего
+
+- Наименование — из Каталога общего
+
+- Характеристики — из Каталога общего
+
+- Ед. измерения — из Каталога общего
+
+- Кол-во в наличии — из подвкладки «Заказы»
+
+- Забронировано — через функцию бронирования
+
+- Остаток фактический = Кол-во в наличии − Забронировано/Списано
+
+- Заказано — сумма позиций со статусом «заказан»
+
+- Примечание — заполняется при добавлении или импорте
+
+## 7.4 Карточка позиции (двойной клик)
+
+Нередактируемые поля — те же что в таблице.
+
+### Функция бронирования:
+
+- Кнопка «Забронировать» → модальное окно:
+
+  - Выбор менеджера из выпадающего списка
+
+  - Количество
+
+  - Примечание
+
+- Нельзя забронировать больше, чем есть в наличии → ошибка «Такого кол-ва нет в наличии»
+
+- После бронирования в карточке появляется список «Забронировано»:
+
+  - Менеджер, кол-во, номер заказа(ов), примечание
+
+  - Иконки: ✓ (списать) и ✕ (отменить бронь) — аналогично рекламациям
+
+### Логика списания (нажата ✓):
+
+- Кол-во списывается с соответствующих заказов
+
+- Сохраняется история: куда ушла позиция, из какого заказа
+
+- В карточке ведётся история: кем, когда, куда забронировано и списано
+
+### Остатки в карточке:
+
+Отображаются внизу карточки — аналогично реализации в «Запчастях».
+
+## 7.5 Подвкладка «Заказы»
+
+Ручное добавление заказов или через импорт.
+
+### Поля заказа:
+
+- Номер заказа — вводится вручную
+
+- Артикул — артикул позиции
+
+- Статус заказа — на складе / заказан / отгружено
+
+- Кол-во заказано — вводится вручную
+
+- Остаток — фактический остаток с учётом бронирований и списаний
+
+- Примечание
+
+- Дата добавления
+
+## 7.6 Связи
+
+- ← Каталог общий (картинки, артикулы, характеристики)
+
+- ← График отгрузок (данные об отгрузках)
+
+# 8. Документация
+
+Вкладка для хранения документов. Поддерживается создание папок, загрузка файлов (инструкции, прайсы, прочая документация).
+
+# 9. Техническое описание
+
+Переносится вкладка «Техническое описание» из manager без изменений.
+
+# 10. Калькуляции
+
+Будет разработана и добавлена отдельно.
+
+**Схемы архитектуры**
+
+<img src="image_dep.png" style="width:6in;height:4.72461in" />
+
+**Рис. 1. Граф зависимостей разделов платформы Manager**
+
+<img src="image_str.png" style="width:6in;height:4.29948in" />
+
+**Рис. 2. Структура вкладок платформы Manager**

docs/refactor/tz-admin.md

@@ -0,0 +1,148 @@
+# ТЗ: Модуль Администратор
+
+Связанные документы:
+
+- [План реорганизации](plan.md)
+- [Карта нового меню](menu.md)
+- [Исходное ТЗ](source-tz.md)
+
+## 1. Назначение
+
+Модуль `Администратор` объединяет административные функции Manager 2.0:
+
+- пользователи;
+- роли и права;
+- настройки;
+- справочники;
+- импорт/экспорт;
+- служебные операции.
+
+В текущей CRM аналогичная группа называется `Администрирование`.
+
+## 2. Статус
+
+Статус модуля: **реализован, требуется переименование группы меню**.
+
+В текущей CRM уже есть:
+
+- подрядчики;
+- договоры;
+- пользователи;
+- роли и права;
+- настройки;
+- округа;
+- районы;
+- журнал уведомлений;
+- импорт;
+- экспорт/импорт года;
+- удаление данных.
+
+## 3. Место в меню
+
+Целевое меню:
+
+```text
+Администратор
+├── Подрядчики
+├── Договоры
+├── Пользователи
+├── Роли и права
+├── Настройки
+├── Округа
+├── Районы
+├── Журнал уведомлений
+├── Импорт
+├── Экспорт/Импорт года
+└── Удалить данные
+```
+
+Требования:
+
+- переименовать группу `Администрирование` в `Администратор`;
+- сохранить текущие подпункты;
+- все административные подпункты, включая `Подрядчики`, показывать только внутри группы `Администратор`;
+- не оставлять специальное поведение, при котором `Подрядчики` выводятся отдельным верхним пунктом при ограниченных правах;
+- текущие маршруты не переименовывать;
+- текущие права не менять.
+
+## 4. Текущие соответствия
+
+| Пункт | Маршрут | Статус |
+|---|---|---|
+| Подрядчики | `contractors.index` | Есть |
+| Договоры | `contract.index` | Есть |
+| Пользователи | `user.index` | Есть |
+| Роли и права | `admin.roles.index` | Есть |
+| Настройки | `admin.settings.index` | Есть |
+| Округа | `admin.district.index` | Есть |
+| Районы | `admin.area.index` | Есть |
+| Журнал уведомлений | `admin.notifications.log` | Есть |
+| Импорт | `import.index` | Есть |
+| Экспорт/Импорт года | `year-data.index` | Есть |
+| Удалить данные | `clear-data.index` | Есть |
+
+## 5. Права доступа
+
+На первом этапе оставить текущие права:
+
+- `contractors.view`;
+- `contracts.view`;
+- `users.view`;
+- `admin.roles`;
+- `admin.settings.view`;
+- `districts.view`;
+- `areas.view`;
+- `admin.notification_logs.view`;
+- `import.view`;
+- `admin.year_data.view`;
+- `admin.clear_data.view`.
+
+Требования:
+
+- не вводить новые права;
+- сохранить текущие проверки прав для дочерних пунктов;
+- группа `Администратор` показывается, если доступен хотя бы один дочерний пункт.
+- пункт `Подрядчики` не показывается отдельным верхним пунктом, даже если у пользователя есть только `contractors.view`.
+
+## 6. Функциональные требования
+
+Сохранить текущую функциональность:
+
+- управление пользователями;
+- управление ролями и правами;
+- настройки системы;
+- справочники округов и районов;
+- подрядчики и договоры;
+- импорт данных;
+- экспорт/импорт года;
+- журнал уведомлений;
+- удаление данных.
+
+## 7. Что не входит в первый этап
+
+- переработка ролей и permissions;
+- изменение маршрутов;
+- изменение логики импорта;
+- изменение логики удаления данных;
+- перенос справочников;
+- изменение моделей.
+
+## 8. Этапы реализации
+
+- [ ] Переименовать группу меню `Администрирование` в `Администратор`.
+- [ ] Сохранить все текущие подпункты.
+- [ ] Перенести `Подрядчики` внутрь группы `Администратор` без отдельного верхнего пункта.
+- [ ] Проверить отображение для администратора.
+- [ ] Проверить отображение для пользователя с частичными административными правами.
+- [ ] Проверить, что пользователь только с `contractors.view` видит группу `Администратор` и пункт `Подрядчики` внутри нее.
+- [ ] Проверить маршруты всех подпунктов.
+- [ ] Проверить, что текущие права работают без изменений.
+
+## 9. Критерии приемки
+
+- В меню группа называется `Администратор`.
+- Все существующие административные пункты доступны по текущим правам.
+- Текущие маршруты сохранены.
+- Пользователь без административных прав не видит группу.
+- Пользователь с одним административным правом видит группу и доступный ему пункт.
+- `Подрядчики` всегда отображаются внутри группы `Администратор`, а не отдельным верхним пунктом.

docs/refactor/tz-calculations.md

@@ -0,0 +1,115 @@
+# ТЗ: Модуль Калькуляции
+
+Связанные документы:
+
+- [План реорганизации](plan.md)
+- [Карта нового меню](menu.md)
+- [Исходное ТЗ](source-tz.md)
+- [ТЗ: Каталог общий](tz-catalog-common.md)
+
+## 1. Назначение
+
+Модуль `Калькуляции` предназначен для связи Manager 2.0 с внешним API калькуляций.
+
+По новым вводным калькуляции не реализуются внутри CRM как самостоятельный расчетный движок. CRM должна отправлять запрос во внешний API по артикулу позиции и отображать возвращенную калькуляцию, если она есть.
+
+## 2. Статус
+
+Статус модуля: **будет разработан отдельно**.
+
+На первом этапе:
+
+- добавить пункт меню;
+- добавить страницу-заглушку;
+- подготовить кнопку `Калькуляция` в карточке позиции общего каталога.
+
+Заглушка доступна всем авторизованным пользователям.
+
+## 3. Место в меню
+
+Целевое меню:
+
+```text
+Калькуляции
+```
+
+Также в карточке позиции `Каталог общий` должна быть кнопка `Калькуляция`.
+
+## 4. Права доступа
+
+На первом этапе:
+
+- текущую систему прав не менять;
+- заглушку показывать всем авторизованным пользователям.
+
+Целевая модель прав определяется после появления платформы калькуляций.
+
+## 5. Интеграция с общим каталогом
+
+Требования:
+
+- карточка позиции общего каталога содержит кнопку `Калькуляция`;
+- кнопка выполняет запрос во внешний API калькуляций;
+- запрос выполняется по артикулу позиции;
+- если API возвращает калькуляцию, CRM должна показать ее пользователю;
+- если калькуляции нет, CRM должна показать понятное сообщение.
+- выбранный год в CRM не влияет на запрос и отображение калькуляций.
+
+Открыто:
+
+- endpoint API;
+- метод запроса;
+- параметры кроме артикула;
+- формат авторизации;
+- структура успешного ответа;
+- структура ответа, когда калькуляция не найдена;
+- требования к хранению или кешированию результата в CRM.
+
+## 6. Возможный функционал будущего модуля
+
+Предварительный список:
+
+- запрос калькуляции из позиции каталога по артикулу;
+- отображение результата, если калькуляция найдена;
+- сообщение об отсутствии калькуляции;
+- просмотр статуса калькуляции;
+- привязка результата к позиции каталога;
+- история калькуляций по позиции.
+
+Этот список предварительный и должен быть уточнен после отдельного ТЗ на платформу калькуляций.
+
+## 7. Что не входит в первый этап
+
+- реализация платформы калькуляций;
+- API-интеграция до получения подробного описания API;
+- хранение результатов калькуляций;
+- новые права;
+- синхронизация данных.
+
+## 8. Этапы реализации
+
+- [ ] Добавить пункт меню `Калькуляции`.
+- [ ] Добавить страницу-заглушку.
+- [ ] Добавить место под кнопку `Калькуляция` в карточке общего каталога.
+- [ ] Получить подробное описание внешнего API калькуляций.
+- [ ] Согласовать формат запроса по артикулу.
+- [ ] Реализовать запрос из карточки позиции.
+- [ ] Реализовать отображение возвращенной калькуляции.
+- [ ] Реализовать сообщение для случая, когда калькуляция не найдена.
+- [ ] При необходимости реализовать хранение истории калькуляций.
+
+## 9. Критерии приемки
+
+- Пункт `Калькуляции` есть в меню.
+- Заглушка открывается.
+- В карточке общего каталога предусмотрена кнопка `Калькуляция`.
+- После появления API запрос по артикулу работает для конкретной позиции каталога.
+- Если калькуляция найдена, пользователь видит результат.
+- Если калькуляция не найдена, пользователь видит понятное сообщение.
+
+## 10. Открытые вопросы
+
+- Какой endpoint, метод, авторизация и формат ответа у внешнего API?
+- Какие параметры кроме артикула нужно передавать?
+- Нужно ли хранить историю полученных калькуляций в CRM?
+- Какие роли имеют доступ к калькуляциям?

docs/refactor/tz-catalog-common.md

@@ -0,0 +1,224 @@
+# ТЗ: Модуль Каталог общий
+
+Связанные документы:
+
+- [План реорганизации](plan.md)
+- [Карта нового меню](menu.md)
+- [ТЗ: Модуль ДКР](tz-dkr.md)
+
+## 1. Назначение
+
+`Каталог общий` — центральный справочник позиций платформы Manager 2.0.
+
+Он является базовым источником данных для модулей:
+
+- `Графики`;
+- `Рекламации`;
+- `Склад наличие`;
+- `Технич. описание`;
+- `Калькуляции`.
+
+`Каталог общий` и каталог ДКР — разные сущности. Текущий каталог ДКР остается внутри модуля `ДКР`; общий каталог проектируется отдельно.
+
+## 2. Статус
+
+Статус модуля: **нужно реализовать**.
+
+В текущей CRM уже есть раздел `Каталог` ДКР:
+
+- маршрут списка: `catalog.index`;
+- маршрут карточки: `catalog.show`;
+- контроллер: `ProductController`;
+- модель: `Product`;
+- загрузка изображения/thumbnail;
+- загрузка сертификата/документа;
+- экспорт каталога.
+
+Эта реализация относится к каталогу ДКР и не становится автоматически `Каталогом общим`. Ее можно использовать как источник UI/технических паттернов, но данные и назначение общего каталога должны быть отделены.
+
+## 3. Место в меню
+
+Целевое меню:
+
+```text
+Каталог общий
+├── Позиции
+└── Карточка позиции
+```
+
+Требования:
+
+- пункт `Каталог общий` должен быть отдельным верхним пунктом меню;
+- пункт `Каталог` должен остаться внутри меню `ДКР`;
+- текущие маршруты `catalog.index` и `catalog.show` остаются маршрутами каталога ДКР;
+- маршруты `Каталог общий` должны использовать префикс `common-catalog/...`;
+- таблицы и права `Каталог общий` должны использовать техническое имя `common-catalog`;
+- выбранный год в CRM не влияет на отображение и данные общего каталога;
+- реорганизация меню выполняется сразу общей для всей платформы Manager 2.0.
+
+## 4. Права доступа
+
+На первом этапе для заглушки используем доступ для всех авторизованных пользователей.
+
+| Действие | Permission |
+|---|---|
+| Просмотр заглушки | Любой авторизованный пользователь |
+| Просмотр общего каталога после реализации | `common-catalog.view` |
+| Создание/редактирование/удаление | Права с префиксом `common-catalog.*` |
+| Импорт/экспорт | Права с префиксом `common-catalog.*` |
+
+Требования:
+
+- не переиспользовать `catalog.view` автоматически, потому что это право относится к каталогу ДКР;
+- новые права общего каталога использовать с техническим именем `common-catalog`;
+- заглушку `Каталог общий` показывать всем авторизованным пользователям.
+
+## 5. Основные сущности
+
+Базовая сущность: позиция каталога.
+
+Возможная техническая основа для анализа:
+
+- модель `Product`;
+- карточка позиции через `catalog.show`;
+- связи с МАФ/SKU через текущую модель данных.
+
+Эти сущности относятся к каталогу ДКР и не должны смешиваться с общим каталогом без отдельной миграции или синхронизации.
+
+Целевая роль позиции:
+
+- единый справочник номенклатуры;
+- источник изображения, артикула, наименования, характеристик и единицы измерения для склада наличия;
+- источник данных для графиков и рекламаций;
+- точка перехода в техническое описание;
+- точка перехода в калькуляцию.
+
+## 6. Список позиций
+
+Список позиций должен поддерживать базовую функциональность справочника и быть подготовлен к расширению. Текущий каталог ДКР можно использовать как референс интерфейса, но не как источник данных общего каталога.
+
+Функционал:
+
+- просмотр списка позиций;
+- поиск;
+- фильтры;
+- пагинация;
+- переход в карточку позиции по двойному клику или текущему механизму таблицы;
+- экспорт;
+- импорт, если он будет предусмотрен для общего каталога.
+
+Колонки:
+
+- взять текущие колонки каталога ДКР как ориентир для анализа;
+- дополнительно сверить с шаблоном калькулятора;
+- недостающие поля вынести в отдельный список доработок после анализа шаблона.
+
+## 7. Карточка позиции
+
+Карточка позиции должна стать центральной карточкой товара/МАФ.
+
+Функционал карточки:
+
+- просмотр и редактирование полей позиции общего каталога;
+- загрузка фото МАФ/позиции;
+- хранение сопутствующих документов;
+- блок/выгрузка технического описания, если модуль техописаний будет поглощен каталогом;
+- переход в `Калькуляции`;
+- отображение связанных МАФ/SKU, если это потребуется для новой логики;
+- сохранение привычных действий карточки каталога ДКР только как UI-паттерна, без смешивания данных.
+
+Текущие возможности каталога ДКР, которые можно использовать как паттерн:
+
+- `catalog.upload-thumbnail` — использовать как основу загрузки фото;
+- `catalog.upload-certificate` — использовать как основу загрузки документов, но расширить модель до нескольких произвольных документов, если текущая реализация ограничена сертификатом.
+
+## 8. Фото и документы
+
+Фото:
+
+- хранится у позиции общего каталога;
+- используется в `Склад наличие`;
+- используется в карточке позиции;
+- должно быть доступно для отображения в таблицах, где нужна картинка позиции.
+
+Документы:
+
+- у позиции должен быть блок `Документы`;
+- документы могут быть разных типов: сертификаты, инструкции, паспорта, прочие файлы;
+- хранение документов выполняется через текущий файловый механизм проекта;
+- загрузка, просмотр и удаление должны учитывать будущие права общего каталога;
+- если текущая реализация поддерживает только один сертификат, нужна доработка интерфейса до набора файлов без замены базового механизма хранения.
+
+## 9. Импорт и экспорт
+
+Требования:
+
+- спроектировать импорт и экспорт общего каталога;
+- использовать текущий импорт/экспорт каталога ДКР как технический референс, если это ускорит реализацию;
+- привести состав колонок к шаблону калькулятора после анализа шаблона;
+- при импорте обновлять существующие позиции по стабильному ключу;
+- ошибки импорта должны быть понятны пользователю.
+
+Открытая доработка:
+
+- отдельно сверить шаблон калькулятора и текущие поля каталога ДКР как референс.
+
+## 10. Связи с другими модулями
+
+| Модуль | Связь | Требование |
+|---|---|---|
+| ДКР | Имеет собственный каталог | Не смешивать каталог ДКР с общим каталогом. |
+| Склад наличие | Использует картинку, артикул, наименование, характеристики, ед. изм. | Склад должен брать справочные поля из общего каталога. |
+| Графики | Используют данные по позициям | При разработке графиков опираться на общий каталог. |
+| Рекламации | Используют данные по позициям | Сохранить/добавить связь рекламаций с позициями общего каталога. |
+| Технич. описание | Вероятно является частью общего каталога | Использовать готовый Laravel-модуль как источник экспорта/формата. |
+| Калькуляции | Запрашиваются из карточки позиции через внешний API | Запрос по артикулу, отображение возвращенной калькуляции при наличии. |
+
+## 11. Что не входит в первый этап
+
+В первый этап общего каталога не входит:
+
+- переименование текущих маршрутов `catalog.*`;
+- полная переработка модели `Product`;
+- внедрение новых прав доступа;
+- разработка модуля `Склад наличие`;
+- отдельный модуль `Технич. описание`, если он будет поглощен каталогом;
+- разработка интеграции с калькуляциями до получения подробного описания API;
+- изменение бизнес-логики ДКР.
+
+## 12. Этапы реализации
+
+- [ ] Проверить текущие маршруты `catalog.*`.
+- [ ] Зафиксировать, что текущие маршруты `catalog.*` относятся к каталогу ДКР.
+- [ ] Использовать префикс маршрутов `common-catalog/...` для `Каталог общий`.
+- [ ] Использовать техническое имя `common-catalog` для таблиц и прав общего каталога.
+- [ ] Добавить верхний пункт `Каталог общий`.
+- [ ] Добавить страницу-заглушку `Каталог общий`.
+- [ ] Спроектировать карточку позиции общего каталога.
+- [ ] Проверить загрузку фото позиции.
+- [ ] Спроектировать загрузку документов позиции через текущий файловый механизм.
+- [ ] Составить список текущих полей каталога ДКР как источник для анализа.
+- [ ] Сверить поля с шаблоном калькулятора.
+- [ ] Описать недостающие поля для доработки.
+- [ ] Подготовить расширение блока документов до набора файлов, если нужно.
+- [ ] Определить, включается ли `Технич. описание` внутрь карточки общего каталога.
+- [ ] Добавить в карточку место под API-запрос `Калькуляции`.
+- [ ] Проверить связи с модулями, которым нужен общий каталог.
+- [ ] Проверить, что заглушка `Каталог общий` видна всем авторизованным пользователям.
+
+## 13. Критерии приемки
+
+- В верхнем меню есть пункт `Каталог общий`.
+- В меню `ДКР` остается пункт `Каталог`.
+- Текущие маршруты `catalog.index` и `catalog.show` сохранены как маршруты каталога ДКР.
+- Заглушка `Каталог общий` доступна всем авторизованным пользователям.
+- После реализации общий каталог не смешивает данные с каталогом ДКР без отдельной миграции/синхронизации.
+- Карточка позиции общего каталога поддерживает фото, документы, техописание/выгрузку и калькуляцию по артикулу.
+- ДКР продолжает использовать свой каталог без поломки существующих связей.
+- Реорганизация меню выполнена как часть общей структуры Manager 2.0.
+
+## 14. Открытые вопросы
+
+- Какие точные колонки должны быть добавлены по шаблону калькулятора?
+- Как именно включить готовый Laravel-модуль техописаний в общий каталог и какие экспорты оттуда переносить?
+- Какой точный формат API калькуляций: endpoint, параметры, авторизация, структура ответа?

docs/refactor/tz-dkr.md

@@ -0,0 +1,237 @@
+# ТЗ: Модуль ДКР
+
+Связанные документы:
+
+- [План реорганизации](plan.md)
+- [Карта нового меню](menu.md)
+
+## 1. Назначение
+
+Модуль `ДКР` — самостоятельный рабочий контур текущей CRM для управления площадками, МАФ, каталогом ДКР, отчетами, ответственными и заказами МАФ.
+
+В рамках Manager 2.0 модуль не проектируется заново. Его нужно сохранить как автономный блок и перегруппировать в новом меню. Каталог ДКР остается внутри ДКР; `Каталог общий` является отдельной сущностью.
+
+## 2. Статус
+
+Статус модуля: **реализован**.
+
+Основная задача по ДКР на первом этапе — реорганизация навигации без изменения бизнес-логики.
+
+## 3. Состав модуля
+
+Целевое меню ДКР:
+
+```text
+ДКР
+├── Площадки
+├── МАФ
+├── Каталог
+├── Отчеты
+├── Ответственные
+└── Заказы МАФ
+```
+
+Текущие соответствия:
+
+| Раздел ДКР | Текущий маршрут | Текущий контроллер | Статус |
+|---|---|---|---|
+| Площадки | `order.index` | `OrderController` | Есть |
+| МАФ | `product_sku.index` | `ProductSKUController` | Есть |
+| Каталог | `catalog.index` | `ProductController` | Есть |
+| Отчеты | `reports.index` | `ReportController` | Есть |
+| Ответственные | `responsible.index` | `ResponsibleController` | Есть |
+| Заказы МАФ | `maf_order.index` | `MafOrderController` | Есть |
+
+## 4. Каталог ДКР
+
+Текущий пункт `Каталог` должен остаться внутри ДКР.
+
+Решение:
+
+- `catalog.index` остается маршрутом каталога ДКР.
+- В меню `ДКР` пункт `Каталог` показывается пользователям с текущим доступом к каталогу.
+- Каталог ДКР и `Каталог общий` не смешиваются на уровне данных и назначения.
+- Связи ДКР с товарами/позициями продолжают работать через текущий каталог ДКР.
+
+## 5. Требования к меню
+
+- Добавить верхний пункт меню `ДКР`.
+- Внутри `ДКР` разместить существующие пункты:
+  - `Площадки`;
+  - `МАФ`;
+  - `Каталог`;
+  - `Отчеты`;
+  - `Ответственные`;
+  - `Заказы МАФ`.
+- Сохранить текущие permissions для каждого пункта.
+- Не менять URL существующих рабочих страниц.
+- Активное состояние меню должно корректно подсвечивать пункт `ДКР` и выбранный подраздел.
+- Если у пользователя нет доступа ни к одному подразделу ДКР, пункт `ДКР` не показывать.
+
+## 6. Площадки
+
+Текущий раздел: `Площадки`.
+
+Функционал должен сохраниться:
+
+- список площадок;
+- карточка площадки;
+- создание/редактирование/удаление при наличии прав;
+- загрузка фото и документов;
+- генерация документов;
+- связь с МАФ;
+- связь с рекламациями;
+- связь с графиком монтажей;
+- поиск, фильтры, пагинация и экспорт, если доступны в текущей реализации.
+
+Изменения на этапе реорганизации:
+
+- только перенос пункта меню внутрь `ДКР`;
+- бизнес-логику и структуру данных не менять.
+
+## 7. МАФ
+
+Текущий раздел: `МАФ`.
+
+Функционал должен сохраниться:
+
+- список МАФ;
+- карточка МАФ;
+- импорт/экспорт МАФ;
+- загрузка паспорта;
+- связь с площадкой;
+- связь с позицией каталога ДКР;
+- inline-обновления, если доступны в текущей реализации;
+- реестр на оплату, если доступен в текущей реализации.
+
+Изменения на этапе реорганизации:
+
+- пункт меню переносится внутрь `ДКР`;
+- связи с каталогом должны продолжить вести в каталог ДКР.
+
+## 8. Отчеты
+
+Текущий раздел: `Отчеты`.
+
+Функционал должен сохраниться:
+
+- текущие вкладки отчетов;
+- отчеты по монтажам;
+- отчеты по выполненным работам;
+- общие отчеты;
+- отчеты по рекламациям, если они присутствуют в текущем разделе.
+
+Изменения на этапе реорганизации:
+
+- пункт меню переносится внутрь `ДКР`;
+- состав отчетов не менять без отдельного ТЗ.
+
+## 9. Ответственные
+
+Текущий раздел: `Ответственные`.
+
+Функционал должен сохраниться:
+
+- список ответственных;
+- добавление ответственного;
+- редактирование ответственного;
+- удаление при наличии прав;
+- поиск и фильтры, если доступны в текущей реализации.
+
+Изменения на этапе реорганизации:
+
+- пункт меню переносится внутрь `ДКР`;
+- бизнес-логику не менять.
+
+## 10. Заказы МАФ
+
+Текущий раздел: `Заказы МАФ`.
+
+Функционал должен сохраниться:
+
+- список заказов МАФ;
+- создание заказа;
+- редактирование заказа;
+- удаление при наличии прав;
+- отметка заказа как `На складе`;
+- массовая отметка заказа как `На складе`, если доступна в текущей реализации;
+- связь заказа с МАФ/позицией.
+
+Изменения на этапе реорганизации:
+
+- пункт меню переносится внутрь `ДКР`;
+- бизнес-логику не менять.
+
+## 11. Внешние связи ДКР
+
+ДКР остается самостоятельным модулем, но его данные используются другими разделами Manager 2.0.
+
+| Внешний раздел | Связь с ДКР | Требование |
+|---|---|---|
+| Рекламации | Используют площадки ДКР при создании рекламации типа `ДКР` | Сохранить текущую связь. |
+| График монтажей | Использует площадки ДКР | Сохранить текущую связь при переносе графика в группу `Графики`. |
+| Каталог ДКР | Используется МАФ и связанными позициями ДКР | Сохранить текущий каталог внутри ДКР. |
+| Каталог общий | Отдельный общий справочник платформы | Не смешивать с каталогом ДКР без отдельной миграции/синхронизации. |
+| Склад наличие | Будет использовать МАФ/позиции из общего каталога | Прямую зависимость склада от каталога ДКР не делать. |
+
+## 12. Права доступа
+
+На первом этапе используются текущие права:
+
+| Раздел | Permission |
+|---|---|
+| Площадки | `orders.view` |
+| МАФ | `maf.view` |
+| Каталог | `catalog.view` |
+| Отчеты | `reports.view` |
+| Ответственные | `responsibles.view` |
+| Заказы МАФ | `maf_orders.view` |
+
+Требования:
+
+- текущая логика `hasPermission(...)` должна сохраниться;
+- новые права для ДКР на этапе перегруппировки не вводить без необходимости;
+- верхний пункт `ДКР` отображать, если доступен хотя бы один дочерний пункт.
+
+## 13. Что не входит в этап ДКР
+
+В рамках этого ТЗ не выполняется:
+
+- переписывание моделей ДКР;
+- изменение структуры таблиц ДКР;
+- изменение бизнес-логики площадок, МАФ, отчетов, ответственных и заказов МАФ;
+- перенос текущих URL на новые адреса;
+- перенос каталога ДКР в `Каталог общий`;
+- разработка нового общего каталога;
+- разработка склада наличия;
+- разработка графика заказов и графика доставок.
+
+## 14. Этапы реализации
+
+- [ ] Проверить текущие маршруты и permissions разделов ДКР.
+- [ ] Добавить верхний пункт меню `ДКР`.
+- [ ] Перенести пункты `Площадки`, `МАФ`, `Каталог`, `Отчеты`, `Ответственные`, `Заказы МАФ` внутрь `ДКР`.
+- [ ] Проверить, что `catalog.index` доступен как каталог ДКР.
+- [ ] Проверить активное состояние меню для каждого подраздела ДКР.
+- [ ] Проверить отображение меню для ролей с разным набором прав.
+- [ ] Проверить, что существующие страницы ДКР открываются по прежним маршрутам.
+- [ ] Проверить связи площадок с рекламациями.
+- [ ] Проверить связи площадок с графиком монтажей.
+
+## 15. Критерии приемки
+
+- В верхнем меню есть группа `ДКР`.
+- В группе `ДКР` отображаются только доступные пользователю подразделы.
+- В группе `ДКР` есть пункт `Каталог` для пользователей с текущим доступом к каталогу.
+- Текущий каталог доступен как каталог ДКР.
+- Все существующие страницы ДКР открываются без 404/403 при корректных правах.
+- Бизнес-логика ДКР после реорганизации меню не изменилась.
+- Рекламации продолжают работать с площадками ДКР.
+- График монтажей продолжает работать с площадками ДКР.
+- Тесты проекта проходят.
+
+## 16. Принятые решения
+
+- Текущие маршруты ДКР оставляем без переименования.
+- На первом этапе используем текущие права дочерних разделов без добавления отдельного права `dkr.view`.
+- Каталог ДКР и `Каталог общий` — разные сущности.

docs/refactor/tz-documents.md

@@ -0,0 +1,206 @@
+# ТЗ: Модуль Документация
+
+Связанные документы:
+
+- [План реорганизации](plan.md)
+- [Карта нового меню](menu.md)
+- [Исходное ТЗ](source-tz.md)
+
+## 1. Назначение
+
+Модуль `Документация` предназначен для централизованного хранения общих документов платформы Manager 2.0.
+
+Типовые документы:
+
+- инструкции;
+- прайсы;
+- регламенты;
+- шаблоны;
+- технические файлы;
+- прочая документация.
+
+## 2. Статус
+
+Статус модуля: **нужно реализовать**.
+
+Модуль должен быть доступен из верхнего меню `Документация`.
+
+## 3. Место в меню
+
+Целевое меню:
+
+```text
+Документация
+```
+
+Требования:
+
+- добавить верхний пункт `Документация`;
+- пункт меню доступен всем авторизованным пользователям;
+- выбранный год в CRM не влияет на отображение и документы модуля;
+- внутри раздела отображается дерево папок и список документов выбранной папки.
+
+## 4. Структура папок
+
+Папки должны отображаться деревом.
+
+Требования:
+
+- поддерживается вложенность папок;
+- корневые папки может создавать только администратор;
+- подпапки может создавать пользователь, у которого есть право записи на родительскую папку;
+- при создании подпапки права доступа наследуются от родительской папки;
+- права подпапки можно изменить отдельно, если у пользователя есть право управления/записи для этой папки;
+- папку можно переименовать при наличии права записи;
+- папку можно удалить при наличии права записи;
+- удаление папки должно учитывать вложенные папки, документы и версии документов.
+
+## 5. Документы
+
+Документ хранится внутри папки.
+
+Функционал:
+
+- загрузка документа;
+- скачивание документа;
+- переименование документа;
+- удаление документа;
+- загрузка новой версии документа;
+- просмотр списка версий;
+- скачивание любой доступной версии;
+- полное удаление отдельной версии;
+- полное удаление всех версий при удалении документа;
+- отображение даты загрузки;
+- отображение автора загрузки;
+- поиск по названию документа.
+
+Пользователь может создавать документы в папке, если у него есть право записи на эту папку.
+
+## 6. Версионность
+
+Для документов должна быть предусмотрена версионность.
+
+Требования:
+
+- первая загрузка файла создает версию `1`;
+- загрузка новой версии увеличивает номер версии;
+- у документа есть текущая активная версия;
+- пользователь может скачать текущую версию;
+- пользователь может открыть список предыдущих версий;
+- пользователь с правом записи может загрузить новую версию;
+- пользователь с правом записи может полностью удалить отдельную версию;
+- при полном удалении версии удаляются и метаданные версии, и физический файл;
+- если удаляется текущая версия, система должна назначить текущей последнюю оставшуюся версию;
+- если удалены все версии документа, документ считается удаленным;
+- при удалении документа удаляются все его версии.
+
+## 7. Права доступа
+
+Читать общедоступную документацию могут все авторизованные пользователи.
+
+Управление доступом задается на уровне папки. Документы внутри папки наследуют права папки, если для документа не задано отдельное правило.
+
+### 7.1 Администратор
+
+Администратор:
+
+- создает корневые папки;
+- видит все папки и документы;
+- может назначать права чтения и записи;
+- может создавать, редактировать и удалять папки и документы;
+- может удалять версии документов.
+
+### 7.2 Права на папку
+
+На папку назначаются права:
+
+- чтение;
+- запись.
+
+Право чтения дает возможность:
+
+- видеть папку в дереве;
+- видеть документы внутри папки;
+- скачивать доступные документы и версии.
+
+Право записи дает возможность:
+
+- создавать подпапки;
+- создавать документы;
+- загружать новые версии документов;
+- переименовывать папки и документы;
+- удалять папки, документы и версии;
+- изменять права дочерних объектов, если это разрешено общей моделью управления.
+
+### 7.3 Субъекты доступа
+
+Права чтения и записи могут назначаться:
+
+| Субъект | Описание |
+|---|---|
+| Все | Все авторизованные пользователи. |
+| Роль | Все пользователи выбранной роли. |
+| Пользователь | Конкретный пользователь. |
+
+Пример: папку могут читать роль `Администратор` и пользователь `Иванов`.
+
+### 7.4 Наследование
+
+Требования:
+
+- подпапка при создании наследует права родительской папки;
+- документ при создании наследует права папки;
+- если права на дочерний объект не переопределены, используются права родителя;
+- если права переопределены, дочерний объект использует собственные настройки;
+- пользователь с правом записи на папку может создавать подпапки и документы в этой папке.
+
+## 8. Permission-модель
+
+Целевые системные права:
+
+- `documents.view` — вход в раздел документации;
+- `documents.update` — административное управление документацией, включая создание корневых папок и настройку прав.
+
+Администратор имеет все права по умолчанию.
+
+Права чтения/записи на конкретные папки и документы хранятся отдельно от системных permissions.
+
+## 9. Хранение
+
+Требования:
+
+- использовать текущий файловый механизм проекта;
+- физические файлы хранить в стандартном storage проекта;
+- хранить метаданные папок, документов, версий и правил доступа в БД;
+- для версии хранить номер версии, имя файла, путь, размер, автора загрузки и дату загрузки;
+- при полном удалении версии удалять физический файл и запись версии;
+- при полном удалении документа удалять все версии и физические файлы.
+
+## 10. Поиск и отображение
+
+Функционал:
+
+- дерево папок;
+- список документов выбранной папки;
+- поиск по названию документа;
+- отображение текущей версии;
+- отображение даты последнего обновления;
+- отображение автора последнего обновления;
+- отображение доступных действий согласно правам пользователя.
+
+## 11. Критерии приемки
+
+- Пункт `Документация` есть в верхнем меню.
+- Раздел доступен всем авторизованным пользователям.
+- Папки отображаются деревом.
+- Корневые папки может создавать только администратор.
+- Пользователь с правом записи на папку может создавать в ней подпапки и документы.
+- Подпапки наследуют права родительской папки.
+- Документы наследуют права папки.
+- На папку можно назначить права чтения и записи для всех, ролей и отдельных пользователей.
+- Документы поддерживают версии.
+- Можно загрузить новую версию документа.
+- Можно скачать предыдущую версию документа.
+- Можно полностью удалить отдельную версию документа.
+- При удалении документа удаляются все его версии.
+- Файлы хранятся в текущем файловом механизме проекта.

docs/refactor/tz-reclamations.md

@@ -0,0 +1,198 @@
+# ТЗ: Модуль Рекламации
+
+Связанные документы:
+
+- [План реорганизации](plan.md)
+- [Карта нового меню](menu.md)
+- [Исходное ТЗ](source-tz.md)
+- [ТЗ: Модуль ДКР](tz-dkr.md)
+- [ТЗ: Графики](tz-schedules.md)
+- [ТЗ: Запчасти](tz-spare-parts.md)
+
+## 1. Назначение
+
+Модуль `Рекламации` предназначен для ведения клиентских рекламаций Manager 2.0.
+
+В новом формате раздел должен сохранить текущую рабочую логику рекламаций и получить структуру:
+
+```text
+Рекламации
+├── Все
+└── ДКР
+```
+
+Рекламации имеют два типа:
+
+- `ДКР` — рекламации по программе ДКР;
+- `Прочее` — остальные рекламации.
+
+## 2. Статус
+
+Статус модуля: **частично реализован**.
+
+В текущей CRM уже есть:
+
+- список рекламаций;
+- карточка рекламации;
+- маршрут списка: `reclamations.index`;
+- маршрут карточки: `reclamations.show`;
+- контроллер: `ReclamationController`;
+- модель: `Reclamation`;
+- связь с площадкой/заказом;
+- документы и фото до/после;
+- генерация пакетов документов;
+- связь с запчастями и резервами;
+- создание записи в графике монтажей из рекламации.
+
+На первом этапе бизнес-логика не меняется, выполняется только реорганизация меню и подготовка разделения `Все` / `ДКР`.
+
+## 3. Место в меню
+
+Целевое меню:
+
+```text
+Рекламации
+├── Все
+└── ДКР
+```
+
+Требования:
+
+- добавить верхний пункт меню `Рекламации`;
+- внутри разместить пункты `Все` и `ДКР`;
+- текущий маршрут `reclamations.index` оставить без переименования;
+- текущий маршрут `reclamations.show` оставить без переименования;
+- для пункта `ДКР` использовать фильтр текущего списка;
+- реорганизация меню выполняется в общем этапе Manager 2.0.
+
+## 4. Права доступа
+
+На первом этапе оставляем текущие права.
+
+| Действие | Permission |
+|---|---|
+| Просмотр рекламаций | `reclamations.view` |
+| Создание/редактирование | Использовать текущие права рекламаций |
+| Экспорт | Использовать текущие права рекламаций |
+
+Требования:
+
+- не вводить новую систему прав на первом этапе;
+- пользователи с текущим доступом к рекламациям должны сохранить доступ;
+- верхний пункт `Рекламации` показывать, если доступен хотя бы один дочерний пункт.
+
+## 5. Подраздел `Все`
+
+Назначение:
+
+- общий список всех рекламаций независимо от типа.
+
+Функционал:
+
+- текущий список рекламаций;
+- поиск и фильтры;
+- экспорт;
+- переход в карточку;
+- отображение статусов;
+- отображение рекламаций по ДКР и прочих рекламаций.
+
+Текущая основа:
+
+- `reclamations.index`.
+
+## 6. Подраздел `ДКР`
+
+Назначение:
+
+- список рекламаций типа `ДКР`;
+- работа с рекламациями, созданными по площадкам ДКР.
+
+Функционал:
+
+- отображение только рекламаций типа `ДКР`;
+- реализация через текущий список рекламаций с предустановленным фильтром по источнику;
+- создание рекламации с привязкой к площадке ДКР;
+- сохранение текущей карточки рекламации;
+- связь с графиком монтажей;
+- формирование запросов на запчасти.
+
+Принятое решение:
+
+- отдельный URL для списка `ДКР` не нужен;
+- используется текущий список с фильтром по источнику рекламации;
+- для определения источника рекламации добавляется отдельное поле;
+- при создании рекламации из площадки источник устанавливается `ДКР`;
+- при создании рекламации не из площадки источник устанавливается `Прочее`.
+
+## 7. Карточка рекламации
+
+Карточка должна сохранить текущий функционал:
+
+- основные поля рекламации;
+- связь с площадкой/заказом;
+- данные по МАФ/позициям;
+- документы;
+- фото до и после;
+- акты;
+- чат, если используется в текущей реализации;
+- блок запчастей;
+- активные резервы и дефициты;
+- действия по резервам;
+- генерация документов;
+- перенос в график монтажей.
+
+Изменения на первом этапе:
+
+- не менять структуру карточки;
+- добавить/использовать отображение источника рекламации `ДКР` / `Прочее`;
+- сохранить текущие маршруты и формы.
+
+## 8. Связи
+
+| Модуль | Связь | Требование |
+|---|---|---|
+| ДКР / Площадки | Используется при создании рекламации типа `ДКР` | Сохранить текущую связь. |
+| Каталог общий | Данные по позициям | Использовать общий каталог как источник номенклатуры. |
+| График заказов | Используется при создании рекламации | Реализовать после появления графика заказов. |
+| График монтажей | Рекламация может попасть в монтажный график | Сохранить текущую связь. |
+| Запчасти | Из рекламации формируется запрос на запчасть | Сохранить текущую связь и резервы. |
+
+## 9. Что не входит в первый этап
+
+- изменение текущих маршрутов `reclamations.*`;
+- переработка модели `Reclamation`;
+- изменение логики резервов запчастей;
+- изменение генерации документов;
+- разработка графика заказов;
+- внедрение новых прав доступа.
+
+## 10. Этапы реализации
+
+- [ ] Проверить текущие маршруты `reclamations.*`.
+- [ ] Проверить текущие permissions рекламаций.
+- [ ] Добавить верхнюю группу меню `Рекламации`.
+- [ ] Добавить пункт `Все`, ведущий на текущий список.
+- [ ] Добавить пункт `ДКР` как отдельный URL или фильтр после решения.
+- [ ] Проверить открытие карточки рекламации.
+- [ ] Проверить создание рекламации по площадке ДКР.
+- [ ] Проверить связь с графиком монтажей.
+- [ ] Проверить блок запчастей и резервов.
+- [ ] Проверить экспорт рекламаций.
+
+## 11. Критерии приемки
+
+- В меню есть группа `Рекламации`.
+- Внутри есть пункты `Все` и `ДКР`.
+- `Все` открывает текущий общий список рекламаций.
+- Текущие маршруты рекламаций сохранены.
+- Пользователи с прежним доступом сохраняют доступ.
+- Рекламации типа `ДКР` связаны с площадками ДКР.
+- При создании рекламации из площадки источник автоматически устанавливается `ДКР`.
+- При создании рекламации не из площадки источник устанавливается `Прочее`.
+- Пункт `Рекламации -> ДКР` открывает текущий список с фильтром по источнику `ДКР`.
+- Из рекламации по-прежнему можно работать с запчастями.
+- Перенос рекламации в график монтажей работает как раньше.
+
+## 12. Открытые вопросы
+
+- Как будет использоваться связь с будущим `График заказов` при создании рекламации?

docs/refactor/tz-schedules.md

@@ -0,0 +1,285 @@
+# ТЗ: Модуль Графики
+
+Связанные документы:
+
+- [План реорганизации](plan.md)
+- [Карта нового меню](menu.md)
+- [ТЗ: Каталог общий](tz-catalog-common.md)
+- [ТЗ: Модуль ДКР](tz-dkr.md)
+
+## 1. Назначение
+
+Модуль `Графики` объединяет календарные и производственные представления Manager 2.0:
+
+- график заказов на производстве;
+- график доставок;
+- график монтажей.
+
+Цель модуля — дать единый раздел для планирования производства, доставки и монтажных работ, сохранив текущую рабочую реализацию графика монтажей.
+
+## 2. Статус
+
+Статус модуля: **частично реализован**.
+
+В текущей CRM реализован:
+
+- `График монтажей`;
+- маршрут: `schedule.index`;
+- контроллер: `ScheduleController`;
+- модель: `Schedule`;
+- создание записей из площадок/заказов;
+- создание записей из рекламаций;
+- экспорт графика;
+- недельное/месячное представление, если доступно в текущей реализации.
+
+Нужно реализовать:
+
+- `График заказов`;
+- `График доставок`;
+- новую верхнюю группу меню `Графики`;
+- связи между графиками.
+
+## 3. Место в меню
+
+Целевое меню:
+
+```text
+Графики
+├── График заказов
+├── График доставок
+└── График монтажей
+```
+
+Требования:
+
+- добавить верхний пункт меню `Графики`;
+- перенести текущий пункт `График монтажей` внутрь `Графики`;
+- текущий маршрут `schedule.index` оставить без переименования;
+- для `График заказов` и `График доставок` на первом этапе добавить страницы-заглушки `В разработке`;
+- выбранный год в CRM не влияет на новые модули `График заказов` и `График доставок`;
+- реорганизация меню выполняется сразу общей для всей платформы Manager 2.0.
+
+## 4. Права доступа
+
+На первом этапе оставляем текущие права.
+
+| Раздел | Permission |
+|---|---|
+| График монтажей | `schedule.view` |
+| График заказов | Заглушка доступна всем авторизованным пользователям |
+| График доставок | Заглушка доступна всем авторизованным пользователям |
+
+Требования:
+
+- не переименовывать текущие права;
+- не вводить новую систему прав на первом этапе;
+- верхний пункт `Графики` показывать, если пользователю доступен хотя бы один дочерний пункт.
+
+## 5. График заказов
+
+Статус: **нужно реализовать**.
+
+Назначение:
+
+- отображать график заказов на производстве;
+- быть основным источником данных для доставок;
+- быть связанным с монтажами;
+- использовать позиции из `Каталог общий`.
+
+Требования по ТЗ Manager 2.0:
+
+- таблица с графиком заказов на производстве;
+- перенос функционала `график отгрузок` из старого manager с адаптацией под текущие реалии;
+- загрузка данных через 1С;
+- связь с `Каталог общий`;
+- связь с `График монтажей`.
+
+Предварительный функционал:
+
+- список заказов/позиций в производственном графике;
+- дата/период производства;
+- адрес/объект, если приходит из источника данных;
+- позиции заказа из общего каталога;
+- статусы или этапы производства, если они есть в источнике;
+- фильтры по дате, заказу, позиции, статусу;
+- импорт/обновление данных из 1С;
+- история последней загрузки;
+- обработка ошибок загрузки.
+
+Открытые вопросы:
+
+- какой источник данных 1С и формат обмена;
+- какие поля приходят из 1С;
+- нужен ли ручной ввод/редактирование или график полностью загружается;
+- что именно в текущем/старом manager называется `график отгрузок`;
+- какие статусы производства должны отображаться;
+- как связывать строку графика с позицией `Каталог общий`.
+
+## 6. График доставок
+
+Статус: **нужно реализовать**.
+
+Назначение:
+
+- показывать недельный список доставок;
+- позволять вручную планировать занятость водителей;
+- брать адреса автоматически из `График заказов`.
+
+Требования по ТЗ Manager 2.0:
+
+- отображение в виде недельного списка;
+- адреса добавляются автоматически из `График заказов`;
+- вручную указывается занятость водителей: какой заказ и когда везут;
+- добавление через модальное окно;
+- возможная связь с вкладкой `Отгрузки` требует уточнения.
+
+Предварительный функционал:
+
+- недельный календарь доставок;
+- список заказов/адресов, доступных для доставки;
+- добавление доставки через модальное окно;
+- выбор даты и времени доставки;
+- выбор водителя или ответственного за доставку;
+- выбор заказа/адреса из графика заказов;
+- комментарий;
+- изменение и удаление записи доставки при наличии прав;
+- фильтры по неделе, водителю, заказу;
+- визуальное отображение занятости водителей.
+
+Открытые вопросы:
+
+- где хранится список водителей;
+- нужна ли отдельная сущность `Водитель`;
+- какие статусы есть у доставки;
+- нужна ли связь с отдельным разделом `Отгрузки`;
+- требуется ли печатная форма или экспорт недельного списка;
+- как обрабатывать несколько доставок по одному заказу.
+
+## 7. График монтажей
+
+Статус: **есть, переносится в новую группу меню**.
+
+Текущая основа:
+
+- маршрут: `schedule.index`;
+- контроллер: `ScheduleController`;
+- создание записи из заказа/площадки;
+- создание записи из рекламации;
+- обновление записи;
+- удаление записи;
+- экспорт;
+- недельное/месячное представление.
+
+Требования:
+
+- сохранить текущую бизнес-логику;
+- сохранить текущий маршрут `schedule.index`;
+- перенести пункт меню внутрь `Графики`;
+- сохранить текущие права `schedule.view` и связанные права обновления/экспорта;
+- сохранить связь с площадками ДКР;
+- сохранить связь с рекламациями;
+- добавить/подготовить связь с `График заказов`, когда он будет реализован.
+
+Что не менять на первом этапе:
+
+- структуру таблиц графика монтажей;
+- существующие маршруты `schedule.*`;
+- текущие правила создания записей из заказов и рекламаций;
+- текущий UI графика, кроме положения в меню.
+
+## 8. Связи между графиками
+
+Целевая логика связей:
+
+| Источник | Получатель | Связь |
+|---|---|---|
+| Каталог общий | График заказов | Позиции заказа и справочные данные по номенклатуре. |
+| График заказов | График доставок | Адреса и заказы для планирования доставки. |
+| График заказов | График монтажей | Связь производственного графика с монтажом. |
+| ДКР / Площадки | График монтажей | Площадки для монтажных работ. |
+| Рекламации | График монтажей | Работы по рекламациям. |
+
+Требования:
+
+- связи не должны ломать автономность ДКР;
+- текущий график монтажей должен работать до реализации графика заказов;
+- новые графики должны опираться на `Каталог общий`, а не на каталог внутри ДКР.
+
+## 9. Данные и модели
+
+Для `График монтажей` использовать текущие модели и таблицы.
+
+Для `График заказов` и `График доставок` модели проектируются отдельно после уточнения данных.
+
+Предварительно потребуются сущности:
+
+- производственная запись графика заказов;
+- строка/позиция производственного заказа;
+- запись доставки;
+- водитель или ответственный доставки;
+- журнал загрузок из 1С.
+
+Открыто:
+
+- точные имена таблиц и моделей;
+- структура полей;
+- необходимость истории изменений;
+- связь с существующими `Order`, `Product`, `ProductSKU`.
+
+## 10. Первый этап реализации
+
+В первый этап модуля `Графики` входит:
+
+- общая реорганизация меню;
+- перенос `График монтажей` внутрь группы `Графики`;
+- сохранение текущего маршрута `schedule.index`;
+- добавление заглушки `График заказов`;
+- добавление заглушки `График доставок`;
+- сохранение текущих прав;
+- проверка доступности текущего графика монтажей.
+
+В первый этап не входит:
+
+- разработка обмена с 1С;
+- проектирование БД графика заказов;
+- проектирование БД графика доставок;
+- реализация недельного календаря доставок;
+- изменение текущей логики графика монтажей.
+
+## 11. Этапы реализации
+
+- [ ] Проверить текущие маршруты `schedule.*`.
+- [ ] Проверить текущие permissions графика монтажей.
+- [ ] Добавить верхнюю группу меню `Графики`.
+- [ ] Перенести текущий пункт `График монтажей` внутрь `Графики`.
+- [ ] Оставить маршрут `schedule.index` без переименования.
+- [ ] Добавить страницу-заглушку `График заказов`.
+- [ ] Добавить страницу-заглушку `График доставок`.
+- [ ] Проверить активное состояние меню для `Графики`.
+- [ ] Проверить, что текущий график монтажей открывается и работает.
+- [ ] Проверить создание записи графика из площадки/заказа.
+- [ ] Проверить создание записи графика из рекламации.
+- [ ] Проверить экспорт графика монтажей.
+- [ ] Составить отдельный список полей для будущего графика заказов.
+- [ ] Составить отдельный список полей для будущего графика доставок.
+
+## 12. Критерии приемки
+
+- В верхнем меню есть группа `Графики`.
+- Внутри группы есть пункты `График заказов`, `График доставок`, `График монтажей`.
+- `График монтажей` открывается по текущему маршруту `schedule.index`.
+- Текущая логика графика монтажей не изменилась.
+- Заглушки `График заказов` и `График доставок` открываются без 404/403 у авторизованных пользователей.
+- Пользователи с текущим доступом к графику монтажей сохраняют доступ.
+- График монтажей продолжает работать с площадками ДКР.
+- График монтажей продолжает работать с рекламациями.
+
+## 13. Открытые вопросы
+
+- Какой формат обмена с 1С для графика заказов?
+- Какие поля должны отображаться в графике заказов?
+- Нужен ли ручной ввод в графике заказов?
+- Где хранить список водителей для графика доставок?
+- Нужен ли отдельный модуль `Отгрузки`, или график доставок закрывает эту задачу?
+- Какие статусы нужны для доставок?
+- Как должна выглядеть связь между графиком заказов и графиком монтажей?

docs/refactor/tz-spare-parts.md

@@ -0,0 +1,199 @@
+# ТЗ: Модуль Запчасти
+
+Связанные документы:
+
+- [План реорганизации](plan.md)
+- [Карта нового меню](menu.md)
+- [Исходное ТЗ](source-tz.md)
+- [ТЗ: Рекламации](tz-reclamations.md)
+- [ТЗ: Склад наличие](tz-stock-availability.md)
+
+## 1. Назначение
+
+Модуль `Запчасти` предназначен для учета запчастей, заказов запчастей, контроля наличия, расшифровок и работы с запросами из рекламаций.
+
+По Manager 2.0 `Запчасти` являются общим модулем для всей платформы, включая ДКР. Раздел остается отдельной верхней группой и не принадлежит только ДКР.
+
+## 2. Статус
+
+Статус модуля: **реализован**.
+
+В текущей CRM есть:
+
+- каталог запчастей;
+- заказы деталей;
+- контроль наличия;
+- справочник расшифровок;
+- справка;
+- резервы запчастей;
+- списание и отмена резервов;
+- связь с рекламациями.
+- использование в ДКР и других модулях, где нужны запчасти.
+
+Текущие маршруты:
+
+| Подраздел | Маршрут | Контроллер |
+|---|---|---|
+| Каталог | `spare_parts.index` | `SparePartController` |
+| Заказы запчастей | `spare_part_orders.index` | `SparePartOrderController` |
+| Контроль наличия | `spare_part_inventory.index` | `SparePartInventoryController` |
+| Справочник расшифровок | `pricing_codes.index` | `PricingCodeController` |
+| Справка | `spare_parts.help` | `SparePartController` |
+| Резервы | `spare_part_reservations.*` | `SparePartReservationController` |
+
+## 3. Место в меню
+
+Целевое меню:
+
+```text
+Запчасти
+├── Каталог
+├── Заказы запчастей
+├── Контроль наличия
+├── Справочник расшифровок
+└── Справка
+```
+
+Требования:
+
+- оставить `Запчасти` отдельной верхней группой;
+- сохранить текущие подпункты;
+- переименовать интерфейсный пункт `Заказы деталей` в `Заказы запчастей`;
+- текущие маршруты не переименовывать;
+- бизнес-логику не менять;
+- считать модуль общим для всех разделов Manager 2.0, включая ДКР;
+- использовать этот модуль как эталон для реализации `Склад наличие`.
+
+## 4. Права доступа
+
+На первом этапе оставляем текущие права.
+
+| Раздел | Permission |
+|---|---|
+| Запчасти | `spare_parts.view` |
+| Заказы запчастей | Использовать текущие права заказов запчастей |
+| Контроль наличия | Использовать текущие права контроля наличия |
+| Справочник расшифровок | Показывать всем пользователям с доступом к модулю `Запчасти` |
+
+Требования:
+
+- не вводить новые права;
+- сохранить текущую логику `hasPermission(...)`;
+- пользователи с прежним доступом сохраняют доступ.
+- пункт `Справочник расшифровок` показывать всем пользователям, у которых есть доступ к модулю `Запчасти`;
+- операции создания, редактирования и удаления в справочнике выполнять по текущей логике прав, если она предусмотрена в существующей реализации.
+
+## 5. Каталог запчастей
+
+Функционал должен сохраниться:
+
+- список запчастей;
+- карточка запчасти;
+- создание, редактирование, удаление;
+- импорт и экспорт;
+- загрузка изображения;
+- цены и расшифровки;
+- минимальный остаток;
+- поиск, фильтры, пагинация.
+
+## 6. Заказы запчастей
+
+Функционал должен сохраниться:
+
+- список заказов запчастей;
+- создание и редактирование заказа;
+- статусы заказа;
+- отметка как `На складе`;
+- отгрузка;
+- корректировки;
+- связь с активными резервами;
+- списание и отмена резервов;
+- история действий, если есть в текущей реализации.
+
+## 7. Контроль наличия
+
+Функционал должен сохраниться:
+
+- расчет остатков;
+- отображение дефицитов;
+- контроль минимального остатка;
+- связь с заказами деталей и резервами;
+- подсветка критичных позиций.
+
+## 8. Справочник расшифровок
+
+Функционал должен сохраниться:
+
+- список кодов;
+- создание, редактирование, удаление;
+- поиск;
+- получение расшифровки через текущие AJAX/API маршруты.
+
+## 9. Связь с рекламациями
+
+Требования:
+
+- из рекламации должен формироваться запрос на запчасть;
+- резервы запчастей должны отображаться в карточке рекламации;
+- списание и отмена резерва должны работать как сейчас;
+- дефициты должны продолжить отображаться в рекламации.
+- рекламации ДКР используют общий модуль `Запчасти`, без отдельного контура запчастей внутри ДКР.
+
+## 10. Эталон для склада наличия
+
+Раздел `Склад наличие` должен строиться по образцу `Запчасти`.
+
+Используемые паттерны:
+
+- вкладки;
+- карточки;
+- заказы;
+- расчет остатков;
+- бронирование;
+- списание;
+- отмена брони;
+- история;
+- импорт/экспорт;
+- права доступа.
+
+Отличие:
+
+- в `Склад наличие` вместо запчастей используются МАФ/позиции из `Каталог общий`.
+
+## 11. Что не входит в первый этап
+
+- изменение бизнес-логики запчастей;
+- изменение маршрутов;
+- переработка моделей;
+- перенос данных;
+- объединение запчастей со складом наличия;
+- новые права.
+
+## 12. Этапы реализации
+
+- [ ] Проверить текущие маршруты `spare_parts.*`.
+- [ ] Проверить текущие маршруты `spare_part_orders.*`.
+- [ ] Проверить текущие маршруты `spare_part_inventory.index`.
+- [ ] Проверить текущие маршруты `pricing_codes.*`.
+- [ ] Перенести меню `Запчасти` в новую структуру без изменения маршрутов.
+- [ ] Переименовать пункт `Заказы деталей` в `Заказы запчастей`.
+- [ ] Открыть пункт `Справочник расшифровок` всем пользователям с доступом к модулю `Запчасти`.
+- [ ] Проверить каталог запчастей.
+- [ ] Проверить заказы запчастей.
+- [ ] Проверить контроль наличия.
+- [ ] Проверить справочник расшифровок.
+- [ ] Проверить связь с рекламациями.
+- [ ] Зафиксировать логику модуля как основу для `Склад наличие`.
+
+## 13. Критерии приемки
+
+- В меню есть верхняя группа `Запчасти`.
+- Все текущие подпункты доступны.
+- Пункт заказов называется `Заказы запчастей`.
+- Текущие маршруты сохранены.
+- Пользователи с прежним доступом сохраняют доступ.
+- Пользователь с доступом к модулю `Запчасти` видит `Справочник расшифровок`.
+- Модуль используется как общий контур запчастей для Manager 2.0, включая ДКР.
+- Рекламации продолжают формировать запросы на запчасти.
+- Резервы, списание и отмена брони работают как раньше.
+- Логика запчастей не изменилась после реорганизации меню.

docs/refactor/tz-stock-availability.md

@@ -0,0 +1,288 @@
+# ТЗ: Модуль Склад наличие
+
+Связанные документы:
+
+- [План реорганизации](plan.md)
+- [Карта нового меню](menu.md)
+- [Исходное ТЗ](source-tz.md)
+- [ТЗ: Каталог общий](tz-catalog-common.md)
+- [ТЗ: Запчасти](tz-spare-parts.md)
+
+## 1. Назначение
+
+`Склад наличие` — новый модуль для учета МАФ/позиций, которые есть на складе или заказаны.
+
+Модуль должен быть реализован полностью по образцу раздела `Запчасти`, с адаптацией под МАФ/позиции из `Каталог общий`.
+
+## 2. Статус
+
+Статус модуля: **нужно реализовать**.
+
+На первом этапе в меню добавляются заглушки:
+
+- `Наличие`;
+- `Заказы`.
+
+Полная реализация выполняется после согласования модели данных и переноса паттернов из `Запчасти`.
+
+## 3. Место в меню
+
+Целевое меню:
+
+```text
+Склад наличие
+├── Наличие
+└── Заказы
+```
+
+Требования:
+
+- добавить верхний пункт `Склад наличие`;
+- добавить пункты `Наличие` и `Заказы`;
+- для первого этапа добавить страницы `В разработке`;
+- выбранный год в CRM не влияет на отображение и данные модуля;
+- техническое имя маршрутов, таблиц и прав модуля: `stock`.
+
+## 4. Права доступа
+
+Требования из исходного ТЗ:
+
+| Подраздел | Доступ |
+|---|---|
+| Наличие | Видно всем пользователям |
+| Заказы | Видит только админ и помощник руководителя (`assistant_head`) |
+
+На первом этапе:
+
+- текущую систему прав не перерабатывать;
+- заглушки `Наличие` и `Заказы` показывать всем авторизованным пользователям;
+- при реализации добавить/назначить права согласно таблице выше.
+- роль `помощник руководителя` в системе соответствует `assistant_head`.
+
+## 5. Подраздел `Наличие`
+
+Назначение:
+
+- отображать список МАФ/позиций, у которых есть наличие на складе.
+
+Правило вывода:
+
+- показывать МАФ, у которых есть хотя бы одна запись в подвкладке `Заказы`;
+- в итоговом списке основное внимание на позициях с остатком на складе больше 0.
+
+Колонки:
+
+| Колонка | Источник |
+|---|---|
+| Картинка | `Каталог общий` |
+| Артикул | `Каталог общий` |
+| Наименование | `Каталог общий` |
+| Характеристики | `Каталог общий` |
+| Ед. измерения | `Каталог общий` |
+| Кол-во в наличии | Подвкладка `Заказы` |
+| Забронировано | Функция бронирования |
+| Остаток фактический | Кол-во в наличии минус забронировано и списано |
+| Заказано | Сумма позиций со статусом `заказан` |
+| Примечание | Добавление или импорт |
+
+Функционал:
+
+- список наличия;
+- поиск и фильтры;
+- переход в карточку позиции по двойному клику;
+- экспорт в PDF всех позиций в наличии;
+- отображение фактического остатка;
+- отображение количества в бронях;
+- отображение заказанного количества.
+
+## 6. Карточка позиции
+
+Карточка открывается из `Наличие` двойным кликом.
+
+Нередактируемые поля:
+
+- картинка;
+- артикул;
+- наименование;
+- характеристики;
+- единица измерения;
+- количество в наличии;
+- забронировано;
+- остаток фактический;
+- заказано;
+- примечание.
+
+Функционал карточки:
+
+- отображение остатков внизу карточки аналогично `Запчастям`;
+- список активных броней;
+- история бронирований и списаний;
+- кнопка `Забронировать`;
+- действие `Списать`;
+- действие `Отменить бронь`.
+
+## 7. Бронирование
+
+Кнопка `Забронировать` открывает модальное окно.
+
+Поля:
+
+- менеджер из выпадающего списка;
+- количество;
+- примечание.
+
+Правила:
+
+- нельзя забронировать больше доступного остатка;
+- при попытке превышения показывать ошибку `Такого кол-ва нет в наличии`;
+- после бронирования запись появляется в списке `Забронировано`.
+
+Список `Забронировано`:
+
+- менеджер;
+- количество;
+- номер заказа или заказов;
+- примечание;
+- действие `Списать`;
+- действие `Отменить бронь`.
+
+## 8. Списание
+
+Списание выполняется по активной брони.
+
+Правила:
+
+- количество списывается с соответствующих заказов;
+- сохраняется история, куда ушла позиция;
+- сохраняется история, из какого заказа списана позиция;
+- фиксируется пользователь и время операции;
+- после списания фактический остаток пересчитывается.
+
+## 9. Отмена брони
+
+Правила:
+
+- отмена возвращает количество в доступный остаток;
+- история отмены сохраняется;
+- отмененная бронь не участвует в расчете активного забронированного количества.
+
+## 10. Подраздел `Заказы`
+
+Назначение:
+
+- ручное добавление складских заказов;
+- импорт складских заказов;
+- источник данных для расчета наличия.
+
+Поля заказа:
+
+| Поле | Описание |
+|---|---|
+| Номер заказа | Вводится вручную |
+| Артикул | Артикул позиции из общего каталога |
+| Статус заказа | `на складе` / `заказан` / `отгружено` |
+| Кол-во заказано | Вводится вручную |
+| Остаток | Фактический остаток с учетом бронирований и списаний |
+| Примечание | Ручной ввод или импорт |
+| Дата добавления | Заполняется автоматически |
+
+Функционал:
+
+- список заказов;
+- создание заказа;
+- редактирование заказа;
+- импорт;
+- изменение статуса;
+- связь с позицией общего каталога;
+- расчет остатка по заказу;
+- отображение активных броней.
+
+## 11. Экспорт
+
+Требования:
+
+- в `Наличие` должна быть кнопка `Экспорт`;
+- экспорт выполняется в PDF;
+- экспортируются все позиции в наличии;
+- PDF формируется по отдельному шаблону;
+- шаблон PDF нужно подготовить отдельно.
+
+## 12. Связи
+
+| Модуль | Связь | Требование |
+|---|---|---|
+| Каталог общий | Источник картинки, артикула, наименования, характеристик, ед. изм. | Обязательная связь. |
+| График отгрузок / График заказов | Данные об отгрузках | Уточнить после реализации графиков. |
+| Запчасти | Эталон логики | Использовать паттерны реализации. |
+
+## 13. Модель данных
+
+Проектируется по образцу `Запчасти`.
+
+Предварительные сущности:
+
+- складская позиция наличия;
+- складской заказ;
+- бронь складской позиции;
+- история движений;
+- импорт складских заказов;
+- PDF-экспорт.
+
+Открыто:
+
+- точные имена таблиц и моделей;
+- использовать ли отдельную сущность наличия или рассчитывать ее из заказов;
+- как связать заказ склада с позицией общего каталога: по `product_id`, артикулу или обоим полям.
+
+## 14. Что не входит в первый этап
+
+- полная реализация склада;
+- проектирование финальной БД;
+- PDF-шаблон;
+- интеграция с графиком отгрузок;
+- новые постоянные permissions.
+
+Первый этап:
+
+- добавить меню;
+- добавить заглушки, доступные всем авторизованным пользователям;
+- подготовить ТЗ;
+- использовать `Запчасти` как эталон.
+
+## 15. Этапы реализации
+
+- [ ] Разобрать текущие модели и сервисы `Запчасти`.
+- [ ] Составить карту соответствия сущностей `Запчасти` -> `Склад наличие`.
+- [ ] Согласовать имя модуля в маршрутах и таблицах.
+- [ ] Спроектировать таблицы.
+- [ ] Добавить модели.
+- [ ] Реализовать `Заказы`.
+- [ ] Реализовать `Наличие`.
+- [ ] Реализовать карточку позиции.
+- [ ] Реализовать бронирование.
+- [ ] Реализовать списание.
+- [ ] Реализовать отмену брони.
+- [ ] Реализовать историю.
+- [ ] Реализовать импорт.
+- [ ] Реализовать PDF-экспорт.
+- [ ] Настроить права доступа.
+- [ ] Покрыть расчеты остатков тестами.
+
+## 16. Критерии приемки
+
+- В меню есть `Склад наличие`.
+- Есть подвкладки `Наличие` и `Заказы`.
+- `Наличие` доступно всем пользователям.
+- `Заказы` доступны админу и помощнику руководителя.
+- `помощник руководителя` соответствует роли `assistant_head`.
+- Позиции берут справочные данные из `Каталог общий`.
+- Нельзя забронировать больше доступного остатка.
+- Списание уменьшает остаток соответствующего заказа.
+- Отмена брони возвращает доступный остаток.
+- История операций сохраняется.
+- PDF-экспорт формируется по шаблону.
+
+## 17. Открытые вопросы
+
+- Какой точный PDF-шаблон нужен для экспорта?
+- Как будет выглядеть связь с графиком отгрузок/заказов?

docs/refactor/tz-technical-description.md

@@ -0,0 +1,99 @@
+# ТЗ: Технич. описание
+
+Связанные документы:
+
+- [План реорганизации](plan.md)
+- [Карта нового меню](menu.md)
+- [Исходное ТЗ](source-tz.md)
+- [ТЗ: Каталог общий](tz-catalog-common.md)
+
+## 1. Назначение
+
+`Технич. описание` описывает технические данные позиции общего каталога и выгрузки этих данных в заданном формате.
+
+По новым вводным это, скорее всего, не отдельный самостоятельный модуль, а часть модуля `Каталог общий`: по сути это те же данные позиции, только представленные и выгружаемые в определенном формате.
+
+## 2. Статус
+
+Статус: **кандидат на поглощение модулем `Каталог общий`**.
+
+Есть готовый модуль на Laravel. Его нужно изучить и использовать как источник:
+
+- структуры данных технического описания;
+- правил формирования выгрузок;
+- шаблонов/форматов экспорта;
+- возможных UI-решений, если они применимы к текущей CRM.
+
+## 3. Место в меню
+
+До окончательного решения пункт `Технич. описание` можно оставить в целевой карте меню как заглушку для совместимости с исходным ТЗ.
+
+Предпочтительная целевая модель:
+
+```text
+Каталог общий
+└── Карточка позиции
+    └── Технич. описание / экспорт
+```
+
+Требования:
+
+- не проектировать отдельную сущность техописания, если достаточно данных карточки общего каталога;
+- открыть техописание из карточки позиции общего каталога;
+- обеспечить выгрузку технического описания в требуемом формате;
+- использовать готовый Laravel-модуль как источник логики экспорта.
+- выбранный год в CRM не влияет на техописания и их выгрузки.
+
+## 4. Права доступа
+
+На этапе заглушки:
+
+- пункт/заглушку показывать всем авторизованным пользователям.
+
+Целевая модель:
+
+- просмотр техописания наследует доступ к позиции общего каталога;
+- экспорт техописания наследует доступ к позиции общего каталога;
+- редактирование данных техописания наследует права редактирования позиции общего каталога, если техописание будет встроено в карточку позиции.
+
+## 5. Функциональные требования
+
+Целевой функционал:
+
+- просмотр технических данных из карточки позиции общего каталога;
+- редактирование технических данных вместе с карточкой позиции или в отдельной вкладке карточки;
+- формирование выгрузки технического описания в установленном формате;
+- использование готового Laravel-модуля как основы для экспорта;
+- хранение данных в структуре общего каталога или связанной таблице, если данные нельзя уложить в основную карточку позиции.
+
+## 6. Что не входит до анализа готового модуля
+
+- отдельный самостоятельный раздел техописаний;
+- отдельная модель прав, не связанная с каталогом;
+- перенос данных без анализа структуры готового Laravel-модуля;
+- финальная схема таблиц.
+
+## 7. Этапы реализации
+
+- [ ] Получить и изучить готовый Laravel-модуль техописаний.
+- [ ] Составить карту данных модуля техописаний.
+- [ ] Составить карту экспортов и форматов выгрузки.
+- [ ] Сопоставить данные техописаний с полями `Каталог общий`.
+- [ ] Решить, какие данные хранятся прямо в карточке позиции, а какие требуют связанных таблиц.
+- [ ] Встроить просмотр/редактирование техописания в карточку общего каталога.
+- [ ] Перенести или адаптировать экспорт из готового Laravel-модуля.
+- [ ] Если отдельный пункт меню больше не нужен, убрать его из финальной навигации.
+
+## 8. Критерии приемки
+
+- Техническое описание доступно из карточки позиции общего каталога.
+- Данные техописания не дублируют общий каталог без необходимости.
+- Экспорт техописания работает в согласованном формате.
+- Готовый Laravel-модуль использован как источник экспортной логики.
+- Права просмотра/редактирования согласованы с правами общего каталога.
+
+## 9. Открытые вопросы
+
+- Где находится готовый Laravel-модуль техописаний и какие его части можно переносить напрямую?
+- Какие точные форматы выгрузки нужны?
+- Оставлять ли отдельный пункт меню `Технич. описание` или полностью перенести функциональность внутрь `Каталог общий`?