Вопрос по ruby-on-rails – Схема базы данных точек продаж и инвентаризации

13

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

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

The products are always the same (same ID) through the whole system, but inventory (available units for sale per product) is unique per location. Location Y and Z may both have for sale units of product X, but if, for example, two units are sold from location Y, location Z’s inventory should not be affected. Its stocked units are still intact. Selling one (1) unit of product X from location Y, means inventory of location Y should subtract one unit from its inventory.

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

locations

id name

products

id name

transactions

id description

inventories_header

id location_id product_id

inventories_detail

inventories_id transaction_id unit_cost unit_price quantity

orders_header

id date total (calculated from orders_detail quantity * price; just for future data validation)

orders_detail

order_id transaction_id product_id quantity price

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

How do I keep track of changes in units cost? If some day I start paying more for a certain product, I would need to keep track of the marginal utility ((cost*quantity) - (price*quantity) = marginal utility) some way. I thought of inventories_detail mostly for this. I wouldn’t have cared otherwise. Are relationships well stablished? I still have a hard time thinking if the locations have inventories, or if inventories have several locations. It’s maddening. How would you keep/know your current stock levels? Since I had to separate the inventory table to keep up with cost updates, I guess I would just have to add up all the quantities stated in inventories_detail. Any suggestions do you want to share?

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

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

хорошо, братан, это хороший вопрос r.hamd

Ваш Ответ

2   ответа
2

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

19

что вы действительно делаете больше, чем просто 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.

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

Error: User Rate Limit Exceeded Andrés Botero
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceeded Andrés Botero
Error: User Rate Limit Exceeded

Похожие вопросы