Translate

Monday, March 3, 2014

Pegging On Oracle ASCP


The below Information would be very help Full for you to understand the Scope of the Pegging Report
The MSC Pegging information is stored in the Table MSC_FULL_PEGGING.
This table represents the pegging from supply to demand.
The other two tables connected with the MSC_FULL_PEGGING are MSC_DEMANDS for demands and MSC_SUPPLIES for supplies.

We will take two scenarios where we will see how we the pegging information is stored in the table and how we can interpret the same.

DISCLAIMER
-----------------------

The Logic behind the storage of data in the Pegging tables is internal and is bound to change at any time.


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.

No comments:

Post a Comment