销售点和库存数据库架构

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

有些事情需要考虑:

  • 整个系统中的产品始终相同(相同的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数量*价格计算;仅用于未来的数据validation)
  • orders_detail

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

好的,那么,有什么问题吗? 当然。

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

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

提前致谢。

这里棘手的部分是你真的不仅仅是一个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和对sourcing_order_line_idproduct_idlocation_id FK引用。

每次进行销售时,您都将创建一个具有负数量的InventoryTransaction以及对order_line_idproduct_idlocation_idsource_inventory_transaction_id FK引用。

source_inventory_transaction_id将是从负数量InventoryTransaction回到使用您选择的任何会计方法计算的正数量InventoryTransaction的链接。

一个位置的当前库存将是SELECT sum(quantity) FROM inventory_transactions WHERE product_id = ? and location_id = ? GROUP BY product_id, location_id SELECT sum(quantity) FROM inventory_transactions WHERE product_id = ? and location_id = ? GROUP BY product_id, location_id SELECT sum(quantity) FROM inventory_transactions WHERE product_id = ? and location_id = ? GROUP BY product_id, location_id

边际成本将通过追溯销售,通过2个相关库存交易追溯到SourcingOrder线来计算。

注意:您必须处理在2个库存交易中分配一个订单行的情况,因为订购数量大于要分配的下一个库存交易中剩余的数量。 此数据结构将处理此问题,但您需要自己处理逻辑和查询。

布莱恩是对的。 只是为了添加其他信息。 如果您正在为您的企业或客户开发一个完整的系统。 我建议你开始从事组织层面的工作,直到POS和会计流程。 这将使您的数据库体验更加广泛…:P根据我在系统开发方面的经验,库存模块始终以库存+(购买 – 购买退货)= SKU可供销售开始。 POS不直接连接到库存模块,而是由销售主管每天进行协调。 每日总销售数量将扣除至可供销售的SKU。 您还将研究成本计算和定价模块。 正确的数据库规范化始终是必须的。