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.

...

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

All the useful documents (templates, tests, cutover) are available in folder:

Exemple of dataflow overview :

Usage information

Technical flow. No user usage, only IT.

Dataflow overview

Image Added

Image Added

Image Added

Image AddedTemplate Application name DataFlow

Functional and Technical rules on Workbench + Reporting

Rules & Explanations

Dependencies with other applications

Data loadings

Info providers and objects loaded

Loading frequency

Average performance

...

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.Image Added

• 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.
  Image Added
  
  
• 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:

1. CCA migration in SAP sources systems
2. Full reload for all the CCA related BW Master data
3. 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"
4. 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
5. 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

Loading frequency

None → One shot reload during CCA migration

...

Record Keeping

Reporting

Queries End User Documentation

Main queries

Main functionalities

Broadcast

Maintenance

Known bugs

Recurring procedure

...