strprfcrm/docs/refactor/tz-spare-parts.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. Место в меню

Целевое меню:

Запчасти
├── Каталог
├── Заказы запчастей
├── Контроль наличия
├── Справочник расшифровок
└── Справка

Требования:

• оставить Запчасти отдельной верхней группой;
• сохранить текущие подпункты;
• переименовать интерфейсный пункт Заказы деталей в Заказы запчастей;
• текущие маршруты не переименовывать;
• бизнес-логику не менять;
• считать модуль общим для всех разделов 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, включая ДКР.
• Рекламации продолжают формировать запросы на запчасти.
• Резервы, списание и отмена брони работают как раньше.
• Логика запчастей не изменилась после реорганизации меню.