2011-01-06 9 views
1

私は、バックオーダーに置かれた商品の配送日を見積もる際に「スマートな」ロジックを適用するよう求められました。出荷予定日 - カーソル?

Pie in the Sky/Real Fancy Display 単一の購買発注よりもバックオーダーが多い場合は、どの発注書がどの購買発注にコミットするかを計算します適切な日付を表示します。 例:

Open Sales Orders 
SO# 123455 – Req Date 12/15/10 – PN A00Backorder 2 pcs. 
SO# 123462 – Req Date 12/16/10 – PN A00Backorder 7 pcs. 
SO# 123941 – Req Date 12/17/10 – PN A00Backorder 4 pcs. 

Open Purchase Orders 
PO# 987654 – Promised 12/29/10 – 5 pcs. 
PO# 994258 – Promised 1/15/11 – 15 pcs. 

Dates we should be displaying 
SO# 123455 – ESD = 12/29/10 
SO# 123462 – ESD = 1/15/11 
SO# 123941 – ESD = 1/15/11 

私はオープンPO情報を保持するために一時テーブルを作成し、要求された日付順に各オープン販売注文をつかむためにカーソルを使用して、満足し早いPOを得ることができることを知っていますその数量をそのPOから減額する。物事をより面白くするために、私たちはパーシャルを発送します。したがって、最初の注文が7の場合は5を出荷し、残りの2をバックオーダに配置します。したがって、それは "12/29/10に出荷され、残りの2つは1/15/11に出荷される"のようなものになります。どんな勧告?

+2

SQLではなく呼び出し側アプリケーションでロジックを実行することをお勧めします。アイテム、表示される日付、および数量をテーブルに取り込み、そのデータをアプリで使用します。 – JNK

+1

このようなコードはSQLで行うことができますが、そのための最良のツールではありません。レンチで釘を打つこともできますが、それは良い考えではありません。 – JNK

答えて

1

これは単一のSQL文で行うことができると思われますが、それは非常に複雑で、試してみるのは難しいでしょう。 (誰かが、おそらく私の投稿の数分以内に間違っていることを証明するでしょう。)手続き型コードをループすることは、ここの一日のようです。

ちょうど私の頭の上から、私はおそらく同じようseomthingんだろう:

  • は、販売 Purcahse活動のリストを生成日によって最初に注文した後、(その後、活動を購入する)ことにより、
  • 各行が処理されるにつれて、使用可能なアイテムのプールを追跡し、増分(購入)または減分(売上)を追跡して、このリストを反復してカウンタ(使用可能なユニット)必要に応じて
  • 各販売アイテムが現れたら、使用可能な部品の量に応じて、完全または部分的な履行を示す新しいエントリ(新しいテーブル?)を作成し、まだ完全に処理されていない販売を追跡します。

これはすべて推定値です。このルーチンで生成されたデータを保持する必要はありませんか?

+1

@ JNKに同意します.T-SQLより手続き型コードで実装する方がはるかに簡単です。 –

関連する問題