What does SAP SD look like in SAP S/4 HANA?

简介: What does SAP SD look like in SAP S/4 HANA? – Changes and simplifications  https://eursap.

What does SAP SD look like in SAP S/4 HANA? – Changes and simplifications 


What does SAP SD look like in SAP S/4 HANA?
In this blog, I shall begin exploring the SAP S/4HANA Line of Business (LoB) that contains what was formerly “Sales & Distribution” and see what this looks like in the new world of S/4HANA.

I will explore:
1) Master data changes
2) Functionality changes
3) Data model simplifications

SAP S/4HANA is formed of 3 key areas:
a) SAP S/4HANA Finance
c) SAP S/4HANA Enterprise Management Logistics, which covers what was ECC 6.x Logistics



1) Master Data Changes

The customer/vendor master will cease to exist in its current form and will be replaced by Business Partner functionality (BuPa). SAP is also planning to remove many of the standard transactions like XD01, XD02, XD03, VD01 etc…This raises a lot of questions:
? What happens to the existing data?
? How do we migrate to the new data structure?
? What other implications does this have?

It is essential to carefully plan your approach when moving to S/4HANA:

Moving to S4HANA

The preparation phase is the all-important phase. This is where the organization needs to spend time & analyse what business value SAP S/4HANA would bring, how the organization should move towards S/4HANA and clearly define their strategy & planning.

The side car or a phased approach is suitable for those that are on ECC6 EHP1 and above. If a client is on version 4.7c or below, it makes more sense to re-implement with S/4HANA. The side car approach is implementing part by part, for example moving just the database to S/4HANA or implementing S/4HANA Finance first and then moving other functional SAP areas to S/4HANA in phases.

While I focus specifically on SD here, there are wider changes in the suite that apply to all modules for example Master data.

Business Partner will be used for centrally managing Master data for business partners, customers, and vendors. With current development, BP is the single point of entry to create, edit, and display Master data for business partners, customers, and vendors.

During the system conversion existing SAP customers have to migrate Supplier and Customer data into the Business Partner using the Customer Vendor Integration.

The SAP simplification list describes the steps to move onto the SAP business partner objects in 4 steps:
? Preparation: Implement pre-checks as per conversion guide & check/clean-up based on the errors this tool gives out
? Synchronization: data load is done via a cockpit and use the standard report given by SAP to check and rectify errors
? Conversion Process must be triggered according to the S/4HANA Conversion guide.
? Post-processing: After the conversion, activate the customer/vendor post processing by referring to the guide

Business Rationale:
There are certain limitations with the current Customer Vendor Master data, not all necessarily apply to all industries/ businesses: Only one single address, No relation between a vendor and a customer for the same real world entity(no role concept), No persons( B2C), No time-dependency.

With Business partner: general data shared across different roles, BP: Roles:: 1: N ( Customer, Vendor, HR personnel etc.), one BP can have multiple addresses, time-dependent object attributes & relationships. CVI Integration component ensures the sync between BP object and customer/vendor objects.

? The existing data structures, tcodes will be phased out and all of the Business Partner data can be found in tables: BUT000, BUT020, BUT* etc.
? DEBMAS/CREMAS etc. Idocs are still supported
? Migration needs to be planned based on notes in the simplification list.
? User training is required on the new transactions and how to use them for the business.
? New role based Fiori apps and required authorizations need to be covered.

2) Functionality Changes

Broad level changes affecting SD are:

SAP S4HANA Sales Solution Simplification

a. Foreign Trade: Currently, there are 2 options to implement International trades: Foreign trade and GTS (Global Trade Services). In the S/4HANA world, SD-FT will be phased out and businesses must use the GTS functionality.

Business rationale: GTS in general has more features for Compliance, Customs and Risk management and some of the limitations with SD-FT/MM-FT are addressed in GTS.
Compliance Management: Sanctioned party list screening, Export & Import legal control
Customs Management: Customs processing, Transit procedures, Trade document printing , Customs communications
Risk Management: Restitution handling & Preference processing


Impact: There is an option to integrate GTS natively in SAP S/4HANA Core or it can be as a separate application / instance. All existing foreign trade business practice/processes/settings need to be analyzed and mapped to GTS.

For Intrastat, businesses can leverage functionality within SAP S/4HANA. For the
Letter of Credit–Legal Control and Preference Management the functionalities based on SAP Global Trade Services (GTS) can be used. SAP GTS can be natively integrated with S/4HANA. Additional functionalities for Import- and Export Management are available with SAP GTS.

b. Credit Management: The traditional FI/SD Credit Management will be phased out in S/4HANA, and we will need to use FSCM.

Business Rationale: The FSCM credit management provides enhanced functionality to improve cash flow through the new FSCM functionalities- Collections management, disputes management, Credit Management. FSCM-CM brings in better control over customers credit scoring with features like managing credit scoring internally, and/or storing credit rating of External Rating companies, Interfacing with Credit Rating Agencies etc. and works in unison with BuPa.

Credit Management

Impact: The business processes have to reconsidered, if the business would like to have business rules + payment history of the customer to define their own scores and credit risk categorization. However, if an organization doesn’t want to re-structure or re-define their existing Credit Management processes- the FSCM-CR can be mapped accordingly.
You need to carry out a migration from FI-AR-CR to FIN-FSCM-CR.
This migration has several elements: configuration data, master data, credit exposure data, credit decision data
àSAP provides tools for support.

c. Rebate Management: is replaced by Settlement management in S4H. Exception: CRM TPM. CRM TPM customers can still use SD Rebate Processing for their business process, but have to adapt to a SAP S/4HANA optimized solution.

Business Benefit:
? Transparency of all documents involved where a contract condition was determined and where accruals were posted, which enables a detailed view on complex settlement scenarios, and an overview of all settlement documents and their financial (FI) status
? Accruals will be cleared at settlement run, Changes of settlement-related conditions will not influence the accruals – Accrual conditions and settlement conditions are different
? Sales related rebates(standard), scan back rebates, Customer funds & some additional processes can be customized

? Existing agreements have to be processed by the end of the validity of the agreement & closed by a new settlement.
? Rebate Index Table VBOX will be phased out.
? Authorizations need to be re-done & training has to be provided on the new transaction codes/process.

Rebate Management x

d. Revenue Recognition: SD-Revenue recognition is not available within S/4HANA. The new functionality SAP Revenue accounting and reporting functionality has to be used instead.

Business Benefit: This functionality supports the new revenue accounting standard as outlined in IFRS & adapted by local GAAPs. Migration to the new solution is required irrespective of whether a business moves to S/4HANA or not.

Implications: Prior to the Conversion to S/4HANA, you need to migrate all sales order and contracts processed by “SD Revenue Recognition” to “SAP Revenue Accounting and Reporting” that are: not fully delivered and invoiced, have deferred revenue still to be realized & for which you expect follow-on activities like increase quantity, create credit memo or cancel invoice. A thorough evaluation is needed to determine if the current SD-revenue recognition can be managed by SAP Revenue accounting and Reporting and that’s a pre-requisite for S/4HANA migration.

e. ATP Check:
Database table simplifications: VBBS containing aggregates has been phased out & code optimized
Advanced ATP replaces ATP: new Back Order Processing functionality and much interactive delivery scheduling.

Business Benefit:
? Production allocation: supports the business decision on which order should be confirmed and decision is based on every attribute of underlying sales order, SKU or customer
? New BOP functionality and new concept for “Winner-Gainer-Loser” based on prioritization.
? New Release for Delivery app: to enable timely actions on short term supply & demand changes