General presentation

Objective of the application

This page provides all the technical and detailed documentation concerning the "FIWC for Solvay Group" (Finance Working Capital) application in BW, including :

• General overview of the dataflow
• Query, Workbook, Webtemplate and broadcasts documentation
• Maintenance operations : necessary manual updates of master data.

This application replaces the former FIWC application which was created for Rhodia legacy (WP1). It was done in WISE project.

Working Capital global definition: The working capital is a financial indicator used to measure the Free Cash Flow of the enterprise.

It is equal to the sum of:

• Value of the stocks
• Value of the customer receivables
• Value of the vendor payables

It excludes:

• Intercompany
• Companies not in consolidation area (consolidation view) - for GBU usage only

Query Technical Names:

• WC vs BFC (Core Query) / BW_QRY_MVFIWC01_0006
• Working Capital - Acct.view (Core Query) / BW_QRY_MVFIWC01_0008
• Working Capital - Detailed (Core Query) / BW_QRY_MVFIWC01_0007
• BW - Working Capital (Core Query) / BW_QRY_MVFIWC01_0002
• BW - Working Capital Detail of WC (Jump) / BW_QRY_MVFIWC03_0001
• BW - Working Capital Inventories (Core Query) / BW_QRY_MVFIWC01_0005
• BW - Working Capital Payables (Core Query) / BW_QRY_MVFIWC01_0004
• BW - Working Capital Receivables (Core Query) / BW_QRY_MVFIWC01_0003

In BFC: 

Every month, persons in each company will get the values from WBP for each account and enter it manually in BFC.

• Values are entered in local currency. BFC then converts to EUR.
• If amounts are not affected to a business unit then they will manually affect the amounts using rules.

Reporting coordinator is ROLLIER, Charlotte

Usage information

Around 220 users have access to WC applications. Those users are worldwide and most of them are controllers.

History

Project done between 2013 and 2015.

Access Management 

Dataflow

MVFIWC01

MVFIWC03

Part 1

Part 2

https://drive.google.com/open?id=1X0aj6n8leT5osUadKx5AWm9Z4OXuh-6CihIEFbuSEjg

Reporting documentation drive folder:

https://drive.google.com/drive/folders/0B_p_Afe8sjVlfmtSWTJGM29Gdms1bmtXYjFzR2ZhOGdKWFZHQzlhWGJIXzV3RlNWS0toSnc

Query documentation folder:

https://drive.google.com/drive/#folders/0B_adX6faolE3OWdFODVnWHRjUXM/0B_fH_eB4PSMwc1ppRXVrVXh0ZXM/0BwtAGBKWM-z-c3ZMaTdXNU5RTTg/0BwfSNqWU_-PsTFJ2VmhqSXUySkE/0BwfSNqWU_-PsQzg5RVJ4VDZ1amc/0BwfSNqWU_-PsR3ZRNVp6dHFJd0E/0BwfSNqWU_-PsUDcwQlNmcktLUWM/0B_p_Afe8sjVlcUhzYkZmMlFtbzQ

Technical rules on Workbench

Rules & Explanations

Systems involved

• Rhodia ERP WP1

• Solvay ERP PF1 (020)

• CICC ERP PI1

• Acetow ERP RHO

• PRS ERP PF1 (050)

• BFC (flat files)

G/L Accounts

We can split the Working Capital in 3 main component (GL Type), which separates in sub-components (GL Sub types). 

G/L Accounts restitution:

Account types and sub types are managed in WP1 and PF1 systems (PF1 and PI1 share GL accounts so no need to load from PI1 system).

For Acetow system, it's managed manually

Consolidation or Accouting view

Working Capital for GBU queries are working in consolidation view, meaning we exclude Intercompany and other filters in restricted key figures also the intergration rate.

Working Capital for Accounting offers with a variable to working in accounting view, without any filters.

Intercompany exclusion

In the queries, we keep only the company with Intercompany flag as X. This flag is determined in PRS source system.

The flag is stated as X for the consolidation methods 10 (IG - Fully consolidated), 30 (IP - Proportionately consolidated) and 55 (ME - Equity method futur IP). The table used is ZZF_T001_MGT.

Business Assignments

For data coming from FIAR, the base is the Sub-Activity 0G_CWWE01. It's a mix of IECRA (WP1 and RHO systems) and Business area (PF1 and PI1). Functionnally speaking IECRA and Business area are similar so we decided to mix it an existing object, 0G_CWWE01.

For data coming from FIGL and FIAP, the base of the business assignment is the Sub-activity 2 C_SUBACT2. It's a mix of Profit center (WP1) and Business area (PF1, PI1 and RHO systems). As Profit center has a compounded key with the controlling area we were not able to use the same info object as for FIAR.

The notion of Profit center exists in PF1/PI1 but for a different usage that accounting. So to avoid data pollution in existing object 0PROFIT_CTR, we decided to create a new info object, C_SUBACT2.

Both info objects give the Business structure with same attributes used for reporting purpose.

Illustration for WP1 system:

For data coming from FIGL, FIAP and MM, the business assignment is done with the Profit center. 

For data coming from FIAR, the base is the IECRA. From the IECRA we then use the Structure axes to define the business structure.

PRS Source system

We load some master data from PRS system (PF1_050).

With this some source system, we can be sure to have an unique code for companies, customers and vendors.

In WP1 and Acetow, the link between ERP and PRS is managed in tables ZZR_T001_MAP (company), KNA1 (customer) and LFA1 (vendor).

For Solvay and CICC, the PRS code is the same than ERP code.

PRS master data are stored in dedicated info objects: C_COMPPRS, C_CUSTPRS and C_VENDPRS.

We also have dedicated info objects from the ERP with the ERP system and code and the PRS attributes: C_COMPCDE, C_CUSTID and C_VENDID.

At the beginning  we used C_COMPPRS, C_CUSTPRS and C_VENDPRS in the info providers in order to use their attributes but due to poor data quality we had too oftenly the case of missing link in the ERP between ERP and PRS codes. That's why we decided to replicate PRS attributes in C_COMPCDE, C_CUSTID and C_VENDID info objects.

Currency conversion

The BW working capital reports are all based on amounts in Local Currency Those amounts come directly from the source systems.

If user selects a currency in the prompt the query will convert, otherwise it will return the values in local currency.

This conversion is based on the ZRHO rate (coming from WP1).

The current available rate s applied to ALL data (even past data) independently of the date.

For base amount we use the Debit/Credit Amount 0DEB_CRE_LC or FIGL/FIAR/FIAP data and the Stock Value for IM data.

We then apply conversion type ZRH2 for Working Capital - CTK_ZRHWC :

• Based on * ate ZRHO* :

• Uses the rate available for date = * revious Day Exit (Working Cap) -* DATEWC00

• We use the target currency from variable * urrency (Single Value, Optional)*- CURVAR01

Full factoring

The new factoring solution for Solvay leads to the transfer of invoices (AP and AR) from the different ERP (WP1, PF1, RHO) to the CICC system without replication in the ERP, so no possibility to follow the payments in the ERP only (documents are cleared in the ERP when transferred to CICC). Reporting needs are to continue to follow these transferred invoices with the same details, such as MM, SD data and GBU for instance, which can't be determined with CICC data only.

Two kind of flows were created from CICC data propagation layer (DPFIAP03):

• the before CAMS project flow (to DBFIAP03) which concerns the documents not assigned to a factoring contract version "2"
  the technical rules are described in "FIAR data flow" and "FIAP data flow" parts
• the "factoring" flows (DBFIAP05 & DBFIAP06), created for CAMS project which concern the documents assigned to a factoring contract version "2"
  the technical rules are described in "FIAR Factoring data flow" and "FIAP Factoring data flow" parts

Full factoring introduced the notion of "Affiliate" and "Legal" objects.

• "Affiliate" corresponds to data issued from the original FI document in ERP (WP1, PF1 or RHO)
• "Legal" corresponds to data issued from the FI document in CICC.

In Working Capital multiproviders, the existing objects are usually identified to the "Affiliate" objects and some new objects where added to enable "legal" reporting. This way, the impact on the reporting was significantly lower than if the existing object for the company code (or other Master Data linked to the source system) was identified to the "Legal" company code.

Some more informations on full factoring (CAMS project): 

https://drive.google.com/open?id=0B2w5MF8sg0HxMzJTRXFVOWZLem8

Technical rules

FIAR data flow

This part of the Working Capital has been done via ITC project. Please check ITC page for more details.

FIAR Factoring data flow

Please check ITC page for more details.

FIAP data flow

FIAP data re also be used for SPRINT (Purchasing), Project costs and CAPEX applications.

Net due date management and Factoring contract number determination:

The net due date is managed at the document item level and is calculated in the ERP. A new net due date managed manually has been set in each system.
It's available in ZZF_BSEG table.

The factoring contract number is also managed at document item level in ZZF_BSEG table.

For each system we created a new data source based on this table and a dedicated DSO (DPFIWC01 to 04).
In BW, there is a direct loading between ZZF_BSEG DSO and Business layer DSO and also a look-up between Propagation and Business layers to read DPFIWC01 to 04 DSO.

Reclassification of Sub-Activity C_SUBACT2:

In the ERP, when a profit center or a business area is set, it's not possible to modify it later.
In order to resolve that issue, mecanisms have been created in the ERP.

In WP1 ODS_FIWC

Documents can be modified in ZWFAT205 table (transaction ZWFAT205).
In the example below, document has been modified with a different profit center:

This table is loaded in DSO_FI11 in BW and data are updated in Business layer DSO.

In PF1 and PI1

In PI1 system, the mecanism is different and is not managed document by document, like in WP1.
It's done in PI1 (for PI1 and PF1) through data source ZZFCM_BU_EXCEPTIONS_NEW.

This table is loaded in DBFIWC01 DSO in BW.

Between Propagation and Business layers, we read this DSO to determine the new business area.

For example, document for company code 0005 and business area 3240, the new business area will be 8500.

Rhodia legacy rules: (TRSF: DPFIAP01 -> DBFIAP01 (Rhodia))

Initial loading was done from existing DSO ODSFIAP1 and not from WP1 system due to archived document not loadable anymore.

A split of data is done between propagation and business DSO (DPFIAP01 and DBFIAP01), in the start routine inside program z_start__dpfiap01__dbfiap01, using the split retrieved in ODS_FIWC .

z_start__dpfiap01__dbfiap01:

• For residual payments, the split is done using ODS_FIWC data on the reference invoice item (inv_doc_no / inv_item) and not data on the FI doc being processed (ac_doc_no) => except when the reference invoice is also a residual payment, in order to simply the flow, a "normal" split is done, based on the residual item and not on the reference invoice (as, to be correct, we would have to split according to the reference invoice of the reference invoice) 

• For merge with DTO (open items in the old company are cleared and an equivalent document is created in the new company. However, FIAP line items on the DTO documents can't be split "normally" has the DTO document itself doesn't contain enough detail), similarly to the residual payments, the split for the DTO documents is done using the original document and original WBSE element. Links between DTO documents and original document are read in the DSO DBFIGL25 (Data comes from WP1 ZZF_DTO_CTR table) and links between WBSE in the old company and the new company are read in the DSO DPFIGL10 (Data comes from WP1 ZZF_DTO_POSID table).

• The data in ODS_FIWC comes from  ZWFAT123 table in WP1 system, which is filled during 0FI_AP_4 extraction. In consequence, ZWFAT123 content must be deleted before 0FI_AP_4 run and data from ZWFAT123 must be extracted into ODS_FIWC after.   

• For down payments (when SP_GL_TT = "A"), except for doc types ZC/ZD, the line items are not split (that means we do not use ODSFIWC to determine the PO number/Item, WBSE, Order, Material, Plant, Order, Cost center, Profit center... but the ones coming from the Data propagation layer).

• An error stack is updated for residual payments when the invoice line item (inv_doc_no / inv_item) can't be found in the source DSO, as the split for the residual payment could not be determined. However, this error should never occur which could mean one of the field inv_doc_no, inv_item or inv_year is not well filled or the data is missing in the Data Propagation layer. In any case, the entry is updated in the target DSO so the DTP request can be set to "green" status until the correction is done and the error stack can then be processed using an "error" DTP.

Solvay legacy rules: TRSF: DPFIAP02 -> DBFIAP02 (Solvay)

A split of data is done between propagation and business DSO (DPFIAP02 and DBFIAP02) but the mecanism and the logic is much more simple.

We split data using DPFIGL02 DSO (FIGL data) and DBFIGL05 DSO (FIGL - AP data) with detail by material, plant, purchase order number / item, WBS element and CO order (except for the downpayments, SP_GL_TT = "A") .

DBFIGL05 look up is used to retrieve CO order / WBS element enhancements done in this DSO.

We calculate the item's quote part in FIGL and apply this quote part on amount from FIAP document. For the last split line, amount is the total amount minus the sum of other split lines.

Net of Tax (NoT) amounts are also calculated between propagation and business DSO:

it corresponds to the amount of counterparts in the same accounting document (non FIAP line items and non tax line items). 

When there are several K items in the document, the split is done according the prorata of the amounts in local currency.
If there is no tax line items in the document => NoT amounts are similar to the including tax amounts.
If the counterparts are only tax items, the NoT amounts are similar to the including tax amounts.

Tax line items are identified by a list of transaction keys. As transaction keys are not filled in the DSO DPFIGL02 before 2013, a list of G/L accounts is used instead to identified tax line items for postings before 2013 (identification by G/L accounts is less perennial than using the transaction keys). 

An special rule is used to determine the Net of Tax amounts for the Down payments: it corresponds to the including tax amounts less the amounts of the tax items with the same sign ("VST" transaction key is used to identify the tax items in that case). Tax items can be cancelled by line items with transaction key "MWS":

Net of Tax amounts for Down payments = Including tax amount (FIAP amounts) - tax amounts (line items amounts with same sign and KTOSL = "VST") - cancellation of tax amounts (line items amounts with opposite sign and KTOSL = "MWS")

For residual payments (FI_REBZT = "V" or "Z"), the split is done according to the invoice (inv_doc_no). The Net of Tax amounts calculation is also done according to the invoice: 

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)

For merge with DTO, similarly to the residual payments, the split and Net of Tax determination for the DTO documents is done according to the original document and original WBSE element. Links between DTO documents and original document are read in the DSO DBFIGL25 (Data comes from WP1 ZZF_DTO_CTR table) and links between WBSE in the old company and the new company are read in the DSO DPFIGL10 (Data comes from WP1 ZZF_DTO_POSID table). 

An error stack is managed in order to reprocess entries when the FI document line item could not be found in DPFIGL02 as the split can't be determined. It maybe a synchronization problem, so it should be fixed during the next run. That is why the delta DTP is using "Update valid records, reporting possible (request green)" mode. However, the error should not occur twice, so the error DTP is set to "Update valid records, no reporting (request red)" in order to be noticed during the PC monitoring. In any case, the entry is updated in the target DSO. 

The error stack is also updated for residual payments, if the invoice line item (inv_doc_no / inv_item) can't be found in the source DSO, as the split and Net of Tax amounts for the residual payment could not be determined.

CICC legacy rules (TRSF: ODSO DPFIAP03 -> ODSO DBFIAP03):

This flow is filtered in DTP to the factoring version <> "2". And in start routine we delete data where company code = 0001 pr 6050.

In some cases, the factoring contract could be assigned later to the FI document line item and the line item could be moved from this flow to the "factoring" flow. Moreover, as the factoring version is determined in the Data Propagation Layer using a secondary transformation, there is always old images of the FI document to are loaded to this flow at the document creation.

That is why a rule in the start routine of the transformation DPFIAP03 -> DBFIAP03 is used to delete entries that should not be in this flow by replacing recordmode "X" by "D". It is done only when the last image of the FI document line item is recordmode "X" (which means that the new image was routed to a "factoring" flow). In consequence, a semantic group is required in the DTP to ensure that all records on the same FI line item are gathered in the same source package.

In consequence, be aware that some entries could be deleted in the DSO DBFIAP03 (and that it has to be taken into account by the solutions based on this DSO).

Acetow legacy rules (TRSF: DPFIAP04 -> DBFIAP04 (Acetow)):

Not loaded since 2019

A split of data is done between propagation and business DSO (DPFIAP04 and DBFIAP04):

We split data using DPFIGL04 DSO (FIGL data) with detail by material, plant, purchase order number / item, WBS element and CO order, for RMRP documents only.

We calculate the item's quote part in FIGL and apply this quote part on amount from FIAP document. For the last split line, amount is the total amount minus the sum of other split lines.

An error stack is managed in order to reprocess entries when the FI document line item could not be found in DPFIGL04 as the split can't be determined. It maybe a synchronization problem, so it should be fixed during the next run. That is why the delta DTP is using "Update valid records, reporting possible (request green)" mode. However, the error should not occur twice, so the error DTP is set to "Update valid records, no reporting (request red)" in order to be noticed during the PC monitoring. In any case, the entry is updated in the target DSO. 

Deletion of existing lines (in the DSO DBFIAP01/02/04):

As a document line item can be split by several criteria, if, for any reason the value of a split criteria has changed  (that may usually not occur), the key on the old value still remain in the DSO 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, the existing lines on this document item in the DSO are deleted by creating new entries in the datapackage with recordmode = "D".

Warning: in transformation to DBFIAP01 (RCS data), some key figures are in "summation" mode. In consequence, in the case, the keys values are changing for a line item, ensure to not load data until the previous request is activated in the DSO, else, it could lead to duplicated amounts (as the second request would try to delete the old key instead of the new one).

Generally, for every transformations with the deletion of existing lines in target DSO, ensure that every load requests are activated in the DSO before to load a new request (in case the key values changed).

Also note that a semantic group is defined in the DTPs in order to process every images of a FI document line item in a same package. It should be kept to ensure every cases are correctly handled. 

FIAP Factoring data flow

https://drive.google.com/open?id=1sWAG-o9nYLzPOKkd4wHgUxR0nNEKcLpQoosRUaCROfA

"Affiliate" and "Legal" InfoObjects:

Factoring flows DSO and cubes use the notion of "Affiliate" and "Legal" objects.

• "Affiliate" fields are identified by the suffix "AF" (for instance, the affiliate company is C_COMPCAF) and correspond to data issued from the original FI document in ERP (WP1, PF1 or RHO)
• "Legal" fields correspond to data issued from the FI document in CICC. It is usually non suffixed objects but when it was necessary to use a new object, it was suffixed by "LG". For instance, in the multicubes, 0LOGSYS and C_COMPCDE are identified to the Affiliate objects C_LGSYSAF and C_COMPCAF, but, as the legal company is also required in the multicube, it was necessary to use new objects C_LGSYSLG and C_COMPCLG for the "legal" objects in the DSO/cube instead of 0LOGSYS and C_COMPCDE.
• "Affiliate" and "Legal" InfoObjects are always in reference to the "normal" InfoObject.
• When we create a "legal" or "Affiliate" Infoobject, all compounded Infoobjects must also be "legal" or "Affiliate" infoobjects. For instance, C_COMPCLG is necessarly compounded with C_LGSYSLG as 0LOGSYS is identified by C_LGSYSAF in the multiproviders.

Class ZZF_CL_FACTORING_TOOLS:

Most of the transformations used methods of the class ZZF_CL_FACTORING_TOOLS (Tools for the factoring process).

The main methods are:

• GET_INITIAL_ITEMS : method used to retrieve the original documents (invoices in the ERP transferred to CICC) from a list of factoring contract number.
• GET_LANDSCAPE_FROM_COMPPRS : method used to determine the landscape associated to a PRS company code.
• GET_AFF_COMPCDE_FROM_COMPPRS : method used to determine the ERP company code from MD C_COMPCDE for a PRS company code and a landscape.

Data Propagation Layer (DPFIAP03) updated from DPFIWC03 (ZZF_BSEG CICC table):

Update of existing entries in DPFIAP03 only (no creation of new lines)

• The factoring contract, Affiliate PRS company code (current one), Original Affiliate PRS company code (can be different from the Affiliate PRS comp code when the invoice was still open during merging of the company), Affiliate document type, netDueDate are updated directly from the source

• The factoring version is derived from the factoring contract number

• The landscape is obtained from C_COMPPRS MD using the Affiliate PRS company code

An error stack is updated for the following cases:

1) The line item in DPFIWC03 can't be found in DPFIAP03 => no update in DPFIAP03 but the record is put into the error stack to be reprocessed during the next process chain's run

2) The landscape is empty but the factoring version is "2" (Full factoring), it should be due to inconsistencies in C_COMPPRS Master Data => the line item is updated in DPFIAP03 (that means that the factoring contract number and factoring version are updated in DPFIAP03 but, without a landscape, the entry will not be routed to any BTL DSO) but the record is put into the error stack in order to be reprocessed automatically when the master data is fixed.

Business Transformation Layer - common rules:

Rules in common for all landscape (DPFIAP03 -> DBFIAP05/06/07) should be maintained in the transformation between the infosources "IB_FIAP_06" and "IB_FIAP_03".

Business Transformation Layer - landscape dependent rules:

• Enhancements and split using data in AP ERP DSO:

  The logical is similar for every landscape, however, the DSO to read the Affiliate data and the fields to retrieve are different.

  The original FI document item is read using the factoring contract number. When the original FI document is transferred into CICC, the clearing document (doc type KS or KC for Acetow) is also assigned to the factoring contract number and, so, must be excluded from the look up => finally, only one original FI doc item can correspond to a CICC FI doc item (each item of an original FI doc is assigned to a different contract number).

  As the original document item is split by several criteria in the BTL DSO, for every line on the original document item, we create a line on the CICC document item, the amounts on the CICC item is split proportionally to the amount of the line in the original document item (CICC amounts in local currency are not necessarily identical to the amounts in the original document).

  For instance, 

  CICC line item before split (DPFIAP03):

          Original line item WP1, split by purchase order items (DBFIAP01)

          CICC line item after split (DBFIAP05):

          Amounts not coming from CICC :

          Tax amounts (k_wmwst and k_mwsts) and Net of Tax amounts (k_notxlc and k_notxdc) are determined for the CICC document using the corresponding amounts in the original document.

          CICC Tax amounts = CICC amounts * ( original Tax amounts / original amounts )  

          Due to merge without DTO (which means that ERP FI documents transferred to CICC are not duplicated into the new company when merging operations), the current Affiliate company code is different than the one in the original document. The reporting must be based on the current Affiliate, but we also offer the possibility to display the original company code. So we have two different notions of Affiliate company code in the flows:

- the current Affiliate Company code (C_COMPCAF): derived from ZZF_BSEG-ZZ_BUKRS (using the method get_aff_compcde_from_compprs of the class ZZF_CL_FACTORING_TOOLS). If C_COMPCAF can't be determined, the error message " No correspondance in c_compcde for PRS code: " is raised in the DTP monitor.

- the original Affiliate Company code (C_COMPOAF): retrieved from the original document (and should be the same than if it was derived from ZZF_BSEG-ZZ_BUKRS_ORIG).

Warning: the current solution can't handle merge without DTO if the landscape of the new company is different than the original one (for instance, merge a company in WP1 into a company in PF1) as it would required two different "affiliate source system" one for the original affiliate company and all source system dependant characteristics and an other source system for the current Affiliate company. If this case occurs, the original document will be searched in the DSO of the current affiliate company and could not be found. 

• Deletion of existing lines :

• For “Agent” documents, 

  Landscape "ERPRCS":

  Enhancements of Affiliate data using data in AR RCS DSO (DBFIAR01). The sub-activity 2 is the Affiliate profit center. Even if the profit center could change in DBFIAR01, for the moment, it was decided to not make the flow more complex in automating the reclassification for agent documents in the factoring flow.

  Landscape "ERPSOLV":

  Enhancements of Affiliate data using data in AR RCS DSO (DBFIAR02). The sub-activity 2 is the  Affiliate business area. Even if the business area could change in DBFIAR02, for the moment, it was decided to not make the flow more complex in automating the reclassification for agent documents in the factoring flow.

  Landscape "ERPRHO":

  Enhancements of Affiliate Acetow company code using the correspondence with the Affiliate PRS company code in the Master Data C_COMPCDE. 

  The sub-activity 2 is not determined.

Business Transformation Layer - Delta from ERP to redetermine Affiliate data :

The delta is required to redetermine Affiliate data when it has been changed in ERP DSO, it is particularly important when there is the reclassification of the FI document but also if the Affiliate document was updated in the ERP DSO after than the corresponding CICC document was extracted.

CICC data propagation layer is read to reprocess the documents assigned to the impacted factoring contract number.

Another simpler solution was considered, it consisted to update a timestamp in the Data Propagation layer in order to reprocess the documents. However, the chosen solution enables a better segmentation in the Process Chains (the Data Propagation layer is common but Business Transformation layer is split by landscape). 

Business Transformation Layer - records deletion and recordmode management :

• In the first transformation :

We keep only the last image of a FI doc item, in consequence, all records for the same doc item must be gathered in the same packet using semantic group in DTP.

=> To not use key figures in "summation" in the transformations!

In order to handle contract number deletion or landscape change, if the last image of a FI doc item in the packet is not recordmode "N" or "", that means the item should not be in this flow anymore, so, we flag it for deletion (recordmode set to "D").

• In the last transformation :

We delete records in the target if not on the good lanscape or factoring version.
The delta DTP is filtered on the landscape and factoring version, so it will not occur in a "normal" loading, however, this will help ensuring no data on bad landscape is loaded using incorrect filters in DTP.
It also allows simple deletion of records in the target if the landscape/contract has changed and the delta for the deletion was skipped for any reason.

This is done in the rule group "Technical Group" of the transformation.

FIGL data flow

Common rules:

In business layer, we filter to keep posting on account types S (G/L Account) and M (Materials)

Rhodia legacy rules:

We continue to use ODSFIGL3. This DSO is very huge so it would have been to long to load other DSO and it would be to heavy in WBP system.

A split of data is done between propagation and business DSO (ODSFIGL1 and ODSFIGL3), in the start routine of the transformation.

The split is also done in WP1 system, in ZWFAT143 table. This table is filled in WP1 when the data source 0FI_GL_4 is launched. The data are retrieved in ODSFIGL2.

On ODSFIGL1, IECRA is calculated, depending if corresponding data is found in table ZWFAT205 (DSO_FI11). Otherwise, IECRA Substitution is done (For Pax Historical data): we search in DSO DBFIAR25 (DSO for IECRA Transcodification for PAX) if an IECRA to replace is found.

If yes we replace IECRA by IECRA found in DSO DBFIAR25.

This is done on 2 transformations:

• From 0FI_GL_4 to DSO ODSFIGL1.
• DSO ODSFIGL1 on itself.

Info on those rules:

PAX - IECRA substitution done on FIGL PAX - IECRA substitution done on FIGL

Data initialization:

For Solvay and CICC systems, initialization was done using PQ1 system. We made this choice for performance reasons.

FIGL-AR data flow

The perimeter is restricted to the GL account type "RECEIVABLES" (gl_account__c_gl_type) for PF1, CICC and Acetow.

Special perimeter for WP1 (managed in the DTP filters):

The perimeter is extended to the GL account "PREPAID". This is maintained in C_GLBFILT MD (stream = "DBFIGL01", rule = "GL_TYPE")

Morevover, due to rebates reclassification (in order to be aligned with PF1), the account 0041100500 was changed from "RECEIVABLES" to "PAYABLES". However, the organisational structure is determined from the IECRA (g_cwwe01) for these line items, so it can't be moved easily to the FIGL-AP dataflow, so this account is must be kept in the FIGL-AR DSO and excluded from the FIGL-AP DSO but displayed as a payable in the reporting. However, payables must be followed by BFC activity 2 which can't be determined from the IECRA =>that is why the object c_subact2 was added, to be mapped from the profit center for accounts to be considered as "payables" only.

Similarly, the account 0040100500 was changed from "PAYABLES" to "RECEIVABLES" but the organisational structure is derived from the profit center (c_subact2), so it can't be moved to the FIGL-AR dataflow.

=> the account 0040100500 is excluded and the account 0041100500 is included from the DTP filters. This is maintained via an exception list in C_GLBFILT MD (stream = "DBFIGL01", rule = "GL_ACCOUNT"), the exclusions in C_GLBFILT are only used to restrict the initial accounts list selected by the GL account type. 

No specific rules.

FIGL-AP data flow

The perimeter is restricted to the GL account type "PAYABLES" (gl_account__c_gl_type) for PF1, CICC and Acetow.

Special perimeter for WP1 (managed in the DTP filters):

The perimeter is extended to the GL account "ASSET" and "ASSETDP". This is maintained in C_GLBFILT MD (stream = "DBFIGL01", rule = "GL_TYPE")

Morevover, due to rebates reclassification (in order to be aligned with PF1), the account 0041100500 was changed from "RECEIVABLES" to "PAYABLES". However, the organisational structure is determined from the IECRA (g_cwwe01) for these line items, so it can't be moved easily to the FIGL-AP dataflow, so this account is must be kept in the FIGL-AR DSO and excluded from the FIGL-AP DSO but displayed as a payable in the reporting.

Similarly, the account 0040100500 was changed from "PAYABLES" to "RECEIVABLES" but the organisational structure is derived from the profit center (c_subact2), so it can't be moved to the FIGL-AR dataflow.

=> the account 0041100500 is excluded and the account 0040100500 is included from the DTP filters. This is maintained via an exception list in C_GLBFILT MD (stream = "DBFIGL01", rule = "GL_ACCOUNT"), the exclusions in C_GLBFILT are only used to restrict the initial accounts list selected by the GL account type. 

No specific rules.

An additional determination of the CO order and WBS Element is done when updating the FIGL-AP Solvay DSO (DBFIGL05), depending of the reference procedure:

• MKPF: retrieve the CO order and WBSe found in a P&L item of the FI document with the same Purchase Order item.
• RMRP: idem MKPF but if no P&L item was on the same PO item in this FI document, look at any MKPF document item on the same PO item.
• Other: retrieve the CO order and WBSe found in a P&L item of the FI document with the same amount.

CICC FIGL-AP and FIGL-AR "by Affiliate" data flow

CICC FIGL-AP dataflow :

https://drive.google.com/open?id=1KbLLpMubEncRdmH4Bsho-66fTzK_3Cpy8WhCuWKaCG0

CICC FIGL-AR dataflow :

https://drive.google.com/open?id=1ncFxsg_3QEheaujBk3-zSp5ZimgO1ldI51YQz8oif3o

Part of CICC FIGL-AR and FIGL-AP data are to be followed by Affiliate Company code. In contrary to factoring AP and AR entries, they can't be linked to ERP original documents by a factoring contract number.

We decided to create separated flows instead of adding new objects in existing DSO which seemed more easy to maintain (for recovery needs for instance), more flexible to answer potential new requirements, semantically more comprehensible because this is not a mix between flow with or without the notion of Affiliate.

The alternatives were:

• first alternative: add new Affiliate objects “*AF” for every Infoobjects composed with 0logsys => however, we should use these "Affiliate" objects instead of the existing objects in the multicubes and, so, fill these fields with "legal" values for most of the entries which have not this notion of Affiliate, so it would have been confusing…
• second alternative: add new legal objects “*LG”for every Infoobjects composed with 0logsys => it would require to change the key of existing DSO and also, for objects without prefix, it is not clear if it is affiliate data or not. And for flow by affiliate, except for the notion of company, the other objects composed with source system should be cleared (in case it is filled for the “legal” object and so it will not be assigned to the correct source system) => more complex maintenance as different processes are done for the documents inside a same transformation.

PRS Affiliate Company Code determination - Data Propagation Layer (DPFIGL03) updated from DPFIWC03:

Update of existing entries in DPFIGL03 only (no creation of new lines) with the Affiliate PRS company code in DPFIWC03 (Data from ZZF_BSEG CICC table).

An error stack is updated if the line item in DPFIWC03 can't be found in DPFIGL03 => no update in DPFIGL03 but the record is put into the error stack to be reprocessed during the next process chain's run

Recordmode management (DPFIGL03 → Infosource IB_FIGL_03)

For a document line item, if the last entry in a data package has recordmode “X”, the recordmode is changed to “D” in order to delete the existing key in the target DSO. It is necessary to ensure there is no duplicated document in "normal" flows (DBFIGL07/08) and in the flows by Affiliate (DBFIGL21/22).

Affiliate data determination - Business Transformation Layer (DBFIGL21 and DBFIGL22): 

Affiliate source system and Affiliate company code are derived from the PRS Affiliate company code determined in the Data propagation layer by reading Master Data PRS company code (C_COMPPRS) and Company code (C_COMPCDE) (it is done by the method get_aff_compcde_from_compprs of the class ZZF_CL_FACTORING_TOOLS).

If the Affiliate PRS company was determined but the landscape or the ERP Company code can't be determined, it should be due to inconsistencies in C_COMPPRS or C_COMPCDE Master Data (except if the landscape is 'NONERP') => the line item is updated in the target DSO but the record is put into the error stack and the DTP is set to "Update valid records, no reporting (request red)" mode to be warned if it occurs.

Affiliate Partner company = the CICC Partner company, we check in the MD c_company to ensure it corresponds to an existing company for the affiliate source system.

FIGL-IM data flow

• New master data C_MATPNT3

• Technical object

• Based on MBEW table

• Attributes Valuation class, company code, GL account

• To “correct” accounting from SAP systems : to have same BFC GBU account allocation as in SAP Logistic (could be different from allocation in Accounting)

• Need to split FIGL-IM in two silos

• Silo S with accounting on G/L account => based on postings

• Silo M with accounting on Material => based on C_MATPNT3

• 2014 and after only

• Snapshot at 31.12.2013

• Impossible to load full history

Rhodia legacy rules:

Snapshot was made at 31.12.2013 from CUB_IC001

Solvay legacy rules:

Snapshot was made at 31.12.2013 from PQ1.

Acetow legacy rules:

Snapshot was made at 31.12.2013 with flat files from RHO system.

We tried to use standard data sources 2LIS_03_BX, BF and UM to make an initialization at 31.12.2013.
Initialization with 2LIS_03_BX worked but we failed with the other data sources. 

Lease data flow

https://drive.google.com/open?id=1ejEriSI5lEC04vK0NRsW8fojh9yo6vzID0K7PitmOuE

This flow was released in production in 2019, in order to identify the leases to fit IFRS16 (the International Financial Reporting Standard 16).

This flow is based on FIAP data and restricted to the part of amounts linked to a Real Estate contract and a balance sheet accounts (identified by the flag C_BSCTFAF), to be excluded from Working Capital.

Documents created before IFRS16 (<2019) are not loaded in these flows. 

Net Of Tax amounts calculation (Rhodia) (R4):

For Rhodia (DBFIAP01 → DBFIPA10):

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, CO order, Real-Estate contract and balance sheet flag. 

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. 

For merge with DTO (open items in the old company are cleared and an equivalent document is created in the new company. However, FIAP line items on the DTO documents can't be split "normally" has the DTO document itself doesn't contain enough detail), similarly to the residual payments, Net of Tax determination for the DTO documents is done using the original document and original WBSE element. Links between DTO documents and original document are read in the DSO DBFIGL25 (Data comes from WP1 ZZF_DTO_CTR table) and links between WBSE in the old company and the new company are read in the DSO DPFIGL10 (Data comes from WP1 ZZF_DTO_POSID table).

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 → DBFIPA12):

Net of Tax amounts are calculated according to the original FI document item.

The original FI document item is read in DSO DBFIPA10 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 the transformation from DSO DBFIPA10 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 → DBFIPA10):

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 → DBFIPA12):

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. 

Fixed Asset Supplier (FAS) and Lease Interface

3 APD (APD_FICX_0001/2/3, one for RCS, Solvay and CICC SAP system) were created in order to provide FAS and Lease data from BW to allow and justify the FAS transfer accounting entries recorded for the closing:

The APD is based on the Bex query BW_QRY_MVFIWC03_0003, using a different variant for each source system (BW_VAR_MVFIWC03_0003_0001/2/3).

Logical File = Z_BW_FAS_DATA_RCS / Z_BW_FAS_DATA_SOLV / Z_BW_FAS_DATA_CICC

Logical path = Z_FAS = /exploit/BW/FAS/<FILENAME>

Lines with Fixed Asset Supplier key figure = 0 are deleted.

The key date is obtained from a query key figure and format as a NUMC date.

"currency" field is renamed as "loc_currcy".

In the heading, the field's names are suffixed by the number of the column. 

The APD generates a file in the BW directory "/exploit/BW/FAS" containing the result of the query => 1 file by ECC system, overwitten at each execution.

This file is transfered to ECC using ksh scripts called in the end of the D4 process chain. It is then read by an ECC program to update a table which will be used by the monthly process Z1F_CAPEX_MONTHLY_POSTING.

In BW, We have process chain (PC_FREQUENTLY_LOAD_MAIN), which triggeres 3 times in non closing days and runs 7 times in month end closing days.

In this chain, we have scripts and which will allow to transfer files from BW to WP1, BW to PF1 and BW to PI1(CICC) systems.

If the file has not been sent to ECC in any month, We(BW) have to contact IBM team and raise an incident on this issue.

Reference ticket # 4186157

Once the issue resolved, the file will sent to ECC Systems(PF1/WBP and PI1).

==> new way to send the flat file by webmethod usage and no more script.

Below documents sent to webmethod team to build the new solution, the check of webmehtod is done every hour during week day and not during the weekend.

Cash out data flow

Please check BW Cash out

These cubes are used in Working Capital reporting in order to remove CAPEX amounts from the payables.

BFC data flow

Link to BFC data flow documentation: https://drive.google.com/open?id=0B_p_Afe8sjVlY29mX05aSEx1Umc.

The contact concerning the BFC flat file is  marie-yolande.kuczynski@solvay.com.

Dependencies with other applications

WC applications is dependant with

• Project costs (FIAP and FIGL flows)
• ITC Credit Management (FIAR flow)
• SPRINT Purchasing (FIAP flow)
• CAPEX (FIAP and FIGL flows)

Data loadings

Record Keeping

We keep all records.

Reporting

Two roles menu exist for working capital: ZR_RCS_CA_M41 and ZR_RCS_CA_M412, the ZR_RCS_CA_M412 contains WC accounting with no conso view.

Queries list:

Workbook list:

There are 2 sub-folders, 1 for GBU usage and 1 for Accounting and BFC usage.
All workbooks are based on the same info providers. 

Query documentation:

https://drive.google.com/drive/#folders/0B_adX6faolE3OWdFODVnWHRjUXM/0B_fH_eB4PSMwc1ppRXVrVXh0ZXM/0BwtAGBKWM-z-c3ZMaTdXNU5RTTg/0BwfSNqWU_-PsTFJ2VmhqSXUySkE/0BwfSNqWU_-PsQzg5RVJ4VDZ1amc/0BwfSNqWU_-PsR3ZRNVp6dHFJd0E/0BwfSNqWU_-PsUDcwQlNmcktLUWM/0B_p_Afe8sjVlcUhzYkZmMlFtbzQ

Main queries

There is a lot of queries but the main one are:

BW_QRY_MVFIWC01_0002 BW - Working Capital (Core Query)

BW_QRY_MVFIWC01_0003 BW - Working Capital Receivables (Core Query)

BW_QRY_MVFIWC01_0004 BW - Working Capital Payables (Core Query)

BW_QRY_MVFIWC01_0005 BW - Working Capital Inventories (Core Query)

All queries use structures for key figures. There are many key figures, using calculated and restricted key figures inside.

Main functionnalities

Jump query available

Maintenance

Known bugs

No known bug but the following bugs may happen:

• Process chain for Master Data: For some master data we may have invalid characters in some fields. In this case, we modify the value in PSA to remove invalid character and we ask for correction in the source system
• Process chain for Transaction Data: Some roll-up requests of cube may fails. We have to repeat the action in the process chain to solve the issue.
• Documents uploaded in ZWFAT205 table but not in BW. It happened that a document was updated in ZWFAT205 table in WP1 at the exact same time that the info package ran in BW. So the document was not updated. We had to load it manually in BW
• Warning in table ZWFAT123 activation: length of the key is > 120, according to SAP documentation, it will be not possible to transport entries on specified keys, however, there is no reason to transport entries of this table. The solution to reduce the key would be to create a generated primary key (iteration of records for instance → impact in 0FI_AP_4 exit) and to keep actual key as a unique secondary key.

Examples of Freshdesk tickets:

• 2973: Add more fields in 0FI_AP_4 data sources
• 3333: Master data attributes not filled in PF1
• 5008: Bad description of C_MAGNITU and 0BUS_AREA
• 9433: Question about filters
• 2324: WP1 AP data wrongly updated in WBP

Recurring procedure

FIGL Clearing zones

https://drive.google.com/open?id=1EcYdNGfbiOdFa1TSuqyoxYTKiW2ie9laDbZ1iM1YGUA

FIAP & FIGL Data recovery

https://docs.google.com/document/d/1RWQ2gvcuVVPAHMlYB1SFCtjPZfHtWM9tsIlblghbfkE/edit

Planned Evolution

Todo list : https://drive.google.com/open?id=1Qo90KCi1c-8GvNU5IRrx6WLV-ow5hcOSTuyiNR_-EMc