What do MTO & MTS REALLY mean?

 There is confusion in the industry as to the definitions of make-to-order (MTO) and make-to-stock (MTS).  I encounter this at many clients.

On a previous project the planner said, “We are a make-to-order shop.  We stock all raw materials and semi-finished goods based on a forecast.  But we wait until the customer’s sales order is entered and then we make the finished good”.

I asked, “Is the finished good stock segregated by sales order in the stock overview”?

Once he told me that the stock was not segregated by sales order, I advised him that he is not running a make-to-order shop.  In fact, he’s running a make-to-stock shop!

This blog post discusses two possible definitions and comes to the conclusion that inventory segmentation is the true determining factor for make-to-order.

Definitions of MTO and MTS from SAP

Even within the SAP websites the definitions are not clear:

Definition 1 from SAP Help

You can decide if production is triggered by sales orders (make-to-order production), or if it is not triggered by sales orders (make-to-stock production).

Definition 2 from SAP Glossary

Make-to-order Production: A type of production in which a product is manufactured for a particular customer.  (My comment:  SAP means *manufactured for a particular sales order/item).

Make-to-stock Inventory: An inventory of goods that were not manufactured for specific sales orders or projects. The stock is anonymous.

Definition 1 says that the difference between MTO and MTS is how production is triggered:  actual sales orders or sales forecast respectively.   Definition 2 suggests the difference is whether the resulting finished goods inventory is segregated by sales order.  In my opinion Definition 2 is correct.  Definition 1 is not definitive because within both MTO and MTS there is a continuum of production triggering before and after the sales order.

Let’s take a closer look…

Definition 1 – Triggering of Production

Depending on the planning strategy set in the finished product (FERT) material master and the settings in the assemblies’ material masters it is possible to stock at different BOM levels based on forecast, prior to the entry of the sales order.   In the graphic below semi finished HALB1 is stocked based on the forecast for the finished product but production of the finished product and HALB 2 and its two assemblies is triggered only after the sales order is entered.

Nothing in this graphic tells us whether this is make-to-order or make-to-stock production!

Stocking at different BOM levels

 

In fact, there is a continuum of stocking levels and procurement triggering for MTO and MTS planning strategies as you can see in the graphic below.

Possible stocking levels for several MTO and MTS Planning Strategies

 

With MTO Strategy 20 there is no sales forecast.  Nothing is stocked prior to receipt of the sales order.  Once the sales order is entered MRP triggers you to procure all BOM levels and place the FERT in sales order segmented inventory.

With MTO Planning without Final Assembly Strategy 50 sales are forecasted.  You can choose to stock some/all ROHs and some/all HALBs prior to the receipt of the sales order. Once the sales order is entered MRP triggers you to procure the remaining ROHs, HALBs and the FERT and place it in sales order segmented inventory.

With MTS Net Requirements Planning Strategy 10 sales are forecasted.  You stock the FERT as anonymous inventory based on forecast.  The sales order has no effect on MRP.

With MTS Planning with Final Assembly Strategy 40 sales are forecasted.  You stock the FERT as anonymous inventory based on forecast.  If there is insufficient FERT stock when the sales order is entered, MRP will trigger you to procure all BOM levels until the extra FERTs are stocked.  So these extra sales orders trigger procurement of all BOM levels.

MTS Planning without Final Assembly Strategy 52 is the close-cousin of MTO Strategy 50. Sales are forecasted.  You can choose to stock some/all ROHs and some/all HALBs prior to the receipt of the sales order. Once the sales order is entered MRP triggers you to procure the remaining ROHs, HALBs and the FERT and place it in anonymous inventory.

Therefore, the SAP Definition 1: You can decide if production is triggered by sales orders (make-to-order production), or if it is not triggered by sales orders (make-to-stock production) is not correct.

Definition 2 – Segmentation of Finished Goods Inventory

Here is the Stock Overview of a MTO finished good material C-1100:

Stock Overview for a MTO material

If you double click on the line “Sales Order Stock” you see that 30 PC of the 77 PC are tied to sales order 242; 17 PC are tied to sales order 509 and so on.  So, the inventory is segmented by sales order.  This segmentation defines make-to-order!

Sales Order Stock 

Now here is the Stock Overview of a MTS finished good material 578:

Stock Overview for a MTS material

Notice that there is no line “Sales Order Stock” under the storage location 0001.

In summary, with MTO production the resulting inventory is tied to a sales order; in MTS the inventory is not tied to a sales order.  Therefore, segmentation of inventory by sales order is the only true determinant for make-to-order.

Note that it is possible for a material to exhibit both MTO and MTS behaviours.  Manufacturers of sanitary appliances (toilets) are MTS but once in a while a customer will request toilets without the manufacturer’s logo stamped on them, which is the normal practice in the industry.  So they switch to MTO for this sales order/item so that the stock is kept separate.

Conclusion

Because there is confusion in the industry as to the definitions of make-to-order and make-to-stock you are well advised to ask several questions and look in your client’s SAP system before deciding what type of production they run.  You don’t want to start off on the wrong foot with your client!

Source: https://blogs.sap.com/2020/09/07/what-do-mto-mts-really-mean/

S/4HANA_System Conversion_ Finance Data Consistency checks

 A best practice for any S/4HANA conversion is to identify the consistency of all financial data prior to conversion into S/4HANA.

There is new functionality (available in late 2020) that facilitates deep consistency checks of all General Ledger data by executing the reports described in this blog post.  A key feature of this new functionality is not only the detection of inconsistencies,  but new functionality has been released that will also correct many of the issues.

 

FIN_CORR_RECONCILE & FIN_CORR_DISPLAY

These pair of reports were released for the S/4HANA 1909 and were created specifically for system transitions using a  System Conversion process (both Classic GL and New GL conversion scenarios are supported).  These reports check and analyze accounting data and verify that all preconditions for the conversion are met.

The FIN_CORR_RECONCILE report deeply analyzes financial data consistency and should be executed in the source ERP system prior to conversion.  Failure to identify these inconsistencies may results in errors when executing the main check reports executed after conversion to S/4HANA (Analyze Transaction Data and the Migration Monitor check routines).

FIN_CORR_RECONCILE focuses primarily on GL data inconsistencies.  Not all possible errors that may occur in the Migration Monitor will be captured by this report, but it is focused more on the possible errors in the migration step R21>Reconciliation of the Transactional Data

To execute the report run transaction code FIN_CORR_RECONCILE

And to display the results run transaction FIN_CORR_DISPLAY

To activate these reports in the ECC system follow

SAP Note 2755360 – Reconciliation prior to S/4HANA Conversion instructions

Tip! Be sure that the following notes are installed to have the latest version of FIN_CORR_RECONCILE:

• 2887318 – Reconciliation, Analysis and Correction of G/L Inconsistencies in ECC prior to S/4HANA Conversion
• 2836444 – Analysis and Correction of G/L Inconsistencies in ECC prior to S/4HANA Conversion- User Interface
• 2793849 – Analysis and Correction of G/L Inconsistencies in ECC prior to S/4HANA Conversion- Application Coding

 FIN_CORR_MONITOR

FIN_CORR_MONITOR analyzes database inconsistencies that were found in FIN_CORR_RECONCILE and allows corrections to be made to the discovered errors.  Details of the correction can be viewed in the FIN_CORR_MONITOR correction logs.

Below is the list of correctable errors and information on the correction strategy used by FIN_CORR_MONITOR to correct them**

Error Message Number	Description	Problem/Root Cause	Assumptions	Correction
FIN_FB_RECON 070, 071	No entry in BSEG/BSEG_ADD for this line item of FAGLFLEXA	One or more lines of document is missing in the Entry view.	Data in document header (BKPF), index and tax tables are considered correct.	Consistency of document status (BSTAT) in the GL view is first checked and corrected. The entry view is created using the data in BKPF, index and tax tables if the zero balance check is successful.
FIN_FB_RECON 220, 221, 223, 224, 225, 226, 227, 228, 229	Values in certain fields of index table and BSEG/BSEG_ADD do not match	There is a mismatch between any of the fields BKPF-BUDAT (posting date), BKPF-BLDAT (document date), BSEG-HKONT (GL account), BSEG-DMBTR (local currency amount), BSEG-ZUONR (assignment number) and the corresponding fields in the index tables.	BSEG/BSEG_ADD entries are considered to be correct. You get a popup during correction to confirm this.	Index fields are updated from BKPF and BSEG/BSEG_ADD accordingly.
FIN_FB_RECON 334, 335, 336, 337, 338	Open item in BSEG/BSEG_ADD, missing in BSI*/FAGLBSIS but available in BSA*/FAGLBSAS	Missing clearing information in BSEG/BSEG_ADD	Clearing information in the index table is considered correct.	The clearing information is updated in BSEG/BSEG_ADD from the secondary index if it is available. However if either one of AUGBL or AUGDT is already filled in BSEG/BSEG_ADD, then the case is excluded as a concrete decision cannot be made on the correct clearing information.
FIN_FB_RECON 339, 340, 341, 342, 343	Missing index table entries	Index table records are missing	Data in document header (BKPF), document (BSEG/BSEG_ADD) and indexes are considered correct.	New index records are created using BKPF, BSEG/BSEG_ADD and indexes.
FIN_FB_RECON 354, 355, 356, 357, 358, 359, 360, 361	Duplicate index table entries	There are duplicate index records created for a particular line item in the index tables.	BSEG/BSEG_ADD entries are considered to be correct.	The dupicate index entries are moved to a dummy client (ZZZ). The index records are created from BSEG/BSEG_ADD accordingly.
FIN_FB_RECON 372, 373, 374, 375, 376, 377, 378, 379	Missing archival flag in index table entry	The field XARCH should be populated with ‘X’ in the secondary index tables when the documents are archived. Due to some issue the field is populated with space.	If the document is not present in the header table (BKPF), BSEG/BSEG_ADD and new GL item table (FAGLFLEXA), it is considered to be archived	The flag XARCH is updated to ‘X’ for the entry in the corresponding index table.
FIN_FB_RECON 391, 392, 393, 394, 395	Shifted BUZEI issue	The incorrect line item numbers (BUZEI) in reversal documents is caused by the issue mentioned in the note 1988463. Other cases of incorrect BUZEI is due to some other issue.	If the document is a reversal document, the issue is with incorrect BUZEI in BSEG (Note 1988463). For all other cases BUZEI in BSEG is considered to be correct	For reversal documents the BUZEI is corrected in the entry view (BSEG) if only BUZEI mismatch is seen between entry view and GL view and all other information (i.e, account and amounts – TSL, HSL, KSL, OSL and GL update currency- RTCUR) is the same. If the document is not a reversal document and only BUZEI mismatch is seen between entry view and GL view lines while all other information (i.e, account and amounts – TSL, HSL, KSL, OSL and GL update currency- RTCUR) is the same, then the BUZEI is corrected in the GL view.
FIN_FB_RECON 577, 578	Open item flag mismatch between account master and document	There is a mismatch in the open item management flag (BSEG/BSEG_ADD-XOPVW) between the account master data and the document. This could be due to subsequent changes done to the account master data.	The master data table(SKB1) of the account is considered to be correct.	The value of field XOPVW is set in the document as per the value in the master data table SKB1.
FIN_FB_RECON 584, 585	Ledger specific clearing field (XLGCLR) in BSEG/BSEG_ADD has a junk character	The field BSEG/BSEG_ADD-XLGCLR or SKB1-XLGCLR in some G/L accounts had received a junk value ( ‘/’ or ‘\’ ) due to multiple bugs in the past. The root causes have been fixed in the latest SPs and through notes.		The value of field XLGCLR is set ‘ ‘ wherever it is equal to ‘/’ or ‘\’.  This correction is done once per company code. It is checked irrespective of any error messages proactively.
FIN_FB_RECON 592, 593, 594, 595	Clearing specific to ledger groups differs between master data and BSEG/BSEG_ADD	There is a mismatch in the ledger specific clearing flag (BSEG/BSEG_ADD-XLGCLR) between the account master data and the document. This could be due to the junk values in SKB1 being corrected or pure account master data change done subsequently.	The master data table(SKB1) of the account is considered to be correct.	The value of field XLGCLR is set in the document as per the value in the master data table SKB1.

** Reference  Note 2956096 – FIN_CORR_MONITOR: Information on correctable errors for more details

To execute the report run transaction code FIN_CORR_MONITOR to display and correct the data.  Please refer to my  future blog post FIN_CORR_MONITOR for more details on this transaction

To activate FIN_CORR_MONITOR , implement in the following order the below notes and follow the instructions in the notes:

2887318 – Reconciliation, Analysis and Correction of G/L Inconsistencies in ECC prior to S/4HANA Conversion

2793849 – Analysis and Correction of G/L Inconsistencies in ECC prior to S/4HANA Conversion- Application Coding

2836444 – Analysis and Correction of G/L Inconsistencies in ECC prior to S/4HANA Conversion- User Interface

Be aware that note 2755360 is a prerequisite before all above notes can be installed

Tips! Be sure that the following notes are also installed to correct some known errors

• 2896016 – FIN_CORR_MONITOR: Additional corrections
• 2937335 – Correction prior to S/4HANA Conversion using tool FIN_CORR_MONITOR: Error message FIN_FB_RECON 334,335,336,337,338 given in reconciliation check FIN_CORR_RECONCILE

RFINDEX_NACC

This report is an analysis tool for SAP support in a pre-converted ERP source system. This report can be used in classic GL and some of the checks are also valid for new GL postings.  The RFINDEX_NACC is not to be used on a post-converted S/4HANA system. RFINDEX_NACC contains a lot of check options which allows SAP Support to identify deep inconsistency issues.

The disadvantage of the RFINDEX_NACC  is that it very often lists inconsistencies which do not have any impact on a System Conversion.  That means that not all errors reported may need to be corrected and could possibly co-exist during the conversion process.  This is the main reason for RFINDEX_NACC is considered as a SAP Support tool.

In some cases, this report can be executed in a System Conversion (more often after your first Sandbox iteration) to resolve issues for specific documents.  Be aware that running the report in update mode can lead to new inconsistencies if it is run in the wrong way, and only experienced SAP resources should use the update mode.

Tips! Only use RFINDEX_NACC – FI Consistency Check with the option, Indexes vs. Documents. All other checks of this program are not relevant for a System Conversion

In summary,  the accounting data needs to be identified, analyzed and corrected in ECC system to fulfill the pre-conditions for a System Conversion to S/4HANA.  In this blog post you can learn about the reports that will help with those activities and guide you during the process.

Hopefully this is helpful, please add in the comment section any other topics you think are valuable to have included in this blog post.

– Brought to you by the S/4HANA RIG –

Source: https://blogs.sap.com/2020/09/02/s-4hana_system-conversion_-finance-data-consistency-checks/

How to analyze S/4HANA tables with proxy objects

 Since we, the BI folks need to deal with ERP quite a bit, it is also sometimes handy to understand how things are structured “out there”. So, this writing is about proxy-objects / replacement views and associated topics. I will do it based on two examples that came from real-life questions so we can generalize afterwards.

First and foremost, we are dealing with a “new” ERP now, which is called S/4HANA. You may ask me now why is this important? Well, because that has changed things for us (BW folks) under the hood. To illustrate it I have made a GIF out of a slide that has been ever presented on a TechEd, wherein it is visible per area which of the tables lost their original importance and have been at least partially replaced by something.

(slide source 2018 SAP TechEd presentation CNA244)

Table disappeared completely

This never really happens (to be absolutely precise that was the case in one of the ancient versions of S/4, but now they’re back). While strictly speaking tables have not disappeared, they may have been replaced by the view. An example of such a table is GLT0 (G/L account master record transaction figures). If I recall it correctly, it was a monthly summary table, filled from BSEG/BKPF on regular basis. If we look in the system, indeed in SE11 it will show that it is not a table anymore but a view

While it is tempting to go and see what this view is about, we can try having a look, but not in SE11. Unfortunately, this is not a regular dictionary view that you can look at like this in SE11, it is an ABAP CDS view, actually, and all the new features, including ABAP CDS views are available in ABAP Development Tools in Eclipse, so you need to get them for yourself and add an ABAP project there.

When you’ve done so, you can search for things using the magic button

and typing what are you searching for there

While this code may be enjoyable for some, it could be less enjoyable for others, therefore I recommend you having a graphical overview of major building blocks in this view by right-clicking and choosing Open With → Dependency Analyzer

What we see then is that our view GLT0 is a result of a serious sandwich of other views (8 layers of them) and that it actually gets its data directly from ACDOCA.

So, we can summarize here a few thoughts:

• There are a bunch of tables that are gone
• They’re not gone completely, because otherwise the system would’ve been ruined, so they are replaced by views
• In our particular example a hugely summarized table has been replaced by a view on Universal Journal, or simply put a line-item data
• All of this is beautiful because the summary tables like this do not need to be filled and serviced anymore
• On the other hand we understand that line-items is some heavy stuff, so we hope it runs very very smooth

Table almost disappeared

Let us have another example of a table behaving in a certain interesting way, this is a COEP table that has CO object line items inside.

Contrary to the first example, this one is not a view (says Transparent Table up there), but I have some suspicions… So, if I check it in Extras → Proxy Object… I will see something being filled there

Analyzing the view V_COEP_VIEW is done in exact same fashion as we have already done with GLT0, so again, I know I am dealing with ACDOCA data with some additional modeling on top of it (9 layers of CDS views on top of a line-item table with quite significant “something”).

Coming to an intermediate stop in here let us realize what we have:

• a transparent table COEP that holds no data anymore
• a CDS view V_COEP_VIEW which does provide the data

I can already sense you asking “how does that all work together?”. It works the following way: any SELECT operation on COEP will go to the view (Program / FM / Views / BW DataSource, etc.), so, that the data will be as fresh as it gets  any INSERT / UPDATE / DELETE operation will still run on an original table (because you can’t, obviously manipulate data in a view). This is done by SAP for easier transition of those cases where a customer may have some custom code working on those tables with proxy objects.

Table disappeared partially

Now, this may sound confusing but please, stay with me. There are some tables that (contrary to our last example with COEP) still do hold some data, but just not everything they originally did. Let us take an example of MARC, which is Plant-dependent Material Master. Using the same ideas we can see a proxy object NSDM_E_MARC

which, interestingly enough, is based on a table MARC!

– WHAT???

– Calm down and read on

To my humble understanding, most of the fields of MARC are still stored where they used to, it is just some part of them that is no longer being stored in a table MARC itself, but are rather calculated on the fly. Since we are here for learning the basic principles, I will just tell you that some Quantity fields are no longer needed to be stored in MARC, so they do get calculated every time we call for them. And judging on the screenshot above they are calculated based on MATDOC_EXTRACT table, which hints at relatively up-to-date information.

Wrap up

If you would please remember a few things after reading this, I would like them to be:

• Some tables have changed
• Use “Proxy Object” of a table to find the view. If for some reason you need all of tables with proxy objects, find it in DD02L with setting the filter VIEWREF<>”
• Try reading the ABAP CDS, but if you’re not into it, use dependency analyzer for higher-level view
• If you need to dig into field-level detail, try doing so, it’s not that scary

Source: https://blogs.sap.com/2020/08/25/how-to-analyze-s-4hana-tables-with-proxy-objects/

Extending Customer Master App: In-App Extensibility

 With S/4HANA, comes another hot topic that we have been hearing a lot about …yes, you guessed it right… Extensibility i.e. how we are going to enhance or customize the standard processes or applications according to our business needs.

In this blog, I am going share step by step process on how we can enhance the standard Customer Master app using In-App Extensibility.

Let’s say we have a requirement to add a custom field into the customer master. So, first thing that comes into mind is how we are going to achieve it in S/4HANA… In ECC , we would have enhanced the standard table by including the custom field or looked for the screen exit to add field to the screen and must have written the field update logic in user exit… but what should be the approach in case of S/4HANA…

And the answer is, if we are working in S/4HANA On-premise version, we still have all the above options available but the recommendation is to use In-App Extensibility ; which can fulfill your requirement and in case of S/4HANA Cloud, In-App extension is the only option…yes, the only option.

In my case, I am working in On-premise version. But, nothing to worry even if you are working in Cloud, as the In-app Extensibility works the same way in both cases.

Moving forward, let’s say we have to add custom field “Sales Zone” to the customer master general information section and we should be able to Add/change/display value in the field from our standard Customer Master App.

Below is the step by step approach.

• GoTo the Fiori Launchpad and open the Customer Master App as shown below.

• Initial screen will look like this. Next step is to check if we have the access to adapt/enhance the screen. To do so, click on the User Icon as shown below.

• Check if you can see the Adapt UI option. In case you don’t see it, that means you are missing the required access.

• To be able to extend the application you need to get the “SAP_UI_FLEX_KEY_USER” role to your user ID.

• Once role is added, check the user details again to see if you are able to see the “Adapt UI” option.

• Now, go back to the customer master app and click on Go. You should see the customer details.

• Select any customer and click to display the details.

• Customer details will be displayed as shown in screen shot below. So this is the screen where we want to add a custom field under Basic Data tab in General information. Click on User icon and select Adapt UI option.

• Once we select the “Adapt UI” option we will see that we are in UI adaption mode. Right click on the screen we want to add custom field and click on Create group.

• A group will be created with the name “New Group”. Right click on the group and click on rename to give any name as per your choice. I am giving the name “Customer Fields”.

• Now let’s add the custom field to this group. Right click again and click on “Add field”

• In the popup screen , you will see all the fields available as a part of the standard datasource. If we want to add any of this available fields we can just select and it will be added to the screen. But, yes…you are right … we have the need to add custom field. So, to do so, click on “+” (create custom field, association or logic) icon on the pop up screen “

• The click on “+” icon will navigate you to the “Custom fields and Logic” app’s initial screen. The good part is that it will automatically select Business Context applicable for the screen where we want to add the custom field…Yes, you read it right… No, more confusion on which Business context to select.

• Click on “+” (Create) icon to create a custom field

• The pop up screen will have Business context pre-populated and we just need to fill rest of the details like Label which is “Sales Zone” in this case, data type, length. After filling the details, click on “create and publish” button.

• The screen will show your custom field details with status as “Publishing”. It will take some time to change the status to published. Basically, it automatically adds the custom field to the standard table which customer master table in this case.

• Ones Publish, we can go to back-end and see that the field is automatically created in the Business Partner General data table (BUT000) in this case as show blow.

• To see which all tables this field has been automatically included, just do the where used list on the data element of the field.

• Let’s get back to the task. So, now we have created the custom field “Sales Zone” and published it. Now, we need to add it to the screen where we started from. Right click on the custom group “customer fields” that we created and click on add field. This time you should see the custom field “Sales Zone” in the list of available fields. Select the field and click ok.

• So, we have now successfully added the custom field “Sales Zone” under the “Custom fields” group that we created as shown in screen shot below.

• Click on “Save & Exit” and get out of the UI adaption mode.

• We are out of the UI adaption screen now and we can see our custom field on standard screen. Let’s say we now want to update data in this field now. Just click on the “Edit” button and the we will see the editable screen with option to put data in our custom field.

• Enter the data in the field, “Test Zone” in this case and click on save. You will get a message “Master data record saved” on successful update in database.

• We can see the updated data in the customer details screen.

• We can check in the back-end table BUT000 also for customer “100000” which we just updated. And as shown below, we have the data in the standard table as well.

• What about when we create the new customer? Let’s see that also. Go to the initial screen of the app and click on create and Select either of person or organization.

• On the Input pop up screen, provide the customer name (mandatory field), in this case, “Extensibility test customer” and any other option inputs if you want and click ok.

• In the next screen, we can see the custom field “Sales Zone”  is available even in create customer scenario. We can enter all the required data along with sales zone and can create the customer.

• And we have successfully created the new customer “1000020”

So, does that mean we can enhance any app or any screen using this approach and the answer to this is NO .

Then how do we know which screen can be extended?? Very well, when we click on “Add Field” under the UI adaption screen, the “+”  to add custom field would be grayed out as is shown in below screen shot when we try to add custom field in the address details screen.

With this we have successfully extended the Standard Customer Master App using In-App Extensibility approach.

 

Thanks

Vijay

Source: https://blogs.sap.com/2019/03/20/extending-customer-master-app-in-app-extensibility/