This page provides all the technical and detailed documentation concerning the "FIWC for Solvay Group" (Finance Working Capital) application in BW, including :
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:
It excludes:
Query Technical Names:
In BFC:
Every month, persons in each company will get the values from WBP for each account and enter it manually in BFC.
Reporting coordinator is ROLLIER, Charlotte
Around 220 users have access to WC applications. Those users are worldwide and most of them are controllers.
Project done between 2013 and 2015.
| Role Code | Role Description | Explanation |
|---|---|---|
| ZR_RCS_CA_M41 | WCAP – Working Capital Solvay Group | Role menu |
| ZBI_RCS_FI_A31 | WCAP – Working Capital GBU Solvay Group - End User role | End user role |
Link to the BW Catalog of role
https://drive.google.com/open?id=10GEfKYqrT1eeTO_uHYAheL1GX7L5y_pvH0KQU64qh5I
Reporting documentation drive folder:
Query documentation folder:
Rhodia ERP WP1
Solvay ERP PF1 (020)
CICC ERP PI1
Acetow ERP RHO
PRS ERP PF1 (050)
BFC (flat files)
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
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.
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.
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.
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.
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 :
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):
Full factoring introduced the notion of "Affiliate" and "Legal" objects.
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
This part of the Working Capital has been done via ITC project. Please check ITC page for more details.
Please check ITC page for more details.
FIAP data re also be used for SPRINT (Purchasing), Project costs and CAPEX applications.
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 DPFIWC DSO.
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
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.
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.
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)
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 downpayments (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.
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)
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.
This flow is filtered to the factoring version <> "2".
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).
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.
Factoring flows DSO and cubes use the notion of "Affiliate" and "Legal" objects.
Most of the transformations used methods of the class ZZF_CL_FACTORING_TOOLS (Tools for the factoring process).
The main methods are:
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
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", 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.
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".
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 :
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), or the original document was missing in a first time in the "Affiliate" DSO, 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".
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.
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.
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).
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").
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.
In business layer, we filter to keep posting on account types S (G/L Account) and M (Materials)
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.
For Solvay and CICC systems, initialization was done using PQ1 system. We made this choice for performance reasons.
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.
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:
CICC FIGL-AP dataflow :
CICC FIGL-AR dataflow :
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:
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 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 DBFIGL20 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.
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
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.
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).
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.
Please check BW Cash out
These cubes are used in Working Capital reporting in order to remove CAPEX amounts from the payables.
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.
WC applications is dependant with
List on info providers inside the technical cockpit.
Around 1h for WP1 and 1h for other systems.
We keep all records.
All the reporting is available throught workbooks in the role "WCAP - Working Capital Solvay Group" ZR_RCS_CA_M41
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:
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.
Jump query available
A broadcast is sent to users. The schedule is determined in the BW process chains. Actually, the broadcasts are sent the 6th, 10th, 15th and 20th working day of the month.
For those days, at the end of the process chain, a file is put in the BO server. When the BO server idenfity this file (an empty txt) file, it triggers the broadcasts.
All the design and settings are managed in BO.
On WBP system : the event for BI broacasts are managed on the process chain PC_FREQUENTLY_LOAD_MAIN
Program : ZBW_BI4_EVENT_BCAST
No known bug but the following bugs may happen:
Examples of Freshdesk tickets:
FIGL Clearing zones
https://drive.google.com/open?id=1EcYdNGfbiOdFa1TSuqyoxYTKiW2ie9laDbZ1iM1YGUA
FIAP & FIGL Data recovery
https://docs.google.com/document/d/1RWQ2gvcuVVPAHMlYB1SFCtjPZfHtWM9tsIlblghbfkE/edit
Todo list : https://drive.google.com/open?id=1Qo90KCi1c-8GvNU5IRrx6WLV-ow5hcOSTuyiNR_-EMc