销售点和库存数据库架构答案

【问题标题】：Point of Sale and Inventory database schema销售点和库存数据库架构
【发布时间】：2012-04-19 17:32:09
【问题描述】：

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

需要考虑的一些事项：

整个系统中的产品始终相同（相同的 ID），但每个位置的库存（每个产品的可销售单位）是唯一的。位置 Y 和 Z 可能都有产品 X 的待售单位，但例如，如果从位置 Y 出售两个单位，则位置 Z 的库存不应该受到影响。其库存单位仍然完好无损。
从位置 Y 销售一 (1) 件产品 X，意味着位置 Y 的库存应从其库存中减去一单位。

由此，我想到了这些表格：

地点
- 身份证
- 姓名
产品
- 身份证
- 姓名
交易
- 身份证
- 说明
inventories_header
- 身份证
- location_id
- product_id
inventories_detail
- inventories_id
- transaction_id
- 单位成本
- 单价
- 数量
orders_header
- 身份证
- 日期
- 总计（由 orders_detail 数量 * 价格计算；仅用于未来数据验证）
orders_detail
- order_id
- transaction_id
- product_id
- 数量
- 价格

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

如何跟踪单位成本的变化？如果有一天我开始为某种产品支付更多费用，我需要以某种方式跟踪边际效用 ((cost*quantity) - (price*quantity) = marginal utility)。我主要为此想到了inventories_detail。否则我不会在意的。
关系是否稳固？我仍然很难考虑这些地点是否有库存，或者库存是否有多个地点。真让人抓狂。
您将如何保持/了解您当前的库存水平？由于我必须将库存表分开以跟上成本更新，我想我只需要将inventories_detail 中列出的所有数量相加即可。
您有什么建议要分享吗？

我确信我还有一些问题，但这些主要是我需要解决的问题。另外，由于我是第一次使用 Ruby on Rails，实际上，作为一种学习体验，在设计上停下来很遗憾，没有让我更快地完成实现，但我想这就是应该的方式。

提前致谢。

【问题讨论】：

标签： ruby-on-rails database-design point-of-sale inventory

【解决方案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 以及对 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 返回到使用您选择的任何会计方法计算的正数量 InventoryTransaction 的链接。

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

边际成本将通过从销售追溯至 SourcingOrder 行的 2 个相关库存交易来计算。

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

【讨论】：

见鬼，会计方法使跟踪变得更加困难。我知道最后添加“单位成本”绝对不是一个好主意……感谢您的回答。我会特别注意继续阅读它。
你好！如果我要使用 FIFO，我将如何关联这些字段？如果我只卖了两件商品，我会从最旧的（order_date）SourceOrder 中减去，对吗？对不起，只是试图关联信息。谢谢！哦，对了，如果我单独处理位置的订单/库存，location_id 不应该进入 SourceOrder 而不是 SourceOrderLine 吗？
是的，关于 FIFO 问题。在 SourceOrder 与 SourceOrderLine 上，你可以选择任何一种方式。如果您想为多个商店发出单个订单，我会将其放在生产线级别以增加灵活性。另外，请接受答案。
哪里是阅读此类内容的最佳地点？（仓库库存、采购订单等的数据库模型）
干得好，兄弟，继续努力

【解决方案2】：

布赖恩是正确的。只是为了添加其他信息。如果您正在为您的企业或客户构建一个完整的系统。我建议您从组织层面开始工作，直至 POS 和会计流程。这将使您的数据库体验更加广泛......：P 在我的系统开发经验中，库存模块总是以盘点+（购买 - 购买退货）=可供销售的 SKU 开始。 POS 不直接附加到库存模块，而是由销售主管每天对账。然后，每日总销售量将扣除可供销售的 SKU。您还将制定成本计算和定价模块。数据库的正确规范化始终是必须的。

【讨论】：