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.
Technical flow. No user usage, only IT.
Dataflow overview
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:
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"
Please find the CCA BW Migration - Cutover plan used on 20/11/2023 :
The main steps are the following:
Data change can be check with the query BW_QRY_MVFIAR01_0001.
Detail of process chain, list + link between or special event done for the loading
Detail of frequency : monthly; weekly or else
if possible, give some information on average process chain duration, amount of data loaded and total data volume example: daily process chain loaded in 30 min, weekly chain loaded in 1h15, with around 2k to 10k lines in DELTA mode for a total of 10M lines in cube. The purpose is to give a general overview of the volume of data managed y the application
| 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 |
Give details if any historisation is done, example: keep only data greater than beginning of Y-3
Query end user documentation should be created in the public "Customer Support Wiki" space under the corresponding BW application page : BW - Application. Technical query query documentation, if necessary should be added as a sub-page of this documentation using the BW Technical Query Documentation template.
List the most important and complex queries only with a link to the documentation
Give detail on all complex functionalities: list most important and/or complex KPI, query jump, alerts
Indicate if there are broadcasts and give some details on the broadcast settings.
Give the list and explanation on the known, not-solved, bugs.
List recurring procedures
Detail planned major evolution if already known. Example: complete decommissioning of application is planned in 2017 / Extension to solvay perimeter planned in 2nd semester of 2016