With SAP S/4HANA Release 1909 (FPS1 and FPS2) new features & functionalities are added to the scope. Most of them focuses on third Party system connections (Non SAP source) but also some more related to Initial Load.
Here is the high level view and as we move on we will discuss the components in detail.
- Third Party system support for Payment & clearing processes
With 1909 is the source system is Non-SAP, the clearing information is transferred from Non-SAP to SAP S/4HANA system via SLT. The below items are part of the change:
- Complete clearing of one/Multiple invoice(s) with one payment
- Clearing of partial payments/Down payments for one invoice
- Handling and update of residual items
- Update of withholding tax of original invoice
- Reverse document and reset clearing
- Clearing several invoices by payment with discount
- Clearing by credit memo
New structure is added to SLT staging tables:
- DEBITITM and CREDITM (invoice that needs to be cleared)
- CLRITM (clearing item)
- CLRWHT (withholding tax)
It is managed via SLT where additional table is created /1LT/CF_E_CLRITM – clearing items which contains below fields
|ITEMNO_ACC||Line Item Number of Accounting Document|
|DOC_LINE_NO||Line Item Number Within Accounting Document in Source System|
|OPEN_ITEM_DOC_NO||Document Number of open Item Document in Sender System|
|OPEN_ITEM_FISCAL_YEAR||Fiscal Year of open item in Sender System|
|OPEN_ITEM_ITEMNO_ACC||Item Number of open item document in Sender System|
|OPEN_ITEM_DOC_LINE_NO||Item Number of open item document in Sender System|
|SPECIAL_LEDGER_INDICATOR||Special G/L Indicator|
In the third-party interface the clearing information is stored in the clearing item table CLRITM in the fields CLEARING_DATA and INVOICE_REFERENCE.
- If multiple invoices are processed in one payment then all open items which are cleared by this payment in the clearing item table CLRITM must be added
- Both the clearing item table CLRITM and the field CLEARING_DATA on header level are filled then the clearing process is triggered
- For partial payment the fields INVOICE_REFERENCE and INVOICE_REFERENCE_ITEM must be filled with the document number and the line item number of the invoice for which partial payments were made.
- Third Party system interface – CO-PA Data
To quickly give a snapshot, SAP focusses on Account-based COPA, which is now Margin Analysis. This is the concept of SAP itself but at the end its management reporting and is done irrespective of the systems so this should not be limited to SAP systems. Considering this now the non-SAP systems data is also supported starting 1909 release.
When an FI document is posted into the Central Finance system, a profitability segment is generated (PAOBJNR in ACDOCA table). The profitability segment number (PAOBJNR) as well as values for all relevant characteristics are written into the ACDOCA table. The replication of CO-PA data is integrated into existing message handling. Also important to note that key & value mapping is supported in CO-PA data.
Profitability analysis in Universal Journal is based on attributes from finance and logistics (e.g. customer, product, sales area)
It is managed via SLT where additional table is created /1LT/CF_E_COPA – clearing items which contains below fields
|FIELDNAME||Fieldname of CO-PA Criteria|
|VALUE||Value of CO-PA Criteria|
|MATERIAL_NO||Value of CO-PA Criteria Material|
- Third Party system interface – Group currency Data
In the organization, the Group Currency will be generally one but there may be many ERP systems may be a combination of SAP ECC and Non-ECC, so in a way the group Currency data should be consistent.
In SAP S/4HANA systems, FI documents can be posted not only in local currency, but also in group currency. This enables reporting on group currency level. In 1909 release Financial documents from a third-party system can be replicated containing group currency information as well as amounts in group currency. As a prerequisite the group currency must be maintained on client level in the Central Finance system
- Changes to Initial Load – Below issues are resolved
- Original Document Split
- Replication of Profit Centre & trading partner replication during balance load when source system is on classic G/L and on target side its new G/L
- Replication of documents from non leading ledger are taken over with the fiscal year variant from the leading ledger and documents which are relevant for non leading ledgers were wrongly selected by the initial load when the leading & non-leading ledger have different FY variant.
Some additional changes related to Material cost estimate replication & activity rate replication are added. Feel free to check those changes. CLICK HERE