With the TOP Simplification List Items approach we want to start a S/4HANA SCN Blog series to provide more information about dedicated simplification items. Simplification items where we assume that any customer project has to deal with. The following S/4HANA SCN Blog is collecting these TOP Simplification Items with the links to the dedicated S/4HANA blogs.

The TOP Simplification List Items

Within this blog we want to provide additional information regarding the Simplification Item:

FIN - Technical Changes in Controlling

Description

With SAP S/4HANA, on-premise edition 1511 several general data model simplifications have been made to Controlling area. Those are:

• Actual data (value type = 04) that was formerly in COEP (CO line item table) is now in ACDOCA (universal journal)
• Statistical data (value type = 11) is stored in additional columns in ACDOCA (universal journal) and in COEP for compatibility access
• Totals tables for primary costs (COSP) and secondary costs (COSS) are replaced by views
• Actual data for long running orders and projects that were in COSP_BAK and COSS_BAK (back up for former totals tables) is now in ACDOCA
• Value types other than 04 and 11 continue to be stored in COEP, COSP_BAK and COSS_BAK (examples include planned costs and target costs)
• Table header COBK is updated as before
• Compatibility Views such as V_COEP and V_COEP_ORI provide access to data as before

Business Impact

• No impact on the standard SAP business processes
• Existing CO programs such as allocations and settlements are gradually being adjusted to read the universal journal directly
• Views aggregate data on the fly allowing select statements in SAP coding and customer coding to work as before
• It might be required to adapt Custom Code if fields have been added to the totals table or CO line item table.
• Write statements and customer DDIC objects must be adapted according to the instructions in the Note 1976487
• Replace access via compatibility views with direct access to ACDOCA for value types 04 and 11 (see Note 2185026)

Recommended Action

• Check existing totals tables and line item table to determine whether fields have been added
• Adjust access to read from ACDOCA directly

For more details see the PPT attached to the following SAP Note:

http://service.sap.com/sap/support/notes/2270404

As the noise around SAP S/4HANA seems to grow and grow I have been reviewing the S/4HANA Cloud versions. The solution has now grown into a more robust offering and I feel it is now ready for customers to move to. Whilst the current SAP ECC customer base have been spoilt with the perceived flexibility to allow be-spoking a common theme of simplicity and moving back to standard is coming from a growing group of customers. I have identified 5 key benefits that an Organisation can achieve by moving to SAP S/4HANA Cloud.

1. Quicker implementation times

1. Reduction of support costs

1. Ability to resort back to standard and provide control

1. Aligning to SAP’s strategic direction

1. Flexibility to integrate and enhance

Quicker implementation times– the benefits here are pretty simple to identify. The overall project duration is reduced due to the Cloud principles. The biggest time saving is during the build due to the reduced configuration and guided configuration process. However savings will occur during the testing phase due to the new testing tools and training will reduce due to the SAP Fiori screens being more intuitive and easier to train.For an existing SAP ECC client there is no code to copy and the system conversion is replaced with data migration. Within data migration SAP provides pre delivered data migration scripts and templates to reduce the effort of loading data into the new system. The reduction in the implementation times will reduce the overall effort of external consultants and the customer’s project team, which in turn will reduce the overall cost of the implementation which will always be welcomed.

Reduction of support costs– moving to SAP S/4HANA cloud will mean a new type of contract will be in place. An Annual subscription is used, and included in this are the core licences, the hosting of the solution and the box level support.  Current jobs like back-ups and performance monitoring are all covered which will allow the customer to focus on their business rather than managing the system of record. Further to this, as the core SAP S/4HANA solution is not as customisable as a traditional SAP ECC on premise solutions,the application support costs will reduce as well due to the reduction of bespoke objects.

Revert back to standard– for many SAP ECC customers with a mature SAP ECC system the level of bespoke would have grown over time. Some of the bespoke code maybe required, some will not be required.  The perception of what is REALLY required compared to what someone would actually WANT is often missed, leading to excessive additional coding. Being able to start from a clean and simple solution, based on SAP best practice will provide a number of customers the ability to work in a more lean and efficient manner. This in turn will reduce the overall cost of support and ensure the TCO will reduce. Customers who are looking at a Cloud solution will see efficiency as the key driver and moving to a fully customisable product will erode that benefit.

SAP’s strategic direction– the clear direction of SAP S/4HANA is for the product to be a Cloud first tool. This means all of the new functionality will be released first within the Cloud editions (a new release is planned 4 times a year for the Cloud version and only once for the on premise solution) and therefore before the on premise edition. The demand for Cloud based tools is rapidly growing and ERP is now firmly on this journey as well. With focus on the digital core and the ability to change quickly, Cloud has all of the attributes to help achieve this. SAP’s recent acquisitions have mainly been best of breed Cloud solutions such as Hybris, Success Factors and Concur, S/4HANA Cloud is now the best of breed ERP Cloud product.

Flexibility of integration– SAP S/4HANA Cloud edition is not a one stop shop for all enterprise tools. Within the product a number of API’s are available to link to other systems such as Success Factors, Hybris and others. HCP can be used to create specific bespoke applications that cannot be achieved within S/4HANA Cloud edition. This removes the need to bespoke in the core S/4HANA system. The out of the box integration between the SAP cloud products will reduce the time spent building and managing integration points.

Summary

SAP S/4HANA Cloud is a very attractive solution for customers wishing to implement a simplified ERP solution and gain the associated benefits. Being able to be agile and quick to change is a real competitive advantage for SAP S/4HANA Cloud. With “the cloud” the overall cost of the implementation, licences, hosting and support are much more competitive compared to an on premise implementation. Finally SAP S/4HANA is now market ready and growing in functionality with a true digital core, it is a product that will be attracting a lot of attention over the coming months and years.

Introduction

By now we all know S/4 HANA is in market and capturing the SAP space with very rapid speed.

In order to begin the S/4 journey there are three different ways we can choose from the S/4 HANA transition. This selection is mainly driven based on the current landscape setup and business requirement.

Let’s look at three different options,

New Implementation: New Implementation of S/4 HANA (Greenfield approach)

System Conversion:Customers who want to convert their current system into an SAP S/4 HANA system. Database, SAP NetWeaver and application transition in one step.

Landscape Transformation: Customers who want to consolidate their landscape

Transition to S/4 HANA

Here, in this blog we are going to focus on the system conversion part of S/4 transition and process/plan which needs to follow in order to do the system conversion on to S/4 HANA

System Conversion:

The system conversion option is available for such customer who wants to convert their current system into an SAP S/4 HANA system

System conversion will help you with the analysis of your existing business scenarios and adoption of SAP S/4 based scenarios based on the identified value as per the real business needs

The system conversion is basically involves the robust planning and involvement of Basis, technical and functional experts along with inputs from business stake holders in order to understand the conversion process and desire output as per the business requirements

Below is the high level plan to have S/4 HANA transition with the system conversion option. We will go in deep dive of the various steps in subsequent blogs as part of S/4 HANA implementation

To start with the conversion process, it’s very important to follow the detailed planning of conversion process.

The actual plan starts with the checks of your existing system, the study of existing system components, add-ons, business functions and industry solutions using the maintenance planner to ensure the compatibility with SAP S/4 HANA.

The details of how to use maintenance planner and its output is discussed in the blog, How to use Maintenance Planner for S4 HANA Conversion!

Reference Links:

http://discover.sap.com/S4HANA

https://open.sap.com/courses/s4h4

https://www.s4hana.com/

Introduction

In previous blog of S/4 HANA adoption we learnt about what all options to adopt the S/4 HANA and started discussing about the option of system conversion.

As discussed earlier, the system conversion option is available for such customer who wants to convert their current system into an SAP S/4 HANA system

Let’s quickly go over the high level plan for S/4 HANA conversion project as shown below,

Maintenance Planner:

The first step in S/4 HANA conversion is to analyse the source system using the Maintenance planner tool.

When you open the SAP Maintenance Planner for your system landscape you will see below screen with the list of available systems under “Explore Systems”.

Select the system from the list which you are planning for S/4 HANA conversion

In this case I am selecting the system EC1 which got some errors in verification and data sync with Solution Manager

The sync errors are resolved by ignoring the software components as these components are not present in my source system and can be ignored

After rectifying all the errors my system is ready for planning the S4 HANA conversion

Start the Planning activity as shown below,

This is the benefit of running maintenance planner at the start of S/4 HANA conversion project. At start of the project you will come to know if your system is ready for conversion or not and what all things which needs to be completed before system made ready for S/4 HANA conversion

As per below error screen, there are certain add-ons and business functions available in my system which are not supported by S/4 HANA and these issues needs to be addressed before we can select the S/4 HANA conversion

Check SAP note 2214409 and 2011192 for further details on how to handle the non-supported add-ons for S/4 HANA

I am able to resolve all the dependency and made sure the business functions information is available in solution manager so that it will be selected during the conversion process

After rectifying the above error the system is ready for the S/4 HANA conversion project

It’s very important to resolve the add-on errors as all the add-on's are not supported by S/4 HANA. Also, this is very important step as part of early planning in S/4 HANA conversion projects as it will give clear understanding in terms of if your environment is eligible for conversion scenario or you need to go for new Implementation and then do the data migration/conversion

Note: Solution manager plays very vital role in S/4 HANA conversion projects and it’s very important to have Solution manager properly setup and right data is sync between source system and solution manager

Select plan a conversion to SAP S/4 HANA option to start the process and download all required media files for S/4 HANA conversion

This is the 1^st step in your S/4 HANA conversion project.

Once the maintenance planner is successfully run we need to go to the second and important step of code and compatibility check.

Code and compatibility check phase is sub divided into 3 different steps, which we will learn in next blog of Code and Compatibility Checks!

Reference Links

The System Conversion to SAP S/4HANA, on-premise edition 1511 - Technical procedure and semantic adaption tasks

SAP S/4 HANA Flipbook

SAP Business Suite 4 SAP HANA

https://websmp203.sap-ag.de/~sapidb/011000358700000309032009E/

Beta Release of SAP Best Practices Explorer (SAP BPX) is now available for customers and partners. SAP BPX is the new web-channel to Search, Browse and Consume SAP Best Practices content for SAP S/4HANA and other SAP products.

Key Features of Beta Release

• Browse packages via catalog and A-Z index
• Search and filter packages
• Manage favorites
• Use/Download accelerators online and offline
• Access Content via Mobile Devices (only Tablets are supported)

How to Access SAP Best Practices Explorer:

Go to https://service.sap.com/rds and click the SAP Best Practices Explorer link.

We are in Beta Phase now. Once we Go-Live in near future, you can directly access SAP Best Practices Explorer @https://rapid.sap.com/bp

Please post your questions and feedback here.

The document describes a brief summary on the scope , design and architecture and also simplification list for SAP S4 HANA on premise edition 1511.

Broad View of S4 HANA Scope

Diagram source :SAP

SAP S4 HANA Architecture

Diagram source :SAP

Before and after S4 HANA The Principle of simplified and One

Diagram source :SAP

• Simple Data Model

Only mail table exists now no redundancies

Clear separation of Master data from transactional data

Reduction of Memory footprint

• Principal of “ONE”

Only one evaluation method(Material Ledger)

Instead of 2(IM + ML)

Flexible rebate Management instead of cumbersome and expensive redundancies

• Throughput Increase

INSERT command available only on data base level (MM-IM)

No locks for standard price valuation

A Brief Summary on the S4 HANA changes based on the white paper Simplification List for SAP S/4HANA, on premise edition 1511

• Master Data:  Business partner is now capable of centrally manage data for customers and vendors. BP is now the single point of entry to create, edit and display master data.
• ProductTable T130F (Table of Field attributes) does have delivery class E (E = Control table, SAP and customer have separate key areas). In SAP Business Suite the delivery class of table T130F is G (G= Customizing table, protected against SAP Update, only INS all).
• Material Number field length:   With SAP S/4HANA, on premise edition 1511, the maximum field length of the material number is extended from 18 to 40 characters.
• Simplification The field KZEFF in table MARA is not available anymore. The current setting KZEFF is such that the field will be hidden only from the UI, but still continue to be available in the database. However, Assign effectivity parameter values/ override change numbers (KZEFF) impacts the parameter effectivity in BOM explosion by providing a popup to manually overwrite validity parameters.

• The user interface for SAP S/4HANA, on premise edition 1511 is transaction BP.
• The specific transactions like XD01, XD02, XD03 or VD01, VD02, VD03 / XK01, XK02, XK03 or MK01, MK02, MK03 etc. are not available in SAP S/4HANA on premise edition 1511
• Currently mass maintenance for customers and vendors via transaction MASS is not available (on the roadmap of a future SAP S/4HANA release)

          Hence, the value of this field needs to be reset from X to space. This ensures similar behavior in UI & in the backend.

• The Foreign Trade functionalityas part of Sales & Distribution is not available within SAP S/4HANA. The functional equivalent in SAP S/4 HANA is     SAP Global Trade Services (GTS). The below mentioned fields for Letter of Credit/ Legal control/ Export control/ Preference management in Foreign Trade is supported by GTS and not through Material Master:
  • CAP product list no.
  • CAP prod. Group
  • Preference status
  • Vendor decl. status
  • Exemption Certificate
  • Exemption Cert. No.
  • Iss.date of ex.cert.
  • Military goods
• MRP fields in Material Master

The SAP S/4HANA simplification is done on the following tabs in transaction MM01/02/03.

Lot Size data in MRP1 Tab: unit of measure group is considered in only retail henceforth it is not

required to switch it on in the material master.

• Unit of Measure Group

Procurement in MRP2: MRP considers quota arrangements always, henceforth it is not required to

switch it on in the material master.

• Quota arr. usage.

BOM explosion /dependent Requirement tab in MRP4

• Selection Method

Repetitive manufacturing /assembly /deployment strategy tab of MRP4

• Action control
• fair share rule
• push distribution
• Deployment horizon.

Storage Location in MRP4

• SLoc MRP indicator
• spec.proc.type SLoc
• Reoder Point
• Replenishment qty.

Also the backend database fields for these "omitted functionality" remains existing in the system

• Material type "SERV" for services is introduced for Product Master in S/4HANA for simplification purposes. When you use material type SERV, some fields and departments that are irrelevant in S/4 are hidden from the screen. This gives all transactions relevant for material master, a leaner and simplified look.
• Business Partner IDOC Types (DEBMAS and CREMAS):The business partner related iDoc message types - DEBMAS and CREMAS are not available with Sap S/4HANA, on-premise edition 1511. They are planned to be available in a future release of SAP S/4HANA, on-premise edition.

If you try to transfer data using these message types in S/4HANA, data would be transferred without actually having created a business partner

• SD Data Model:
  • Elimination of Status Tables VBUK, VBUP: Status fields have been moved to the corresponding header and item tables - VBAK and VBAP for sales documents, LIKP, and LIPS for deliveries, VBRK for billing documents
  • Simplification of Document Flow table VBFA.
  • Field length extension of SD document category: Data element VBTYP (Char1) has been replaced by data element VBTYPL (Char4), also: elimination of field VBTYP_EXT (Char4)
  • Elimination of redundancies – Document Index Tables VAKPA , VAPMA, VLKPA, VLPMA, VRKPA, VRPMA
  • Elimination of redundancies – Rebate Index Table VBOX: see simplification item SD Rebate Optimization

Key benefits of the data model changes:

• Reduced memory footprint (simplified Document Flow, elimination of index tables, fewer aggregates)
• Increased performance of HANA queries and code pushdown (one select statement instead of two select statements, easier join for header/items including status and business data)
• Increased robustness of Rebate processing (no redundancies due to aggregates)
• Data Model Changes in SD Pricing

Business documents within the SAP Business Suite such as the sales order or the purchase order used

to store the pricing result in the database table KONV. In SAP S/4HANA, table KONV was replaced in

its data persistency role by the new table PRCD_ELEMENTS. However, KONV is and can still be used for

data declaration purposes. It still defines the structure of the pricing result within the application coding. The content of KONV is transferred to PRCD_ELEMENTS when moving to SAP S/4HANA.

Several other DDIC changes have been done in pricing condition table. Please refer the SAP paper for more details.

• Billing Document Output Management

With SAP S/4HANA a new Output Management approach is in place

• The complete configuration differs from the configuration that is used when output

        management is based on NAST. The configuration is based on BRF+ which is accessible for Customers.

• Output management based on NAST is not available for new documents in SD Billing. Billing documents that

are migrated from legacy systems and for which NAST based output has been determined, can be processed

with this technology.

• In application Billing it is recommended to use Adobe Forms but also Smartforms and SapScripts are supported
• In contrast to the output management based on NAST the new output management supports only the

        Channels PRINT, EMAIL, XML and IDOC (for on premise). Other channels are not available by default.

• The FI-AR-CR Credit Management
• SD Rebate Processing replaced by Settlement Management: In general, SD Rebate Processing is not available within SAP S/4HANA. The functional equivalent in SAP S/4 HANA is SD Rebate Processing is Settlement Management.
• SAP SRM: The functional scope of SAP supplier relationship management will gradually be made available with S/4 HANA a limited functional scope is now available as compared to SAP SRM. The coverage is proposed to grow overtime and procurement solution will evolve to take over SRM functions.
• SAP Supplier Lifecycle Management: The goal is that - over time - the functional scope of SAP Supplier Lifecycle Management (SAP SLC) will be available within the SAP S/4HANA stack.
• MM-Inventory management data Model:
• Material Ledger Obligatory for Material Valuation: This simplification makes it obligatory to use the Material Ledger in all SAP S/4HANA systems. When a system is converted to SAP S/4HANA the Material Ledger will be activated if not active already. Please take a note that though material ledger will be active for parallel valuation of inventory and other purposes it is not mandatory to activate/use actual costing.

In MM02 and MR21 material prices can now be maintained in multiple currencies. In Financials the inventory account balances are calculated separately for each currency and result therefore in a cleaner and more consistent valuation in other currencies than the local currency.

• Sales & Operations Planning (SOP) will be replaced by Integrated Business Planning IBP12. Integrated Business Planning supports all SOP features plus advanced statistical forecasting, multi-level supply planning, an optimizer, collaboration tools, an Excel-based UI, and Web-based UIs.

In this blog post, I will focus on how to migrate to a new SAP S/4HANA system, independent of the source environment. I’ll also talk about SAP Best Practices and tools that you can use out of the box – at no cost which is NEW.

When it comes to SAP S/4HANA, there are a lot of options on how to get there. We nailed it down to three so called transition scenarios. Depending on the deployment model (Cloud (SaaS), HEC (IaaS) or On-premise) and maturity level (S/4HANA Finance or full S/4HANA Enterprise Management), the path to a digital future looks more like a labyrinth than a straight line. This is the case, because you may have a lot of requirements to carry over and don’t want to digest too many changes at a time. However, you also might be trapped with too many corridors that you want to try out before you even realize that it means changes to your custom coding as well as changes in how your system works today.

But let’s back up a little bit. I mentioned SAP’s three transition scenarios for SAP S/4HANA:

• Scenario 1: New Implementation
  This is a new implementation of SAP S/4HANA (green field): customers who are migrating from a non-SAP legacy system or from an SAP ERP system and implementing a fresh system that requires an initial data load. In this scenario, the SAP S/4HANA system is implemented, and master and transactional data are migrated from the legacy system, thus standard data migration tools and content has to be used.
• Scenario 2: System Conversion
  This is a complete conversion of an existing SAP Business Suite system to SAP S/4HANA (lift & shift): customers who want to change their current SAP ERP system to SAP S/4HANA. This scenario is technically based on Software Update Manager (SUM) with Database Migration Option (DMO) in case the customer is not yet on SAP HANA as the underlying database.
• Scenario 3: Landscape Transformation
  This is a consolidation of current regional SAP systems into one global SAP S/4HANA system or a split out of different parts of a system: customers who want to consolidate their landscape or carve out selected entities (such as a company code) or processes into a single SAP S/4HANA system.

Coming back to the labyrinth, scenarios 2 and 3 are a lot like that: it looks simple from afar and really great with all the options and possibilities. However, sometimes you simply can’t make your way through it, especially when the labyrinth is really tricky due to the uber-customized old environment that you might be running on and your non-committal to change.

I guess you’re continually reading this because you want to change to a digital company, and you already got the message that SAP S/4HANA is the future and the answer to those issues arising with the digital world. You simply can’t risk your business with standstill on future IT investments, so you actually want the change. And at least somehow, this change will also involve your UI with new user interfaces (aka Fiori). Change that you need because there was actually a lot of room for improvement in the old ERP transaction world... In addition, it will involve changes in your processes as you actually aim for a simplification here, too.

So why not start fresh? Use a green field approach and implement a clean new SAP S/4HANA system! With this approach, you’ll have the opportunity to take the straight route without being trapped in the labyrinth of your old environment. Below are the tools and the SAP Best Practices content, which will help you in your transformation:

Data Migration to SAP S/4HANA in an on-premise or HEC hosted environment:

SAP Data Services is a key element of SAP’s solutions for Enterprise Information Management (EIM). SAP Data Services provides capabilities for data extraction, transformation, and load (ETL), as well as data quality management, and text data processing. The good news is that you can use the ETL capabilities of SAP Data Services for your SAP S/4HANA system without owning a costly SAP Data Services license (for more information continue reading). But you may consider to acquire that additional license (in case you don't own it already) to perform data cleansing and de-duplicate your data before the load.

More information:

Download Now! Rapid Data Migration to SAP S/4HANA, on-premise edition

Access the content:

SAP Service Marketplace - RDM for S4HANA On Prem

Demo video:

SAP S/4HANA, On-premise Edition: Migrate Your Data - YouTube

How-to guide:

A better way to migrate your SAP data with Rapi... | SCN

Data Migration to SAP S/4HANA offered as a SaaS model Cloud:

For SAP S/4HANA Cloud, SAP offers the built-in S/4HANA Migration Cockpit. This tool is available as part of the built-in Manage Your Solution Fiori application. You can execute data migrations directly out of this application via simple file upload and migrate your non-SAP or SAP legacy data. The data-migration objects are proposed based on the pre-configured business processes that were selected when the system was configured.

More information:

Watch the Demo: Migration to the Cloud | SCN

Demo video:

SAP S/4HANA, Cloud Editions: Migrate Your Data - YouTube

The Data Migration Guys:

Introducing the Data Migration Guys | SCN

While the above mentioned tools, including best practices content, are all available for no money, the best way to start fresh is to begin with clean and trusted data.

What will you take with you from your legacy systems into SAP S/4HANA?

Data Quality - you don’t want to just push your existing data problems into a new system, do you? SAP S/4HANA is the core of your digital enterprise, the postmodern ERP system for the information age. Success depends not just on going live with S/4HANA, but with running a real time enterprise where decisions and actions are based on high quality, dependable data. That is why data quality matters.

SAP Data Services has Data Quality capabilities for profiling, cleansing and de-duplication of data. It can even help you feed the migration templates that are used in the S/4HANA Migration Cockpit. Take the opportunity and try it!

Below is a comparison of the free Data Integration capabilities for ETL (aka basic data migration) or full use of SAP Data Services (aka data migration pro):

Bottom line

This blog post provided an overview on how to migrate to SAP S/4HANA by choosing from 3 transition scenarios, focusing on the New Implementation one. In addition to this, it introduced you to the process of data migration to SAP S/4HANA, on-premise or cloud by using SAP Data Services and SAP’s built in S/4HANA Migration Cockpit.

EVEN MORE

For more information on data migration to SAP, feel free to check out the Data Migration SCN Community, the new SAP Data Migration book, the new data migration online training, the recorded webinars, and The Data Migration Guys.

Still questions? Below is the link to our Q&A:

The DM Guys Episode 9, OpenSAP, Data Migration to SAP S/4HANA and more.....

Hello SAP Admins,

I was googling out for S/4 HANA material which is relevant to SAP Admins but didn't get exactly what I was looking out. I had to do lots of readings to get an idea of what S/4 HANA is for SAP Admins. So thought of writing this blog which will be useful for SAP Admins.

As everyone might have heard about S/4 HANA and its evolution into SAP business suite. Here's my bit of understanding of what actually it is and what different it is from a SAP Administrator standpoint. Well I must say, it is nothing different in terms of administering it. That's similar like administering a system running on top of HANA database but with a new SAP Fiori end user experience. It comes with a pre-configured industry specific best practices which are ready to use and can be customized according to customer's need.

About S/4 HANA:

SAP S/4 HANA will be a replacement for SAP R/3 or business suite platforms down the line. In SAP R/3, 'R' stood for Real-time while in S/4 HANA, 'S' means 'Simple' real-time business. S/4 HANA ( SAP Business Suite 4 SAP HANA --as it is called) is a new business suite of applications designed to run simple in a digital and connected world. Being built on the advanced in-memory platform, SAP HANA and designed on the most modern user experience, SAP Fiori has down to earth like features.

--->Complete choice of deployment - cloud and on-premise editions

--->Instant value across lines of business and industries

---> The ultimate sophistication: simplicity

Comparison between on-premise & cloud edition:

SAP S/4 HANA, on-premise edition, already offers a business scope that is similar to the current SAP Business Suite in terms of coverage, functionality, and languages. Within this scope, SAP S/4 HANA also includes the transformational simplifications delivered with SAP S/4 HANA Finance (SAP accounting powered by SAP HANA) as well as a planned integration with SAP SuccessFactors Employee Central and SAP Ariba Network.

The on-premise edition is intended to offer a yearly innovation cycle through innovation packages.

SAP S/4 HANA, cloud edition covers specific business scenarios for the marketing line of business and for the professional services industry as well as the most essential scenarios in the cloud with a digital core, which includes: finance, accounting, controlling, procurement, sales, manufacturing, plant maintenance, project system and product lifecycle management, plus integration with SAP SuccessFactors Employee Central, SAP Ariba Network, SAP Hybris Marketing, SAP Fieldglass and SAP JAM.

Three offerings are currently available as part of SAP S/4 HANA, cloud edition:

--> SAP S/4 HANA, cloud marketing edition -- for the market line of business

--> SAP S/4 HANA, cloud project service edition -- for the professional services industry

--> SAP S/4 HANA, cloud enterprise edition -- for a full ERP scope

The cloud edition is intended to offer a quarterly innovation cycle.

To keep it simple, on-premise edition can be installed by professional services vendor on SAP certified hardware ( something like a TDI) whereas cloud edition will be installed by SAP itself and the overall support/maintenance would be done by SAP for which the customer has to pay subscription fee.

SAP Systems running on business suite can jump in to S/4 HANA, on-premise edition in a one step technical procedure using SUM tool with DMO option. ( this is some thing to very exciting for SAP Admins )

Customers coming from SAP business suite can jump in to SAP S/4 HANA, cloud edition by implementing the SAP S/4 HANA cloud system using the guided configuration functionalities plus (if required) data migration functionality technically based on SAP LT.

Methodology Being Followed For S/4 HANA :

As always SAP comes up with quite a new naming conventions every time during its major releases and now they named SAP Activate as the standard methodology for S/4 HANA.

SAP Activate uses SAP Best practices, Methodology and guided configuration which will help in reduced time and reduced TCO.

In simple terms, we have a four phases in SAP activate namely Prepare, Explore, Realize and Deploy. Pictorial representations here says it all.

During the initial phase, SAP would provide a 30 day free trail of S/4 HANA with pre-defined business processes as per SAP Best Practices for different industry types (Charges would be taken for hosting on the SAP Partner Vendor's cloud {AWS} ). If customers are satisfied with the solution, then they would go ahead with the implementation.

Release Strategy:

SAP S/4 HANA was first released to customers in Feb'15, finance being the major component which was called as SAP S/4 Simple finance or SFIN. The latest on-premise edition is 1511 FPS02. For this product, SAP ships one new key release per year and 3 successive feature pack stacks (FPS) on a quarterly basis. Then comes the next key release, followed by 3 feature pack stacks, etc.,

Technically speaking, an FPS is similar to an SPS, but it may include non-disruptive, non-mandatory features.

The current on-premise product: --> SAP S/4 HANA, on premise edition 1511 (shipped in Nov'15) --> 1511 FPS01 ( Feb'16) --> 1511 FPS02 ( June'16) --> 1511 FPS03 ( planned in Q3 2016).

In Q4 2016, S/4 HANA, on-premise edition 1511 will go to maintenance cycle only mode and will be supported by SPS ( support pack stacks), according to the maintenance contract.

Numbering of FPS/SPS will be consecutive i.e., the first SPS after a FPS3 would consequently called as SPS4.

At the same time, SAP will ship the next big on-premise release S/4 HANA , on-premise edition 1610, which will be followed by feature pack stack on a quarterly basis.

FP-->New functionality + enhanced functionality + patches/bug fixes

SP-->Just patches ( new functionality is not even allowed here)

One more important thing here to note is the ECC main component SAP_APPL will be replaced by S4CORE Component ( ex--S4CORE 100 0001 -- Component/Release/SP-level).

Implementation Scenarios ( This is what We {Admins} need to watch out for ) :

Practically there are three scenarios for ultimately reaching S/4 HANA shown as below.

Scenario 1 - System Conversion : Existing SAP Business Suite Customers who want to move to SAP S/4 HANA

Scenario 2 - Landscape Transformation : Existing SAP Business Suite Customers who wants to optimize their system landscape & move to S/4 HANA.

Scenario 3 - New Implementation : New SAP Customers who want to move from legacy systems to SAP.

Brief overview on the three scenarios :

Scenario 1 - System Conversion : Existing SAP Business Suite Customers who want to move to S/4 HANA --> This scenario is focused on existing Business Suite customers who want to change current system to S/4 HANA, on-premise 1511 system. This includes the following steps.

--> Update to SAP NW AS ABAP 7.5

--> Migrating DB to SAP HANA ( in case, SAP Business Suite system is not yet on SAP HANA)

--> Installation of SAP S/4 HANA, on-premise edition

--> Installation of SAP Fiori for S/4 HANA

--> Migration of data from the old data structures to the new simplified data structures

**** Supported start releases for a one-step procedure : ERP 6 and suite on HANA, ERP 6.0 EHP 0-8, Suite on HANA ( including S/4 HANA Finance Add-on)

**** Customers on older business suite releases can move to S/4 HANA in a two-step approach ( ex- Unicode conversion & business partner conversion as a 1st step and move to S/4 HANA as a 2nd step).

Scenario 2 - Landscape Transformation : Existing SAP Business Suite customers who want to optimize their system landscape & move to S/4 HANA --> This scenario is focused on existing business suite customers who want to change to their current system or system landscape to S/4 HANA. This scenario covers more complex migration scenarios. Below are the technical steps:

--> Possibly a new installation of S/4 HANA, on-premise edition 1511 system

--> Possibly converting a system to S/4 HANA, on-premise edition

--> Additional migration steps that are based on SAP LT combined with SAP Landscape Optimization services.

**** In simple terms, suppose say you have region specific ECC systems and want to integrate all these systems into one system.

Scenario 3 - New Implementation : New SAP Customers who want to move from legacy systems to SAP

--> Installation of SAP NW AS ABAP 7.5 based on SAP HANA

--> Installation of S/4 HANA, on-premise

--> Installation of SAP Fiori for S/4 HANA, on-premise

**** In this scenario, S/4 HANA is implemented and master & transactional data is migrated from the legacy system. Depending on the S/4 HANA editions and detailed customer requirements, SAP LT or SAP Data Services technology is used for the required data migration.

Below picture would be the final evolution of SAP landscape in mere future.

Tools To Be Used For these Implementation :

SWPM - For new installation

SUM with DMO - For existing systems

Solution Manager (Solman 7.2) has to be integrated with the existing system which is be migrated for generating stack file with maintenance planner ( replacement of Maintenance Optimizer - MOPZ).

Future scope :

Below picture say it all !!!

Hope this is useful...

Yesterday I have write a blog post in Linkedin with the same title. Today I am in the middle of an SAP ERP HANA migration and I wanted to share the same title here in SCN with extended content.

Great song by Clash, I used the title of this great song to reflect the question among the existing/potential SAP customers' mind:

Should I stay or should I go now?
Should I stay or should I go now?
If I go there will be trouble
An' if I stay it will be double
So come on and let me know

S/4HANA is the new product that replaces existing Business Suite, has new code-line, has major simplifications in Finance and Logistics. Future destination is S/4HANA no-doubt, but when?

I have started to work on S/4HANA on premise 1511 after couple of days later from the date that it was announced. I was very curios about the new code-line and compatibility layer. I had many questions regarding the existing ERP functionality of new S4CORE which has replaced SAP_APPL. I have shared my findings here in SCN all blogs can be found here Sarhan Polatates

Now the question is obvious: Should I move to S/4HANA or Stay?

Answer is not as simple as the question,  but I have a personal roadmap:

1. For Net New Names / New SAP customers / Potential SAP Customers: Go with S/4HANA, it is safe and great, all simplifications are making life easier/faster/real-time without loosing any well-known SAP ERP functionality.

2. For Existing/Experienced/Mature SAP Customers: Moving to S/4HANA is not a technical migration, requires functional involvement in order to adopt simplifications brought by S4HANA, please keep this in mind. It is something like replacing  X system by S/4HANA. I mean the version of SAP ERP system that you are using is not important, even if your SAP ERP system is running on HANA. I am strongly recommending you to start with fresh implementation of S/4HANA. Assume that your existing SAP ERP is not an SAP product. Remember your first SAP implementation, do the same thing. This way is more safe, fast and cheap. However if you do not have option like this you need to convert your existing SAP Business Suite to S4HANA. The following graph illumunates what I reccomend. And the related posting can be found here: When and How S4HANA?

Cheers,

Introduction

As we know the S/4HANA is picking the speed and many customers started evaluating the S/4HANA transition requirement.

The S/4HANA transition can be done with 3 different options as explained in the blog: S/4HANA – Path to Digital Transformation

But the main question comes is which option is good from the customer point of view and what is the option as a S/4 consultant I can give it to my customer so that they can en-cash the benefits of S/4HANA and get the optimal return what the business is looking for.

Frankly speaking there is no right or wrong answer about which option a customer should consider for S/4 transformation, however based on my limited work experience in S/4 space, I have some point of view which I learnt over the period.

Again as I mentioned earlier there is no right or wrong answer in selecting the option and it’s completely driven by business decisions.

So as we know there are 3 options for S/4 transition, as per my view the “greenfield” implementation is the more suitable and easy to adopt option for any of the customer. I have put down certain points to support my view and I welcome others to add any additional viewpoints they might have,

From the “greenfield” implementation perspective if I divide the various tasks which are required for S/4HANA implementation vs the list of tasks required to go with the system conversion option then we will find quite a huge list of activities required in order to perform the conversion of existing system as against fresh implementation.

So let’s compare both these options with certain parameters,

S/4HANA “greenfield” Implementation:

Planning

The S/4HANA “greenfield” implementation means the new implementation of SAP S/4HANA, e.g. for customers migrating a legacy system, also known as ““greenfield”” approach.

Basically for any “greenfield” HANA implementation there are certain activities which are very important and needs to be considered while doing the new implementation,

It’s very important to have robust planning done for S/4 implementation. The planning activities mainly consist of,

• Choosing the implementation option: If you want to go for on-premise edition of S/4 or cloud edition of S/4
• Selection of hardware vendor or cloud partner
• Choosing the right deployment option for both non-prod and prod systems
• Doing the right sizing for your S/4 based on the amount of data which will be moved from legacy/SAP systems
• Designing the landscape: Number of environments for S/4 (Sandbox, Dev, QA, Prod etc)
• Any requirement for HA/DR setup
• Strategies around backup, HA/DR, network, hostname, SID name etc
• Data migration strategy
• Integration strategy with existing SAP/legacy landscape and with any 3^rd party providers
• Security requirement etc

Basically these are the most common activities for any of the “greenfield” implementation but from the S/4HANA perspective the important aspect would be to consider the strategy around moving the data from legacy/SAP systems

Timelines

Based on the Demo 21 implementation as well as the on-premise implementation which I did the “greenfield” implementation has shorter timelines due to faster implementation cycle

The additional activity of data migration planning and strategy which is required for “greenfield” implementation and which might be little time consuming based on the below considerations,

• If you have existing SAP data services landscape then you can use it for data migration and it will save some more time.
• If you don’t have existing data services in your landscape then additional time required for setting up the SAP data services landscape
• The re-engineering and process simplification for business processes

Cost

The cost parameter is driven by lots of factors, but based on my experience I can see the new implementation cost is less as compared to system conversion due to shorter timelines and the number of resources which will be involved in implementation

Number of Steps

Earlier we saw few basic steps as part of planning activity, so mainly the high level steps which are required for “greenfield” implementation are,

• Landscape planning – Details as given in the planning phase
• System installations – Installation for application server and HANA DB. Additional system installations for SAP data services or SLT are based on the consideration if these components are present in the landscape or not.
• Data migration – Initial data migration from ERP or legacy systems. The predefined migration objects are available which makes data migration very easy and fast from existing ERP or legacy systems.
• Functional configurations – Business process configurations as per business requirements. Also, the best practices are available along with the required guided configurations
• Custom code requirements (optional) – If any custom functionality needs to be implemented on top of S/4HANA functionality
• Testing – Regular testing cycles which includes Unit, integration and user acceptance testing

Team Involvement

PMO - It’s very important to have a strong technical Project manager involved for your S/4HANA green filed implementation. The technical project manager is the one who can understand and co-ordinate very well between SAP, HW vendors, Infrastructure team, and basis team, as these are the major components in the HANA implementation projects

Infrastructure – You should have infrastructure resources from data centre setup, network, operating system etc aligned to your project

Basis – Basis team plays very important role throughout the project and they have major activity during the installation using the SWPM – software provisioning manager tool

Functional (Limited – Based on business functions which needs to be adopted)

ABAP Technical (If any custom development needs to be done on top of S/4 functionality)

Tools

Below are the main tools which are required for “greenfield” implementation,

• SAP QuickSizer
• SAP Software provisioning Manager (SWPM) – SAP SWPM is used for the system installation. The SWPM is available as part of sltoolset
• SAP data services (BODS) – SAP DS plays very important role in “greenfield” implementation as its required to migrate the data from legacy SAP ERP or non-SAP systems

Impact on existing Landscape

With “greenfield” implementation there is minimum impact on your existing landscape and only new S/4HANA landscape needs to be setup along with SAP data services system for data migration

Data Strategy

Robust data migration strategy is required to load the initial data. It’s very important to use the ETL tool such as SAP DS. Also, the data strategy helps in archiving the older data and load only required data into newly implemented S/4HANA system so that it will have reduced data footprint, optimal performance and good return on investment

Business Process Optimization

Simplified and easy to adopt business process due to new implementation

S/4HANA System Conversion:

Planning

The S/4HANA system conversion is good for the customers who want to convert their current system into SAP S/4 system

The initial planning activities which needs to be considered for the system conversion is similar to that of “greenfield” implementation as below,

• Choosing the implementation option: If you want to go for on-premise edition of S/4 or cloud edition of S/4
• Selection of hardware vendor or cloud partner
• Choosing the right deployment option for both non-prod and prod systems (TDI, MCOD, MCOS etc)
• Doing the right sizing for your S/4 based on the amount of data which will be moved from legacy/SAP systems
• Designing the landscape: Number of environments for S/4 (Sandbox, Dev, QA, Prod etc)
• Any requirement for HA/DR setup
• Strategies around backup, HA/DR, network, hostname, SID name etc
• Data migration strategy
• Integration strategy with existing SAP/legacy landscape and with any 3^rd party providers
• Security requirement etc

Addition to this the major steps for system conversion starts with the analysis of your existing system, compatibility checks, custom development checks and rectification and making sure the source system is ready for conversion.

The additional activities which we are talking about here are very time consuming and needs to have proper analysis, deep thinking of various dependencies and thought process to make the conversion project successful

Timelines

Currently I am in process of doing the system conversion for one of our ERP system. Based on the process the system conversion timelines is very long due to various activities which are involved for system conversion,

• Source system pre-requisites checks and readiness
• Technical preparation steps
• Functional conversion activities
• Conversion execution using DMO tool
• Post conversion activities

Cost

More cost as compared to “greenfield” implementation as longer timelines to implement and many teams are involved

Sometimes the source system is not compatible and pre-requisites are not mate for S/4HANA conversion. So to make your source system compatible you need to perform various activities which adds up the cost to overall system conversion project

Number of Steps

For the system conversion scenarios the requirement is to have all the steps which are mentioned for “greenfield” and additionally the steps which are required from the initial system readiness from business functions as well as custom code adjustment perspective

Please refer the below blog series to get an idea about different S/4HANA system conversion processes,

S/4HANA – Path to Digital Transformation

• Landscape planning – For system conversion scenario also you need to have proper landscape planning as mentioned earlier in the blog
• System conversion checks – This is the very important step in the system conversion process. Please refer blog How to use Maintenance Planner for S/4HANA Conversion
• Business function checks – Review the simplification list made available for S/4HANA against the existing business function scenarios. Please refer blog, S/4HANA Conversion 2nd Step – Code and Compatibility Check
• Custom code checks and adjustments - For the SAP system conversion to SAP S/4HANA, any modification/simplifications made to SAP objects need to be considered in your customer objects. The Custom Code Migration work list helps to provide the details of all customer objects and provide the reference to simplified SAP objects and links to information about how to adopt these customer objects.
• System installation and migration – Installation of S/4HANA system and migration using the DMO operation
• Functional configurations – Post migration functional configurations as per the business requirements
• Custom code requirements – Additional custom development if required (Optional)
• Testing – Regular testing cycles which includes Unit, integration and user acceptance testing

Team Involvement

For the system conversion scenarios, it’s very important to have technical project manager along with the functional leads from the respective business functions which are enabled in your source systems.

The functional consultant’s needs to analyse and make sure the business functions are validated against the existing processes to make your conversion successful

Additionally, it’s very important to involve the strong ABAP technical resource who will be able to analyse the custom code against the simplification list of S/4HANA

Tools

Tools required are,

• SAP Quicksizer + ABAP sizing reports for HANA for sizing the landscape – From the sizing perspective, it’s very important to consider the existing database size and comp up with the sizing
• Maintenance Planner – This is the first step in S/4HANA conversion is to analyse the source system using the Maintenance planner tool.
• Business functions checks – Simplification list provided by SAP for S/4HANA. The list is available with the required changes inPDFandXLSformat for customer reviews for better planning and estimation for the S/4HANA conversion programs
• Custom code analyzer – The tool is available for doing the comparison with custom code and the S/4HANA simplified code. This needs to be implemented on system which should have NW7.5 ABAP stack
• SUM – Software update manager for DMO operation
• Solution Manager – Solution manager plays very important role in system conversion projects. The SAP activate methodology can be implemented and used for S/4HANA conversion projects.
• SAP data services, SAP SLT – These tools are optional and required if any data movement is required from legacy system to S/4HANA

Impact on existing Landscape

For the system conversion projects, it’s always recommended to have n+1 landscape. So additional landscape planning is required, the parallel landscape helps to avoid business disruptions

Additionally the requirement is to have NW7.5 ABAP stack to do the custom code analysis, this is temporary server requirement

Data Strategy

For system conversion it’s very important to complete the analysis required to migrate the data before we start the conversion activities

It’s recommended to put together the strategy to get rid of unwanted data, have archiving strategy in place to reduce the data footprint on S/4HANA. It helps to make sure there is no data loss during migration process and the migration activities are faster

Business Process Optimization

Even though SAP claims system conversion as Migration without re-implementation, still as part of conversion process, functional team will end up doing the review the existing business process as those needs to be map with the S/4HANA business processes as you need to re-evaluate the existing process flows.

Conclusion:

So based on the above data points what we can conclude is the “greenfield” option is very viable for the customers,

• Who has very complex business scenarios configured and want to look for simplified business processes based on the S/4HANA
• The customers who has huge customization done and want to adopt SAP standard application and get rid of custom developments
• The customers who want to archive their legacy data and utilize S/4HANA only for the data which is required from their day to day operations perspective and can liaise on archival or NLS solutions for older data
• Customers who are looking for rapid turn around and faster path for S/4HANA adoption

Whereas system conversion is viable option for the customers,

• Who has very less business processes configured in their existing ERP system
• There is very less amount of customization in existing environment
• Customers who still want to utilize their data and don’t want to adopt archival or NLS solutions (This point is true with either of the option, so not exactly the comparison)

Recommendations

So finally, as we stated earlier there is no right or wrong answer for the option and it’s very much driven by the business requirements. However the recommendation is to opt for the “greenfield” implementation due to below upfront benefits,

• Re-engineering and process simplification based on ready to run business processes
• Predefined migration objects & best practices available with guided configuration
• Reduce time to value and customer total cost of ownership
• Rapid adoption of new innovations

Lastly I want to put a quote from one of the famous businessman “I don’t believe in taking right decisions, I believe in taking decisions and making them right”.

So whatever path you choose for your S/4HANA transitions just take the decision and make it right with right procedure.

Hope this blog helps you with your S/4HANA transition, good luck!

Reference Links

SAP S/4 HANA Flip book

SAP Business Suite 4 SAP HANA

https://open.sap.com/courses/s4h4

https://open.sap.com/courses/s4h1

In the video below we show how to execute Maintenance Planner for an upgrade to S/4HANA Finance 1605 as part of SAP ERP6 EHP8.   Customers can migrate to S/4HANA Finance 1605 from any ERP6 release.  For more details see this note 2235268 - Release Information Note: SAP S/4HANA Finance 1605

Why is this video need?   The Maintenance Planner makes it very easy to plan an install of S/4HANA Enterprise Management 1511 - but what if my company isn't ready for the simplification of Logistics and Finance?   What if I just want the innovation of S/4HANA Finance?   The S/4HANA Finance 1605 release delivers the latest Finance simplifications and then allows me to move to Enterprise Management once we've mastered the process optimizations in Finance.

Please post your thoughts and questions!

Important Notes for S/4HANA Finance 1605

2235268 - Release Information Note: SAP S/4HANA Finance 1605

2233539 - Release Scope Information: SAP S/4HANA Finance 1605

2255079 - Release Information: SAP Fiori for SAP S/4HANA Finance 1605

2277137 - Release information Note: SAP Smart Business for SAP S/4HANA Finance 1605

2261242 - SAP S/4HANA Finance: Information on Upgrade Paths

2158106 - Problems with add-on installation/upgrade to SAP NW 7.50 AS ABAP

What are some of my lessons learned?

• This is a move to SAP ERP6 EHP8 with S/4HANA Finance 1605 as an ABAP Add-on.   The test scope for all non-Finance applications will be similar to that of any other Enhancement Package project.
• Check your ABAP add-on compatibility!   We had an old Gateway component installed that wasn't compatible with Netweaver 7.50 (foundation for S/4HANA Finance 1605).   Used SAP Note 2319097 to uninstall IW_SCS 200.
• Maintenance Planner doesn't add all media to your download basket for EHP8.   When you start SUM SP17 it will prompt you for the ERP EHP8 Upgrade Export DVDs.   This is about 24GB of DVDs!  So painful to download when you already downloaded everything else from Maintenance Planner.   You'll need 50GB just for EHP8 & S/4HANA Finance 1605 media.
• For your source ERP system - ensure the following has been completed before starting Maintenance Planner
  • Update SAP Host Agent and validate registration to Solution Manager SLD
  • Update SLD Content (SAP Note 669669)
  • Validate Product System & Technical System data in LMDB - specifically the data suppliers. (it's not even worth trying the Maintenance Planner until all this data is good)
  • Use the 'Upload to SAP Support Portal' to upload LMDB data to the Maintenance Planner
    

Direct Link to YouTube video > Preparing S/4HANA Finance 1605 Installation with Maintenance Planner - YouTube

Michael Pytel

The following blog provides a comparison of how the process of marking vendors for deletion is different between legacy ECC system and new S4 HANA system.

How we used to Flag for Deletion in ECC

In legacy ECC environment, vendors could be flagged for deletion at the vendor master level using transaction XK02. At the vendor master level you could go to Extras -> Deletion Flags

At the following screen, the users could selectively flag for deletion at All Areas, Selected Company Code and Selected Purchasing Organization

The other option users had was to use transaction XK06 to flag for deletion Centrally 

The third option users had was to use transaction MK06 to flag for deletion at the Purchasing Organization level.

How we now have to flag Business Partners for deletion in S4 HANA

With S4 HANA 1511 and above SAP has introduced the concept of business partners and the concept of vendors is obsolete. So the way to flag vendors for deletion has changed as well.

Here is a Business Partner which is a vendor and is displayed via T Code BP. Notice that under the Extras menu there is no option of flagging the Business Partner for deletion

The Archiving Flag can now be found in the General View -> Status tab. This will flag the Business Partner for deletion at an overall level.

The other option is to flag Business Partners for deletion is at the company code level. Users can selectively choose for which company codes the Business Partner needs to be flagged

With the concept of Business Partners the transactions XK06 and MK06 are obsolete. Now you can use the transaction BUPA_PRE_DA to flag multiple Business Partners for deletion as the same time.

The e.g. shown below is for one Business Partner. Execute the transaction with the Test Run flagged and review the log

Once successful, run the transaction without the test run flag

The system will prompt and ask for confirmation. Select Yes

The log will show that the run was successful

At the BP transaction, the same Business Partner has a STOP sign and at the Status tab the “Archiving Flag” is flagged

At the BP table, BUT000 – XDELE is flagged

At the vendor table, LFA1 – LOEVM is flagged

A short intro to S/4HANA inventory management. Keep watching for more on this topic. Next session will be on inventory postings and material documents.

S4HANA Session 1 Intro and Inventory - YouTube

As of the latest releases (May/June 2016) for S/4HANA packages both On Premise (Edition 1511 FPS02) & On Cloud (Edition 1603), there have been certain significant enhancements & extensions on the functionalities under logistics. In this piece, I will focus on the business value & benefits of different offerings under Sourcing, Procurement, Supply Chain & Manufacturing along with key functionalities provided in S4/Hana under each of them. I am not at all going to touch on the technical differences between OP & Cloud editions but at a broader level will highlight the functional aspects which are quite similar for both sort of deployments.

SAP has tried to make it clear that SAP S/4HANA is a new product line & not the successor of any pre-existing business suite but the sort of functionalities covered under S/4HANA Enterprise Management edition directs one to think that if at all they will be migrating to S/4HANA which is inevitable, they have to leave the existing business suite behind to fully harness the capabilities S4/HANA has to offer. I also totally understand that the offerings under On Premise & Cloud edition may differ a bit but not to such an extent that we have to have separate write-ups from point of view of covering logistics functions.

I will be discussing the Key Innovations under each area in S4/HANA as per the mapping into product map & I will also try to go deeper wherever needed into exactly how these innovations will work for any business based on the best practices adopted into S/4HANA.

PROCUREMENT

Simplicity– Procurement is an area is well known for the complexity, manual work, time-consuming processes with high volume of purchasing documents and line items. S/4HANA lowers the procurement operation cost by providing a simple yet efficient procure to pay process facilitated by Fiori apps i.e. for Analytics, Spend KPI’s. User experience is simplified & enhanced by role based apps. Business value is added by real time analytics.

Visibility– S4/HANA gives ultimate visibility at fingertips by using Fiori apps, providing Ad-hoc supplier transparency & performance evaluation based on detailed data points & most importantly integrating with SAP Ariba network for transactional data.

Adoption– Procurement process is supposed to be manual or semi-automatic leading to slow cycle time & error prone. S/4HANA has Self-Service Requisitioning leading to higher business user adoption through a consumer-grade user experience. It also offers five times less interaction steps to get the procurement information leading to faster & accurate data.

INVENTORY MANAGEMNET

Accuracy– Due to missing real time analytics, process & data redundancies one can’t be sure of the accuracy of valuation or Inventory figures. S/4 HANA is capable of more timely & detailed real-time processing of Inventory postings leading to higher accuracy of Inventory. Parallel inventory posting for standard price-driven materials is also possible. This also helps in Improved On time delivery. Valuation is more accurate since it’s based on one valuation method (Material Ledger) instead of 2 (MM-IM and ML). All of this is simplified by use of Fiori apps for Mangers as well as warehouse resources.

High Inventory Turnover– S4/HANA gives more visibility & accuracy of Inventory across the board & hence lesser Safety stock can be an option which will help to have better Inventory turnover ultimately leading to reduced Working capital cost to company.

Segment of One– S4/HANA offers real-time processing instead of batch processing & support to manage dynamic demand fulfillment for even lot size of one & facilitate this throughout the logistics operations. 

MATERIAL REQUIREMENT PLANNING / CAPACITY PLANNING

Flexibility– It’s is common to have revenue loss due to stock-outs & poor on time delivery performance. S4/HANA offer prioritized view on material flow issues with clear visibility. It also gives system-generated solution proposals & automated creation of procurement proposals. It’s flexible in tailoring of available capacities and receipts to meet required quantities.

Quick– Accelerated MRP run on S4/HANA can be 10+ times faster along with faster demand propagation along the supply chain giving more chances for simulation & better planning quality.

Real Time– S4/HANA offers Real-time alerting based on current stock requirements situation as well as Real time Inventory picture.

MRP Fiori apps offers managing and monitoring external and internal requirements, material coverage, monitoring production or process orders. It’s planned to have one MRP system for planning including the APO PP/DS into S/4 Hana & Live cache-based, finite-capacity planning as an integral part of the SAP HANA platform, requiring just one database to manage along with simplified data integration, advanced analytics. It will also offer Intuitive maintenance of master data and integration models. This will be a great innovation & edge for planning aspect on S4/HANA since this will lead to fulfillment of an order on time with accurate quantity using various checks for different business scenarios along with performing automatic back-order processing.

AVAILABLE TO PROMISE

On Time– S/4HANA enabled mass product availability check for sales, planned and production orders i.e. ATP check for all items of an order at once which leads to fulfill an order on time and in the desired quantity using different kind of checks for different business scenarios. It helps to promise accurate and reliable order dates & to fulfill orders from the entire network or to substitute products automatically.

Efficient– S/4HANA has significant performance improvements for releasing large production orders. There are plans for data and process innovations in Backorder processing and Sales Product Allocation.

PS: All the above are personal perspective on the basis of exposure to information provided by SAP on S/4HANA.

SAP S/4 HANA is the new offering from SAP built on the high performance In-memory platform HANA with an enriching user experience using FIORI apps.This new system includes major changes and massive simplifications ranging form changes in underlying data models to new user interface through FIORI apps.

Objective:

The objective of this blog is to understand the data model simplifications in SD area through a comparative study with a non S/4 system.

Below are the major simplification points:

• Status tables VBUK and VBUP have been eliminated and the new status fields have been added to:

• VBAK and VBAP for sales order header and item
• LIKP and LIPS for delivery document header and item
• VBRK for billing document header
• No status fields are present for billing items.

• Simplification of document flow table VBFA

• Document index tables like VAKPA , VAPMA etc. have been done away with.

Comparison:

Let us understand the differences by looking at the table structures:

• VBUK and VBUP are still present in S/4 HANA but they are not filled when an order is created.
• The status fields have been added through append structure.

• If any custom fields have been added to VBUP or VBUP tables in source system, they will have to be added to respective document tables in S/4 HANA system.
• An append field to the document header status table VBUK must be added to one or several of the document header tables VBAK, LIKP, or VBRK. This decision depends on which of the document types the respective field is relevant for.
• An append field to document item status table VBUP must be added to one or more of the document item tables VBAP or LIPS.

VBAK:

VBAP:

When a sales order is created in  a non S/4 HANA system:

Sales Order: 7137:

VBAK table holds the order header details

Order status information is present in VBUK table

Sales Order in S/4 HANA system:

VBAK table contains both the header details as well as the header status

Header status fields are now added to VBAK table

Table VBUK is present but is not filled.

Reason VBUK / VBUP are still present in S/4 HANA:

Since the status tables are not being filled it can be questioned why the tables are still present and not removed from system altogether. The reason for this is to enable smooth transition for those opting for migration to S/4 HANA system.

New function modules have been written which read the document status fields from VBAK , LIKP aur VBRK tables and populate in output whose structure is similar to that of VBUK.

For example FM SD_VBUK_READ_FROM_DOC is a new FM that fills VBUK structure for one SD document out of document header tables. The data is fetched depending upon the document type.

• The output structure ES_VBUK still refers to VBUK table.
• Any custom fields added to appends like VBAK_STATUS will be read by this FM.

Advantages:

• Reduced memory footprint : Since fewer tables are involved this means reduction of redundant data and simplified document flow.
• Now if we need to query the order table on the basis of document status we can simply do so by 1 single query on VBAK table instead of join on VBAK and VBUK.

NOTES:

• OSS Note 2198647 can be referred for further information.

Acknowledgment:

• Reference taken from Simplification List for S/4 HANA 1511 0302.

Suggestions and Comments Welcomed !!

~Tanmay

This post aim to give to the members of this community that are not fully familiar with what S/4HANA is and it is looking for more information before going deep into this journey and going for more technical details.

This is one of many posts that I am planning to share with this community.

SAP Business Suite 4 SAP HANA, S/4 HANA or S/4HANA (all together) is a new Business Suite officially announced by SAP in 2015.

Time to re-build the Business Suite for the digital world

(image source: SAP)

SAP has been enhancing their business applications according to the technology and 2015 was the year that a revolutionary business suite was officially announced. Thanks to the new technologies in Hardware that brought massive processing power and speed with costs decreasing, huge memory and multicore processors, SAP was able to redesign their existing products and that originated the SAP S/4HANA.

The S/4HANA is a core component of a whole new “next generation” of SAP products.

SAP S/4HANA – A reimagined suite to reimagine business

Business Scope of release 1511:

• Finance: Accounting Operations
• Finance: Unified Ledger & Fast Close
• Manufacturing: Production Processing & Subcontracting
• Manufacturing: Quality Management
• Supply Chain: Production Planning
• Supply Chain: Inventory
• Sourcing & Procurement: Operational Procurement
• Sourcing & Procurement: Contracts and requisitioning
• Sales: Sales Order Fulfillment & Returns
• Service: Project and Service Management
• Human Resources: Time Management

(image source: SAP)

Companies can start their journey with basic components and grow later adding new products for a more robust enterprise management.The S/4HANA, like the SAP ERP ECC is the main product that will support all core business process in the company, like P2P, OTC and etc.In combination with applications such as SAP Hybris, SAP Success Factors,  SAP Ariba, SAP Fieldglass, Concur and the Internet of Things projects, SAP offers a digital value network, which interconnects all aspects of the value network in real-time to drive business outcomes. Those are some of the other business Solutions that can be added at any time to provide the best experience and technology to manage the many different business in a company.The S/4HANA is built on SAP’s advanced in-memory platform, SAP HANA, and runs ONLY in a HANA DB, as no other DB can provide the speed and technology required to achieve the level of experience that this new Suite expects to deliver.SAP HANA DBBefore we go in more details on S/4, let’s talk briefly about the HANA DB.

(image source: SAP)

Years ago SAP started researching on how to develop their products and applications to run over an in-memory database, but then they realized that the Database expert companies couldn’t deliver what SAP wants, then SAP began their on in-memory database development.They had to work very closer to the market leading chip manufactures in order to find the optimal design to the database that could explore the full power of the next generation of processors.In 2011 the SAP HANA was finally announced and it was available as a standalone data mart solution to allow customers capture data from any source in real-time, load that data to in-memory database and build the BI reports and applications on top of it.Then SAP did offer the SAP HANA as an Accelerator to be deployed as side-car engines to run parallel to the SAP ERP in critical business functions, yet performing slowly. Meanwhile SAP did start developing new applications completely powered by SAP HANA (for example Smart Meter Analytics).Then in 2012, SAP migrated the an already existing application to the SAP HANA, the SAP BW, and this was followed with the SAP Business Suite, names Suite on HANA (SoH), not S/4HANA.As mentioned already, 2015 was the year that SAP announced the S/4HANA, after completely rewriting the ECC. Different from SoH, the S/4 is a brand new code-line that works only on SAP HANA and can’t work with any other vendor’s database, like the SoH, mitigating the limitation of those DBs and exploring 100% of the SAP HANA capabilities.

Key Aspects of SAP S/4HANA

(image source: SAP)

So, what changed then?It is hard to explain it in detail when I am proposing to just introduce the S/4HANA to you. But I can explore in future posts going in a deeper detail.

• The S/4HANA is natively built on SAP HANA, and because of that, it adheres to the capabilities of this powerful application platform and database management technology, which includes predictive analytics, advanced text mining, real time decision support and etc..
• A new UI that offers personalized user experience with SAP Fiori and can deliver the same level of experience targeting in productivity in different devices, such as computers, laptops, tablets, smartphones and etc.
• The data model was simplified reducing and vanishing unnecessary tables and the data stored and subsequently the data footprint was significantly reduced, simplifying the application design and extensibility.
• It can be deployed in the cloud or on-premise.
• S/4HANA Cloud Edition* is delivered in different flavors:
• Enterprise Edition-based ERP with Cloud extensions (SuccessFactors, Employee Central, Fieldglass, hubris, Concur and Ariba)
• Project Services Edition, focused on professional services with Cloud extensions (SuccessFactors, Employee Central, Fieldglass, Concuren Ariba)
• Marketing Edition Customer Engagement & Commerce
• Real-time OLAP capabilities inside the ERP system allows you to run all your operational reports directly in the source data using SAP HANA Live.
• Fiori Smart Business Cockpits using SAP HANA Live providing real-time insights in real-time Business Processes.
• Free Text searches – google-like experience in ERP improving for example customer service by reducing customer response times with regards to sales orders.
• Eliminate batch processes and enable real-time operations like in Plant Maintenance

*S / 4HANA Cloud Enterprise Edition, provides a state-of-the-art base to completely innovate the business and digitize. Processes and information flows are greatly simplified and employees can work proactively and accurate contextual and personalized real-time information. By HANA Cloud Integration platform to be easily interfaces with other SAP cloud solutions enabling the digitization of all processes in the chain is quickly realized.

(image source: SAP)

Due to the new data model, SAP S/4HANA replaces successively the old code line with a new code line, which is free from limitations of traditional databases and allows SAP, partners and customer developers to explore and maximize the benefits of the in-memory database technology.

SAP HANA in-memory technology can be defined as in-memory first processing instead of replicating a subset of data from disc to memory.

S/4HANA comes by the built in capabilities of SAP HANA. You can notice that in the new S/4HANA applications:

Application Services: As well as a database, SAP HANA can also provide many application services. This means many applications can be built in a 2-tier model, rather than a 3-tier model.

Processing Services: SAP HANA can handle many new types of data. This includes text, spatial, graph and more. But is not enough to simple store these new data types we need to be able to build applications that can process and integrate this data with traditional data types, such as business transactions. SAP HANA provides native in-memory engines that process any types of data in real time.

Integration Services: SAP HANA has multiple data consumption options built in. We can analyze continual streaming data, read data remotely in any data source, read Big Data stores such as Hadoop, synchronize in both directions with remote databases and devices that collect data (IoT). SAP HANA has built in Extraction, Transformation and Loading (ETL) capabilities so that separate software is no longer needed to clean, enrich and profile data from any sources.

Database Services: SAP HANA is a full in-memory column and row store database that can support both OLTP and OLAP requirements and is built to run on high-end hardware. It stores data optimally using automatic compression and is able to manage data on different storage tiers to support data ageing strategies. It has built in high availability functions that keep the database running and ensure mission critical applications are never down.

I hope you find this information useful... See you on my next post.

Leandro da Pia Nascimento

Digitalization started in the late nineties when the first physical products such as music and photos were converted to a digital format. The evolution of these industries depended heavily on developments such as the high-speed internet and mobile technologies. Today, digitalization affects every person and every business – the “hockey stick” of digitalization is here. Enterprises that previously took a more traditional approach to their strategy are now employing chief digital officers to redefine their business models for the digital world. “Analogue” business models find themselves under massive pressure to change.

Our answer for our customers to the digital change is SAP S/4HANA. As the digital core, it enables the modular integration of digital practices that are evolving around the core, while rethinking back- and mid-office processes to cope with the new reality. As with all digitalization approaches, the quality of the proven business semantic is retained, maximum automation and scalability is achieved, the consumption model is massively simplified, and completely new areas and sources of value are generated.

At SAPPHIRE NOW this year it was all about SAP S/4HANA - whether on the show floor, in keynotes or 1:1 meetings with customers and analysts. In my strategic talk, I highlighted that with digitalization the number of transactions will rise enormously and at the same time the value of these transactions is decreasing. As one of the consequences of digital transformation this challenges existing IT landscapes. In my session I summarized how companies or organizations can master these challenges. Enjoy watching.

Overview     

To support data extraction while using SAP S/4HANA system as source, with current version (SAP S/4HANA on-premise 1511 FPS02), both options are available as listed below:

1) SAP BW (Business Warehouse) DataSources

2) ABAP CDS (Core Data Service)-based VDMs (Virtual Data Models)

This blog aims to explain these 2 options including how-to-find guidance, but will not go into details of SAP BW DataSources, ABAP CDS, or S/4 HANA Embedded Analytics, etc.

SAP S/4HANA data extraction with SAP BW DataSources

Customers are able to extract data from SAP S/4HANA 1511 to their own BW-Hub using the BW extractors delivered by SAP. In some areas, extractors have been deprecated or can no longer be used with SAP S/4HANA 1511. The extractors related to deprecated functionality, or Add-ons etc. that due to S/4HANA simplification will not be available after conversion, and accordingly the downstream ETL, modeling, queries will be also affected. Meanwhile, customers are able to simplify traditional BI, and utilize S/4HANA embedded analytics for instant insight-to-action operational reporting. Please refer to the general restriction Note 2214213 for SAP S/4HANA 1511. There, in Section 12, restriction Notes of multiple areas are listed which contain the list of no longer available BW extractors.

DataSource adjustments might be required to comply with changed Scope and data structures within SAP S/4HANA 1511. This needs to be verified on customer-specific basis. For example, in SAP S/4HANA the material number was extended from 18 to 40 characters for moving SAP DIMP to core. After the upgrade to SAP S/4HANA all DataSources in the source system are deactivated. Thus the metadata of the DataSources must be replicated to the central SAP BW system again (TA RSA1). Consequentially the persistency tables in the SAP BW staging area are extended to 40 characters.

For very basic scenarios, the S/4HANA database interface layer of NetWeaver redirects all extractor related SELECTs to compatibility views (proxy objects are in place for objects like MKPF, etc.), which retrieves the same data based on the new data model (ACDOCA, MATDOC, and also backup tables like xxxx_BCK, etc.) e.g.:

SAP S/4HANA, on-premise edition 1511 FPS02 Simplification List:

http://help.sap.com/s4hana -> SAP S/4HANA, on-premise edition 1511 FPS02 -> Simplification List

SAP S/4HANA, on-premise edition 1511: Restriction Note:

http://service.sap.com/sap/support/notes/2214213

How to check available DataSources in the system:

SAP S/4HANA CDS based data extraction

The analytics programming model of SAP S/4HANA is based on Core Data Services (CDS) views and the accordingly provided semantic layer Virtual Data Model (VDM). The virtual data model is also used for transactional or search uses cases and aims to fulfill on-premise and on-demand qualities. A complete Analytics solution also requires data extraction capabilities to support scenarios such as central EDW, Data-as-a-Service (DaaS), Mobile Offline apps, and offline Analytics like with Lumira Desktop. The CDS views provided with the virtual data model can also be used as basis for data extraction.

CDS views for data extraction shall be annotated with “@Analytics.dataExtraction.enabled: true”.

dataExtraction.enabled– Full data extraction is enabled.

Via this indicator the application marks those Entities that are suitable for data extraction. This ability is typically lost on the level of consumption views where joins, procedures and aggregations “blur” the relation to the primary data (especially data replication including calculated elements leads to wrong query results in the target system). To avoid additional data modeling outside VDM for the data provisioning scenarios, a logical sub-layer in the CDS reuse layer should be redundancy-free, but still complete from the business perspective. For each reuse view which is part of this core layer, it is decided from a technical (performance, ...) and semantic perspective, whether it can be also released for extraction use cases mentioned above. All views with an analytical data category of #FACT, #DIMENSION, #TEXT, #HIERARCHY are also suitable for data extraction.

ABAP CDS in ABAP Dictionary - HELP SAP Documentation:

http://help.sap.com/abapdocu_750/en/index.htm-> ABAP - Keyword Documentation→  ABAP - Dictionary→  ABAP CDS in ABAP Dictionary

How to check if a CDS based VDM is enabled for extraction?

With the name of an existing CDS View or S/4HANA ‘eliminated’ table, several approaches could be used to check the detailed DDL definition of the (underlying) CDS View. From there the dataExtraction.enabled property can be checked further.

An overview of useable approaches according to the type of object could be found in the below table. Detailed explanation follows afterwards.

1. General CDS views

Option 1: Via Report RUTDDLSSHOW2

Run the report RUTDDLSSHOW2 via transaction SE38, entering the CDS View name, e.g. BSAD.

The DDL definition of this CDS object is returned directly in the SAPGUI.

Option 2: Via ADT Search function

Launch ADT (ABAP Development Tools) and search with this CDS View name directly in it. (Window > show view > Search). Then you can double click on the object showed in the search result area to open the definition, and the search normally takes longer time compared to other approaches.

Option 3: Via Transaction SE11 redirecting to ADT

For general CDS view objects including analytical data category of #FACT, etc., the fastest way is to just open the CDS view in Transaction SE11 with object name (e.g. BSAD -> name of the DDL source is e.g. BSAD_DDL as in the field below).

Double click on the name of the DDL source in SE11 -> double click on the ADT Link -> CDS Editor will be opened in ADT directly, showing the DDL definition of this DDL Source.

Some additional information here:

The CDS View can also be displayed in a graphical way by using content menu “Open With Graphical Editor”:

The object package hierarchy can be found under Attribute tab in the view definition (SE11).

2. S/4 HANA ‘ELIMINATED TABLES WITH PROXY OBJECT’ (e.g. MKPF)

The 'eliminated' tables of the SAP ERP 6.0 world do still exist in S/4HANA as DDIC definition as well as database object. For compatibility reasons there are CDS views assigned as proxy objects to all those tables ensuring each read access. Each read access to one of the tables will get redirected in the database interface layer of NetWeaver to the assigned CDS view. The details should be checked in the 'SAP S/4HANA, on-premise edition 1511 FPS02 Simplification List', as well.

To find the DDL definition of these objects, first of all, you need to get the names of the Proxy Object.

Open Transaction SE11 and display the table via object name e.g. MKPF.

If the table has been ‘eliminated’ in S/4HANA like MKPF, we can get the name of the assigned proxy object via Menu Extras -> “Proxy Object…”. (Refer to below for simplification list: http://help.sap.com/s4hana -> SAP S/4HANA, on-premise edition 1511 FPS02 -> Simplification List)

You can check the detailed DDL definition by using report RUTDDLSSHOW2 or ADT search function as described in previous section “1. General CDS Views” Option 1 and 2, using the proxy object name as the input.

How to perform BW extraction from S/4HANA CDS based VDMs?

SAP BW is able to consolidate data from different source systems and provide a harmonized view for reporting. For this SAP BW supports various tools and concepts, e.g. different staging areas and data sources for each system that needs to be integrated into the central reporting.

Option 1: BW extraction from S/4HANA basing on CDS views

With this option, the ETL procedure is to extract data from SAP S/4HANA to SAP BW via a dedicated ODP (Operational Data Provider) source system type as below:

For each CDS View in the source system, there is a corresponding Open ODS View in BW. After data source creation, with this Open ODS View, you can directly consume the definition of the CDS in the source system. The ODP name of the source object is exactly the name of the CDS view you were looking at in the source system. This gives you the possibility to have one interface on the source system side for direct access in the source system, and for data provisioning from the source into BW as well.

Option 2: BW extraction from S/4HANA basing on CDS underlying technical database views:

The other way around, is to integrate the underlying database views of the CDS views. Below typical scenarios can be referenced:

    a) Via SDA, virtual access

          Load data from S/4HANA into BW via SDA

    2) Via ODP and SLT, real time replication

          Please refer to the following Wiki page on SCN:

          SLT | ODP based Real-time Replication

          SAP Note 2037476 - Operational Data Provisioning with SAP LT Replication Server:

          http://service.sap.com/sap/support/notes/2037476

          For this scenario, view must contain key fields of original table, per SAP Note "1958809 - Installation/Upgrade SLT - DMIS 2011 SP6 / DMIS 2010 SP10":

          http://service.sap.com/sap/support/notes/1958809

Thank you for reading!

Gavin Huang

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.

I recently wrote how I go about Appending MARA (adding custom fields) (in S/4HANA and elsewhere)- as this is kind of the prequel to this blog, you probably want to read it.

Now lets do something a little more complicated: Appending MBEW!

SE11, MBEW, Navigate to EMBEW, Append Structure….

Create an append, in it create an include with a dummy field.

Activate the include;

Activate the append.

But what is this? We get an error when activating the append!

Here’s the error:

In SE11 everything looks just fine: the table is active, our field is there:

But we had the error on activation, and we also can see that there’s a problem in the application e.g. when trying to call MEBW in SE16n, we get a dump:

So, what is to do now?

Note 2242679 kind of helps us on that topic, it tells us to create an EXTEND VIEW

But actually, I had to create as many as 4 extend views, just to get that 1 dummy field working (display it in SE16n) in MBEW:

extend view mbv_mbew_ext

extend view Mbv_Mbew_Basis

extend view mbv_mbew_case

extend view mbv_mbew

(I also noticed, that in the first two I had to give the tablename MBEW.[Fieldname], while in the last two just [Fieldname] worked ).

I did NOT have to use report NSDM_PROXY_SUBSTITUTION – after I created the 4 append-views, SE16n is working, and when checking MBEW in SE11 I get “No inconsistencies found” -> just like it should be.

Conclusion:

This really was a lot of work to do, just to add one filed – on the positive side, I think it hepled my understaning of the CDS-paradigm and how it is used in the S/4HANA data model a little.

Smal sidenote:

For appending MARC you just need 1 extend view, but there you do utilize report NSDM_PROXY_SUBSTITUTION. Maybe I write more about that some other day.

Have you already appended some tables or structures, and found strange behavior? Let us know about it!

Best

Joachim