[ASCP] PO 的先進先出分配

    我們會將 ASCP Reschedule 的結果拋回 ERP，而且要求廠商依照我們的 Need by Date 交貨，但廠商反映給採購一個問題，明明是比較晚開立的 PO，Need by Date 卻比較早。


    例如，同一個料號有兩張 PO，一張是在一月份開立，一張是在二月份開立，但偏偏現在(五月份) ASCP Plan 出來的結果，二月份開立的 PO，其 Suggest dock date 卻比較早。

     這個議題困擾我很久，採購與廠商要求越早發出的 PO，應該交期越早，這樣的需求並沒有錯，偏偏 ASCP 的結果卻不是這樣。

    ASCP 的四種 Pegging Method 我讀了再讀，各種 Pegging Logic 雖有不同，但最終還是會有 FIFO 分配隱含在裡面，可惜 ASCP 是怎麼決定 FIFO ，從結果看不出來。

    文件上解釋 分配邏輯時，只說日期越早的優先分配，但並沒有交代這個所謂日期，用的是什麼日期(如果按照我們的期望，就是 PO 被 Approved 的日期)。
 
    我花了一段時間測試發現，ASCP 做 FIFO 分配時用的日期，是 MSC_SUPPLIES 的 NEW_SCHEDULE_DATE 或 OLD_SCHEDULE_DATE，時間緊迫，我索性兩個一起改掉。

    這必須改 Data Collection 那組的資料，也就是 plan_id = -1 的資料。我在 Data Collection 後增加了一段客製程式，先將各料號的 PO 按照 PO Number 做排序(在我們這邊，其結果基本等同用 PO Approved Date 做排序)，然後以每一筆 PO Shipment 間隔一個禮拜的方式，將 MSC_SUPPLIES 的 NEW_SCHEDULE_DATE 或 OLD_SCHEDULE_DATE 覆寫。

    例如，假設 A 料號有三張 PO Shipment，我就會把他的兩個 schedule date 放在下週、下下週與下下下週(連續三週)。
   
    有一點很重要，必須放在未來的時間。一開始我只是將 PO Approve Date 覆寫到兩個 Schedule Date，乍看之下也已經先進先出排序了，不過實測後結果不如預期。我花了一段時間才發現，如果放在一個過去時間，則 ASCP 會把這些 PO 視為同一天(推測會視為 Plan 當天)，同一天的 PO 誰會先被 Pegging，就依照各個不同 Pegging Method 的 Logic 了。

     我目前使用的 Pegging Method 是 Priority Pegging，但我有另外測過 Standard 與 Priority + FIFO 兩種 Pegging Method，這招在三種 Pegging Method 下都可以達到我們希望的效果。