ERP Platform Docs

Баг

время чтения ~4 мин.

BUG-025: Склад не создаётся автоматически при создании ТТ

Описание

Когда пользователь создаёт новую торговую точку, в Warehouse Service не создаётся связанный склад (warehouses). В результате любая операция склада (приёмка, списание, инвентаризация) для этой ТТ падает с ошибкой «Склад не найден для этой ТТ».

В админке нет UI для ручного создания склада (нет страницы /warehouses/new, нет кнопки «Создать склад» на карточке ТТ). Единственный способ сейчас — дёрнуть POST /api/v1/warehouses?store_id=...&name=... напрямую или вставить запись в warehouse_db.warehouses через SQL.

Это полностью блокирует работу со складом для любой новой ТТ.

Шаги воспроизведения

  1. Создать новую франшизу (или использовать существующую без ТТ)
  2. Создать новую торговую точку (POST /api/v1/admin/stores)
  3. Открыть раздел «Склад → Приёмки» → нажать «Создать приёмку»
  4. Выбрать созданную ТТ

Ожидаемое поведение

Основной путь: при создании ТТ автоматически создаётся склад с именем по умолчанию (например, «Склад {store_name}»). Выполняется либо через Kafka-событие store.created, на которое подписан Warehouse Service, либо синхронным внутренним вызовом из Store Service → Warehouse Service.

Дополнительно: на карточке ТТ в админке — блок «Склад» с именем склада и возможностью переименовать.

Фактическое поведение

  • При создании ТТ склад не создаётся
  • Запрос на создание приёмки возвращает ошибку «Склад не найден для этой ТТ»
  • UI не предлагает создать склад — кнопки нет

В БД warehouse_db.warehouses отсутствуют записи для новых ТТ.

Затронутые сервисы

  • Warehouse Service — нет @KafkaListener для store.created и/или нет внутреннего endpoint’а, который Store Service дёргал бы при создании ТТ. API POST /api/v1/warehouses существует, но полагается на ручной вызов.
  • Store Service — не публикует событие store.created в Kafka (или не вызывает Warehouse при создании ТТ).
  • Admin Franchise (web) — нет страницы создания склада, нет блока «Склад» на карточке ТТ.

Перед реализацией — разобрать модель склада (YumaPOS как референс)

Не факт что авто-создание склада — правильное решение

Решение «автосоздание при создании ТТ» — самый простой путь, но он жёстко фиксирует модель 1 ТТ = 1 склад. В YumaPOS модель богаче, и если мы идём в сторону полноценной складской системы — надо выбрать модель ДО реализации.

Как это устроено в YumaPOS (_reference/yumapos/managing-stores.md, register-stores.md):

  1. Склад — самостоятельная сущность с отдельным разделом UI «Склад → Склады» (список со всеми складами всех ТТ)
  2. У одной ТТ может быть несколько складов — бар, кухня, заморозка. «Если у магазина только один склад…» — значит типично 1:1, но N допустимо
  3. Склад можно перепривязать к другому магазину (пока нет остатков)
  4. Режим продаж у склада — определяет как списывать остатки при продаже:
    • Все — списываются все проданные товары
    • По категориям — только товары определённых категорий (например, со «склада заморозки» списываются только замороженные)
    • Ничего — с этого склада ничего не списывается (если у ТТ есть другой склад с режимом «Все»)
  5. Акты перемещения между складами (внутри одного ЮЛ) — можно перекидывать остатки
  6. Авто-создание при создании ТТ — опциональное. При добавлении магазина в форме есть поле Склад: если имя введено — создаётся с этим именем, если пусто — создаётся автоматически с именем магазина. Т.е. пользователь может и пропустить, и переопределить

Что из этого следует для нашего решения:

  • Если мы планируем поддержку нескольких складов на ТТ + акты перемещения + режимы продаж → эта BR намного больше чем «автосоздать склад». Это полноценный раздел «Склады» в админке (CRUD + перепривязка + удаление с проверкой остатков).
  • Если пока решаем минимум для MVP (1 ТТ = 1 склад) → хватит автосоздания + возможности переименовать на карточке ТТ, но это закрывает дорогу к N-складам без миграции.

Варианты решения

ВариантОбъёмПлюсыМинусы
A. Автосоздание + переименование на ТТ1-2 дня бэк + фронтБыстро. Достаточно для MVP сети кофеенФиксирует модель 1:1. Путь к N-складам позже — через миграцию
B. Полноценный раздел «Склады» + опциональное автосоздание (YumaPOS-style)2-3 неделиПолноценная складская модель. Готов к расширениям (цеха, акты перемещения, режимы)Большая работа. Нужен отдельный BR, а не фикс бага
C. Отложить — только UI «Создать склад» на карточке ТТ3-5 днейБыстро закрывает баг. Не фиксирует модель 1:1. Ставит задел на будущий разделПользователь должен помнить создавать склад после создания ТТ (UX-трение)

Рекомендация

Перед выбором — проговорить с бизнесом: планируем ли мы N складов на ТТ, акты перемещения, режимы продаж? Если «да, в обозримом будущем» → заводим отдельный BR «Полноценный раздел Склады» (вариант B), этот баг меняется на описание отсутствующего UI. Если «нет, 1:1 достаточно» → быстро делаем вариант A.

Воркэраунд (сделано вручную для Demo Coffee)

INSERT INTO warehouses (id, franchise_id, store_id, name, status, created_at)
VALUES (
  gen_random_uuid(),
  'a0c0ffee-0000-0000-0000-000000000001',
  '713dddb1-7552-4d85-974b-2f9136a907ff',
  'Склад Шаурма на Углях', 'active', now()
);

Вид графа