The new wiki link for this data flow is here:
Please update the doc there and no longer here.
This flow allows to calculate the Cash key figures in the Project Costs Reporting and CAPEX analysis application. It corresponds to the paid amounts on WBS Elements, calculated according to BFC CAPEX definition.
The assignement of FI AP (vendor) entries to WBSE is performed in BW (and/or datasource exit in ECC) according to the assignment on counterpart P&L entries in the same FI document.
Dataflow:
https://drive.google.com/file/d/1YIKhlwaaXyXb16yFnwIM3n-ycxOgHLbouGUqNxr7Z2Q/view
FIWC relevant rules for Project Costs (cf. FIWC documentation: https://wiki.solvay.com/x/ZqA_AQ) :
Net due date management (FIAP) (R1)
Reclassification of Sub-Activity C_SUBACT2 (R1)
FIAP Split (R1)
Additional determination of WBS Element by look-up in P&L items (R2)
Net of Tax amounts calculation (Solvay)
WBS element determination according to the PM orders (R3):
Solvay / Rhodia :
Only line items that could be linked to WBS elements are updated in the target DSO.
Net Due Date Determination (FIGL-AP)(R6):
The net due date is obtained by look up in DSO DSO_PBDT (resp. DPFIAP05 for Solvay) on the doc date and the payment term.
All payment dates are calculated in the datasource DTS_TERMSPAY_CALENDAR and extracted into BW in DSO DSO_PBDT.
Deletion of existing lines in the DSO DBFIPA* (R3):
As the WBS element is part of the key of the DSO, if, for any reason (change in PM order settlement rules for instance), the determined WBS element for an accounting document item has changed, the key on the old WBS element still remain and a new key is created which would lead to false result and duplicated amounts.
In consequence, before to update a document item in the DSO, when the WBSE is derived from the PM order, the existing lines on this document item in the DSO are deleted by creating new entries in the datapackage with recordmode = "D". Actually, existing lines are always deleted in Solvay flows even when the WBSE was already filled in DBFIAP* DSO, but this deletion could be limited (as it is done in RCS flow) to the lines where the WBSE is initial and will be derived from the PM order.
In FIAP flows, an accounting document item can be split by several characteristics and in FIGL Rhodia, a document item can be split by profit center. If not all the lines of a document item are processed in the same datapackage, only the keys in the last source package would remain. To avoid that problem, a "Semantic Group" is defined in the DTP to ensure that all lines of a document item are processed in the same datapackage (it also implies that all lines of a same document item must be change at the same time in the source DSO).
=> in consequence, in case of historical data recovery using this transformation, avoid to filter on a split criteria that could lead to not reload the complete FI line item (for instance, if a line item is split on 3 different WBS elements, to not filter on one WBSe, else, the complete line item will be deleted in the target but only the part of the line item with the filtered WBSe will be updated).
In an FIAP delta loading, deletion and recreation of all lines on the document item is done on the source DSO, so it is impossible that not all lines on the same document item are loaded on the same delta request.
For Rhodia FIAP factoring flow (DBFIPA08): not all the lines on the document item are deleted before update but only the lines on the exact key (except the WBSE which could be redetermined in the transformation). As the WBSE is determined from the PM order settlements rules if not already filled, we delete all the lines on the PM order. We put in error stack entries at a finer level than the FI document item, which means not all the lines concerning a document item could be reprocessed in the same error package, so it is necessary to not delete all the lines at each load (or manage to put all entries for a same doc item in the error stack). The semantic group is defined in consequence.
Net Of Tax amounts calculation (Rhodia) (R4):
For Rhodia (DBFIAP01 → DBFIPA02):
Net of Tax amounts (K_NOTXLC and K_NOTXDC) corresponds to the sum of the amounts of the non "K" items on the accounting document that are affected to the same Purchage Order item (even if empty), same WBS element and CO order.
This is done by a look up in the DSO ODSFIGL3. For residual payments (FI_REBZT = "V" or "Z"), the Net of Tax amounts are obtained from the reference invoice (inv_doc_no) : NoT of the residual payment = NoT amounts of the inv_doc_no * ( including tax amounts of the residual payment / including tax amounts of the inv_doc_no) => except if it is a residual payment of a residual payment (there are some existing case), because it would be even more complex, we decided to not apply this exception rule.
Net Of Tax amounts can be correctly determined only if the FIAP item is split by PO item. As the Rhodia FIAP split by PO item was done in 2016 and that FI documents before 2013 were archived in WP1, Net Of Tax amounts can't be calculated for year < 2013. In consequence, it was chosen to update Net of Tax amounts with the including tax amounts (Net of Tax amounts = Incl. tax amounts) for year <2013.
For Rhodia factoring (DBFIAP05 → DBFIPA08):
Net of Tax amounts are calculated according to the original FI document item.
The original FI document item is read in DSO DBFIPA02 using the factoring contract number.
As the original document item is split similarly to the CICC document item, we find the equivalent for each line on the FI document item, calculate the Net of Tax rate of the original document lines and apply it to the CICC amounts : CICC NoT amounts = CICC amounts * ( original NoT amounts / original amounts )
Clearing date review for Korean Payment Card (Rhodia) (R5)
In Project Costs reporting, an invoice is considered as paid at the time of the clearing date.
Korean Payment Card (KPC) is a payment method with specific posting schema (on Payables side):
the invoice is cleared by a debt transfer posting (document type = "ZP") but it should be considered as paid at the time of the debt transfer clearing by a payment posting.
Example:
In a transformation from DSO DBFIPA02 to itself, for all documents (<> "ZP") that are cleared by a "ZP" document, a look up is done in the clearing document in DSO DBFIAP01. The initial clearing date is changed to the clearing date of the clearing document item with CGS code (sp_gl_ind) = "B". A "FULL" load is needed as the invoice is not updated when the ZP document is cleared.
Only documents from Rhodia source system are concerned.
Error stacks :
Rhodia (DBFIAP01 → DBFIPA02):
An error stack is updated when the document can’t be found in FIGL DSO ODSFIGL3, which means that the Net of Tax amounts calculation could not have been done. For residual payments, the error stack is updated when the reference invoice can't be found in FIGL DSO.
Documents updated in the error stack are NOT updated in the target DSO => if this behaviour has to be changed, be careful about the factoring flow (DBFIAP05 → DBFIPA08) which put entries in error stack when the original document is not found in DBFIPA02, maybe a delta should be generated to reprocess corresponding factoring documents when the NoT amounts are finally calculated.
The error stack is reprocessed at every loads.
To not forget that when we delete an error DTP request in a target, it will clear the entire error stack, so we should also delete all the "normal" DTP requests that brought the data into the error stack or manually reprocessed the entries that were into the error stack.
Entries should normally not stay more than once into the error stack else, something must be wrong and an analysis must be done.
Rhodia factoring (DBFIAP05 → DBFIPA08):
An error stack is updated when there is no correspondance in DSO DBFIPA02, which means that the Net of Tax amounts calculation could not have been done.
Only new images (recordmode "" or "N") are put into the error stack because for other recordmodes, it can correspond to keys that do not exist anymore and it would stay permanently in the error stack.
Documents updated in the error stack are also updated in the target DSO.
The error stack is reprocessed at every loads.
To not forget that when we delete an error DTP request in a target, it will clear the entire error stack, so we should also delete all the "normal" DTP requests that brought the data into the error stack or manually reprocessed the entries that were into the error stack.
Entries should normally not stay more than once into the error stack else, something must be wrong and an analysis must be done.
Process Chain | Code | Type | Frequency | Comments |
|---|---|---|---|---|
| FIPA: TD - Rhodia (Payables AP + GL) | PC_FIPA_01 | SLAVE |
|
|
| FIPA: TD - Solvay (Payables AP + GL) | PC_FIPA_02 | SLAVE |
|
|
| FIPA: TD - Acetow (Payables AP + GL) | PC_FIPA_03 | SLAVE |
|
|
daily
Key Figure | Estimation |
|---|---|
| ~ Average Process Chain Runtime | RCS = 20min Solvay = 10min Acetow = 5min |
| ~ Average nb of rows loaded per load | |
| ~ Total nb of rows loaded (if full) | |
| ~ Average Runtime for 10k lines |
All records