Создан единый источник истины rules-complete.md v9.1 с полной интеграцией всех правил системы. Консолидированы правила создания предметов по ролям, уточнен статус брака (НЕ РЕАЛИЗОВАНО), обновлен механизм учета ПЛАН/ФАКТ с заменой брака на потери при пересчете. Добавлен экономический учет расходников фулфилмента для селлера через рецептуру. Удалены дублирующие файлы правил (CLAUDE.md, development-checklist.md, work-protocols.md, violation-prevention-protocol.md, self-validation.md, description.md). Интегрированы UI структуры создания поставок и концепция многоуровневых таблиц.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
Veronika Smirnova
2025-08-05 15:29:41 +03:00
parent ee72a9488b
commit d30e3f9666
23 changed files with 2038 additions and 6162 deletions

2462
rules-complete.md Normal file
View File

@ -0,0 +1,2462 @@
# ПРАВИЛА СИСТЕМЫ УПРАВЛЕНИЯ СКЛАДАМИ И ПОСТАВКАМИ - ЕДИНЫЙ ИСТОЧНИК ИСТИНЫ v9.1
> ⚠️ **АБСОЛЮТНО ПОЛНЫЙ ЕДИНЫЙ ИСТОЧНИК ИСТИНЫ**: Данный файл объединяет АБСОЛЮТНО ВСЕ правила системы: протоколы работы Claude Code, детальные протоколы по сложности, систему предотвращения нарушений, расширенную самопроверку, специальный UI/UX протокол и бизнес-правила. Визуальные правила вынесены в отдельный файл visual-design-rules.md с автоматической интеграцией.
## 🔴 ПРОТОКОЛЫ РАБОТЫ CLAUDE CODE
### ⛔ ЖЕСТКИЙ ПРОТОКОЛ - ОБЯЗАТЕЛЬНОЕ ИСПОЛНЕНИЕ
**Я НЕ МОГУ выполнять НИКАКИХ изменений в коде без предварительного чтения этого файла**
**КОМАНДА ОСТАНОВКИ**: "СТОП - ЧИТАЙ ПРАВИЛА" - немедленно останавливает любую работу
### 📋 ОБЯЗАТЕЛЬНЫЙ ЧЕК-ЛИСТ ПЕРЕД КАЖДОЙ ЗАДАЧЕЙ
**КАЖДЫЙ ОТВЕТ ДОЛЖЕН НАЧИНАТЬСЯ С:**
```
## 📋 Чек-лист соответствия правилам:
- ✅ Прочитал rules-complete.md
- ✅ Задача понята в контексте правил
- ✅ План действий соответствует правилам
- ✅ [ЕСЛИ UI/UX ЗАДАЧА] Прочитал visual-design-rules.md
- ✅ Готов выполнять согласно единому источнику истины
```
**БЕЗ ЭТОГО ЧЕК-ЛИСТА = НИКАКИХ ДЕЙСТВИЙ**
### 🔄 ДВУХЭТАПНЫЙ ПРОЦЕСС РАБОТЫ
#### **ЭТАП 1: ПЛАНИРОВАНИЕ (ОБЯЗАТЕЛЬНЫЙ)**
- Прочитать этот файл правил
- Создать детальный план действий
- Указать какие правила будут применены
- **ОСТАНОВИТЬСЯ И ЖДАТЬ ОДОБРЕНИЯ ПЛАНА**
#### **ЭТАП 2: ВЫПОЛНЕНИЕ (ТОЛЬКО ПОСЛЕ ОДОБРЕНИЯ)**
- Получить одобрение плана от пользователя
- Следовать ТОЛЬКО одобренному плану
- Использовать TodoWrite для отслеживания прогресса
**ПРАВИЛО ДВУХЭТАПНОСТИ: БЕЗ ОДОБРЕНИЯ ПЛАНА = НИКАКОГО ВЫПОЛНЕНИЯ**
## 🛠️ ДЕТАЛЬНЫЕ ПРОТОКОЛЫ ПО СЛОЖНОСТИ ЗАДАЧ
### 🎯 ПРОТОКОЛ ДЛЯ ЗАДАЧ СРЕДНЕЙ СЛОЖНОСТИ
**ОПРЕДЕЛЕНИЕ СРЕДНЕЙ СЛОЖНОСТИ:**
- Работа с 2-3 файлами
- Изменение логики в 1-2 модулях
- Добавление новых функций без изменения архитектуры
- Задачи, требующие анализа зависимостей
**ОБЯЗАТЕЛЬНЫЕ ЭТАПЫ:**
#### 1. 🔍 **ЭТАП АНАЛИЗА** (STOP & THINK)
```
ПЕРЕД НАЧАЛОМ ЗАДАТЬ СЕБЕ:
□ Какие файлы нужно изучить? (перечислить ВСЕ)
□ Какие правила из этого документа применимы?
□ Есть ли зависимости между компонентами?
□ Что может пойти не так?
□ Нужны ли уточнения от пользователя?
```
#### 2. 📋 **СОЗДАНИЕ ПЛАНА**
```
□ Разбить задачу на подзадачи (не более 5)
□ Определить порядок выполнения
□ Выявить критические точки
□ Создать TODO список
```
#### 3. 🔄 **ВЫПОЛНЕНИЕ С ПРОВЕРКАМИ**
```
ПОСЛЕ КАЖДОГО ШАГА:
□ Соответствует ли результат правилам из этого документа?
Не нарушены ли связи с другими модулями?
□ Работает ли измененный код?
□ Нужно ли обновить documentation?
```
### 🔥 ПРОТОКОЛ ДЛЯ ЗАДАЧ ВЫСОКОЙ СЛОЖНОСТИ
**ОПРЕДЕЛЕНИЕ ВЫСОКОЙ СЛОЖНОСТИ:**
- Работа с 4+ файлами
- Изменение архитектуры системы
- Создание новых модулей/компонентов
- Задачи, влияющие на несколько кабинетов
- Изменения в правилах или workflow
**ОБЯЗАТЕЛЬНЫЕ ЭТАПЫ:**
#### 1. 🛑 **СТОП! ГЛУБОКИЙ АНАЛИЗ**
```
ОБЯЗАТЕЛЬНЫЕ ВОПРОСЫ ПОЛЬЗОВАТЕЛЮ:
□ Уточнить ВСЕ требования и ожидания
□ Выяснить приоритеты и ограничения
□ Узнать о связях с другими системами
□ Понять критерии успеха
```
#### 2. 🔍 **ИССЛЕДОВАТЕЛЬСКАЯ ФАЗА**
```
□ Изучить ВСЕ связанные файлы параллельно
□ Построить карту зависимостей
□ Найти все правила в этом документе
□ Выявить потенциальные конфликты
□ Проанализировать влияние на систему
```
#### 3. 📊 **СОЗДАНИЕ ДЕТАЛЬНОГО ПЛАНА**
```
□ Разбить на этапы с промежуточными проверками
□ Определить точки возврата (rollback points)
□ Создать план тестирования
□ Предусмотреть обновление документации
```
### ❓ СИСТЕМА ОБЯЗАТЕЛЬНЫХ УТОЧНЕНИЙ
#### 🔴 **КРИТИЧЕСКИЕ СИТУАЦИИ** (ОБЯЗАТЕЛЬНО):
- Обнаружил противоречие в правилах
- Задача может нарушить архитектуру системы
- Неясно как применить правило к конкретной ситуации
- Есть несколько способов решения с разными последствиями
- Изменения затрагивают критические бизнес-процессы
#### 🟡 **ВАЖНЫЕ СИТУАЦИИ** (РЕКОМЕНДУЕТСЯ):
- Задача требует создания новых типов данных
- Нужно изменить существующий workflow
- Есть сомнения в интерпретации требований
- Решение может повлиять на производительность
- Требуется интеграция с внешними системами
**ФОРМАТ УТОЧНЯЮЩИХ ВОПРОСОВ:**
```
🎯 КОНТЕКСТ: Что именно я делаю
❓ ВОПРОС: Что конкретно неясно
⚖️ ВАРИАНТЫ: Какие есть альтернативы (если применимо)
⚠️ РИСКИ: Что может пойти не так
💡 ПРЕДЛОЖЕНИЕ: Мой рекомендуемый подход
```
### 🎨 СПЕЦИАЛЬНЫЙ ПРОТОКОЛ ДЛЯ UI/UX ЗАДАЧ
**АВТОМАТИЧЕСКАЯ АКТИВАЦИЯ:** При обнаружении ключевых слов: дизайн, интерфейс, компонент, стили, UI, UX, визуал, цвет, кнопка, форма, карточка
**ОБЯЗАТЕЛЬНЫЕ ЭТАПЫ:**
#### 1. 📖 **ИЗУЧЕНИЕ ВИЗУАЛЬНЫХ ПРАВИЛ**
```
ОБЯЗАТЕЛЬНО:
□ Прочитать visual-design-rules.md
□ Найти применимые цветовые схемы
□ Проверить правила для конкретного кабинета (селлер/фулфилмент/поставщик/логист)
□ Изучить glass-system и UI компоненты
```
#### 2. 🎯 **ПРИМЕНЕНИЕ ДИЗАЙН-СИСТЕМЫ**
```
ПРОВЕРИТЬ:
□ Соответствие цветовой палитре (OKLCH)
□ Использование glass-эффектов (bg-white/10 backdrop-blur)
□ Правильные статусные цвета
□ Адаптивность и отзывчивость
□ Консистентность с существующими компонентами
```
#### 3. ✅ **ВАЛИДАЦИЯ ДИЗАЙНА**
```
УБЕДИТЬСЯ:
□ Соблюдены принципы иерархии
□ Цвета соответствуют функциональному назначению
□ Интерфейс доступен и понятен
□ Стиль согласован с общей системой
```
## 🚨 СИСТЕМА ПРЕДОТВРАЩЕНИЯ НАРУШЕНИЙ
### 🛑 ОБЯЗАТЕЛЬНЫЕ ОСТАНОВКИ ПЕРЕД ДЕЙСТВИЯМИ
#### **СТОП-СИГНАЛ #1: ПЕРЕД ЛЮБЫМ АНАЛИЗОМ КОМПОНЕНТОВ**
```
❌ ЗАПРЕЩЕНО: Делать предположения о содержании файлов/компонентов
✅ ОБЯЗАТЕЛЬНО:
1. Использовать поиск для понимания
2. Читать файлы для точного содержания
3. Только ПОСЛЕ изучения кода - выводы
```
#### **СТОП-СИГНАЛ #2: ПРИ НЕОПРЕДЕЛЕННОСТИ**
```
❌ ЗАПРЕЩЕНО: Гадать, предполагать, домысливать
✅ ОБЯЗАТЕЛЬНО:
1. СТОП - зафиксировать неопределенность
2. Использовать инструменты анализа (если применимо)
3. Задать прямой вопрос пользователю
```
#### **СТОП-СИГНАЛ #3: ПЕРЕД ВЫПОЛНЕНИЕМ СРЕДНИХ/СЛОЖНЫХ ЗАДАЧ**
```
❌ ЗАПРЕЩЕНО: Сразу приступать к работе
✅ ОБЯЗАТЕЛЬНО:
1. Применить соответствующий протокол из этого документа
2. Создать план через TodoWrite
3. Пройти этап самопроверки
```
### 🔒 СИСТЕМА ПРИНУДИТЕЛЬНЫХ ПРОВЕРОК
#### **ПРОВЕРКА #1: АНАЛИЗ КОДА**
```
Если задача включает анализ компонентов:
□ Использовал ли поиск по кодовой базе?
□ Прочитал ли исходный код?
□ Основаны ли выводы на фактах, а не предположениях?
```
#### **ПРОВЕРКА #2: СОБЛЮДЕНИЕ ПРОТОКОЛОВ**
```
Для каждой задачи:
□ Определил ли сложность задачи?
□ Применил ли соответствующий протокол?
□ Создал ли план действий?
□ Провел ли финальную самопроверку?
```
### ⚡ СИСТЕМА АВТОМАТИЧЕСКИХ ТРИГГЕРОВ
#### **ТРИГГЕР #1: При упоминании компонентов**
- Ключевые слова: "компонент", "файл", "содержание", "показывает"
- Действие: ОБЯЗАТЕЛЬНО использовать инструменты анализа кода
#### **ТРИГГЕР #2: При неопределенности**
- Ключевые фразы: "возможно", "вероятно", "думаю", "предполагаю"
- Действие: СТОП + вопрос пользователю
#### **ТРИГГЕР #3: При работе с UI/UX**
- Ключевые слова: "дизайн", "интерфейс", "компонент", "стили", "UI", "UX", "визуал", "цвет", "кнопка", "форма", "карточка"
- Действие: ОБЯЗАТЕЛЬНО прочитать visual-design-rules.md перед началом работы
### 🛡️ СИСТЕМА БЛОКИРОВКИ НАРУШЕНИЙ
```
🛑 ОСТАНОВИТЬСЯ НЕМЕДЛЕННО ЕСЛИ:
- Не определил сложность задачи
- Пропустил этап "Стоп и подумай"
- Есть сомнения в правилах
- Не проверил все применимые разделы этого документа
- Не уведомил о важных изменениях
```
## ✅ РАСШИРЕННАЯ СИСТЕМА САМОПРОВЕРКИ
### 🛑 ОБЯЗАТЕЛЬНЫЙ ПРОТОКОЛ ПЕРЕД КАЖДОЙ ЗАДАЧЕЙ
#### **ШАГ 1: ОПРЕДЕЛЕНИЕ СЛОЖНОСТИ И ПРОТОКОЛА**
```
ВОПРОСЫ:
- Сколько файлов затрагивает задача? (1-3 = средняя, 4+ = высокая)
- Изменяется ли архитектура или workflow? (да = высокая)
- Влияет ли на критические бизнес-процессы? (да = высокая)
ДЕЙСТВИЕ: Применить соответствующий протокол из этого документа
```
#### **ШАГ 2: ЭТАП "СТОП И ПОДУМАЙ"**
```
ОБЯЗАТЕЛЬНЫЕ ВОПРОСЫ:
- Какие правила из этого документа применимы?
- Какие файлы нужно изучить? (перечислить ВСЕ)
- Есть ли неопределенности, требующие уточнения?
- Что может пойти не так?
ДЕЙСТВИЕ: Составить план с промежуточными проверками
```
### 📊 ФИНАЛЬНАЯ МЕГА-ПРОВЕРКА
```
МЕГА-ВОПРОС К СЕБЕ:
"Применил ли я правильный протокол, проверил ли все правила,
задал ли нужные вопросы, готов ли результат к production?"
ЕСЛИ ОТВЕТ НЕ "ДА 100%" - ВЕРНУТЬСЯ К НАЧАЛУ!
```
### 📈 МЕТРИКИ УСПЕХА
```
ЦЕЛЬ: 0 пропущенных критических деталей
ИЗМЕРЕНИЕ:
✅ Количество вопросов на уточнение
✅ Полнота анализа источников
✅ Отсутствие нарушений правил
```
## ⚡ БЫСТРЫЙ СПРАВОЧНИК
### 🚨 КРИТИЧЕСКИЕ ПРАВИЛА (ОБЯЗАТЕЛЬНЫ К СОБЛЮДЕНИЮ)
1. **🔴 ТИПИЗАЦИЯ**: Каждый предмет ОБЯЗАТЕЛЬНО имеет тип: `PRODUCT`, `CONSUMABLE`, `DEFECT`, `FINISHED_PRODUCT`
2. **🔴 WORKFLOW**: Нельзя пропускать статусы поставок: PENDING → SUPPLIER_APPROVED → CONFIRMED → ... → DELIVERED
3. **🔴 ДОСТУП**: Фулфилмент = полный доступ, Селлер ≠ доступ к чужим данным, Брак = ЗАПРЕЩЕН к заказу
4. **🔴 ПАРТНЕРСТВО**: Все связи через модель `Counterparty`, поставщики в формах ТОЛЬКО из партнеров `WHOLESALE`
5. **🔴 ФИЛЬТРАЦИЯ**: По типу предмета происходит в GraphQL резолверах, НЕ на фронтенде
### 🔍 БЫСТРЫЙ ПОИСК ПО ТЕМАМ
| Тема | Раздел | Ключевые понятия |
|------|--------|------------------|
| **Типы предметов** | [2](#2--типизация-предметов) | PRODUCT, CONSUMABLE, DEFECT, FINISHED_PRODUCT |
| **Кабинет фулфилмента** | [11](#11--кабинет-фулфилмента-полная-документация) | Склад, Услуги, Сотрудники, 6 модулей |
| **Workflow поставок** | [5](#5--workflow-поставок) | 8 статусов, уведомления, логистика |
| **GraphQL запросы** | [18](#18--graphql-и-typescript-правила), [24](#24--технические-приложения) | Резолверы, мутации, типизация |
| **Система партнерства** | [13](#13--система-партнерства-и-контрагентов) | Counterparty, WHOLESALE, заявки |
| **Критические запреты** | [17](#17--критические-запреты) | Что НЕЛЬЗЯ делать в системе |
### 🎯 ДЛЯ РАЗНЫХ РОЛЕЙ
**👩‍💻 РАЗРАБОТЧИКИ**: Разделы [18](#18--graphql-и-typescript-правила), [19](#19--архитектурные-принципы), [20](#20--правила-качества-кода), [24](#24--технические-приложения)
**📊 АНАЛИТИКИ**: Разделы [15](#15--статистика-и-аналитика), [6](#6--процесс-создания-продукта), [7](#7--система-учета-движения-товаров)
**👔 МЕНЕДЖЕРЫ**: Разделы [1](#1--основные-принципы-системы), [3](#3--структура-кабинетов), [5](#5--workflow-поставок)
---
## 🔤 ГЛОССАРИЙ ТЕРМИНОВ
> Для людей → `В коде`
### **ТИПЫ ПРЕДМЕТОВ:**
- **ТОВАР** → `PRODUCT` - базовый товар от поставщика, может стать продуктом или браком
- **РАСХОДНИКИ** → `CONSUMABLE` - материалы, классифицируются по назначению при использовании (операционные/производственные)
- **БРАК** → `DEFECT` *(НЕ РЕАЛИЗОВАНО)* - функционал брака еще не внедрен в систему
- **ПРОДУКТ** → `FINISHED_PRODUCT` *(планируется)* - готовый товар, создается из товара по рецептуре
### **ТИПЫ ОРГАНИЗАЦИЙ:**
- **ПОСТАВЩИК** → `WHOLESALE` - создает товары и расходники, обрабатывает заказы
- **СЕЛЛЕР** → `SELLER` - заказывает товары, создает поставки на маркетплейсы
- **ФУЛФИЛМЕНТ** → `FULFILLMENT` - обрабатывает товары, создает продукты, максимальные права
- **ЛОГИСТИКА** → `LOGIST` - управляет доставками, подтверждает транспортировку
### 2.2 Правила создания предметов по ролям
**КТО МОЖЕТ СОЗДАВАТЬ:**
- **ПОСТАВЩИК** (`WHOLESALE`): Товары (`PRODUCT`) и Расходники (`CONSUMABLE`)
- **ФУЛФИЛМЕНТ** (`FULFILLMENT`): Продукты (`FINISHED_PRODUCT`) - только из существующих товаров
- **СЕЛЛЕР/ЛОГИСТ**: НЕ МОГУТ создавать предметы
**КТО МОЖЕТ ПОКУПАТЬ:**
- **СЕЛЛЕР** (`SELLER`):
- Товары и расходники у поставщиков
- Расходники фулфилмента у фулфилмента (через рецептуру в поставке)
- **ФУЛФИЛМЕНТ** (`FULFILLMENT`): Товары и расходники у поставщиков
- **ПОСТАВЩИК/ЛОГИСТ**: НЕ МОГУТ покупать предметы
**ЭКОНОМИЧЕСКИЙ УЧЕТ:**
- Когда селлер выбирает расходники фулфилмента в рецептуре, это формирует экономические данные:
- В кабинете селлера: расход на расходники фулфилмента
- В кабинете фулфилмента: доход от продажи расходников селлеру
### **КЛЮЧЕВЫЕ СУЩНОСТИ:**
- **Контрагент** → `Counterparty` - связь между организациями для партнерства
- **Поставка** → `SupplyOrder` - заказ товаров/расходников с workflow статусами
- **Рецептура** - состав продукта: товар + услуги + расходники (задается селлером)
---
## 📑 ОГЛАВЛЕНИЕ
> 📋 **ЧТО ОБЪЕДИНЕНО**:
> - rules-unified.md (v3.0) - общая база знаний системы
> - fulfillment-cabinet-rules.md (v1.0) - детализация кабинета фулфилмента
> - Устранены все несоответствия в терминах, последовательностях и детализации
### 🏗️ **АРХИТЕКТУРА И ОСНОВЫ**
1. [🎯 Основные принципы системы](#1--основные-принципы-системы)
2. [📦 Типизация предметов](#2--типизация-предметов)
3. [🏢 Структура кабинетов](#3--структура-кабинетов)
4. [🔐 Система ролей и доступов](#4--система-ролей-и-доступов)
### 🚚 **WORKFLOW И ПРОЦЕССЫ**
5. [🚚 Workflow поставок](#5--workflow-поставок)
6. [🔄 Процесс создания продукта](#6--процесс-создания-продукта)
7. [📊 Система учета движения товаров](#7--система-учета-движения-товаров)
### 🏢 **КАБИНЕТЫ СИСТЕМЫ**
8. [🏠 Общие правила кабинетов](#8--общие-правила-кабинетов)
9. [🏠 Кабинет селлера (детальные правила)](#9--кабинет-селлера-детальные-правила)
10. [🏪 Кабинет поставщика](#10--кабинет-поставщика)
11. [🏭 Кабинет фулфилмента](#11--кабинет-фулфилмента)
12. [🚚 Кабинет логистики](#12--кабинет-логистики)
### 🤝 **СИСТЕМА ПАРТНЕРСТВА**
13. [🤝 Система партнерства и контрагентов](#13--система-партнерства-и-контрагентов)
### 🌐 **ИНТЕГРАЦИИ И ФУНКЦИИ**
14. [🌐 Интеграции с системой](#14--интеграции-с-системой)
15. [📊 Статистика и аналитика](#15--статистика-и-аналитика)
16. [📱 Правила UI/UX и интерфейса](#16--правила-uiux-и-интерфейса)
17. [⚠️ Критические запреты](#17--критические-запреты)
### 🛠️ **ТЕХНИЧЕСКИЕ ПРАВИЛА**
18. [🛠️ GraphQL и TypeScript правила](#18--graphql-и-typescript-правила)
19. [🔧 Архитектурные принципы](#19--архитектурные-принципы)
20. [🎯 Правила качества кода](#20--правила-качества-кода)
21. [🔍 Диагностика и решение проблем](#21--диагностика-и-решение-проблем)
### 📋 **ПРИЛОЖЕНИЯ**
22. [📋 Категории товаров и расходников](#22--категории-товаров-и-расходников)
23. [🎖️ Приоритеты разработки](#23--приоритеты-разработки)
### 🚨 **КРИТИЧЕСКИЕ СИТУАЦИИ**
24. [🚨 Критические ситуации и Edge Cases](#-критические-ситуации-и-edge-cases)
### 📎 **ТЕХНИЧЕСКИЕ ПРИЛОЖЕНИЯ**
25. [📎 Технические приложения (GraphQL, компоненты)](#24--технические-приложения)
---
## 🏷️ РЕЕСТР СУЩНОСТЕЙ СИСТЕМЫ
### 📦 **ОСНОВНЫЕ ПРЕДМЕТЫ**
| Сущность | Название в системе | Кабинет создания | Описание | Статус |
| ---------- | ---------------------------------- | ---------------- | ----------------------------------------------- | --------------- |
| Товар | `Product` (type: `PRODUCT`) | Поставщик | Базовый тип товара от поставщика | ✅ Реализовано |
| Расходники | `Product` (type: `CONSUMABLE`) | Поставщик | Материалы и вспомогательные товары | ✅ Реализовано |
| Брак | `Product` (type: `DEFECT`)* | Фулфилмент | Производная от товара с дефектами | 📋 Планируется |
| Продукт | `Product` (type: `FINISHED_PRODUCT`)* | Фулфилмент | Готовый к продаже товар (производная от товара) | 📋 Планируется |
> **\* Планируется**: Типы `DEFECT` и `FINISHED_PRODUCT` еще не добавлены в Prisma схему
### 🏢 **ОРГАНИЗАЦИИ И РОЛИ**
| Сущность | Название в системе | Основные функции | Статус |
| ---------- | ---------------------------------- | --------------------------------------- | -------------- |
| Поставщик | `Organization` (type: `WHOLESALE`) | Создание товаров, управление поставками | ✅ Реализовано |
| Селлер | `Organization` (type: `SELLER`) | Заказ товаров, управление поставками | ✅ Реализовано |
| Фулфилмент | `Organization` (type: `FULFILLMENT`) | Обработка товаров, управление складом | ✅ Реализовано |
| Логистика | `Organization` (type: `LOGIST`) | Управление доставками | ✅ Реализовано |
### 🤝 **СИСТЕМА ПАРТНЕРСТВА**
| Сущность | Название в системе | Описание | Статус |
| ------------ | ------------------ | ---------------------------------- | -------------- |
| Контрагент | `Counterparty` | Связь между организациями | ✅ Реализовано |
| Заявка | `CounterpartyRequest` | Запрос на сотрудничество | ✅ Реализовано |
---
## 1. 🎯 ОСНОВНЫЕ ПРИНЦИПЫ СИСТЕМЫ
### 1.1 Архитектура системы
**СТРУКТУРА СИСТЕМЫ ПО КАБИНЕТАМ:**
**🏢 КАБИНЕТ ПОСТАВЩИКА** - создает и управляет:
- **ТОВАР** (`PRODUCT`) - базовые товары от поставщика
- **РАСХОДНИКИ** (`CONSUMABLE`) - материалы и вспомогательные товары от поставщика
**🏭 КАБИНЕТ ФУЛФИЛМЕНТА** - принимает, обрабатывает и управляет всеми типами:
- **ТОВАР** (`PRODUCT`) - базовые товары от поставщиков (принятые на склад)
- **БРАК** (`DEFECT` - планируется) - производная от товара (товар с дефектами)
- **ПРОДУКТ** (`FINISHED_PRODUCT` - планируется) - готовый к продаже товар
- **РАСХОДНИКИ (`CONSUMABLE`)** - единый базовый тип, классифицируется по назначению при использовании:
- **"Операционные расходники"** - используются фулфилментом для выполнения услуг
- **"Производственные расходники"** - используются в рецептурах селлеров для создания продуктов
**🛍️ КАБИНЕТ СЕЛЛЕРА** - заказывает и управляет поставками:
- Создает заказы товаров и расходников
- Управляет поставками на фулфилмент и маркетплейсы
- Отслеживает статусы поставок
### 1.2 Основные принципы разработки
**КРИТИЧЕСКИ ВАЖНЫЕ ПРИНЦИПЫ:**
1. **Строгая типизация**: Каждый предмет имеет один из типов: ТОВАР (`PRODUCT`), РАСХОДНИКИ (`CONSUMABLE`), БРАК и ПРОДУКТ (планируется)
2. **Партнерская система**: Все связи между организациями через модель `Counterparty`
3. **Workflow статусов**: Строгая последовательность статусов поставок
4. **Безопасность доступа**: Контроль доступа на уровне GraphQL резолверов
5. **Единый источник истины**: Централизованное управление данными
---
## 2. 📦 ТИПИЗАЦИЯ ПРЕДМЕТОВ
### 2.1 Два реализованных и два планируемых типа предметов
#### **1. ТОВАР** (`PRODUCT` - базовый тип)
- **СОЗДАЕТСЯ**: Поставщиком
- **СТАТУС**: Может быть активным/неактивным
- **ЗАКАЗ**: Доступен для заказа всеми типами организаций
- **ТРАНСФОРМАЦИЯ**: Может стать ПРОДУКТОМ или БРАКОМ
- **ЦЕНА**: Обязательна, больше 0
#### **2. РАСХОДНИКИ** (`CONSUMABLE` - базовый тип)
- **СОЗДАЕТСЯ**: Поставщиком как универсальный тип
- **КЛАССИФИКАЦИЯ ПРИ ЗАКАЗЕ**:
- Фулфилмент заказывает → "Расходники фулфилмента"
- Селлер заказывает → "Расходники селлеров"
- **ДОСТУП**: Видны всем типам организаций в маркете
#### **3. БРАК** (`DEFECT` - планируется, производная от товара)
- **БУДЕТ СОЗДАВАТЬСЯ**: Фулфилментом на основе существующего ТОВАРА при обнаружении дефектов
- **МОМЕНТ СОЗДАНИЯ**: В процессе обработки товара (ШАГ 3 алгоритма создания продукта) при выявлении брака
- **СВЯЗЬ**: Обязательная связь с родительским товаром (parentId)
- **ЗАКАЗ**: ЗАПРЕЩЕН заказ брака
- **СТАТУС**: Всегда неактивен для заказа
- **ЦЕНА**: Для селлера - себестоимость дефектного товара, для фулфилмента - 0
- **WORKFLOW**: Особый процесс списания и утилизации
- **УЧЕТ**: Отдельный учет в статистике потерь
- **ОТОБРАЖЕНИЕ**: Виден только для учета потерь
- **⚠️ СТАТУС РАЗРАБОТКИ**: Тип `DEFECT` еще не добавлен в схему БД
#### **4. ПРОДУКТ** (`FINISHED_PRODUCT` - планируется, производная от товара)
- **БУДЕТ СОЗДАВАТЬСЯ**: Фулфилментом на основе ТОВАРА по заказу селлера
- **ИНИЦИАТОР**: Селлер создает заказ с рецептурой, фулфилмент исполняет
- **СВЯЗЬ**: Обязательная связь с родительским товаром (parentId)
- **РЕЦЕПТУРА**: Задается селлером при создании заказа (Товар + Услуга + Расходники)
- **СТАТУСЫ**: "в работе" → "готов к отправке"
- **ЗАКАЗ**: Доступен только в статусе "готов к отправке"
- **⚠️ СТАТУС РАЗРАБОТКИ**: Тип `FINISHED_PRODUCT` еще не добавлен в схему БД
### 2.2 Обязательные поля карточки
**КРИТИЧЕСКИ ВАЖНО**: Название, артикул, цена > 0, тип предмета
**ИСКЛЮЧЕНИЕ ДЛЯ БРАКА**: Цена может быть 0 для фулфилмента (себестоимость для селлера)
**ОБЯЗАТЕЛЬНО**: Количество (может быть 0 для предзаказа)
**ДЛЯ ПРОИЗВОДНЫХ ТИПОВ**: Обязательная связь с родительским предметом
---
## 3. 🏢 СТРУКТУРА КАБИНЕТОВ
### 3.1 Общие принципы кабинетов
**КАЖДЫЙ КАБИНЕТ ИМЕЕТ:**
1. **Главная страница** (`/dashboard`) - общая информация и статистика
2. **Экономика** (`/economics`) - финансовая аналитика
3. **Универсальные разделы**:
- Маркет (`/market`) - просмотр и заказ товаров
- Партнеры (`/partners`) - управление контрагентами
- Мессенджер (`/messenger`) - связь между организациями
- Настройки (`/settings`) - профиль и API ключи
### 3.2 Специфические разделы по типам организаций
**🏪 ПОСТАВЩИК (`WHOLESALE`):**
- Склад (`/warehouse`) - управление товарами и расходниками
- Поставки (`/supplies`) - обработка заказов от селлеров
**🛍️ СЕЛЛЕР (`SELLER`):**
- Мои поставки (`/supplies`) - управление заказами товаров
- WB Интеграция (`/wb-integration`) - связь с Wildberries
**🏭 ФУЛФИЛМЕНТ (`FULFILLMENT`):**
- Склад фулфилмента (`/fulfillment-warehouse`) - управление всеми типами товаров
- Поставки фулфилмента (`/fulfillment-supplies`) - обработка поставок
- Услуги (`/services`) - управление услугами, логистикой, расходниками
- Сотрудники (`/employees`) - управление персоналом
- Статистика фулфилмента (`/fulfillment-statistics`) - детальная аналитика
**🚚 ЛОГИСТИКА (`LOGIST`):**
- Заявки (`/logistics-requests`) - управление заявками на доставку
- Маршруты (`/routes`) - планирование маршрутов
---
## 4. 🔐 СИСТЕМА РОЛЕЙ И ДОСТУПОВ
### 4.1 Контроль доступа к разделам
**ПРОВЕРКА НА УРОВНЕ КОМПОНЕНТОВ:**
```typescript
{user?.organization?.type === "FULFILLMENT" && (
// Компоненты доступны только фулфилменту
)}
```
**СПЕЦИАЛЬНАЯ ЛОГИКА РОУТИНГА:**
```typescript
const handleSuppliesClick = () => {
switch (user?.organization?.type) {
case "FULFILLMENT":
router.push("/fulfillment-supplies");
break;
case "SELLER":
router.push("/supplies");
break;
// ... другие типы
}
};
```
### 4.2 GraphQL проверки доступа
**В Apollo Client запросах:**
```typescript
const { data } = useQuery(GET_MY_SERVICES, {
skip: user?.organization?.type !== "FULFILLMENT",
});
```
**В GraphQL резолверах:**
```typescript
if (currentUser.organization.type !== "FULFILLMENT") {
throw new GraphQLError("Доступно только для фулфилмент центров");
}
```
### 4.3 Контроль доступа к заказам
- **Создатель заказа** - полный доступ к своим заказам
- **Поставщик** - доступ к заказам, где он является поставщиком
- **Фулфилмент-центр** - доступ к заказам, направленным в его центр
- **Логистическая компания** - доступ к заказам для доставки
---
## 5. 🚚 WORKFLOW ПОСТАВОК
> 📌 **ВИЗУАЛЬНЫЕ ПРАВИЛА**: См. [visual-design-rules.md - Статусы поставок](#142-статусы-поставок---расширенная-цветовая-система)
### 5.1 Детализированная система статусов
**Статусы SupplyOrder (Заказ поставки):**
1. **PENDING** - Ожидает подтверждения поставщиком
2. **SUPPLIER_APPROVED** - Одобрено поставщиком
3. **CONFIRMED** - Подтвержден (готов к обработке)
4. **LOGISTICS_CONFIRMED** - Подтверждено логистикой
5. **SHIPPED** - Отгружено поставщиком
6. **IN_TRANSIT** - В пути (логистика доставляет)
7. **DELIVERED** - Доставлен на фулфилмент
8. **CANCELLED** - Отменен
### 5.2 Пошаговый процесс поставки
**ЭТАП 1: Создание заказа**
1. Селлер заказывает товар/расходники у поставщика
2. Система создает SupplyOrder со статусом `PENDING`
3. Автоматическое уведомление поставщику
**ЭТАП 2: Обработка поставщиком**
4. Поставщик получает оповещение
5. Поставщик нажимает "Одобрить"
6. Статус меняется на `SUPPLIER_APPROVED`
**ЭТАП 3: Передача в фулфилмент**
7. Поставка отображается в кабинете фулфилмента
8. Фулфилмент выбирает ответственного и логистику
9. Статус меняется на `CONFIRMED`
**ЭТАП 4: Логистическое подтверждение**
10. Логистика подтверждает доставку
11. Статус меняется на `LOGISTICS_CONFIRMED`
**ЭТАП 5: Отгрузка**
12. Поставщик отгружает товар
13. Статус меняется на `SHIPPED`, затем `IN_TRANSIT`
**ЭТАП 6: Доставка и приемка**
14. Логистика доставляет на фулфилмент
15. Фулфилмент принимает товар
16. Статус меняется на `DELIVERED`
### 5.3 Система уведомлений
**Обязательные уведомления:**
- Поставщику: о новом заказе
- Фулфилменту: о подтвержденной поставке
- Логистике: о назначении на заявку
- Селлеру: об изменении каждого статуса
---
## 6. 🔄 ПРОЦЕСС СОЗДАНИЯ ПРОДУКТА
> 📌 **СВЯЗАННЫЕ РАЗДЕЛЫ**:
> - Типы предметов → См. [раздел 2.2](#22-обязательные-поля-карточки)
> - Склад фулфилмента → См. [раздел 11.2](#112-структура-раздела-склад-фулфилмента)
> - Статистика движения → См. [раздел 7](#7--система-учета-движения-товаров)
### 6.1 Пошаговый алгоритм создания продукта
> 📌 **ВИЗУАЛЬНЫЕ ПРАВИЛА**: См. [visual-design-rules.md - Процесс создания продукта](#143-процесс-создания-продукта---визуальный-workflow)
#### **ПРЕДВАРИТЕЛЬНОЕ УСЛОВИЕ: РЕЦЕПТУРА ЗАДАНА** (селлер)
```
Время: при создании заявки на поставку
Действие: селлер указывает рецептуру продукта
Обязательные компоненты:
✓ Базовый товар (от поставщика)
✓ Услуги фулфилмента (упаковка, маркировка и т.д.)
✓ Расходники (материалы для производства)
Результат: рецептура сохраняется в заявке и передается фулфилменту
```
#### **ШАГ 1: ПОСТУПЛЕНИЕ НА СКЛАД** (автоматически)
```
Время: при смене статуса поставки DELIVERED
Действие: товар переходит в статус "на складе"
Ответственный: система
Результат: +Прибыло в статистике товаров
```
#### **ШАГ 2: ПЛАНИРОВАНИЕ РАБОТЫ** (менеджер фулфилмента)
```
Время: в течение 2 рабочих дней после поступления
Действие: назначение параметров обработки
Ответственный: менеджер фулфилмента
Обязательные поля:
✓ Дедлайн выполнения (не более 5 рабочих дней)
✓ Ответственный исполнитель (из списка сотрудников)
✓ Рецептура (товар + услуги + расходники, указанная селлером в заявке на поставку)
Опциональные поля:
- Место хранения готовых продуктов (зона склада, стеллаж, ячейка)
- Комментарии к работе
Результат: поставка переходит во вкладку "В работе"
```
#### **ШАГ 3: ОБРАБОТКА ТОВАРА** (исполнитель)
```
Время: согласно дедлайну (обычно 1-3 дня)
Действие: физическая обработка товара
Ответственный: назначенный сотрудник
Обязательные действия:
1. Проверка качества товара
2. Фиксация фактического количества
3. Выявление и учет брака
4. Применение рецептуры (услуги + расходники)
5. Создание готового продукта
Точки контроля:
- Соответствие плану/факту
- Качество выполнения услуг
- Расход материалов по норме
УЧЕТ ПЛАН/ФАКТ:
- ПЛАН: Количество товаров из поставки селлера (указано в заказе)
- ФАКТ: Реальное количество после обработки = Брак + Хороший товар
- ДЕТАЛИЗАЦИЯ: Учет ведется по каждому размеру/объему/варианту
- КОРРЕКТИРОВКА: Статистика автоматически обновляется на фактические данные
```
#### **ШАГ 4: КОНТРОЛЬ КАЧЕСТВА** (менеджер/отдел качества)
```
Время: сразу после завершения ШАГ 3
Действие: приемка готовой продукции
Ответственный: менеджер или контролер качества
Критерии приемки:
✓ Соответствие рецептуре селлера
✓ Качество выполненных услуг
✓ Правильность упаковки/маркировки
✓ Полнота комплектации
Результат: продукт готов к отправке или отправлен на доработку
```
#### **ШАГ 5: ЗАВЕРШЕНИЕ** (система + менеджер)
```
Время: после успешного прохождения контроля качества
Действие: финализация процесса
Автоматические действия:
- Создание записи FINISHED_PRODUCT в БД
- Обновление статистики: товар "на складе" → продукт "готов"
- Списание использованных расходников
- Уведомление селлера о готовности
Ручные действия менеджера:
- Подтверждение перехода во вкладку "Выполнено"
- Указание фактических расходов материалов
- Добавление комментариев о выполненной работе
```
### 6.2 Временные рамки и SLA
| Этап | Стандартное время | Максимальное время | Ответственный |
|------|------------------|-------------------|---------------|
| Планирование | 1 рабочий день | 2 рабочих дня | Менеджер ФФ |
| Обработка | 2-3 рабочих дня | 5 рабочих дней | Исполнитель |
| Контроль качества | 4 часа | 1 рабочий день | Отдел качества |
| Завершение | 2 часа | 4 часа | Менеджер ФФ |
### 6.3 Управление браком и расхождениями
### 6.4 Детальная рецептура продукта
**РЕЦЕПТУРА ПРОДУКТА** (задается селлером при создании поставки):
- **БАЗОВЫЙ ТОВАР**: Исходный материал (обязательно)
- Артикул товара
- Количество единиц
- Размерная сетка (если применимо)
- **УСЛУГА ФУЛФИЛМЕНТА**: Из каталога услуг фулфилмента
- Тип услуги (глажка, упаковка, маркировка и т.д.)
- Количество применений
- Специальные требования
- **РАСХОДНИК СЕЛЛЕРА**: Материалы селлера (опционально)
- Фирменная упаковка
- Этикетки, бирки
- Дополнительные аксессуары
- **РАСХОДНИК ФУЛФИЛМЕНТА**: Материалы фулфилмента (опционально)
- Стандартная упаковка
- Защитные материалы
- Маркировочные элементы
- **СВЯЗЬ С МАРКЕТПЛЕЙСОМ**: Привязка к карточке (опционально)
- ID карточки на маркетплейсе
- Артикул маркетплейса
- Особые требования МП
**ФОРМУЛА**: ПРОДУКТ = Товар + Услуга(и) + Расходники селлера + Расходники ФФ
### 6.5 Учет план/факт в процессе работы (без брака)
**ПЛАН**: Количество товара из поставки селлера
**ФАКТ**: Реальное количество после пересчета (работник фулфилмента производит сортировку при пересчете)
**ФИКСАЦИЯ ПОТЕРЬ:**
- **КОГДА**: В процессе работы (вкладка "В работе")
- **ЧТО**: Недостача, повреждения (без создания записей брака)
- **КАК**: Корректировка количества в статистике
**WORKFLOW СОЗДАНИЯ ПРОДУКТА:**
1. Товар поступает на склад фулфилмента (статус "на складе")
2. Товар берется в работу (переход в статус "в обработке")
3. Исполнитель производит пересчет и сортировку
4. Создается готовый продукт (тип FINISHED_PRODUCT)
5. Продукт готов к отправке на маркетплейсы
**ВЛИЯНИЕ НА СТАТИСТИКУ:**
- При принятии поставки: +План в статистику
- При выявлении факта: корректировка на реальные данные
- **ФОРМУЛА**: Факт = Потери + Хороший товар
*Где потери - это недостача/повреждения, выявленные при пересчете и сортировке*
- **ЛОГИКА**: Фактическое количество = сумма всех пересчитанных предметов
- **ПЛАН/ФАКТ**: Корректировка статистики при выявлении расхождений
---
> 🚧 **БУДУЩАЯ ФУНКЦИОНАЛЬНОСТЬ**: Система статусов товаров в фулфилменте будет детализирована позже
## 7. 📊 СИСТЕМА УЧЕТА ДВИЖЕНИЯ ТОВАРОВ
### 7.1 Принципы учета в фулфилменте
**ОСНОВНЫЕ ПРИНЦИПЫ:**
- **ПРИХОД**: Товары поступают через принятые поставки (из состояния "в пути" → "на складе")
- **ОБРАБОТКА**: Товары переходят в статус "в работе" для создания продуктов
- **РАСХОД**: Товары убывают при отгрузке, списании, возврате, превращении в продукты
- **УЧЁТ**: Ведется учет прихода и расхода для каждого типа предметов
- **ВИЗУАЛИЗАЦИЯ**: Движение отображается в дополнительных значениях
### 7.2 Дополнительные и основные значения
**ДОПОЛНИТЕЛЬНЫЕ ЗНАЧЕНИЯ (показатели движения):**
- **ПРИБЫЛО**: Количество предметов, поступивших на склад
- **УБЫЛО**: Количество предметов, списанных со склада
- **ВЛИЯНИЕ**: От этих значений зависят основные значения (общее количество)
**ОСНОВНЫЕ ЗНАЧЕНИЯ (текущие остатки):**
- **ОПРЕДЕЛЕНИЕ**: Итоговое количество предметов на складе
- **РАСЧЁТ**: Основные значения = Предыдущие остатки + Прибыло - Убыло
- **ОТОБРАЖЕНИЕ**: Показываются в каждом модуле статистики
- **РАЗДЕЛЕНИЕ ТОВАРОВ**:
- Товары "на складе" - готовы к обработке
- Товары "в обработке" - находятся в процессе создания продукта
---
## 8. 🏠 ОБЩИЕ ПРАВИЛА КАБИНЕТОВ
### 8.1 Универсальная структура кабинетов
**ВСЕ ТИПЫ КАБИНЕТОВ** включают следующие обязательные разделы:
#### 8.1.1 Страница "Главная"
**СТАТУС**: Реализовано
**ДОСТУП**: Через навигацию в sidebar для всех типов кабинетов
**СОДЕРЖАНИЕ**: Универсальная страница с типо-зависимыми компонентами
**ПРАВИЛА**:
- **ОБЯЗАТЕЛЬНО**: Каждый тип кабинета должен иметь страницу "Главная"
- **НАВИГАЦИЯ**: Доступ через кнопку в sidebar (первая в списке)
- **УНИВЕРСАЛЬНОСТЬ**: Одинаковая структура навигации для всех кабинетов
- **РОУТ**: `/home` с универсальным компонентом HomePageWrapper
- **КОМПОНЕНТЫ**: 4 типо-зависимых компонента: SellerHomePage, FulfillmentHomePage, WholesaleHomePage, LogistHomePage
#### 8.1.2 Раздел "Экономика"
**СТАТУС**: Реализовано в системе
**РАСПОЛОЖЕНИЕ**: Перед настройками в каждом кабинете
**СОДЕРЖАНИЕ**: Пустые разделы-заглушки с пометкой "будет добавлен позже"
**ПРАВИЛА**:
- **ОБЯЗАТЕЛЬНО**: Каждый кабинет имеет раздел "Экономика"
- **РОУТ**: `/economics` с универсальным компонентом EconomicsPageWrapper
- **КОМПОНЕНТЫ**: 4 типо-зависимых компонента экономики: SellerEconomicsPage, FulfillmentEconomicsPage, WholesaleEconomicsPage, LogistEconomicsPage
- **КНОПКА**: "Экономика" в sidebar навигации перед настройками
- **БЕЗОПАСНОСТЬ**: Проверки доступа и безопасности в экономических компонентах
#### 8.1.3 Общие разделы для всех кабинетов
**УНИВЕРСАЛЬНЫЕ РАЗДЕЛЫ** (доступны всем типам):
- 🏠 **Главная** - основная страница кабинета (реализовано)
- 🛒 **Маркет** - просмотр и заказ товаров
- 🤝 **Партнеры** - управление контрагентами
- 💬 **Мессенджер** - внутренняя связь
- 💰 **Экономика** - финансовая аналитика (реализовано)
- ⚙️ **Настройки** - профиль и конфигурация
**СПЕЦИАЛИЗИРОВАННЫЕ РАЗДЕЛЫ** (зависят от типа кабинета):
- Определяются в соответствующих разделах каждого кабинета
### 8.2 Правила sidebar навигации
#### 8.2.1 Структура навигации
**ОБЩИЙ ПРИНЦИП**:
- Условное отображение: `{user?.organization?.type === "TYPE" && (...)}`
- Адаптивность: сворачиваемый sidebar с `getSidebarMargin()`
- Состояния активности: подсветка текущего раздела
**ПОРЯДОК РАЗДЕЛОВ В SIDEBAR**:
1. 🏠 **Главная** (реализовано для всех)
2. **Специализированные разделы** (зависят от типа кабинета)
3. 🛒 **Маркет** (универсальный)
4. 🤝 **Партнеры** (универсальный)
5. 💬 **Мессенджер** (универсальный)
6. 💰 **Экономика** (универсальный, реализовано)
7. ⚙️ **Настройки** (универсальный)
8. **Выход** (универсальный)
#### 8.2.2 Типо-зависимая логика
**АДАПТИВНЫЙ РОУТИНГ**:
```typescript
// Пример: кнопка "Поставки" ведет на разные страницы
const handleSuppliesClick = () => {
switch (user?.organization?.type) {
case "FULFILLMENT":
router.push("/fulfillment-supplies");
break;
case "SELLER":
router.push("/supplies");
break;
case "WHOLESALE":
router.push("/supplies");
break;
case "LOGIST":
router.push("/logistics-orders");
break;
}
};
```
---
## 9. 🏠 КАБИНЕТ СЕЛЛЕРА (ДЕТАЛЬНЫЕ ПРАВИЛА)
> 📌 **ВИЗУАЛЬНЫЕ ПРАВИЛА**: См. [visual-design-rules.md - Кабинет селлера](#145-кабинет-селлера)
### 9.1 Структура раздела "Мои поставки"
#### **🏢 ПОСТАВКИ НА ФУЛФИЛМЕНТ**:
- **Товар** - поставка товаров для создания продуктов
- **Карточки** - поставка через WB API с рецептурой (результат: WildberriesSupply)
- **Поставщики** - заказ товаров у поставщиков с рецептурой (результат: SupplyOrder)
- **Расходники селлера** - поставка материалов для товаров селлера
#### **🛒 ПОСТАВКИ НА МАРКЕТПЛЕЙСЫ** _(планируется)_:
- **Wildberries** - прямые поставки на WB
- **Ozon** - прямые поставки на Ozon
### 9.2 UI структура создания поставки расходников селлера
#### **📄 Структура страницы создания поставки:**
**БЛОК 1: ПОСТАВЩИКИ** _(верхняя часть экрана)_
- **Отображение**: Карточки поставщиков из раздела "Партнеры"
- **Навигация**: Горизонтальный скролл (слева-направо) при превышении ширины экрана
- **Выбор**: Клик выделяет карточку поставщика
- **Результат**: Загружаются расходники выбранного поставщика в блок 2
**БЛОК 2: РАСХОДНИКИ** _(центральная часть)_
- **Содержание**: Расходники выбранного поставщика
- **Сортировка**: По цене, названию, категории
- **Фильтры**: По категории, ценовому диапазону
- **Карточка расходника**:
- Фото, название, цена, остаток, категория
- Количество в комплекте (если есть комплектность)
- Поле ввода количества (единицы или комплекты)
- Кнопки +/- для изменения количества
- **Действие**: Клик добавляет расходник в корзину
**БЛОК 3: КОРЗИНА** _(правая часть)_
- **Содержание корзины**:
- Количество видов расходников
- По каждому расходнику: название, количество, цена за единицу, сумма
- Общая сумма всех расходников
- **Управление**: Изменение количества, удаление позиций
- **Валидация**: Проверка остатков у поставщика
- **Настройки поставки**:
- Выбор фулфилмент-центра (dropdown из партнеров)
- Дата поставки (по умолчанию - дата создания, нельзя выбрать прошедшую)
- **Кнопка**: "Создать поставку"
### 9.3 Многоуровневые таблицы для отображения поставок
#### **📊 Структура многоуровневой таблицы:**
**ПЕРВЫЙ УРОВЕНЬ** _(основной список)_:
- Порядковый номер поставки (от большего к меньшему)
- Количество видов расходников селлера
- Стоимость всей поставки
- Количество категорий
- Статус поставки
- Кнопка раскрытия/сворачивания
**ВТОРОЙ УРОВЕНЬ** _(раскрывается по клику)_:
- Название расходника селлера
- Количество
- Цена за единицу
- Общая стоимость позиции
- Категория
- Поставщик
- **Режим**: Только просмотр (редактирование недоступно после создания)
**ПРАВИЛА ОТОБРАЖЕНИЯ**:
- По умолчанию таблица свернута, показан только первый уровень
- Клик по строке или кнопке раскрывает второй уровень
- Анимация раскрытия плавная (300ms)
- Визуальная индикация раскрытого состояния (поворот стрелки, изменение фона)
### 9.4 Правила кнопки "Создать поставку" в разделе "Мои поставки"
#### **9.4.1 Общие принципы**
- **КОНТЕКСТНОСТЬ**: Кнопка создания появляется только в активном табе
- **РАСПОЛОЖЕНИЕ**: Правая часть строки таба, на том же уровне что и название
- **СТИЛИСТИКА**: В том же стиле что и сами табы (соответствует уровню иерархии)
- **ФУНКЦИОНАЛЬНОСТЬ**: Кнопка ведет на страницу создания поставки соответствующего типа
#### **9.4.2 Размещение кнопок по табам**
**УРОВЕНЬ 2 (Подтабы фулфилмента):**
- **📦 Товар → Карточки**: Кнопка "Создать поставку" → `/supplies/create-cards`
- **📦 Товар → Поставщики**: Кнопка "Создать поставку" → `/supplies/create-suppliers`
- **🔧 Расходники селлера**: Кнопка "Создать поставку" → `/supplies/create-consumables`
**УРОВЕНЬ 2 (Подтабы маркетплейсов):**
- **🟣 Wildberries**: Кнопка "Создать поставку" → `/supplies/create-wildberries`
- **🔵 Ozon**: Кнопка "Создать поставку" → `/supplies/create-ozon`
#### **9.4.3 Стили кнопок**
**ДЛЯ УРОВНЯ 2 (h-9):**
```css
/* Размер и отступы */
h-9 px-3 py-1 ml-auto
/* Фон и границы */
bg-white/8 border border-white/20 hover:bg-white/12
/* Текст и иконки */
text-xs font-medium text-white/80 hover:text-white
/* Скругления */
rounded-lg
/* Переходы */
transition-all duration-150
```
**ДЛЯ УРОВНЯ 3 (h-8):**
```css
/* Размер и отступы */
h-8 px-2 py-1 ml-auto
/* Фон и границы */
bg-white/5 border border-white/15 hover:bg-white/8
/* Текст и иконки */
text-xs font-normal text-white/60 hover:text-white/80
/* Скругления */
rounded-md
/* Переходы */
transition-all duration-150
```
#### **9.2.4 Поведение кнопок**
- **ВИДИМОСТЬ**: Кнопка показывается только в активном табе
- **ИКОНКА**: `Plus` размером `h-3 w-3` слева от текста
- **ТЕКСТ**: "Создать" на мобильных, "Создать поставку" на десктопах
- **АДАПТИВНОСТЬ**: Скрытие текста на маленьких экранах (`hidden sm:inline`)
#### **9.2.5 Удаление старой кнопки**
- **УБРАТЬ**: Текущий dropdown "Создать поставку" из верхней части
- **ПРИЧИНА**: Заменяется контекстными кнопками в табах
- **СОХРАНИТЬ**: Стили и логику навигации, но адаптировать под новые роуты
### 9.3 Структура страницы "Мои поставки" - Трёхблочная архитектура
#### **9.3.1 Обязательная структура страницы**
**ПРИНЦИП**: Страница состоит из трёх визуально разделённых блоков
```
┌─────────────────────────────────────────┐
│ 1. БЛОК ТАБОВ (навигация) │
│ - Фиксированная высота │
│ - Glass-эффект │
│ - Иерархическая структура │
├─────────────────────────────────────────┤
│ 2. БЛОК СТАТИСТИКИ (метрики) │
│ - Контекстные данные │
│ - 4 карточки в ряд (desktop) │
│ - Динамическое обновление │
├─────────────────────────────────────────┤
│ 3. ОСНОВНОЙ БЛОК (контент) │
│ - Сохраняет весь функционал │
│ - Таблицы, фильтры, действия │
│ - Высота до низа sidebar │
└─────────────────────────────────────────┘
```
#### **9.3.2 Блок статистики - контекстные метрики**
**ПРАВИЛО**: Статистика меняется в зависимости от выбранных табов
**Для путей "Фулфилмент → Товар → Карточки/Поставщики":**
- Всего поставок
- Активных поставок
- Сумма активных поставок
- В пути
**Для пути "Фулфилмент → Расходники селлера":**
- Всего поставок
- Активных поставок
- Видов расходников
- Критические остатки
**Для путей "Маркетплейсы → Wildberries/Ozon":**
- Поставок на маркетплейс
- Товаров отправлено
- Возвраты за неделю
- Эффективность поставок
#### **9.3.3 Высота основного блока**
**ФОРМУЛА РАСЧЕТА**:
```css
height: calc(100vh - headerHeight - tabsHeight - statsHeight - margins)
```
**ПРАВИЛО ВЫРАВНИВАНИЯ**:
- Нижняя граница основного блока должна быть на одном уровне с нижней границей sidebar
- При изменении размера окна высота пересчитывается
- Внутренний скролл: `overflow-y-auto`
#### **9.3.4 Сохранение функционала**
**КРИТИЧЕСКИ ВАЖНО**: При добавлении блока статистики весь существующий функционал сохраняется:
- Таблицы с данными поставок
- Фильтры и сортировка
- Кнопки действий
- Детализация при клике
- Пагинация
- Поиск
**ЗАПРЕЩЕНО**:
- Удалять существующие компоненты
- Изменять логику работы таблиц
- Нарушать существующие API вызовы
### 9.4 Табы "Карточки" и "Поставщики" - объединённая логика
#### **9.4.1 Принцип единого типа предмета**
**КЛЮЧЕВОЕ ПРАВИЛО**: Табы "Карточки" и "Поставщики" - это два способа создания поставок одного типа предмета (ТОВАР)
**СПОСОБЫ СОЗДАНИЯ**:
- **Карточки** - импорт товаров через WB API с автоматическим созданием поставки
- **Поставщики** - прямой заказ товаров у поставщика с указанием рецептуры
**РЕЗУЛЬТАТ**: Оба способа создают `SupplyOrder` с товарами типа `PRODUCT`
#### **9.4.2 Общая статистика**
**ПРАВИЛО**: Блок статистики показывает ОДИНАКОВЫЕ данные для обоих табов
**МЕТРИКИ ДЛЯ ТАБОВ "КАРТОЧКИ" И "ПОСТАВЩИКИ"**:
- Всего поставок товаров (из всех источников)
- Активных поставок товаров (в работе)
- Сумма активных поставок товаров
- Товаров в пути (все способы доставки)
**ЗАПРЕЩЕНО**: Разделять статистику по способу создания
#### **9.4.3 Общий основной блок**
**СОДЕРЖИМОЕ**: Единая таблица всех поставок товаров
**ИСТОЧНИКИ ДАННЫХ**:
- Поставки, созданные через импорт карточек WB
- Поставки, созданные через заказ у поставщиков
- Все промежуточные и завершённые поставки
**РАЗЛИЧИЯ ТАБОВ**:
- Только кнопки создания ведут на разные страницы
- Таб "Карточки": `/supplies/create-cards`
- Таб "Поставщики": `/supplies/create-suppliers`
### 9.5 Создание поставки расходников селлера
#### **Структура страницы**:
**БЛОК 1: ПОСТАВЩИКИ** _(обязательный, верхняя часть)_:
- Карточки поставщиков из раздела "Партнеры"
- Горизонтальный скролл при превышении ширины
- Выбор только одного поставщика одновременно
**БЛОК 2: РАСХОДНИКИ** _(зависимый, центральная часть)_:
- Активен только после выбора поставщика
- Сортировка: цена, название, категория
- Фильтры: категория, ценовой диапазон
- Карточка с полем ввода количества и кнопками +/-
**БЛОК 3: КОРЗИНА** _(правая часть)_:
- **РАСПОЛОЖЕНИЕ**: Правая часть экрана
- **СОДЕРЖАНИЕ**:
- Счетчик видов расходников
- Детализация по каждому расходнику (название, количество, цена, сумма)
- Общая сумма всех расходников
- **УПРАВЛЕНИЕ**:
- Изменение количества (с валидацией остатков)
- Удаление позиций
- **ОБЯЗАТЕЛЬНЫЕ ПОЛЯ**:
- Выбор фулфилмент-центра (из партнеров)
- Дата поставки (не прошедшая, по умолчанию - текущая)
### 9.6 Многоуровневая таблица поставок
#### **ПЕРВЫЙ УРОВЕНЬ** _(основной список)_:
- **СОРТИРОВКА**: Номер поставки от большего к меньшему
- **ОБЯЗАТЕЛЬНЫЕ КОЛОНКИ**:
- Порядковый номер поставки
- Количество видов расходников
- Стоимость всей поставки
- Количество категорий
- Статус поставки
#### **ВТОРОЙ УРОВЕНЬ** _(детализация по клику)_:
- **АКТИВАЦИЯ**: По клику на строку первого уровня
- **СОДЕРЖАНИЕ**:
- Название расходника
- Количество
- Цена
- Категория
- Поставщик
- **ОГРАНИЧЕНИЯ**: Только просмотр, редактирование запрещено
---
## 10. 🏪 КАБИНЕТ ПОСТАВЩИКА
### 10.1 Основные возможности
**СОЗДАНИЕ КАРТОЧЕК**:
- **ТОВАР** - базовые товары поставщика
- **РАСХОДНИКИ** - материалы и вспомогательные товары
### 10.2 Обязательные поля карточки
**Базовые параметры**:
- Фото (система загрузки и управления изображениями)
- Название
- Автоматическая генерация артикула СФ
- Описание
- Количество предметов в единицах
- Количество комплектов (если применимо)
- Категория (28 предустановленных + специализированные для расходников)
- Бренд, Цвет, Размер/объем, Вес, Габариты, Материал
- Цена за единицу и за комплект
- Заказано, В пути, Остаток, Продано
### 10.3 Отображение информации в карточках
**Каждая карточка содержит**:
- Основное изображение
- Название и артикул СФ
- Цена за единицу/комплект
- Категория и статус активности
- Данные о движении: остаток, заказано, в пути, продано
- Индикаторы низких остатков
### 10.4 Статистика поставщика
**Блок статистики включает**:
- **ТОВАРЫ**: Общая статистика товаров поставщика
- **РАСХОДНИКИ**: Материалы и вспомогательные товары
- Классифицируются при заказе в зависимости от заказчика
- Общая статистика по всем расходникам
---
## 11. 🏭 КАБИНЕТ ФУЛФИЛМЕНТА
### 11.1 Общие характеристики кабинета фулфилмента
#### 11.1.1 Принципы доступа
- **МАКСИМАЛЬНЫЕ ПРАВА**: Фулфилмент имеет доступ ко ВСЕМ разделам системы
- **АДАПТИВНАЯ НАВИГАЦИЯ**: Sidebar изменяется в зависимости от `user.organization.type === "FULFILLMENT"`
- **ЭКСКЛЮЗИВНЫЕ КОМПОНЕНТЫ**: Услуги, Сотрудники, Статистика фулфилмента доступны ТОЛЬКО фулфилменту
- **СПЕЦИАЛЬНЫЙ РОУТИНГ**: При нажатии "Поставки" → `/fulfillment-supplies` (не `/supplies`)
#### 11.1.2 Архитектурные особенности
- **GraphQL проверки**: `skip: user?.organization?.type !== 'FULFILLMENT'` в запросах
- **Условное отображение**: `{user?.organization?.type === "FULFILLMENT" && (...)}`
- **Адаптивные отступы**: `getSidebarMargin()` для responsive design
- **Полинг данных**: Статистика обновляется каждую минуту (`pollInterval: 60000`)
### 11.2 Структура раздела склад фулфилмента
> 📌 **ВИЗУАЛЬНЫЕ ПРАВИЛА**: См. [visual-design-rules.md - Кабинет фулфилмента](#141-кабинет-фулфилмента)
#### 11.2.1 Структура склада по модулям (ОБЯЗАТЕЛЬНАЯ ПОСЛЕДОВАТЕЛЬНОСТЬ)
1. **📦 ПРОДУКТЫ** - готовые к отправке товары
2. **🛒 ТОВАРЫ** - базовые товары от поставщиков
- **"На складе"** - готовы к обработке
- **"В обработке"** - в процессе создания продукта
3. **❌ БРАК** - товары с дефектами, требуют утилизации
4. **↩️ ВОЗВРАТЫ С ПВЗ** - возвращенные товары, к обработке
5. **🎯 РАСХОДНИКИ СЕЛЛЕРОВ** - материалы для селлеров (тип `CONSUMABLE`, заказанные селлерами)
6. **⚙️ РАСХОДНИКИ ФУЛФИЛМЕНТА** - операционные материалы (тип `CONSUMABLE`, заказанные фулфилментом, КЛИКАБЕЛЬНЫЙ модуль)
#### 11.2.2 Система учета склада
**Дополнительные значения** (показатели движения):
- **ПРИБЫЛО** - количество поступивших на склад за период
- **УБЫЛО** - количество списанных со склада за период
**Основные значения** (текущие остатки):
- **ФОРМУЛА**: Основные значения = Предыдущие остатки + Прибыло - Убыло
- **ОБНОВЛЕНИЕ**: В реальном времени с изменениями за сутки
- **ИСТОЧНИК**: GraphQL query `GET_FULFILLMENT_WAREHOUSE_STATS`
#### 11.2.3 Структура данных склада (3-уровневая иерархия)
```
🔵 УРОВЕНЬ 1: МАГАЗИНЫ
├── ТехноМир (синий - blue-400/500)
├── Стиль и Комфорт (розовый - pink-400/500)
└── Зелёный Дом (изумрудный - emerald-400/500)
🟢 УРОВЕНЬ 2: ТОВАРЫ (зеленый - green-500)
🟠 УРОВЕНЬ 3: ВАРИАНТЫ ТОВАРОВ (оранжевый - orange-500)
```
**Цветовое кодирование**:
- Каждый уровень имеет цветной индикатор увеличивающегося размера
- Цветная левая граница с увеличивающимся отступом и толщиной
- Скроллбары в цвете уровня
- Контрастный цвет текста для читаемости
### 11.3 Движение товаров в фулфилменте
#### **Поступление товаров**:
- **ПОСТАВКИ**: От поставщиков через систему заказов
- **ВОЗВРАТЫ**: Товары, возвращенные с ПВЗ
- **ПЕРЕМЕЩЕНИЯ**: Между складами и магазинами
#### **Расход товаров**:
- **ОТГРУЗКА**: Товары отправлены селлерам
- **СПИСАНИЕ**: Брак, утрата, утилизация
- **ВОЗВРАТ**: Возврат поставщику
- **ИСПОЛЬЗОВАНИЕ**: Расходники для операций
### 11.4 Модуль "Расходники фулфилмента"
**ОСОБЕННОСТИ**:
- **ИНТЕРАКТИВНОСТЬ**: Кликабельный элемент в статистике
- **ФУНКЦИОНАЛЬНОСТЬ**: Полноценный раздел учёта
- **СОДЕРЖАНИЕ**: Управление расходниками фулфилмента
### 11.5 Поставки фулфилмента (`/fulfillment-supplies`)
#### 11.5.1 Структура: 2 основные вкладки
**A) 🛒 ПОСТАВКИ ТОВАРОВ**:
- **Детализированные товары ФФ** - планы и факты поставок с маршрутами
- **Товары ФФ** - общие поставки товаров от селлеров
- **Возвраты с ПВЗ** - обработка возвращенных товаров
**B) 🔧 ПОСТАВКИ РАСХОДНИКОВ**:
- **Заказы расходников** - управление заказами от селлеров
- **Расходники селлеров** - материалы для клиентов
- **Создание поставок** - формирование новых поставок расходников
#### 11.5.2 Workflow поставок товаров
**Этапы обработки**:
1. **Planned** - поставка запланирована
2. **In-transit** - товар в пути
3. **Delivered** - доставлен на склад
4. **Completed** - обработка завершена
### 11.6 Статистика фулфилмента (`/fulfillment-statistics`)
#### 11.6.1 Блоки аналитики (сворачиваемые)
**1. НАКОПЛЕННАЯ СТАТИСТИКА** (`allTime: true`):
- Обработано товаров (общий объем)
- Выявлено брака (всего единиц)
- Поставок получено
- Общий доход (за все время)
- Выполнено заказов (успешных отгрузок)
- Удовлетворенность клиентов (средний рейтинг)
**2. ОТГРУЗКА НА ПЛОЩАДКИ** (`marketplaces: true`):
- Отправлено на Wildberries
- Отправлено на Ozon
- Отправлено на другие площадки
**3. АНАЛИТИКА ПРОИЗВОДИТЕЛЬНОСТИ** (`performance: false`):
- Среднее время обработки (на единицу товара)
- Уровень брака (от общего объема)
- Уровень возвратов (возвраты с площадок)
- Удовлетворенность клиентов
### 11.7 Услуги фулфилмента (`/services`)
#### 11.7.1 Структура: 3 обязательные вкладки
**A) 🛠️ УСЛУГИ** (`defaultValue="services"`):
- **CRUD операции**: создание, редактирование, удаление услуг
- **Управление ценами** и описаниями
- **Загрузка изображений** услуг (`imageUrl`)
- **GraphQL**: `GET_MY_SERVICES`, `CREATE_SERVICE`, `UPDATE_SERVICE`, `DELETE_SERVICE`
**B) 🚚 ЛОГИСТИКА**:
- **Создание маршрутов доставки** (откуда → куда)
- **Тарификация**: цена до 1м³ и свыше 1м³
- **Группированные локации**:
- Мой фулфилмент (название организации)
- Рынки (предустановленные)
- Склады Wildberries
- Склады Ozon
- **GraphQL**: `GET_MY_LOGISTICS`, `CREATE_LOGISTICS`, `UPDATE_LOGISTICS`, `DELETE_LOGISTICS`
**C) 📦 РАСХОДНИКИ**:
- **Управление расходниками фулфилмента**
- **Интеграция с модулем "Услуги"** - селлеры могут использовать в услугах
- **Списание со складских остатков** при использовании
- **Стоимость включается** в стоимость услуги
### 11.8 Сотрудники фулфилмента (`/employees`)
#### 11.8.1 Структура: 2 основные вкладки
**A) 👥 СОТРУДНИКИ** (`defaultValue="combined"`):
**Управление персоналом**:
- **CRUD операции**: создание, редактирование, удаление сотрудников
- **Статусы сотрудников**: `ACTIVE`, `VACATION`, `SICK`, `FIRED`
- **Формы добавления**: Компактная (`showCompactForm`) / Полная форма
- **Поиск и фильтрация** по имени, должности, статусу
**Табель рабочего времени**:
- **Навигация по месяцам**: текущий год/месяц с кнопками ←/→
- **Отметки по дням**: статус дня и количество отработанных часов
- **GraphQL**: `GET_EMPLOYEE_SCHEDULE`, `UPDATE_EMPLOYEE_SCHEDULE`
**B) 📋 ОТЧЕТЫ** (`value="reports"`):
- **Сводные отчеты** по сотрудникам за период
- **Экспорт данных** табеля
- **Аналитика рабочего времени**
### 11.9 Блок детализации по магазинам
**НАЗНАЧЕНИЕ**: Распределение товаров по торговым точкам/магазинам
**ФУНКЦИИ**:
- **ОСТАТКИ ПО МАГАЗИНАМ**: Отображение количества товаров в каждом магазине
- **УПРАВЛЕНИЕ РАСПРЕДЕЛЕНИЕМ**: Перемещение товаров между точками
- **КОНТРОЛЬ ДВИЖЕНИЯ**: Отслеживание перемещений между складами и магазинами
- **АНАЛИТИКА**: Сравнение эффективности разных точек
- **ПЛАНИРОВАНИЕ**: Оптимизация распределения товаров
---
## 12. 🚚 КАБИНЕТ ЛОГИСТИКИ
### 12.1 Основные функции логистики
**РОЛЬ В СИСТЕМЕ**: Управление доставками и транспортировкой
**ОСНОВНЫЕ ФУНКЦИИ**:
- **ПОДТВЕРЖДЕНИЕ ДОСТАВКИ**: Подтверждение возможности доставки поставок
- **ТРАНСПОРТИРОВКА**: Организация и выполнение доставки товаров
- **КОНТРОЛЬ МАРШРУТОВ**: Управление логистическими маршрутами
- **ОТСЛЕЖИВАНИЕ**: Мониторинг грузов в пути
### 12.2 Workflow для логистики
#### **ЭТАП 1: Получение заявки**
1. Логистика получает уведомление о новой поставке
2. Заявка появляется в разделе "Заявки" кабинета логистики
3. Логист изучает детали поставки (объем, вес, маршрут)
#### **ЭТАП 2: Подтверждение доставки**
4. Логист нажимает кнопку "Одобрить"
5. Статус поставки меняется на `LOGISTICS_CONFIRMED`
6. Уведомления отправляются всем участникам
#### **ЭТАП 3: Забор товара**
7. Логист приезжает к поставщику за товаром
8. Поставщик отгружает товар логисту
9. Поставщик отмечает "Отправлено"
10. Статус меняется на `SHIPPED`, затем `IN_TRANSIT`
#### **ЭТАП 4: Доставка**
11. Логистика доставляет товар на фулфилмент-центр
12. В кабинете логистики нажимают "Доставлено"
13. Фулфилмент принимает товар и отмечает "Принято"
### 12.3 Система тарификации
**ПАРАМЕТРЫ ТАРИФИКАЦИИ**:
- **Тариф до 1м³** - базовая стоимость для малых грузов
- **Тариф свыше 1м³** - стоимость для крупных грузов
- **Маршруты доставки** - от точки отправления до точки назначения
- **Описание услуг** - дополнительные условия доставки
**РАСЧЕТ СТОИМОСТИ**:
- Автоматический расчет стоимости доставки по объему груза
- Отображение примерной стоимости при создании заказа
- Учет специфики маршрута и условий доставки
### 12.4 Управление заявками
**РАЗДЕЛЫ КАБИНЕТА ЛОГИСТИКИ**:
- **НОВЫЕ ЗАЯВКИ** - поступившие заявки на доставку
- **В РАБОТЕ** - принятые к исполнению заявки
- **ВЫПОЛНЕННЫЕ** - завершенные доставки
- **ОТКЛОНЕННЫЕ** - заявки, которые не могут быть выполнены
**ИНФОРМАЦИЯ О ЗАЯВКЕ**:
- Детали груза (объем, вес, габариты)
- Маршрут доставки (откуда - куда)
- Срочность доставки
- Особые требования к транспортировке
- Контактная информация участников
### 12.5 Правила логистики
**ОБЯЗАТЕЛЬНО**:
- Своевременное подтверждение заявок
- Соблюдение сроков доставки
- Бережная транспортировка товаров
- Уведомление о статусе доставки
**ЗАПРЕЩЕНО**:
- Принятие заявок без подтверждения возможности выполнения
- Нарушение сроков доставки без уведомления
- Повреждение товаров при транспортировке
---
## 13. 🤝 СИСТЕМА ПАРТНЕРСТВА И КОНТРАГЕНТОВ
### 13.1 Основы системы партнерства
**ПРИНЦИП РАБОТЫ**:
- Все типы кабинетов могут создавать партнерские отношения
- Партнерство реализовано через таблицы `Counterparty` и `CounterpartyRequest`
- Двустороннее партнерство: каждая организация видит другую в разделе "Партнеры"
**ТИПЫ ОРГАНИЗАЦИЙ-ПАРТНЕРОВ**:
- `WHOLESALE` - Поставщики товаров и расходников
- `FULFILLMENT` - Фулфилмент-центры
- `LOGIST` - Логистические компании
- `SELLER` - Селлеры (торговые организации)
### 13.2 Способы создания партнерства
#### **СПОСОБ 1: Через заказ в маркете (автоматическое партнерство)**
**WORKFLOW**:
1. Поставщик создает товар → товар попадает в глобальный маркет
2. Селлер/Фулфилмент находит товар в маркете
3. Создает заказ (`SupplyOrder`) → статус `PENDING`
4. Поставщик получает уведомление в разделе "Заявки"
5. Поставщик одобряет заявку → статус `SUPPLIER_APPROVED`
6. **Автоматически создается двустороннее партнерство**:
- Запись в `Counterparty` для заказчика (`organizationId``counterpartyId`)
- Обратная запись в `Counterparty` для поставщика
7. Обе организации видят друг друга в разделе "Партнеры"
#### **СПОСОБ 2: Через раздел "Партнеры" (заявочная система)**
**WORKFLOW**:
1. Любая организация идет в раздел "Партнеры"
2. Использует поиск для нахождения нужной организации
3. Отправляет заявку на партнерство → создается `CounterpartyRequest`:
- `senderId` - отправитель заявки
- `receiverId` - получатель заявки
- `status: PENDING`
- `message` - опциональное сообщение
4. Получатель видит заявку в разделе "Партнеры" → "Входящие заявки"
5. Получатель принимает заявку → статус меняется на `ACCEPTED`
6. **Автоматически создается двустороннее партнерство** (аналогично способу 1)
**СТАТУСЫ ЗАЯВОК**:
- `PENDING` - Ожидает рассмотрения
- `ACCEPTED` - Принята (партнерство создано)
- `REJECTED` - Отклонена
- `CANCELLED` - Отменена отправителем
### 13.3 Использование партнерства в системе
#### **В форме создания поставки товаров через поставщиков**
**ПРАВИЛО ОТОБРАЖЕНИЯ ПОСТАВЩИКОВ**:
- Показываются только партнеры с типом `WHOLESALE`
- Источник: таблица `Counterparty` where `counterparty.type === "WHOLESALE"`
- Фильтрация по `organizationId` текущего пользователя
**ЛОГИКА РАБОТЫ**:
1. Пользователь выбирает поставщика из dropdown партнеров-поставщиков
2. Загружается каталог товаров поставщика из `Product` таблицы
3. Товары фильтруются по `organizationId = поставщик.id`
4. Пользователь может добавлять товары в корзину и создавать заказ
#### **В других разделах системы**
**ВЫБОР ФУЛФИЛМЕНТ-ЦЕНТРА**:
- Партнеры с типом `FULFILLMENT`
- Используется при создании поставок расходников
**ВЫБОР ЛОГИСТИКИ**:
- Партнеры с типом `LOGIST`
- Используется при планировании доставок
**МЕССЕНДЖЕР**:
- Общение доступно только между партнерами
- Список чатов формируется из таблицы `Counterparty`
### 13.4 Технические правила
**СОЗДАНИЕ ЗАПИСЕЙ В COUNTERPARTY**:
```sql
-- При создании партнерства создаются ДВЕ записи
INSERT INTO counterparties (organizationId, counterpartyId) VALUES (org1_id, org2_id);
INSERT INTO counterparties (organizationId, counterpartyId) VALUES (org2_id, org1_id);
```
**ПРОВЕРКА ПАРТНЕРСТВА**:
```typescript
const isPartner = await prisma.counterparty.findFirst({
where: {
organizationId: currentOrgId,
counterpartyId: targetOrgId
}
});
```
**ПОЛУЧЕНИЕ ПАРТНЕРОВ ПО ТИПУ**:
```typescript
const wholesalePartners = await prisma.counterparty.findMany({
where: {
organizationId: currentOrgId,
counterparty: {
type: "WHOLESALE"
}
},
include: {
counterparty: true
}
});
```
### 13.5 Решение распространенных проблем
#### **ПРОБЛЕМА: GraphQL запрос не возвращает данные партнеров**
**Симптомы**:
- В консоли браузера: `All counterparties: 0`, `All counterparties data: []`
- GraphQL запрос отправляется успешно, но возвращает пустой массив
- В базе данных партнеры существуют
**Возможные причины и решения**:
1. **НЕПРАВИЛЬНОЕ ИМЯ ПОЛЯ В КОДЕ** (наиболее частая ошибка):
```typescript
// ❌ НЕПРАВИЛЬНО
const allCounterparties = counterpartiesData?.getMyCounterparties || [];
// ✅ ПРАВИЛЬНО
const allCounterparties = counterpartiesData?.myCounterparties || [];
```
**Объяснение**: В GraphQL схеме поле называется `myCounterparties`, а не `getMyCounterparties`
2. **НЕСООТВЕТСТВИЕ ID ПОЛЬЗОВАТЕЛЯ**:
- Проверить что пользователь авторизован под правильным аккаунтом
- Убедиться что `context.user.id` соответствует ожидаемому пользователю
3. **ПРОБЛЕМЫ С КЕШИРОВАНИЕМ APOLLO CLIENT**:
```typescript
const { data, loading, error } = useQuery(GET_MY_COUNTERPARTIES, {
fetchPolicy: 'network-only', // Обходим кеш
errorPolicy: 'all'
});
```
4. **ОТСУТСТВИЕ ЛОГИРОВАНИЯ В РЕЗОЛВЕРЕ**:
- Добавить console.log в GraphQL резолвер для отладки
- Проверить что резолвер вызывается
**Чек-лист для диагностики**:
- [ ] Проверить правильность имени поля в коде (`myCounterparties`)
- [ ] Убедиться что пользователь авторизован
- [ ] Проверить логи сервера на вызов резолвера
- [ ] Добавить отладочное логирование в браузере
- [ ] Проверить данные в базе через Prisma Studio
- [ ] Использовать `fetchPolicy: 'network-only'` для обхода кеша
---
## 14. 🌐 ИНТЕГРАЦИИ С СИСТЕМОЙ
### 14.1 Глобальная интеграция
- **МАРКЕТ**: Товары поставщиков отображаются в глобальном маркете
- **СИНХРОНИЗАЦИЯ**: Данные склада синхронизируются с модулем аналитики
- **УВЕДОМЛЕНИЯ**: Единая система через встроенный мессенджер
### 14.2 Интеграция с маркетплейсами
- **WILDBERRIES**: Обязательная проверка активности API ключа
- **СИНХРОНИЗАЦИЯ**: Регулярное обновление данных из внешних источников
- **ЛОКАЛЬНЫЕ КОПИИ**: Сохранение данных для офлайн работы
### 14.3 Интеграция с модулем "Услуги"
**РАСХОДНИКИ ФУЛФИЛМЕНТА В УСЛУГАХ**:
- Расходники фулфилмента - собственность фулфилмента (куплены у поставщиков)
- Фулфилмент создает заявки-поставки для покупки расходников у поставщиков
- Селлеры могут использовать расходники фулфилмента в разделе "Услуги / Расходники"
- Для создания продукта из товара
- Расходники списываются с остатков фулфилмента
- Стоимость включается в стоимость услуги
**WORKFLOW ИСПОЛЬЗОВАНИЯ**:
1. Селлер выбирает услугу "Создание продукта"
2. Указывает базовый товар
3. Выбирает необходимые расходники фулфилмента
4. Фулфилмент обрабатывает заказ и создает продукт
5. Расходники списываются, создается готовый продукт
---
## 15. 📊 СТАТИСТИКА И АНАЛИТИКА
### 15.1 Структура статистики по кабинетам
#### **В КАБИНЕТЕ ПОСТАВЩИКА**:
- **ТОВАРЫ**: Общая статистика товаров поставщика
- **РАСХОДНИКИ**: Материалы и вспомогательные товары (классифицируются при заказе)
#### **В КАБИНЕТЕ ФУЛФИЛМЕНТА**:
- **ТОВАРЫ**: Базовые товары от поставщиков (принятые на склад)
- **ПРОДУКТЫ**: Отдельный блок готовой продукции
- **БРАК**: Статистика потерь и списаний
- **РАСХОДНИКИ ФУЛФИЛМЕНТА**: Операционные материалы фулфилмента
- **РАСХОДНИКИ СЕЛЛЕРОВ**: Материалы для товаров селлеров
### 15.2 Ключевые метрики
**ОБЩИЕ ПОКАЗАТЕЛИ**:
- Общие остатки, заказано, в пути, остаток, продано
- Подсветка предметов с остатками ниже критического уровня
**АКТУАЛИЗАЦИЯ ДАННЫХ**:
- При изменении количества в карточке данные актуализируются во всей системе
- Статистика обновляется в реальном времени
- Отслеживание изменений для аналитики
---
## 16. 📱 ПРАВИЛА UI/UX И ИНТЕРФЕЙСА
### 16.1 Отзывчивость интерфейса
- **ОБЯЗАТЕЛЬНО**: Интерфейс должен работать на всех устройствах
- **ПРАВИЛО**: Адаптивная сетка для карточек товаров
- **ФУНКЦИЯ**: Оптимизация для мобильных устройств
- **ТРЕБОВАНИЕ**: Корректное отображение на экранах от 320px до 4K
### 16.2 Обратная связь пользователю
- **ОБЯЗАТЕЛЬНО**: Уведомления об успешных/неуспешных операциях
- **ПРАВИЛО**: Индикаторы загрузки для длительных операций
- **ФУНКЦИЯ**: Подтверждение критических действий (удаление, деактивация)
- **UX**: Понятные сообщения об ошибках с предложением решения
### 16.3 Правила обработки ошибок
- **ОБЯЗАТЕЛЬНО**: Логирование всех ошибок с детальной информацией
- **ПРАВИЛО**: Понятные сообщения об ошибках для пользователя
- **ФУНКЦИЯ**: Автоматическое восстановление после сбоев
- **МОНИТОРИНГ**: Отслеживание критических ошибок в реальном времени
### 16.4 Производительность
- **ПРАВИЛО**: Пагинация для больших списков товаров
- **ФУНКЦИЯ**: Ленивая загрузка изображений
- **ОПТИМИЗАЦИЯ**: Кэширование часто запрашиваемых данных
- **ПРОИЗВОДИТЕЛЬНОСТЬ**: Время загрузки страницы не более 3 секунд
---
## 17. ⚠️ КРИТИЧЕСКИЕ ЗАПРЕТЫ
### 17.1 НИКОГДА НЕ ДЕЛАТЬ:
1. ❌ Удалять предметы с существующими заказами
2. ❌ Изменять статусы заказов без уведомлений
3. ❌ Обходить проверки остатков предметов
4. ❌ Давать доступ к чужим данным
5. ❌ Игнорировать ошибки валидации
6. ❌ Сохранять пароли в открытом виде
7. ❌ Пропускать логирование критических операций
8. ❌ Блокировать интерфейс без индикации загрузки
9. ❌ Создавать брак или продукт без связи с родительским товаром
10. ❌ Создавать отдельные типы расходников (только общий тип "РАСХОДНИКИ")
11. ❌ Разрешать заказ брака
12. ❌ Нарушать иерархию типов предметов
13. ❌ Пропускать промежуточные статусы в workflow
14. ❌ Нарушать обязательную последовательность модулей в статистике фулфилмента
15. ❌ **Использовать неправильные имена полей GraphQL** (`getMyCounterparties` вместо `myCounterparties`)
16. ❌ **Использовать GET_SUPPLY_SUPPLIERS для отображения поставщиков в формах** (только партнеры WHOLESALE)
17. ❌ **Создавать интерфейсы TypeScript не соответствующие schema.prisma** (`sku`/`stock` вместо `article`/`quantity`)
18. ❌ **Использовать общие запросы вместо специализированных** (`GET_ALL_PRODUCTS` вместо `GET_ORGANIZATION_PRODUCTS` для конкретного поставщика)
19. ❌ **Показывать расходники в формах создания поставок товаров** (строгая типизация `PRODUCT`/`CONSUMABLE`)
20. ❌ **Фильтровать предметы по типу на фронтенде** (фильтрация должна быть в GraphQL резолвере)
21. ❌ **ИСПОЛЬЗОВАТЬ МОКОВЫЕ ДАННЫЕ БЕЗ РАЗРЕШЕНИЯ** - все компоненты ОБЯЗАТЕЛЬНО должны использовать реальные GraphQL запросы. Моковые данные можно добавлять ТОЛЬКО с явного разрешения пользователя
### 17.2 ОБЯЗАТЕЛЬНЫЕ ПРАВИЛА:
1. ✅ Проверка остатков перед добавлением в корзину
2. ✅ Валидация всех числовых значений (цена > 0, вес > 0)
3. ✅ Автоматическая генерация уникальных артикулов СФ
4. ✅ Логирование всех изменений статусов
5. ✅ Уведомления всех участников при изменении статусов
6. ✅ Обязательная типизация всех предметов
7. ✅ Связь производных типов с родительскими предметами
8. ✅ Проверка доступности товаров перед заказом
9. ✅ Соблюдение жизненного цикла статусов поставок
10. ✅ Фиксация план/факт в процессе создания продукта
---
## 18. 🛠️ GRAPHQL И TYPESCRIPT ПРАВИЛА
### 18.1 Правила именования полей
**ВАЖНО**: Имена полей в GraphQL запросах должны точно соответствовать схеме!
```typescript
// ✅ ПРАВИЛЬНО - соответствует схеме
export const GET_MY_COUNTERPARTIES = gql`
query GetMyCounterparties {
myCounterparties { // <- имя поля в схеме
id
name
type
}
}
`;
// Использование в компоненте
const allCounterparties = counterpartiesData?.myCounterparties || [];
```
```typescript
// ❌ НЕПРАВИЛЬНО - не соответствует схеме
const allCounterparties = counterpartiesData?.getMyCounterparties || []; // Ошибка!
```
### 18.2 Правила отладки GraphQL
**При проблемах с GraphQL запросами следовать чек-листу**:
1. **Проверить соответствие имен полей схеме**
2. **Добавить fetchPolicy: 'network-only' для обхода кеша**
3. **Логировать данные в браузере и сервере**
4. **Проверить авторизацию пользователя**
5. **Убедиться что резолвер вызывается**
### 18.3 Обязательные поля для отладки
```typescript
const { data, loading, error } = useQuery(QUERY_NAME, {
fetchPolicy: 'network-only', // Обходим кеш при отладке
errorPolicy: 'all' // Показываем все ошибки
});
// Логирование для отладки
console.log("Data:", data);
console.log("Loading:", loading);
console.log("Error:", error);
```
### 18.4 TypeScript Rules
#### **Интерфейсы данных**
**Поля интерфейсов должны соответствовать GraphQL схеме**:
```typescript
// ✅ ПРАВИЛЬНО - соответствует schema.prisma
interface GoodsProduct {
id: string;
name: string;
article: string; // <- соответствует полю в schema
quantity?: number; // <- соответствует полю в schema
organization: {
id: string;
name: string;
};
}
```
```typescript
// ❌ НЕПРАВИЛЬНО - не соответствует schema
interface GoodsProduct {
sku: string; // <- в schema поле называется 'article'
stock?: number; // <- в schema поле называется 'quantity'
}
```
### 18.5 Система партнерства в GraphQL
**ПРАВИЛА ИСПОЛЬЗОВАНИЯ ПАРТНЕРСТВА**:
- Поставщики в формах берутся только из партнеров с типом `WHOLESALE`
- Используется запрос `GET_MY_COUNTERPARTIES` с фильтрацией по типу
- НЕ используется `GET_SUPPLY_SUPPLIERS` для отображения поставщиков в формах
- Партнерство создается двумя способами: через заказ в маркете или через раздел "Партнеры"
- Двусторонние записи в таблице `Counterparty` при создании партнерства
### 18.6 Архитектурные принципы GraphQL
- **Создавать специализированные резолверы** для каждого контекста использования
- **Использовать параметризованные запросы** (`organizationId`, `type`, `search`) вместо фильтрации на фронтенде
- **Добавлять подробное логирование** в резолверы для отладки (входные параметры, результаты фильтрации)
- **Типы запросов должны отражать бизнес-логику**: `organizationProducts` для товаров конкретной организации
- **Значения по умолчанию в резолверах** для критических параметров (`type: args.type || "PRODUCT"`)
- **Валидация обязательных параметров** на уровне схемы (`organizationId: ID!`)
- **Кеширование обходить при проблемах** через `fetchPolicy: 'network-only'`
---
## 19. 🔧 АРХИТЕКТУРНЫЕ ПРИНЦИПЫ
### 19.1 Стандарты разработки
- **ОБЯЗАТЕЛЬНО**: Покрытие тестами критической функциональности
- **ПРАВИЛО**: Следование принципам SOLID
- **ФУНКЦИЯ**: Автоматическое тестирование при развертывании
- **КАЧЕСТВО**: Минимальное покрытие тестами 80%
### 19.2 Документация
- **ОБЯЗАТЕЛЬНО**: Документирование всех API методов
- **ПРАВИЛО**: Комментарии к сложной бизнес-логике
- **ФУНКЦИЯ**: Автоматическая генерация документации
- **СТАНДАРТ**: Актуальная техническая документация
### 19.3 Масштабируемость
- **АРХИТЕКТУРА**: Модульная структура для легкого расширения
- **ПРАВИЛО**: Использование индексов для быстрого поиска
- **ФУНКЦИЯ**: Горизонтальное масштабирование при росте нагрузки
- **ПЛАНИРОВАНИЕ**: Готовность к увеличению нагрузки в 10 раз
### 19.4 Безопасность данных
- **ОБЯЗАТЕЛЬНО**: Шифрование чувствительных данных
- **ПРАВИЛО**: Аудит всех действий пользователей
- **ФУНКЦИЯ**: Контроль доступа на уровне API
- **БЕЗОПАСНОСТЬ**: Двухфакторная аутентификация для критических операций
---
## 20. 🎯 ПРАВИЛА КАЧЕСТВА КОДА
### 20.1 Проверки и валидация
**ОБЯЗАТЕЛЬНЫЕ ПРОВЕРКИ**:
- ✅ Типизация предметов: каждый предмет имеет один из типов: ТОВАР (`PRODUCT`), РАСХОДНИКИ (`CONSUMABLE`), БРАК и ПРОДУКТ (планируются)
- ✅ БРАК и ПРОДУКТ имеют обязательную связь с родительским товаром (parentId)
- ✅ Расходники создаются как универсальный тип, классифицируются при заказе
- ✅ **В формах создания поставок товаров показываются ТОЛЬКО предметы типа ТОВАР** (`PRODUCT`)
- ✅ **В формах создания поставок расходников показываются ТОЛЬКО предметы типа РАСХОДНИКИ** (`CONSUMABLE`)
- ✅ **Фильтрация по типу предмета происходит на уровне GraphQL резолвера**, не на фронтенде
### 20.2 Workflow статусов
- ✅ Соблюдена последовательность: PENDING → SUPPLIER_APPROVED → CONFIRMED → LOGISTICS_CONFIRMED → SHIPPED → IN_TRANSIT → DELIVERED
- ✅ Нет пропуска промежуточных статусов
- ✅ Каждое изменение статуса сопровождается уведомлением
### 20.3 Правила доступа
- ✅ Поставщик НЕ может добавлять собственные товары в корзину
- ✅ Заказ брака ЗАПРЕЩЕН
- ✅ Только активные предметы отображаются в маркете
- ✅ Проверка остатков перед добавлением в корзину
---
## 21. 🔍 ДИАГНОСТИКА И РЕШЕНИЕ ПРОБЛЕМ
### 21.1 Правило уточнений
**КРИТИЧЕСКИ ВАЖНО**: Если я не уверен в выполнении задачи или вижу противоречия в правилах - ОБЯЗАТЕЛЬНО уточнить у пользователя!
### 21.2 КОГДА УТОЧНЯТЬ:
- [ ] Недостаточно информации для правильного выполнения
- [ ] Вижу противоречия между правилами
- [ ] Задача может нарушить критические правила
- [ ] Неясно как применить правило в конкретной ситуации
- [ ] Есть сомнения в интерпретации требований
### 21.3 КАК УТОЧНЯТЬ:
1. Четко сформулировать что именно неясно
2. Указать какие правила/требования конфликтуют
3. Предложить варианты решения если возможно
4. Запросить конкретные уточнения
**❌ НИКОГДА не делать предположений если есть сомнения!**
---
## 22. 📋 КАТЕГОРИИ ТОВАРОВ И РАСХОДНИКОВ
### 22.1 Полный список 28 универсальных категорий товаров
1. Одежда и обувь
2. Косметика и парфюмерия
3. Дом и сад
4. Детские товары
5. Спорт и отдых
6. Электроника
7. Книги
8. Здоровье
9. Автотовары
10. Строительство и ремонт
11. Продукты питания
12. Зоотовары
13. Дача, сад и огород
14. Канцелярские товары
15. Хобби и творчество
16. Украшения и аксессуары
17. Сумки и чемоданы
18. Техника для дома
19. Музыкальные инструменты
20. Игры и игрушки
21. Мебель
22. Товары для красоты
23. Бытовая химия
24. Товары для путешествий
25. Медицинские товары
26. Религиозные товары
27. Антиквариат и коллекционирование
28. Прочие товары
### 22.2 12 специализированных категорий расходников
#### 🎁 **1. УПАКОВКА И ЗАЩИТА**
- Коробки (различных размеров)
- Пакеты (полиэтиленовые, бумажные, фирменные)
- Пузырчатая пленка, воздушные подушки
- Стрейч-пленка, гофрокартон
- Паллетная пленка, защитные уголки
#### 🏷️ **2. МАРКИРОВКА И ИДЕНТИФИКАЦИЯ**
- Этикетки (адресные, штрих-код, QR-код)
- Бирки (ценники, размерники)
- Стикеры и наклейки
- Маркеры и ручки
- Штампы и печати, термоэтикетки
#### 🔧 **3. КРЕПЕЖ И СОЕДИНЕНИЕ**
- Скотч (прозрачный, цветной, армированный)
- Клей и клеевые составы
- Стяжки пластиковые
- Степлер и скобы
- Веревки и шнуры, стрейч-лента
#### 📄 **4. ДОКУМЕНТООБОРОТ И ВКЛАДЫШИ**
- Накладные и сопроводительные документы
- Инструкции по эксплуатации
- Гарантийные талоны
- Рекламные буклеты, визитки и флаеры
- Благодарственные письма, купоны и промокоды
#### 🧼 **5. ГИГИЕНА И БЕЗОПАСНОСТЬ**
- Перчатки (латексные, нитриловые)
- Маски и респираторы
- Антисептики и дезинфекторы
- Салфетки и тряпки
- Фартуки и халаты, бахилы
#### 🛠️ **6. ИНСТРУМЕНТЫ И ПРИСПОСОБЛЕНИЯ**
- Ножи и резаки, ножницы
- Линейки и рулетки
- Упаковочные машины (ленточные)
- Дозаторы скотча
- Пистолеты для термоклея
- Весы и мерная тара
#### 🎨 **7. БРЕНДИНГ И ДИЗАЙН**
- Фирменные пакеты с логотипом
- Брендированные коробки
- Цветная упаковочная бумага
- Ленты и банты
- Наклейки с логотипом компании
- Подарочная упаковка
#### ⚡ **8. СПЕЦИАЛИЗИРОВАННЫЕ МАТЕРИАЛЫ**
- Антистатические пакеты
- Влагопоглотители
- Температурные индикаторы
- Хрупкие наклейки
- Пломбы и пломбировочные материалы
- Защита от краж (магнитные датчики)
#### 🏪 **9. ТОРГОВОЕ ОБОРУДОВАНИЕ**
- Манекены и вешалки
- Ценникодержатели
- Подставки и стойки
- Корзины и тележки
- Зеркала примерочные
- Освещение витрин
#### 🚚 **10. ЛОГИСТИКА И СКЛАДИРОВАНИЕ**
- Паллеты и поддоны
- Контейнеры и ящики
- Стеллажные системы
- Погрузочные ремни
- Защитные чехлы
- Адресные ярлыки для груза
#### 💻 **11. ТЕХНИЧЕСКИЕ РАСХОДНИКИ**
- Картриджи для принтеров
- Термоголовки, красящие ленты
- Батарейки для сканеров
- Чистящие средства для техники
- Запчасти для упаковочного оборудования
#### 🎪 **12. СЕЗОННЫЕ И ПРАЗДНИЧНЫЕ**
- Новогодняя упаковка
- Подарочные мешки
- Праздничные ленты
- Тематические наклейки
- Открытки и поздравления
- Сезонная упаковочная бумага
**ПРИМЕЧАНИЕ**: Данные категории являются рекомендательными и могут быть адаптированы под специфику конкретного поставщика расходников.
---
## 23. 🎖️ ПРИОРИТЕТЫ РАЗРАБОТКИ
### 23.1 ВЫСОКИЙ ПРИОРИТЕТ:
1. 🔴 Безопасность и контроль доступа
2. 🔴 Целостность данных и валидация
3. 🔴 Корректность статусов поставок
4. 🔴 Уведомления участников процесса
5. 🔴 Правильная типизация предметов
6. 🔴 Связи между товарами и производными типами
### 23.2 СРЕДНИЙ ПРИОРИТЕТ:
1. 🟡 Производительность и оптимизация
2. 🟡 Пользовательский опыт
3. 🟡 Аналитика и отчетность
4. 🟡 Интеграции с внешними системами
5. 🟡 Workflow для брака и продуктов
6. 🟡 Разделение расходников по типам
### 23.3 НИЗКИЙ ПРИОРИТЕТ:
1. 🟢 Дополнительные фильтры
2. 🟢 Косметические улучшения
3. 🟢 Экспериментальные функции
4. 🟢 Расширенная кастомизация
---
## 🚨 КРИТИЧЕСКИЕ СИТУАЦИИ И EDGE CASES
### 🔴 Отмена заказов на разных этапах workflow
**PENDING → Отмена разрешена**
- Действие: Удаление заказа без последствий
- Уведомления: Поставщику о отмене
- Влияние на статистику: Нет
**SUPPLIER_APPROVED → Отмена с согласия поставщика**
- Действие: Требуется подтверждение поставщика
- Штрафы: Возможны согласно договору
- Восстановление: Товары возвращаются в доступные остатки
**CONFIRMED/LOGISTICS_CONFIRMED → Отмена критическая**
- Действие: Требуется согласие всех участников
- Штрафы: Логистические расходы
- Альтернатива: Изменение адреса доставки
**SHIPPED/IN_TRANSIT → Отмена невозможна**
- Действие: Только возврат после получения
- Процедура: Через модуль "Возвраты с ПВЗ"
### 🔄 Частичная доставка товаров
**Сценарий**: Поставщик доставил 80 из 100 заказанных единиц
**Алгоритм обработки**:
1. Фулфилмент фиксирует фактическое количество
2. Система создает два отдельных документа:
- DELIVERED (80 единиц) - обрабатывается обычным порядком
- PARTIAL_DELIVERED (20 единиц) - остается в статусе ожидания
3. Селлер получает уведомление о частичной поставке
4. Принятие решения: ждать остаток или отменить недопоставку
### 📊 Превышение лимитов остатков
**Проблема**: Попытка заказать больше чем есть у поставщика
**Техническая реализация**:
```typescript
if (requestedQuantity > availableStock) {
throw new GraphQLError(`Недостаточно товара. Доступно: ${availableStock}, запрошено: ${requestedQuantity}`);
}
```
**UX решение**: Real-time валидация в формах заказа
### 🔍 Дубликаты артикулов
**Сценарий**: Поставщик пытается создать товар с существующим артикулом
**Проверка на уровне БД**:
```sql
UNIQUE INDEX ON products(article, organization_id)
```
**Обработка**: Автоматическое добавление суффикса или предложение изменить артикул
---
## 24. 📎 ТЕХНИЧЕСКИЕ ПРИЛОЖЕНИЯ
### Приложение A: GraphQL запросы фулфилмента
```typescript
// Основные запросы
GET_MY_SERVICES; // Услуги фулфилмента
GET_MY_LOGISTICS; // Логистические маршруты
GET_MY_EMPLOYEES; // Сотрудники организации
GET_FULFILLMENT_WAREHOUSE_STATS; // Статистика склада
GET_WAREHOUSE_PRODUCTS; // Товары на складе
GET_MY_FULFILLMENT_SUPPLIES; // Расходники фулфилмента
GET_EMPLOYEE_SCHEDULE; // Табель рабочего времени
// Мутации
CREATE_SERVICE, UPDATE_SERVICE, DELETE_SERVICE;
CREATE_LOGISTICS, UPDATE_LOGISTICS, DELETE_LOGISTICS;
CREATE_EMPLOYEE, UPDATE_EMPLOYEE, DELETE_EMPLOYEE;
UPDATE_EMPLOYEE_SCHEDULE; // Обновление табеля
```
### Приложение B: Компоненты фулфилмента
```typescript
// Основные dashboard компоненты
FulfillmentWarehouseDashboard; // Склад фулфилмента
FulfillmentStatisticsDashboard; // Статистика
ServicesDashboard; // Услуги (3 вкладки)
EmployeesDashboard; // Сотрудники
SuppliesDashboard; // Поставки фулфилмента
// Специализированные компоненты
ServicesTab, LogisticsTab, SuppliesTab; // Вкладки услуг
EmployeeInlineForm, EmployeeEditInlineForm; // Формы сотрудников
FulfillmentSuppliesTab, FulfillmentConsumablesOrdersTab; // Поставки
```
### Приложение C: Специальный роутинг для типов организаций
```typescript
const handleSuppliesClick = () => {
switch (user?.organization?.type) {
case "FULFILLMENT":
router.push("/fulfillment-supplies"); // Специальный роут
break;
case "SELLER":
router.push("/supplies");
break;
case "WHOLESALE":
router.push("/wholesale-supplies");
break;
case "LOGIST":
router.push("/logist-supplies");
break;
}
};
```
---
_Эта база знаний создана путем объединения rules-unified.md (v3.0) и fulfillment-cabinet-rules.md (v1.0) с устранением всех несоответствий и добавлением критически важных улучшений: быстрый справочник, глоссарий терминов, детальные алгоритмы процессов, edge cases._
_Версия: 9.1_
ата создания: 2025_
_Статус: ЕДИНЫЙ ИСТОЧНИК ИСТИНЫ - ГОТОВ К РАЗРАБОТКЕ_
### 🚀 УЛУЧШЕНИЯ v6.0:
- Быстрый справочник критических правил
- 🔤 Полный глоссарий терминов с определениями
- 🎯 Навигация по ролям (разработчики, аналитики, менеджеры)
- 🔄 Детальный алгоритм создания продукта с временными рамками
- 🚨 Раздел критических ситуаций и Edge Cases
- 📌 Связующие блоки между разделами
- 📊 Таблицы SLA и временных рамок
### 🔧 ИСПРАВЛЕНИЯ v6.1:
- Устранено противоречие в моменте создания БРАКА
- Исправлена логическая цепочка: рецептура задается селлером ДО процесса
- Реалистичные временные рамки SLA (рабочие дни вместо часов)
- Унифицирована классификация расходников (по назначению при использовании)
- Согласованы все алгоритмы и процессы между разделами
### 🔧 ОБНОВЛЕНИЯ v6.3:
- **ДОБАВЛЕН КРИТИЧЕСКИЙ ЗАПРЕТ**: Использование моковых данных в продакшене
- **ОБНОВЛЕН ЧЕКЛИСТ**: Добавлена проверка на отсутствие mock данных
- **РЕАЛИЗАЦИЯ**: Полная очистка моковых данных из раздела "Мои поставки" селлера
### 🎨 ИНТЕГРАЦИЯ v6.2:
- Синхронизация с visual-design-rules.md v1.1
- Добавлены визуальные правила для 8 статусов поставок
- Создана цветовая система для 6 модулей фулфилмента
- Визуальный workflow процесса создания продукта
- Перекрестные ссылки между техническими и визуальными правилами
- Покрытие визуальными решениями увеличено с 40% до 85%
### 🚀 КОНСОЛИДАЦИЯ v7.0:
- Интеграция development-checklist.md и CLAUDE.md
- Удаление дублирующих файлов
- Создание единого источника истины
### 🔧 ПОЛНАЯ ИНТЕГРАЦИЯ v8.0:
- Интеграция work-protocols.md (детальные протоколы по сложности)
- Интеграция violation-prevention-protocol.md (СТОП-сигналы и триггеры)
- Интеграция self-validation.md (расширенная система самопроверки)
- Удаление всех дублирующих файлов протоколов
### 🎯 ОПТИМИЗАЦИЯ UI/UX v8.1:
- Добавлен ТРИГГЕР #3 для автоматической активации visual-design-rules.md
- Интегрирован специальный UI/UX протокол в чеклист
- Создана система перекрестных ссылок с visual-design-rules.md
- visual-design-rules.md остается отдельным специализированным файлом
### 📊 ИНТЕГРАЦИЯ DESCRIPTION v9.0:
- Добавлена UI структура создания поставки расходников (3 блока)
- Интегрирована концепция многоуровневых таблиц
- Добавлен механизм учета ПЛАН/ФАКТ в процессе создания продукта
- Расширена детализация рецептуры продукта
- Добавлена опция места хранения готовых продуктов
### 🔧 УТОЧНЕНИЯ ЛОГИКИ v9.1:
- Уточнен статус брака: НЕ РЕАЛИЗОВАНО (еще не дошли до этого этапа)
- Добавлены четкие правила создания предметов по ролям
- Добавлен экономический учет расходников фулфилмента для селлера
- Обновлен механизм ПЛАН/ФАКТ: потери вместо брака при пересчете
- Добавлена заметка о будущей детализации статусов товаров