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

Question

我需要开发库存和销售系统.

对于库存,我需要能够跟踪理想的库存水平,当前库存水平,再订货点,成本,销售价格等.

并非库存中的每个项目都是"可销售的".例如,我可能想要保存用于苏打水的塑料杯的库存.这意味着,每次我卖苏打水时,我都要从塑料杯的库存数量中减去一个.因此,"中焦"实际上是塑料杯,一些餐巾和流体,每个项目都有自己的当前库存水平,成本等.

然后是"组合"的概念.也许1美元中等可口可乐和3美元汉堡包作为组合一起出售,仅需3.50美元(0.50美元的节省).提到可乐包括一些餐巾.说汉堡包还包括自己的餐巾纸.然而,作为一个组合,买家没有得到可乐和汉堡的餐巾; 相反,买家只获得相同数量的餐巾纸,就好像他/她只购买可口可乐一样.

对于销售系统,我需要跟踪每笔销售并可能与库存记录保持关系(这意味着,一旦销售,我就永远无法真正删除库存中的商品 - 出于历史目的).当我以1美元的价格出售"中等可乐"时,或许我应该将其分解为流体的0.90美元和塑料杯的0.10美元.

当我出售"组合"时,也许我需要能够指定汉堡包实际上以3美元的价格出售而中等可乐只需要0.50美元(只有苏打水被打折以使组合更具吸引力).

这不是一个新问题.有没有人有任何想法(或例子)我可以看看来解决这个问题？我不确定如何建模库存,可销售物品(尤其是组合)以及如何记录销售.

Answer 1

您正在寻找的解决方案将依赖于会计风格模型和几种物料清单(BOM).您的主要实体类型包括:

• SKU这是您销售的商品清单.它的属性将包括产品描述和当前零售价格等内容.你可以把价格和价格分成一个儿童餐桌,随着时间的推移给出价格.让我们假设你现在要离开那个皱纹.有些SKU可能是您所谈论的那种"组合".

• 组件这是组成SKU的东西的列表,例如餐巾,杯子,小圆面包,肉饼,焦糖浆等 - 使用你的例子.正如SKU有描述和价格一样,COMPONENT也有描述和单位成本.(也可以在子表中进行历史记录.)此表也是您通常存储ROP的位置.

• 组成这是一个与SKU和COMPONENT相交的BOM,并说明每个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表中记录的金额相加.需要注意的是,你通常不会确切地知道哪些餐巾纸或小面包你卖了,所以这将是不可能的特定组件reciepts与特定的SKU销售环节.相反,您需要有一个约定来确定哪些组件用于任何给定的SKU.您可能有会计规则,指定您需要使用的约定.大多数人使用FIFO.一些行业使用LIFO,我甚至看到加权平均成本会计.