开票与报价或估算

Question

如果发票可以无效,是否应将它们用作报价单？

我有一个Invoices表是从与Job或相关联的库存创建的Order.我可以将一张Quotes桌子作为库存和发票之间的中间位置,但感觉我会有重复的数据结构和逻辑来处理"这是一个引用吗？" 位.

从商业角度来看,报价是从不同的发票:报价之前承诺发送和发送发票,一旦完成,付款到期,但如何在我的资料库和模型来表示这一点.

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

编辑:对于此特定实例,指示Job=== Order.

Answer 1

有3种方法:

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

   如果发票和报价重复的字段很少(或者使用3个表格的选项#3),并且如果它们之间存在1-many或many-many关系(对于1-1,则使用选项#2),这是一个很好的设计).

   如果两者之间的"共享"信息在报价成为发票时实际上会发生变异(尽管其中一些突变应该用单独的字段/表格正确处理,例如应用折扣等),这也是一个不错的选择. ).

   当多个报价转换为单个(或多个)发票时,显然需要略微改变此选项.这会添加第3个表,它是一组引号和发票(或发票组合,如果它变得那么复杂)之间的映射.

2. 将它们存储在同一个表中,并带有额外的标记"Invoice or quote"以及两个存储的额外字段.这可以通过不同行中的发票和报价来完成,也可以与它们共享行(标志也具有"两个"值)来完成.

   后者(同一行可以是发票和报价)是一个很好的选择,如果它们被映射为1到1,并且很少有字段区分这两者.

   前者(发票和报价单独的行)通常不是一个好的设计,而是使用#3或#1选项做得更好.

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

   如果发票和报价被映射为1-1,或者它们是1-many但是许多发票中的每一个都具有完全相同的字段值,无论哪个字段是常见的,这都是一个不错的选择.否则,使用#1.

   当多个报价转换为单个发票时,可以略微改变此选项.这会添加第4个表,它是一组引号和一个发票(或一组发票,如果它变得那么复杂)之间的映射.同样,这里的假设是,在所有引用和发票之间存在相当大的共同信息,这些引用和发票被链接/组合在一起,否则只需要与#1一起使用.

Answer 2

报价更类似于订单.我见过几个分销/零售系统,其订单表有一个名为IsQuote的布尔标志.这看似简单,因为将报价转换为订单变得微不足道.我从来不喜欢它,因为从引号中产生的订单并不总是完全引用.因此,像这样的系统会丢失可能有用的信息(即将报价与订单进行比较的报告).因此,我更喜欢报价和订单表大致相同但又分开的系统.在分销系统中,这通常会导致OrderHeader,OrderLine(与项目/库存表相关),QuoteHeader和QuoteLine等表格.您可能还有一个表来建模关系,其中一个引用可以映射到多个订单.

发票通常来自订单.有时,单个发票上将收到多个订单.例如,在某些情况下,我看到公司每月都会向好客户收费.我还看到它以另一种方式工作,其中多个发货的大订单在多个发票上开帐单(每个发货一个).

最后,付款通常与发票有多对多的关系.有时一笔付款包含多张发票.有时,一张发票可以通过几笔付款获得付款.

Answer 3

[为简单起见，忽略单一产品和服务。]

一个销售报价是建议卖出好并在时间窗（日期范围）价格给另一方。该资产还不需要存在。您可以引用资产（商品）的规格。

报价应该在某个时候到期，并且可能会或可能不会在到期前被接受。

一个销售订单是一个承诺具体日期另一方卖出好价格。它可以从接受的报价中创建。

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

订单可能是针对尚不存在的商品（您出售的是商品，而不是资产）。也许你正在建造它。也许你会从别人那里买。

销售订单导致采购（从库存中提取、制造或购买）实物资产，然后是实物资产的装运，这可能会也可能不会以交付结束。有时，客户“会打电话给”供应商来提货。

一般来说，必须先转移资产，然后才能将订单行计为收入（这取决于您的运输条款，可能是在装运时或交货时或中间）。

可以取消销售订单（例如，某些行业有冷静期）。

一个销售发票是一个付款要求对订购的产品。它可能发生在交货前、交货时或交货后，或者根本没有发生（例如在麦当劳排队）。一个订单可能有一张或多张发票，一张发票可能是几个订单的。

一张发票有望导致一笔或多笔付款，这些款项应用于一个帐户。一笔付款通常会产生一份或多份付款收据。如果使用权责发生制会计，付款不一定与收入相同。