web-dev-qa-db-ja.com

POSおよび在庫データベーススキーマ

基本POSおよび在庫管理システムを作成しようとしています。

考慮すべきいくつかの事柄：

  • 製品はシステム全体で常に同じ（同じID）ですが、在庫（製品ごとに販売可能な販売単位）は場所ごとに異なります。ロケーションYとZの両方に製品Xの販売ユニットがある場合がありますが、たとえば、ロケーションYから2つのユニットが販売された場合、ロケーションZの在庫は影響を受けません。 Itsストックされたユニットはそのままです。
  • ロケーションYから製品Xの1ユニットを販売するということは、ロケーションYの在庫がその在庫から1ユニットを差し引く必要があることを意味します。

それから、私はこれらのテーブルについて考えました：

  • 場所

    • id
    • 名前

  • 製品

    • id
    • 名前

  • トランザクション

    • id
    • 説明

  • inventories_header

    • id
    • location_id
    • 製品番号

  • inventories_detail

    • inventories_id
    • transaction_id
    • 単価
    • 単価
    • 量

  • orders_header

    • id
    • 日付
    • 合計（orders_detail数量*価格から計算。将来のデータ検証のためのみ）

  • orders_detail

    • order_id
    • transaction_id
    • 製品番号
    • 量
    • 価格

さて、それで、何か質問はありますか？もちろん。

  1. ユニットコストの変化を追跡するにはどうすればよいですか？いつか特定の製品にもっとお金を払い始めたら、限界効用を追跡する必要があります（(cost*quantity) - (price*quantity) = marginal utility）なんらかの方法で。私は主にこれのためにinventories_detailを考えました。そうでなければ気にしなかっただろう。
  2. 人間関係はしっかりと確立されていますか？その場所に在庫があるのか​​、それとも在庫に複数の場所があるのか​​、私はまだ考えるのに苦労しています。それは腹立たしいです。
  3. 現在の在庫レベルをどのように維持/把握しますか？コストの更新に対応するために在庫テーブルを分離する必要があったので、inventories_detailに記載されているすべての数量を合計する必要があると思います。
  4. 何か提案を共有したいですか？

まだいくつか質問があると思いますが、ほとんどの場合、これらの質問に対処する必要があります。また、私はRuby on Railsを初めて使用しているので、実際には、学習体験として、デザインで停止するのは残念です。実装をより迅速に実行できるようにしますが、そうあるべきだと思います。

前もって感謝します。

ruby-on-railsdatabase-designpoint-of-saleinventory
15
Andrés Botero

ここで注意が必要なのは、実際にはPOSソリューション以上のことをしているということです。また、在庫管理と基本的な原価計算システムも行っています。

対処する必要のある最初のシナリオは、販売されたアイテムのコストを決定するために使用する会計方法です。最も一般的なオプションは、FIFO、LIFO、または特定の識別（Googleで検索できるすべての用語）です。

3つのシナリオすべてで、商品の購入をデータ構造に記録する必要があります（通常、PurchaseOrderと呼ばれますが、この場合、元の質問の注文テーブルと区別するためにSourcingOrderと呼びます）。

以下の構造は、各ソーシングオーダーラインが1つの場所に対するものであると想定しています（そうでない場合、事態はさらに複雑になります）。つまり、ストアA用に2つのウィジェットを購入し、ストアB用に2つのウィジェットを購入した場合、数量4の1行ではなく、それぞれ数量2の2行を注文に追加します。

_SourcingOrder
 - order_number
 - order_date

SourcingOrderLine
 - product_id
 - unit_cost
 - quantity
 - location_id
_

在庫は1つのレベルにすることができます...

_InventoryTransaction
 - product_id
 - quantity
 - sourcing_order_line_id
 - order_line_id
 - location_id
 - source_inventory_transaction_id
_

SourcingOrderLineがストアで受信されるたびに、正の数量と_sourcing_order_line_id_、_product_id_、および_location_id_へのFK参照を使用してInventoryTransactionを作成します。

販売が行われるたびに、負の数量と_order_line_id_、_product_id_および_location_id_、_source_inventory_transaction_id_へのFK参照を使用してInventoryTransactionを作成します。

_source_inventory_transaction_id_は、負の数量InventoryTransactionから、選択した会計方法を使用して計算された正の数量InventoryTransactionへのリンクになります。

場所の現在の在庫はSELECT sum(quantity) FROM inventory_transactions WHERE product_id = ? and location_id = ? GROUP BY product_id, location_idになります。

限界費用は、販売から2つの関連する在庫トランザクションを介してSourcingOrderラインまでさかのぼって計算されます。

注：注文数量が次に割り当てられる在庫トランザクションに残っているものよりも多かったため、2つの在庫トランザクションに1つの注文ラインを割り当てる場合を処理する必要があります。このデータ構造はこれを処理しますが、ロジックを操作して自分でクエリを実行する必要があります。

19
Brian Glick

ブライアンは正しいです。追加情報を追加するだけです。あなたがあなたのビジネスまたはクライアントのための完全なシステムに取り組んでいるなら。 POSや経理のプロセスに至るまで、組織レベルでの作業を開始することをお勧めします。それはあなたのデータベース体験をより広範囲にするでしょう...：Pシステム開発の私の経験では、在庫モジュールは常に在庫取得+（購入-購入返品）=販売可能なSKUで始まります。 POSは在庫モジュールに直接接続されていませんが、営業監督者によって毎日調整されます。その後、1日の総販売数量が、販売可能なSKUに差し引かれます。原価計算と価格設定のモジュールも作成します。データベースの正しい正規化は常に必須です。

2
koch