domingo, 23 de fevereiro de 2020

Different views on what is Central Finance

Objectives

What is Central Finance? That question has been coming up a lot. The term Central Finance is used in different context and the meaning usually depends on the context. This can lead to different understandings and expectations. Many times I also get questions like “Can I do this or that in Central Finance?” I think it is important to know what can be meant when someone talks about Central Finance. That is why in this blog I will try to answer typical questions around Central Finance. I will share my views on the different meanings of Central Finance and give you more insights into:
  • Is Central Finance a system, a product or a solution?
  • Is Central Finance a transition scenario to SAP S/4HANA?
  • What is Central Finance in a nutshell.

Different views on Central Finance

Central Finance as a system

Let me start with a commonly used short description: SAP S/4HANA for central finance foundation (also known simply as “Central Finance”) is a S/4HANA system installed as side-car, receiving financial accounting transactions via real-time replication from SAP or non-SAP ERP source systems. So in this context Central Finance is a S/4HANA system.

Central Finance as a product

From a product point of view the software solution Central Finance is more than a S/4HANA system. It is based on S/4HANA but it comes additionally with a set of enabling technologies (like logging, replication, mapping, posting, error correction and reconciliation) and uses SLT, MDG, AIF and ALE/IDOC. It also requires minimal adaptions on source side to technically enable the source system to be connected to Central Finance. (More details I will explain later.)
Centrally deployed ERP systems for Finance have been around for a long time. Central Finance allows you to run one central platform for corporate finance across distributed landscapes. It is explicitly designed for the needs of enterprises that have multiple ERP systems in their landscape, as well as a central finance and controlling department serving all business divisions. The capabilities of the solution make it a perfect fit for a divisional setup with operational finance on the divisional level, and central financial reporting and consolidation on the corporate level. [source: Mapping Your Journey to SAP S/4HANA – A Practical Guide for Senior IT Leadership]

Central Finance as a solution

While reporting is a key value driver, the Central Finance software solution evolved from a pure advanced financial reporting system to a central transformation platform where you can execute financial processes centrally. As Central Finance is running on S/4HANA, it allows any enterprise, SAP or not, to start using S/4HANA Finance innovations. Thus, Central Finance provides a transformation platform for the digital business. In this context Central Finance is often referred as solution, that is based on the Central Finance product and includes also complimentary functionalities of S/4HANA and maybe complementary software solutions like:
  • SAP Advanced Compliance Reporting (ACR) for statutory reporting,
  • SAP Group Reporting for Consolidation,
  • SAP Credit Management,
  • SAP Collections Management,
  • SAP Dispute Management,
  • SAP Cash Management,
  • SAP Analytics Cloud (SAC) for planning and/or analytics,
  • SAP Cash Application that provides intelligence based on machine learning for your invoice and payment matching process,
  • SAP Intelligent Robotic Process Automation that can automatically replicate tedious actions that have no added value
  • and many more.
In a nutshell the picture illustrates the views of Central Finance as explained above:
  • SAP S/4HANA as the system where Central Finance is running,
  • SAP S/4HANA for central finance foundation (aka Central Finance) as a product, that is based on SAP S/4HANA and comes with additional functionalities and
  • Central Finance Solution that covers additional aspects and the full scope for a Central Platform for Corporate Finance.
As the Central Finance system is a complete S/4HANA system, it can also be used to run business processes, including logistics (MM, SD, PP, etc.) for company codes that are native to the system (eg Company Code 0002). You can replicate financial postings from source systems into the Central Finance system for some company codes (eg Company Code 0001) and also run your normal business processes for other company codes that originate in your S/4HANA system, all within the same client (SAP Note 2184567, question #33). This scenario is illustrated in the following picture and shows only one possible scenario for a process split.
There are also other possible scenarios how you can split processes in Central Finance. In the end the design of your business processes depending on your business requirements makes your specific Central Finance Solution. Of course it is recommended to do a proper analysis and evaluation which business processes can and/or should be run for which company codes in Central Finance and/or in the source systems only.

Central Finance as a transition scenario to SAP S/4HANA

Central Finance is one important implementation approach towards an SAP S/4HANA-based digital core. Companies looking for a Central Finance platform can start with SAP S/4HANA for central finance foundation and plan the system conversions of each of the source SAP ERP instances later on. In this typical scenario you can transition with Central Finance to a centralized SAP S/4HANA with minimal disruption to your current system landscape.
In such a scenario Central Finance can be a “first stepping stone” in a transition to SAP S/4HANA, but not just in any landscape. As already mentioned, Central Finance is explicitly designed to run one central platform for corporate finance across distributed landscapes. Companies with a single SAP ERP instance should first focus on the standard transition scenarios to SAP S/4HANA:
  • System conversion
  • New implementation
  • Selective data transitions
A transition with Central Finance to S/4HANA requires proper diligence and it is important to understand the capabilities and limitations in Central Finance (e.g see SAP Note 2184567, questions #7,10,12,13,14 and 35). For the SAP S/4HANA transition options a practical guide is available: Mapping Your Journey to SAP S/4HANA – A Practical Guide for Senior IT Leadership.

What is Central Finance in a nutshell

This was a quick overview and introduction to Central Finance. Let’s have a look into the capabilities of the software solution in more detail. For further details I recommend the SAP Help and the FAQ note for finding answers for Frequently Asked Questions on Central Finance:
I strongly recommend to have a look into this Central Finance FAQ note. The note is updated regularly and provides information about:
  • Central Finance and its licensing
  • Functionalities in scope and limitations
  • Administrator’s Guide for Central Finance in S/4HANA
  • Required tools and many “How to” questions are addressed

System landscape

As already said, SAP S/4HANA for central finance foundation is architecturally a new S/4HANA system receiving financial accounting transactions via real-time replication from SAP or non-SAP ERP source systems. Some source releases are supported out-of-the-box – others require additional effort – see SAP Note 2184567, question #5. For third-party system integration see SAP Note 2462424.
The graphic shows a simplified overview of Central Finance from a system landscape view. In a typical set-up, multiple source systems are connected to one SAP System Landscape Transformation (SLT) Replication Server which is connected to one Central Finance S/4HANA system ( SAP Help – Central Finance System Landscape).
The SAP S/4HANA Central Finance system receives financial accounting transactions via real-time replication from SAP or non-SAP ERP systems with a set of enabling technologies, mainly:
  • Initial Data load (for historical data migration) and simulation
  • Data Logging (SAP source systems)
  • Real-time Replication (SAP SLT)
  • Business Mapping (MDG mapping tables)
  • Inbound posting
  • Error correction with Application Interface Framework (AIF)
  • Data Reconciliation
Central Finance offers integration to Master Data Governance (MDG) to access available mapping information there. You can map your different accounting entities (for example, account, profit center, or cost center) in your source systems to one common set of master data in the central system to establish a common central reporting structure. In order to ensure consistency within the Central Finance system some values could be overwritten although you have mapped them (eg Profit Center or AP/AR reconciliation account, see SAP Note 2184567, question #25).
Even if MDG is not in use, in the background Central Finance uses the MDG mapping tables that are available without installing MDG. Central Finance does not cover the replication of all potentially required master data, but only the replication scenarios mentioned below. The governance and distribution of additional required master data like G/L accounts, cost centers and so on can be done with MDG.
If errors occur during replication, they can be handled with the error handling tool SAP AIF (Application Interface Framework). As of release 1909 the SLT replication processes can also be monitored with Focused Run: Central Finance Operations Monitor with Focused Run

Central Finance functionalities and replication scenarios

The scope of the supported replication scenarios and functionalities increased with each release. Initially only the replication of financial postings (FI and CO documents) and cost objects (orders) were supported. With release 1909 Central Finance supports the following main replication scenarios as illustrated in the picture and summarized below. For a detailed scope and limitations of the replications scenarios including third-party systems as source system see the documentation in SAP Help:
  • Cost Objects 
    • Replication of orders (internal orders, production orders, product cost collectors, service/PM order, QM order, process order)
    • Supported order types: SAP Note 2180924 
    • Changes of orders are also replicated: SAP Note 2184567, question #11
    • Settlement rules are not covered: SAP Note 2184567, question #12
    • Replication of sales orders is not covered (SAP Note 2184567, question #13 and #14)
    • SAP Help: Cost objects mapping
  • FI/CO postings
    • Replication of FI postings including primary CO postings
    • Postings not included see Postings Excluded from Transfer
    • Postings from Accounts Payables (FI-AP) and Accounts Receivables (FI-AR): SAP Note 2184567, question #6
    • Changes to a document (e.g. via transaction FB02) are also replicated: SAP Note 2184567, question #8
    • Postings from fixed asset (FI-AA) from the source system currently post into the General Ledger on the reconciliation account only (SAP Note 2184567, question #7)
  • CO secondary postings
    • Replication of CO postings not coming from FI
    • Supported business transactions: SAP Note 2184567 question #18 and 2103482
    • Replication from costing-based CO-PA in source: SAP Note 2184567, question #17
  • EC-PCA postings (new in 1709 FPS01)
    • Replication of internal EC-PCA postings from classic Profit Center Accounting that do not flow in via FI or CO
    • Internal PCA postings are posted in the Universal Journal into an extension ledger
    • Supported are the following activity types posted with these transactions:
      • PRC5: Profit center document entry (transaction 9KE0, 9KE9 or 1KEL)
      • PCAA: Actual assessment in profit center accounting (transaction 3KE5)
      • PCAD: Actual distribution in profit center accounting (transaction 4KE5)
    • SAP Help: EC-PCA postings from classic Profit Center Accounting
  • Commitment postings (new in 1709 FPS01)
    • Replication of commitments and commitment updates for purchase requisitions and purchase orders (1709 FPS00: SAP Note 2554827)
    • Commitments are also posted in the Universal Journal into an extension ledger
    • SAP Help: Commitment postings
  • Projects (new in 1709 FPS01)
  •  Accounting View of Logistics Information – AVL (new with 1809 and 1909)
    • Central Finance does not include the replication of logistics documents (e.g. Purchase Orders, Sales Orders, Material Documents, Delivery Documents etc.), but only the replication of a subset of certain logistic object data into new accounting view  tables. The following objects are currently in scope of AVL (SAP Note 2184567, question #13):
      • Purchase Order
      • Supplier Invoice
      • Sales Order
      • Customer Invoice
    • Supported fields for each logistics object in the Accounting View of Logistics Information scenario: SAP Note 2184567, question #64
    • SAP Help: Accounting View of Logistics Information (AVL)
  • Activity Rates Replication (new in 1909)
  • Material Cost Estimates (new in 1909)
The following table lists the main entities for the configuration of the replication scenarios in the SAP Landscape Transformation (SLT) Replication Server and the corresponding interfaces in the Application Interface Framework (AIF):
Replication scenarioTableReplication ObjectAIF Interface
Cost ObjectAUFKCFI_AUFK_RCO_OBJ
FI/CO PostingCFIN_ACCHDCFI_ACCHD_RAC_DOC
CO Secondary PostingCOBKCFI_COBK_RCO_DOC
CommitmentsCFIN_CMT_HCFI_CMT_H_RCMT_DOC
Accounting Views – Customer InvoiceVBRKCFI_VBRK_RAV_CI
Accounting Views – Sales OrderVBAKCFI_VBAK_RAC_SO
Accounting Views – Supplier InvoiceRBKPCFI_RBKP_RAV_SI
Accounting Views – Purchase OrderEKKOCFI_PO_EKKO_RAV_PO
Cost Center Activity RateCOSTCFI_COST_RCC_AR
Cost Estimate MaterialKEKOCFI_KEKO_RCE_MAT
ProjectPS_OBJ
There are also other replication objects supported and also required for certain scenarios in Central Finance (eg for central payment):
These core functionalities and provided replication scenarios in Central Finance from a product point of view are an enabler for a Central Platform for Finance. As already mentioned, Central Finance is running on a S/4HANA system and therefore you can also use the available and compatible standard features of S/4HANA. Thus you can benefit from the well-known available innovations in Finance in S/4HANA and of course also from the S/4HANA platform, SAP HANA database and related innovations and technologies, like:
  • Universal Journal, single source of truth
  • Single (same) platform for transactions and analysis
  • Fiori user interaction / digital age user experience
  • Embedded Analytics in SAP S/4HANA
  • S/4HANA Platform (Cloud connectors,…)
  • Intelligent Technologies (AI/ML)
  • Digital boardroom

Conclusion and Outlook

In this blog I explained that a Central Finance solution is more than the Central Finance replications scenarios only. I discussed different views and I hope I could bring some useful insights into what is Central Finance.
The organization of Finance functions is an important topic in a Central Finance scenario and also discussed by Gartner: Finance function redesign starts with centralization decisions.
In my next blog I will therefore focus on central processes in Central Finance, because Central Finance evolved from a pure advanced financial reporting system to a central transformation platform where you can execute financial processes centrally. Thus, the question arises:
Which processes can be executed centrally in Central Finance alternatively or complementary to process execution in source ERP systems?

ABAP CDS VIEWS simplified – PART 1

INTRODUCTION:


ABAP Core Data Service Views also known as ABAP CDS Views. There are so many limitations in SE11 views but we can come out of all the limitations and create a powerful views with the help of ABAP CDS Views.
In general SE11 views and ABAP CDS Views both will create a database views at the backend. When we try to access these views as a table in the ABAP code, this code will be executed at the database level.
Hence, SE11 views and ABAP CDS Views both will implement code push-down, In-spite of this, CDS views has many advantages in CDS views.

Below are the comparison between SE11 views and ABAP CDS Views:
SE11 ViewsCDS Views
1. It can be created from SAPGUI or Eclipse.
2. Calculated column are not possible.
3. Input Parameters are not possible.
4. Only Join is possible.
5. Grouping and aggregation are not possible.
6. Annotations are not possible.
1. It can only be created from Eclipse platform only.
2. Calculated columns are possible.
A. Operator
B. CDS Function
C. CASE Expression D. Aggregated Functions
3. Input parameter are allowed.
A. In calculated Columns
B. For filtering data
4. Join and Union both are possible.
5. Grouping and aggregation are possible.
6. Annotation can be used to provide more metadata information to individual fields and Views.

Basic ABAP CDS View creation:

Below are the prerequisite knowledge required to create a ABAP CDS View:
  1. Creation of ABAP Project
  2. Creation of ABAP Package
  3. ABAP programming
I have already created the ABAP Project and ABAP Package in the HANA Development perspective and below are the screen shot of these object.
  1. ABAP Project
2. ABAP Package

Note: Make sure that you should create a ABAP package inside the ABAP project.

I am demonstrating the ABAP CDS view creation using SPFLI table with all the fields of it.

Step1. Right click on the ABAP Package and select new ABAP repository object and navigate to                   Core Data Services, select the Data Defination and provide a name to CDS view.

Step2 and Step 3. Please provide a suitable name based on your project’s naming                   convention. Click on next and select the Transport request as shown below:
Step 4. Select the template based on your requirement and Click finish. I am selecting Define View template since I am creating a ABAP CDS view with all the fields of Database table SPFLI.
Step5. As soon as you click on the finish, Below code will appears. Please refer the screen shot for explanation.
Step6: Below is the logic for CDS views.

Step7. Activate it and click on data preview option.

Step8. Click on data preview to view the data of this CDS view.

With this example, we have completed the First part of ABAP CDS VIEWS simplified.

Please like and comment on it if you find it helpful.

Argentina Tax Reporting: Import Dispatch Documents in FB01/FB60 Transactions

When you report your financial operations to AFIP (Administración Federal de Ingresos Públicos) in Argentina through the Argentina Tax Reporting (RPFIGLAR_TAXREPORTING) report, the system extracts all the relevant information required by the government and prepares it in an output for you to send it to tax authorities.
One of the required information that is extracted and included in the output files of the Argentina Tax Reporting report are the import dispatch documents that you create for imported goods in FB01 or FB60 transactions.
To make sure you report the correct information in the correct way so that you are compliant with AFIP requirements about import dispatch documents, it’s important that you have your system correctly configured for the data extraction.
To help you on this, we have created the knowledge base article (KBA) 2763445 – Import Dispatch Documents for Argentina. There you find the best practices for creating import dispatch documents in FB01 or FB60 transactions.
For blindsided people to see: The picture shows a screenshot of the SAP system in FB60 transaction.
We hope this KBA is useful for you!
The full documentation of the Argentina Tax Reporting report is in the system. You can access it by choosing the F1 help button. The most updated version of the text is delivered in SAP Note 2809400 – Argentina Tax Reporting (RPFIGLAR_TAXREPORTING): Report Documentation, so make sure you have applied it to your system.
You can also make use of the KBA 2463319 – Argentina’s Reporting Troubleshooting Guide for any questions you might have about the report.
If this post helped you, share the content with your colleagues.
Do you have more doubts about Argentina Tax Reporting? Leave them in the comments below, your question can be the subject of our next post.
See you next time and stay compliant,
Rosana
#SAPGoGlobal #SAPLocalization

sexta-feira, 14 de fevereiro de 2020

SAP Integrated Business Planning Demand Sensing Functionality

Demand planning provides you with several tools to generate forecasts for various scenarios or for specific parts of your business. Using historical data and scientifically based statistical algorithms, it allows you to improve the accuracy of revenue forecasts, align inventory levels with predictable changes in demand, and enhance profitability for a given channel or product.
We are all known about the statistical forecasting process in a standard manner, which means loading the sales data and sales history-cleansing process, finally, execute the statistical forecast methods identify the better forecast error method adopt to business data. This process may vary but an overall goal to achieve a consensus plan, during this process multiple business stakeholders involve like sales, marketing, region and global teams. This process deal with mid-long term planning (12,18,24 months)
Now SAP introduced a demand sensing algorithm to do a better forecast for short-term planning (4-8 Weeks).

What is Demand Sensing?

Demand sensing is a forecasting method that leverages new mathematical techniques and near real-time information to create an accurate forecast of demand, based on the current realities of the supply chain. Gartner, Inc. insight on-demand sensing can be found in its report, “Supply Chain Strategy for Manufacturing Leaders: The Handbook for Becoming Demand Driven.
Traditionally, forecasting accuracy was based on time series techniques that create a forecast based on prior sales history and draws on several years of data to provide insights into predictable seasonal patterns. However, past sales are frequently a poor predictor of future sales. Demand sensing is fundamentally different in that it uses a much broader range of demand signals (including current data from the supply chain) and different mathematics to create a more accurate forecast that responds to real-world events such as market shifts, weather changes, natural disasters, consumer buying behavior etc
Demand sensing will support the tactical plan of business needs.

Where Demand Sensing fit in SAP IBP?

Demand sensing is a part of the SAP IBP demand module and it is a very effective impact on business to generate short term forecasts considering multiple inputs.

Who Benefits from Demand Sensing?

Basically, every company that wants to achieve a more accurate short-term demand plan can benefit from Demand Sensing. The use cases are widespread.
Below are some examples, e.g. companies that…
  • Struggle with volatile markets and demand shifts
  • Already applied demand-driven business strategies but want to further improve
  • Capable of adjusting their production plan within a short term horizon and want to further improve on
  • Capable of adjusting their transport plan within a short term horizon and want to further improve on
  • Want to close the gap between a monthly demand planning cycle and daily or weekly demand requirements for the short term horizon

What planning processes does the Demand Sensing impact?

Difference between Demand sensing and normal Statistical Forecasting?

Demand Sensing Proof of Concept Results–Two Examples

Customer who did not have a demand sensing process before

  • Reduction in forecast error across the demand sensing horizon: 18% -49 %
  • Weekly consensus demand forecast error across the demand sensing horizon: 50% -68%

Customer who had a demand sensing process before

  • Reduction in forecast error across the demand sensing horizon: 4% -6%
  • Weekly consensus demand forecast error across the demand sensing horizon: 40% -43%

How to run demand sensing the first time?


Conclusion

SAP Integrated Business Planning Demand Sensing is one of the best application in the market to cover short term forecast planning based on pattern recognition to improves the forecast accuracy and lower the inventory levels.

Additional Documentation

I would very much appreciate your comments and suggestions.
Best Regards,