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.
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.
Hi Gautham,
ReplyDeleteThanks a lot for the information. I am not able to see the screen shots though...
I would be helpful with the data from the screen shots...
I do not understand the ecstasy in particularly copying and pasting a metalink note...
ReplyDeleteThis is excellent blog. Clarified all Pegging related questions. Thanks for posting.
ReplyDelete