销售点和库存数据库架构

Question

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

需要考虑以下几点：

• 产品在整个系统中始终相同（相同的ID），但每个位置的库存（可供销售的单位数量）是独一无二的。例如，Y和Z位置都可以销售X产品的单位，但如果从位置Y出售两个单位，则不应影响位置Z的库存，它的存货单位仍然完好无损。
• 从位置Y销售一个（1）个X产品单位，意味着位置Y的库存应该从其库存中减去一个单位。

基于此，我想到了以下表格：

• 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（由orders_detail数量*价格计算得出；仅供未来数据验证）

• orders_detail

  • order_id
  • transaction_id
  • product_id
  • quantity
  • price

好的，那么还有问题吗？当然有。

1. 如何跟踪单位成本的变化？如果某天我开始支付更多钱购买某个产品，我需要以某种方式跟踪边际效用 ((成本*数量) - (价格*数量) = 边际效用)。我想主要使用inventories_detail来实现这一点。否则我就不会关心了。
2. 关系是否建立良好？我仍然很难想象位置是否拥有库存，或者库存是否有几个位置。这让我发狂。
3. 你如何保持/知道你当前的库存水平？由于我必须将库存表分开以跟上成本更新，所以我想我只需加总inventories_detail中所述的所有数量。
4. 您是否有任何建议要分享？

我相信我还有一些问题，但这些大多是我需要解决的问题。此外，由于我第一次使用Ruby on Rails，实际上作为一次学习经验，被设计阻止太快地实现，这真是遗憾，但我想这应该是正确的方法。

提前感谢您。

- Andrés Botero

Answer 1

这里的棘手之处在于你需要执行的不仅是POS解决方案，还需要进行库存管理和基本成本会计系统。

首先，你需要解决的情况是确定任何出售商品的成本的会计方法。最常见的选项是FIFO、LIFO或特定鉴别法（可以通过谷歌搜索得到这些术语）。

在这3种情况下，您应该将商品购买记录在数据结构中（通常称为采购订单，但在这种情况下，我将其称为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_id、product_id 和 location_id 的 FK 引用。

每次进行销售时，您将创建一个 InventoryTransaction 并具有负数数量以及对 order_line_id、product_id、location_id 和 source_inventory_transaction_id 的 FK 引用。

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

位置的当前库存将通过 SELECT sum(quantity) FROM inventory_transactions WHERE product_id = ? and location_id = ? GROUP BY product_id, location_id 进行计算。

边际成本将通过跟踪销售、通过两个相关库存交易追溯回 SourcingOrder 行来计算。

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

- Brian Glick

---

该死，会计方法让跟踪变得更加困难。我知道“单位成本”上次的添加绝对不是个好主意...谢谢你的回答。我会特别注意继续阅读它。 - Andrés Botero

嗨！如果我要使用FIFO，我该如何关联字段？如果我刚刚卖了两个物品，我会从最早的（order_date）SourceOrder中减去，对吧？抱歉，我只是试图联系信息。谢谢！顺便说一下，如果我单独处理位置的订单/库存，那么location_id应该放在SourceOrder而不是SourceOrderLine中，对吗？ - Andrés Botero

是的，在FIFO问题上。在SourceOrder vs SourceOrderLine方面，你可以选择任何一种方式。如果你想为多个商店发布单个订单，我会将其放在行级别以增加灵活性。另外，请接受这个答案。 - Brian Glick

最好的阅读这类内容的地方在哪里？（例如仓库库存、采购订单等数据库模型） - Joe Van Dyk

干得好，兄弟。继续保持！ - r.hamd

有人知道一本好书可以解释这个会计销售系统的设计模式吗？ - undefined

Answer 2

Brian说得没错。我想再补充一些信息。如果你正在为你的业务或客户开发完整的系统，建议你从组织层面开始，逐步推进到POS和会计流程。这样可以让你的数据库经验更加广泛...:P在我进行系统开发的经验中，库存模块总是从盘点开始+(采购-采购退货)=可供销售的SKU。 POS并不直接附属于库存模块，而是由销售主管每天进行调节。每日总销售数量将从可供销售的SKU中扣除。你还需要处理成本和定价模块。正确的数据库规范化始终是必须的。

- koch