Roadmap to SAP S/4HANA – A Strategy and Approach

.

Introduction

SAP introduced S/4 in 2015, termed as Simplified 4th generation ERP Business Suite. This is a major milestone in SAP’s ERP product evolution from R/2, R/3, ECC to S/4. SAP reimagined all the processes with simplification and digitalization at the core and usage of the latest innovations in speed of data processing, such as in-memory database – HANA, machine learning, and web based & user-friendly GUI, such as Fiori. Two software versions are the going forward strategy for SAP – S/4 Cloud version with a quarterly release cycle and S/4 on-premise version with a yearly upgrade cycle.

Companies with SAP as their ERP backbone for business are at a stage of looking into how to approach an S/4 upgrade or S/4 implementation. This document outlines a strategy and approach for their S/4 Roadmap.

Business Case

Comprehensive Business Case preparation is required for justifying the investment for an S/4 upgrade. Current in-flight projects, their importance, and relevance for Organizational Strategy would have influence on the priority of an S/4 upgrade / implementation project. A true value assessment with process and technical elements would provide a plan for capital budgeting for the organizational initiative. Once the justification is established, the next logical questions are “when” and “how”.

  • Ownership: Business Leadership or IT Leadership are the key decision makers who impact the overall strategy. While IT leadership has insight into technological advances, business leadership is the true justifier of the investment.
  • Business Environment for Changes: Some organizations are early adopters of new innovations and others wait for the new offerings to mature. Early adoption induces some risks along with quick benefits.
    • Examples: Companies who implemented Simple Finance early on had to undergo one more round of upgrade to S/4. Three versions of S/4 – 1511, 1610, and 1709. Business risk can be avoided if timing is correctly determined.
  • Time – How long of a wait to upgrade? Systems are constantly changing. There is no perfect period for an upgrade as new versions evolve with time. The easiest upgrade is to go from the previous person to the next. If organizations wait too long, support costs escalate and future upgrade costs increase as well.

Strategy and Roadmap

While considering the most appropriate path for your organization for transition to SAP S/4HANA, there are two important decisions that must be made:

  • What version will you choose? Answer to this question sometimes obvious – latest version, but questions such as whether Cloud or On-premise
    • One of our Greenfield implementation started with 1511 version but had to go-live with 1610, because it is timing of the overall project determines which version. At the time of go-live, latest version was 1709 but project had to freeze to a 1610, otherwise the project go-live was at risk
  • What is your approach to transition? It is always first choice to choose the version with a provision to go for latest and then choose approach for implementation. Following options need to be evaluated
    1. Greenfield Implementation. This is the new implementation of S/4HANA into which data from a legacy ERP system is migrated. This is natural choice for new SAP customers. Some of the existing Customers also adopt this approach to bury the shortcomings of their existing customization and adopt new innovations. This can be called as “Clean Implementation”.
    2. Brownfield Implementation. This option is available for on-premise versions 1511 onwards and transition of existing – ECC, Business Suite on HANA, Simple Finance to S/4. Whether this is cost effective or not depends on the current systems’ custom code and integration with 3rd party systems and solutions.
    3. Central Finance. If companies want quick benefits for consolidating their finance transactional process on existing ECC, Business Suite systems, Central Finance scenarios provide quick benefits of S/4 and not having to immediately implement S/4 for their legacy systems. This scenario may be best suitable for companies with a heterogeneous system landscape and having different versions in different systems
    4. Landscape Transformation. Companies with large scale user base with different regions, multiple source systems must go with different approach. These organizations may opt for consolidating all systems into single S/4HANA instance and go with transition to S/4 plans and may also adopt some mixed approach of greenfield and brownfield, as suitable for their source systems.

Current Business Systems Assessment

Most organizations are confident about their understanding of their current system landscape. In reality, business systems, integrations and processes evolve over a period and they remain more complex than they are visible. Different versions of software, heavy customization, organizational silos add complexity to current evaluation your current business system landscape. A systematic assessment your current business systems and their process inventory would help the true estimation of an S/4 project cost while also minimizing the business risk of disruption of technologies.

Strategy Towards Cloud Solutions

Cloud applications – such as Concur, Coupa, Salesforce and Workday – have become common and standard cloud solutions. While undertaking a major project towards SAP S/4, it is important to investigate your business process portfolio and make an appropriate assessment whether to switch any applications from traditional ERP to cloud based solutions. As a common example, companies using SAP HR modules in ECC are now considering either going for SAP’s cloud-based tool, SuccessFactors, or Workday. Since there are significant benefits for cloud applications and less maintenance, this decision has greater impact on overall strategy.

S/4 Assessment

Upgrading to S/4 is a significant investment in terms of resources, time, and cost for organizations. Performing a Business Value Assessment would provide insight into technological changes and impacts on business process changes. Looking into current landscape of business systems, their level of software versions and integrations is a prerequisite for successful adoption of S/4. SAP provides a simplification list in S/4 and provides details on how different elements changed.

Simplifications are categorized into the following based on the type of impact they have. Analyzing the simplification provides inputs into the overall roadmap and strategy on whether to go for a greenfield or brownfield implementation.

  • Re-architecting SAP HANA in-memory platform: Applications are now optimized with new capabilities of SAP HANA as SAP HANA provides new database structures.
    • Example: Single Universal Journal table is provided for accounting, which eliminates data storage in multiple tables and reduces the financial closing cycles.
    • Embedded Planning functions are some of the new business functions.
  • Consolidation of existing functionalities: Underlying technical details changed, but, from an end-user perspective, the functionality remains the same.
    • Example: Order-to-Cash functionality remains the same though the underlying tables for material documents have changed.
  • No functional equivalent: There are some business processes eliminated from ECC. SAP provides alternative options, such as providing cloud solutions.

Simplifications Analysis provides a view whether the organization is ready for an S/4 migration or not. If some processes used extensively in your current system is not available in S/4, it may not be the right time to upgrade unless alternative options are evaluated.

S/4 Conversion Components

For a conversion to be successful, the source system, custom code, and target system (simplifications) must be analyzed. During your analysis, you may come to realize that your custom code must be remediated. SAP suggests multiple iterations of testing until the system is ready for production. SAP provides various resources regarding this.

  • System Conversion Guide: A PDF document with required technical elements to be considered and list of notes
  • Simplification List: A PDF document and also available as a web-based tool.
  • Migration Roadmap Viewer: An interactive tool that gives clear visual view of migration activities

SAP S/4HANA System Conversion

SAP Readiness Check for SAP HANA is a new cloud-based tool provided by SAP to perform Simplification item checks, custom code, recommended Fiori apps, and other compatibility comparisons/checks. SAP provides an ABAP report, which is an available check to be performed on systems 1709 and onwards.

SAP Readiness Check for SAP S/4HANA

System readiness check for HANA (cloud-based tool) provides a graphical view of different elements of custom code and other components.

SAP Readiness Check for SAP S/4HANA

SAP S/4HANA Readiness Analysis

Custom Code has to be adopted after conducting checks against Simplification Database and remediate whether a specific custom code is needed. If functionality is changed, it needs to be evaluated from a functional process perspective whether this code is required to be adopted or dropped completely.

SAP S/4HANA Custom Code Remediation

SAP S/4HANA Technical Conversion

SAP S/4HANA – A Paradigm Shift and Your Journey

SAP S/4HANA simplifies many of the technical data models discussed above and best utilizes the in-memory database, which contribute to speed and design thinking. As the technology landscape continue to change with cloud, big data, machine learning, robotic process automation (RPA), and process bots, business processes need an ERP system to support these technological advances. SAP S/4HANA provides these desired technological environments for businesses to adopt.

  • Embedded Analytics – A major technical hurdle for businesses in earlier ERP systems was time lag between transactional data and analytical data. SAP S/4 provides built-in tools for embedded analytics, eliminating the need for data replication as the reporting comes out with real-time data.
  • Reconciled Data – SAP S/4 provides unified data structures and a single table data storage for Finance. There is no need for reconciliation effort. This eliminates the historical issues, such as reconciliation between General Ledger and other reporting ledgers.
  • Role-Based Fiori – Award winning SAP S/4 Fiori is the standard GUI for all SAP products, including SAP Support Portal. This standardization brings the user interface to the next level and is the most business-friendly & natural way to interact with business systems.
  • Intelligent Fiori Apps – Fiori apps, when associated with KPIs, would automatically get updates and visually display key figures on its tiles. For example, Revenue figures can be seen on the dashboard without having to drill down to the application.

 

This blog post is part of GyanSys Solutions Lab’s weekly series titled SAP S/4 1709 Simplification Digest. Come back every Friday for a new post or you can subscribe below to get updated every time a new post is published! Contact us to learn more about changes in SAP S/4 1709 and how it impacts your organization. 

.

Billing Document Request is Available to View Data from External Billing Document Request (EBDR) in SAP S/4 1709

.

Introduction

Billing Document Request, a Factsheets-based Fiori app, was introduced to view billing data generated from the External Billing Document Request (EBDR). This App provides a quick view into all the information available before performing the billing. Initially this app was introduced in SAP S/4 Cloud version 1708, now this App is also made available in SAP S/4 1709 On-Premise Version.

Key Business-Related Information

The billing clerk would be able to access following information on the Billing Document Request, which helps interactions with business partners involved in the end to end billing process.

  • General information
    • Billing date
    • Status
    • Business partners
    • Total amount
  • Reference system that the EBDR data originates from and the associated external reference number
  • Terms and conditions (Incoterms)
  • Individual billing items contained in the EBDR – You can branch directly to material details
  • Business partners – You can display contact details for the sold-to party, bill-to party, and payer
  • Accounting information
  • Pricing elements
  • Tax information
  • Texts attached to the EBDR (originating from external system)

Billing Document Request

External Billing Document Request (EBDR) Process

Omni channel approach for billing is to present one single invoice for all types of divergent billing processes. For the customer, it is one interface and eliminates reconciliation overhead. For the organization, it reduces the customer service requests and always deals with a single source of billing information.

As subscription models are maturing, diverse types of billing requirements are also emerging. Three types of billing requirements are very common now:

  • One-time billing – this is traditional billing and used for any kind of delivery based sales
  • Subscription billing – Some form of this billing is recurring, and they are also based on usage of data. Billing for data center and cloud services usage invokes usage based subscription billing
  • Recurring billing – Project related milestone billing is one form of recurring billing

When it comes to billing and invoicing, customer expects single Invoice instead of receiving multiple invoices for different services. SAP provides External Billing Document Request (EBDR) solution for convergent billing options.

SAP S/4 1709 Billing Document Flowchart

Business Process Steps

  1. Receive External Billing Information
  2. Validate and reprocess Idoc errors
  3. Create External Billing Document Requests
  4. Manage EBDR
  5. Attach missing documentation or other information
  6. Run Billing Due list
  7. Verify Billing Due list picks of Documents from ERP system as well as EBDR documents
  8. Create Billing Document – Convergent Billing
  9. Generate Invoice document to be sent
  10. Validate Accounting postings for Receivables
  11. Validate Revenue Recognition postings

Technical Information on Billing Document Request

SAP S/4 1709 Billing Document Request Table

Key Benefits

  • Single Integrated View of Billing Data
  • Reduces Overhead of Reconciliation between different types of invoices
  • Solution Centric, Subscription, and Recurring Billing are supported out of the box with these new features

 

This blog post is part of GyanSys Solutions Lab’s weekly series titled SAP S/4 1709 Simplification Digest. Come back every Friday for a new post or you can subscribe below to get updated every time a new post is published! Contact us to learn more about changes in SAP S/4 1709 and how it impacts your organization. 

.

Key Features and Missing Functions of Central Finance (FI-CF) in S/4 On-Premise 1709

.

Introduction

Central Finance (FI-CF) is a S/4 HANA system facilitates connections to non-S/4 ERP systems and replicates transactional postings from these source systems. As of  version on premise 1709, only finance postings at General Ledger level completely replicate and some limited functionality is added for Accounts Payable and Accounts Receivables processes. Central Finance System (CFS) provides new Business Use Cases and is aimed at a framework to standardize and rationalize financial posting logic at Central system.

First introduced in SAP S/4 1503 on premise edition, Central Finance has undergone significant changes over past two years. As of on premise 1709, Central Finance is further enhanced to support Central Payment, Central Tax Reporting and 3rd party system process integration.

Is CF a Standalone System?

No. CFS is not a standalone system. CFS solution is part of the finance suite with a separate license with in SAP S/4HANA system. By default, CFS is not activated and business function FINS_CFIN activation enables this functionality and provides necessary configuration, process and error handling nodes in S/4HANA system.

It is a complete S/4HANA system that includes logistics components such as MM, SD, PP, and so on, along with Finance modules – GL, AP, AR, Asset and Controlling modules – CCA, PS, and Profitability Analysis.

Landscape Scenarios for S/4HANA with Central Finance (FI-CF)

Almost every customer system landscape and business process requirements would be unique and result in that many combinations of options to consider for S/4HANA with CFS.

Common landscape scenarios:

  • Only enable CFS in S/4HANA system and integrate all legacy systems
  • Implement S/4HANA with logistics and finance for one location and integrate all other ERP systems to CFS
  • Implement all legacy SAP system in S/4HANA and non-SAP systems replication to CFS
  • Implement MDG for master data mapping for CFS and implement replication with legacy

Consolidate only related company codes and replicate Finance for standardized reporting and harmonized data.

CFS Only Landscape Scenario

Systems Landscape for Central Finance Transactions

As CFS provides non-disruptive way of experiencing new innovations in in-memory HANA® based system, roadmap assessment projects should consider CFS part of their S/4HANA migration strategy.

Business Process in Central Finance (FI-CF) System

  • Data Mapping – it is initial mapping as well as on going mapping of master data finance objects such as GL Accounts, Cost Centers, Profit Centers with legacy transactional systems
  • MDG Data Mapping – if CFS is implemented along with MDG landscape, mapping is performed part of MDG tool and reflected in CFS through standard interface
  • Maintain Master Data – CF system needs all master data elements needed to be created and provide the information for mapping
  • Error Handling – SAP Application Interface Framework(AIF) component is used for analyzing replication errors. Correcting errors reprocessing errors and deleting error lines are some common business processes
  • Deletion of Replication Documents – CFS provides tools to delete documents which are replicated from FI-CF system. Deleting single document or a set of documents is possible
  • Reconciliation – Financial postings from different systems need to be reconciled on regular basis with appropriate checks to make CF system for system records for Financials
  • Comparison Reports – CFS provides specific reports to compare journal header line item reports of GL accounts and they can be used for reconciling the central system with feeder systems
    • Central Finance: Comparison of FI Document Headers
    • Central Finance: Comparison of FI Balances
    • Central Finance: Comparison of FI Line Items
    • Central Finance: Comparison of CO Document Headers
    • Central Finance: Comparison of CO Balances
    • Central Finance: Comparison of CO Line Items
  • Initial Load – Initial Load is a complex and critical process. This is a one-time process, but would be an on-going process as new locations are rolled into replication landscape
  • Open Item Replication – from latest versions of S/4HANA, open items from source system are replicated with open, cleared status. This enables S/4HANA to handle Central Payments
  • Cross Company Code and Document Splitting – If document splitting is activated in CFS then all company codes which are part of splitting need to be transferred. Line item reports have to be run for cross company code reconciliation
  • Handling of Reversal of documents in SAP – not all documents in CFS can be reversed. Special steps need to be followed in reversals
  • Central Tax Reporting – from 1709 version onwards, tax reporting can be performed from CFS. Sales tax calculations, are still not possible for source system sales and purchases. However, GL line items carry tax information for reporting purposes. This reporting is still evolving as of 1709 and lot of restrictions apply
  • Central Payments – from 1709 version Central Payment system is enabled and open items can be applied in Central System. This brings considerable value. As of this articles’ publication, a lot of restrictions still exist and needs careful consideration to make productive use
    • Single Euro Payment Area (SEPA) also can be implemented part of payments

Limitations of Central Finance (FI-CF) System (Missing Functions)

  • Fixed Assets – Fixed Assets lines in source system are not replicated into Fixed Assets in CFS. Asset and Depreciation journals in source system do replicate in CFS, but as General Ledger entries only
  • Special Purpose Ledger – If source system has SPL part of their process landscape and having special ledger reporting, these postings are not replicated in CFS. Special process requirements need to be assessed to achieve these specific requirements
  • CO-PCA – if CO-PCA is implemented in source system and if there are internal postings for stock movements in profit center valuation, they are not replicated in CFS system
  • Sales Orders as Cost Objects – If source system line items are posted with Sales Orders (generally in COPA with Make to Order scenario), Sales Orders are not replicated into CFS. A unique set of Internal Orders may be mapped to this scenario
  • Settlement Rules – Settlement rules in source system are not replicated in CFS
  • Accounts Payable – Open Items replication from source system to CFS needs SAP notes to be implemented
  • Accounts Receivable – Open Items replication from source system to CFS needs SAP notes to be implemented
  • Tax Reporting – Even though tax reporting is available as of on premise 1709, many restrictions exist and this process can not be used for productive purpose as of now
  • Document Reversals – Some restrictions apply for reversing the documents in central system
  • Profitability Analysis(COPA) – Profitability Analysis implementation in Central Finance is based completely on different model than previous version to S/4. Account Based COPA is the new preferred version and all line items are posted into the universal journal. Source system Costing based CO line items are not replicated into Central Finance System
  • Functional Area – Functional Area derivation is not supported in CFS system
  • Special GL transactions – Transactions such as down payments, bills of payment, and noted items are not replicated into Central System
  • Parking Documents – Documents parked in source system are not replicated into Central System

FI-CF system is an innovation from SAP to support non-disruptive adoption of S/4HANA. Since its inception, CFS gone through rapid changes to accommodate different requirements from customers. It is expected, all limitations would be crossed to make CFS the standard model for harmonization and standardization.

 

This blog post is part of GyanSys Solutions Lab’s weekly series titled SAP S/4 1709 Simplification Digest. Come back every Friday for a new post or you can subscribe below to get updated every time a new post is published! Contact us to learn more about changes in SAP S/4 1709 and how it impacts your organization. 

.

Upload Journal Entries Now Available in SAP S/4 On-Premise Version 1709

.

Overview

Over the years, those who worked in SAP General Ledger are very familiar with the two shortcomings of SAP GL in core Financials. One being, the famous (almost notorious) “999” line item limitation for journal entry and the other – missing standard functionality of General Ledger Upload. Both these functions need a programming change – were part of RICEF listing – Enhancement for “999” limit and Interface for GL upload. SAP did solve one of these two issues – “Fiori App” – Upload General Journal Entries has been released for uploading Journal Entries, eliminating the need for “Enhancement” or external tools such as “Winshuttle Journal Upload”. The “999” line limit will be a topic for subsequent blog posts from GyanSys’ Solutions Lab. This GyanSys Digest will focus on “Simplification” around Upload Journal Entries.

Journal Entry Business Process

Most journals are posted automatically from other integrated modules in SAP. Inventory Movements, Customer Invoicing, Vendor Invoicing, Production Activities update General Ledger at real time. While this integration is in built, General Ledger Accountants need to make large set of Journals at month end for Accrual Posting, Recurring Postings or Journals from non-SAP systems. Until now, there is no SAP standard or simplified upload process. It has been given practice to either use an external tool – such as “Z Option”, Winshuttle or Custom Interface wrapper around SAP Standard BAPI.  With SAP S/4 version 1709 onwards, this upload functions are made available for General Ledger Entries.

Upload Journal Entries Process

For posting Journals through this upload program, two Fiori Apps need to be used. Fiori App – Post General Journal Entries posts the Journals in the system and Fiori App Upload General Journal Entries actually uploads the data and keeps ready for posting app.

Post General Journal Entries App has been available from initial SAP S/4 versions. However it has undergone changes in 1709 to accommodate the Upload App. The following illustration provides end-to-end flow of the General Ledger Upload:

GL Upload flow_GyanSys

Business Process Steps

  1. Download a Template File from Fiori App – Upload General Journal Entries
  2. Template files can have different formats – csv or excel files
  3. Prepare the data header and line items for multiple journals
  4. Upload the data into Fiori App – Upload General Journal Entries
  5. Identify Errors and identify Batch ID for the file
  6. Correct Errors based on the respective error type – expected common errors
    1. Missing Cost Centers
    2. Missing Internal Orders or other Cost Objects
    3. Issues regarding field status for different GL Accounts
    4. Missing GL Accounts at company code level etc.,
  7. Once the Upload data is all in correct status, prepare for post
  8. Invoke Fiori App – Post Journal Entries
  9. Validate Journal Postings in either backend system or use display accounting journal app

Key Features of the General Journal

Following key features are available:

  1. Templates are ready to be used
  2. View logs by Batch ID
  3. Data upload into Multiple GAAP Ledgers – USGAAP and Local GAAP
  4. Search posted journal entries by data range
  5. Reprocess the file multiple times before actually posting journals

Technical Information

Name Upload General Journal Entries Post General Journal Entries
Available 1709 Version Onwards SAP S/4 HANA 1709

SAP S/4 HANA 1610 FSP02

SAP S/4 HANA 1610 FSP01

SAP S/4 HANA 1610

SAP S/4 HANA 1511 FSP02

SAP S/4 HANA 1511 FSP01

SAP S/4 HANA 1511

Available Backend SAP S/4 On-Premise

SAP S/4 Cloud

SAP S/4 On-Premise

SAP S/4 Cloud

SAP Business Suite on HANA

App ID F2548 F0718

Functional Limitations

Following limitations have been identified:

  • Only supports Desktop Device Types
  • Accounts Payable (A/P) not supported GL lines
  • Accounts Receivables (A/R) not supported
  • Posting Journals to Fixed Assets directly not supported
  • Attachment functionality not yet integrated
  • Not available for old versions, it is nice to have for other versions of S/4 system

Key System Benefits

  • Out of the box functionality for Journal Upload
  • Error processing is extremely simplified in comparison with other options
  • Journal Processing is highly in General Ledger Accountant role and eliminates unnecessary need for IT role in the process
  • Can be used for eliminating any kind of file interfaces as file processing simplified
  • simply get the file into format and process
  • Native integration with all General Ledger Fiori Apps

 

This blog post is part of GyanSys Solutions Lab’s weekly series titled SAP S/4 1709 Simplification Digest. Come back every Friday for a new post or you can subscribe below to get updated every time a new post is published! Contact us to learn more about changes in SAP S/4 1709 and how it impacts your organization. 

.

Integration of SAP Digital Payment Add-On and SAP S/4 On-Premise Version 1709

.

Overview

SAP released SAP Digital Payment Add-On for integrating SAP Applications for Digital Payments. This Add-On is part of FSCM functional area and available as “Cloud Application” (SAP-FSCM-HCP-DP) and can be subscribed as SaaS based solution. Initially SAP natively integrated this Digital Payment Add-on with all SAP Cloud Applications including SAP S/4 Cloud Version.

From SAP S/4 On-Premise 1709, SAP Digital Payments Add-On is Integrated, and which provides native integration to Digital Payments Innovations.

System Architecture

Payment Service Providers need to be set up in Digital Payment Add-On with respective adaptor and digital payment related requests would be routed to respective PSP. Fiori Apps are provided on Digital Payment Add-On to perform core setup. At S/4 On-Premise Application side, RFC Destination and Application Configuration must be complete to enable the Digital Payment Functionality.

Technical Configuration in S/4 On-Premise System

Following Integration settings need to be completed to connect – SAP system with SAP Digital Payment Add-On. Two RFC connections must be made in SM59

  • RFC destination: DIGITALPAYMENTS_OAUTH
  • RFC destination: DIGITALPAYMENTS
RFC1
RFC Destination DIGITALPAYMENTS_OAUTH
Connection Type G SAP S/4 Digital Payment Add-On is an external Cloud Application
Host **** Get from Basis Team
Port 443 Default
Path Prefix /oauth/token
User *** One user Per System if SAP Digital Payment Add-On is used by more than one System
Password *** As provided by admin
RFC2
RFC Destination DIGITALPAYMENTS
Connection Type G SAP S/4 Digital Payment Add-On is an external Cloud Application
Host **** Get from Basis Team
Port 443 Default
Path Prefix /core/v1/ For 1709 purpose
Path Prefix /core/ Future Versions higher than 1709
SPRO > SAP Digital Payment Add-On > Activation

Functional Configuration

Some of the configuration elements do not change from previous version

  • Basic Settings
  • Business Partner Synchronization
  • Settings in SAP SD Billing
  • Credit Card Payment Advise Notes (Bank Recon)
  • Clearing Account Posting Rules
  • Virtual Bank
  • Tax Code Settings for Bank Charges
  • SAP Digital Payment Add-On

SPRO > Cross-Application Components > Payment Cards >  Basic Settings > Maintenance of payment type

Payment Type Description Digital Payments
DP01 Visa X
DP02 Master Card X
DP03 American Express X
DP04 Discover X
All types of credit cards which would be allowed by Business need to be set up here and SAP Digital Payment Add-On – Router for respective Payment Service Provider

SPRO > Cross-Application Components > Payment Cards > Basic Settings > Maintenance of Payment Category

Payment Type Description
01 Credit Card
02 Direct Debit (ACH)
03 Business to Business Payments
Only Credit Card is Available now. In future other types of services are expected from SAP Digital Payments

Following Credit Card Checking Rules Not relevant in 1709 if Digital Payments Add-On is used, as the Credit Card Checks would be performed in SAP Digital Payment Add-On

  • American Express Checking Rule BUP_CCARD_CHECK_AMEX
  • VISA Checking Rule BUP_CCARD_CHECK_VISA
  • MasterCard Checking Rule BUP_CCARD_CHECK_MC
  • Diners Club Checking Rule BUP_CCARD_CHECK_DINERS

End-to-End Credit Card Integration Processes

 

Key System Benefits

  • Centralized configuration for Digital Payments
  • Cloud and on-premise Applications can access same Digital Payment Application
  • SAP Customer Digital Payments is natively integrated for Cloud Applications
  • Other expense solutions such as Paymetrics ( Software as well as Consulting) not required

 

This blog post is part of a weekly series titled SAP S/4 1709 Simplification Digest. Come back every Friday for a new post or you can subscribe below to get updated every time a new post is published! Contact us to learn more about changes in SAP S/4 1709 and how it impacts your organization. 

.

New Logic for SAP COPA Segment Number Determination

.

Current COPA Segment Determination Logic

All Business Process such as Sales Order, Invoice, Journal Entry, COPA Direct posting and Plan values, derive COPA Segment based on a unique combination of characteristic values. If new values encountered, the system creates a new segment number in CE4xxxx table and assigns the segment number to line items. Different tables for two types COPA modules – Account Based and Costing Based would use this unique segment number for storing the actuals or plan values. From S/4 1511 version onwards, Account Based COPA is designed to store values in Universal Journal table – ACDOCA and simplified the COPA reconciliation between “General Ledger Accounting” and Profitability Analysis.

While elimination of CO tables simplified reporting for Account Based COPA, the table access for CE4xxxx table was performed by multiple business processes.

Issues with COPA Segment Determination and Storage Logic

Following issues were identified in above solution of using same segment numbers for multiple business processes.

  • Performance Issues: Every business process needs to check the table CE4XXXX to determine whether new “Segment” is needed. This impacts system performance significantly and counter productive to simplification drive by SAP Solutions
  • Summarization Issues: Characteristic summarization process is invoked on to table CE4XXXX such that information sometimes gets lost unexpectedly in a business process if a characteristic is summarized.

Simplification Solution in SAP S/4 1709 (On-Premise and Cloud)

SAP changed the logic of assigning the Segment Number. New Table is created CE4XXX_ACCT and segment numbers are uniquely generated in this table by respective business process. No summarization is applied to CE4XXXX_ACCT table.

Business Processes not covered by Simplification

Following Business Processes still use CE4XXXX and do not use the segment number created in new table CE4XXXX_ACCT

  • Costing Based COPA – this type of COPA is not in SAP’s target architecture and still uses CE4XXXX table for storing “Segment Number”
  • Cost Center Allocations
  • Top Down Distribution
  • Classic COPA Planning (KEPM)

Impact existing data on 1610 and Previous Versions

Custom programs which are reading the table CE4XXXX directly needs to be further analyzed to see whether ACDOCA table can be used for data retrieval.

SAP automatically redirecting the data of COEP ( old account based ) to ACDOCA table. SAP standard functionality 1709 is storing all segment data in ACDOCA table.

This blog post is part of a weekly series titled SAP S/4 1709 Simplification Digest. Come back every Friday for a new post or you can subscribe below to get updated every time a new post is published! Contact us to learn more about changes in SAP S/4 1709 and how it impacts your organization. 

.