I have one doubt regarding repegging of sales order to different PO.

What is driving the sales order to peg to a new PO from one day to the next ie one day the plan output shows SO A pegged to PO A but the next day it may be pegged to PO B. So my question is what are the factors driving this change? Thanks in advance

As your supply demand picture changes, pegging changes as well. e.g. on Day1, you had a SO1 dated 6/1/09 and it was pegged to a PO due to arrive on 5/1/09. But then you got a big new sales order and the new sales order is dated 5/15/09. Now the plan is going to peg the new sales order to this PO and your old SO is going to get pegged to a different PO. The only time this won't happen is when you have back-to-back orders and when you consider reservations in the plan. In other cases, the pegging will always be dynamic. Hope this helps.

ASCP Pegging Information Logic

The Logic behind the storage of data in the Pegging tables SCENARIO - 1 ============== Consider we have a Finished Good Item A with the following BOM [Bill Of Material] A -> Finished Good Item B -> Subassembly Item C -> Purchased Good. Consider we have a Forecast for the Item A, for quantity 100. So after running the Plan the pegging would like below in the UI [User Interface / Planners Work Bench]... Forecast Demand for A - Planned Order for A - Planned Order demand for B - Planned Order for B - Planned Order demand for C - Planned Order for C

How is this seen in the Database Tables. -----------------------------------------------------------The Demands are stored in the table MSC_DEMANDS Say it looks something like this >>

The ORIGINATION_TYPE is actually a number. represented here as a meaning for better understanding. The Supplies are stored in the table MSC_SUPPLIES Say it looks something like this >>

How the above is hooked up in the MSC_FULL_PEGGING Say it looks something like this >>

So as we see there would be three rows showing which demand is pegged to which supply. The Supply here is the TRANSACTION_ID. The below is what you are seeing. >> Forecast Demand for A - Planned Order for A - Planned Order demand for B - Planned Order for B - Planned Order demand for C - Planned Order for C The relation between the Planned Order Demand of B with the forecast demand of A is stored in the PREV_PEGGING_ID . The END_PEGGING_ID is the top demand in the whole chain. SCENARIO - 2 ============= If we consider the quantities and we have 2 Forecasts in our Scenarios then how would the pegging

work. Consider we have a Finished Good Item A with the following BOM [Bill Of Material] A -> Finished Good Item B -> Subassembly Item Consider we have a Forecast F1 for Item A for quantity 10 Consider we have another Forecast F2 for Item A for quantity 15 So after running the Plan the pegging would like below in the UI [User Interface / Planners Workbench] Forecast Demand F1 for A for quantity 10 - Planned Order for A for quantity 25 Pegged quantity 10 - Planned Order demand for B for quantity 25 Pegged Quantity 10 - Planned Order for B for quantity 25 Pegged Quantity 10 Forecast Demand F2 for A for quantity 15 - Planned Order for A for quantity 25 Pegged quantity 15 - Planned Order demand for B for quantity 25 Pegged Quantity 15 - Planned Order for B for quantity 25 Pegged Quantity 15 How is this seen in the Database Tables. -----------------------------------------------------------The Demands are stored in the table MSC_DEMANDS Say it looks something like this >>

The ORIGINATION_TYPE is a actually a number represented here as a meaning for better understanding.

The Supplies are stored in the table MSC_SUPPLIES Say it looks something like this >>

How the above is hooked up in the MSC_FULL_PEGGING Say it looks something like this >>

The relation between the Planned Order Demand of B with the forecast demand of A is stored in the PREV_PEGGING_ID . The END_PEGGING_ID is the top demand in the whole chain.

SCENARIO - 3 ============= If we consider the quantities and we have 2 Forecasts in our Scenarios then how would the pegging work. Consider we have a Finished Good Item A with the following BOM [Bill Of Material] A -> Finished Good Item B -> Subassembly Item Consider we have a Forecast F1 for Item A for quantity 10. Consider we have another Forecast F2 for Item A for quantity 15. Also we have a On hand for Component B with quantity 5. So after running the Plan the pegging would like below in the UI [User Interface / Planners Workbench] Forecast Demand F1 for A for quantity 10 - Planned Order for A for quantity 25 Pegged quantity 10 - Planned Order demand for B for quantity 25 Pegged Quantity 10 - Onhand for B for quantity 5 Pegged Quantity 5 - Planned Order for B for quantity 20 Pegged Quantity 5 Forecast Demand F2 for A for quantity 15 - Planned Order for A for quantity 25 Pegged quantity 15 - Planned Order demand for B for quantity 25 Pegged Quantity 15 - Planned Order for B for quantity 20 Pegged Quantity 15 How is this seen in the Database Tables. -----------------------------------------------------------The Demands are stored in the table MSC_DEMANDS Say it looks something like this >>

The ORIGINATION_TYPE is a actually a number. represented here as a meaning for better

understanding.

The Supplies are stored in the table MSC_SUPPLIES Say it looks something like this >>

How the above is hooked up in the MSC_FULL_PEGGING Say it looks something like this >>

The relation between the Planned Order Demand of B with the forecast demand of A is stored in the PREV_PEGGING_ID . The END_PEGGING_ID is the top demand in the whole chain.