17

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

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

  • 製品はシステム全体で常に同じ（同じID）ですが、在庫（製品ごとに販売可能な販売単位）は場所ごとに異なります。ロケーションYとZの両方に製品Xの販売ユニットがある場合がありますが、たとえば、ロケーションYから2つのユニットが販売された場合、ロケーションZの在庫は影響を受けません。その在庫のあるユニットはまだ無傷です。
  • 場所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を初めて使用するので、実際には、学習体験として、実装を迅速に進めることができず、設計にとどまるのは残念ですが、そうあるべきだと思います。

前もって感謝します。

4

2 に答える 2

24

ここで注意が必要なのは、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がストアで受信されるたびに、正の数量と、、、およびへのFK参照を使用してInventoryTransactionを作成sourcing_order_line_idしproduct_idますlocation_id。

販売が行われるたびに、負の数量とFK参照を使用してInventoryTransactionを作成しorder_line_idます。product_idlocation_idsource_inventory_transaction_id

これ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つの注文ラインを割り当てる場合を処理する必要があります。このデータ構造はこれを処理しますが、ロジックを操作して自分でクエリを実行する必要があります。

于 2012-04-06T01:34:37.577 に答える
3

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

于 2013-11-24T16:47:08.983 に答える