С чего начать систему учёта склада?

Question

[Антон Алфимов]

Поставлена задача: вести управление складскими запасами магазина на собственной платформе.
Сейчас склад выглядит как таблица, каждый столбец которой вычитает значение для списания товара и прибавляет значение артикула для пополнения.

Мрак полнейший, никуда не годится.

Минимзирую работу до атомарных единиц:
Для начала создал БД.
Вначале таблица склада (коллекция в моём случае) с основными полями:
[ {артикул товара, число товара на складе} ].
Далее таблица с заказами, содержащими товар к списанию:
[ {артикул товара, число товара к списанию} ].
Ещё есть поставки и возвраты – это действия обратные для заказа, но суть та же:
[ {артикул товара, число товара к пополнению} ].
Всё остальное в данных условиях не играет роли.

Знатоки, внимание, вопрос:
Укажите, пожалуйста, как правильно организовать подсчёт текущего количества товарных позиций на складе, если:

• нельзя вычитать и прибавлять напрямую значения при создании нового заказа или поставки, т.к. нельзя выполнять необратимые операции. (Или без вариантов надо делать транзакции?)
  
• при каждом обращении рассчитывать предыдущее состояние склада, вычитать из него 3-4 тысячи заказов и прибавлять 3-4 сотни поставок – не решение
  
• необходимо будет добавить подгруппы числа товара на складе «в резерве» «брак» и прочие
  
• при поступлении нового заказа должна происходить проверка на наличие позиций склада, а так же резервирование продукции из наличия на этот заказ.
  

На данный момент мне уже известно, что данный класс задач относится к подсистемам WMS (Warehouse Management System), но я нигде не могу найти информации о том, как устроены эти системы, поэтому буду рад даже не столько готовым ответам, сколько информации об источниках по методологии, проектированию и внедрению, касающихся моей проблемы.

Язык, СУБД, и прочие технические аспекты не имеют решительно никакого значения, так как вопрос в данной плоскости сугубо теоретический.

Answer 1

[Алексей]

Я на своей практике (а работаю я именно с системами учета) из нормальных могу порекомендовать такую структуру:
1) таблица Приходов Income (заголовок, где указанны дата прихода, подразделение куда пришел и прочее) + IncomeGoods - (тело заголовка, где указан товар, количество и цена)
2) Таблица Расходов Outgo(заголовок, где указанны дата расхода, подразделение от куда ушел) + OutgoGoods - (тело заголовка, где указан товар, количество и цена)
3) таблица взаимосвязей - RelationIO (идентификаторы приходной позиции товара из IncomeGoods и OutgoGoods )-> таблица взаимосвязей приходов и расходов.
В чем суть таблицы: у вас есть приход допустим 20 штук. Вам нужно забрать из него 10 штук. Вы записываете в RelationIO то количество которое вы забрали из прихода и что его забрало.
Только понадобится написать процедуру проведения накладной - под проведением я подразумеваю набор свободных остатков для расхода.
Теперь по отдельным пунктам.

• Проводить документ только в транзакции. Никакие вычитания в данной системе не нужны. Все операции обратимы. Вы можете убрать взаимосвязи и удалить расход
  

• при каждом обращении рассчитывать предыдущее состояние склада, вычитать из него 3-4 тысячи заказов и прибавлять 3-4 сотни поставок – не решение

  
  Для проведения это единственное правильное решение. Иначе готовьтесь к большой Ж... в приходах и расходах, когда вся ваша система разрастется.
  
• Создайте в заголовках места хранения "Основное" и "Брак" + прочие
  
• По последнему писать не буду. Много там слишком. Если такая система заинтересует, могу примерную структуру таблиц прислать с алгоритмом (или кодом на MS SQL) для проведения
  
  

Comments

[Антон Алфимов]

Алексей, спасибо!
Посмотрел так же ваш ответ с ER

То есть, "у нас появился заказ -> создаётся транзакция -> записываем данные заказа в OutgoHead, а информацию о каждом товаре в OutgoBody -> пересчитываем Qty в RelationIO -> завершаем транзакцию" ?

Но я не понимаю как быть, если изначально, как я описал в вопросе, есть таблица "склад" в которой для каждого SKU должен быть свой Qty. При обращении к этой таблице нужно узнавать сколько каждого товара независимо от поставки находится сейчас на складе в свободном обращении.

Каждый раз пересчитывать все RelationIO для каждого SKU?

[Алексей]

Антон Алфимов: транзакция нужна на любую операцию где запись идет в две и более таблиц.

Насчет остатков - по мне таблица не решение, решение запрос в базу. Считать запрос остатков можно двумя способами: если вам нужно знать с каких приходов вам нужно будет списать товар, то по формуле ПРИХОДЫ-РЕЛЕЙШЕНЫ, если просто нужно знать количество остатков по SKU- то формула - ПРИХОДЫ-РАСХОДЫ (так быстрее).
Соглашусь, что это не всегда быстро. Но вариант держать таблицу в базе SKU-Кол-во мне не по душе, по причине того, что количество нужно будет увеличивать и уменьшать. Это и отслеживать неудобно и я не гарантирую правильности заполнения при частых и одновременных запросах.

Плюс данная система позволяет знать с какого прихода мы списали товар, а это как раз учитывается при расчете прибыли.

[Антон Алфимов]

Алексей: Всё-таки меня мучает вопрос с пересчётом тысяч расходов и сотен приходов каждый раз. Подумал, что к этому стоит добавлять промежуточные выписки, где будут высчитаны приходы-расходы за архивный отчётный период.

Большое спасибо за инфу, очень надеюсь, что теперь эти знания помогут наладить учёт товара =)

[kolkov]

Алексей, по идее сложение и вычитание - это можно реализовать на триггерах, а что бы не было одновременных действий, то использовать SELECT FOR UPDATE, как вариант.

[Алексей]

kolkov, а вы когда нибудь администрировали триггеры? Разбираться с их работой такая головная боль, что я давно взял за правило - чем меньше триггеров, тем лучше.

[kolkov]

Алексей, не знаю, что вы понимаете под администрированием триггеров, но кое-где они очень удобны, например в подобном случае. Тем более они работают в текущей транзакции, что очень удобно.

[YellowLightning]

Алексей, не могли бы вы прислать примерную структуру таблицы с алгоритмом

Answer 2

[xmoonlight]

по квадратикам:
1. только транзакции
2. ничего не надо рассчитывать: пакетная обработка с длиной пакета N-операций между состояниями
3. это пару свойств (если детально нужно, то - подмножества) товарного предложения
4. см. п.1
Советую Вам спроектировать диаграмму состояний на UML, чтобы Вы могли наглядно анализировать движение данных между конечными состояниями.

Comments

[Антон Алфимов]

Благодарен за ответ! Может быть в вашем арсенале найдутся ссылки на материалы, боевые проекты? Или хотя бы именования методологий? Ну например "используйте accounting patterns от Martin Fowler" или "вам подойдёт CQRS pattern Greg Young'a", а я бы тогда может усомнился в необходимости применять domain driven design и мы бы поискали какие-то альтернативные возможности проектирования.

А то выходит, что я задаю риторические вопросы уровня: "надо делать транзакции?", - "надо делать транзакции!"

[xmoonlight]

Антон Алфимов: здесь описаны шаги проектирования сайта в общем виде: https://sitecoder.blogspot.ru/p/blog-page_23.html
Они помогут упорядочить Ваш процесс.
Ктсати, что там по-поводу токенов и виджетов?)

[Антон Алфимов]

xmoonlight: нет, проектирование сайта тут ни при чём. Я прошу помощи в конкретной задаче, которую минимизировал в своём вопросе до пары таблиц.

[xmoonlight]

Антон Алфимов: ответ у меня более чем понятный. а что касается ссылок - гугл в помощь и изучайте.

[Леонид]

https://zippy.com.ua/

Бесплатная система складского учета с открытым кодом и веб интерфейсом