探しているソリューションは、会計スタイルモデルといくつかの部品表（BOM）に依存します。主なエンティティタイプは次のとおりです。
-
SKU これはあなたが売るもののリストです。プロパティには、製品の説明や現在の小売価格などが含まれます。あなたは空想を得て、時間の経過とともに価格を与える子テーブルに価格を分割することができます。今のところ、そのしわを残しておくと仮定しましょう。一部のSKUは、あなたが話している種類の「コンボ」である可能性があります。
-
コンポーネント これは、ナプキン、カップ、パン、パテ、コークスシロップなど、SKUを構成するもののリストです。例を使用します。 SKUに説明と価格があるのと同じように、コンポーネントには説明と単価があります。 （これは子テーブルで履歴を作成することもできます。）このテーブルは、通常、ROPも格納する場所です。
-
構成 これは、SKUとCOMPONENTを交差させ、各COMPONENTのユニットがSKUのユニットにいくつ入るかを示すBOMです。 2つのSKUを交差させるには、これらの1つが必要です（コンボの場合）。これには、1つのテーブルまたは2つのテーブルのいずれかを使用できます。 2つのテーブルは純粋主義者を幸せに保ち、1つのテーブルはコーダーの観点から便利です。
-
セール これは、1つ以上のSKUの販売を記録するためのヘッダーを提供するトランザクションテーブルです。このテーブルには、取引日、レジ係ID、その他のヘッダー項目などが含まれます。
-
SALE_ITEM これは、どのSKUが販売されたか（およびその数）とその金額を含むトランザクション詳細テーブルです。販売時のSKU価格の非正規化はいくらですか。ただし、価格の特別なオーバーライドを含めることもできます。 SKUに実際に請求された価格は、非正規化するのに適しています。誰かがSKUの定価を編集すると、その時点でアイテムに実際に請求された金額がわからなくなる可能性があるためです。
-
INVENTORY_HDR これは、概念的にはSALEに似たトランザクションテーブルですが、新しい在庫の受け取り、在庫の使い切り（販売時など）、在庫調整などの在庫トランザクションのヘッダーです。繰り返しになりますが、これは日付/説明の内容になりますが、必要に応じて、販売である在庫移動のSALE_ITEMへの直接リンクを含めることができます。そのようにする必要はありませんが、トランザクションごとに収益とコストの関係を確立したい人もいます。
-
INVENTORY_DTL これは在庫取引の詳細です。これは、どのCOMPONENTが出入りしているか、出入りした数量、およびこの移動が適用されたINVENTORY_HDRトランザクションを示します。これは、コンポーネントアイテムに支払われた実際のコストを保持する場所でもあります。
-
場所 （必要に応じて）受け取って使用/販売する在庫の物理的な場所を追跡することもできます。レストランでは、これは重要ではないかもしれませんが、チェーンを持っている場合、またはレストランに成分成分のオフサイト倉庫がある場合は、気にするかもしれません。
次のERDについて考えてみます。
収益会計を行うには、SALE_ITEMテーブルに記録されている金額を合計します。
在庫レベルが計算されます 各コンポーネントのINVENTORY_DTLインとアウトの合計に基づいています。 （現在の在庫レベルをテーブルに保存しないでください-これは調整の問題を引き起こす運命にあります。）
原価計算を行うには、INVENTORY_DTLテーブルに記録されている金額を合計します。通常、どれが正確にわからないことに注意してください。 販売したナプキンまたはパン。特定のコンポーネントのレセプトを特定のSKUの売上にリンクすることはできません。代わりに、特定のSKUに使用されたコンポーネントを決定するための規則が必要です。使用する必要のある規則を指定する会計規則がある場合があります。ほとんどの人はFIFOを使用します。一部の業界ではLIFOを使用しており、加重平均コスト会計も見たことがあります。