domingo, 16 de julho de 2023

Stock/Requirement Pegging (MD04P) and MRP Statuses

 SAP S/4 HANA has come up with multiple enhancements in existing standard transactions. In this blog, we are going to discuss the MRP statuses and Stock Requirement Pegging. Both functionalities are made available from S/4 HANA with 1709 release.

Users can refer transaction MD04P- stock/requirements pegging as the facelift version of the popular standard transaction MD04. The MRP statuses groups the MRP elements on the basis of pegging in the MD04P report. The MD04P display is a user-friendly ALV screen and can be transferred to Microsoft excel in tab file format.

MRP Statuses

MRP Statuses are pre-configured keys which group the MRP elements in the stock requirement list on the pegging criteria. The grouped list is shown in MD04P.

Available MRP Statuses

MRP StatusDescription
*Custom Status 3
/Custom Status 5
#Custom Status 1
%Custom Status 2
+Custom Status 4
3Planned independent requirements that have been consumed by sales orders. Sales orders for which you have already posted a goods issue are not displayed in this status.
AFreely available stock, unrestricted-use stock (batch stock, purchase requisition, planned order, and so on) which are considered during the standard MRP run as valid available stock that has not yet been assigned to requirement.
BMRP blocked requirements: Any demand/requirement that has not yet been covered by any existing stock.
CSupply Assignment: IFO Assignment
DSupply Assignment: On Delivery
ESales order stock: Stock that is posted in inventory management with reference to a sales order. The sales order must be flagged with an item category according to make-to-order production or purchase-to-order procurement. MRP does not change this assignment. The allocation run changes this assignment to status F (fixed).
FSupply Assignment: Ready for Delivery- Stock element is fixed by the requirement documents. Outbound delivery can be created for these requirement documents.
HSupply Assignment: On Hold for Delivery – Stock element is fixed and on hold by the requirement documents. Outbound delivery cannot be created for these requirement documents.
IAdditional Information
KVendor Consignment Stock
MRetail Merchandise Distribution
NStock with account assignment without requirements. Example: First a sales order (make-to-order) was planned but then the customer rejected it at a later time. The stock remains in status N until it becomes unrestricted-use stock again after a balance sheet transfer. Stock with this status is not used for covering requirements in MRP.
OSupply Assignment: Ready for Release – Stock element is allocated to the requirement document. A release rule check is required before the outbound delivery can be created.
RSupply Assignment: On Reservation- Stock element is reserved by the requirement documents. Outbound delivery cannot be created for these requirement documents.
SInformation about third-party order processing.
TTemporary assignment of requirements to stock.
WCustomer consignment. You post stock to inventory management stock with reference to the customer. You can increase and reduce stock by consignment fill-up and consignment withdrawal.
XExcluded requirements. Display of requirements that are not considered during MRP in a make-to-stock scenario. Allocated stock elements are displayed for information purposes only.
ΣStock/Requirement Overview

 

Stock Requirement Pegging (MD04P)

Stock Requirement Pegging is the dynamic list similar to the standard stock requirement list with a pegging advantage. The transaction is available from S/4 HANA 1709 release onwards. The transaction layout is more realistic than MD04. The transaction is available for individual and collective access.

Prerequisites

User need access for authorization object

  • FSH_HRL
  • M_MTDI_ORG

Display

The selection screen contains the input material, plant in the mail screen. The additional filters are available for MRP statuses (above mentioned list), Stock Element, Stock Number, Requirement Element and requirement Number. Users can also set the validity in the future from today.

The main screen has three tabs and a details screen as like MD04

The first tab is T- Temporarily Assigned Stock/Requirements List. It shows the list of the requirement elements against Stock elements (catering elements) in one line.  After MRP run, the stock element is updated for every requirement element. The other planning details like dates and material are also available in the same line.

The second tab ∑- Stock/Requirement Overview gives more details about the requirement element.

Order conversion and other function are accessible from the top menu.

 

The Third Tab I- Additional Information gives the summarized details of the stock elements and required elements. In this view, user can see the overall picture for the planning situation along with excluded stock for planning.

Conclusion

The MD04P gives additional pegging information over MD04. The basic advantage is to see pegging immediately on the first screen.  The customized report can be designed on the basis of the function module ‘FSH_API_GET_STOCK_REQ_LIST’ (Not Released Status).

 

Regards,

Chandrashekhar Damale


Source: https://blogs.sap.com/2020/03/10/stock-requirement-pegging-md04p-and-mrp-statuses/

Handy tools for SAP TM Development

 

Intended Audience

You are

  • an SAP TM Developer or Consultant.
  • familiar with the ABAP programming language, BOPF framework.

You have already

  • faced the difficulties of GUIDs, determination/validation cycles.
  • debugged TM ABAP code.
  • got lost in the call stack / complexity of a debugger session.

You would like to understand

  • which BOPF action is responsible for setting a certain field?
  • how does the TM application work within the BOPF framework?
  • what is the actual execution sequence of actions and determinations?

Introduction

In this blog post I would like to show you how I use the following tools in SAP TM maintenance:

  • Notepad++:                     to deal with GUIDs.
  • Change Documents:      to investigate the crime scene.
  • TM BOPF Navigator:     for free style search, navigation, and where-used-list of BOPF objects.
  • Debugger script /SCMTMS/DS_TRACE: to quickly identify, which code is responsible for certain changes, and to visualize the program flow.

Disclaimer:

Debugger script /SCMTMS/DS_TRACE was written as an internal support tool. Though officially not supported, any feedback is highly appreciated and will be considered. Please be aware that certain gaps, features, fixes to bugs – that would absolutely make sense – may never be implemented.

Notepad++

As a complementary tool, I use application Notepad++ from https://notepad-plus-plus.org/ to find identical GUIDs with a double click:

Figure%201%3A%20Notepad++%20*%20Click%20to%20enlarge%20*

Figure 1: Notepad++ * Click to enlarge *

In this screenshot, you can see the data I have copied from database tables and double clicked on one of the ROOT GUID. When working in a debugger session, I regularly copy the content of internal tables into Notepad++ and use this feature to quickly identify TOR documents with PARENT_KEY or item hierarchy with ITEM_PARENT_KEY, for example

 

Change Documents

Whenever someone asks: “This field value was changed, why?”, your first task is to identify when it has happened. So that we could identify the exact process as a first step to provide a step-by-step reproduction.

This can be identified from the “Change Documents” tab, Transaction Code:

Figure%202%3A%20Change%20Documents%20*%20Click%20to%20enlarge%20*

Figure 2: Change Documents * Click to enlarge *

As column “Transaction Code” is hidden by default, you will need to add it to the displayed columns. In this screenshot, I have also replaced the description columns with “Node” and “Field Name”, as for me, the technical names are more informative.

Now, what corrections are needed and how can the values under “Transaction Code” be interpreted?
Consulting note #2951038 -How to use Change Documents, field Transaction Code
describes possible values and the existing correction notes.

On the screenshot under column Transaction Code, value /SCMTMS/FRE_ORDER means, that the change was done on the Freight Order maintenance WebDynpro application. Value /SCMTMS/FWD_ORDER means the Forwarding Order maintenance WebDynpro application.

Sometimes it is not that easy to identify the origin of a Transaction Code even with the help of consulting note #2951038. Maybe a prefix character could be added to quickly identify the source, in this example “Web Dynpro Application”. What do you think? Can you use “Transaction Code” on the “Change Documents” tab “as is” or would you welcome a prefix character? Please share your opinion in the comment section of this blog!

TM BOPF Navigator

Start TM BOPF Navigator with transaction code /SCMTMS/BONAV.
This is what I would call a fine tool, as it does not need any documentation.
Enter any search term and explore the functionality yourself!

I frequently use it to

  • navigate with a double click into ABAP source code directly after vaguely remembering an action name.
  • discover the usage of actions via “Where-Used” List

Figure%203%3A%20TM%20BOPF%20Navigator%20*%20Click%20to%20enlarge%20*

Figure 3: TM BOPF Navigator * Click to enlarge *

Please share your improvement ideas for this tool in the comment section, let’s make this even better together!

The latest correction was delivered in the following correction note:
#3234950 – Technical correction, TM BOBF Navigator 3.

 

Debugger Script /SCMTMS/DS_TRACE

Some thoughts on debugger scripts if you have not used them before. It can be used to automate what you can also do manually in a debugger session. Here is a blog post how it works: https://blogs.sap.com/2010/12/14/abap-debugger-scripting-basics/

You do need a debugger session to be able to execute a debugger script. It means, that you cannot use it to investigate a “not reproducible issue”. It can also not be used for example to trace all users in the background.

It can be used in the following situations/cases:

  • A reproducible example is available.
  • It is known at which interaction step the issue occurs.
  • It can be used to trace a single interaction step.

Selecting “Start New Trace” in transaction /SCMTMS/DS_TRACE creates a breakpoint in the WebDynpro framework. When you execute the step that you would like to trace in the TM application, the breakpoint will start a debugger session. Then you can load and start the debugger script to trace the execution of that interaction step.

Why was it important to understand the technical background? Because this breakpoint may also start the debugger for other reasons:  For example, a “Proposal Search” aka “Type-ahead Search”, that is being executed as you type, may involuntarily start the debugger session. Be mindful and exit the debugger if it was accidentally started for a “Proposal Search”!

Now let me show you the use of debugger script /SCMTMS/DS_TRACE.

The STORY is a mystery to be solved:

There is a freight order having a “Proof of delivery” execution event already reported.
After reporting the “Arrival at destination” event, “Proof of delivery” event was deleted:

Figure%204%3A%20Freight%20document%2C%20Execution%20events%20tab%20*%20Click%20to%20enlarge%20*

Figure 4: Freight document, Execution events tab

Let’s find out together why this has happened!

  • Prepare a freight order with a “Proof of delivery” execution event.
    Enter “Arrival at destination” event (do not save it yet).
  • In an SAPGUI session start transaction /SCMTMS/DS_TRACE.
    Select button “Start New Trace”. Enter a trace name, Continue.

Figure%205%3A%20Transaction%20/SCMTMS/DS_TRACE%2C%20start%20new%20trace%20*%20Click%20to%20enlarge%20*

Figure 5: Transaction /SCMTMS/DS_TRACE, start new trace

  • When the next window is displayed, a breakpoint was set in the WebDynpro framework so that a debugger session could be started. Switch back to the freight order screen now!

Figure%206%3A%20Transaction%20/SCMTMS/DS_TRACE%2C%20take%20the%20trace%20now%20*%20Click%20to%20enlarge%20*

Figure 6: Transaction /SCMTMS/DS_TRACE, take the trace now

  • Select “Save” in the freight order. This is the interaction step that we shall trace with debugger script /SCMTMS/DS_TRACE.
    Remember: “Proof of Delivery” event was already saved on the document, we have entered now an “Arrival at Destination” event and shall check what happens during save.

Figure%207%3A%20Freight%20document%2C%20Execution%20events%20tab%20before%20save%20*%20Click%20to%20enlarge%20*

Figure 7: Freight document, Execution events tab before save * Click to enlarge *

  • A debugger session is started automatically. In the debugger session select tab “Script”, load and start script /SCMTMS/DS_TRACE.

Figure%208%3A%20Debugger%20session%2C%20load%20and%20start%20script%20/SCMTMS/DS_TRACE%20*%20Click%20to%20enlarge%20*

Figure 8: Debugger session, load and start script /SCMTMS/DS_TRACE * Click to enlarge *

  • The debugger script is expected to run silently. It is expected that the freight order session is returned with a saved freight order. The “Proof of delivery” event was deleted:

Figure%209%3A%20Freight%20document%2C%20Execution%20events%20tab%20after%20save%20*%20Click%20to%20enlarge%20*

Figure 9: Freight document, Execution events tab after save

  • Switch back to the SAPGUI session, select “Continue” to close the last window. The trace file is displayed in the file list.

Figure%2010%3A%20Transaction%20/SCMTMS/DS_TRACE%2C%20trace%20file%20*%20Click%20to%20enlarge%20*

Figure 10: Transaction /SCMTMS/DS_TRACE, trace file

 

It is time for the analysis of the trace file!

  • Open the file and select tab “Modifications” to show the modifications of the document(s). Column “Change” shows, that only changes occurred for the events (no delete/insert). Double-clicking on one of the modifications reveals that field EVENT_REVOKED was updated.
  • Using the free style search, we mark all modifications that have updated field EVENT_REVOKED.

Figure%2011%3A%20Transaction%20/SCMTMS/DS_TRACE%2C%20Modifications%20tab%20*%20Click%20to%20enlarge%20*

Figure 11: Transaction /SCMTMS/DS_TRACE, Modifications tab * Click to enlarge *

From the “Modifications” tab, we have learned that the “Proof of Delivery” event was not deleted but revoked. Where did it happen?

  • Select tab “Hierarchy” to show the executed actions/determinations. The search is still active for field EVENT_REVOKED, so it shows the same modifications as on the “Modifications” tab, but also displays the action that has created them.It shows that action TOR-EXECUTIONINFORMATION-REVOKE_EVENT has created these modifications that revoked the “Proof of Delivery” event.

Figure%2012%3A%20Transaction%20/SCMTMS/DS_TRACE%2C%20Hierarchy%20tab%20*%20Click%20to%20enlarge%20*

Figure 12: Transaction /SCMTMS/DS_TRACE, Hierarchy tab * Click to enlarge *

Now we know, which action was responsible for this change.
Lastly, we would like to identify when this action was called.

  • Select tab ‘Time Stream’ to show the trace data in the execution time sequence. The hierarchy displayed is the call hierarchy (like “ABAP Call Stack” in a debugger session): The parent level executes the actions/determinations of the child level.On the screenshot the red arrows show the call stack / execution hierarchy of action REVOKE_EVENT.

Figure%2013%3A%20Transaction%20/SCMTMS/DS_TRACE%2C%20Time%20Stream%20tab%20*%20Click%20to%20enlarge%20*

Figure 13: Transaction /SCMTMS/DS_TRACE, Time Stream tab * Click to enlarge *

What has happened?

  • Seq 3  Action REPORT_EVENT has created the “Arrival at destination” event.
  • Seq 6  Determination DET_EXEC_AM has started processing event modifications (in this case the event creation of “Arrival at destination” event).
  • Seq 11 and 21  Freight order stops and items were updated with handling statuses (in response to the new event). This led to the removal (EVENT_REVOKED = X) of the “Proof of Delivery” event at Seq 22.

Now we know that the “Proof of Delivery” event was revoked based on an item level handling status change.

  • The following screenshot shows the changes of the stop / item handling statuses:

Figure%2014%3A%20Transaction%20/SCMTMS/DS_TRACE%2C%20Time%20Stream%20tab%20*%20Click%20to%20enlarge%20*

Figure 14: Transaction /SCMTMS/DS_TRACE, Time Stream tab * Click to enlarge *

We can see that Handling Execution Status on Item Level (TOR-ITEM_TR-HANDLING_EXEC) was set to value 04 – Not Unloaded. Meaning, that if the item is “Not Unloaded”, the Document cannot have a “Proof of Delivery”, thus the event was revoked!

 

Concluding Remarks

As we saw, there is not only a debugger script to create a trace file, but also a powerful visualization and navigation transaction for the analysis of the trace files.

I hope you have enjoyed following this example!

I encourage you to further discover both the tool and its other powerful features:

  • Read the built-in “How to Guide” and “Good to Know” for more information.
  • Use the “Where-used-List” and “BOBF”, jump into the source code via double click.
  • Discover even more data and functions by double-clicking on the trace lines.

The latest correction of the tool was delivered in SAP Note: #3281444 – Technical correction, Debugger Script: TM generic 3.

Last, but not least: With the latest corrections, we have new options for “Start New Trace” to avoid a timeout of the debugger session:

Figure%2015%3A%20Transaction%20/SCMTMS/DS_TRACE%2C%20new%20options%20on%20Start%20New%20Trace%20window%20*%20Click%20to%20enlarge%20*

Figure 15: Transaction /SCMTMS/DS_TRACE, new options on Start New Trace window

Both “Simple trace” and “Forced trace write” are empty by default and can be set to X.

  • “Simple trace”:
    When too much data is processed, the debugger script slows down the processing so much, that the debugging session times out. Set “Simple trace” to X to avoid this time out. The trace file shall contain less data, but at least it does finish.
  • “Forced trace write”:
    The other solution to avoid time outs was to write the trace file only once at the end of the processing. It works most of the time. However, when it misses writing the trace file, then there is no trace file at all!
    Thus we needed the second parameter “Forced trace write” to fall back to regularly write out the trace file. Setting it to ‘X’ means, that you will always have the trace file with the time-out handicap in case of too much data is processed.
Source: https://blogs.sap.com/2023/05/11/handy-tools-for-sap-tm-development/?source=social-Global-LINKEDIN_COMPANY-TrainingEnablement-Digital_Supply_Chain-DSC-Risk-resilient%2Fsustainable_supply_chain_IDP-spr-10356797382-account_name&campaigncode=CRM-YA22-BSC-1440506&sprinklrid=10356797382

Custom Migration Objects using BAPI

 In a SAP S/HANA project is often required to migrate master data from the current system (SAP or Non-SAP) to the new one, or also create massive master data.

Since the first release of SAP S/4HANA, it’s highly recommended by SAP to use LTMC(Legacy Transfer Migration Cockpit) tool, for massive master data loading.

The purpose of this blog is to enhance your knowledge about migration cockpit resources, if you are not familiar with this technology I suggest you read this blog (credits: Ruthvik Chowdary) before reading this one.

SAP delivers plenty of migration objects, such as business partners, cost centers, accounts, conditions records. Nevertheless, there are master data objects which are not supported.

The solution for those cases is customize your own migration object using a BAPI function which maintain the desired master data.

Below I’ll explain the steps how to do it by using master data of TM Resources as example.

Before starting, it is important to mention that the functional consultant may have the basics of technical knowledge, such as data types and BAPI execution, if necessary a technical consultant may help on the whole process.

I’m going to use BAPI function module BAPI_RSSRVSCMB_SAVEMULTI2 in order to fullfill the requirement of massive resource creation.

  1. Once the migration project is set, go to transaction code LTMOM in change mode and create a migration data object as “User defined”:
  2. Define a object name, its description and select option “Function Module”, and click on “Next”:
  3. On the next screen, fullfill the desired BAPI function name.
    In section of “Simuation Settings” fullfill with BAPI parameters which controls the db commit command, if aplicable.
    Click on “Next”:
  4. The new migration object will be created. Navigating throught the paths on the left side, select path “Source Structure”, select “Append structure to Lower Level” and then define a name for the structure:

  5. A window on the right side will be displayed where you can define the input file fields, click on “Insert field” button to create.
    TIP: Using same field names from BAPI function will help on automatic mapping afterwards.

  6. After defining source fields, you should map them to the BAPI structures, go to “Structure Mapping” path on the left side and then drag source structure to the BAPI structure, do the same for each field of the source structure.
  7. Go to “Field Mapping” path and click on “Rule Proposals”, the system will propose automatically field mapping.


    In case of fields that the system didn’t match automatically the rule proposal will get in blank, you may define it manually.
    Click on Continue.
  8. Now you can generate the migration object, click on “Activate” button.
  9. The activation result will be displayed at bottom of the screen, in case of no errors occurred you may test your custom migration object.

Master data is always a topic in SAP projects which demands time and dedication of the project team.
Using custom migration objects is an option to acelerate process of loading master data which are not covered by standard migration objects.

I hope you enjoyed this topic and it helps you on your SAP S/4HANA projects.


Source: https://blogs.sap.com/2021/08/13/custom-migration-objects-using-bapi/