1. Objective and Scope

1.1 Objective of this Operation

The purpose of this document is to provide the operational / technical details describing the “Reporting axes” process, the axes determining the Group structure for BFC and BW, in terms of Business.

This process describes the way to formalize the elements enabling to report the results of the Solvay Group according to a hierarchy of axes representing the Group structure.

On a top-down approach, the Group structure is defined in the following way, as described in the GAR documentation:

• Cluster: top level of the Group structure

• Group of GBU: intermediate level

• GBU: main operational and financial sub-division

• Group of activities : sub-division of a GBU

• BFC activity 1: main level of the BFC reporting, previously called “division rapportante” in the Solvay Legacy and “market” in the Rhodia Legacy. Sometimes abbreviated as “Act1” in this document. 

• BFC activity 2 : sub-division of “activity 1”, based on an “industrial axis” – it was not present in the Solvay Legacy and called “CGU” in the Rhodia Legacy. Presently in the ERP Solvay, it is uniquely determined by the Act1 on a one-to-one basis.

• Lower levels depending on the Legacy.

1.2 Scope

This procedure covers the implementation of a new business structure in SAP PF1 and PI1.

2. Definitions

See Finance Glossary:

• BFC
• Business area
• IS
• PIF
  
  

3. Tasks description

3.1. I receive the information that a new business structure needs to be implemented in PF1

All requests for data under the responsibility of Finance Data & reporting must be made through the “MDWF” workflow.

For complex changes and topics, there are usually several preliminary contacts and the workflow is created when the solution has been designed and agreed.

In terms of reporting axes, the information can also be provided by an email from Corporate Controlling. 

3.2. I analyze and validate the information provided in the request 

The description of the process of defining Reporting axes in the systems linked to the Solvay Legacy can be divided into 5 sub-processes, for an easier understanding :

1. New “BFC activity 1”
2. New PIF (product division) in existing “activity 1”
3. New profit center for existing PIF (product division) and “activity 1”
4. Re organisation of reporting elements “below activity 1”
5. Update of Group structure “above activity 1”.

3.2.1. New “BFC activity 1”

The introduction of a new “activity 1” is requested by the GBU and formally accepted / decided by GAR/Corporate Controlling, who assign its code in BFC, as well as its position in the global organization chain up to the “Cluster” and the related BFC Act2. 

Historically, it has been a two-digit code for Solvay Legacy GBU and a four letter code for Rhodia Legacy GBU.

The solvay business structure can be found here and is usually updated every year. 

After GAR’s approval, the GBU needs to communicate to Finance Data the necessary elements in order to activate the set-up process.

Determination in the accounting process:

The BFC activity 1 It is mainly materialized in SAP PF1 and PI1 by :

• the Business area, for postings linked to the Balance sheet
• the “reporting” profit centers, for postings linked to the P&L.
  
  

For the operations linked to material movements (purchasing, consumption in production process, sales…), the Business area is determined by a table (T134G, view V_T134G_WS), based on the combination of the product division contained in the material and the plant where the operation takes place.

For costing operations, the Business area can be specified in the cost center or other objects, but it can be changed during the Assessment cycles.

For other operations, the business area can be entered manually in the document.

In case the operation arrives in the BFC /BW interface without business area, a default business area is determined by company code in table ZZR_REPO_DIV_EXC (records for “dummy reporting divisions 00 and 99). This table also enables a change of Business Area in the BFC interface, creating thus a difference between the accounting documents in the ERP system and the data transmitted to BFC.

SAP Objects:

A “BFC activity 1” involves the following SAP objects:

• “BFC Activity 1” → table ZZF_BFC_MARKET.
• “Reporting Division / Division rapportante” : BFC “activity 1” [trans codified into 2-character code if initially longer] → table ZZR_REPO_DIV.
• Trans codification between “reporting division” and BFC Act1 → table ZZF_BFC_DIV_COVV.
• Business area = way of representing the “activity 1” for most SAP postings → table TGSB – view ZZRTGSBV.
• Often: PIF (“Produit Issu de Fabrication”), materialized by two SAP objects :
  • level of the “commercial hierarchy”, under the responsibility of OtC → table T179 – view ZZRT179V
  • product division (“secteur d’activité” in French) → table TSPA – view ZZRTSPAV.
• Profit Centers and their hierarchies, on two levels :
  • global profit center representing the “activity 1” (D + business area code)
  • detailed profit centers at PIF / industrial origin level (F* range).
  • In both cases, additional profit centers can be necessary, based on the partner company.
• COPA Characteristics → Transaction KES2
  
  

SAP implementation: roles and actors

The implementation of a new “BFC activity 1” requires the following steps:

• GAR informs the “community” of the creation of a “BFC activity 1” with its BFC code and position in the Reporting chain.

• The GBU controller defines with the GBU marketing and OtC the appropriate product hierarchy structure. In case of implementation in the ERP Solvay of a Rhodia Legacy “activity 1”, and in the absence of specific requirement from OtC, the “minimum” hierarchy is determined by Finance Data in basis of the other data. The GBU controller makes a request to Finance Data, including the following elements :
  • BFC activity 1;
  • “PIF” contained in the hierarchies, specifying whether they are new PIF or re-assignment of existing PIF – giving the product hierarchy of the new PIFs;
  • For each PIF, the list of the involved industrial origins (either linked to actual production, or external purchases or “mix of bulks” in external storages). In case of Rhodia Legacy GBU, RCS code of these product divisions;
  • For each PIF, the list of the plants for which automatic determination of the business area is needed to derive the new business area;
  • Possible additional profit centers to be created to include the partner company.

• Finance Data analyses the request and, if all clear and OK :
  • Creates the Reporting Division in tables ZZR_REPO_DIV, ZZF_BFC_MARKET, and ZZF_BFC_DIV_COVV;
  • Open a Freshdesk ticket to IS Structure Data requesting:
    • The update of table ZZRTGSBV with the new business area code;
    • Rules for the business area determination (For the operations linked to material movements (purchasing, consumption in production process, sales…), the Business area is determined by a table (T134G, view V_T134G_WS), based on the combination of the product division contained in the material and the plant where the operation takes place);
      
      

After the confirmation by IS Structure Data, proceed to the creation of the other elements:

• Create the D* profit center at “reporting division” level and insert it directly under the node representing the BU.
• Create the F* profit centers representing the combination of “PIF + industrial origin + bulk / pack”.

If needed, insert the “partner division” for some companies purchasing the goods represented by this “activity 1” (table ZZF_BFC_DIVPARTV).
If needed and exceptionally / temporarily, force a change of Business area in table ZZR_REPO_DIV_EXC, to change the “business area – activity 1” in the BFC / BW interface to by-pass the one in the documents, when changes are decided when there are open documents.

When these activities are completed, Finance Data informs the Controller and the project team so they can undertake the downstream activities, according to 3 scenarios. Most often, these actions are included in a “mini-project” to be coordinated by IS teams:

1. First scenario: “brand new” materials – this is the easiest scenario:
   1. Insert profit center in the material costing view (F* for finished goods to be sold and D* for raw materials).
   2. Check that the combination “plant / product division” exists in table T134G (view V_T134G_WS).
      
      
2. Second scenario: existing materials but without stock :
   1. Idem as first scenario plus possible updates of open sales orders and other documents using the profit center. Table T134G (view V_T134G_WS) can only be updated under this scenario if there is no stock for any material representing the combination “plant / product division”. Otherwise, scenario 3 must be activated.
      
      
3. Third scenario: existing materials with stock: this is the most complex scenario, requiring a series of sequential actions, usually coordinated by an IS Project team. As the working capital is calculated by “BFC Act1”, existing stock must be moved from the old to the new Act1. The safest way of achieving this, even not the simplest, is to go through a “zero stock” phase. It is strongly advised that this operation is done under the coordination of IS people used to this type of operations. 
   As no shipments or stock consumption is possible during the operation, it needs to be made at a time of low activity as to be agreed with the local Supply Chain manager:
   
   1. 1st phase: the stock is removed to arrive at a zero stock situation and thus cancelling the working capital on the old Business area.
   2. 2nd phase: all updates are made in table T134G (view V_T134G_WS), profit center in material costing views….
   3. 3rd phase: the stock is reinstated as before, reloading thus also the working capital on the new Business Area.

Other updates might be needed at different times, to be ascertained and coordinated by the IS project team.

3.2.2. New PIF (product division) in existing “activity 1”

This sub-process deals with the request of a new product division within an existing “activity 1”.

For Rhodia Legacy products, it corresponds to the decision to create new product divisions with an existing BFC Activity 1.

The GBU needs to communicate to Finance data & reporting the necessary elements in order to activate the set-up process.

We need to make sure that the new PIF is “independent” from existing ones and that they do not ask a PIF under or above an existing one.

The PIF (“Produit Issu de Fabrication”) is a level of the “commercial hierarchy” on which the “prix de revient” (cost of goods) is calculated. It is the common level between the Sales & Marketing functions and the Accounting process. 

It is materialized in SAP by three objects :

• level of the “commercial hierarchy”, under the responsibility of OtC

• product division (“secteur d’activité” in French), linked to Finance

• profit centers for finished goods.

SAP Objects:

A PIF involves the following SAP objects:

• PIF (“Produit Issu de Fabrication”), materialized by two SAP objects :

• • level of the “commercial hierarchy”, under the responsibility of OTC → table T179 – view ZZRT179V

  • product division (“secteur d’activité” in French) → table TSPA – view ZZRTSPAV.

• Profit Centers and their hierarchies: detailed profit centers at PIF / industrial origin level (F* range).

• COPA Characteristics → Transaction KES2

  
  

SAP implementation: roles and actors

The implementation of a new “PIF product division” within an existing “BFC activity 1” requires the following steps :

• The GBU controller defines with the GBU marketing and OtC the appropriate product hierarchy structure.

• In case of implementation in PF1 of a Rhodia Legacy product division, and in the absence of specific requirement from OtC, the “minimum” hierarchy is determined by Finance data & reporting in basis of the other data.

• The GBU controller makes a request to Finance data & reporting, including the following elements :

• • Activity 1 in which the new PIF will be reported.

  • “PIF” contained in the hierarchies, specifying whether they are new PIF or re-assignment of existing PIF – giving the product hierarchy of the new PIFs.

  • For each PIF, the list of the involved industrial origins (either linked to actual production, or external purchases or “mix of bulks” in external storages).

  • In case of Rhodia Legacy GBU, RCS code of these product divisions.

  • For each PIF, the list of the plants for which automatic determination of the business area is needed to derive the new business area.

  • Possible additional profit centers to be created to include the partner company.

• Usually, the request for the new product hierarchy is made to IS Structure Data by the GBU, either Controller or Marketing.

• Finance data & reporting analyse the request and, if all clear and OK : 

• Create the F* profit centers representing the combination of “PIF + industrial origin + bulk / pack”.

  
  

• When these activities are completed, Finance data & reporting informs the Controller and the project team so they can undertake the downstream activities (material profit center, open orders…).

3.2.3. New profit center for existing PIF (product division) and “activity 1”

This sub-process deals with the request of a new F* profit center for an existing PIF – product division, without change of “activity 1”. It is much simpler because it only involves the creation of profit centers.

It can be prompted by a new industrial origin or the need of a specific partner.

Typically, this type of decision is made by a GBU Controller.

The GBU needs to communicate to Finance data & reporting the necessary elements in order to activate the set-up process.

The first thing to check is that the requested hierarchy of the profit center corresponds to a PIF, neither under nor above. If not, the request cannot be accepted.

SAP Objects:

 Only the Profit Centers and their hierarchies are involved.

SAP implementation: roles and actors

The implementation of a new profit center within existing “PIF / product division” and BFC activity 1” requires the following steps :

• The GBU controller makes a request to the Finance Data team, including the same elements as for an “activity 1”, specifying the existing PIF, “activity 1” and industrial origin.

• Finance Data analyses the request and, if all clear :

• • Check that the requested profit center is at PIF level, neither above nor under.

  • Create the profit centers insert them into the hierarchy as in the first sub-process.

• The local Controllers ask Service Unit Management accounting team to update the profit center in the material master data.

3.2.4. Re organisation of reporting elements “below activity 1”

In certain cases, the GBU can decide to move a PIF from an Activity 1 to another existing one, thus without the creation of new Act1.

3.2.4. Update of Group structure “above activity 1”

At the end of each year, the Corporate Management decides on the modifications of the group structures, in terms of clusters, groups of GBU, GBU, group of activities and “activity 1 and 2”.

The present section only deals with the situation in which the changes are made only above the “Business Area / BFC Act1” level.

Examples: GBU A is split into two GBU, A1 and A2. Or GBU B1 and GBU B2 are merged into GBU C.

Finance Data receives this information from GAR, who communicates the required changes.

SAP Objects:

The full hierarchy of Solvay Business structure is implemented in two ways in the ERP Solvay:

1. A set of tables in PRS, replicated to the ERP Solvay (PF1) and to the CICC (PI1):
   
   1. Clusters – table ZZR_REPO_CLU
   2. Groups of GBU, also called sub-clusters – table ZZR_REPO_SCLU, including the link to the appropriate cluster
   3. GBU – table ZZR_REPO_BU, including the link to the appropriate “sub-cluster”
   4. Groups of Act1, also called sub-GBU – table ZZR_REPO_SBU, including the link to the appropriate GBU.
   5. Table for the Act1 (ZZR_REPO_DIV) includes the link to the “sub-GBU”.
2. The hierarchy of Reporting Profit centers: CHEFCHEOPS, starting from the GBU downwards.

SAP implementation: roles and actors

The implementation of a change of organization above “Act1” requires the following steps :

• Finance Data fixes a date for implementing the change, together with the GBU Controller and the Service Center manager.
• Finance Data creates a workflow describing the changes to be made and asks the GBU Controller to submit/validate it.
• At the given date,Finance Data implements the change in the tables and the profit center hierarchies.

3.3. I verify and update tables ZZR_REPO_CLU, ZZR_REPO_SCLU, ZZR_REPO_BU and ZZR_REPO_SBU tables

The “chain” of reporting axes "above activity 1" is materialized in the ERP Solvay (PRS / PF1) and the CICC (PI1) by the following tables :

• ZZR_REPO_CLU Reporting: Cluster
• ZZR_REPO_SCLU Reporting: Sub Cluster
• ZZR_REPO_BU Reporting: Business Unit
• ZZR_REPO_SBU Reporting: Sub Business Unit
  
  

All these tables are managed in PRS, from which they are transported automatically every hour to PF1_020 and PI1_020.

In addition, tables ZZR_REPO_BU is also transported to WP1.
This automatic transport system also includes the corresponding “development”, “quality” and “pre-production” systems.

Note: in these tables, the dates “valid from” and “valid to” are only attributes. They are present “for information only”. Thus only one record per organization element can be entered, unlike other tables in which the “valid to date” is part of the key and we can create several periods.

3.3.1. Table ZZR_REPO_CLU: Reporting Cluster

This table formalizes the highest level in the Solvay Business hierarchy: 

In PRS (PF1-050), go to SM30 and enter table ZZR_REPO_CLU:

Enter:

• the 4-character code received from Corporate Controlling
• the description received from them
• the date at which the new cluster will be active
• by default 31.12.9999 as “end date”.

Whenever, Corporate Controlling informs us that a cluster becomes obsolete :

• change the “end date” to the one specified by them
• insert “ZZZZ ” in front of the description.
  
  

3.3.2. Table ZZR_REPO_SCLU: Reporting Sub-Cluster

This table formalizes the second level in the Solvay Business hierarchy: the “sub cluster” or “group of GBU’s”.

In PRS (PF1-050), go to SM30 and enter table ZZR_REPO_SCLU:

Enter :

• the 3-character code received from Corporate Controlling
• the description received from them both in “medium name” and in “name”, abbreviating the latter if too long
• the 4-character code of the cluster to which the sub-cluster belongs to
• the date at which the new sub-cluster will be active
• by default 31.12.9999 as “end date”.

Whenever, Corporate Controlling informs us that a sub-cluster becomes obsolete :

• change the “end date” to the one specified by them
• insert “ZZZZ ” in front of the description.

3.3.3. Table ZZR_REPO_BU: Reporting (Global) Business Unit

This table formalizes the third level in the Solvay Business hierarchy: the “Global Business Unit” or “GBU”.

In PRS (PF1-050), go to SM30 and enter table ZZR_REPO_BU:

Enter :

• the 2-character code received from Corporate Controlling
• the description received from them both in “medium name” and in “name”, abbreviating the latter if too long
• the 3-character code of the sub-cluster to which the GBU belongs to
• the date at which the new GBU will be active
• by default 31.12.9999 as “end date”.

Whenever, Corporate Controlling informs us that a GBU becomes obsolete :

• change the “end date” to the one specified by them
• insert “ZZZZ ” in front of the description.
  
  

3.3.4. Table ZZR_REPO_SBU : Reporting “Sub Business Unit”

This table formalizes the fourth level in the Solvay Business hierarchy: the “Sub Global Business Unit”, also called “Group of activities”.

In PRS (PF1-050), go to SM30 and enter table ZZR_REPO_SBU:

Enter :

• the 5-character code received from Corporate Controlling, starting with the 2-character code of the GBU
• the description received from them both in “medium name” and in “name”, abbreviating the latter if too long
• the 2-character code of the GBU to which the “group of activities” belongs to
• the date at which the new GBU will be active
• by default 31.12.9999 as “end date”.

Whenever, Corporate Controlling informs us that a GBU becomes obsolete :

• change the “end date” to the one specified by them
• insert “ZZZZ ” in front of the description.

3.4. I update tables ZZR_REPO_DIV, ZZF_BFC_MARKET, ZZF_BFC_DIV_COVV

The “chain” of reporting axes "below activity 1" is materialized in the ERP Solvay (PRS / PF1) and the CICC (PI1) by the following tables :

• ZZR_REPO_DIV Reporting: Division
• ZZF_BFC_MARKET BFC – Market
• TGSB Business Areas
• ZZF_BFC_DIV_COVV BFC Division conversion

• T134G/H Business Area determination for material movements

All these tables are managed in PRS, from which they are transported automatically every hour to PF1_020 and PI1_020.
In addition, tables ZZF_BFC_MARKET are also transported to WP1.
This automatic transport system also includes the corresponding “development”, “quality” and “pre-production” systems.

3.4.1. Table ZZR_REPO_DIV: Reporting: Division

This table formalizes the “BFC Activity 1” in the “ERP Solvay” logic, where it was previously called “Reporting Division” or “Division Rapportante”.

There are several possibilities :

• The code received by Corporate Controlling is a 2-character code starting with a digit, thus in the continuity of ERP Solvay tradition of “Reporting Division” : the code can be taken as such.

• The code received by Corporate Controlling is a 4-character code starting with a letter, thus in the continuity of RCS tradition : the code must be transcodified to a 2-char code. The first letter represents the GBU, selected in a mnemotechnic way according to GBU code or GBU name. 

Examples : C for Novecare or T for Technology Solutions.

• The second letter is a sequential letter for the Act1, except for the “GBU Non allocated”, for which we systematically select letter N.

Examples : 

CB for CSCH - NOVECARE - HOME PERSONAL CARE

CN for CSNR – NON ALLOCATED NOVECARE TRANSACTION

ID for PMPM – POLYAMIDE TIERS

IN for PMNR – UNALLOCATED PM.

• A special case deals with the portion of GBU Special Chem that comes from the Solvay  Legacy. 

• When the split of division 33 + 63 was done early 2016, the BFC code has been built with : prefix CH + digit 3 + one letter for each Act1.

• The Reporting division is the last 2 characters of the BFC Act1 : digit “3” + one letter.

• Example : BFC Act1 CH3B – BATTERIES corresponds to Reporting Division 3B.

Enter :

• the 2-character code resulting from the determination described above

• the description :

• • if BFC Act1 is 2-character long : description received from them both in “medium name” and in “name”, abbreviating the latter if too long

  • if the BFC Act1 is 4-character log : code of BFC Act1 + “ – “ + description received from them both in “medium name” and in “name”, abbreviating the latter if too long

    
    

• the 5-character code of the “group of Act1” to which the Act1 belongs to 

• the date at which the new Act1 will be active

• by default 31.12.9999 as “end date”.

Whenever, Corporate Controlling informs us that a BFC Act1 becomes obsolete :

• change the “end date” to the one specified by them

• insert “DO  NOT USE – EX ” in front of the description.

Table is TGSB but it must be displayed via view ZZRTGSBV.

This table is maintained by IS Structure Data, upon request from Finance Data via Freshdesk. It is important that the request to IS Structure Data is made after the other tables have been updated because it is the Business Area which “opens” the possibility for used to make postings on the new Act1 : ZZR_REPO_DIV + ZZF_BFC_MARKET.

It contains the following data, which must be specified in the request to IS Structure Data :

• Business Area code, made of three parts :

• 1 character for the “sector” :

• 3 for Plastics = Specialty Polymers and  Vinyls

• 7 for Chemicals = Soda Ash + Peroxides + Special Chems + Chlorinated outside of vinyls

• 8 for Corporate activities, such as CBS, Energy or NBD

• 9 for Rhodia and Cytec legacy GBU

• 9999 for “Common” multi business – specific cases

• other digits are obsolete and can no longer be used.

• 2 characters for the Reporting Division, equal to table ZZR_REPO_DIV.

• Last digit : 0, except for German companies who can use sub-divisions.

• Description = description of Reporting division.

• Initial validity = determined automatically by the system when the record is created.

• End of validity = 31.12.9999 by default.

• The dates “valid from” and “valid to” are only attributes. They are present “for information only”. Thus only one record per organization element can be entered, unlike other tables in which the “valid to date” is part of the key and we can create several periods.
  

Table ZZF_BFC_DIV_COVV converts the Reporting Division into the official BFC Activity 1 codes in the interfaces to Reporting systems such as BFC or BW, extracting it, for example, from the middle 2 characters of the Business Area.

It is managed by dates, to be able to take into such situation in which the BFC Act1 code would be modified while retaining the Business Area code and thus the Reporting Division.

Example : the main reporting division for Special Chem Fluor Business has been historically “33”. It has been decided to split it into several Act1 on 01.01.2016, “CH3 + letter”, to be used for finished goods, retaining “33” for fixed costs and services. As the “new division 33” has not the same “dimension” as the old one, it has been decided to change the BFC Act1 for clarity on the results.

We thus create 2 records :

• one from the past to 31.12.2015 → Act 1 = 33

• one from 01.01.2016 to the infinity → Act 1 = CH3X.

  
  

In case of new reporting division, enter :

• Code of the Reporting Division – from table ZZR_REPO_DIV.

• Valid to = 31.12.9999 by default.

• Valid from = date on which the new reporting division is active – should be rather near the “begin validity date” of Business area in view ZZRTGSBV.

• BFC Activity 1 : the official 2 or 4-character code used in BFC, with an existence check in ZZF_BFC_MARKET.

• BFC Activity 2 : the code supplied by Corporate Controlling – in case several values exist for a given Act1, take the one corresponding to the continent which has the most business in that Act1, often EMEA.

• BFC Partner Act1 : equal to BFC Act1.

In case of change of Act1 or Act2 for an existing reporting division (only actual change, not error correction) :

• Copy the existing record to a new one, changing the “end of validity date” to the last day that record is valid.

• Update the original record :

• Valid from = date on which the new combination becomes active – must be the day after the one used in the previous step, to avoid gaps or overlaps

• New Act1 – Act2 – Partner Act1 according to the instruction from Corporate Controlling.

• See example above for division 33.

In case of obsolescence of BFC Act1 :

• Copy the existing record to a new one, changing the “end of validity date” to the last day that record is valid.

• Delete the original record.

3.5. I request the creation of the new business structure elements to IS Materials & Structure Data

Open a Freshdesk ticket to IS Structure Data requesting:

• The update of table ZZRTGSBV with the new business area code;
• Rules for the business area determination (For the operations linked to material movements (purchasing, consumption in production process, sales…), the Business area is determined by a table (T134G, view V_T134G_WS), based on the combination of the product division contained in the material and the plant where the operation takes place);

3.6. I request CGI team to create / update the COPA characteristics

For new entries/codes, COPA characteristics are automatically updated.

Check in transaction KES2 if the new COPA characteristics code is already available. 

If not, open a Freshdesk ticket, asking to update it accordingly: 

End of document.