Database design 发票与报价或估价 如果发票可以作废，是否应将其用作报价？

我有一个

发票

表，它是从与

作业

或

订单

关联的库存中创建的。我可以有一个

Quotes

表作为库存和发票之间的中转站，但它感觉我会有重复的数据结构和逻辑来处理“这是报价吗？”位

从业务角度来看，报价与发票不同：报价在承诺之前发送，发票在完成且付款到期后发送，但如何在我的存储库和模型中表示这一点

• 在数据库中存储和管理报价和发票的优雅方式是什么

---

编辑：为该特定实例指定了

作业

=

顺序。
有三种方法：

将发票和报价存储在单独的表中

如果发票和报价中几乎没有重复的字段（否则，使用选项#3和3个表），并且它们之间存在1-many或many-many关系（对于1-1，使用选项#2），则这是一个很好的设计

如果当报价成为发票时，两者之间的“共享”信息实际上可能发生变化（尽管其中一些变化应使用单独的字段/表格进行适当处理，如应用折扣等），那么这也是一个很好的选择

当将多个报价转换为单个（或多个）发票时，显然需要对该选项稍加修改。这将添加第三个表，该表是一组报价和发票（或一组发票，如果它变得如此复杂）之间的映射

将它们存储在同一个表中，并使用额外的标记“Invoice or quote”和来自这两个表的任何额外字段。这可以通过不同行中的发票和报价来实现，也可以通过它们共享行来实现（标记也具有“两者”值）

后者（同一行可以是发票和报价）是一个不错的选择，如果它们映射为1到1，并且很少有字段区分这两个字段

前者（发票和报价的单独行）通常不是一个好的设计，最好使用#3或#1选项

有3个表，一个用于两个表之间的公共字段，两个仅用于发票和报价

如果发票和报价是1-1映射的，或者如果发票和报价是1-many，但多张发票中的每一张都有相同的字段值，则这是一个很好的选择。否则，请使用#1

如果将多个报价转换为一张发票，则可以对该选项稍加修改。这增加了第四个表，它是一组报价和一个incoice（或一组发票，如果它变得那么复杂）之间的映射。同样，这里的假设是，链接/组合在一起的所有报价和发票之间有相当大的公共信息块，否则只需使用#1即可

报价更类似于订单。我见过几个带有订单表的分销/零售系统，该订单表有一个名为IsQuote的布尔标志。这看起来很简单，因为它使得将报价转换为订单变得微不足道。我从来都不喜欢它，因为从报价中得出的订单并不总是与报价完全一致。因此，像这样的系统会丢失一些有用的信息（即，将报价与订单进行比较的报告）。因此，我更喜欢报价表和订单表大致相同但相互独立的系统。在分销系统中，这通常会导致出现OrderHeader、OrderLine（与物料/库存表相关）、QuoteHeader和QuoteLine等表。您还可能有一个表来建模一个关系，其中一个报价可以映射到多个订单

发票通常来自订单。有时，一张发票上会开具多张订单的账单。例如，我看到一些公司每月向他们的好客户支付账单。我也看到了另一种工作方式，即一个包含多个装运的大订单在多个发票上开票（每批装运一张发票）

最后，付款通常与发票有多对多关系。有时一次付款包含多张发票。有时一张发票可以在几次付款中支付。
我建议尽量灵活。使用下表

作业表、发票表、报价表

在发票表和报价表中，存储作业Id，为其提供索引并创建外键约束。将聚集索引保留在报价id和发票id上。
在我使用的上一个系统上，报价和发票之间唯一的区别（就db而言）是表上的一个标志，指示客户是否接受报价（此时，生成了另一条具有所有相同信息的语句，除了它是发票而不是报价）
[为了简单起见，忽略了单个产品和服务。]

销售报价是一个建议以时间窗口（日期范围）内的价格向另一方出售商品。此资产不必存在。您可以根据资产（商品）的规格进行报价

报价应在某个时间点到期，到期前可能会被接受，也可能不会被接受

销售订单是一种承诺以某一日期的价格将商品出售给另一方。它可以根据接受的报价创建

订单或报价可能有付款条件，例如“您可以在交货后30天付款”

订单可能是针对一种尚不存在的商品（你出售商品，而不是资产）。也许你正在建造它。也许你将从其他人那里购买它

销售订单导致有形资产的采购（从库存中提取、制造或购买），然后是有形资产的装运，这可能会结束，也可能不会结束