またはInvoicesに関連付けられたインベントリから作成されたテーブルがあります。在庫と請求書の中間にテーブルを使用することもできますが、「これは見積もりですか?」を処理するためだけに、データ構造とロジックが重複しているように感じます。少し。JobOrderQuotes
ビジネスの観点からは、見積書は請求書とは異なります。見積書は請負の前に送信され、請求書は完了して支払いが期日になったときに送信されますが、これをリポジトリとモデルでどのように表現するか。
編集：この特定のインスタンスに対してJob===を示しました。Order
3つのアプローチがあります：
請求書と見積もりを別々のテーブルに保存します。
これは、請求書と見積もりに重複するフィールドがほとんどない場合（または、3つのテーブルでオプション＃3を使用する場合）、およびそれらの間に1対多または多数の関係がある場合（1-1の場合、オプション＃2を使用）に適した設計です。 ）。
これは、見積もりが請求書になったときに2つの間で「共有」された情報が実際に変化する可能性がある場合にも適しています（ただし、これらの変化の一部は、適用された割引など、別々のフィールド/テーブルで適切に処理する必要があります。 。）。
複数の見積もりが単一の（または複数の）請求書に変換される場合は、このオプションのわずかなバリエーションを実行する必要があることは明らかです。これにより、見積もりのセットと請求書（または複雑になる場合は請求書のセット）の間のマッピングである3番目のテーブルが追加されます。
それらを同じテーブルに保存し、追加のフラグ「請求書または見積もり」と両方の追加のフィールドを保存します。これは、請求書と見積もりを別々の行に配置するか、行を共有することで実行できます（フラグにも「両方」の値があります）。
後者（同じ行を請求書と見積もりの両方にすることができます）は、 1対1でマップされており、2つを区別するフィールドがほとんどない場合に適しています。
前者（請求書と見積もりの行を分ける）は、一般的にはさまざまな優れた設計ではなく、＃3または＃1のオプションを使用した方が適切です。
3つのテーブルがあります。1つは2つの間の共通フィールド用で、2つは請求書のみと見積もりのみ用です。
これは、請求書と見積もりが1対1でマッピングされている場合、または1対多であるが、多くの請求書のそれぞれが、共通のフィールドに対してまったく同じフィールド値を持っている場合に適しています。それ以外の場合は、＃1を使用します。
複数の見積もりが単一の請求書に変換される場合、このオプションのわずかなバリエーションを実行できます。これにより、4番目のテーブルが追加されます。これは、一連の見積もりと、それらのインコイス（または複雑になる場合は一連の請求書）の間のマッピングです。繰り返しになりますが、ここでの前提は、すべての見積もりと請求書の間にかなりの量の共通情報がリンク/結合されていることです。それ以外の場合は、＃1を使用します。
見積もりは注文に似ています。IsQuoteのような名前のブールフラグを持つ注文テーブルを備えたいくつかの流通/小売システムを見てきました。見積もりを注文に変換するのは簡単なので、これは単純に思えるかもしれません。見積もりから出てくる注文は必ずしも見積もりどおりではないので、私はそれが好きではありませんでした。その結果、そのようなシステムは、何らかの有用な情報（つまり、見積もりと注文を比較するレポート）を失います。したがって、見積もり表と注文表がほぼ同じであるが別々であるシステムを好みます。流通システムでは、これにより、OrderHeader、OrderLine（アイテム/在庫テーブルに関連）、QuoteHeader、QuoteLineなどのテーブルが作成されることがよくあります。また、1つの見積もりを複数の注文にマッピングできる関係をモデル化するためのテーブルがある場合もあります。
請求書は通常、注文から発生します。1つの請求書に複数の注文が請求される場合があります。たとえば、企業が優良顧客に毎月請求するのを見たことがあります。また、複数の出荷を伴う大量注文が複数の請求書（出荷ごとに1つ）で請求されるという逆の方法でも機能することを確認しました。
最後に、支払いは通常、請求書と多対多の関係があります。1回の支払いで複数の請求書がカバーされる場合があります。1つの請求書が2回の支払いで支払われる場合があります。
[簡単にするために、単一の製品とサービスは無視されます。]
販売見積は、時間枠 (日付範囲) 内の価格で商品を別の関係者に販売するための提案です。このアセットはまだ存在している必要はありません。資産 (商品) の仕様を引用できます。
見積もりはある時点で失効する必要があり、失効前に受け入れられる場合と受け入れられない場合があります。
販売注文とは、商品を特定の日付の価格で別の当事者に販売することを約束することです。承認された見積もりから作成できます。
注文または見積もりには、「配達後 30 日以内に支払うことができます」などの支払い条件が含まれる場合があります。
注文は、まだ存在しない商品に対するものである場合があります (資産ではなく、商品を販売します)。多分あなたはそれを構築しています。たぶん、あなたはそれを他の人から買うつもりです。
販売注文は、物的資産の調達(在庫からの取得、製造または購入) につながり、次に物的資産の出荷につながります。場合によっては、顧客がベンダーにアセットの受け取りを「電話」することがあります。
一般的に言えば、注文明細行を収益としてカウントする前に、資産を譲渡する必要があります(これは出荷条件によって異なります。出荷時、配送時、またはその間の場合があります)。
販売注文は取り消すことができます(たとえば、業界によってはクーリング オフ期間があります)。
売上請求書は、注文された製品の支払いの要求です。配達前、配達中、または配達後に発生する場合もあれば、まったく発生しない場合もあります (マクドナルドの列に並んでいる場合など)。注文には 1 つ以上の請求書が含まれる場合があり、請求書は複数の注文に対応する場合があります。
請求書は、アカウントに適用される1 つまたは複数の支払いにつながることが期待されます。多くの場合、支払いは 1 つまたは複数の支払いの受領につながります。発生主義会計を使用している場合、支払いは必ずしも収益と同じではありません。
できるだけ柔軟にすることをお勧めします。次の表を使用してください
ジョブテーブル、請求書テーブル、見積もりテーブル
請求書テーブルと見積もりテーブルに、ジョブIDを保存し、それにインデックスを付けて、外部キー制約を作成します。クラスター化されたインデックスを見積もりIDと請求書IDに残します。
最後のシステムでは、見積もりと請求書の唯一の違い（データベースに関して）は、見積もりが顧客に受け入れられたかどうかを示すテーブル上のフラグでした（その時点で、別のステートメントがすべて同じで生成されました）見積もりではなく請求書であったことを除いて、情報）