Я работаю для оптовика много лет, и то, как мы делаем это на уровне базы данных (общие понятия и ОЧЕНЬ упрощено):
- основное внимание уделяется инвентарю продукциив каждом распределительном центре (то, что вы называете местоположениями).
- каждому клиенту назначается распределительный центр, обычно ближайший к отправке.
каждый раз, когда клиент размещает заказ,инвентарь распределительного центра вычитается из суммы, которую он заказал, упаковал и отправил.
мы также заказываем товары у производителей.
- эти заказы выполняютсяпри автоматическом инициировании пополнения запасов.
- триггеры обнаруживают, если доступность продукта ниже определенного уровня.
- для этого существует сложный алгоритм (например, что больше всего востребовано в течение сезона или города),но это выходит за рамки этого вопроса.
- каждый раз, когда эти заказы поступают в центр, выполняется процесс, который мы называем Пополнение.
- Пополнение - это добавление нового инвентаря в базу данных.и поместите продукты на назначенные полки в центре.
Итак, в итоге
Существует также много других процессов, таких как возврат, управление обратным заказом, ... но давайте продолжим суть.
У нас также есть перемещения продуктов между распределительными центрами, как и у вас.Но, будучи «сфокусированными на товарно-материальных запасах», перемещения обрабатываются как частный случай продаж для центра, отправляющего товары, а другой - как частный случай пополнения запасов.
ИМХО, я не предлагаю вам рассчитывать запас на основедвижения.Это принесет много расчетов ни за что.Если у вас большие заказы со многими предметами, создание инвентаря может быть ОГРОМНЫМ вычислением.
Другая проблема, создаваемая этим, заключается в том, что каждая единица должна быть идентифицирована, помечена каким-либо образом, отслежена, рассчитана, сообщена, ...
В любом случае, вот моя попытка схемы вашей проблемы.
Моя логика:
- Единица : центральный элемент в схеме.
Все вращается вокруг него, чтобы определить единицу и отследить, где она находится.
Заказ : заказ представляет собой набор единиц, которые были заказаны одновременно.
Order_has_Unit : связывает юниты с заказами.Обратите внимание, что, поскольку мы отслеживаем каждую единицу в отдельности, каждый элемент должен быть связан здесь.8 таблиц == 8 единиц == 8 строк в Order_has_Unit.
Unit_has_Movement , Движение и Расположение используетсядля отслеживания каждого юнита при его перемещении в системе.
Сценарий, получение заказа:
- создать одну запись юнита на элемент в Ордене.
- свяжите его с соответствующим Продуктом
- определите Движение от [Location == external] к [Location == "X"]
- свяжите это Движение с каждой полученной Единицей.
Чтобы соответствовать этому дизайну в действительности, КАЖДЫЙ блок должен быть помечен чем-то, чтобы идентифицировать его.Штрих-код достаточен для идентификации продукта, но не для идентификации одной единицы.Необходимо будет создать новый «номер метки».
Вы задались вопросом, как будет выглядеть запрос на создание инвентаря в определенном месте.Вот логин (не SQL!):
- Найдите каждый блок, где:
- У самого последнего Движения есть idLocationTo == Место, которое вы хотите
- Этиможет быть посчитан и сгруппирован по продукту, поэтому у вас есть итоги.
Я надеюсь, что это даст вам идеи для продолжения работы и, возможно, рассмотрит другие решения для ваших требований.Желаем удачи!