1.PURPOSE AND USAGE OF BUSINESS STRUCTURES IN BFC

Solvay IFRS reporting is organized per legal companies (one reporting package per legal company) reporting their Financial Statements (P&L, Balance Sheet and Cash Flow Statement) on a monthly basis. To allow Businesses to get their Financial results, each legal company will in addition split its results on Business dimensions. 

The following items of Financial Statements require an allocation per Business:

  • P&L until EBIT (Operating Income)
  • Internal sales and external sales
  • Working Capital (stocks, acc. receivables and payables), CAPEX (capital expenditures), Fixed assets and Investments
  • Free Cash flow

It means that Group IFRS Consolidated results can be obtained as sum of legal companies and as sum of Businesses.

This IFRS reporting per Businesses is used by both Businesses and Corporate Controlling teams to prepare the analysis of Solvay Businesses performance included in both Financial press releases every quarter and Annual report.

To be noted that Business structures are also used in Controlling reporting categories (RSB and PREV).


2.BUSINESS STRUCTURES HIERARCHIES IN BFC

Business structures are organized around 5 levels aggregating each others in a global hierarchy (following a "Russian dolls" principle - 1 level can belong to only one upper level and never two):

  • CLUSTER = Operating segment
    • This is the upper level of the hierarchy
    • Codification rule : 4 letters 
    • Corresponds to the level of external communication on Solvay Businesses performance 
    • Only used for retrieval purposes, not as entry point for data entry
    • Example: CHEM "Chemicals", MATE "Materials", SOLU "Solutions"...
    • Approval process for creation of new CLUSTER / update of content: Corporate Controlling
  • SEGMOP = Group of GBU's = Operational Segment
    • This is the 2nd level of the hierarchy
    • Codification rule : 3 letters 
    • Used internally to group GBU's - not a level subject to external communication
    • Only used for retrieval purposes, not as entry point for data entry
    • Examples in Cluster CHEM "Chemicals": GCT "Coatis", GEB "Vinythai"...
    • Approval process for creation of new SEGMOP/ update of content: Corporate Controlling
  • ENTREP = GBU = Global Business Unit
    • This is the 3rd level of the hierarchy
    • Codification rule : 2 letters 
    • Used internally  - corresponds to the Business organization and management with Global Director, Finance teams...
    • Only used for retrieval purposes, not as entry point for data entry
    • Examples in Segmop GCT "Coatis"": CT "Coatis", FI "Fibras"
    • Exception / constraint on codification: do not choose codes starting with "D", "Dx" codes dedicated to Discop GBU's (examples: DO "Discop Acetow" / DM "Discop Performance Polyamides"...), creation subject to request and approval from GAR
    • Approval process for creation of new GBU : Corporate Controlling , on proposal made initially by Businesses
    • Approval process for update of content : Businesses
  • BU = Business Unit
    • This is the 4th level of the hierarchy
    • Codification rule :  5 letters - the 2 first letters are the ones of the belonging GBU code
    • Used internally  - allows each GBU to sub divide its activities (criterias considered to split can be external market, external application, product lines...)
    • Only used for retrieval purposes, not as entry point for data entry
    • Examples in GBU FI "Fibras"": FITEX " Fibras Textile"
    • Exception/constraint: do not choose codes starting with "D", "DxDIS" codes dedicated to Discop BU's (examples: DODIS "Discop Acetow"...)
    • Approval process for creation of new BU / update of content : Businesses
    • Note that Business requests are subject to challenge from SBS FSL teams if they bring complexity (in setup and maintenance) without any demonstrated added value for performance follow up


5th and last level combines 2 different dimensions : MARK "Activity1" and CGU "Activity2"

  • MARK "Activity1"
    • Level for data entry in the IFRS reporting packages to enter P&L components and Acc Receivables
    • Level also directly used in BFC customizing (category scenario, consolidation rules, reports, Business users accesses...) and in Journal manual entries from Corporate (GAR and Controlling)
    • Codification rule :
      • Different practices coming from the past Solvay legacy (letters & digits - digits corresponding to Division codes from former Cheops conso tool from Solvay) and Rhodia legacy (letters)
        • example on the right side on GBU CH "Special Chem":
          • BU CHRAR coming from the Rhodia legacy includes Activity 1 codes made of letters only (ex CHAT)
          • while BU CHFLO "Fluorine" coming from the Solvay legacy includes Activity1 codes made of both letters & digits (ex CH3A)
      • Best practice: it is recommended to cross check that any new Activity1 code proposed for BFC (for both Solvay and Rhodia legacies) does not exist already :
        • 1) in Solvay ERP's (PF1, WP1) with FSL SU MAC Master Data team
        • and 2) in BFC dimension builder
  • CGU "Activity2"
    • Level for data entry in the IFRS reporting packages to enter Working capital, Fixed assets and Investments
    • Level also directly used in BFC customizing (category scenario, consolidation rules, reports, Business users accesses...) and in Journal manual entries from Corporate (GAR and Controlling)
    • Codification rule :
      • As for MARK dimension, different practices coming from the past Solvay and Rhodia legacies
        • example on the right side on GBU CH "Special Chem":
          • BU CHRAR coming from Rhodia legacy includes Activity 2 codes made of letters & digits (ex CHCGU113)
          • while BU CHFLO "Fluorine" coming from the Solvay legacy includes Activity2 codes made of letters & digits but not organized with the same sequence (ex CHCGU3AP)
      • Best practice: it is recommended to cross check that any new Activity2 code proposed for BFC (for both Solvay and Rhodia legacies) does not exist already:
        • 1) in Solvay ERP (PF1, WP1) with FSL SU MAC Master Data team
        • and 2) in BFC dimension builder
  • Approval process for both MARK and CGU:
    • Approval process for creation of new MARK and GBU : Businesses
    • Note that Business requests are subject to challenge from SBS FSL teams if they bring complexity (in setup and maintenance) without any demonstrated added value for performance follow up







3. OVERALL PROCESS FOR BUSINESS STRUCTURES UPDATES 

3.1. PLANNING

Process of Business structures updates is organized yearly through a "3 steps / waves" cycle

Best practice is to start in Q3 Y the identification and setup of Business structures changes expected for Go Live Jan 1st Y+1

Wave 1 - October Y: 1st set of expected changes needed for Budget

  • Needed for budget exercise in PREV reporting category
  • Only new structure items are created with "NEW " value in "Changes" characteristic of both Actvity1 and Activity2 reference tables from Dimension builder (to avoid usage in Y Actuals)

Wave 2 - December Y : 2nd set of changes (late answers from GBU's) / Creation of New objects in BFC

  • Late decisions from GBU's (not communicated earlier in October)
  • Only new structure items are created with "NEW " value in "Changes" characteristic of both Actvity1 and Activity2 reference tables from Dimension builder (to avoid usage in Y Actuals)

Wave 3 - end of January Y+1 : Activation/Deactivation in BFC for January Y+1 reporting

  • GO to be given by Corporate Controlling - when Year end Y-1 results finalized
  • Around January 25th to have few days for BFC set up before January reporting generation
  • In this last round:
    • "NEW" values removed to blank
    • "OLD" values set up to block usage on Activity 1 & 2 not to be used anymore in Y+1 ACTUALS
    • updates in hierarchies content (change of links)
    • update of descriptions to add OLD when required
  • Not forgetting impacts on Business users accesses: as Business accesses are based on GBU codes, any creation of a new GBU code is expected to require updates (new GBU code to be added) of accesses of Businesses users working for the new GBU
  • Not forgetting impacts on Filters from Dimension builder: such filters have been created to allow artificial combination of several GBU's (to keep track of historical business structures)


Any change of Business structures out of this yearly cycle (i.e. during the year) is technically feasible in BFC structures. However never recommended as restatement of past months (since Jan 1st Y+1) is a heavy exercise in ERP's


3.2. ACTORS AND REFERENCE FILE TO COLLECT Y+1 BUSINESS STRUCTURE CHANGES

The following actors are involved:

  • Corporate Controlling
    • Coordinates the collection of changes with Businesses and inside Corporate Controlling
    • Challenges, when appropriate, the proposed changes - can consult for advice BFC Admin and FSL SU MAC Master Data team
    • Communicates the changes received to BFC Admin and FSL SU MAC Master Data team
    • Controls the BFC set up of changes of Business structures before piloting to BFC Production database


  • BFC Admin team:
    • Create and update the reference file collecting the BFC Business structures changes for Y+1

    • Reference file is created from save as of "Y current business structures"
    • Then it is updated highlighting the different type of changes required for Y+1 (received from corporate Controlling): 
      • new objects to be created and used from Y+1 reportings - yellow back ground in the example above
        • As explained earlier in this procedure, BFC Admin will propose the BFC codification, checking with FSL SU MAC Master Data team that no constraint with ERP's
      • old objects not to be used anymore from Y+1 reportings - pink back ground in the example above
      • change of links (transfers) inside hierarchies - red back ground in the example above


  • Once changes collected and new required codifications are validated, BFC Admin will perform the associated BFC customizing
  • Updates Business users accesses and Business filters, when required, before January Y+1 reporting


  • FSL SU MAC Master Data team:
    • Challenges when needed the requested changes
    • Ensure coordination of Business structures updates in the ERP's with Business Data Administrators, FSL Master data teams and IT
    • Collaborates with BFC Admin to align on BFC codifications
    • Ensure communication within Finance network (FSL, Businesses...)


4. CREATION / UPDATES OF BUSINESS STRUCTURES IN BFC

4.1. CREATION OF NEW OBJECTS

Timing : Wave 2 - December Y

Sequence of creation: From TOP to BOTTOM

  • In case of creation of new objects at each level of the hierarchies and linked each others , it is recommended to start the creation at the upper level of the hierarchy.
    • Example below creation of new Activity 1 associated to a new BU => 1st BFC Admin will create the upper level (BU) and then after the lower one (MARK)


  • Also recommended to start 1st creating new CGU "Activity2" codes and then after new MARK "Activity1"


Connect to BFC_Top:

Select the “Dimension Builder” module in the "Setup" domain.

Then select the MARK and CGU dimensions and expand the hierarchy to access to the upper levels.





4.1.1 Creation of new CGU "Activity 2"

A CGU can be created from the scratch in the option "New Reference Member", or through “Save As” from an existing CGU code.















In the tab “General” and Translation, enter the information in the following fields as indicated in the Reference file:

  • Code
  • Short description - EN &FR (same ones)
  • Long description - EN &FR (same ones)








In the tab “Properties”,

  • Group of activities: COMPULSORY characteristic
    • Enter the belonging BU value defined in the Reference File









  • Changes: 
    • Before Jan Y+1: NEW value to be entered - this is will prevent from usage in Y reportings
    • End of January Y+1, NEW will be removed and field will stay empty => the new object will be available for usage in Y+1 reportings


  • CGU used in RSB transfer: OPTIONAL characteristic
    • this filed is used in RSB consolidation rules to automate some transfers between CGU from an old to a new code) 
    • Value , if any, has to be communicated in the Reference file - if empty, field has to stay empty










4.1.2 Creation of new MARK "Activity 1"


A MARK "Activity 1" can be created from the scratch in the option "New Reference Member", or through “Save As” from an existing MARK code.








In the tab “General” and Translation, enter the information in the following fields as indicated in the Reference file:

  • Code
  • Short description - EN &FR (same ones)
  • Long description - EN &FR (same ones)







In the tab “Properties”,

  • Group of activities: COMPULSORY characteristic
    • Enter the belonging BU value defined in the Reference File











  • MARKET type: COMPULSORY characteristic
    • 4 different possible values:
      • M "Market " - most common value
      • E "Entreprise" - this value has to be selected for new MARK created to host unallocated activities of the GBU (codes such as xxNR)
      • PM "Generic market partner code"  - this value has to be used for new fictive MARK created to host inter BU's sales inside the same GBU (codes xx-INTERBU where xx stands for the GBU code) - usually 1 generic market partner code created for each GBU
      • DISCOP - this value has to be used for new MARK created to host Discontinued activities (post M&A items)
    • Refer to the value indicated in the Reference File





  • CGU value (valeur de CGU des marchés): COMPULSORY characteristic
    • This field allows to link MARK and CGU, link that is needed to manage elimination of margin in inventories in the IFRS consolidation process (%Margin elimination in P&L thus requiring MARK value and in Bal Sheet stocks thus requiring a CGU value)
    • Refer to the value indicated in the Reference File


  • Changes: 
    • Before Jan Y+1: NEW value to be entered - this is will prevent from usage in Y reportings
    • End of January Y+1, NEW will be remove and field will stay empty => the new object will be available for usage in Y+1 reportings


  • MARKET used in RSB transfer: OPTIONAL characteristic
    • this filed is used in RSB consolidation rules to automate some transfers between MARK from an old to a new code) 
    • value , if any, has to be communicated in the Reference file - if empty, filed has to stay empty















4.1.3 Creation of new BU

A BU can be created from the scratch in the option "New Reference Member", or through “Save As” from an existing BU code.

Note that it can be created either using the MARK or the CGU hierarchy (no need to create twice in each as 1 single BU table common to both hierarchies).


Note: No need on BU level to manage the specific fields existing on MARK and CGU (change, RSB transfer, value for margin in inventories...) as BU level is not used for data entry but only for retrieval purposes.



In the tab “General” and Translation, enter the information in the following fields as indicated in the Reference file:

  • Code
  • Short description - EN &FR (same ones)
  • Long description - EN &FR (same ones)








In the tab “Properties”,

  • Enterprise: COMPULSORY characteristic
    • Enter the belonging GBU value defined in the Reference File







4.1.4 Creation of new GBU / SEGMOP / CLUSTER

Customizing principles are the same than the ones explained for the BU "Business Unit" level.

Note that those levels can be created either using the MARK or the CGU hierarchy (no need to create twice in each as single table for each GBU SEGMOP and CLUSTER levels common to both hierarchies).

Note: As on BU level, no need on those levels to manage the specific fields existing on MARK and CGU (change, RSB transfer, value for margin in inventories...) as they are not used for data entry but only for retrieval purposes.


4.2. UPDATE OF OBJECTS: OLD & EMPTY VALUES (MARK"Activity1" and CGU "Activity2" levels only)

Timing : Wave 3 - end of January Y+1

Connect to BFC_Top:

Select the “Dimension Builder” module in the "Setup" domain.

Then select the MARK and CGU dimensions and expand the hierarchy to access to the upper levels.


4.2.1 SWITCH FROM "NEW" TO "EMPTY" VALUE ON CHANGE FIELD 

Doing this move, the new created object (either MARK or CGU) will become available for usage in package data entry in Y+1 ACTUAL's reportings thanks to filters integrated in BFC users accesses providing accesses only on MARK and CGU objects without "NEW" value (=empty) as characteristic :

  • Filter "MARCHACTUELS" for MARK dimension:
    • only contains MARK with empty value (meaning of the "cross" blue icon) on "Changes" characteristic






  • Filter "CGUACTUELS" for CGU dimension:
    • only contains CGU with empty value (meaning of the "cross" blue icon) on "Changes" characteristic







In the tab “Properties” (either CGU or MARK table), 

  • Changes: 
    • NEW value to be removed and field to stay empty - follow the instructions from the Reference file to get the list of objects subject to this switch end of January 











4.2.2 FLAG AS "OLD"

Doing this move, the existing object (either MARK or CGU) expected not to be used anymore from Y+1 will become blocked (unavailable) for usage in package data entry in Y+1 ACTUAL's reportings thanks to filters integrated in BFC users accesses providing accesses only on MARK and CGU objects with empty value (different from OLD and NEW) on "Change" characteristic :

  • Filter "MARCHACTUELS" for MARK dimension:
    • only contains MARK with empty value (meaning of the "cross" blue icon) on "Changes" characteristic






  • Filter "CGUACTUELS" for CGU dimension:
    • only contains CGU with empty value (meaning of the "cross" blue icon) on "Changes" characteristic










In the tab “Properties” (either CGU or MARK table), 

  • Changes: 
    • OLD value to be selected - follow the instructions from the Reference file to get the list of objects to be put as OLD (pink background) 

























In the tab “Translation” (either CGU or MARK table), 

    • Both FR and EN translations to be updated to indicate  - follow the instructions from the Reference file to get the list of objects to be put as OLD (pink background) 








4.3. CHANGE OF LINKS INSIDE HIERARCHIES (ANY LEVEL INSIDE THE HIERACHIES)

Timing : Wave 3 - end of January Y+1

This move has not impact on data entry in reporting packages. However, it impacts the aggregation of each level and thus business results obtained in retrieval reports. 

Note that MARK and CGU hierarchies are not subject to any historisation/archiving. This means that any transfers inside will apply to all reporting periods (past, current and future). This is why set up of manual filters (MARK and CGU dimensions) can be requested to BFC Admin by Corporate Controlling to artificially rebuild the past hierarchies aggregations and allow data retrievals on the past using those filters. 


Connect to BFC_Top:

Select the “Dimension Builder” module in the "Setup" domain.

Then select the MARK and CGU dimensions and expand the hierarchy to access to the upper levels.


Transfers / change of links are highlighted with red backgroung in the Rerefence file - they can be:

  • either transfers of a CGU "Activity2" or a MARK "Activity1" from one BU to another BU
  • or move of a BU "Business Unit" from one GBU to another GBU
  • or move from a GBU from one SEGMOP to another SEGMOP
  • or move from a SEGMOP from one CLUSTER to another CLUSTER






In the tab “Properties” (either CGU or MARK or BU or GBU or SEGMOP table), 

  • Changes: 
    • Replace the existing upper level code by the new one
    • in the example listed before: on MARK "TSDP" change the BU code from TSDPH to TSMIN




Example in 2022 Business structures changes: TSDP and TSFU moving from BU TSDPH yo BU TSMIN


4.4. FINAL VALIDATION & CONSISTENCY CHECKS (APPLICABLE TO EACH WAVE)

Timing : @ each wave of customizing

Step1 - BFC Admin team to perform consistency checks in BFC_TOP (customizing database):

In each MARK and CGU table,

  • Select "Load data" mode and display in columns all characteristics  / descriptions FR and EN
    • Filter on "last changed" to see the latest customized objects
    • Compare changes done versus Reference file to ensure nothing has been missed
  •  


  • Select "Hierarchy" mode, expand the Hierarchy and
    • Search for NEW objects created from Reference file to check their description and right place in the hierarchy
    • Search for OLD objects listed in Reference file to check that their description has been well updated ("no more used to be used from ...")
    • Search for TRANSFERS listed in reference file to check that they have been moved at the right place in the hierarchy

Example for NEW object NBGH (MARK) and NBGH2 (BU)



Example for OLD object CMPM (MARK)


Example for TRANSFERS of TSDP (MARK) from TSDPH (BU) to TSMIN (BU)


Step 2 - BFC Admin team to pilot changes to BFC_WORK (testing database) for review and validation from Corporate Controlling

  • BFC_TOP: Objects to piloted : MARK and CGU references tables members (it includes the full hierarchies content: BU, GBU...)
  • BFC_TOP: Type of task to be used: FCWORK code (not to confuse with sending of tasks to Production)


  • Connect to BFC_WORK, launch Scan and Reception of FCWORK task
    • Check in Dimension Builder in both MARK and CGU tables that objects (NEW / OLD / TRANSFERS) are there
  • Inform Corporate Controlling asking for review and final authorization to pilot to BFC production



5. PILOTING TO BFC_PRODUCTION 

Timing : @ each wave of customizing ONLY when authorized by Corporate Controlling

  • Task to be prepared in BFC_TOP: EXPL-GESTION task including MARK and CGU Reference table members

  • Launch the sending of the task 
  • Connect to BFC_PRODUCTION
    • Launch Scan
    • Once Scan terminated, launch the reception of EXPL-GESTION task
    • Check in Dimension Builder in both MARK and CGU tables that objects (NEW / OLD / TRANSFERS) are there
  • Confirm to Corporate Controlling the effective transport of Business structures changes to Production


6. DOCUMENTATION UPDATES IN GAR AODOC




7. RELATED IMPACTS ON BFC USERS ACCESSES




END OF THE PROCEDURE