开票与报价或估算
如果发票可以作废，是否可以用作报价单？
我有一个 Invoices 表，它是根据与 Job 或 Order 关联的库存创建的。我可以有一个 Quotes 表作为库存和发票之间的中间站，但感觉我会有重复的数据结构和逻辑只是为了处理“这是报价吗？”少量。
从业务角度来看，报价与发票不同：报价在承诺之前发送，发票在完成且付款到期后发送，但如何在我的存储库和模型中表示这一点。
- 什么是存储和管理报价和报价的优雅方式？数据库中的发票？
编辑：指示此特定实例的作业 === 订单。
If invoices can be voided, should they be used as quotations?
I have an Invoices tables that is created from inventory associated with a Job or Order. I could have a Quotes table as a halfway-house between inventory and invoices, but it feels like I would have duplicate data structures and logic just to handle an "Is this a quote?" bit.
From a business perspective, quotes are different from invoices: a quote is sent prior to an undertaking and an invoice is sent once it is complete and payment is due, but how to represent this in my repository and model.
- What is an elegant way to store and manage quotes & invoices in a database?
Edit: indicated Job === Order for this particular instance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
有 3 种方法：
将发票和报价存储在单独的表中。
如果发票和报价单中很少有重复字段（否则，请使用带有 3 个表的选项 #3），并且如果它们之间存在一对多或多对多关系（对于 1-1，请使用选项#2）。
如果当报价成为发票时，两者之间的“共享”信息实际上可能会发生变化，这也是一个不错的选择（尽管其中一些变化应该使用单独的字段/表进行正确处理，例如应用的折扣，等等...）。
当多个报价转换为单个（或多个）发票时，显然需要对此选项进行轻微的修改。这将添加第三个表，它是一组报价和发票（或一组发票，如果变得那么复杂）之间的映射。
将它们存储在同一个表中，并带有额外的标志“发票或报价”以及存储的两个表中的任何额外字段。这可以通过不同行中的发票和报价单或共享行（标志也具有“两者”值）来完成。
如果它们映射为 1 到 1，后者（同一行可以同时是发票和报价单）是一个不错的选择，并且很少有字段可以区分这两者。
前者（发票和报价单的单独行）一般来说并不是一个很好的设计，最好使用 #3 或 #1 选项。
有 3 个表，一个用于两者之间的公共字段，另外两个用于仅发票和报价。
如果发票和报价单映射为 1-1，或者如果它们是 1-多，但许多发票中的每一个对于公共字段都具有完全相同的字段值，那么这是一个不错的选择。否则，使用#1。
当多个报价转换为单个发票时，可以对此选项进行细微的修改。这添加了第四个表，它是一组报价和发票（或一组发票，如果变得那么复杂）之间的映射。同样，这里的假设是，链接/组合在一起的所有报价和发票之间存在大量公共信息，否则就使用#1。
There are 3 approaches:
Store invoices and quotes in separate tables.
This is a good design if invoices and quotes have few fields in duplicate (otherwise, use option #3 with 3 tables), and if there's a 1-many or many-many relationships between them (for 1-1, use option #2).
This is also a good choice if it's common that "shared" information between the two can actually mutate when the quote becomes the invoice (although some of these mutations should be properly handled with separate fields/tables, such as applied discounts, etc...).
A slight variation of this option is obviously needed be done when multiple quotes are turned into a single (or multiple) invoices. This adds a 3rd table which is a mapping between a set of quotes and an invoice (or set of invoices if it gets that complicated) for them.
Store them in the same table, with extra flag "Invoice or quote" and any extra fields from both stored. This can be done with either invoices and quotes in distinct rows, or with them sharing rows (with flag having "both" value too).
The latter (same row can be both invoice and quote) is a good choice if they are mapped 1 to 1, and there are few fields that distinguish the two.
The former (separate rows for invoices and quotes) is not a vary good design in general and better done with the #3 or #1 options.
Have 3 tables, one for common fields between the two, and two for invoice-only and quotes only.
This is a good choice if invoices and quotes are mapped 1-1, or if they are 1-many but each of the many invoices has exactly the same field values for whichever fields are common. Otherwise, use #1.
A slight variation of this option can be done when multiple quotes are turned into a single invoice. This adds a 4th table which is a mapping between a set of quotes and an incoice (or set of invoices if it gets that complicated) for them. Again, the assumption here is that there's a sizeable chunk of common info between all of the quotes and invoices linked/combined together, otherwise just go with #1.
报价更类似于订单。我见过几个带有订单表的分销/零售系统，该表有一个名为 IsQuote 之类的布尔标志。这看起来很简单，因为它使得将报价变成订单变得微不足道。我从来不喜欢它，因为报价中的订单并不总是与报价完全一致。结果，类似的系统会丢失可能有用的信息（即比较报价和订单的报告）。因此，我更喜欢报价表和订单表大致相同但又分开的系统。在分销系统中，这通常会产生诸如 OrderHeader、OrderLine（与商品/库存表相关）、QuoteHeader 和 QuoteLine 等表。您还可能有一个表来建模关系，其中一个报价可以映射到多个订单。
发票通常来自订单。有时，一张发票上会记入多个订单。例如，在某些情况下，我看到公司每月向其优质客户收取费用。我还看到它以另一种方式工作，即多次发货的大订单按多张发票计费（每次发货一张）。
最后，付款通常与发票具有多对多的关系。有时一笔付款涵盖多张发票。有时一张发票需要分几次付款。
Quotes are more analogous to orders. I have seen several distribution/retail systems with an order table that has a boolean flag named something like IsQuote. This can seem simple as it makes it trivial to turn a quote into an order. I never liked it because orders that come out of quotes are not always exactly as quoted. As a result, systems like those lose information that can be of some use (i.e. a report that compares quotes to orders). Therefore, I prefer systems where the quote and order tables are about the same but separate. In distribution systems this often leads to tables like OrderHeader, OrderLine (relates to item/inventory table), QuoteHeader and QuoteLine. You might also have a table to model a relationship where one quote can map to multiple orders.
Invoices usually result from orders. Sometimes more than one order will be billed on a single invoice. For example, there are cases where I have seen companies bill monthly to their good customers. I have also seen it work the other way where a large order with multiple shipments is billed on multiple invoices (one for each shipment).
Finally, payments usually have a many to many relationship with the invoice. Sometimes one payment covers multiple invoices. Sometimes one invoice gets paid in a couple of payments.
[为简单起见，忽略单个产品和服务。]
销售报价是在时间窗口（日期范围）内以一定价格向另一方出售商品的建议 。该资产还不需要存在。您可以对资产（商品）的规格进行报价。
报价应该在某个时候到期，并且在到期之前可能会也可能不会被接受。
销售订单是在某一日期以一定价格向另一方出售商品的承诺。它可以根据接受的报价创建。
订单或报价可能有付款条款，例如“您可以在交货后 30 天向我们付款”。
订单可能针对尚不存在的商品（您出售商品，而不是资产）。也许你正在构建它。也许你会从别人那里购买它。
销售订单导致实物资产的采购（从库存中获取、制造或购买），然后装运实物资产，这可能会也可能不会结束在一次交付中。有时，客户“会致电”供应商来提取资产。
一般来说，必须先转移资产，然后才能将订单行计为收入（这取决于您的运输条款，可能是在装运或交货时或两者之间） ）。
销售订单可以取消（例如，某些行业有冷静期）。
销售发票是订购产品的付款请求。它可能发生在交货前、交货时或交货后，或者根本不发生（例如在麦当劳排队时）。一个订单可以有一张或多张发票，一张发票可以用于多个订单。
发票有望导致一笔或多笔付款，这些付款应用于到帐户。一笔付款通常会产生一张或多张付款收据。如果使用权责发生制会计，则付款不一定与收入相同。
[Single product, and services ignored, for simplicity.]
A sales quote is a proposal to sell a good for a price in a time window (date range) to another party. This asset need not exist yet. You could quote on the specification of the asset (the good).
A quote should expire at some point, and may or may not be accepted prior to expiry.
A sales order is a commitment to sell a good for a price at a date to another party. It can be created from an accepted quote.
An order or quote may have payment terms, such as "you can pay us 30 days after delivery".
An order may be for a good that does not exist yet (you sell the good, not the asset). Maybe you're building it. Maybe you're gonna buy it from someone else.
A sales order leads to the procurement (take from inventory, make or buy) of a physical asset, and then the shipment of the physical asset, which may or may not end in a delivery. Sometimes, the customer "will call" on the vendor to pickup the asset.
Generally speaking, an asset has to be transferred before you can count the order line as revenue (this depends on your shipping terms, could be at shipment or delivery or in-between).
A sales order can be cancelled (for example, some industries have cooling-off periods).
A sales invoice is a request for payment for ordered products. It may happen prior to delivery, at delivery, or after delivery, or not really happen at all (such as if in line at McDonald's). An order may have one or more invoices, and an invoice may be for several orders.
An invoice hopefully leads to one or more payments, which are applied to an account. A payment often leads to one or more receipts of payment. A payment is not necessarily the same as revenue, if using accrual accounting.
我建议尽可能灵活。使用下表
“作业表”、“发票表”、“报价表”
在发票表和报价表中，存储作业 ID、为其指定索引并创建外键约束。将聚集索引保留在报价 ID 和发票 ID 上。
I would recommend being as flexible as possible. Use the following tables
Job Table, Invoice Table, Quote Table
In your Invoice Table and Quote Table, store the Job Id, give it an index and create a foreign key constraint. Leave the clustered index on the quote id and the invoice id.
在我处理的最后一个系统上，报价和发票（就数据库而言）之间的唯一区别是表上的一个标志，该标志指示客户是否接受了报价（此时生成了另一条声明，其中包含所有相同的内容）信息，但它是发票而不是报价）
On the last system I worked on the only difference between quotes and invoices (in terms of the db) was a flag on the table that indicated whether the quote had been accepted by the customer (at which point another statement was generated with all the same information except that it was an invoice instead of a quote)