S/4 HANA EWM Two Steps Cross Company Process and EWM – ERP integrations

This document shows that how to establish the relationship between EWM and ERP systems in the Cross Company process.
I have completed the necessary implementation steps for the EWM Cross Company Process. Testing processes have been started with sample goods issue from EWM storage location for EWM Cross Company process.  In our case, stock warehouse was decreased in EWM system but we didn’t observe the same decrease in ERP sytem which belong to same EWM warehouse. i have checked the T-Code SMQ2 (inbound queue) but i didn’t observe any error message. Then, i have designed similar implementation steps once again and new error message occured while i was trying to do our testing process.
Error Message: /SCWM/ERPINTEGRATION089
In the current situation, Mr. Ozgur has provided assistance and we have found a solution for that case. You can able to find the highlights in note which has been shared by SAP in the past few days.

M.Ozgur Unal: https://answers.sap.com/questions/687132/sto-ewm-storage-location-to-mm-storage-location-cr.html?childToView=688621&answerPublished=true#answer-688621

SAP Note;

https://launchpad.support.sap.com/#/notes/2374224
https://launchpad.support.sap.com/#/notes/2462035

The implementation has been done according to SAP Note. You can able to find the details in below.

We are matching outbound delivery order with EWM standard.

”In this Customizing activity, you can define the quantity offsetting profiles for the document types and item types in delivery processing.

Each quantity allocation profile is assigned to a system profile. The quantity offsetting profile takes the quantity roles, quantity determination rules and quantity offsetting rules from the corresponding system profile.”

We are matching outbound delivery orders from  ” Assignment of Quantity Roles ”

The following parameters must be defined from the Quantity Determination tab.

The following implementations are independent from above SAP Note.
The intergration must be done between EWM and ERP systems  after above implementation steps are completed properly.

Number ranges have to be maintained for ERP documents. Then, other implementation steps will be continued respectively.

We are creating a connection between ERP Delivery type and EWM Delivery Document.

We are matching Document type (ZNLC) and Item type (NLC) with EWM document type. We have used ” Differentiation Attribute for Item Type Mapping (E) ” to make it different from other item matches. Then, we associated with ODLV as EWM item type.

In the next step, we create the relationship between ERP Termin type, EWM Document Type and Item Type.

”The warehouse request differentiates between:

•Start and end date/time

•Planned and actual date/time

This means that both planned and actual start and end dates/times can be stored in the warehouse request.

When a delivery is received in the EWM system, the date/time types from the ERP system can be mapped to the start and/or end dates/times in the warehouse request. The start and/or end dates/times are then automatically stored as planned dates/times.

If you have defined that a confirmation be sent for start and/or end dates/times, these are confirmed to the ERP system when the confirmation occurs. The confirmation of dates/times occurs at the same time as the goods receipt or goods issue is reported to the ERP system.”

The next step will be message process implementation for ERP document type after above implementation steps are performed completely.

You have to maintain ” Configure Delivery Type & Availability Check Procedure by Plant ” as shown below.

”In this step, you specify whether an SD delivery is to be created in the case of a PO with a certain combination of supplying plant and document type. You can also specify which delivery type is to be used. For stock transfers with a billing document, the delivery type ‘NLCC’ is used.”

Standard NLC delivery type has been customized (Z).

I was asked to fulfill the two-step cross company process. Therefore, the fiction was made according to him.

In this step, you define which document type is to be used for a certain combination of supplying plant and receiving plant.

Cross company process will be unique step if you choose one step field as shown below.

The only requested thing that cross company process must be perform in 2 steps. Therefore, the fiction was designed accordingly.

”Depending on the supplying and issuing plants, you can also specify whether or not the stock transfer is to be executed according to the one-step procedure. With the one-step-procedure, the goods receipt in the receiving plant is posted at the same time as the goods issue in the issuing plant.”

Let’s test the accuracy of the customizing steps by testing a sample process in the system.

Let’s check the EWM and ERP stocks to see the changes before starting the processes.

The process will be started with purchase order step. If your implementations are correctly maintained, shipping tab will appear on screen. You can able to validate of data from there.

Outbound delivery document will be performed in background on T-Code VL10D/VL10B with using purchase order numbers. (5000000008)

You need to access to VL02N with the outbound delivery document number. The delivery document will be picking.

EWM storage address( W002) must be entered to storage location field and changes must be saved.

Go to /SCWM/MON and enter Outbound Delivery Order (Outbound -> Documents -> Outbound Delivery Order). Run the delivery document (80000227) by entering it to the ERP Document field on the incoming pop-up screen.

Then the warehouse task will be created for the Delivery Document (100000806) which is created on EWM.

After creating the warehouse task, we will go to the step of confirming warehouse task. We must enter the destination storage address manually due to customizing. Therefore, we will go to the ‘Confirm Warehouse Task in Foreground’ step to confirm the Warehouse task.

We will choose the “Confirm in Foreground”(1) button. Then, we will entered the Storage address to the “Destination Storage Bin” field (2). The “Warehouse task” will be confirmed with clicking the “Confirm+Save”(3) buttons. If the storage address is determined automatically, you can able to pass this step directly by clicking the “Create WT in Background”  button in the background.

Here is the goods issue batch number (1000001124) from EWM and ERP systems.

The status field will change as ‘C’ after the warehouse task is confirmed. When the Warehouse task is confirmed, we are going to make goods issues with delivery document which has been created on EWM system.

Go to transaction code /SCWM/PRDO. We can make goods issue with Delivery Order number (EWM)  or Outbound Delivery Document (ERP)

After you made a goods issue via SCWM/PRDO you can able to follow any error message from T-code SMQ2 to be sure abaout your process completed successfully or not.

Go to transaction code VL03N and check the information on the delivery document.

We will make goods issue(643 movement type) according to the delivery document on Two steps Cross company process. Then, we will make goods receipt referenced purchase order(101 movement type).

The goods entrance step will be started in ERP side after goods issue is done of EWM delivery document.Purchase order will be taken as references while goods entrance is processing.

I would like to mention the important points to be taken into consideration while entering goods according to the order on the ERP system;

In the two step cross company process, batch of material is disappearing while making goods issue. I want to mention an important point that you need to use same batch number while making a goods entrance in ERP system.

User has to enter batch number manually or has to read correct batch number with hand terminal(RFU device). User may make a mistake while using hand terminal or while entering batch number manually.

We need to make X batch’s goods issue from ERP and EWM stocks

The quantity of making goods issue on Two Steps Cross Company process is not be appear automatically on MIGO screen. We have to be carefoult that the quantity of making goods issue and the quantity of purchase order are can be different.

The quantity of making goods issue from W002 storage(643 movement type) and the quantity of making goods receipt (101 movement type) referenced to purchase order are have to be same. You can see as below..

After making goods issue, We will go to  /SCWM/MON  tcode to check EWM stocks. We can see the material’s physical stocks which was making goods issue. We can not display the batch number (1000001124) in screen because goods issue has been completed from batch (1000001124).

When we check the stocks in ERP side from transaction code MB52, you can able to see that 1000001124 batch has not stocks.

Two Steps Cross Company process and the integration between EWM and ERP systems have been completed successfully. The test results are correct as you can see.

Hopefully, this blog will be helpful for everyone

Orhan Akman

Source: https://blogs.sap.com/2019/06/22/s4-hana-ewm-cross-company-process-and-ewm-erp-integrations/

S/4HANA: How to analyze transaction MD04 in debug

Very
A long time ago I wrote the blog https://blogs.sap.com/2014/11/20/how-to-analyze-transaction-md04-in-debug/ explaining how to analyze the Stock/Requirements List (transaction MD04) in debug. I wrote this blog because I have seen many threads in SCN asking why a specific planning element is not appearing in MD04 or why an element appears with a different quantity than expected. Considering that debugging MD04 was pretty straightforward, even a functional person with minimal ABAP knowledge would be able to do it.
This blog was published in 2014 and one year later SAP announced SAP S/4HANA, which changed a little bit the design behind the Stock/Requirements List, in order to improve the performance when reading the planning elements. If previously the planning elements were read one by one from the database and processed individually by an ABAP code, now a single HANA stored procedure reads everything from the database and they are all processed together by an ABAP code.
Besides those changes, the code logic behind MD04, is still the same: The same function module AUFBAUEN_MDPSX_ANZEIGEN is called to read the planning elements from the database and the planning elements relevant for MRP will fill the internal table MDPSX.
The difference starts within function module AUFBAEN_MDPSX_ANZEIGEN. Here, there is a new piece of code which checks if system should use the classic logic or if should trigger the new selection built specifically for the HANA database.

When the new logic is selected, method GET_MAT_WERKS_S4H of class CL_PPH_MDPSX_SELECTION will be triggered, and here is where the magic will happen. Firstly, method EXECUTE_PROCEDURES_S4H will be executed, where the whole database selection will be triggered.
This data selection logic happens in HANA and we would have to access HANA Studio to be able to debug this step, so we cannot see the actual selection in the ABAP debugger. We can see, however, that the database selection results will be stored in the internal table LT_MDPS, so if there if a planning element is already missing here, it means it was not selected from the database and the problem is most likely related to the database selection in the HANA stored procedure.

After that, method FINALIZE_MDPSX_CDS from class CL_PPH_MDPSX_POSTPROCESSING will be called. Here is where the MRP elements selected from the database will be postprocessed and MRP will filter out certain MRP elements based on the settings or it will calculate the quantities, for example.
Within this method, we will basically have a loop in table LT_MDPSX_ENH, which will contain the MRP elements selected from the database and we will have specific checks for each kind of MRP element. In the following picture we can see where this loop starts and we can also see a piece of code with checks that are executed for the MRP elements consistency and also for stock transfer storage locations. Each check is executed separately and the best part is that we now have comments in English!!!

One point to be considered is that, with this new logic, the ABAP BAdI MD_CHANGE_MRP_DATA, which was traditionally called to change an MRP element is no longer called. However, BAdI MD_ADD_ELEMENTS is called after this loop and it can still be used for the same purpose.
Besides those changes when reading the MRP elements, the overall logic is the same and the additional function modules mentioned on my previous blog are still beins used:

• MD_GET_KUND: Read customer information for sales orders;
• MD_GET_LIEF – Read vendor information;
• MDEZX_AUFBAUEN – Build the MRP elements texts, as they are displayed on the screen;
• MDSUX_AUFBAUEN – Buld the MD04 period totals

Source: https://blogs.sap.com/2019/06/07/s4hana-how-to-analyze-transaction-md04-in-debug/

Use LTMOM to enhance fixed asset migration object to create sub-asset

Objective

The objective of this blog is to help you to enhance an existing migration object, specifically the Fixed Asset, but might be helpful to clear some doubts for other objects as well.

Additional remarks

The blog has no introductory aspects, it is recommended that you are familiar with the Migration Cockpit and the Migration Object Modeler, otherwise it will appear incomplete.
No ABAP skills required, but helpful if you have.

Introduction

It is common among fixed asset management processes to have complex assets, which consist of one or more sub-assets that are associated with a main asset. The sub-assets are associated with the same number of the main asset but separately identified by the sub-number.

SAP delivers within the S/4HANA Migration Cockpit an object for the migration of fixed assets, but this object contains some restrictions, one of these is the creation of sub-assets.
In this blog I will show how to enhance the object delivered for fixed asset migration to migrate a fixed asset as a sub-asset.
For additional information about the object restrictions, I suggest reading the documentation for the object available in the migration cockpit and the SAP Notes indicated in the documentation.

Understanding the API capability

There are different ways to understand how an API works, I suggest always start with the documentation, but there isn’t a rule for that.
Whatever way you choose to understand the API behavior, the first step is to identify the API used by the migration object.
For that go to transaction LTMOM, open you object and double click on the “Target Structures” menu, in the shown screen you’ll see the field “Function Module”.

Copy the function module name and go to transaction SE37 to display its attributes.

Once you are displaying the attributes of the function, look for the “Function Module Documentation“.

Documentation analysis should be done based on your business requirement.
It means, look for a parameter that is related to what you are looking for and read the information provided to understand how the parameter works.


Based on the documentation above, we understand that the API requires in the field CREATESUBNUMBER the value “X” to create a sub-asset instead a main asset, with that information we now know what is required to adapt in the field mapping of the migration object to achieve our goal.
Now let’s start to change a migration object, for that, go back to transaction LTMOM and make a copy of the Fixed Asset migration object (Z_FIXED_ASSET_XXX) of your project.

Identify technical requirements

We already know that the migration object delivered by SAP was designed to migrate the main asset only, so it is expected that the structures of the object need to be adapted for the creation of the sub-asset.
If your requirement is not the same as the proposed for this blog, will be necessary to perform two steps before you change the migration object:

• First, understand the field mapping.
• Second, test and simulate the new mapping to conver your requirement.

For the second step, use the transation SE37 to test and simulate your own mapping and check if the results will cover your requirement as expected.
For the business scenario that I proposed for this blog, I did these steps and will present here the conclusion.
There are three fields that need to be changed, which are:

• Main asset number – this field should receive the asset number created in the system.
• Asset Subnumber – this field should receive the subnumber of the main asset.
• Checkbox-create – as shown in the documentation this field should receive the value ‘X’.

In order to do that will be necessary to change the Source Structure, below is one of the standard source structures of the fixed asset migration object.

The different structures that contain in the migration object are related with each other by the key fields BUKRS + ANLN1 + ANLN2.

In our business scenario, we should be able to repeat this key several times in order to create several sub-assets for one single main asset, which won’t work in the curret state.

Thus, we need to add a new parameter in this key that allow us to repeat the Asset number and Asset subnumber, otherwise, the system will abort the process due to key duplication.

Look at the screenshots below to understand the scenario AS-IS/TO-BE.
AS-IS

TO-BE

Hands-on

Let’s adapt the migration object, please follow the steps below:
1. Include one field as key in all the structures of the migraiton object,
Remember, this new field will be used to sorting the sequence of the sub-asset creation, define a type that you can apply this kind of logic.

2. Adjust all the foreign key relationship between the structures.


3. Map the fields as shown in the screenshot below.
Note: Assign the conversion rules CVT_ANLN1 and CVT_ANLN2 respectively.


4. Assign a rule to move the fixed value (‘X’) to the checkbox field


5. Finally, generate the migration object again.


If you follow these steps, now you should be able to create the sub-assets with the Migration Cockpit.
Note that the field we add in the structure will not actually interact with the API structure, this is just to allow us to repeat the main asset number many times. In other words, even the field being a numeric type, its value will not be the actual subnumber, that column only is to sort the sequence that the sub-asset will be created.
I hope this document helps you with your requirement.

Regards.


Source: https://blogs.sap.com/2019/05/20/enhance-the-fixed-asset-migration-object-to-support-sub-assets-creation/comment-page-1/#comments

3 Tips You Should Know about SAP S/4HANA Migration Cockpit

You leverage SAP S/4HANA Migration Cockpit to migrate the custom legacy business data into the new SAP Cloud ERP——SAP S/4HANA. Here I list some scenarios where you would need help on using Migration Cockpit, and some useful tips you should know about Migration Cockpit.

---

Scenario 1: You are using Migration Cockpit for the first time, or you are encountering different questions on different migration objects. You don’t know what channel to check with.
Tip 1: It’s strongly recommended to read the SAP Note 2538700 before having hands-on experience on Migration Cockpit. This is a collective Note which provides you with a list of SAP Notes/Knowledge base articles (KBA) related to the SAP S/4HANA Cloud Migration Cockpit content.
There are questions related to the tool:

There are also questions related to certain migration objects:

Moreover, we are also updating this Note very frequently, to ensure all those latest hot questions are included.

---

Scenario 2: You are preparing the customer legacy data with certain migration object template, SAP just publishes new content for the migration object templates in the new quarterly release. You want to know if there are any changes to the migration object template which you are working on.
Tip 2: Considering the new content will be published every quarter, this is a common scenario which could happen at customer projects. SAP provides the Migration Objects Template Comparison Report, which helps the customer to find out what are the new/changed/unchanged migration objects between releases. It can also help to list out the detailed changes for certain migration object from release to release.
E.g. change overview from 1902 to 1905:

You can also find out the detailed field-level changes for every migration object between releases:

---

Scenario 3: You are filling the data into the migration objects template which you downloaded from Migration Cockpit. You are familiar with SAP R3 ERP, but not with SAP S/4HANA. You are having difficulties to maintain the migration objects template.
Tip 3: In every migration object template, we hide some fields(SAP technical structure name, technical field name, detail description). By unhiding the fields, it can help you to add the data into the template file correctly. Especially if you are an SAP R3 consultant, you will be very familiar with these technical names.



So, these are the tips which I would like to share in this blog. Hope it can help to clarify some of the questions you have on using Migration Cockpit


Source: https://blogs.sap.com/2019/05/21/3-tips-you-should-know-about-sap-s4hana-migration-cockpit/?

S/4HANA Cloud 1905 – What´s new in test automation tool for S/4HANA Cloud

The next release for S/4HANA Cloud is coming. Time to explore exciting improvements, new features, and… time to do regression testing!

Here is some information about
A) new features in test automation tool for SAP S/4HANA Cloud, and
B) changes to standard automated test scripts, delivered by SAP.

If you prefer listening to reading, you might want to check out the “early release webinar” for “SAP Activate deployment – test your solution”. It is available in the list of early release webinars for 1905.

A) New features

If there’s just one thing you take away from this blog, I’d like to highlight this first feature! We enabled the change of role for testing not only for custom process steps, but also for process steps in type “standard”. This allows you to do role-based testing, whilst keeping the respective process step in type “standard”. With that, you can profit from the quarterly updates to automated test scripts that SAP delivers.

“Manage Your Test Processes” app

1.Possibility to change roles in process type “standard”

2. Release change information available at test process level

3.Download list of test processes (filtered/unfiltered list) into an excel spreadsheet

“Test Your Processes” app

1. Release change information at standard automated test process

…is now available on test process level (under test plan). This highlights where a standard process step was changed compared to the previous release.

2.Download list of test plans (filtered/unfiltered list) into spreadsheet

3.Define test data variants that shall be used for execution within “schedule test plans” feature

 

4.Execute test processes with data variants (similar as available feature at test plan and logs level)

B) Changes to automated test scripts

In 1905, the number of pre-delivered automated test scripts increased to 228. The 13 new automated test scripts are in the following areas: Financials (7), Manufacturing (2), Database & data management (1), Sourcing & Procurement (1), and Supply Chain (2). The complete list of available automated test scripts in 1905 is available in the “Automated Test Scripts Index” in the JAM Group for test automation tool (request access via mail to saps4hanacloudtesttool@sap.com)
A detailed change information at test scripts is available in the “What´s new” document within the same JAM Group. SAP updates the pre-delivered automated test scripts (process steps in type “standard”) in every release, to adapt them to release dependent changes of your system. The “what´s new” document will highlight all changes to the pre-delivered automated test scripts on the test process step level. If you created custom process steps, you should check for changes in the original process step from SAP. Most likely you will have to adapt your custom steps in a similar way.


Source: https://blogs.sap.com/2019/05/03/s4hana-cloud-1905-whats-new-in-test-automation-tool-for-s4hana-cloud/?source=social-global-voicestorm-LinkedIn&campaigncode=CRM-YA19-SSO-GETSOC1

S/4 HANA : MSEG or MATDOC Where is my data going?

       

5 Likes 114 Views 1 Comment

In S/4 HANA, there is always a confusion about the tables MSEG and MATDOC. This blog is to explain where exactly your data is going and how to understand the link between MSEG and MATDOC tables.

For example, in the below case when you check the number of entries of MSEG in SE16N, it shows 55 entries.


Where as if you check the same in MATDOC, it shows the same 55 records. So which one is real?



Lets try a different approach. Lets try to check the correct entries through a database query using transaction DBACOCKPIT which directly queries the database. First check in MATDOC as below.

Perfect!. it shows 55 as expected when you run a straight forward select query from MATDOC at database level.
Lets try to run the same thing for MSEG now and I am sure you are expecting 55 here as well. Right?

Oops!. It shows 0. So it is clear that we don’t have any entries in MSEG in HANA database. It just simply points towards MATDOC internally when you run through SE16N. How is it doing & how do we know that?
This is an important screenshot taken from transaction SE11. Go to Extras menu for table MSEG and you will see these details.
SAP has introduced a concept called ‘Replacement Object’ where a CDS view name is mentioned. Earlier, this was called as Proxy object till 1709 version and it looks like SAP has renamed it as ‘Replacement Object’ to avoid any confusion because of the word ‘Proxy’.


For MSEG, NSDM_E_MSEG is shown as replacement object. So when you access MSEG either in SE16N or in your custom program, SAP routes the logic through this CDS view which gets the data from MATDOC. You can see the logic in the below screenshot.
Give CDS View NSDM_E_MSEG in view name in SE11. You will get the below details which gives the DDL definition name and the DDL SQL view name (NSDM_V_MSEG) also.

View NSDM_V_MSEG in SE11 clearly shows that it gets the data from MATDOC.
 
Last part in the DDL definition talks about any custom fields or appended fields and how this is handled in these replacement objects. You need to use Extend view and append the custom fields in Eclipse editor.

Please note that you don’t have the replacement object available for all replaced tables in S/4 HANA. This concept is different for each table and above explained steps are specific to MSEG/MATDOC. Replacement object/Proxy object concept was mainly introduced to avoid confusions/changes in custom programs which deals with MSEG. So if a custom program does a select from MSEG, it will still work similar to what we saw in SE16N screenshot above.
Hope this blog helped to clarify some of the doubts related to MSEG/MATDOC tables.

Source: https://blogs.sap.com/2019/05/09/s4-hana-mseg-or-matdoc-where-is-my-data-going/?