销售点和库存数据库架构

Question

我正在尝试创建一个基本的销售点和库存管理系统.

有些事情需要考虑:

• 整个系统中的产品始终相同(相同的ID),但库存(每个产品的可用销售单位)在每个位置是唯一的.位置Y和Z都可以具有产品X的销售单位,但是如果例如从位置Y销售两个单元,则位置Z的库存不应受影响.它的库存单位仍然完好无损.
• 从位置Y销售产品X的一(1)个单位,意味着位置Y的库存应从其库存中减去一个单位.

从那以后,我想到了这些表:

• 地点

  • ID
  • 名称

• 制品

  • ID
  • 名称

• 交易

  • ID
  • 描述

• inventories_header

  • ID
  • LOCATION_ID
  • PRODUCT_ID

• inventories_detail

  • inventories_id
  • TRANSACTION_ID
  • 单位成本
  • 单价
  • 数量

• orders_header

  • ID
  • 日期
  • 总计(根据orders_detail数量*价格计算;仅用于未来的数据验证)

• orders_detail

  • ORDER_ID
  • TRANSACTION_ID
  • PRODUCT_ID
  • 数量
  • 价钱

好的,那么,有什么问题吗？当然.

1. 如何跟踪单位成本的变化？如果有一天我开始为某个产品支付更多费用,我需要以(cost*quantity) - (price*quantity) = marginal utility某种方式跟踪边际效用().我想到了库存_主要是为了这个.我不会另外关心.
2. 人际关系是否稳固？我仍然很难想到这些地点是否有库存,或者库存是否有多个地点.这令人抓狂.
3. 您如何保持/了解您当前的库存水平？由于我必须将库存表分开以跟上成本更新,我想我只需要将库存中的所有数量相加即可.
4. 您想分享任何建议吗？

我确信我还有一些问题,但这些问题主要是我需要解决的问题.此外,由于我第一次使用Ruby on Rails,实际上,作为一种学习体验,停止设计是一种耻辱,不让我更快地实现实现,但我想这应该是它应该的方式.

提前致谢.

Answer 1

这里棘手的部分是你真的不仅仅是一个POS解决方案.您还在进行库存管理和基本成本会计系统.

您需要解决的第一个方案是您将使用哪种会计方法来确定所售商品的成本.最常见的选项是FIFO,LIFO或特定标识(所有可以使用Google搜索的术语).

在所有3种情况下,您应该在数据结构中记录您的商品购买(通常称为PurchaseOrder,但在这种情况下,我将其称为SourcingOrder,以区别于原始问题中的订单表).

下面的结构假设每个采购订单行将用于一个位置(否则事情变得更加复杂).换句话说,如果我为商店A购买2个小工具,为商店B购买2个小工具,我会在订单中添加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.

每一个销售由时间,您将创建一个负数量和FK引用的InventoryTransaction的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个库存交易中分配一个订单行的情况,因为订购数量大于要分配的下一个库存交易中剩余的数量.此数据结构将处理此问题,但您需要自己处理逻辑和查询.