SAP BLOG R2R Series Blog #6: Build vs Buy – 3rd Party Data Integration for SAP Central Finance

SAP Blog

Kayıtlı Üye
Katılım
22 Ara 2017
Mesajlar
1,925
Tepki puanı
7
Puanları
6
This is Blog #6 in our Record to Report Blog Series. You can find the complete series outlined HERE.

Author: John Hume, Sales Consulting Manager at Magnitude Software

The allure of SAP S/4HANA for central finance for Finance organizations to completely reimagine business processes for the digital age is compelling. There are some significant benefits from Central Finance, and the impact of pulling together all financial information as a single source of truth is strategic and powerful.

In moving forward with your Central Finance implementation, one of the first questions is how to integrate ‘external’ source data. Any company considering Central Finance has certainly done many system integration projects before. At first glance it may seem natural to tackle this project as a typical in-house (or system integrator-led) custom development effort, but with a little consideration, you will see that custom development is fraught with risk!

Capture-23.jpg


A common conclusion amongst companies that have tried to build custom connectors to non-SAP data sources is that IT IS NOT EASY! In fact, in many cases, it has proven to be non-viable.

Let’s look at some of the reasons why:

  • Source System Complexity
  • Multiple Transaction Types
  • Target System (SAP) Evolution
  • Specialized Skills

SOURCE SYSTEM COMPLEXITY

Most companies have multiple source systems (Oracle EBS, JD Edwards, PeopleSoft, Microsoft Dynamics, Infor, and many more). Each requires an automated connector to identify relevant journal entries, extract them, transform them into the required SAP SLT format, and then load them into the SAP SLT staging area for posting into Central Finance. This requires an intimate knowledge of the source system – the physical and logical way transactions are stored in the system, as well as how they are managed and updated over time.

But it doesn’t stop there:

  • Consider that all this may change during source ERP upgrades, requiring new connector rewrites when new releases are implemented.
  • Do you know how to apply CDC (change data capture) on each source system?
  • Do you know how summary and detailed financial postings are handled in each system? (hint: nearly every system is different!)
  • What about how tax information is treated?
  • What about something as seemingly simple as dates? (Hint: Different ERPs actually handle dates differently!)

MULTIPLE TRANSACTION TYPES

To the layman, a journal entry is a journal entry – right? There are a range of journal transaction types that must be supported – from sales invoices to purchase invoices, from materials transactions to transfers, from depreciation to retirement and revaluation, and a whole lot more. Each has its own nuances in how they are recorded and represented in each source system, and each must be correctly mapped into the required SAP format. There are dozens of transaction types that must be understood, developed and tested per source system. And here are a few more even less obvious issues to consider:

  • The maximum document length in SAP is 999 lines, so if you have more, you have to split the document.
  • SAP holds 2 significant figures (digits past the decimal point) which can cause reconciliation errors that must be resolved.
  • Entries must be validated prior to load or risk creating errors in SAP.
  • Balances migration – initial balances must be migrated to set up SAP – non-standard and non-trivial integration task.
  • Tax codes often have to be standardized (max 2 characters in SAP).

TARGET SYSTEM (SAP) EVOLUTION

Central Finance gains new functionality with each release. This means that connectors must change too, in order to deliver the right information in the updated format. But it’s not just change that creates complexity.

  • Here is a sampling of other issues to consider:
  • Voided documents and reversals requires special treatment (due to duplicated document IDs).
  • Credit documents require special treatment.
  • Withholding tax requires special treatment.
  • Maximum document name length of 10 often requires special handling.

SPECIALIZED SKILLS

Clearly, building all this requires specialized skills in multiple areas: integration work, source and target system knowledge, and functional interpretation of the transactions, to name a few. Most companies do not have these skills, and if they do, they already have a job, so cannot be immediately reassigned to this project. New hiring takes time and is of course an additional cost. Even experienced system integrators struggle to assemble the broad set of functional and technical expertise required across all source ERPs, the SAP target ERP, and technologies involved.

CONCLUSION

Developing these integrations is not easy work, and some early companies who tried to do so, found out the hard way that the 4 to 6-month development task that they had anticipated was actually much more – a reality that not only inflated costs, but also pushed out go-live dates. This realization only reaffirmed what these companies already knew – that they didn’t really want to be in the software development business in the first place.

SAP Central Finance Solution Extensions by Magnitude can replace these complex and risky efforts with prebuilt and intelligent software that integrates your source ERPs in a robust manner that drives highest value in your Central Finance deployment. CLICK HERE to compare these Solution Extensions vs. a custom build approach.

Additionally CLICK HERE to access to explore the estimated business benefits for the implementation of SAP Central Finance Transaction Replication by Magnitude.

You can find all blogs available in our Record to Report Blog Series HERE.

Okumaya devam et...
 
Üst