数据库设计：库存和销售系统？

Question

我需要开发一个库存和销售系统。

对于库存，我需要能够跟踪理想的库存水平、当前库存水平、再订购点、成本、售价等。

并非库存中的每件商品都是“可销售的”。例如，我可能想要保留用于汽水的塑料杯的库存。意思是，每次我卖一瓶汽水，我都需要从塑料杯的库存中减去一个。因此，“中度可乐”实际上是塑料杯、一些餐巾纸和液体，每件物品都有自己的当前库存水平、成本等。

然后是“组合”的概念。也许 1 美元的中型可乐和 3 美元的汉堡包作为组合出售时只需 3.50 美元（节省 0.50 美元）。提到可乐包括一些餐巾纸。假设汉堡包本身也包括餐巾纸。然而，作为一个组合，购买者没有得到可乐和汉堡的餐巾纸；相反，买家只得到与他/她只购买可乐一样数量的餐巾纸。

对于销售系统，我需要跟踪每笔销售，并可能与库存记录保持关系（这意味着一旦完成销售，我就永远无法真正删除库存中的商品——出于历史目的）。当我以 1 美元的价格出售“中型可乐”时，也许我应该将其分解为液体 0.90 美元和塑料杯 0.10 美元。

当我出售“组合”时，也许我需要能够指定汉堡包的实际售价为 3 美元，而中杯可乐仅为 0.50 美元（只有苏打水打折以使组合更具吸引力）。

这不是一个新问题。 有没有人有任何想法（或示例）可以解决这个问题？我不知道如何为库存建模、可销售物品（尤其是组合）以及如何记录销售额.

Answer 1

我建议将存货表与货币会计表完全分开。例如，你举的例子我知道很荒谬：对于你的普通快餐店来说，一杯 0.90 美分的可乐成本约为 0.05-0.07 美元一杯，而液体不到一美分，留下一个整洁的0.83 美元左右的利润。为什么成本加起来要高达 0.90 美元？

表格：

InventoryItems 字段：InventoryItemId、名称、CurrentInventoryLevel、IdealInventoryLevel

InventoryChangeRecords 字段：InventoryChangeId、InventoryItemId、Change (int)

RetailItems 字段：RetailItemId、名称、价格

RetailItemMakeup 字段：RetailItemId、InventoryItemId、数量

SaleTransactions 字段：SaleTransactionId、DateTime、TotalSale

SaleTransactionItems 字段：SaleTransactionId、RetailItemId、数量

对于每次销售，您应该使用存储过程（或触发器）来更新 CurrentInventoryLevel，并将记录插入到 InventoryChangeRecords。通过从 SaleTransaction 到 SaleTransactionItems 再到 RetailItemMakeup，您可以轻松了解任何销售对库存的影响。

如果您想以更强大（但与 IMO 无关）的方式执行此操作，您可以在 SaleTransactionItems 和 InventoryChangeRecords 之间创建另一个多对多表。

Answer 2

您正在寻找的解决方案将依赖于会计样式模型和几个物料清单 (BOM)。您的主要实体类型将包括：

• SKU 这是您销售的商品列表。它的属性将包括产品描述和当前零售价等内容。您可以得到花哨的价格并将价格分解到一个子表中，该表会随着时间的推移给出价格。让我们假设你现在要离开那个皱纹。有些 SKU 可能是您所说的那种“组合”。

• 组件 这是构成 SKU 的物品列表，例如餐巾纸、杯子、面包、肉饼、可乐糖浆等 - 以您的示例为例。正如 SKU 有描述和价格一样，组件也有描述和单位成本。 （也可以在子表中进行历史记录。）此表通常也是您存储 ROP 的地方。

• COMPOSITION 这是一个 BOM，它与 SKU 和 COMPONENT 相交，表示每个 COMPONENT 有多少单位进入一个 SKU 的单位。您也需要其中之一来与两个 SKU 相交（对于组合）。您可以为此使用一张或两张桌子。两张桌子会让纯粹主义者高兴，从编码人员的角度来看，一张桌子会很方便。

• SALE 这是一个交易表，提供用于记录一个或多个 SKU 的销售的标题。此表将包含交易日期、收银员 ID 和其他标题项目。

• SALE_ITEM 这是交易详细信息表，其中包含已售出的 SKU（以及数量）和售价。销售时 SKU 价格的非规范化是多少，但也可能包括对价格的任何特殊覆盖。对 SKU 实际收取的价格进行非规范化是一件好事，因为有人可以在 SKU 中编辑标价，然后您就会忘记当时对该商品实际收取的价格。

• INVENTORY_HDR 这是一个在概念上类似于 SALE 的事务表，但它是库存事务的表头，例如接收新库存、用完库存（如在销售它）和库存调整。同样，这将是日期/描述内容，但如果您愿意，它可以包含指向 SALE_ITEM 的直接链接，用于销售库存变动。您不必这样做，但有些人喜欢在逐笔交易的基础上建立收入和成本之间的联系。

• INVENTORY_DTL 这是库存交易的详细信息。这指示了进出哪个 COMPONENT、进出的数量以及此移动应用到的 INVENTORY_HDR 事务。这也是您保存为组件项目支付的实际成本的地方。

• 位置您还可以（如果您愿意）跟踪您接收和使用/出售的库存的实际位置。在餐厅中，这可能并不重要，但如果您有连锁店，或者您的餐厅有一个异地仓库来存放成分，那么您可能会关心。

考虑以下 ERD：

要进行收入核算，您需要将 SALE_ITEM 表中记录的金额相加。

库存水平的计算基于将每个 COMPONENT 的 INVENTORY_DTL 输入和输出相加。 （不要将当前库存水平存储在表格中——这注定会导致对账问题。）

要进行成本核算，您需要将 INVENTORY_DTL 表中记录的金额相加。请注意，您通常不会确切地知道哪些餐巾或面包您卖了，因此无法将特定组件收据与特定 SKU 销售联系起来。相反，您需要有一个约定来确定用于任何给定 SKU 的组件。您可能有会计规则来指定您需要使用的约定。大多数人使用先进先出。有些行业使用 LIFO，我什至见过加权平均成本会计。