As of SAP Enhancement Package 7 for SAP ERP 6.0 (release 617), a new table was introduced on the standard system to store the planning file entries of the MRP Fiori apps.

This table should be updated after each MRP relevant change that should affect the MRP Fiori Apps, similarly to the existing MRP planning file entries.

However, this update should only happen if the ERP on SAP HANA with HANA optimization for MRP (business function LOG_PPH_MDPSX_READ activated) and the MRP Fiori apps are running (areas of responsibility SDM_AOR are maintained).

In some specific scenarios, however, entries were created and updated on this table even when the above pre-requisites were not met.

This unnecessary update of this table on systems where HANA is not being used could lead to performance issues or deadlocks in extreme cases.

Notes with corrections to avoid this issue were already created and the issue should be fixed on the standard system, however, if you have already upgraded to release 617 or if you are planning an upgrade, you should ensure that the following notes are implemented on your system:

For more information about the HANA optimizations available for MRP on release 617, take a look below:

MRP on HANA: What's new?

For more information about the MRP Fiori Apps, check the following blow:

Using SAP Fiori to manage shortages on MRP

This post is describing how KBED entries are changed according to the status of production order.

Basics

Table KBED saves capacity requirement records. Field BEDID is key field of table KBED, and also the linking field between table AFKO and KBED. And there are 6 important fields which contains scheduled capacity requirements and remaining capacity requirements for segments.  Each operation of production orders has 3 segments: set up, processing and tear down.

1. Status CRTD

When create an production order, capacity requirement entries are created for each operation. If multiple capacity categories are assigned to the correcponding work center of the operation, e.g. 2 capacity categories, then 2 entries are created in table KBED for this operation.

For example,

• The formulas are maintained as below in Capacity view of Work Center.
  Setup formula = Standard formula SAP005  = Setup * Operation Splits
  Porcessing formula = Standard formula SAP006 = Machine * Operation quantity / Base qty
  Teardown formula = blank

• Routing has 2 operations.
  Operation 0010 has standard values as Setup = 1 Hour   Processing = 1 Hour
  Operation 0020 has standard values as Setup = 2 Hours Processing = 2 Hours

When create an production order with qty 10, capacity is caculated as below.

Operation 0010

• Setup = Setup standard value(1 H) * Operation Splits("No. of individula capacity" maintained in Capacity details, 1 this time) = 1 Hour
• Processing = Machine standard value(1 H) * Operation qty(10 PC) / Base qty(1 PC) = 10 Hours

Operation 0020

• Setup = Setup standard value(2 H) * Operation Splits("No. of individula capacity" maintained in Capacity details, 1 this time) = 2 Hour
• Processing = Machine standard value(2 H) * Operation qty(10 PC) / Base qty(1 PC) = 20 Hours

You can see 2 entries in table KBED for 2 operations. I will only explain the change for operation 0010. Operation 0020 is the same.

For Setup segment, the scheduled capacity requirement(KRUESOLL) and remaining capacity requirement(KRUEREST) are 1 H; For processing segment, the scheduled capacity requirement(KBEASOLL) and remaining capacity requirement(KBEAREST) are 10 H.

2. Status PCNF

When partial confirmation is executed, remaining capacity is reduced accordingly, based on the remained order qty, scheduled capacity requirement does not change. This time, partial confirmation with qty 2 is executed. For Setup segment, scheduling capacity requirement(KRUESOLL) remains same, remaining capactity requirement(KRUEREST) does not change too, because the parameters of setup formula are not related to order qty. For Processing segment, scheduling capacity requirement(KBEASOLL) remains same, remaining capacity requirement(KBEAREST) is changed to 8 hours, since remaining order qty is 8.

3. Status CNF

When final confirmation is executed, remaining capacity requirement(KRUERESR & KBEAREST) becomes ZERO, scheduled capacity requirement(KRUESOLL & KBEASOLL) does not change.

4. Status TECO

When technically close an order, capacity requirement entries are deleted.

When revoking TECO, capacity requirement entries are regenerated.

5. Status CLSD

When close an order, capacity requirement entries are deleted.

The Purpose of this document is to explain the significance of “Storage Location MRP”. This feature gives you flexibility to:

1) Exclude storage location stock from MRP

2) Plan storage location stock separately

Material requirement planning generally runs at plant level. When you run it for a material, system sums-up total stock from all storage locations and considers it as "available stock" to fullfill the demand elements.

The control of "storage location MRP" on Material Master is maintained in MRP 4 view:

 
 
Let’s consider a raw material RM0001 maintained in plant FP01. This material is extended to storage locations SL01 and SL02. I have kept both the Sloc as non WM managed in order to simplify the example.

RM0001 has following stocks in 2 storage locations

SL01 – 20

SL02 – 50

FP01 = 70 (Plant Stock = 20 + 50)

The stock requirement list shows:

Case 1: When the indicator is blank " "

This is the default case where stock of material at storage location is considered for MRP run (Plant level). This is the default case in which total stock (70) of all storage locations is used together in MRP at plant level.

Case 2: With indicator “1”

The storage location stock gets excluded from MRP

Example: let’s set this indicator “1” for sloc SL01 (with 20 quantity)

MRP 4:

Now if we check MD04 for same stock situation we will see 20 Qty is excluded from total plant stock:

The important point to note here is that total 70 is still "unrestricted quantity" and available for use but since we have set indicator “1” in SL01, the sloc stock will get EXCLUDED in MRP run. This means that we can still consume 20 qty via goods issue but system ignores it in Planning run (MRP).

Now if there is demand for this material for 60 quantities

System will only consider 50 for MRP calculation and ignore 20 from SL01 (excluded)

After MRP:

There is a demand of 60 and out of which 50 is covered by stock in MRP calculation and system finds a deficit of 10 quantities. Even though there is an extra stock of 20 in SL01 but since we have excluded it from MRP run, system generates a purchase requisition of 10 quantities.

Case 3: with indicator "2"

Storage location stock is planned separately

Separate storage location MRP is carried out using consumption-based planning. In this case, one must define a reorder level and a replenishment quantity (fixed lot size) at storage location level. In so doing, now if the stock level falls below the reorder level in that perticular the storage location, its considered in MRP run.

MRP 4 settings

Consider current stock as below:

SL01 as 10 - to be planned separately

SL02 as 50

Sicne the current stock (10) level is below reorder point  (15) and it should be considered in MRP run. As shown in below expample, for requirement of -25 system create a transfer requirement of 25 quantity from SL02 as stock is already present in different storage location under same plant.

After MRP run

Once the transfer posting is made against the reservation, stock situation looks like this:

Stock from SL02 has moved to SL01

Apart from transfer posting with movement 311, there are possibilities to use special procurement key for Sloc to be planned separately.  They can be maintained in MRP 4 at storage location details:

Scenario 1

Material RM0001 in plant FP01 in Sloc SL01 (Storage location to be planned separately with SPK 40 – Stock transfer)

Reorder point –  15

Replenishment Quantity - 25

Current Stock of RM0001 – 10 (below reorder point)

Demand plant - FP01

Supplying plant - FP02

MD04 in Demand Plant FP01

After MRP run:

System creates a planned order that can be converted in Purchase requisition then to Stock Transfer order

STO gets created with Suppling plant as FP02

After Goods Receipt, the stock gets updated

Default Storage location MRP setting in SPRO

You can also set default setting of Storage location MRP customizing under below path:

Production > Basic Data > Material Requirement Planning > Planning > Define Storage Location MRP per Plant (OMIR)

If you set this indicator in custominzing then system will propose same settings at the time of creating new material master record. 

Incase materials are already extended to a perticular storage location and you set OMIR settings later, then system will not set these settings automatically in MRP4 view. One has to set them manually in material master record.

Situations where such Indicator is useful:

1. When you want to have some quantity of material separate for specific purpose (only for manual goods issue)

2. When you DO NOTwant to have a particular material considered for net requirement planning.

3. When stores / warehouse is geographically too far from the production location that is planned with the storage location MRP

4. When stock of a storage location is only available for service and not for production

etc...

There could be multiple other cases where Storage Location MRP functionality can be used instead of setting up complex scenarios.

* Request all readers to please suggest other possible cases, if they have come across any, so that this documents can be updated and improved with the course of time.

Thank you for reading.

The BOM selection logic is quite complex as several customizations and fields of the material master are involved, so I am summarizing it here.

First of all, the BOMs of a material may exist in the architecture below.

1. Usage: e.g. production BOM, costing BOM, engineering BOM etc.
2. Multiple BOM: Multiple alternative BOMs under one usage.
3. BOM change status: Different BOM items/quantities etc in different periods which can be made by change numbers.

Please see the picture below.

The BOM determination in MRP is done level by level through the structure above and by the procedure below.

Here is the detail of the steps.

Step 1: Determine the BOM usage.

The usage is determined by the selection ID which can be configured in customizations below. In the MRP customization, the selection ID to be used is defined on plant level and the BOM customization OS31 defines the priorities of each BOM usage. If there is no BOM exists under the usage of the first priority, the usage of the next priority is checked.

Step 2: Determine a BOM in the multiple alternative BOMs.

This is decided by the field 'Selection method' of the material master in the picture below.

2.1 Selection method is blank (Selection by order quantity):

The quantity range of each BOM header is checked to see which BOM can be applied according to the order quantity, here is a picture for an example.

Here is the screen shot of the quantity range of multiple BOMs.

2.2 Selection method is 1 (Selection by the explosion date):

To use this method, the customization of the picture below should be maintained.

In the example above, the alternative BOM 1 is valid from May 1 to May 31 and the BOM 2 is valid since June 1. They are selected by the explosion date, either the order start date or the end date or the date of the explosion number according to the customization transaction OMIW in the picture below.
The one of the MRP group has higher priority.

2.3 Selection method is 2 or 3 (Selection by production version):

The production version can be maintained in the material master and it defines both the BOM usage and alternative BOM as the picture below.

Step 3: Determine the valid BOM according to the BOM change status.

A valid BOM is determined by the explosion date in multiple periods of an alternative BOM as shows in the picture below, the periods can be made by change numbers.

The explosion date is the one explained in the step 2.2 and here is more information of the date of explosion number. Using the explosion number all levels of BOM are exploded by the same date of the explosion number as showed in the picture below instead of the start or the end date of planned orders in each level.

Here is the explosion number maintenance transactin MDSP and the fields where the explosion number can be entered in the PIR (Planned Independent Requirements) and sales order.

Additional checking points:

1. BOM header

2. BOM Item:

The BOM item should be relevant to production.

3. Customization of specific BOM explosion:

The field 'Excl.Bulk Mat.' controls if the bulk materials can be exploded.
The field 'Sales Order/WBS' can check whether the sales order BOMs or WBS BOMs can be exploded if they have.

4. BOM buffering:

To improve the performance of MRP, the exploded BOM can be buffered and MRP reads that onward instead of reading from tables unless the BOM is changed. Please pay attention to the statements below in the F1 help of the field above.

********************************************************************

Note that you should not switch off this indicator and then switch it on again a short time later, because then the BOM time stamps are no longer current. In this case, the wrong BOMs could be used. However, you can delete the buffered BOMs in the shared buffer using the report RMMDBOM1.
********************************************************************

For more information, please refer to blog Problems with BOM explosion on MRP (Exception message 52).

In some situations, we want to have a specific material planned on a regular basis by MRP, even when there was no MRP relevant change for this material and the planning file was not set.

This is generally necessary when a planned order was created outside the opening period. If there was no MRP relevant change, this material will not be planned again by MRP and a purchase requisition will not be created when the planned order reaches the opening period.

One of the possible solution is to run a regenerative planning run (processing key NEUPL), however, with this key all the materials will be planned and this is a frequent cause of performance issues.

Another option is to use the setting "plan regularly" on the MRP type and this blog will explain how to use this setting. With this setting, a material can be planned on a regular interval, defined on the MRP group.

The first step is to create an MRP type on the customizing transaction OMDQ where the flag "plan regularly" is set on customizing. On the following example I have created a new MRP type Z2 as a copy of the standard MRP type PD, just setting this flag.

The second step is to define a "Maximum MRP interval" for the MRP group on the customizing transaction OPPR.

On this example, we have defined an interval of 7 days, which means that this material will be planned by MRP 7 days after being planned for the last time.

After that, ensure that the MRP type and the MRP group were assigned to your material on transaction MM02.

Now, if you run MRP for your material, you can observe on transaction MD21 that a planning date has been set on the planning file. This material will be planned again by MRP after the planning date, even if there was no MRP relevant change for this material.

On this example, MRP was executed for this material on 03.06.2015, therefore, considering that we defined a maximum MRP interval of 7 days for this material, the planning date calculated was 10.06.2015.

Therefore, with the above settings we can ensure that some materials are planned regularly, without using the processing NEUPL.

It means that this material will be planned again if you run MRP on 10.06.2015 or after, even if the planning file has not been set in this period.

If this material is planned again by MRP before 10.06.2015, a new planning date will be calculated, considering the maximum MRP interval.

"Shift Order" indicator in customizing tcode OPU3 controls if the actual dates of the partially confirmed operations are taken into account during a new scheduling run.

Prerequisite

1. Create a production order in tcode CO01 and release it. Scheduling is automatically executed.
   
   Operation 0010 starts on 2015.6.2 and ends on 2015.6.4.
   
   Operation 0020 starts on 2015.6.4 and ends on 2015.6.6.
   
2. Execute partial confirmation with 5 qty for operation 0010 in tcode CO11N on 2015.05.28.
   

When "Shift Order" is ON

System ignores the existing actual dates as if no confirmation happeded, and shift the order to the dates when re-scheduling is executed.

Execute scheduling by clicking the scheduling icon in tcode CO02.Today is 2015.6.4.
Check the rescheduling result. The planned start date was on 2015.6.2, now it starts on 2015.6.4, the date when re-scheduling is executed.

You can also check the "Confirmed dates" view. The order qty is 10, 5 of them has been confirmed on 2015.5.28, the other 5 starts from current date 2015.6.4.

When "Shift Order" is OFF

System takes actual confirmed dates 2015.5.28 in to consideration during re-scheduling.

Execute scheduling by clicking the scheduling icon in tcode CO02. Check the rescheduling result. The planned start date was on 2015.6.2, now it starts on 2015.5.28, the actual dates when the partial confimation was executed.

You can also check the dates in "Confirmed Dates" view. Start time is same as the actual confirmed dates.

Scheduling internally converts the dates in seconds relative to a reference date (1980.1.1). It is called PIT time. E.g. 1 o'clock on 1980.1.1, 1 hours is 3600 seconds, so this date/time is represented as 3600 internally.

Reference date 1980.1.1 is hard-coded. Only date between 1980.1.1 and 2048.1.1 can be converted without problem. Considering 2048 is approaching, you can use note 49257 to change the reference date.

Sometimes the scheduling result is hard to be explained, you want to analyze it via debugging. However, the dates are a long number in internal calculation. Report CYDATTIM can be used to get the real date/time.

Execute report CYDATTIM in t-code SE38

There are 5 fields.

• DATED - Real date
• TIMED - Real time
• DATEI - Integer format for date
• TIMEI - Integer format for time
• PIT - seconds from reference date

In this sample, PIT equals to 1,123,722,816, what is the real date/time for this PIT? It is 2015.8.11 01:13:36.

A dump below with error CO889 occurs if there are more than 99 phantom materials on one level of BOM when a production order is created.

The cause is that the length of the field keeping the number of phantoms is only 2 so it cannot hold the number greater than 99. The adjustment of BOM structure is necessary in order to avoid the dump, e.g. reduce the number of phantom materials on the same level of BOM, but it is sometimes difficult to find the phantoms if the BOM is very big. Thus, a report is developed to find them and show.

It's source code can be found in the wiki below.

http://wiki.scn.sap.com/wiki/display/ERPMan/BOM+checking+tool+for+the+dump+with+error+CO889+while+creating+production+orders

Here is the selection screen.

This can be used to check the material BOM, sales order BOM, WBS BOM, and the material number/plant/usage should be entered whichever BOM need to be checked.

1. 'MAXLEVEL' is for restricting the BOM explosion up to that level for better performance.
2. ORD_NUM and ORD_ITEM are for sales order number and its item.
3. WBS is for the WBS number.

If no sales order number or WBS number is entered, the material BOM is checked.

Here is the result.

At the top, it shows the number of phantoms and the level where the phantoms are located. The column 'Count Phantoms' shows the number of of each phantom till the current one on the same level, so, scroll down to the last phantom can show the total number, the material number of phantoms and the numbers of phantoms therefore can be identified.

More information can be found in the result screen as following.

Please feel free to let me know if this can help or any suggestions to make it easy to use.

There are several parameters below in the initial screen of MRP execution transactions like MD01, here, I am summrizing their usages and also introduce how they work with their corresponding customizations.

• Scope of planning.
• Processing key
• Create purchase requisition
• Create MRP list
• Planning mode
• Scheduling
• Planning date
• Parallel processing
• Display Material list
• User exit key
• User exit parameter

1. Scope of planning:

It can group multiple plants and MRP areas, so those can be run together by one time execution.

Customization transaction code: OM0E

2. Processing Key:

NEUPL:  Regenerative planning, all materials whose MRP type is not ND are planned.
              Technically speaking, the materials who have planning file entries in transaction MD21.

NETCH:  All materials whose MRP relevant objects have been changed and that actions changed the stock requirement situation are planned.
              Technically speaking, the materials who have the indicator NETCH get set in the planning file entry are planned, this is for improving the MRP   
              performance.

NETPL:  Only materials which had MRP-relevant change in the planning horizon since the last planning are planned and requirements in the planning horizon
              are covered. 

Planning Horizon of NETPL:

For plant: Customization transaction, OPPQ > Planning Horizon
For MRP group: Customization transaction, OPPR > Planning Horizon

3. Create Purchase requisition:

• Purchase requisitions
• Purchase requisitions in opening period
• Planned order

Opening period: MRP creates planned orders first internally, if the planned orders whose opening date is earlier than today or the same, then they are converted to purchase requisitions.

The scheduling margin key is entered in the material master, and the opening period can be defined in the customization below for the schedule margin key.

This can be maintained in several places below and they have priorities for total planning (MD01/MDBT or MS01/MSBT or MD40/MDBS) .

Priority  
1            MRP group  (Other execution parameters can also be maintained here.)
2            Plant
3            Initial screen

4. Planning Mode:

Values
1            Adapt planning data (Normal mode)  -  Only process the changed data
2            Re-explode BOM and Routing          -  Read the BOM and routing again for the existing proposals
3            Delete and recreate planning data     - Completely delete the MRP data and create again

Note:
planning mode 3 is not suggested for better performance unless it is really necessary, mode 1 and 2 is generally sufficient in business.

5. Scheduling:

Values:
1  Basic Scheduling
2  Lead time Scheduling

6. Planning Date:

This is only valid for time-phased planning. In time-phased planning, we can run materials on specific date only, e.g. every Tuesday, the next date to be run is recorded in the planning file entry of that material in transaction MD21. Therefore, the material is planned when its date of planning file entry is the same as the planned date entered in the initial screen of MRP execution transaction.

7. Parallel Processing:

To improve the performance, the materials can be divided into several groups and run on multiple dialog work processes in parallel. The maximum number of work processes and destination instances can be defined in the customization transaction OMIQ. Please make sure that the instance exists in the transaction SM59 and is configured correctly.

If an MRP job is scheduled in parallel on background by transaction SM37,  the work processes occupied can be monitored in transaction SM66 below when the job is running.

The program RMMRP000 which is running on background work process (Type BTC) is the main program of MRP, this only divides and distributes the materials to several dialog work processes (Type DIA and programs start with SAPLM61*), RMMRP000 doesn't run materials actually. It shows the status 'Stopped' (Sometimes 'On hold') but it doesn't mean that the MRP job is stopped or is held because the materials are running on other dialog processes and it is just waiting for the result from them so shows those kinds of statuses. Thus, if you'd like to make a trace for performance analysis, the dialog work processes should be traced instead of the main program RMMRP000.

8. User exit Key, User exit Parameter:

User exit M61X0001 can be implemented to exclude some materials from planning, the user exit key and parameters can be entered, those are transferred to the user exit to identify what materials should be excluded. E.g. the parameter can be the MRP controller or MRP group or material group etc.
The user exit contains 2 function modules below. The 2 function modules should be programmed with the same source codes if the user exit is active because one is for non-parallel processing and another one is for parallel processing.

EXIT_SAPLM61C_001

EXIT_SAPMM61X_001

The user exit key and parameter are the importing parameters of the function modules as showed in the screen shot below, so they can be transferred to the function modules, and can be excluded by writing own source code there based on the parameters transferred.

In SAP standard the subcontracting requirements are not considered in the long-term planning.

In transaction MS04 the subcontracting dependent requirements are not displayed.
You can find further information in the SAP note 311336.

With an implementation of BAdI MD_CHANGE_MRP_DATA using method CONSIDER_RESB, it is possible to make the subcontracting requirements relevant for long-term planning.

Sample code:

*--> set flag to consider SC dep. requirements in LTP

       ch_no_exit_flags-ltp_subcon = 'X'.

*--> set changed flag

       ch_changed = 'X'.

Sometimes I wonder how much flexibility, great thought and opportunity for business improvement was packed into SAP-ERP. Yes, it's not the new, flashy poster child of SAP, but it has an enormous amount of functionality and features. the key is to find this stuff and apply it correctly. Just last week I was experiencing one of those magic moments when a certain functions, which I didn't give the attention it deserves, makes perfect sense to solve a problem most people think SAP is not good at solving. The function helps with planning in the long, middle and short term as I describe in a previous blog Respecting your planning horizons.

SAP ERP provides you with the ability to plan, sequence, level and schedule on three different levels. These levels somewhat correspond to the level of detail used in the horizons long-term, mid-term and short-term. For whatever reason, these scheduling levels are not very often used to their full potential but they provide excellent features to move your plan through the periods and fine-tune it along the way. You can, as an example, use different task lists for the long term as what you’re using for the short term. Also, you may decide to perform mid and long term scheduling period and rate based,  whereas you’re planning your capacity in the short term to specific dates and hours, even minutes.

This poses some interesting opportunities for your planning efficiency. As most people stick with discrete routings throughout all planning horizons, there is the great possibility to use a rough-cut planning profile for the long term, rate routings in the mid-term and for detailed planning in the short term we can determine exact, planned execution times with a routing or recipe.

If you do this, you’re effectively planning rates and periods (like 20 pieces for August and 5 pieces for week 25) for when specific, date based planning is too far out and you are planning your order’s capacity load onto a very specific point in time with its specific output quantity for the next – let’s say – four weeks. Remember that the short term planning horizon does not equal the frozen zone. In the short term you’re still planning with planned orders, whereas the frozen zone only contains released production orders.

Task lists are assigned to a planning horizon in the production version of a material as shown in below screen shot

In above example a discrete routing (with a group counter 1 out of routing group 500000002) is assigned to short term, detailed planning. Interestingly, a rate routing has been assigned to rate-based planning which effectively describes the mid-term. Often, one comes across the notion that rate routings are only used in repetitive manufacturing. However, that is not true as rate routings provide an exquisite instrument for period and rate-based planning. They describe a production process with an output rate from the operation (quantity per time) other than a discrete routing which uses the opposite: the time it takes to produce (time per quantity) a lot size. Most people would agree that planning period and rate based in the mid-term, more closely reflects the actual business process and allows for better planning results and manageability.

The settings in above figure also suggest that for the long term (rough-cut planning) a rough-cut planning profile is used. Rough-cut planning profiles are, similar to rate routings, also meant to plan for rates in periods. But that may be the only similarity.

You define your scheduling levels, and what happens to them, in customizing for planned order scheduling. This customizing table has its own transaction code – OPU5. An example of how the scheduling levels can be set up you can see in the screen shot above.

In this example, planned orders (order type LA) in plant 1000 and maintained with production supervisor 101 (production scheduler in the ‘work scheduling’ screen of the material master), will be scheduled and loaded with capacity requirements  for the short term (Detailed Scheduling) and the mid term (Rate Based Scheduling). Note that it is a choice that we use detailed scheduling for the short term and rate based scheduling for the mid term. The decision is done by the assignment of a rate or discrete routing and the type of planning table we will be using (period or date based planning table.

No scheduling or capacity records are generated for the long term (rough-cut planning)

.

You can see the results of these choices (settings) after you run the MRP Run with lead time scheduling. In the generated planned order you will see separate tabs for each scheduling level that was planned. These scheduling records can then be used in the respective planning horizons to plan capacity with the appropriate detail and time frame.

So what's the point in all of this? I think that using scheduling levels can elevate your planning to the next level. Given that you are respecting your planning horizons and you operate in a long, in a middle and in a short term planning horizon (and you also execute in a frozen zone), you can now control the level of detail you're planning with. But more importantly, using a rough-cut planning profile for the long term and a rate routing for the mid-term - and using the appropriate planning table, you can plan periods and rates where, in the past, you might have killed yourself planning exact dates and quantities.

As an example... at my current client we use rate routings for the mid-term and the resulting rate based orders are scheduled and capacity leveled in the tabular or graphical planning table. In fact we are doing this in Long Term Planning in a simulative mode using transaction MS05. That way we can look at periods and move the rate based orders without having to deal with all the unnecessary detail of a detailed, discrete routing. According to the need to respect the planning horizons (as described in a previous blog post), we manage demand in the mid-term and capacity level simulative planned orders until we find the perfect demand program (as defined by the Planning Scenario in LTP). Once done, we hand over that demand program to MRP so that, by use of a discrete routing and the respective detail scheduling level, exact dates, times and quantities are determined in the short term.

The beauty is, that because of our upfront work in the mid term, the demand program should fall pretty well into the available capacity profile and there shouldn't be too much work in terms of detailed scheduling to do anymore.

Using scheduling levels might not get you to the perfect system of planning for your capacity and customer delivery service, but it may be a great step forward to a more integrated system of handling and managing your orders (using standard SAP-ERP software functionality).

In any case, you will have to be clear about where you are planning, what you are planning for and it what timeframe you'd like to use what level of detail first...

...or like Yogi Berra said: "If you don't know where you are going, you might wind up someplace else"

One of the most frequent issues described on SCN threads is that MRP does not plan a specific material. The idea behind this blog is to describe exactly what can be checked to ensure that all the materials will be planned by MRP.

Below you can find the steps to check this specific material on your system and understand exactly why it was not planned.

1 - Check if there is a termination on the MRP background job

The first check to be carried out is if there was any termination on the MRP background job. We can check that accessing the job on transaction SM37.

The most frequent cause of terminations on the MRP background job is when the number ranges are almost expired. Note 531599 provides more details about this issue.

2 - Check the material MRP List

When a material is planned by MRP, an MRP List is generally created and it can be accessed on transaction MD05.

On the MRP list we can find exactly when this material was planned by the last time and if any error message happened during the MRP planning run, that could affect the MRP results. Here, we will define if the material was not planned by MRP or if it was planned but no replenishment proposals were created due to a termination or any other possible issue.

Below there is an example of a MRP List where a termination happened for a material.

We can also find all the MRP lists where an error happened running the report RMMDERRO on transaction SE38. This report is very useful when errors are happening for several materials.

CAUTION: depending on the settings defined on the MRP variant or on the MRP Group Creation Indicator, the MRP list may not be created.

3 - Check the planning file entry exists on transaction MD21

If a material is not being planned by MRP in background or on MD01, then we must check if the planning file exists on transaction MD21.

Please observe that the material can still be planned by individual MRP transactions, such as MD02 or MD03, since they do not check the planning file when planning a specific material.

If the planning file does not exist, the error message "No planning file entry exists for this selection" should be displayed on MD21 and the solution in this case is to run transaction MDAB (report RMMDVM20), in order to create ensure that all the planning file entries were created.

CAUTION: The planning file entries are generally created when MRP is active for a plant and a material is create with a valid MRP type. It is not necessary to run this transaction or report on a regular basis.

See also the blog PP-MRP Hot Note - "MRP does not plan any materials" and further clarifications about planning file entries

4 - Check if the planning file flags NETCH or NETPL are marked

Whenever there is an MRP relevant change for a material (such as a goods movement, a master data change or any change to an MRP element) the planning file flags should be marked. Therefore, a material will be only planned in background with the keys NETPL or NETCH if the respective flag is marked on the planning file.

If those flags are not checked, it's probably because there was no MRP relevant change for this material since the last MRP run, so it was not necessary to plan this material again.

If there are uncovered requirements and this material should have been planned by MRP, you must find out what was the last MRP relevant change for this material and understand exactly why the planning file flags were not set. A good starting point for the investigation is to compare MD04 with MD05 to check if there is any missing planning element or any new planning element, to find out exactly when the planning file entry was not set.

A workaround for this issue is to run MRP using key NEUPL, which will plan all the materials, even when those flags are not set.

CAUTION: Transaction MDAB (Rerport RMMDVM20)only creates missing planning file entries. It does not check the flags NETCH or NETPL when the planning file already exists. The same is valid for transaction MDRE (RMMDVM10), which  only corrects inconsistencies but does not check those flags when there is no inconsistency.

5 - Check if it is an MPS material

A material with an MPS MRP type will be planned by MPS transactions and programs. MPS uses different transactions, such as MDBS, MD40, MD41, etc... so these materials will not be planned by MRP transactions.

6 - Check if the servers for parallel processing are available

If you are using parallel processing, the servers that will be used for parallel processing are defined on the customizing transaction OMIQ. During the MRP run, all the servers must available, otherwise, one of the packages may not be processed, which means that some materials may not be planned by MRP.

Generally, all the servers defined on the customizing transaction OMIQ must be available on transaction SM51, so that MRP can correctly process all the packages.

A workaround for this issue is to run MRP with the flag "parallel processing" unchecked, until fixing the entries on transaction OMIQ.

7 - Retail listing prevents the planning with MRP.

There is a retail functionality called listing, which can prevent the a material to be planned within MRP. When this functionality is active we can generally find an entry on table WLK1 for the material.

8 - Check if EXIT_SAPMM61X_001 and EXIT_SAPLM61C_001 are implemented

User exits EXIT_SAPMM61X_001 and EXIT_SAPLM61C_001 are generally implemented to select which materials will be planned by MRP. The most frequent use of these exits is to plan all the materials for a specific MRP controller. However, if there is any problem on the exits implementation, it may affect the MRP planning run. So we must test the MRP run after deactivating those exits, in order to ensure that there is no problem with the exits implementation.

9 - Check if there is any BAdI active

Any BAdI active executing custom code during the MRP run can lead to unknown side-effects. When a BAdI is executed during the MRP run, the indicator BAdI Active is displayed on the MRP List (MD05), as displayed on the picture below:

A list of the BAdIs available for MRP is available on the document BAdIs for MRP.

As I have explained on my previous blog MRP on HANA: What's new?, as of SAP Enhancement Package 7 for SAP ERP 6.0, MRP was completely redesigned to take full advantage of the SAP HANA architecture.

Now there is a new MRP mode called MRP Live, which is executed on a different transaction and that can be much faster than the classic MRP. The new MRP Live is fully executed on HANA and, since it was built from the scratch, there are some scenarios that are still not covered by MRP Live. A complete list of these scenarios can be found on note 1914010.

As explained on my blog MRP on HANA: What's new?, when MRP Live is executed and system finds one of these restrictions, it will automatically change to the classic MRP, where the database reading was optimized to be executed on HANA, but further processing is carried out on the old ABAP logic.

It means that all the materials can be planned on MD01N, even though they cannot be totally planned on HANA. However, in order to achieve the optimal performance on the MRP Live, we must try to avoid those restrictions, so that we can plan as many materials as possible directly on HANA.

In order to help you to estimate how many materials can be planned by MRP Live and exactly which restrictions do you have on your system, SAP delivered note 1975704, which contains report PPH_CHECK_MRP_ON_HANA.

This note is valid as of release 600 and this report is delivered on a support package, even on systems that are not using HANA. With this report, you can estimate the effort to improve your master data focusing a better performance on MRP Live after an upgrade.

The report provides a compact display, with the total number of materials that can be planned by MRP Live by low-level code, and also specifying the number of materials that cannot be planned by MRP Live for a specific restriction.

The report also provides a detailed display, where all the materials are displayed. Here, the report will tell you if the material will be planned in HANA or in ABAP and it will also tell you if there is any specific restriction for this material.

Therefore, if you are considering to use MRP on HANA, you can use this report to improve your master data and reduce the number of restrictions, focusing a better performance on MRP Live.

I also suggest you to take a look on the following note, which provides more information about the MRP on HANA performance:

2023766 - MRP Live/MRP Classic: Performance Information

See also the information from the following SAP Help link for more details:

MRP Live: Incompatible Changes - Carrying Out the Planning Run Using MRP Live - SAP Library

At last, the common issues on this topic are described on Issues related to MRP on HANA.

I have already seen many threads on this space asking for books to study production planning, therefore, I have decided to share here the books that I consider more relevant on this area.

Starting with the SAP Press "official" books, we can find some intersting topics abou production planning.

If you are just starting to learn production planning and you would like to learn a little bit about process before a deep dive into the technical aspects, a good book to start is The Goal. It is and easy reading book, as it is written as a novel and it provides an overview about the theory of constraints.

Another book that provides an overview of production planning and that may be interesting for someone starting on this area is Fundamentals of Production Planning and Control - Stephen N. Chapman.

A classic book about production planning is Toyota Production System, written by Taiichi Ohno. He is nothing else than the inventor of the Toyota Production System and Lean manufacturing.

You can also find several suggestions of books about this topic on the link Production Planning.com - Latest in Production Planning and Scheduling.

Now considering SAP Press official books, Uwe Goehring, who is a regular contributor of the SAP ERP Manufacturing - Production Planning (SAP PP) space recently wrote the book Materials Planning with SAP. von Uwe Goehring - by SAP PRESS, which provides an overview of Materials Planning on the ERP system. I did not read the book yet, but considering the quality of the content published bu Uwe on SCN, I'm quite sure that it is worth the price.

Another interesting book about PP is Production Planning and Control with SAP ERP. von Jaw - by SAP PRESS. It is more focused on production control and provides an overview about discrete, repetitive and process manufacturing types on the SAP ECC.

SAP Press also publshed the e-book Configuring Kanban in SAP ERP MM and PP - SAP PRESS, which is more specific about the Kanban functionality.

At last, there are the official SAP trainings, and the related documentation. Take a look on the following links for more details:

SCM130 - SAP ERP Planning & Manufacturing Overview

SCM240 - Production Planning in ERP

SCM310 - Production Orders in ERP

TSCM40 - Planning/Manufacturing I

TSCM42 - Planning/Manufacturing II

If you know any other interesting book about this topic, please share it on the comments and I'll add to the list.

You are running MRP on your system with the parameter Scheduling = '2 - lead-time scheduling and capacity planning', as shown on the figure below:

After the MRP execution, you are observing the following symptoms:

1. Only the first planned order generated by MRP is correctly schedule and, for all the other orders, the tab 'lead time scheduling' is not created.
2. Planned orders created by MRP are no longer generating capacity requirements and they are not displayed on capacity leveling or capacity evaluation transactions, such as CM21, CM25 or CM01.
3. If you try to manually schedule one of these planned orders on transaction MD12, the tab 'lead time scheduling' is correctly created without any kind of problems.

This is a side-effect of note 2131199, which was created to improve the performance of the planned orders lead-time scheduling. This note was delivered on support package SAPKH61708 and, after the implementation of this note, you may observe the described symptoms.

In order to avoid this issue on your system, you must implement the following note:

If this not is not relevant for you and the planned orders are still not scheduled correctly, I suggest you to check the work center and routing settings, according to the documents below:

CRP Basic Settings Part 1 - Work Center

CRP Basic Settings Part 2 – Routing

In addition, the following notes may be useful

As I see daily on the Manufacturing PP space threads asking for exits or BAdis for specific scenarios, I decided to create this list with the most important user-exits and BAdIs that are available for production and process orders (if you are looking for BAdIs for MRP, check the blog BAdIs for MRP).

Below you can find the main BAdIs for production and process orders and the methods available for each one:

• WORKORDER_UPDATE: This BAdI is called whenever the order is changed, for example, on transaction CO02 or during capacity leveling
  • ARCHIVE_OBJECTS - Archiving Additional Objects
  • AT_DELETION_FROM_DATABASE - Order is deleted from the database (archiving)
  • AT_SAVE - Save Order Time: Dialog
  • CMTS_CHECK Check - Configurable Warehouse Order Allowed
  • INITIALIZE - Initialization when Importing/Creating Order
  • IN_UPDATE - Save Order Time: Update
  • NUMBER_SWITCH - Swap Tempory Order Numbers with Final Order Numbers
  • BEFORE_UPDATE - Save Order Time: Before Calling Update
  • AT_RELEASE - Release Order Time: After SAP Checks, Before Release
  • REORG_STATUS_ACT_CHECK - Reorganization of Order: Status Check
  • REORG_STATUS_ACTIVATE - Reorganization of Order: Follow-Up Action After Status Set
  • REORG_STATUS_REVOKE - Reorganization of Order: Follow-Up Action After Status Reset

• WORKORDER_CONFIRM: This BAdI is called during the order confirmation for additional checks.
  • AT_SAVE - Confirm Order, Time: Dialog
  • BEFORE_UPDATE -Confirm Order, Time: Before Update
  • IN_UPDATE - Confirm Order, Time: Update
  • AT_CANCEL_CHECK - Confirm Order, Time: Check if Cancellation is Possible
  • INDIVIDUAL_CAPACITY - Confirm Order: Preassignment Individual Capacity

• WORKORDER_GOODSMVT: This BAdI can be used to manipulate goods movements that are posted during an order confirmation
  • BACKFLUSH - Confirmation: Backflush
  • GOODS_RECEIPT - Confirmation: Automatic Goods Receipt
  • MANUAL_GOODS_RECEIPT - Manual Goods Receipt for Order
  • IM_CALLED - Time after Inventory Management is Called
  • PICKLIST - Pick list
  • GM_SCREEN_LINE_CHECK - Goods Movement Overview: Line Check
  • GM_SCREEN_OKCODE_CHECK - Goods Movement Overview: OK Code Check
  • COGI_AUTHORITY_CHECK - Postprocessing: Authorization Check
  • COGI_POST - Postprocessing of Incorrect Goods Movements
  • COMPLETE_GOODSMOVEMENT - Confirmation: Addition of User Input on Goods Movement
  • GM_WIPBATCH_PROPOSE - Goods Movement WIP-Batch: Proposal
  • GM_WIPBATCH_CHECK - Goods Movement WIP-Batch: Line Check

• WORKORDER_REWORK: This BAdI is used on a rework scenario, in order to transfer outwards an additional yield when entering a backflush for PP orders. This is added
  • GET_REWORKED_QUANTITY - Returns the Reworked Yield

• WORKORDER_INFOSYSTEM: This Business Add-In can be used to fill additional (customer-specific) fields in the order info system (transactions COOIS, COOISPI, COHV...) for production orders and process orders.
  • ORDER_TABLES_MODIFY - Processing of order tables
  • PLANNED_ORDER_TABLES_MODIFY - Processing of planned order tables
  • AT_SELECTION_SCREEN - Is called in the WBS for the PPIO_ENTRY selection screen
  • AT_OUTPUT_SCREEN - Is called for every action on the output list
  • OVERVIEW_MODIFY - Processing of the object overview
  • TABLES_MODIFY_LAY - Processing of Order and Planned Order Tables
  • DETAIL_LIST_LAY - Process Detail Lists
  • OVERVIEW_TREE_LAY - Process Layout-Based Object Overview
  • AT_OUTPUT_SCREEN_LAY - Call When Action is Carried Out on the Output List

• WORKORDER_DOCLINKS: This BAdI can be used to manipulate the order document links.
  • MAINTAIN_DOCLINKS - Document Link Maintenance

• WORKORDER_PISHEET: This BAdI enables you to discard browser-based PI sheets directly from  the process order.
  • PI_SHEET_DISCARD - Discard PI Sheet
  • PI_SHEET_DISCARD_DOWN - Discard PI Sheet/Download to External System

• WORKORDER_CONFIRM_CUST_SUBSCR: This BAdI enables you to change the subscreen for customer-specific fields in the time ticket (single-screen entry CO11N/COR6N and in the order header confirmation CO15/CORK).

  • GET_SUBQTY_LAYOUTS - Determine Name of Existing Quantity Layouts

  • CHECK_SUBQTY_LAYOUT - Check for Layout for Existence of Subdivided Quantities

  • GET_CONF_CUSTOMIZING - Customizing Confirmation Parameters

  • CHECK_SUBQTY_POSTED - Check Whether Subdivided Quantities Confirmed

  • PUT_DATA_TO_QM_SUBSCR - Transfer Data to Screen Enhancement for QM

  • PUT_OK_CODE_TO_SUBSCR - Transfer OK Code to Screen Enhancement

  • PUT_DATA_TO_SUBSCR - Transfer Data to Screen Enhancement

  • GET_DATA_FROM_SUBSCR - Adopt Data from Screen Enhancement

Here are the user-exits available for PP order processing:

• PPCO0001
  • EXIT_SAPLCOBT_001 - User Exit PP Order Processing (Non-Order-Type-Specific)

• PPCO0002
  • EXIT_SAPLCORE_001   Set deletion flag
  • EXIT_SAPLCORE_002   Set deletion indicator
  • EXIT_SAPLCORE_003   Technically complete
  • EXIT_SAPLCORO_001   Check exit for function "Set deletion flag"
  • EXIT_SAPLCORO_002   Check exit for function "Set deletion indicator"

• PPCO0003
  • EXIT_SAPLCOEXT_001 - Check Exit for Production Order Change from Assembly Order

• PPCO0004
  • EXIT_SAPLCORE_004 - Mass Processing of Production Orders: General Sort Exit

• PPCO0005
  • EXIT_SAPLCOSD_001 - Storage Location/Backflushing on Order Creation

• PPCO0006
  • EXIT_SAPLCOZF_003 - Exit for Predefining Fields in the Order Header

• PPCO0007
  • EXIT_SAPLCOZV_001 - User Exit for Checking or Changing Header Fields During Order-Type-Specific

• PPCO0008
  • EXIT_SAPLCOMK_006 - Enhancement in the adding and changing of components

• PPCO0009
  • EXIT_SAPLCOSF_001 - Customer Exit: Goods Receipt for Production Order

• PPCO0010
  • EXIT_SAPLCOCOM10_001 - Enhancement in make-to-order production - Unit of measure

• PPCO0012 - Production Order: Display/Change Order Header Data
  • EXIT_SAPLCOKO1_001 - Transfer of Order Data to Customer Enhancement
  • EXIT_SAPLCOKO1_002 - Transfer of Data Changes from Customer Enhancement

• PPCO0013
  • EXIT_SAPLCOMK_008 - Change Priorities for Selection Criteria for Batch Determination

• PPCO0014
  • EXIT_SAPLNWDB_001 - Select process orders for external relationships

• PPCO0015
  • EXIT_SAPLCOSD_002 - Customer Exit: Additional Attributes Document Link

• PPCO0016
  • EXIT_SAPLCODM_001 - User Exit: Generate Document Links from Master Data

• PPCO0017
  • EXIT_SAPLCODD_001 - User Exit: Document Links Dialog Processing

• PPCO0018
  • EXIT_SAPLCOKO1_004 - Check whether changes to order header/item are allowed in th

• PPCO0019
  • EXIT_SAPLCOVG_001 - User Exit for Checks of Operation Changes in the Production

• PPCO0020 - Process order: Display/change order header data
  • EXIT_SAPLCOKO_005 - Transfer of Order Data to Customer Enhancement
  • EXIT_SAPLCOKO_006 - Transfer of Data Changes from Customer Enhancement

• PPCO0021
  • EXIT_SAPLCOZR_003 - Release Control for Automatic Batch Determination: Handling

• PPCO0022
  • EXIT_SAPLCOTX_001 - Determination of Production Memo

• PPCO0023
  • EXIT_SAPLCOMK_014 - Checks Changes to Order Components

User-exits called during the process order confirmation:

• CONF0001  Enhancements in order confirmation
  • EXIT_SAPLCORU_001 - Order Confirmation: Deactivation of Functions

• CONFPI01
  • EXIT_SAPLCORF_401 - Process order conf.: Calculate cust.specific default values

• CONFPI02
  • EXIT_SAPLCORF_402 - Process Order Confirmation: Customer-Specific Input Check Wi

• CONFPI03 
  • EXIT_SAPLCORF_403 - Process Order Conf.: Customer-Specific Checks after Operation

• CONFPI04 
  • EXIT_SAPLCORF_404 - Process Order Confirmation: Customer-Specific Input Checks

• CONFPI05
  • EXIT_SAPLCORF_405 - Process order conf.: Cust. spec. enhancements when saving

• CONFPI06
  • EXIT_SAPLCORF_406 - Process order confirmation: Actual data transfer

User-exits called during the process order confirmation:

• CONFPP01
  • EXIT_SAPLCORF_101 - PP order conf.: Determine customer specific default values

• CONFPP02 
  • EXIT_SAPLCORF_102 - PP order conf.: Customer specific input checks 1

• CONFPP03 
  • EXIT_SAPLCORF_103 - PP order conf.: Cust. specific check after op. selection

• CONFPP04 
  • EXIT_SAPLCORF_104 - PP order conf.: Customer specific input checks 2

• CONFPP05 
  • EXIT_SAPLCORF_105 - PP order conf.: Customer specific enhancements when saving

• CONFPP06 
  • EXIT_SAPLCORF_106 - PP Order Confirmations: Actual Data Transfer

• CONFPP07 - Single Screen Entry: Inclusion of User-Defined Subscreen
  • EXIT_SAPLCORU_S_100 - Transfer Data from SAPLCORU_S to Customer-Defined Screen
  • EXIT_SAPLCORU_S_101 - Return Data from Customer-Defined Screen to SAPLCORU_S

You wonder why a field is filled automatically by the system.  How to make it happen?  Here are some general settings:

1. In the screen level

Firstly find which screen the field belongs to.  Take the field 'process order' in t-code COR6 for example.

Click F1 help on the field. Then click button 'Technical details'.  You will find the screen number and field name on the popup.

In t-code SE51, check the field attributes.  There is a field 'parameter ID' and 2 indicators 'SET parameter' and 'GET parameter'.  They control whether the field can store the field content to an internal parameter or get the content from the parameter.

If you go to t-code COR3 and check the same.  On Screen 5110 of program SAPLCOKO, the field 'process order' also refers to the same parameter ID.

Therefore, if the indicators 'SET parameter' and 'GET parameter' are set for field CORUF-AUFNR, after you dispaly a process order in COR3, then navigate to COR6, the process order number will be shown automatically.

2. In program level

Sometimes the system can set or get a parameter id by coding directly.  It usually occurs in a PBO module.  You can set a breakpoint at 'GET parameter'.

3. In customizing

For some transactions you may be able to control it by customizing settings.  As an example you can check the KBA 2031843.

2031843 - Fields 'Material' 'Plant' and 'Group' are proposed automatically from previous input in transaction code CA01/CA02/CA03

An alternative item group is used to group together alternative items in a BOM. Any of the materials in the alternative item group could be included in the assembly. These items are known as alternative items in the BOM.

You can use alternative items in the following situations:

• Alternative items with a usage probability

    The alternative items are included with a certain usage probability. 

• Material requirements planning (MRP) uses the usage probability to determine dependent requirements for the materials.
• In the production order, dependent requirements are converted to a reservation.

  · The withdrawal posting for the reservation in the production order uses either the usage probability or the 100% availability check according to ATP logic. 

• Alternative items for information: You can enter an alternative item for information only. For example, the item is only relevant to missing parts. The usage probability for the item is 0 .

Please follow the below URL to have a depth insight to this concept.

http://https://help.sap.com/saphelp_470/helpdata/en/ea/e9b3c44c7211d189520000e829fbbd/content.htm

I am going to describe two scenarios with this alternate item group concept in BOM.

Plant - 1000

Finished goods – ALTFERT

Raw material – G1 and G2.

Order type – PP01

Go to Order type control and set the configuration as User can’t release the Order if there are any missing parts. Please see the below screen shots( Tr code OPJK ) :

Case 1: If the requirement is either we may consume G1 or G2 100 % to manufacture ALTFERT based on the stock.

Create a Fert and 2 raw materials in 1000 plant. Create a BOM and Routing in the pant.

For Bom follow the settings:

Then do the settings for Alt group as shown:

Double click on the item no 0010 and then input the alternate group as “A1” and select the arrow.

A new pop up will open as shown below, and then input the parameters as shown.

Double click on the item no 0020 and then input the alternate group as “A1” and select the arrow.

A new pop up will open as shown below, and then input the parameters as shown.

That means for manufacturing 1 qty of ALTFERT we require either G1 or G2 ( any of them ) of 2 qty.

Save the BOM.

Do some stock posting for raw material G1 only (maintain stock for G1 only not for G2.)

Then create Prod. Plan by MD61 and run the mrp.

SAP will create planned orders for the dependent materials.

Then convert the planned order to production order. As one of the material G1 is available so the production order will be release although the availability check is maintained that without mat available no release.

Then Release the Production Order:

Then check the Components list, you can see G1 reqmt showing is 20 and G2 reqmt automatically changed to zero.

CASE 2: If the requirement is to consume G1 or G2 by 80 % and 20% as available in stock to manufacture ALTFERT for its base qty.

Maintain the BOM:

Maintain the total reqmt qty same for both the raw materials.

Then maintain the Alt BOM  Group for G1 :

Then maintain the Alt BOM Group for G2 :

Then create Routing.

Then create PIR for 10 qty and save it. Then run mrp. A planned order for 10qty will be shown in md04 for the Finished Good.

Then automatically SAP will create the planned orders for both.

G1 = 20 * 80/100 = 16

G2 = 20* 20/100 = 4

Check in MD04.

Then convert the planned order to prod order and release it. You can check the Components list it’s changed as per the settings in Alt Bom Group.

Then follow the Standard SAP PP Flow and close the Production Order.

Thanks

Subhrant

Very frequently, problems are observed when deleting a work center on transactions such as CR02, CRC2 or IR02.

The work center can be deleted directly on the mentioned transactions if we choose the menu 'Work center' - 'Delete' or it can be archived using the archiving object PP_WKC (Archiving Work Centers (PP-BD-WKC) - Production Planning and Control (PP) - SAP Library)

However, very frequently a TIME OUT short dump happens when you try to delete the work center directly on the transaction .

The TIME_OUT dump usually occurs when the tables where the work center is being used are huge. That's because, during the work center deletion, system must perform a where-used selection, to find on which tables the work center is being referred. This procedure is necessary in order to prevent database inconsistencies, that means, avoid the deletion of a work center that is still being used on another table or transactions.

For example, if the work center was used on a production and if you delete this work center, you would probably observe a short dump or an inconsistency when trying to open this work center.

Therefore, system must confirm that the work center is nor referenced on the following tables, before the deletion:

• PLKO - Task list - header
• AFRU - Order completion confirmations
• EQUZ - Equipment time segment
• IFLO - Functional Location (View)
• AFIH - Maintenance order header
• ILOA - PM Object Location and Account Assignment
• QMEL - Quality Notification

When there is a lot of data on these tables, the performance of this where-used selection is very bad and the work center cannot be deleted.

In this case, the archiving of unnecessary PM orders and Production orders to reduce the size of those tables is extremely recommended. This procedure will reduce the number of entries in the tables and it should avoid the TIME OUT.

In addition, there may be no suitable access path for the select statement on the tables, such as AFRU. This would not normally be an issue if the size of the order tables were not out of hand.  However, with the large amounts of data in these tables, the unsuitable access path really is a significant issue.  A new table INDEX with the field ARBID can be used, but this is considered as a MODIFICATION. Normally, SAP suggests a MAXIMUM of five indexes for a given table. This minimizes the required tablespace and minimizes the time needed by the Cost Based Optimizer to evaluate the possible access paths.

It is possible, however, to temporarily create the ARBID index, until the size of the order tables can be reduced sufficiently to allow

proper access to these tables or until the deletion of the desired work centers. After that, the index can be removed from the table.

Note 415031 provides more details about this specific issue and the mentioned index.

Another very frequent issue is the error message 'CR002 -  Work center XXXXXXXX in plant XXXX is still being used'.

This error message happens when the work center is still being referenced in one of the mentioned tables and the deletion will not be allowed while such reference still exists.

A quick way to identify where the work center is being referenced is to run transaction CR40 with all the flags checked.

Transaction CR40 will show exactly on which documents the work center is being used and you can proceed with a clean up of these documents.

Only when there is no usage for this work center on transaction CR40 you should be able to delete the work center.

In order to clear the references for this work center, we can replace it on routings and task lists and we should archive existing orders where this work center was used, with a proper archiving object (e.g. archiving object PP_ORDER for production orders).

If RF ID has scanned wrong Serial number for a FG material, then the procedure to replace it with new serial number is as below

Steps

1) Change the production order using CO02 transaction.

2) Click on header and Select Serial numbers.

3) Replace the Serial Number XXXX117571059with new serial number XXXX12073

Click on OK and Press Save

4) Execute the IB52 transaction. Give the Ibase number 1205105 and press Enter

5) Replace the Serial Number XXXX117571059 with new serial number XXXX12073 and Press Save

Note: If you want to confirm the production order with new serial number withoutchanging the serial number of components that are already backflushed

Please do the below steps before confirming the production order.

Execute the IB52 Transaction, give the Ibase number  and press Enter.

  Click on the FG material

Click on activate icon twice to deactivate and activate it

Also, click on the Component

Click on Activate icon twice to deactivate and activate it. Click on Save and IBase is changed successfully.

All the GI components are assigned to the new serial number from old Serial number database