General presentation

Objective of the application

This page provides all the technical and detailed documentation concerning the ITC (Invoice to Cash FIAR) application in BW, including :

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

Objective of this application is to provide an unique reporting tool for Credit Management team.

ITC is a solution to measure, analyse and decide based on all Credit data available.

Reporting coordinator is Sandrine Micollet.

Tool leader is François Rublon. 

Usage information

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

History

Project done between 2013 and 2015.

Roles & Access

Roles and access

Authorisation objects

Link to the BW Catalog of role

https://drive.google.com/open?id=10GEfKYqrT1eeTO_uHYAheL1GX7L5y_pvH0KQU64qh5I

Dataflow presentation

Overview

Reporting documentation drive folder:

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

Query documentation:

https://drive.google.com/a/solvay.com/?tab=mo#folders/0B_p_Afe8sjVlS1NLLW9maEV5ZEU

Workbooks description (made by Credit Management Team):

https://docs.google.com/a/solvay.com/file/d/0B_p_Afe8sjVlOVl1M214ckFfMm5KUWQ5OVBiN2NISE1YTDdF/edit

Detailled FIAR data flow:

https://docs.google.com/a/solvay.com/presentation/d/1AwviCF1m66qqSNWWwUtp7sQdG1itGBuF0m8x7Wq9vz4/edit#slide=id.p13

Functional and Technical rules on Workbench + Reporting

Rules & Explanations

Systems involved

• Rhodia ERP WP1

• Solvay ERP PF1 (020)

• CICC ERP PI1

• Acetow ERP RHO

• PRS ERP PF1 (050)

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 RCS 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

We use same conversion rate as Working Capital.

Main objects

Sub-Activity 0G_CWWE01:

The main object for business structure (BFC GBU for example) is the Sub-activity 0G_CWWE01.

Before ITC project, it was labelled IECRA. Now it containes IECRA values for WP1 and also Business area for other systems.

Company code C_COMPCDE:

We use for company code the object C_COMPCDE. It's compounded with the source system.

The attributes of C_COMPCDE are read from C_COMPPRS master data (loaded from PRS system).

In the reporting, we use this master data to retrieve the percentage of contribution and to identify the Intercompany. 

Customer number C_CUSTID:

We use for customer number the object C_CUSTID. It's also compounded with the source system.

The attributes are read from C_CUSTPRS but some are loaded from the ERP systems.

The object C_CUSTPRS is also stored in the info providers but is not used anymore. At the beginning of the project we used C_CUSTPRS in order to use the attributes of PRS.

But due to bad data quality we oftenly had the case of missing link in the ERP between ERP number and PRS number. To avoid that, we decided to retrieve PRS attributes in C_CUSTID and to use only C_CUSTID.

So in case of update in the ERP, we are sure to have dynamism. 

Reclassification of Sub-Activity C_SUBACT2:

In the ERP, when a IECRA 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.

Specific business rules

Rhodia legacy rules:

• Initial loading was done from existing DSO ODS_FI01 and not from WP1 system due to archived document not loadable anymore. It was also much faster
• The reclassification is done only in DBFIAR01, not in the propagation layer.
• We copied all existing rules applied in ODS_FI01. Maybe some them were obsolete.

Solvay legacy rules:

• Initial loading was done from PF1 system
• Business rules applied in end routine (easier to understand and maintain) : Reclassification by function module with data source ZZFCM_BU_EXCEPTIONS_NEW and DBFIWC01, fill info objects by reading master data

CICC legacy rules:

• Initial loading was done from PI1 system
• Business rules applied in end routine (easier to understand and maintain) : Reclassification by function module with data source ZZFCM_BU_EXCEPTIONS_NEW and DBFIWC01, fill info objects by reading master data

• Affiliate management (company of origin for FI document managed by CICC) : C_CMAFFIL

  • Loaded in one shot from flat file in DBFIAR05

  • If doc header text begins by ‘99999’

    • If characters 6 to 9 of doc header text is a company (check in C_COMPCDE)

• • => C_CMAFFIL = this company code

  • Read DBFIAR05 for CICC company and Customer code to determine C_CMAFFIL

• If doc header text doesn’t begin by ‘99999'

  • Read DBFIAR05 for CICC company and Customer code

Acetow legacy rules:

• Initial loading was done from RHO system
• Business rules applied in end routine (easier to understand and maintain) : Sub-activity from by business area (RHO + business area or constant value), fill info objects by reading master data.

SD KPI

Blocked orders:

• • Existing solution for Rhodia legacy not modified

  • Specific tables created in ERP systems so new solution

  • Very simple data flow without any difficult rules inside

  • Was modified by another project after

Credit Settings:

• • KPI to know if the customers is review automatically or manually

    • • Only CICC system PI1

  • Two data sources but ZZF_BW_CREDIT_SETTINGS is obsolete

  • Need has changed during the project

  • Very simple data flow : 1 DSO Propa & 1 Multiprovider

GBU Delegation Matrix:

• • Sum of outstanding and open sales order, open delivery and open billing

    • • For all systems (Rhodia, Solvay and Acetow)

  • Comparison with credit limit

  • • Managed in CICC at customer level

    • Managed in PRS at customer group level

Credit Exposure:

• • Master data C_CREDEXP / DSO DBFIAR07

  • Included in FIAR data providers

  • Outstanding calculated in FIAR data flow

  • Credit Exposure into DBFIAR07

  • • Sum of credit exposure from all systems (customers can have exposure in all systems)

    • Delete DSO before loading

  • Credit Exposure into into C_CREDEXP from DBFIAR07

  • • Master data loaded from itself to set attributes to 0

  • Credit limit loaded into C_CREDEXP

  • DBFIAR12 to have credit exposure evolution

  • Weekly loading

  • • Loading is too long to be daily (1h)

    • Comparison with ERP (FD33) impossible : Too much changes in the ERP to have same key figures in BW

Dependencies with other applications

WC applications is dependant with

• WCAP Working Capital (FIAR flow)
• FIAR Account Receivables (FIAR data source)

Data loadings

Info providers and objects loaded

List on info providers inside the technical cockpit.

Loading frequency

During closing period (last day of the month and 4 first working days):

• WP1 data are loaded 7 times a day: 6am, 10am, 12am, 2pm, 4pm, 6pm and 10pm (french time)
• PF1, PI1 and RHO systems are loaded 3 times a day: 6am, 12am and 6pm (french time)

Outside closing period:

• All systems are loaded 3 times a day: 6am, 12am and 6pm (french time)

Average performance

Around 20min for all systems.

Record Keeping

We keep all records.

Reporting

Queries End User Documentation

All the reporting is available throught workbooks in the role "ITC - Credit Management" ZR_RCS_CA_M39

 There are 2 difficult workbooks

• ITC Credit Management Workbook
• ITC Process Expert Workbook

Those workbooks are difficult because they contain a lot of sheets using many queries. So be careful when you modify it and don't hesitate to create back-up !

Workbooks description (made by Credit Management Team):

https://docs.google.com/a/solvay.com/file/d/0B_p_Afe8sjVlOVl1M214ckFfMm5KUWQ5OVBiN2NISE1YTDdF/edit

Main queries

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

BW_QRY_MVFIAR01_0001 BW - Credit Management DSO (Core Query)

This query contains more than 200 key figures ! 

When possible, queries use structures for key figures. 

Main functionnalities

Jump query available

Broadcast

No broadcasts

Maintenance

Known bugs

No known bug

Recurring procedure

No procedure

Planned Evolution

No planned evolution