Схема базы данных торговых точек и инвентаря

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

Некоторые моменты, которые следует учитывать:

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

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

  • локации

    • id
    • имя

  • продукты

    • id
    • имя

  • сделки

    • id
    • описание

  • inventory_header

    • id
    • location_id
    • идантификационный номер продукта

  • inventory_detail

    • inventories_id
    • ID транзакции
    • себестоимость единицы продукции
    • Цена за единицу
    • количество

  • orders_header

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

  • orders_detail

    • order_id
    • ID транзакции
    • идантификационный номер продукта
    • количество
    • цена

Хорошо, есть вопросы? Конечно.

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

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

Заранее спасибо.


ruby-on-rails inventory database-design point-of-sale
person Andrés Botero    schedule 06.04.2012    source источник

Ответы (2)


arrow_upward
23
arrow_downward

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

Первый сценарий, который вам нужно рассмотреть, - это метод учета, который вы будете использовать для определения стоимости любого проданного товара. Наиболее распространенными вариантами будут FIFO, LIFO или Specific Identification (все термины, которые можно найти в 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 складским проводкам, потому что заказанное количество было больше, чем то, что осталось в следующей складской проводке, которая должна быть распределена. Эта структура данных справится с этим, но вам нужно будет самостоятельно проработать логику и запрос.

person Brian Glick    schedule 06.04.2012
comment
Черт возьми, методы бухгалтерского учета усложняют отслеживание. Я знал, что последнее добавление «за единицу» было определенно НЕ хорошей идеей ... Спасибо за ответ. Я буду читать ее с особым вниманием. - person Andrés Botero; 06.04.2012
comment
Привет! Если бы я использовал FIFO, как бы я связал поля? Если бы я просто продал два предмета, я бы вычитал из самого старого (order_date) SourceOrder, верно? Извините, просто пытаюсь передать информацию. Спасибо! Да, кстати, если я обрабатываю заказы / инвентарь местоположений индивидуально, не следует ли location_id указывать в SourceOrder вместо SourceOrderLine? - person Andrés Botero; 06.04.2012
comment
Да, по вопросам FIFO. В SourceOrder vs SourceOrderLine вы можете пойти в любом направлении. Я бы поставил это на линейном уровне, чтобы позже повысить гибкость, если вы захотите оформить один заказ для нескольких магазинов. Также примите ответ. - person Brian Glick; 09.04.2012
comment
Где лучше всего почитать о подобных вещах? (Модели базы данных для складских запасов, заказов на поставку и т. Д.) - person Joe Van Dyk; 10.04.2013
comment
отличная работа, братан, так держать - person r.hamd; 18.11.2015

arrow_upward
3
arrow_downward

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

person koch    schedule 24.11.2013