Cost Center, Profit Center & FSV Tables in S/4

Writing this blog based on my personal struggle to find out tables and how they store Cost Center, Profit Center and FSV data in S/4 HANA. This is especially more relevant for the sidecar scenario where data is replicated from S/4 HANA to HANA Enterprise for reporting purpose & we need to re-create Cost Center, Profit Center and FSV hierarchies in HANA Enterprise just like how they exist in S/4 HANA.
FSV is covered in a separate blog, you can check it here.
Let’s start with Cost Center and Profit Center hierarchies, main tables involved are SETHEADERT (stores text descriptions of nodes),  SETNODE (stores hierarchy nodes), SETLEAF (stores actual Cost Center/Profit Center numbers)
Both Cost Center and Profit Center hierarchies’ data are maintained in the same database tables, for explanation purpose I am using Cost Center however you can also retrieve Profit Center hierarchy using the same tables and steps.
As a first step, you may like to see the standard Cost Center Hierarchy in ECC or S/4 system, use tcode: OKEON/OKEN to check Cost Center hierarchy and to check Profit Center hierarchy use tcode KCH4.
Cost Center Hierarchy screenshot:

Steps to retrieve Cost Center/Profit Center hierarchies from database tables:
1. First, let’s try to get the header/main node of the CC hierarchy (Root Node), marked in green in below screenshot:

Table: SETHEADERT

• In ‘Set Class’ pass 0101, please note for Cost Center Set Class is always 0101 and for Profit Center, it is 0106
• In ‘Org.Unit’ enter your organization unit/controlling area, in my case, it is 2000
• In ‘Set Name’ enter value that you see at the top of CC hierarchy in the above screenshot, it is 2000 (marked in orange)

The output of this table will give you CC Header and its description:

2. Now let’s get node under header 2000 (Level 1), marked in Green in below screenshot

Table: SETNODE

• In Set Class pass 0101 for Cost Center Set Class is always 0101
• In Org.Unit enter your organization unit, in my case, it is 2000
• In Set Name enter 2000, it may be different in your case

Output field Subset ID of this table will give you items under the header node:

3.Now to get nodes under USABB or CANADA or FMOPS again use SETNODE table and pass these as Set Name (Level 2):

For node under USABB

For node under CANADA

For node under FMOPS

Output for USABB:

Now to get nodes under FMCORP or SC or PI or MRO, again use SETNODE table and pass these as Set Name (Level 3), marked in Green in below screenshot:

Table: SETNODE

• In Set Class pass 0101 for Cost Center Set Class is always 0101
• In Org.Unit enter your organization unit, in my case, it is 2000
• In Set Name enter FMCORP OR PI OR SC OR MRO

Output for FMCORP:

Repeat this process until you reach to the last node or leaf node, in below example Canada does not have any node underneath it, it has a Cost Center assigned to it but no child node hence Canada is a leaf node and when you reach to the leaf node you will not find any entry in SETNODE table :

SETNODE output for Canada:

Finally, to get Cost Center numbers under leaf node (in this example, Canada) you need to use table SETLEAF:



Hopefully this blog will help you in recreating CC, PC hierarchies in your BI platform.


Source: https://blogs.sap.com/2019/06/29/cost-center-profit-center-fsv-tables-in-s4/

S/4HANA Stock Room Management

What is SAP S/4HANA stock room management? (June 2019)
Stock room management is a specific offering for installed base customers to continue running their light warehouse management implementation in the context of SAP S/4HANA beyond 2025. License is included in S/4HANA Enterprise Management component.
The main reason for creating the offering named Stock Room Management is to give existing customers of LE-WM an opportunity to keep these warehouses untouched that do not benefit immediately from moving to embedded EWM.
Stock room management is basically the ECC warehouse management component (LE-WM) without capabilities supporting more complex warehouses. Relevant for small warehouses with manual operations (i.e. storage bin management).
Functionalities of LE-WM that are not part of stock room management are:

• Task & Resource Management (WM-TRM)
• Warehouse Control Unit interface (WM-LSR)
• Value Added Service (WM-VAS)
• Yard Management (WM-YM)
• Cross-Docking (WM-CD)
• Wave Management (WM-TFM-CP)
• Decentral WM (WM-DWM)

There are no innovations planned here and EWM remains the strategic product. Components that are part of the compatibility scope (not stock room management!) must not be used anymore beyond 2025!
2269324 – Compatibility Scope Matrix for SAP S/4HANA on-premise
Best Practices for S/4HANA EWM can be found in this SAP Note:
1606493 – SAP EWM Deployment Options Best Practices
Hint: different storage locations of the same plant can have different warehouse scenarios, this is how you easily can move to EWM step-by-step in a later project, for instance.
Historical background
As many of us already know in S/4HANA LE-WM ist not supported beyond 2025 and the recommendation was to migrate to EWM. Unfortunately there are no migration tools that can do the job. Hence this ended up in some projects in a lot of effort to introduce EWM (with all its potential features) for customers that only needed the “minimal” functionality.
Details could be read in the SAP Note (maybe an update is following soon):
2577428 – Road map for LE-WM in SAP S/4HANA
When? First shipment is planned in SAP S/4HANA 1909.

Best Regards
Marco


Source: https://blogs.sap.com/2019/06/27/s4hana-stock-room-management/

SAP ERP to S/4 HANA

In my last post, we discussed some of the technical features of S/4 HANA. You can read the post with the link below:
https://blogs.sap.com/2018/02/12/system-conversion-to-s4-hana/
In this post, we will discuss about the innovations from SAP ERP to S/4 HANA around Enterprise Management.
To start with, I would recommend to go through the simplification list. The simplification list covers all the simplifications made across different areas and the actions to be taken for transitioning from SAP ERP to S/4 HANA. You can get a copy with the below link.
https://help.sap.com/doc/4698ca4ad85a4a24994b2016f366cc77/1709%20000/en-US/SIMPL_OP1709.pdf
Core processes in SAP ERP have largely remained unchanged but certain innovations have been made within the core processes to support the new age requirements to support companies with digital transformation, IoT, etc.
You can read the post by Sven Denecken to know in which processes innovations have been made. The link to the blog is below:
https://blogs.sap.com/2015/11/18/s4hana-1511-product-scope-guide/
The below posts by Rudolf Hois will give an insight into Innovations made in 1610 and 1709 versions.
https://blogs.sap.com/2017/02/22/sap-s4hana-on-premise-edition-1610-feature-pack-stack-1-fps01/
https://blogs.sap.com/2017/09/15/introducing-sap-s4hana-1709/
Innovations have been made in S/4 HANA across different processes. Some of them are as below:
Sales Orders Management becomes much easier with apps available for exception handling in fulfilling the orders. The principle is to have the process automated seamlessly while the customer service teams focus only on the exceptions.
ATP is part of the core as it is used as a function in both Order to Cash and also Plan to Produce. With this, the availability check function remains the same in both the processes and much faster, is carried out for all items simultaneously and in real time. With the ‘Release for Delivery’ app, it is easier to prioritizing sales orders and changing confirmations. Below link

Inventory Management has real time stock visibility and with processes like backflush, there is no need to process the stock postings with batch jobs but rather in real time which eliminates discrepancies in stock reporting. This also means accurate inventory valuation.
MRP is live, which means much faster and multiple MRP runs are possible with S/4 HANA allowing for smaller lot size planning allowing to respond to demand much faster. There can be real time alerts possible to prioritize critical exceptions.
In Purchasing, the source assignment has been simplified, real time purchasing and inventory information so as to allow faster and accurate decision making.
All these changes are an outcome of the simplified data model which could be made possible with HANA. This results in eliminating redundancies and reduction in data footprint, translates into ‘Principle of One’, eliminating unnecessary locks on the tables making the application faster and an accurate output.
The S/4 HANA Cookbook has lots of useful details about S/4 HANA. You can read more with the link below:
https://wiki.scn.sap.com/wiki/display/ATopics/SAP+S4HANA+Cookbook+-+What+is+SAP+S4HANA
The below post by Gregory COJA has useful resources which can help further.
https://blogs.sap.com/2016/09/07/useful-sap-s4hana-documents-on-scn/


Souce: https://blogs.sap.com/2018/02/27/sap-erp-to-s4-hana/

SAP ERP to S/4 HANA Migration Scenarios

# Purpose of this Article
There have been multiple scenarios while it comes to SAP (ECC) ERP migration to SAP S/4 HANA. It is important to understand customers current landscape and used functionalities and modules in current SAP landscape/system to determine the appropriate S/4 HANA migration scenario.
Determination of migration scenario is so important that based on this understanding only scope, team size and project valuation (bidding value) can be determined. For example, there could be multiple phases (sub projects) in one simple e.g. ECC6, EhP7 migration to S/4 HANA 1709.
Identification of appropriate migration scenario would help you finalizing following things:

1. Magnitude of Work (Scope)
2. Number of Project Phases
3. Team Size Requirement
4. Project Amount (Bid Amount)

Mainly this article is for sales team involved in approaching customers for SAP migration. I hope it helps them.
Note: This article is mainly for SAP consultants/management who are market goers (Sales Team). Please get your basics strong before committing anything about S/4 HANA Migration.
In this article we would be focussing on Scenario 6 and Scenario 7. Other Scenarios will be covered in future articles.
Note: This document is prepared considering that first, the migration will take place from ECC environment and required additional functionality would be activated in the migrated S/4 HANA 1709 environment. With this your customer would be in your hand.
 
# SAP S/4 HANA Migration Scenarios

Note: A new scenario has been evolved in S/4 HANA 1709 for customers who are already in SAP ERP with HANA1 (Suite on HANA) or S/4 HANA with HANA1 (S/4 HANA Finance 1503, 1605 and S/4 HANA 1511, 1610) and want migrate to S/4 HANA 1709 (which is on HANA2). Migration has to be done in two phases:
Phase1: SAP ERP o HANA (Suite on HANA) to SAP ERP HANA2 (Suite on HANA2)
Phase2: S/4 HANA with HANA1 (S/4 HANA Finance 1503, 1605 and S/4 HANA 1511, 1610) to S/4 HANA 1709 (1709 is on HANA2)

# S/4 HANA Migration Concepts (Doc. Splitting and Parallel Ledger/Accounting/HANA2)
Following points help you determining migration scenario in respect to scenario 6 and scenario 7:

1. There is no concept of ‘New GL or ‘Classic GL’ in S/4 HANA
2. New GL is not a pre-perquisite for migrating to S/4 HANA, you can migrate to S/4 HANA from classic GL
3. Migration from Classic GL to S/4 HANA 1610 (1503, 1511, 1605 and 1610) was possible, but subsequently document splitting was not possible and due to this SAP recommendation was to activate first New GL (Ledger introduction and document splitting) and then migrate to S/4 HANA
4. Migration from Classic GL (without activating to New GL) to S/4 HANA 1709 is possible, additionally, now subsequent document splitting and ledger introduction is possible in S/4 HANA 1709. This is the reason, now there is no need of doing a project for New GL activation in ECC environment.
5. Need to keep in mind that there might be possible three separate projects for converting ECC on classic GL to S/4 HANA with document splitting and parallel accounting (additional ledgers).
6. Subsequent Ledger (Parallel Accounting) introduction was possible from SAP S/4 HANA Finance SAP 1605 and S/4 HANA 1610.
7. A new scenario has been evolved in S/4 HANA 1709 for customers who are already in SAP ERP with HANA1 (Suite on HANA) or S/4 HANA with HANA1 (S/4 HANA Finance 1503, 1605 and S/4 HANA 1511, 1610) and want migrate to S/4 HANA 1709 (which is on HANA2). Migration has to be done in two phases:

# Project Phases for Migrating SAP ECC System to S/4 HANA 1709
Considering there is one SAP ECC customer with classic GLs and he wants to move to S/4 HANA 1709. He also wants have functionality such as document splitting and parallel accounting (additional ledgers).

Phase 1: ECC Migration to S/4 HANA
a. Preparatory Phase

• System Requirement (Unicode Conversion)
• Maintenance Planner
• Pre-Checks
• Custom Code Pre-Parathion

b. Technical Migration (SUM)

• Database Migration
• Software Upgrade
• Data Conversion

c. Delta Customization
d. Data (Functional) Migration (Migration Cockpit)
e. Testing
f. Go-Live

Phase2: Activation of Parallel Ledger (Non-Leading Ledger Introduction)
SAP has two approaches to meet multi GAAP reporting requirements i.e. the account approach and the ledger approach

1. Preparatory Phase
2. Execution Phase
3. Post – Processing Phase

Phase3: Activation of Document Splitting

1. Preparatory Phase
2. Execution Phase
3. Post – Processing Phase

(Further detailing can be obtained from this blog https://blogs.sap.com/2017/12/11/subsequent-document-splitting-in-s4-hana-finance-1709-on-premise/#)
Note: No SLO service is required for activating document splitting subsequently. Standard document splitting activation cockpit is available in IMG node in S/4 HANA 1709.

# Major/Select Changes in S/4 HANA 1709
If you are going to customer for sales pitch before that please get the understanding of ‘what is new in S/4 HANA 1709’.

• New HANA Data Base i.e. HANA 2 DB
• Machine Learning capabilities on S/4 HANA 1709 On-Premise
• Expanding Core with Embedded
• Innovation on Core: Demand Driven Replacement, Advanced Variant Configuration, Real Time Inventory Management (e.g. Oil & Gas)
• New S/4 HANA Migration Cockpit
• New addition to SAP Fiori Lot

 Source: https://blogs.sap.com/2018/01/31/sap-erp-migration-to-s4-hana-scenarios-sales-proposition-bidding/

SAP S/4 HANA- Customer planning for implementation scenario

Why SAP S/4 HANA :

By 2020, 5 billion people will enter the middle class and come online, while 50 billion devices will be connected to the Internet of Things, creating a digital network of virtually everything
Data is the new Oil and for enterprise application will have to process huge amount of data in real time, requires business to consume the next generation of Business Suite. R3  is not capable to do such colossal task. Hence moving to SAP S/4 HANA is the real need of business application.

Short quick facts one should consider based on timeline, complexity, system requirements.

S4 HANA Suitable Scenario:

There are more than one way to move your business to SAP S/4 HANA . System conversion or new implementation are usually the most know scenario. Landscape transformation is another way to run business on S/4 HANA. Will try to explain which scenario is best suited for your business.

As per system requirement:

Release type:
If a Business Suite System is on an older release, you have to execute several steps to move to SAP S/4HANA.
You first have to move to SAP ERP 6.0 EHP7 / SAP HANA, adapt to this release, and then move to SAP S/4HANA. In this case, a New Implementation might have advantages because this in-between step is not required.
Can you move to SAP S/4 HANA On Premise edition in one step procedure
System conversion looks better option in this case.
Business Add-on and function Pre-check: If you have identified un-supported add-ons and business function and they are still not available on the roadmap- Such case will postpone S/4 Project to certain point of time and usually independent from transition scenario.

As Per Business Process:

Business process fits to current and future requirement: Performing system conversion is better option. Based on the simplification list approach, the conversion project is guided where things are different in SAP S/4HANA
Business process does not fit to current and require redesign: Complete re-design require performing new implementation. New process based on Best practice content and migrate your application data to new process.

As per custom Code: Custom code need to be identified while planning to migrate to S/4 HANA.
Want to take over custom code: If you business needs to take over existing custom code , then system conversion might have advantages. Using Custom code migration worklist, customer is guided to compile custom code to data structures and scope of S/4 HANA
Want to replace custom code: If S/4 HANA already contains replacement of your custom code as standard S/4 HANA functionality, then you can choose any transition scenario.

As per Timeline:

How fast you want to move to S/4 HANA: If your customer is global and wants all business residing in different countries to be migrated to S/4 HANA, system conversion would be better choice as complete re-design is going to take longer time.
Risk Mitigation: If customer wants to mitigate risk and move only one application to SAP S/4 HANA, then landscape scenario is not the one should be considered. Landscape transformation will be better given choice. Landscape transformation allows you to move your application phase wise like SAP S/4 HANA central finance, SAP S/4 HANA cloud version or SAP S/4 HANA core.




Source: https://blogs.sap.com/2018/03/05/s4-hana-how-does-the-customer-plan-to-implement-s4-hana./

S/4 HANA Implementation

SAP S/4 HANA have Choice of deployment as below:

• On-premise – On Premise We can configure using SPRO( as earlier) , and in future SAP will provide  S/4 HANA Guided Configuration.
• On Cloud ( Cloud Provide S/4 HANA Guided Configuration to implement S/4 HANA )-

        

1.                   An assisted way to adapt best practices to customer needs .
2.                   Facilitates the life-cycle management of business process content.

• Hybrid – This type of implementation contain  both on-premise and on-cloud.

3 Situation which describe in more detail for choice of deployment as below –



S/4 HANA can be implementation project are two types-
1. Greenfield Implementation ( New Implementation) – Starting Point A in above picture , best suited for this type of implementation.






2. Brownfield Implementation (Migration)- Starting Point B and C in above picture, is more suitable for this type of implementation.



Starting Point B :


Starting Point C :



Thanks.


Source: https://blogs.sap.com/2016/07/08/s4-hana-implementation/

S/4 HANA On-Premise Vs S/4 HANA Cloud

 

                                            

          

In this blog, I will focus on the difference between S/4HANA Cloud and On-premise.

SAP S/4 HANA On-Premise Edition

SAP S/4HANA on-premises is the ERP business suite based on the SAP HANA in-memory database. With on premises, the customer manages everything, including the HANA database, applications, data centers, OS, middleware, servers, virtualization and networking.

SAP S/4 HANA Cloud Edition

SAP S/4HANA Cloud is the SaaS version of S/4HANA. SaaS deployment means that users can take advantage of much of on-premises S/4HANA’s functionality without needing the hardware, databases or IT staff required for the on-premises version.
In S/4HANA Cloud, SAP provides and manages almost everything for customer.

S/4HANA On-premise Vs S/4HANA Cloud

Let’s compare S/4HANA Cloud and on-premise version on common customer concerns.

Licensing Model

Cloud: Subscription licensing
On Premise: Traditional licensing

Infrastructures and maintenance

Cloud: SAP provides the system and is responsible for the system maintenance 
On Premise: The customer is in control of deployment and maintenance with dedicated own IT staff

Customization

Cloud: Although able to be customized to some extent, there is far less flexibility compared to on premises.
On Premise: There is far more flexibility with and control of customization since the company manages all customization in-house.

Implementation

Cloud: The implementation is faster than S/4HANA on premises since the cloud version uses a ready-made platform that has already been provisioned, implemented and tested by the cloud provider.
On Premise: Implementation takes time, cost, effort and the right personnel to set up a new environment. There may also be a need to purchase additional hardware or software to implement new features.

Integrations

Cloud: Integration among various corporate systems can be complex and involves greater security risks due to data being sent over the internet.
On Premise: Data transfer among systems is faster, and integration over the internet is relatively simpler.

Upgrades and support packages

Cloud: There is less control over an upgrade schedule compared to on premises. However, the cloud provider can inform the customer in advance about the impending upgrades, and the customer can choose the timing and functionality of the upgrade.
On Premise: The company decides the frequency and schedule of software upgrades or whether to implement the latest support packages. This option is time-consuming and expensive, and involves technical or functional resources.

Scalability

Cloud: Scaling up or down is easier, faster and cheaper to meet the changing needs of the company.
On Premise: This approach needs long-term planning and commitment for resources required for scaling.

How do I know Which SAP S/4HANA Is Right for My Business?

The SAP S/4HANA, on-premise edition is the best fit for enterprises in any industry that need the full spectrum of functionality combined with a high degree of flexibility in customization.

Typically, these will be larger enterprises with very well-established processes that they are not interested in changing.

The SAP S/4HANA, cloud edition is the best fit for companies that need a highly agile offering that covers their core business scenarios, yet offers more flexibility and a faster innovation cycle (quarterly as opposed to yearly). It’s perfect for businesses that are changing or growing rapidly and want a platform that can grow and change with them.

Have any doubt or question? Please post that in comment.


Source: https://blogs.sap.com/2018/11/10/s4-hana-on-premise-vs-s4-hana-cloud/

SAP S/4HANA System Conversion Overview

With more than over 1500 live customers on SAP S/4HANA since January 2018, the path to SAP S/4HANA via a System Conversion is a popular transition path for existing ERP customers. With a System Conversion approach, you can conduct a technical conversion project and adapt mandatory simplification/FI migration with subsequent projects to adapt new business process innovations at your own pace. Another approach for customers is to conduct a system conversion and additional/full business process transformation scope together to SAP S/4HANA. No matter what approach you decide, Fiori UX implementation should be considered and implemented alongside of the system conversion project to obtain the value of in memory computing, the digital core, and running a live business with SAP S/4HANA.

In our SAP S/4HANA Regional Implementation group, we have supported many System Conversion projects since the SAP S/4HANA 1511, 1610, and now 1709 releases. In this blog, a presentation was created to introduce you to: the SAP Readiness Check for SAP S/4HANA, System Conversion process, an example of a mock cutover for a system conversion, and an overview of a conversion project within a 4-tier system landscape.  The major point of the conversion process is practice makes a perfect conversion. Plan as many production test cycles as your project time line allows, ensure you test the production cutover like how it will be executed (e.g. Uptime Phase: implementation of precheck in production weeks in advance and business operation with precheck implemented and Downtime Phase: optimization of SUM activities and FIN migration), and freeze the software stack (e.g. SUM, HANA and S/4HANA) if possible after the development system conversion.
Link to document: SAP S/4HANA System Conversion Overview
Thanks,
SAP S/4HANA RIG


Source: https://blogs.sap.com/2018/01/18/sap-s4hana-system-conversion-overview/

S/4HANA Conversion

This blog post will give quick overview for S/4HANA conversion.

Overview

You have an existing ERP system, and you want to leverage your previous investment in the business processes that you already have implemented in ERP. You want to bring them to the new world of SAP S/4HANA. Then S/4HANA system conversion is perfect option for you…!!!
Overall journey for conversion to S/4HANA looks like as below –

(reference from SAP-Press book “ADM328 SAP S/4HANA Conversion and SAP System Upgrade)
S/4HANA conversion journey divides into pre-conversion, conversion and post-conversion phases.
In short, we should be aligned with these phases throughout S/4HANA journey. In pre-conversion phase, we are performing all pre-steps which are required to start conversion. This will help us to find any issue in early phase of project. In conversion, we are converting system to new world of SAP S/4HANA. This phase includes adaptation to new business process, validation etc… And final phase is post-conversion, here we are performing follow-up activities to make sure we get maximum use of SAP S/4HANA for our business.

Pre-Conversion

These checks will help to find out what mandatory steps we must carry out before converting S/4HANA system. The checks are divided into category such as –

• System Requirement
• Maintenance Planner
• SI-Check
• Custom-code analysis

System Requirement

We need to evaluate system and check out its compatibility regarding OS, DB and Stack (Single/Dual) etc.

• Unicode is needed, due to technical restriction with S/4 kernel. If legacy system is not Unicode, then at first place perform Unicode conversion
• Dual stacks are not supported on SAP HANA. So, perform dual-stack split, if required
• ECC system should be >= 6.0.
• Check minimum required version of DB/OS for conversion into S/4HANA

(reference from SAP-Press book “S4H100 SAP S/4HANA Implementation Scenarios)

Maintenance Planner

The Maintenance Planner checks the system with regards to business functions, industry solutions, and add-ons. If there is no valid path for the conversion (for example, the add-on is not released yet), the Maintenance Planner prevents the conversion.

Business function

Business function can have following status: always_on, customer_switchable and always_off.

• If a business function was switched on the start release system, but defined as always_off in the the SAP SAP S/4HANA target release, then a system conversion is not possible with this release
• If business function was switched off in the start release system, but defined as always_on in the SAP S/4HANA target release, then the business function will be activated during the conversion
• If business function is defined as customer_switchable in the SAP S/4HANA target release, it can be activated depending on the needs of the customer, Business functions that were active in source release, remains active in target release.

(reference from SAP Note – 2240360, 2240359)

Add-ons

All add-ons must be certified for S/4HANA in order to run on S/4HANA. If you are converting from ECC to S/4HANA and have add-ons that are not certified, the conversion tool will simply stop in its tracks when Maintenance Planner identifies the uncertified add-on.

(reference from SAP Note – 2214409)

SI-Check

SI-CHECKS will identify simplification items relevant to conversion. It means that it checks data inconsistency or missing mandatory preparation activities.

Tip - Do run this report early in the project.

Procedure

For performing SI-CHECKS, follow below steps

• Start report /SDF/RC_START_CHECKS in transaction SA38
• In the section Simplification Item Check Options, choose the target SAP S/4HANA version
• Choose the mode in which you want to run checks
  • In Online Mode – The results are displayed immediately after the check is finished
  • Background job: If the check will need a long running time, use background mode
• Run the checks to get an overview over all irrelevant simplification items and then check system consistency with Check Consistency for All
• Check the Results and take appropriate action based on logs.

SI-Check message and their meanings

(reference from SAP Note – 2399707)
In order to successfully use the Simplification Item Check as preparation for system conversion/upgrade project

• Start running the Simplification Item Check and fixing the issues found by the checks as early as possible in project
• Stay up-to-date with the latest check and check content versions early in project. But don’t miss to freeze the check notes and check content versions after converting your DEV system
• Archive any data which you don’t strictly need in your SAP S/4HANA system in order to minimize the check runtime and the data cleanup effort.

Custom – Code Analysis

The Custom Code Migration process describes the tools and necessary activities that help you to migrate custom code. The process consists of preparatory analysis (Custom Code Analysis) and the adaptation of the custom code (Custom Code Adaptation) after the technical conversion.
Custom Code Process –

(reference from SAP-Press book “ADM328 SAP S/4HANA Conversion and SAP System Upgrade)

Custom Code Evaluation

ECC system contains a large amount of custom development objects (Z-Objects, enhancements and modifications) that are not used productively. Therefore, monitor system for longer period and do some housekeeping and eliminated the code, which is not used anymore within your productive business applications.
For this purpose, use either UPL (usage procedure log) or ABAP Call Monitor (SCMON) in productive system to find out, which custom ABAP objects are really used within running business processes.
Tool – Solution Manager 7.2

SAP HANA Checks and SAP S/4HANA Checks

This is most important step for custom ABAP code on the way to system conversion to SAP S/4HANA.

• Native SQL of the predecessor database and these database vendor specific dependencies must be eliminated
• Also, in some custom code implementation the SELECT statement without ORDER BY is used. This can lead to unexpected behavior when database is changed (eg. SAP HANA) because the results return in a different order without ORDER BY. Therefore, you need to check your SQL SELECTs without ORDER BY statement if they are still correct
• Pool/cluster tables were removed with SAP HANA, therefore the database operations on these table need to be removed from custom ABAP code

Tools – ABAP Test Cockpit (ATC)

Hana Sizing

Right size SAP HANA hardware to realize the maximum benefit from investment and reduce long-term total cost of ownership. SAP sizing report will provide estimated amount RAM, disk size etc.
The following workflow will help to size HANA hardware.

Conversion

The actual conversion is started with SUM tool. Sum tool performs execution part including Database migration (DMO) and SAP S/4HANA conversion.


(reference from SAP-Press book “ADM328 SAP S/4HANA Conversion and SAP System Upgrade)
SUM tool segregate activities as uptime processing and downtime processing.
The uptime processing is the migration of the shadow repository. It can be migrated during uptime, because no changes are done any long – since the repository was locked at the beginning of the SUM procedure (dev lock). The shadow repository is built up from upgrade media (upgrade DVDs) + the maintenance planner download + additional files (files in the download directory, transport requests, add-ons etc).
The downtime processing is the migration of the application data, customizing data, and user master records. It can be migrated during downtime only, because it would be changed continuously during uptime. New standard customizing and new data, delivered by SAP, is imported.
The migration to SAP HANA DB takes place partially in uptime (UT) processing and partially in downtime (DT) processing of SAP up.

(reference from SAP-Press book “ADM328 SAP S/4HANA Conversion and SAP System Upgrade)

Overall Procedure at a Glance

SUM tool has too started on Primary application server. After some basic configuration setting, such as stack.xml, the SAP up will start to create shadow system. It contains the basic tables and some customizing tables. The system is still running, and end user may work in the system and use functionality that may change application data into database. In this phase, the system is running and available for end users (uptime processing), but the development environment is locked. Then the ramping down phase will start which includes, locking users, cleaning up queue etc.
The technical downtime phase is started. It migrates data from the source database into the target database. After this application tables are updated to the target release. Then validation will take place and go/no-go decision. After go decision from business owner, ramping up phase will start which includes reconnecting landscape, unlocking users etc. and finally system will be live on target release and available for end user.
The system is now migrated to the target database and updated to the target release.

Post – Conversion

(reference from SAP-Press book “ADM328 SAP S/4HANA Conversion and SAP System Upgrade)

Custom Code Adaptation

• Need to adapt any modification and enhancements using the standard transactions SPDD, SPAU, SPAU_ENH
• Need to fix any issues due to SAP S/4HANA simplification

Functional Adaptation

Once system conversion to SAP S/4HANA is completed, need to carry out functional adaptation based on the ATC results.
Adjust modifications and enhancements – To adapt the modifications and enhancements, use the standard transactions SPDD, SPAU, SPAU_ENH
Fix SAP HANA and SAP S/4HANA findings – Adapt custom ABAP code, using the findings of the SAP HANA and SAP S/4HANA checks (ATC results). Findings of SAP S/4HANA checks are related to S/4HANA Simplifications. Each simplification requires a different approach to solve findings. Therefore, findings of SAP S/4HANA checks refer to a SAP Note which describes how you can solve them.
Tool – ABAP Test Cockpit (ATC)

Performance Tuning

Once system conversion to SAP S/4HANA is completed, then need to look which business processes can be optimized on SAP HANA database. As we can make use of full power of SAP HANA regarding performance. Therefore, we need to look which SQL statements can be optimized.
ABAP SQL Monitor allow us to get performance data for all SQL statements executed in production. SQL monitor will help to understand what are the most expensive and most frequently executed SQL statements.  SQL Monitor allows you to link the monitored SQL statements to the corresponding business processes including various aggregation and drill-down options.
Tool – ABAP SQL Monitor

Cleaning up Obsolete Data after the Conversion

To delete obsolete data that may remain after the conversion of your SAP ERP system to SAP S/4HANA.

Cross Application Follow-on Activities

• Adapting Database Extension to SAP S/4HANA
• Adapting the User Interface
• Output Management

Application – Specific Follow-on Activities

• Finance
• SAP Credit Management
• Human Resources
• Sales – Order and Contract Management
• Retail
• Environment, Health and Safety
• Product Safety and Stewardship
• Integration

Conclusion

The conclusion is that – for successful converting to S/4HANA system, you can align with the sequence given in the blog.


Source: https://blogs.sap.com/2019/06/24/s4hana-conversion/

Material Ledger Customizing

Go to start of metadata

What are the benefits to use the Actual Costing - Material Ledger ?

The application component Actual Costing/Material Ledger fulfills two basic objectives: the ability to manage material prices in multiple currencies/valuations, and the actual costing functionality.

The aim is to combine advantages of both the moving average price and the standard price, to calculate the accurate actual price and to distribute price differences and follow-up costs. 

The benefits of the different valuation methods S price / V price are combined: 

• S price -> Stable price for controlling purposes.
• V price -> Actual price for valuation purposes.

The following functionalities are provided:  

1. Inventory Valuation at actual prices.
2. Actual Costing: Actual Price calculation and multilevel.
3. Transparency of value chain.
4. Parallel Currencies and parallel valuation.
5. Actual Price Cost Component Split

 

Customizing Material Ledger

• Basic settings for the Material Ledger in customizing
  There are some basic settings for the Material Ledger in customizing:
  
  
  
  • Activate Valuation Areas for Material Ledger: If the material ledger is active for a particular valuation area, all materials in the valuation area are valuated using the material ledger.
  • Assign Currency Types to Material Ledger Type and Assign Material Ledger Type to Valuation Area.
    You specify which currency types are used separately in the different applications. It is important to make sure that the settings in Financial Accounting, Controlling, and the Material Ledger harmonize with each other.
    
    There is no possibility to change the currency type with the Material Ledger already active. The currency in T000-MWAER must remain the SAME after the ML-startup program. If you change it later you have inconsistent data. In the case of you are working with a test system, you must deactivate the ML, and then you must run the startup program again with the currencies you want to work with. Take into account that the deactivation means: Running report SAPRCKMJX, and this report DELETES all ML-data. Check the KBA 1511335.
  • Define Material Update Structure  and Assign to a Valuation Area.
    In the standard system, the categories in the material update structure 0001 are so defined that the valuation price during material price determination corresponds to the weighted average price - the sum of the beginning inventory and the prices of all receipts of the period.
    
    During the material ledger update, data is collected from valuation-relevant transactions (for example, goods receipts, invoice receipts, settlements of production orders) in different categories in the material ledger according to the material update structure.
    The influence that these transactions have on the valuation price during material price determination depends on the category in which they are collected. The following categories exist:
    • Receipts
    • Consumption
    • Other receipts/consumptions
    A receipt always has an effect on the valuation price.
    If you are working with the update logic in the standard system, the material stock in the closed posting period is valuated with the weighted average price- - the sum of the beginning inventory and prices of all receipts in the period.
    If this logic meets your demands, you do not have to edit this section. The system automatically uses material update structure 0001.
  •  
  • Define and Assign Movement Type Groups of Material Ledger: Setting up the Material Ledger Update of Goods Movements for  Revaluation of Consumption if you want to adjust the single-level consumption values in actual costing with the periodic unit price in all value records, if the Revaluation of Consumption step is run.
    The price differences allocated to the category Consumption are allocated to the individual consumption alternatives in proportion to quantities consumed. Check the related wiki: https://wiki.scn.sap.com/wiki/x/yqw0Gg 
• Transaction CKM9:  Display of ML relevant customizing settings. 

 

 

• Transaction CKM9 with the option 'Display Accounts': the accounts for each ML relevant transaction type and corresponding valuation class are displayed.
  
  
  
• Remember!: activate Actual Costing in customizing to enable multilevel and actual costing functionalities. Check CKM9 for the plant.

• IS-Retail and Material Ledger are not compatible.
  Check the note 1955551. 

Source: https://wiki.scn.sap.com/wiki/display/ERPFI/Material+Ledger+Customizing

Create STO & Delivery from EWM ODO

Hi All,
When we create a Direct ODO from EWM to another plant then system automatically creates the STO & Creates the Outbound Delivery in ECC too.
Here is the process flow

Step1: Maintain STO Setup in ECC.
This is normal STO Setup only.

Step2: Map Delivery type & item type from EWM to ECC.
SPRO –> IMG –> Logistics Execution –> Extended Warehouse Management Integration  –> Direct Outbound Delivery –> Map Document type from EWM to ECC.

Step3: Map Item Categories: (Optional)
SPRO –> IMG –> Logistics Execution –> Extended Warehouse Management Integration  –> Direct Outbound Delivery –> Map Item type from EWM to ECC.
Step3: Create Direct ODO in EWM.




Here Partner is Receiving Plant in my case 4902.
Now Save the Delivery.

Now system triggers the below two FM’s to create PO & Delivery.
/SPE/CREATE_STO_FOR_DIRDLV              –   Create STO from Direct ODO
/SPE/DELIVERY_CREATE_FROM_STO      –    Delivery Create From STO


Storage location is not filling in PO( need to check ).
Step4: Rest of the process is as same as normal STO with EWM.

Hint: you can create a custom RF transaction in EWM with very few input fields( rest will be picked from customizing ) to trigger the STO Process from EWM


Source: https://blogs.sap.com/2019/06/23/create-sto-delivery-from-ewm-odo/