Objective and Scope

The scope of this procedure is to explain how to handle and process Solvay Group Company requests, named Intragroup requests.

The support is provided by MSD team (Materials & Structure Data - former APDM) and by Edmundo Fernandes (RtR team). 

The maintenance of the intragroup data base (vendors, customers) it is the responsibility of the DATA team (Lisbon) - worldwide.

Vendors and Customers intragroup are identified by the Corporate Group 0000800001 SOLVAY. The exceptiom is the DOMO company where the classification is done in the field Trading Partner with the code "DOMO" .

The support concerning DOMO companies is performed by Ramlah Mohamed.

Intragroup requests

Corporate Affairs (Philippe Vanloeij sends a communication via email every time we have changes on the company Structure. MSD team receives that information and creates a ticket for Data Lisbon team in order to proceed manually with the changes or creations on a specific customer or vendor.

It can also be received a request from End Users, due to that we should confirmed first with APDM team if indeed the creation or change should be performed or not, as they have the necessary information to validate the request.

When handling Intragroup requests, it is necessary to gather and analyse existent data in the system, concerning the Solvay Group vendors and customers. This data can be collected from the existing information already inserted in SAP, using transaction ZPRC, in order to complete and confirm the information given by the requesters. 

These can submit requests to update Vendors or Customers, using the HQ mailbox (brussels.codifhq@solvay.com) or through the Freshdesk ticket service (Group PtP DA EMEA) . In any case, the information given has to be accurate and in compliance with the rules mentioned in this procedure. Workflows requests are rejected by the RPA.

• ZPRC

Via transaction ZPRC it is possible to check the existing inputs for all the Solvay Group companies.

Once inside the transaction, it is possible to select the necessary data according to the given inputs (e.g. country, corporate group number, trading partner, company name, among others):

You can analyse all the establishments linked to the company needed by selecting the line and clicking in DISPLAY:

Then click in "All establishments" or "Valid establishments":

NOTE: For Intragroups, the Search Term corresponds to the ‘Abbreviat.’ of the plant. 

To enter an establishment, double click on it. 

It is possible to detect in this area, the information concerning which of them is defined as the prime Establishment: marked as "PRI" is the establishment which corresponds to the Payer (Z**1) or (Z**4), marked as "ADM" is the establishment which corresponds to the Payer (Z**1 or Z**4) or to the Payer-bis (Z**3 or Z**5). The main ADM will be the one marked with PRI. The extra ADMs will normally be payer-bis. The other establishments are normally created as Z**8.

We can have two Z**1 but the main payer should have the main Credit, if the credit is not the same for the two payers than we need to split and create one Z**1 and other Z**4 (any doubts please ask for help MSD team).

Some plants are not available in this transaction. In this situations you can see them in the table T001W.

Any relevant input(s) for this company can be collected in this area (if communicated):

By clicking in the field Address you will be able to see the companies address, complete search term and contacts:

• SE16

Table T001 - will provide the company codes information (local view)

Table T001W - will provide the plant codes information (local view) 

NOTE 1: The companies which provide services as external party (or external storage) can only be found in the Plants Table. In this type of situations the information retrieved during the creation/modification cannot be performed using the ZPRC .

NOTE 2: Subcontracting vendors/customers are not considered intragroup. Example:

They are maintained by RIGA team. When detected this vendors/customers add to the search term 2 the code CO.

Master data creation

The creation of the intragroup vendor/customer is performed in the main system (PF1_050) respecting vendor and customer data base procedures.

All the information received of the company must be checked in the transaction ZPRC.

Then, a check of the data base must be performed to avoid duplications. It is used the transaction SE16_LFA1 and SE16_KNA1 (PF1_050):

If a new Company is created, you have to create at least a vendor and a customer (payer) corresponding to the head office (depending on the company structure) - type of account group Z**1.

An important rule concerning the Payer is that only one payer can exist for a legal company.

If a new Establishment is created for an existing company to send separated invoices from a working unit - type of account group Z**5. This customer must be linked to the payer.

If a new Establishment is created for an existing company, a vendor and a customer have to be created with the address of the new establishment - type of the customer account group is Z**8. This customer must be linked to the payer.

If a new External Storage is created a new vendor or/and customer can be created with the Name 1 field equal to the SOLVAY company name and in the Name 2 field "C/O + Name of the storage". The address will be from the Storage like the VAT ID. The Bank account will be from the CICC bank.

If a new Ship-To (Z**2) is created the vendor creation is not needed.

To create you will use the transactions XK01 (for the vendor) and XD01 (for the customer):

VENDOR	CUSTOMER	Information
Ex.: Establishment of the Company 5726 - Plant MRMA
		The Account Group is chosen according to the country of the company. Regarding the customers they can be: Payer: Z**1 or Z**4; Payer-Bis: Z**3 or Z**5; Sold-to: Z**8; Ship-to: Z**2
		Name, Address and Email (interco-sbs-rtr@solvay.com) are mandatory. Name and Address will be available in the ZPRC if payer or PF1 sold-to. Search Term 2 - can be added if provided (Automatic Interco or Non-Auto Interco)
		Vendor and Customer must be linked here; Trading Partner is mandatory, corresponds to the Company Code; Authorization field: HQ Group Key: 0000800001 (GRCL200131 in RCS) VAT will be available in the ZPRC if applicable.
		Z*3, Z*5 and Z*8 must have a main payer code added to the field PRS Main Payer.
		If requested link to the PF1_020 system.
		The tab Contact Person is maintained at local level (PF1_020 / WP1_400).
		If requested link to the WP1_400 system. Regarding the customer master data: 01 - to send a sold-to (Z*8) 02 - to send a ship-to (Z*2) 03 - to send a payer (Z*1/4)
		Class: G Customer Classification: G

NOTE 1: For European Vendors, the VAT number is mandatory (even if the vendor has to be used in an American Company).

NOTE 2: Trading partner can never be changed, even if the company is sold to another Group.

NOTE 3: A vendor “NON AUTO INTERCO” should be settled with the search term 2 “NON AUTO INTERCO” and not linked to an Intercompany customer. Also this type of vendor can be a copy of an existing vendor AUTOMATIC INTERCO. The search term 1 may contain the acronym CCCY (example: RD/PR (CCCY).

EXCEPTION: external party companies the creation is based in the information received. This customers can only be created as Z*8. It is only checked by the team if a Plant with the same data already exists.

NOTE: An external party company can exist in the system as intragroup and as a standard vendor (it is not considered duplication).  

All the creations must be transported to the system DF1 (BD14: Z_CRE_ERP - ERP Vendor Master distribution).

Master data update

When it is processed a Name or Address update a check of the data base must be performed to avoid duplications. It is used the transaction SE16_LFA1. The update must reflect the information available in the ZPRC table. 

VERY IMPORTANT: every change performed in the vendor master data must be reflected in the customers master data. 

If a Company is deleted, you have to mark for deletion all the vendors and customers already created .

If a company changes of location, the new address must be entered in all the vendors and customers concerned.

The block/deletion of an obsolete intragroup must follow these rules:

1. The ADPM team must confirm the action;
2. Block and mark for deletion of the vendor/customer;
3. Send an email to Logistics team:
   1. PF1: sbs-emea-data-log-pf1@solvay.com
   2. WP1:  sbs-emea-data-log-rcs@solvay.com
4. Create 2 clone tickets:
   1. Materials team - that after having completed the necessary actions, should transferred to the SRM team
   2. RtR Intercompany team

The data in the search term 1 and 2 of the vendor cannot be replaced by ****. 

CONTACT PERSON

This information can be updated if requested using the transaction XD02:

A customer can have several contacts with the name and the same function. Nevertheless each name must have a different contact. 

Use the button Details  to see the Contact persons number:

This code can be added if needed to the customer partners (sales area view). In this case it needs to have the Function and the Method fields filled.

A Contact Person Name cannot be erased if linked to a customer through the partners data. During the deletion the system will inform you if detected this link.

CUSTOMER Account Group change

This update is performed only in PF1. The change can only be performed to the same level or to a below level. A customer Z101 can be changed to a Z1B1, from Z1B8 to Z1B2 is also accepted, from Z1B8 to Z1B1 it is not accepted.

To avoid duplications first it is used the transaction SE16_KNA1 (PF1_050). Then in the local system (PF1_020) it is used the transaction XD07:

First it is inserted the customers code, then ENTER and then ENTER. To chose the new account group click in the button -  :

Select and save.

The change have also to be performed in the PF1_050. It is used one more time the transaction XD07.

INTERNATIONAL version update

The international version of an intragroup plant can be checked in the transaction SM30 - table V_T001W and for an intragroup company SM30 - table V_T001 (used in the local system). 

As soon as confirmed it can be updated on vendor and customers master data (in the main system).

Miscellaneous 

Solvay Companies must NOT be created as ZZCD. If so, they must be marked for deletion. 

Exception: “USE ONLY FOR LOAN” (Materials & Structure Data must be contacted to see the exception).

If in RCS, an intragroup vendor is created as normal vendor and as miscellaneous creditor (Z010 + Z011), if the normal vendor can be used for P. Orders, then there is no reason for creating ZZCD.

In particular situations, Solvay companies can perform loans to other Solvay companies. Only FI documents will be made on these specific vendors. 

NOTE 1: The reconciliation account for this type of vendors is 16800501 or 16800101.

NOTE 2: Vendor must have a link with the main system.

NOTE 3: In Name 2 and Search Term 1 fields, the expression ‘LOAN’ must be applied.

Company, Purchasing and Plant view

The creation at Company Level and Purchasing level is performed with the data provided. If not it can be created with a reference vendor/customer.

The intragroup vendors must be marked with the code ZCCY inside the Company code:

And when not created the Reconciliation Account the ticket must be passed to the RtR team (RtR Intercompany Group).

The WP1 vendors can only be linked to the Purchasing Organisation 3200. The PF1 vendors can only be linked to the Purchasing Organisation ZZ80.

This rule is only applicable when relation is between Solvay companies. For example a Domo with a Solvay, the P. Organisation can be other codes.

The link with the Plant is performed for the vendor code at a Purchasing level with the transaction XK02 (applicable only for “Automatic Interco” ):

Regarding a Customer code, the standard data is:

(The Payment Terms are also applicable for the Vendors code)

Bank data maintenance

The Intragroup bank accounts are maintained in the SOLIA portal:

• Solvay Treasury North America Online
• Solvay Treasury Online

And also:

• https://datastudio.google.com/u/0/reporting/1-P0ROqxzsB-9iusIcm1S9JbEDL6ec7cz/page/sfjO
• https://docs.google.com/spreadsheets/d/1JLG538hq69uhQL2aNoRtH5KQLUgd53zrZIiaAx63KOc/edit#gid=0
• PL bank accounts: https://www.podatki.gov.pl/wykaz-podatnikow-vat-wyszukiwarka

All this bank account can be inserted in an intragroup vendor/customer (do not need confirmation).

When the new bank account is not available to be confirm an email must be sent to François Paulus.

The bank account is inserted according to the country rules.

Bank Keys creation

The creation of a bank key is performed in the PF1_050 system using the transaction FI01.

The mandatory fields are:

• Bank Name (Name of the bank);
• Bank Number (Bank identification used in the IBAN codification);
• SWIFT Code (International bank code that identifies particular banks worldwide. It’s also known as a Bank Identifier Code (BIC) - consists of 8 or 11 characters).
  • Format: Bank code (4) + Country Code (2) + Location code (2) + Branch code (optional + 3). 
  • The code must be confirmed using the website - https://www2.swift.com/bsl/index.faces .
    
    

To transport the data to other systems it is used the FI08:

The update is performed using the transaction FI02.

A complete new Bank Name normally reflects a new swift. Special attention should be paid to these situations. Cases like the Netherlands and Great Britain bank accounts the SWIFT impacts the Bank Key and the IBAN. Before changing the bank key an extraction needs to be performed through the transaction SQ00. All the vendors using the Bank key (that will be changed) need to be analysed and amended if needed.

NOTE 1: A Bank key cannot have symbols - example : BG BFTBBGSF$01.

NOTE 2: When not confirmed the 3 numbers of the branch is not allowed the introduction of 3 Xs - example : AT 18130 (swift BWFBATW1XXX).

Customer Sales view

The link between a Customer code and a Sales area is performed at a local level.

The information can be provided by the requester or it can be retrieved from the SE16_KNVV (to use a customer as reference).

The link is performed using the XD01:

NOTE 1: Inside the tab Partners a customer not payer need to have the main payer as PY and BP. The main payer can be checked in the Extra Master data info.

NOTE 2: Inside the tab Sales, in order to enable the cross-selling functionality "B" needs to be populated in PP cust. proc field (Customer procedure for product proposal).

NOTE 3: Account Assignment Group for Customer is 02 (trade).

When informing the requester of the conclusion of the request it must be mentioned which customer was used as a reference.

• Error messages:
• In situations where the link is not possible due to a red error message, the operator must pass the ticket to the MSD team (IS-DATA-MSD group).
• A yellow error can also occur:

To fix is necessary to go to the tab Documents and add the code ZEI1 plus the Transmission medium needs to be 8:

Useful information

Definitions

• Payer (Z*1 and Z*4): customer who is invoiced. It does not mean that he will necessarily receive the invoice or that he will make the payment himself, but that he is legally responsible for the payment.
• Payer-bis (Z*3 and Z*5): It is a payer linked to the Payer (legal responsible) through the Credit Limit. It is created when the customer wants the invoices separated from a working unit, but still belonging to the same Credit Control Limit. So, it is linked to the Payer as it uses its Credit limit.
• Sold-to-party (Z*8): customer who orders. It must be part of the same legal company as the payer. He must have the same VAT code than the Payer he is linked to.
• Ship-to-party (Z*2): customer who received the goods. Only one ship-to-party can be created per company/address. Only exists at General Level. Does not need a Payer.

• External Storage: store not belonging to SOLVAY companies. Example: SOLVAY MEXICANA S. DE R.L. DE C.V C/O BRENNTAG MEXICO S.A. DE C.V. (customer 2501106).
• Automatic Interco: "Automatic Interco” vendor codes are used to create purchase orders from which you can directly create outbound delivery from the supplying plant. The PO is created automatically with reference to Material and Price. Should be linked to the Plant via Purchasing level.
• Non-Automatic Interco: "Non-automatic Interco” vendor codes are used for intercompany flows between plants but with standard purchase order (receiving plant side), and standard sales order from supplying plant. And also the difference in the purchase order when using auto or non-auto vendor code is in the price determination which is not the same. 
  
  
• CCCY: Consignment Cross Company (customer field is not filled)
  
  

• CSR: Customer service representatives interact with customers on behalf of an organization. They provide information about products and services, take orders, respond to customer complaints, and process returns. We can found this information on the partner functions of the customer.
  
  

• Credit level: any request to extend at credit level of a customer payer needs to be forward to credit-management.europe@solvay.com (this data is analysed through the transaction FD32).

Group Key - is maintained by the MSD team using the transaction ZPRA.

Intragroup invoices - are handled by RtR team. The tickets needs to be send to the Freshdesk Group RtR Intercompany.

SOLIA services portal / intragroup bank accounts - support can be provided by Ana Rita Cunha.

• CICC banks can also be found in the Google sheet.

ZPRC table - maintained by Philippe Van Loeij

RPA message to an intragroup workflow request:

"CET Operador RPA 3 (PT99376086): REJECTED the request:
#RPA - Rejected - Based on purchasing recommendations the inter-company process / PAX entities requests linked with Solvay Companies should be managed outside the VWF. Please proceed in creating a Freshdesk ticket for Data Operations Team with your request."

Links

• Currencies: 

Work charters

• Payment Terms: