Схема базы данных точки продажи и инвентаризации

Я пытаюсь создать базовую систему управления точки продаж и инвентаризации.

Некоторые вещи, которые необходимо учитывать:

  • Продукты всегда одинаковы (одинаковые идентификаторы) по всей системе, но инвентарь (доступные единицы для продажи на продукт) уникален для каждого места. Расположение Y и Z могут иметь для продажи единицы продукта X, но если, например, два устройства продаются из местоположения Y, не следует влиять на местонахождение инвентаря Zs. Его запасные части по-прежнему неповреждены.
  • Продажа одной (1) единицы продукта X из местоположения Y означает, что инвентаризация местоположения Y должна вычитать одну единицу из ее инвентаря.

Из этого я думал об этих таблицах:

  • Места

    • ID
    • имя

  • Продукты

    • ID
    • имя

  • операции

    • ID
    • Описание

  • inventories_header

    • ID
    • LOCATION_ID
    • product_id

  • inventories_detail

    • inventories_id
    • TRANSACTION_ID
    • unit_cost
    • unit_price
    • количество

  • orders_header

    • ID
    • Дата
    • всего (рассчитано из количества заказов_данных * цена, только для проверки будущих данных)

  • orders_detail

    • order_id
    • TRANSACTION_ID
    • product_id
    • количество
    • цена

Хорошо, да, есть ли какие-то вопросы? Конечно.

  • Как отслеживать изменения в стоимости единиц? Если в какой-то день я начну платить больше за определенный продукт, мне нужно будет немного отслеживать предельную полезность ((cost*quantity) - (price*quantity) = marginal utility). Я подумал о том, что в основном для этого есть инвентарь. Я бы об этом не думал.
  • Хорошо ли установлены отношения? Мне все еще сложно подумать, есть ли в этих местах запасы или если в кадастрах есть несколько мест. Его безумие.
  • Как бы вы знали/знали свои текущие уровни запасов? Поскольку мне приходилось отделять таблицу инвентаря, чтобы не отставать от обновлений затрат, я бы просто хотел добавить все количества, указанные в Inventories_detail.
  • Любые предложения, которые вы хотите поделиться?

Я уверен, что у меня все еще есть некоторые вопросы, но это в основном те, которые мне нужны для адресации. Кроме того, поскольку Im, использующий Ruby on Rails в первый раз, на самом деле, как опыт обучения, его стыд останавливается при разработке, не позволяя мне ускорить реализацию быстрее, но я думаю, что так оно и должно быть.

Спасибо заранее.

ОТВЕТЫ

Ответ 1

Трудная часть здесь заключается в том, что вы действительно делаете больше, чем решение POS. Вы также занимаетесь управлением запасами и базовой системой учета затрат.

Первый сценарий, который вам нужно решить, - это метод учета, который вы будете использовать для определения стоимости проданного предмета. Наиболее распространенными параметрами могут быть FIFO, LIFO или специфическая идентификация (все термины, которые могут быть Google).

Во всех трех сценариях вы должны записывать свои покупки ваших товаров в структуре данных (обычно это называется PurchaseOrder, но в этом случае я буду называть это SourcingOrder, чтобы отличать ваши таблицы заказов от исходного вопроса).

В приведенной ниже структуре предполагается, что каждая строка заказа поставщика будет для одного местоположения (в противном случае все становится еще более сложным). Другими словами, если я куплю 2 виджета для магазинов A и 2 для магазина B, я бы добавил 2 строки к заказу с количеством 2 для каждой, а не одной строкой с количеством 4.

SourcingOrder
 - order_number
 - order_date

SourcingOrderLine
 - product_id
 - unit_cost
 - quantity
 - location_id

Инвентаризация может быть на одном уровне...

InventoryTransaction
 - product_id
 - quantity
 - sourcing_order_line_id
 - order_line_id
 - location_id
 - source_inventory_transaction_id

Каждый раз, когда SourcingOrderLine принимается в хранилище, вы создаете InventoryTransaction с положительным количеством, а FK ссылается на sourcing_order_line_id, product_id и location_id.

Каждый раз, когда выполняется продажа, вы создаете InventoryTransaction с отрицательным количеством, а FK ссылается на order_line_id, product_id и location_id, source_inventory_transaction_id.

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

Текущая инвентаризация для местоположения будет SELECT sum(quantity) FROM inventory_transactions WHERE product_id = ? and location_id = ? GROUP BY product_id, location_id.

Маржинальная стоимость будет рассчитываться путем отслеживания от продажи через 2 связанные транзакции с запасами в строку SourcingOrder.

ПРИМЕЧАНИЕ. Вы должны обрабатывать случай, когда вы выделяете одну строку заказа для двух транзакций инвентаризации, потому что упорядоченное количество было больше, чем то, что было оставлено в следующей транзакции инвентаризации. Эта структура данных справится с этим, но вам нужно будет работать с логикой и запросить себя.

Ответ 2

Брайан прав. Просто добавьте дополнительную информацию. Если вы работаете в полной системе для своего бизнеса или клиента. Я бы посоветовал вам начать работать на организационном уровне вплоть до процесса POS и учета. Это сделало бы вашу базу данных более обширной...: P В моем опыте разработки системы модули Inventory всегда начинаются с покупки акций + (покупки-покупки) = SKU для продаж. POS напрямую не привязан к модулю Inventory, а будет сверяться ежедневно руководителем продаж. Суммарное количество ежедневных продаж будет вычитаться в SKU, доступный для продажи. вы также разработаете модули калькуляции и ценообразования. Правильная нормализация базы данных всегда обязательна.