SAP Central Finance is a great product when it comes to financial reporting. Especially where there are multiple productive ERP systems or where legal entities are represented by multiple company codes, it helps tremendously to get a clearer, consolidated picture of what is going on. In short, the productive system remains unchanged and all documents are replicated in real time to the SAP Central Finance (CFIN) system.
I will keep the description short as there are many documents and blogs that describe the benefit of having SAP Central Finance implemented.
However, if you take a closer look at the controlling objects that are available in a standard Central Finance environment, the corresponding list is rather limited, i.e.
- Cost Centers
- Internal Orders
- WBS Elements
- CO-PA Objects.
Since the objects of the Usage View in SAP Real Estate Management (SAP RE) are themselves Cost Objects - despite of Settlement Units which are simply Cost Collectors - one of these buckets must be suitable to reflect the P&L figures in CFIN.
As also stated in SAP Note
2184567 - Central Finance: Frequently Asked Questions (FAQ), question #68 there is no out-of-the-box solution and some BADI coding in the target system is required.
But where to start? The IMKEY field is pretty meaningless and does not help when it comes to reporting CO figures. Ultimately, the question are:
1. What level of detail is required for reporting SAP RE financial data?
Once this question is answered we can concentrate on the next one, i.e.:
2. Which controlling object should be used in the CFIN system instead of the original SAP RE Cost Object?
Preparation
Despite the CO-OM object being used instead of the original RE-FX object, the essential information should be available in the CFIN system. i.e. information about the RE-FX objects themselves.
Nothing is replicated by default, so a new replication object must be created to provide a convenient way of looking up information in SAP Central Finance. A good and concise starting point is the table VICAINTRENO from the source system to get the essential data about the RE-FX cost objects. In addition to that table VISCCC is needed to also have the relevant OBJNR or cost collectors, i.e. settlement units.
Actually, not all the data in table VICAINTRENO is needed. As we are only interested in accounting data, all records where the IMKEY field is initial can be skipped.
Note that while table BSEG uses both the old IMKEY field and the new INTRENO field, COEP, FAGLFLEXA and ACDOCA use the OBJKEY field. For cost collectors, this means that we have to look in VISCCC to find the right INTRENO, which we can use in VICAINTRENO to get the rest of the data.
Of course, in the target CFIN system, the source system must be included as part of the primary key in an appropriate table.
Accounting Object
Anyone familiar with SAP Real Estate Management knows the challenges that time-dependent data may can pose when specifying or designing custom reports.
Speaking of data that is relevant in the given scenario we need to consider the organisational assignment, i.e.
- Business Area
- Functional Area
- Profit Centre.
Depending on your needs additional data can be replicated, for which you need to decide how to solve the time-dependent challenges.
During the lifetime of an object in SAP Real Estate Management this data may change while the object remains the same.
Using Internal Orders
Using customer fields in Master Data
In a simple approach if no information of the hierarchical structure of the usage view of SAP Real Estate Management is required in the CFIN system, using internal orders could be a solution. Of course in the information of the SAP RE structure elements like
- Business Entity
- Building / Land
- Rental Object
- Contract
- Settlement Unit
can be preserved in specific customer fields on the internal order. So only the cost object mapping needs to enhanced to transfer this information to the target internal order as an addition to the master data.
To streamline things, it would make sense to have a dedicated internal order type for objects that originate from SAP RE. You may also want to respect the structure elements such as
Business Entity and
Building from the order type.
Although all tje information is available in the target system, the situation doesn't look so good when it comes to reporting. Since only the internal order number is available in the reported rows, an additional lookup is required to present this information, which if I were the controller, I would insist on having in all reporting on these order types. Adding this as a customer enhancement to each and every report could end up being a pain.
Of course, one could think of using the order number itself to retain some meaningful information about the source object that users can make sense of. However, the AUFNR field only has 12 characters long, while the RECNNR field is already 13 characters long. And looking at objects in the Usage View doesn't make things any better.
Using customer fields in BSEG/ACDOCA
Looking at the database table ACDOCA, all the fields relevant to the accounting of SAP RE are already available, i.e. in the include ACDOC_SI_RE. Therefore they are part of the standard process and should not be used for the purpose given here.
On the other hand, the Universal General Ledger can be extended with customer fields. For a brief overview, see SAP Note
2453614 - FAQ: Universal Journal Extensibility. Staying with internal orders as the accounting objects a good solution is to use the "Journal Entry Item business context" to extend the ACDOCA with custom fields. As of Release S/4HANA 2020, these fields are available not only available in ACDOCA but also in BSEG. However, in order to take advantage of this enhancement different techniques have to be used.
As long as documents are replicated from the source system, everything is set. However, when it comes to manual journals in the CFIN system the above described custom fields described above cannot be entered manually.
“Classic” Coding Block extensibility using OXK3 transaction and CI_COBL structure (only S/4HANA On-Premise)
It may be an old technique, but it does the job of providing the necessary fields at the line item level for real-time reconciliation and manual journal entry. In addition, the relevant fields can be made available for reporting.
What is missing are some validation rules to ensure the fields are properly populated when entering a journal (see also SAP Note
3093515 - Customer defined substitutions and validations during posting of accounting documents/ lin... and
2891508 - Coding Block Validation does not work for all accounts). You may use any technology available in your release, e.g.
- validation in combination with a user exit
- BTE 1011
- BAdI FIN_CODING_BLOCK_VALIDATION.
If you are a S/4HANA Cloud customer you may refer to
SAP S/4HANA Cloud Validation and Substitution rules | SAP Blogs.
Using Margin Analysis
An alternative option you may take into consideration is to use the Margin Analysis formerly known as CO-PA and use the App
Custom Fields and Custom Logic to add the above mentioned SAP RE structure elements as custom characteristics (please also refer to
SAP Central Finance & Margin Analysis (new COPA) | SAP Blogs and
SAP Central Finance & Key Enhancements/Extensibility | SAP Blogs).
Conclusion
As you can see, there is no out-of-the-box solution for integrating SAP Real Estate Management with SAP Central Finance. There are, however, a number of options available to alleviate the situation. My personal favourite is to use the “Classic”
Coding Block extensibility in SAP Central Finance and have dedicated internal order types to reflect the SAP RE structure elements. Which is your favourite?
