Note 1901576was recently released (and introduced on support packages for the latest releases) to correct a program error that could lead to inconsistent results when changing the planned order quantity after jumping to MD04. Many users were used with the old behavior, therefore, I'm writing this blog to clarify why this change was necessary.
When calling transaction CO41 to run the collective conversion of planned orders, system allows you to select a line and jump to transaction MD04.
PROBLEM: After changing the order quantity and getting back to transaction CO41, the planned orders were not selected again from the database table PLAF, therefore, the new quantity was not update on CO41. Therefore, the planned orders would be converted with the old quantity, before the changes made when jumping to transaction MD04.
In order to avoid the conversion of orders with an incorrect quantity, note 1901576 was created. For design reasons, it is not possible to send the new quantity from MD12 back to CO41. Therefore, the planned orders must be selected again from the database when you come back from transaction MD04.
It means that, if you have changed the quantity of a planned order on CO41, before jumping to MD04, this change will lost when you jump back to CO41, since the order will be selected from the database again.
This is the new system standard behavior, as of the following support packages, and it was designed to prevent the conversion of a planned order with and incorrect quantity:
Software Component
Release
Support Package
SAP_APPL
600
SAPKH60025
SAP_APPL
602
SAPKH60215
SAP_APPL
603
SAPKH60314
SAP_APPL
604
SAPKH60415
SAP_APPL
605
SAPKH60512
SAP_APPL
606
SAPKH60609
SAP_APPL
616
SAPKH61604
SAP_APPL
617
SAPKH61702
If note 1901576 is implemented on your system, you should also implement note 1918330, so that system can memorize the manually excluded planned orders and exclude them again after re-selecting the updated planned orders.
MD04 has many hidden powerful and useful functions. Knowing them could make our daily work easier to evalute MRP results.
Set a manual firming date.
You can set a manual firming date by menu 'Edit' > 'Set Firming Date'. Image may be NSFW. Clik here to view. Receipts lying before the firming date are firmed (an asterisk is added to the MRP element)and won't be changed by MRP running. For example, if you increase the PIR quantity to 10 and run MRP again, the firmed proposal (schedule line in this case) within 12.12.2014 is not changed. A new proposal is created to cover the requirement on the manual firming date. Image may be NSFW. Clik here to view. Please note this is an examplle when using MRP type "PD" with blank firming type. Read the F1 help of this field for restrictions and dependencies.
Add additional navigation buttons
You can add an additional navigation button for a particular MRP element by maintaining favorites, or add a series of buttons for different MRP elements by defining a navigation profile.
- Maintaining favorites for an MRP element For example, display a purchase order in MD04. Click the button 'Maintain favorites'. Image may be NSFW. Clik here to view. Click button 'New entries'. You can maintain the fields by yourself or make use of existing examples by clicking button 'Examples'. Image may be NSFW. Clik here to view.
You can also configure whether you'd like to use filter by default when accessing MD04, menu 'Settings' > 'Settings'. Image may be NSFW. Clik here to view.
So what is the difference between 'Display filter' and 'Selection rule'? I'll explain it with a simple example.
Variant Configuration has poor visibility in ECC. This article explains how to incorporate configuration values into a simple planned order query. The concepts can be used to display configuration information for other objects in more complex situations.
There are two reasons why variant configuration visibility is poor in general.
The main one is that the SAP system doesn’t know how many characteristics you are going to use in your configuration, you can use one or you can use 100. In order to incorporate the values into a standard report (like COOIS) it would require a flexible definition tool to allow you to decide what characteristics you want to see. This gets even more complicated if you use different configuration classes with different characteristics for different materials. I assume this complexity is the reason why SAP doesn’t offer the functionality.
The other reason is that the configuration details are not stored in tables so extracting the data directly from the table - or with a simple query - is not an option.
If you use configuration to plan production in a make-to-order environment you will need to drilldown a couple of times to get the planned order configuration.
This is of no use if you want to list, filter and process orders based on their configuration values.
The Query
You can use a query with some embedded code to solve this visibility limitation. The first step is to decide which characteristic values you want to see in your report.
Let’s assume you have width and length as your configuration characteristics. Create the infoset based on the planned order table (PLAF) and add additional fields for the values that you want to see.
Add the following definition in the DATA section of the query code.
* Config data definition
DATA:
INSTANCE LIKE PLAF-CUOBJ,
CONFIGURATION LIKE CONF_OUT OCCURS 100 WITH HEADER LINE.
These are the variables needed to call the configuration value function. In the “Record Processing” section of the query code add the following function call.
* Clear variables
CLEAR: CONFIGURATION, WIDTH, LENGTH.
REFRESH CONFIGURATION.
* Call the function for the planned order instance
INSTANCE = PLAF-CUOBJ.
CALL FUNCTION 'VC_I_GET_CONFIGURATION'
EXPORTING
INSTANCE = INSTANCE
TABLES
CONFIGURATION = CONFIGURATION
EXCEPTIONS
INSTANCE_NOT_FOUND = 0.
* Loop the configuration table returned looking * for the characteristic name and transfer the * configured value to the additional field
loop at CONFIGURATION.
case CONFIGURATION-ATNAM.
when 'WIDTH'.
WIDTH = CONFIGURATION-ATWRT.
when 'LENGTH'.
LENGTH = CONFIGURATION-ATWRT.
endcase.
endloop.
Finish your query by including the new fields with any regular field you require. The result is a quick and efficient query showing the order configuration in nice tabular form. It can then be used to filter, drill down to a transaction, export to Excel, copy paste the order list into COOIS; among other things.
From ERP 6.0 EHP2, if activate business function LOG_PP_LMAN, stock/requirement list(t-code MD04) increases new functions: material grouping and cross-plant view. Nowadays, more and more companies produce the material in multiple plants, this new function can help them to check the stock/requirement from the whole company view.
Then in t-code MD04, "Product Group" tab appears. You can view the stock/requirement situation for multiple materials there. Also, you can decide if it is displayed in aggregated form or not by clicking the aggregation icon.
In the screenshot above, it is in aggregated form. The stock of both materials is 2 in total.
2. Evaluate MRP result across plants
Material ZJLTEST-1 exists in plant 1000 and plant 1100. You can check the stock/requirement in all plants for material ZJLTEST-1 in "Cross-Plant view". You can choose display form using aggregation icon.
SAP R/3 has highly integrated Production Planning System. The PP module is divided into two Sub-modules, 'PP-PI' and 'Production General'.
PP-PI sub-module is designed for process industries like Oil and Gas.
Production Planning module of SAP takes care of Master data needed like Bill Of Materials, Routings and Work Centers and stores it in one separate component.
Various stages of planning system can be planned by using components like
- Sales and Operation Planning
- Long Term Planning
- Demand Management
- Materials Requirement Planning
SAP has distinguished various styles of production like Kanban, Repetitive Manufacturing and Production Order processing. It can take care of various planning strategies like 'Make-to-stock', 'make-to-order', 'planning without final assembly' etc.
SAP R/3 PP module can also plan Capacity. The capacity Planning sub-module is taking into account various capacities like pooled capacity etc.
Production Orders reporting has flexibility of confirming orders with or without backflush. The material can be staged to production site from the Warehouse after releasing order. Costing can be triggered automatically by integrating the module with Cost Accounting Module.
Integration with other modules like Material management, Financial Accounting, Cost Accounting, Human Resources & Development, Sales and Distribution etc adds on to reliability of the production planning system in SAP R/3. The system is a real time system. The changes in demand (cancelled or added sales order etc) and supply (high/low rejection, early/late supply from supplier, breakdown of facilities etc) are reflected in real time and the production controller can react fast to these changes.
SAP R/3 PP module is a very effective tool for production planning. As is gives many alternatives, it must be configured correctly to utilized optimum potential. The person configuring the system MUST have through understanding of the business needs as well as 'PP' and other modules of SAP R/3.
Work center CRHH Work center hierarchy CRHS Hierarchy structure CRHD Work center header CRTX Text for the Work Center or Production Resource/Tool CRCO Assignment of Work Center to Cost Center KAKO Capacity Header Segment CRCA Work Center Capacity Allocation TC24 Person responsible for the workcenter
Routings/operations
MAPL Allocation of task lists to materials PLAS Task list - selection of operations/activities PLFH Task list - production resources/tools PLFL Task list - sequences PLKO Task list - header PLKZ Task list: main header PLPH Phases / suboperations PLPO Task list operation / activity PLPR Log collector for tasklists PLMZ Allocation of BOM - items to operations
Bill of material
STKO BOM - header STPO BOM - item STAS BOMs - Item Selection STPN BOMs - follow-up control STPU BOM - sub-item STZU Permanent BOM data PLMZ Allocation of BOM - items to operations MAST Material to BOM link KDST Sales order to BOM link
Production orders
AUFK Production order headers AFIH Maintenance order header AUFM Goods movement for prod. order AFKO Order header data PP orders AFPO Order item RESB Order componenten AFVC Order operations AFVV Quantities/dates/values in the operation AFVU User fields of the operation AFFL Work order sequence AFFH PRT assignment data for the work order(routing) JSTO Status profile JEST Object status AFRU Order completion confirmations PRT's voor production orders AFFH PRT assignment data for the work order CRVD_A Link of PRT to Document DRAW Document Info Record TDWA Document Types TDWD Data Carrier/Network Nodes TDWE Data Carrier Type
Planned orders
PLAF Planned orders
KANBAN
PKPS Kanban identification, control cycle PKHD Kanban control cycle (header data) PKER Error log for Kanban containers
Reservations
RESB Material reservations RKPF header
Capacity planning
KBKO Header record for capacity requirements KBED Capacity requirements records KBEZ Add. data for table KBED (for indiv. capacities/splits)
Planned independent requirements
PBIM Independent requirements for material PBED Independent requirement data PBHI Independent requirement history PBIV Independent requirement index PBIC Independent requirement index for customer req.
One of my favorite clients runs a mix of production orders and repetitive manufacturing. As I visited their distribution center last week, I saw that they have a fairly simple assembly and kitting operation going on in the warehouse before the ship bundled spare part kits to the customer or the manufacturing plants.
My suggestion was to use repetitive manufacturing for the scheduling of the assemblies (and kitting) to make it easy and automated. With only little customizing necessary, we put the whole thing together within 3 days. Actually, the only customizing effort that was required was for the layout key and a setup matrix (using setup group category and setup group key), so that we can dispatch a sequence that is build automatically according to 'like' setups.
The first thing we did was switching from reorder planning to the deterministic PD. the previous V1 had the effect that inventory holdings (how much to put into the reorder level) had to be calculated based on the two demand sources:
- Stock transport order requests from Manufacturing Plants
- After Market requests from Customers
With a changing demand situation it was very difficult to find the right reorder point and assembly was only triggered when a reorder point was broken. Since then a forward scheduling is executed, the inventory left, after the reorder point was broken, had to be enough to fulfill the demand. This is a very difficult planning situation and requires a lot of inventory.
That is why we decided to plan these products with PD, where future demands (from STOs or customer orders) result in the generation of supply orders in exactly the quantity and exactly the date, they are demanded. Using safety stock to buffer any variation in lead time and demand, we can now schedule production to exactly meet demand. With a fixed lot size FX that corresponds in quantity to the smallest possible run, the MRP run generates supply proposals into the order pool that are a multiple of the minimum run quantity. In scheduling we can then flexibly sequence run quantities in feasible lot sizes
after the MRP run you can then see all the various demand elements in MD04 and the supply that covers them.
Now we can move onto scheduling and in MF50 we can see - tabular or graphically how MRP, which works without any consideration of capacity, sequence or material component availability, fills the pool of orders.
using the previously customized layout key for sequencing according to 'like' setups, we can now simply select three weeks worth of orders and click the 'dispatch button. The system uses the sequencing profile and first sorts all the orders and builds a sequence, then it distributes the orders within the limits of available capacity defined in the individual work orders.
Note that there are three work centers that can be scheduled. If you define alternative routings and production versions, you can use the dispatching strategy in a way that, in case of missing capacity, the dispatching can resort to another work center and therefore perfectly distribute the orders.
since we are working with repetitive manufacturing, there is no need for a planned order conversion to production orders. The orders you see here are executable. Now you may perform a collective availability check using MDVP on the schedule and expedite missing parts for next week.
All that's left is MF51 where you can prnt the schedule and hand it to the operator who will be happy to receive instructions on a feasible plan that's checked for capacity and materials availability.
There are four options for batch entry: Image may be NSFW. Clik here to view. Here you decide if the batch is needed at what step of production process and if the batch determination should be done manually or automatically.
Second place: Customizing OPJ2 Image may be NSFW. Clik here to view. Here you decide if the batch determination should be done automatically during goods movement in production order/process order confirmation.
If you are using WM(warehouse management), the control here may not work, as the WM may use their own batch determination logic which is done in FUNCTION 'L_PPIM_BATCH_DETERMINATION_INT' but not the traditional batch determination function module FUNCTION 'VB_BATCH_DETERMINATION'. If this is the case then the batch entry in the material master is very important to decide when the batch is needed in the whole process.
Third place: Customizing OPJK Image may be NSFW. Clik here to view. Here you decide if the batch is needed when you release the order, it should be checked combined with the batch entry setting in material master.
I am seeing a positive trend within the SAP eco system, of clients better understanding what their options are when it comes to repetitive manufacturing. As we all know, SAP's Repetitive was developed much later than the original PP - the discrete system for job shops. REM was developed because the discrete model didn't fit very well for repetitive manufacturers. So now the big question is: are you a repetitive or a discrete manufacturer? And once you know that answer, the decision to go to repetitive or not should be an easy one. After all, you're not using the HR module to manage your inventory, do you? In the same sense you shouldn't run a repetitive manufacturing environment with discrete production orders.
So a repetitive manufacturer typically exhibits a number of telling characteristics:
- they offer a product catalog to their customers. As soon as you have a standard product in a catalog you will make that product more than once (you can still make it to stock or make it to order). You repeatedly have that product on your line and you should actually measure how many of the product you made this period, as compared to any other period (its more like a rate than a discrete quantity). This brings me to costing...
- repetitive manufacturers cost the products on a period basis. If you make widgets in lots of 1000 over a period of a year, would you want to cost out every single discrete production order or would you want to see how much the production of that material had cost you in May compared to June? I think the answer is easy and what I see happening a lot, is that companies started out on discrete (because they didn't know any better or were not told any better) and the costing people transfer all cost to spreadsheets and then normalize the cost to a parts / period basis
- repetitive manufacturers want their operations to flow. In a discrete environment, where a customer wants exactly one lot size of a thing that has two holes, a handle and is welded onto a stick, you create a discrete production order with a routing describing the exact steps to make that thing. If the plate has to be fabricated first, you might want to create a second discrete production order to fabricate the plate and then you can see how much inventory of those fabricated plates you have and how much each plate has cost you to make it. If you make standard products that always look alike, you want to run a thousand per day and you are not concerned about how much inventory of the fourth level intermediate you have, or how much that one piece had cost you... you want to know how much WiP (work in process) is in the system and how long it takes to get a product made (if your lines flow your wip is low and cycle times are short and then your cost is low too). Flow is what makes a repetitive manufacturer tick and that is why SAP's REM provides a lot of functionality (mostly unknown) to lean and flow your production environment. To do the same with discrete is impossible.
- capacity planning! in discrete manufacturing, capacity planning is looking at a specific work center (usually the bottleneck) and compares capacity offer to capacity requirements and then levels all the orders on a bottleneck to stay within available capacity. usually a mid-point scheduling is carried out then and earlier and later operations of the order are scheduled on the respective work centers to avoid orders getting stuck. That is a novel idea and often perceived as impossible to do when a repetitive environment is managed with discrete orders in SAP (Consultants are very quick to point out that repetitive can't do capacity planning and they then point to discrete where they feel more comfortable). Capacity planning in REM is absolutely efficient... you have much more options and you can 'flow' the lines with takt-based scheduling and integrated Kanban withdrawals. Refer to my other blog posts or read some of SAP's REM documentation for further detail. You just have to rethink your basic idea about capacity planning a little, but REMs capacity planning is superior to discrete - at least when you operate in a repetitive environment.
I could go on for days... explore SAP REM... it's worth it and it was developed just for you, because discrete doesn't work so well for you... at least if you are a repetitive manufacturer - and that you are if you don't happen to make plates with holes and handles (or you're running a jumbled job shop environment)
When you’re in the business of manufacturing parts that you sell through a catalogue, chances are you’re a repetitive manufacturer. And if you produce the same product over and over on a mixed model line, SAP has great functionality for you to schedule and level your production plan – readily available in ECC 6.0. No need for extensive customizing or running a project with 5 consultants over the next 6 months; just yesterday I configured a demo into a client’s ‘sandbox system’ within 3 hours.
As we discussed in part I, to introduce flow into the production line means reducing WiP and with it cycle times. So flow is very desirable, especially if you’re in the repetitive business and to achieve it, you need to balance the operations of the line. Balancing the line means that you allow the same amount of time a product can spend on a work center for every operation. In that case there will be no buildup of WiP (no product has to wait until it can processed on the next work center) in front of any work center.
Let’s see how SAP-ERP can help you do that: First you need to set up your products for repetitive manufacturing and create at least one production version through which you assign the products to the Line Hierarchy. This represents your mixed model line. The production version relates to a routing that contains all operations and work stations the product undergoes while being produced (it ‘flows’ through the line).
The routing may be a Rate (Line) Routing that can be represented graphically…
Once all products are assigned to the Line Hierarchy, you can create a Line Balance for a short term planning horizon of, let’s say, 4 weeks. In that Line Balance, you copy the demand for the next 4 weeks and calculate a takt time by which you need to run the model mix to fulfill exactly that demand. This works in the following way: The system looks at the total demand for all products in the model mix for the next 4 weeks and calculates a daily rate for the model mix, which is necessary to meet the total demand over 4 weeks. Imagine you have 3 products - A, B and C – and a demand of 200, 400 and 100 pieces over the next week for these products. If there are 20 working days in your next 4 weeks, you need to produce 10 As, 20 Bs and 5 Cs every day to fulfill the demand over the next 4 weeks (according to EPEI heijunka leveling). Therefore you need to produce 35 pieces on the line every day. If you have 7 hours available every day, you need to produce 5 pieces per hour or introduce a piece into the line every 12 minutes… this is called the takt time. That, in turn, means that every work center has 12 minutes of work content before it needs to move the product to the next work center.
In above example we have a maximum rate of 35 pieces per 7 hours and a model mix that adheres to the maximum rate. Now we have to make sure that all operations in any work center do not exceed the maximum allowable time in any work center – the takt time. That, in essence, is Line Balancing and may be carried out graphically in standard SAP.
In the Line Balance we can see that product 188 causes a takt violation with operation 0080 on work center 65030TRY (note that work station 65030TRY has more work content available. This is because we have more capacities available – either more labor or more machine capacity). You could now do either one of two things: either you increase the amount of machines used on work center 65030TRY or you could move the operation to another work center, in the flow, that has more work content available. Either way the takt violation is cured.
In any case, you have now calculated a takt time – the speed by which the line must be run to meet demand – and you can now use takt-based scheduling to determine the sequence plan as follows.
From here we can now perform a collective availability check, print the daily schedule or fill a heijunka board on the shop floor. The schedule may also be connected with a Kanban control cycle but that is stuff for another blog post…
Schedule lines are not created by MRP, instead planned orders or purchase requisitions are created 1967840 - MRP does not create schedule lines
Schedule lines are not displayed in MD04 Check the reduced quantity in field EKET-DABMG. If it is equal or larger than the schedule line quantity, the schedule line is not displayed in MD04. If you still don't know why, you may try to debug by setting a breakpoint at form PRUEFEN_MDBS of program SAPLM61X. Refresh MD04 list. The debugger will stop at the breakpoint.
Schedule lines are shown as firmed in MD04 2088322 - Schedule lines are displayed with an asterisk ( * ) in t-code MD04/MS04
Stock transport delivery date is not correct 361308 - Stock transf.releases:Scheduling via plnd dely time 76301 - Scheduling stock transport order/PReq
Multiple / redundant schedule lines are created 1745312 - MRP creates redundant proposals though there are fixed future receipts which can cover the requirements.
Duplicate / double schedule lines on the same date 2108166 - Duplicate schedule lines are created with the same date by MRP
SCN is a great place to share knowledge and learn from experts. I'm recently going through the blogs/documents posted on SCN. I see so many useful documents which I benefited a lot. Sometimes I even feel regrets that it would have saved a lot of time to troubleshoot a problem if I had read the document sooner. These documents are definitely worth your time. It's really a pity to see them buried in the document sea. So I'm keeping a track of the documents I read in this blog and will keep it updated if I see anything new and useful.
PS: Documents marked with a happy face are written by me. Image may be NSFW. Clik here to view.
Three groups of Lot-sizing procedures are available:
Static lot-sizing procedures
Period lot-sizing procedures
Optimum lot-sizing procedures
I will explain here about one of the Optimum lot-sizing procedures: Least unit cost procedure (WI).
Feature
Starting from the shortage date, successive requirements are grouped together to form lots until total costs per unit reach a minumum level. The total cost are equal to the sum of the lot size independent costs plus the total storage costs.
Prerequisite
- Lot size field (MRP 1 view) is set with WI for Least unit cost procedure.
- Lot size independent costs (MRP 1 view) and storage costs indicator (MRP 1 view) is set.
- Requirements exist. In this sample, there are 4 planned independent requirements (PIRs). They are with date 2015/2/6, 2015/2/13, 2015/2/20 and 2015/2/27.
After the upgrade for releases 616 and 617 some customers are observing that, after the MRP run system does not plan any material.
The problem is observed after the MRP execution on MD01, MDBT or by program RMMRP00 and it happens because the planning file entries do not exist anymore. In addition, the problem is only observed on systems where the planning file entry is stored on the old table MDVM and where report RMMDVM10 is executed frequently.
The issue happens because of a program error on report RMMDVM10 causes the deletion of the planning file entries from table MDVM. Without planning file entries, MRP will not select any material for planning.
If you are facing this issue on your system, the following note should be implemented, in order to correct the error on report RMMDVM10:
After that, transaction MDAB (or report RMMDVM20) should be executed, in order to rebuild the planning file entries.
In addition, some clarifications are necessary regarding reports RMMDVM10 and RMMDVM20, as there is a lot of misunderstanding and misusage of these reports.
1 - Report RMMDVM10 runs a consistency check for the planning file entries. It can catch inconsistencies on the low-level code and delete unnecessary planning file entries, however, this report DO NOT check the flags NETCH and NETP for existing entries.
2 - Report RMMDVM20 is generally used to build the planning file entries, before the first MRP execution for a plant. This report will create the planning file entries when they do not exist, however, if the planning file entry already exists, the report WILL NOT check the flags NETCH and NETPL.
I have seen many users running those reports, expecting to have the flags NETCH and NETPL checked, therefore, it's very important to reinforce that this is not the purpose these reports.
Both reports were created for very specific purposes and they were not originally designed to be used regularly. It means that it's not necessary to run any of these reports on a daily or weekly basis on your system.
Running those reports regularly on your system or even before the MRP executions is generally a waste of resources and it will only contribute to increase the total MRP background jobs runtime.
The following KBA also provides more details about the frequent issues related to planning file entries and it may be useful for further reference:
Error 2048 has occurred while executing database procedure ""_SYS_BIC"."sap.erp.sappl.pph.v01.mrp.run/MAT_PLANT_MRP"" on the current database connection "R/3". Database error text: column store error: search table error: [2620] _SYS_BIC.sap.erp.sappl.pph.v01.mrp.run/MAT_PLANT_MRP: line 48 col 3 (at pos 2038): InternalFatal exception: _SYS_BIC.sap.erp.sappl.pph.v01.mrp.run/MAT_PLANT_MRP_PREPARE: line 19 col 3 (at pos 1961): Internal Triggering statement: "dsql_open_proc"
Solution:
To execute MRP Live on HANA, active ScriptServer is required. KBA 1994190 (Shot dump DBPROC_SQL_ERROR occurs when executing transaction code MD01N) explains this. Note 1650957 describes how to activate ScriptServer from HANA database perspective.
2.
"No planning file entry exists for this selection" is displayed on the left bottom of MD01N initial screen.
Solution:
The planning file entries in table DBVM is required. You should execute transaction code OM0F to convert planning file entry from table MDVM into DBVM. KBA 1976004 explains this.
3.
MRP run terminated due to error: Fatal exception occured: Number range not maintain
Solution:
You must create a new number range named "PP" for objects BANF, PLAF and RESB. KBA 1993505 explains how to create number range "PP".
4.
Runtime error ITAB_DUPLICATE_KEY Program ABAP CL_PPH_MRP_DISPATCHER=========CP
The transaction variant/standard variant/screen variant which can be created in transaction SHD0 can be used in many transactions to change the field/button/tab attribures in screens, e.g. hide or make them required fields or display only. If there are no customizations for the transactions to do the same, SHD0 would be an alternative solution. For more information of the variants above, you can read its documentations in SHD0 by clicking the button 'Application help Ctrl+Shift+F12'.
However, the variants can only be created for dialog transactions and others like parameter transactions cannot be applied. In SAP customizations, many transactions are parameter transactions, they have their own transaction codes and call transaction SM30 for a table view with specified parameters, here is an example for PP kanban transaction PK05.Image may be NSFW. Clik here to view.
I'd like to make the field 'Responsible' as a required field by standard variant, but get an error below that the variants are only possible for dialog transactions and the transaction PK05 is a parameter transaction.
In transaction SE93 below for the transaction code PK05, we can see that PK05 calls transaction SM30 inside for the table view V_pvbe.
So, the idea is, create a standard variant for transaction SM30 and the view V_pvbe as following because SM30 is a dialog transaction. Click the button 'Create' as below to create it.
Continue on as we normally do in SM30 or PK05 to reach the screen where the field 'Responsible' is, tick on the field 'Required' at the line of 'Responsible', save the variants.
In some business scenarios, you need to control if an specific planning element will be relevant to MRP or not. For some MRP elements, there is no customizing or master data setting to control that, therefore, SAP delivered BAdI MD_CHANGE_MRP DATA, which allows you to add a custom logic to define the MRP availability of each planning element.
This BAdI is called during the MRP run and on the MRP transactions, such as the stock/requirements list.
On the screenshot below you can see that there is an element PRqRel. This element is MRP relevant, as it is turning the available quantity negative and a purchase requisition was created by MRP to cover it.
It is a very commomn business requirement to have only stock transfer order (not requisition) releases relevant to MRP on the supplying plant. On this document you will find an example of how this BAdI can be used to make a stock transfer requisition release not relevant to MRP on the supplying plant.
Firstly, open BAdI MD_CHANGE_MRP_DATA on transaction SE18. Clicking the button "documentation" you will find a detailed description of this BAdI.
On tab "interface" you will find a list of all the available methods. There is one method for type of each planning and, since this example is focused on stock transfer requisitions releases, we will use method CHANGE_MDPSX_MDUA.
Here you will find a sample code delivered by SAP that makes stock transfer requisitions releases not relevant to MRP (this logic replaces the old modification note 190298). This code will be used as a base for our BAdI implementation.
Get back to transaction SE18 intial screen, choose the menu IMPLEMENTATION and CREATE and choose a name for your BAdI,
On the next screen, write a short text and double click method CHANGE_MDPSX_MDUA, on tab interface. You may be prompted to save and choose a package to your BAdI. You may click the button "LOCAL OBJECT" if you don't have a package.
Now copy the sample code, make the desired changes and activate your method.
Go back to the previous screen and activate the BAdI. If the BAdI is correctly activated, you will see the text "Implementation is called" on field "Runtime Behavior".
Checking the same material from the first screenshot again after the MRP run, we can notice that the purchase requisition was deleted and that stock transfer requisition release does not affect the available quantity anymore.
The same logic can be used on another methods to control the MRP relevance of other planning elements. Basically, field VRFKZ from the internal table CH_MDPS controls the MRP relevance of an MRP element. Besides that, another fields of CH_MDPS can be changed and on the documentation you can find a list of the available parameters. If you don't want to see the planning element on MD04 you should use the parameter CH_EXIT.
You should consider that this BAdI will be called during the MRP run and a complex logic implemented here may affect the MRP overall performance. Also, changes made on planning elements within this BAdI are not saved on the database, however, they will be considered by MRP, therefore, this BAdI should be used very carefully.
For more details about all the BAdIs available on MRP, see the following document:
On the latest SAP ERP releases, MRP has been optimized to improve the overall performance using a HANA database.
This optimization can be activated by the business function LOG_PPH_MDPSX_READ and now there are two different MRP modes:
Classic MRP: The old MRP transactions, (such as MD01, MD02, etc...) were optimized to improve the performance when reading planning elements from the database, when running on a HANA database.
The internal logic to read the planning elements from the database to the internal table MDPSX has been completely redesigned for a better performance with HANA.
There is no substantial change on the transaction design but you can find a flag pointing that the optimization was active during the MRP execution:
This optimization is available as of SAP enhancement package 6 for SAP ERP 6.0 (version for SAP HANA).
MRP Live: This is a new MRP mode, where MRP has been fully redesigned to run an in-memory planning run.
Instead of several different transactions (MD01, MD02, MD03...) there is only one transactions, with more fields for selection, which provides you more flexibility when running MRP.
The new transaction code is MD01N and the report name is PPH_MRP_DISPATCHER:
On this new transaction you can plan a specific group of materials, a product group or all the materials of an MRP controller, for example. It is also possible to run multi-level MRP (same as MD02) checking the flag "BOM Components" or MRP for a single materials (such as on MD03).
The already existing MRP functionalities are still supported, but with a few exceptions.
Even if MRP finds one of these exceptions, this material can still be planned on transaction MD01N. However, instead of running MRP live, it changes internally to classic MRP. A complete list of these restrictions can be found on the following note:
1914010 - MD01N: Restrictions for Planning in MRP Live on HANA
MRP live generally provides a more effective performance improvement than the classic MRP. However, the improvement in performance in MRP live on HANA compared to classic MRP depends on the following:
MRP features used
Number of materials to be planned
Number of materials not to be planned
Number of low-level codes
Basically, the more materials are planned on MD01N with MRP live, better is the performance improvement.
For more details about the performance optimizations using MRP Live, see the the note below:
2023766 - MRP Live/MRP Classic: Performance Information
MRP Live is available as of SAP Enhancement Package 7 for SAP ERP 6.0, support package 01.
You can also find more details about the Performance Optimizations for MRP (both classic MRP and MRP live) on the following link of SAP help:
Have you ever come across error CO 901, saying "Program error (Contact your system administrator)", when you try to TECO a production order? If you are using industry solution IS-AFS, the root cause may be that inconsistency exists between table RESB and J_3ABDSI for the production order, and solution is to run report J_3ACOBD.
Do you want to know how to figure out the the inconsistency data? Here are some debug info about it.
SAPLJ3AU / LJ3AUF20
FORM / ORD_PRE_GET_RESB_BT
CLEAR RESB_BT.
READ TABLE RESB_BT WITH KEY RSNUM = I_RSNUM <<< you can check the reservation number and counter here.
RSPOS = I_RSPOS
BINARY SEARCH
IF SY-SUBRC NE 0.
SELECT SINGLE * FROM RESB
WHERE RSNUM = I_RSNUM
AND RSPOS = I_RSPOS
AND RSART = ' '.
* RESB in der DB ebenfalls nicht vorhanden --> Abbruch
IF SY-SUBRC NE 0.
MESSAGE A901(CO).
ENDIF.
MOVE-CORRESPONDING RESB TO RESB_BT.
ENDIF.
19 FORM ORD_PRE_GET_RESB_BT SAPLJ3AU
18 FORM ORD_PO_PRE_BDSI_PREPARE SAPLJ3AU
17 FUNCTION J_3AU_ORDER_POST_PREPARE SAPLJ3AU
16 FUNCTION CO_BT_ORDER_POST SAPLCOBT
15 FUNCTION CO_BT_ORDER_POST SAPLCOBT
14 FORM ORDER_POST SAPLCOZV
KBA 2159613(Program error occurs when TECO a production order) also describes this.
Hi,I have come across scenario where business want component serial tracking.
Business Scenario : Business involved in manufacturing of products with serial numbers,few raw materials required for finish products are with serial numbers.
business want to generate test certificate for finish products with serial number of components.
Solutions :
1.Create Serial number profile with Procedure QMSL-Maintain inspection lot.
