General presentation
Objective of the application
In context of the Credit Control Area migration done in SAP by using the standard program RFDKLI20, it was necessary to create a dedicated mechanism to migrate data in BW.
Indeed, the CCA migration ran in WP1/PF1/PI1 thanks to the standard SAP program RFDKLI20, does not generate any change logs / any timestamp update on the SAP side.
Therefore, these changes are not catched by the data sources in delta mode, especially 0FI_AR_4.
The following solution has been designed to reprocess data directly in BW to update the FI documents with the new CCA value, based on data extractions from SAP.
Usage information
Technical flow. No user usage, only IT.
Dataflow overview
Functional and Technical rules on Workbench + Reporting
Rules & Explanations
The idea if the BW process for CCA migration is to force the new CCA value (exple: "SYEN" instead of "SOLV") in the FIAR propagation layers (DPFIAR01/02/03) only for the documents migrated in SAP.
To do so:
- The new aDSO AAFIAR01 "FIAR: Control Credit Area migration - FF" has been created with key 0LOGSYS/C_COMPCDE/0FISCYEAR/0FISCVARNT/0AC_DOC_NO/0ITEM_NUM.
AAFIAR01 is updated using new Datasource DTS_FIAR_CCA_01 with flat files including the list of WP1/PF1/PI1 migrated documents at item level.
- Dedicated recursive transformations have been created in order to force the new CCA values in 0C_CTR_AREA in Propagation DSOs DPFIAR01/2/3 for the entries listed in the aDSO AAFIAR01.
In the start routine, only the entries that matches with the entries in AAFIAR01 are kept in the Source Package. Then, the CCA value is retrieved in the field routine.
- As this is a one shot reload, and in order to optimize as much as possible the update process by reducing the volume of processed entries: the FULL mode DTPs needs to be filtered C_COMPCDE & 0FISCYEAR.
Factoring process specificities
Actually, in the Credit Management solution, in the case of factored documents (almost all PI1 entries), the CCA in reporting is not the one of the PI1 company, but the one of the origin (WP1 or PF1) company.
In other words, despite we run the PI1 migrated entries, they are still reported as SOLV (old CCA value) and not as SYEN (new CCA value) in WBP: the reason is that, in case of factoring, the origin WP1/PF1 documents are cleared, meaning that they have been excluded from the SAP migration process.
Notice that this specificity has nothing to do with the BW workaround itself: we would be exactly in the same situation even if we would recollect all the data from SAP, or if we would trigger a delta thanks to an SAP workaround.
The factoring process, which is quite specific and tricky.
To handle the CCA migration properly for these kind of document:
The idea is to consider in BW not the PI1 documents themselves, but the corresponding WP1/PF1 origin documents we have in the ZZF_BSEG tables (see in BW DPFIWC03 and DPFIWC01/02), thanks to the Factoring contract number which is a unique key linking the docs.
For ex. PI1 migrated doc 4044 / 5000528926 / 2022 => Factoring Contract 2006387090 => PF1 not migrated doc 3384 / 6111090349 / 2022 => This is also what we would have to migrate in BW
Therefore, additional extracts and consolidations in Excel are required to complete the list of documents to be reprocessed in BW.
These steps are detailed in the following document, in sheet "HOW TO Identify WP1 & PF1 posting to be retreated"
Full BW procedure, main steps
Please find the CCA BW Migration - Cutover plan used on 20/11/2023 :
The main steps are the following:
- CCA migration in SAP sources systems
- Full reload for all the CCA related BW Master data
- Extraction of the migrated document list from SAP source systems:
- From the BSID table in PF1, WP1 and PI1 : file example
- For the BW Factoring Process, proceed with the dedicated steps detailled in sheet "HOW TO Identify WP1 & PF1 posting to be retreated" - 1. Load the flat files into DSO AAFIAR01 "FIAR: Control Credit Area migration - FF"
2. Configure the DTPs filters for recursive reload on FI Propagation layers DPFIAR01/2/3 - Check data change and wait for the next Applicative Batch: the process chains will populate the changes to upward dataflow.
Data change can be check with the query BW_QRY_MVFIAR01_0001.
Data loadings
Info providers and objects loaded
Loading frequency
Average performance
| Key Figure | Estimation |
|---|---|
| ~ Average Process Chain Runtime | |
| ~ Average nb of rows loaded per load | |
| ~ Total nb of rows loaded (if full) | |
| ~ Average Runtime for 10k lines |