Objective and Scope

Rules on General Data

Explains the rules defined for the data controller to check the content of a request. Step previous to check made by Credit Management. Done before final validation and recording into PRS (Permanent Reference System).

• All requests on customers in PRS (PF1-050) for systems PF1 and PI1 handled in the Workflow.

• Mission entitled to the Data Controller, which constitutes the second step within the procedure for handling client level data of Customers with validation through Workflow.

• The whole procedure for creating or updating a customer in PRS (PF1-050) is described in the following document.

Introduction

General workflow process steps

• • 1^st - The requester enters the data in the SAP workflow form and submit its request
  • 2^nd - The request is available in the workplace of the "Data Controller" who must check the request and approve or reject it, according to the Data management CORE rules.
  • 3^rd- If the customer is a "Payer", the request is available in the workplace of the "Credit Manager" who must check and update the credit data.
  • 4^th - The customer is automatically created in PRS.
    
    
    Afterwards, the customer is sent to the operational environments by the usual ALE procedure.
    
    The data inserted in the workflow is under the responsibility of the Requester. SBS only verifies if the information is in accordance with the CORE rules.
    
    The second step of the procedure, i.e. the first validation, is intended to check the request according to the Data management rules. It is executed by a Data Controller, whose mission is detailed in the CORE rules of the present document. The possible actions are described in (VALIDATION ACTIONS OF THE DATA CONTROLLER)
    
    If the check is positive, the request is approved and then automatically recorded into PRS, except if it is a 'Payer', as the request becomes available for checking and approval in the workplace of the Credit Management, i.e., a second validation.
    
    Otherwise, the Data Controller either returns the request to the requester, or rejects it definitively, always using the Communication Area to explain how the content of the request does not conform to the rules.
    
    The GAC Data Management team, who is functionally responsible for the customers and vendors data maintenance, must be contacted for any problem concerning this procedure.

Request types

• • Creation.
  • Modification

Accesses

Requesters access

Access for Requester is done via transaction Z1S_CWF_REQUEST in PF1_050 system.

Data Controller access

Access for Data Controller is done via transaction SBWP in PF1_050 system or simply clicking in the below Icon.

Open the folder "Workflow" in your Inbox
The list of the requests appears on the right part of the screen.
Double click on the line of the request you want to open

Data controller Rules – Broad description

Standard Version

Once the Data Controller selects a request, the main screen consists in (see example below):

• • a line of workflow functional action icons
  • a header with the administrative field
  • 8 sheets which contain the customers data
    
    

The control action rules of the Data Controller are defined as follows:

• • Verify Communication Area
  • Verify No duplicates (Rules on Duplicates when creating new records)
  • Rules on General Data
  • Rules on General Data 2
  • Rules on Bank Accounts
  • Rules on remaining tabs (Phone/Fax/Mail, Credit, Companies and Distribution) 

Specific rules apply on requests for modification: (Specific Rules on requests for modifications)

International Version

The international version contains the name and address of the customer in non European characters (Kanji, Chinese, Cyrillic, etc).
It must never be checked by SBS (totally under the responsibility of the requesters)

For information only: Access to the international version: click on the button "Internat. Versio…" in the screen "General data"

Then, the following screen appears

It is only possible to see the right characters only if the language selected is the right one (JA for Japanese, ZH for Chinese, BG for Cyrillic). The language code will determine the characters appearing in the international version.

SBS Data Controllers are not in charge of the international version, which is totally under the responsibility of the requester.

In mode "Change", neither click on this button, except if you are logged in the appropriate language (Chinese, Japanese, Bulgarian)

Rules on Duplicates when creating new records

The check on duplicates is done by the standard SAP Matchcodes (transaction XK03).

• For customers located in EU, a first search must be done with the country code (mandatory) and the VAT code.
  Then, if this search is negative, a second search must be done with the country code and a significant part of the name in upper case and lower case (for example *IANGSU* and *iangsu* if the name is CHINA JIANGSU INTERNATIONAL)
• For customers out of EU, only the second search can be done.
  
  
  Request:
  
  
  
  
  Result:
  
  

Rules to Check Duplicates

Rules on General Data, Phone/Fax/Mail, Bank, Credit, Companies, Distribution and Communication Area

Globally each field must follow its rules detailed in the documentation on Customers.

General data 1

The following fields are mandatory: line 1 of the Name, Country, Account Group, Language, Search Term, and City.
Some fields are required according to the Country.

Customer name should be in accordance to the name on legal documents. The workflow needs to be sent back to the requestor in case the Customer Name includes any of the below.

1. Customer name includes C/O's (Care Of) name
2. Customer Name includes DBA (Doing Business As)
3. Customer Name includes T/A (Trading As)
4. Customer name includes A/C (Account)
5. Customer Name includes the location of a plant/warehouse/branch/factory/office/department/center/division
6. Customer Name includes tax codes
7. Customer Name includes any other illegal character
8. Customer Name includes part numbers
9. Customer Name includes address
10. Customer Name is in small alphabets
11. Customer Name includes the name of a person or department with ATTN/ FOA
12. Customer Name includes abbreviation/alternate name following the complete name of the customer.

Regarding the Care of Field :  If need to be check duplications regarding this data, must coordinate table ADRC with KNA1 (SE16) specially when are many results.

Table ADRC give us the Name, Care of, Country and Region.

Table KNA1 will help to filter by Street and account group.
 
  Note (Intragroup): When checking a request concerning a Group customer of vendor, or that seems to be a Group entity (even if there is not complete certainty), the Data Controller should not process the request. Reject the request, with the following information: 

• Please proceed in creating a ticket for Procurement with your request in Service One Portal:
• Procurement / Procurement Data & Analytics / Vendors out of purchasing / Update an intercompany account (vendor or customer)

General data 2

Tax code 1, Tax code 2 and VAT registration number are required for customers, according to the country.

 
  SOUTH KOREA: Payers should have defined "type of business", "type of industry" and "name of representative". Not mandatory.

Telephone/Fax/Email

These fields are checked automatically by the system and are one of the causes of requests with errors (described chapter Requests processed in error).

The email address information format should be: xxxxxxxxx@xxxx.xx, with only one email address per line and without any additional inputs (including blank spaces).
If such requirements are not followed, the data controller should return the WF request for correction by the Requester, mentioning the correct rules.
The exception is if it is a typing error, e.g. a blank space or an extra point.

The data controller must check:

• • The global coherence of the entered data.

Telephone and fax numbers should only have numeric digits in its fields but it is also possible to have: "/". Any other special characters ("-", "+", "&", etc…) must be removed. The requester should be informed of correct practice.

FRANCE: 'Dataline' and 'Teletex' are used for French pharmacies. They have to be both inserted and used at the same time -

• • Teletex = 3 digits, numerical
  • Dataline = generally 6 or 7 digits, numerical

ITALY: Phone and Fax number must contain 0 before the city code number.

JAPAN: No specific rule (International prefix = 081)

CHINA: Hyphens "-" are allowed, on both, Phone and Fax

Checking Bank account Duplicates

Bank accounts

A bank account is not mandatory, but if entered it must be correct according to the SAP rules (checked by SAP).
 
 
In some countries, an IBAN code is required and must be calculated by SAP.
If no IBAN code is introduced, nothing has to be asked to the requester, as each night, a program is running which generates automatically the missing IBAN.
 
   Netherlands: Bank Key must have 8 and 12 digits. If it has less than that (e.g. 4 digits bank keys), the following Name appears in the Bank Name area: "DELETED – Please never use this Bank Key".
The bank key in the list below have been created wrongly:

So, if the requester enters one of these banks, the request must be returned, and the requester must enter a right bank key.
NB: This kind of wrong bank key doesn't exist only for NL, all the banks mentioned as "deleted" must no longer be used.

IBERIA: The bank data for a customer is not mandatory except if the payment method is L ("Recibo Domiciliado").
In all companies (except Pharma), the requesters have to fill the payment methods and payment terms in Companies tab.

ITALY: The bank data for a customer is not mandatory, except if the payment method is B ("Ricevuta Bancaria").
The bank account should have 12 digits. Italian bank accounts are composed by the account number (12 digits numerical), and the control key (one digit alphabetical).
As the control key is included in the IBAN code, it is mandatory and must be inserted in column CK (control key)

The Control key is the letter in the 5th position of the IBAN

If this control key is missing, the request is in error and the customer cannot be created automatically.

To check Italian bank data (with ABI e CAB):

http://online.bancaroma.it/site/labanca/abicabbdr.asp

List of countries with IBAN code can be checked on: http://www.tbg5-finance.org/?ibancheck.shtml

GERMANY: bank accounts must have 10 digits (numerical). The IBAN code must always be checked with the IBAN Checker provided by the Swiss Interbank Clearing, or on the website www.iban-rechner.de

JAPAN: A new field has been added for customers - Japanese Company Code for Account holder.

It must contain the code of one of the 3 Japanese (0360, 5799 and 5846) Solvay Company. This field must never be changed by SBS.
Note: These 3 Japanese companies opened specifics "sub-accounts", linked to their own bank account for each customer. This "sub-account", named "Virtual account" by Conexia, must be registered in the customer master data.

When a customer is created, it is automatically filled in by a specific program (out of the workflow), with a specific bank type ZJP1.So, in the requests for "creation", the bank data must be blank.
For additional information regarding modification of bank data for Japan, check Bank Data .

SAUDI ARABIA:
Bank key: Swift code (8 or 11 positions)
Bank Account: Even if the bank account on the IBAN has 18 digits, it's not necessary to complete with zeros if the bank account on the invoice has less than 18 digits.
Check digit: Must be blank.
Example:

When customer confirms more than one bank account for different types of payment (GBP, EUR, CNY), it is possible to use bank types beginning by the 3 letters of the official currency abbreviation (e.g. GBP0, EUR0, CNY0 and so on). And when there are more than one bank account for the same currency, the fourth digit must be incremented (USD0, USD1, USD3...).

IBAN:
As indicated on the website http://www.sarie.gov.sa/iban/?iban=format&lang=en the format is:
Country code = SA
IBAN check digit = 2 digits (The IBAN Check digit is a totally different notion than the bank account check digit)
Bank identifier = 2 digits (see more information below)
Bank account = 18 (with zeros at the beginning if the bank account has less than 18)

Example:

Where SA is the country code, 03 is the IBAN check digit, 80 is the bank identifier, and 000000608010167519 is the bank account.
The bank identifier has been entered for all SA banks, it is stored in the field "Bank number".
Example:

BRAZIL:

Country code (2 positions) = BR

Bank Key (8 or 9 positions) = BBB0AAAA or BBB0AAAAA (E.g.: 23700957)

• • BBB = Bank Code with 3 positions (E.g.: 237)
  • 0 = bank code digit (E.g.: 237-2)

Note: If bank code digit is unknown, the number zero is required

• • AAAA or AAAAA = Agency with 4 or 5 positions (Ex: 0957)

Note: For further details on the setup of the bank key check ( http://teamsites.solvay.com/sites/FinOpProc/DBM Docs Public/Bank key rules by country.xls

Bank Account = Bank Account with 5 or 12 positions (E.g.: 432466) (Minimum 5 positions)

Control Key (CK) = Bank Account digit with 1 or 2 positions (E.g.: 8)
Note: Bank Account digit can be fulfilled with Bank Account, but dash is required
(E.g.: 432466-8)

Legend: G – Agency Digit; D – Bank Account Digit; b – blank

For new master data creations the following table can be envisaged as reference:

SWIFT Code

The swift code is used by the banking network to handle bank transfers. It is managed by CODIFHQ in table BNKA and introduced for each bank key from an international reference table. The web site of the SWIFT organization is, as you know, (http://www.swift.com), part BIC online.

SWIFT is mandatory for all countries. Is mandatory, the rule is generic. If not available, the Data Controller should contact the CODIFHQ giving:

• • The country code of the bank
  • The bank key
  • The request number (the request number is not necessary for CodifHQ, but if it is useful for SBS, it can be added)

and asking for the creation of the SWIFT CODE.

In case an inconsistency exists between the swift code of the vendors' document (physical proof) and the swift code in the bank file, CODIFHQ is contacted.

If the bank key is marked for deletion, the request can be accepted, but an email must be sent to CODIFHQ with the requester in CC, for CODIFHQ to check if the account can be used (and thus unmarked for deletion).

Additional information: The SWIFT code can be with 8 characters or 11 characters; only the 8 first digit are mandatory, the 3 characters at the end are optional.

Exception: Banks that are not linked to the SWIFT network don't have SWIFT Code, so, in that case, a bank can have no SWIFT code.



Customer bank details Insert or Modify
The process is the following:

- The Sales Assistant and/or Cash Collector have to request to the customer, to sent directly to customers.datamanagement@support.solvay.com  the Bank details with non editable document in attachment (e.g.: PDF, JPG, etc.).

Note: For US country it is mandatory to have a official document from the Bank.

 - Customer Master Data Team ( customers.datamanagement@support.solvay.com ) updates customer account with the bank details provided officially by the customer.

Note: this e-mail is allowed only for external users like this situation

-If data is not according to requirements in terms of format, Customer Master Data Team will ask to provide the correct document or data to the customer and will wait 3 working days for a feedback. If still not get any answer from the customer, a kindly reminder will be sent with information that if no reply the case will be closed within 3 working days.

-After insertion of Bank Details, Data Controller will inform Cash Collections about it and case is complete from Customer Master Data Team side.

For internal topics must always use SERVICE ONE portal

Exceptions :

1. Refund with Direct Debit (SEPA /RIBA) Payments: In these particular cases , the bank accounts can be sent by the CSR or Local Sales or from Cash Collector.

A flag will be add in Collection Auth. in Payment Transactions tab .

2. Rusvinyl exception:

As the invoices are treated by Rusvinyl, the verification and the confirmation of Bank Accounts are done locally.
Customer Master Data Team will not intervene in this process and will accept creation and changes of Bank Accounts (by CWF) in the Master records based on the controls performed locally by Rusvinyl.

Exchange letters and e-mail with Rusvinyl can be found in the end of this procedure.

3. Vostok

The Bank accounts can be inserted in the Customer Workflow Request if customer is from Russia.

4. Chinese Customers

Bank accounts can be sent by the CSR or Local Sales or directly by the customer.

Credit

The Data Controller is not concerned by this sheet. The credit data must only be checked by the Credit Manager
 
  ITALY : It is mandatory that the requester fills the credit limit of a Payer. If this field is empty, it must be returned to the requester in order to complete the information.
  Note: A standard procedure seems not to exist. It will be migrated " as is ", but must be reviewed later on, with POW (Chantal Liesse).
 
  JAPAN : Nothing specific for Japan. Specific account groups Z9J1, Z9J4 and Z9J5 created, requiring a validation by the credit manager.

Contact Person

 
 
  This sheet is optional for Payer and Payer-bis.  
 
As Sold-to, Ship-to/Bill-to, and Prospects are not sent to PI1, Data Controllers do not have to check their "contact person" data.
 
Data :

Distribution

 
 
  Target system PU1 is no longer used.

Communication Area

Area used by Requesters, the Data Controllers and Credit Managers to communicate each-other.
 
May be used to provide tips/information from the stakeholders mentioned above, explain reasons and giving feedback on requests returned or rejected, or add any relevant additional necessary information.
 
   
 
Check if some comments have been entered by the requester in this free text area.

 
As detailed in Data controller Rules – Broad description , this tab, must be primarily checked by the Data Controller.

File Attachment

Area used to attach any file documents to the request. No specific check performed by the Data Controller with the exception of requests placed by SBS organization (company 5960).

Specific Rules on requests for modifications

First check

If the request is a modification, the Data Controller first examines the list of fields changed, as displayed by clicking on the Icon "Fields changed". Each updated field must be checked along the corresponding rules.
 
 
 
 

Additional rules on requests for modification

General data

Modifications for "Name", "Street", "Account Group", can not generate a duplicated record.
If modification generates a duplicate record, rules on chapter  Rules on Duplicates when creating new records are applied.
 

Distribution

It is forbidden to remove a system from the distribution list: in that case the Data Controller must return the request.

VAT Registration number

VAT Reg. Number can be added, but, for Payers, it must never be changed or removed.

Changing/Removing a VAT ID can be accepted only to correct a mistake and if the customer has never been used. In this case, it must be changed, but the accountants must be informed, in order to check the impact on the VAT reports (to be detailed).

For the countries belonging to the EU, a VAT ID must never be changed for a "Payer" (Z**1; or Z**3, or Z**4, or Z**5). If not, the Data Controller returns the request, mentioning this point.
Note: If the VAT IDs were to be changed, the VAT reports sent by Solvay each month to European Tax Authorities might be wrong.

Concerning "Sold-to" (Z**8), the VAT ID is only used for internal purposes of data maintenance, so, it can be changed (but it must always correspond to the reality, and be in according with its payer. It can be checked on the Internet site: {+} http://ec.europa.eu/taxation_customs/vies/vieshome.do?selectedLanguage=EN+
and, concerning "Ship-to/Bill-to" (Z**2), the VAT ID is not mandatory. It can be changed or removed.
One VAT Code (per Country) –

• • • Only one "Payer";
    • Zero, one or several "Payer-bis";
    • Zero, one or several "Sold-to"

SPAIN: It is possible to change the VAT number for Spain according to the table below -

This is only valid for the key position which is the first character after the country code ES (e.g. ES G 010101110).

1) If the request consists in changing the NIF (or VAT ID), the current customer must be blocked and a new customer must be created;2) If the request consists in changing the first letter of the NIF while the numbers that follow the letter remain unchanged, then the request can be approved by Data Team (there is no change in the client's legal personality, as it remains the same);

Tax codes

For LAM region, the tax code can't be changed for Payers accounts. If the request consists in changing the TAX code, the current customer must be blocked and a new customer must be created.

Concerning "Sold-to" (Z**8), the TAX ID is only used for internal purposes of data maintenance, so, it can be changed (but it must always be according with its payer. It can be checked on the official documents.

Bank Data

JAPAN : In the requests for "update", the bank data is present, with bank type ZJP1, and must never be updated or deleted by the data controller . The bank type ZJP1 must never be used for another use.
For additional information regarding creation of bank data for Japan, check section  Checking Bank account Duplicates .

Validation Actions of the Data Controller

Approval

If the request is OK, you just have to click on the Icon "Data Controller approval"

The customer will be automatically created and the customer's number will be automatically added in the request.

Update

If the request has to be updated, you have to click on the Icon "Change (Data Controller)"

Change or add information in the appropriate fields
Then, save your changes and approve or return the request

When the request has been saved by the Data controller, a new possibility is now offered to the data controller, he can return the request.

Return

If the data controller need explanations and or wants to ask the requester to add or modify something, he must write his questions in the communication area:

And then, click on the return button.

Reject

If the request is not acceptable (for example when the data controller has detected a real duplicate) the data controller must reject definitively the request.
If the request is globally acceptable but that one or more information are wrong or missing, the Data Controller must return the request to the requester who will update and resubmit it.
The process is the same in both cases:
Click on the Icon

Then, the "Communication Area" screen is automatically displayed.
The Data Controller must indicate clearly if it a reject and enter his questions or the reason of the reject.

Requests processed in error

When a request is in error the request continues available in the business workplace mailbox with the indication ( status = Error(s) in the request ).
 
 
 

List of requests

The list of all the requests can be edited by the transaction Z1S_CWF_REQUEST_LIST.

This transaction must be executed at least twice per day (8:00 AM and 14:00 GMT) for checking if all the requests have been successfully processed

In the initial screen, you can enter some criteria: Status, Creation date, User ID of the requester.

The list is displayed by status. The Data Controller can double-click on a line for editing the request.

Distribution into PF1

The content of a request (tab Distribution) shows if the customer is intended to be transferred into PF1_020.
 
In case the distribution asked by the requester is NONE, the customer's data are not transferred.

These fields are part of the "Additional data"
 
   
 
Normally, if the requester enters correctly the fields "Distribution", the Data Controller doesn't have to take care of these indicators, but it may be interesting to know where this information is stored in SAP.

General data 1 - Name and Address

Screen shot example: 

Customer area

Title

This field can only be used for "politeness" title, which must be printed on documents but which is not part of the partner's official name, such as "Mr", "Mrs".
Official title part of the company name, such as "Inc." must be included in the name fields and not in this "title" field.
It is printed in the address block of commercial documents.
To avoid the language problem mentioned above, entries are inserted for each "title" in each language needed, copying the description text unchanged in all language codes.
 
No specific check performed by the Data Controller.

Name (line 1 mandatory)

The name is recorded on one line or more. 4 lines for the name may be entered, the first one is mandatory.
If the name exceeds 35 positions, it will be continued on the second line by cutting reasonably the name in two parts, avoiding cutting in the middle of a word. The button "preview" must be used to check the presentation by SAP with the customer's one.

If, according to his name the customer seems to belong to the Solvay Group, the data controller must check if it is really a Solvay Group Company. To check if it is indeed an Intragroup company the Data Controller has to check if the Group field contains the code 0000800001 (see chapter Group ).
Then, if it is really a Solvay Group Company, the Data Controller must inform the requester (ask the requester to put the value "G" in the field "customer class" and return the request.
The name lines cannot contain "address" data.
The use of the fourth line is not recommended, as it may not be printed in some documents.

If the lettering is not in capital letters, the Data Controller can make the change (if it is not significant, like the address or type of corporation) and then writes in the Communication Area that this action was performed.
Note: This rule can not be applied for Pharma in DACH.

ITALY: Except for "Natural Persons", all names of customers should finish with the kind of corporation (SPA, SNC, SRL, SAS ...)
Exception: On Ship-to , if the name of the company is followed by the indication of "Care of" (in Italian it is "P/C"), the request must be approved even if type of corporation is missing.

For Ship-to, the 4 possibilities below must be approved:

• • • Company 1 P/C Company 2
    • Company 1 SNC P/C Company 2
    • Company 1 P/C Company 2 SNC
    • Company 1 SNC P/C Company 2 SNC
      
      
      SPAIN: Except for "Natural Persons" all names of customers should finish with the type of corporation. The list (non exhaustive) of possible types of corporations in Spain is:
      "S.A." (Sociedad Anónima)
      "S.L." (Sociedad limitada)
      "S.A.L" (Sociedad Anónima Laboral)
      "S.C" (Sociedad Colectiva)
      "S.C.S." (Sociedad en Comandita Simple)
      "S.C.A" (Sociedad en Comandita por Acciones)
      "L.T.D.A." (Sociedad de Responsabilidad Limitada)
      
      RUSSIA: Type of Corporation (e.g. JSC / LLC / OOO / OAO / ZAO) should be placed after the company's name (e.g. SATURN OOO)
      
      DACH: mutated vowels and other special characters are written with 2 characters:
      Ö = OE, Ä= AE, Ü=UE, ß = SS

USA (NORTH AMERICA): DOMESTIC and INTERNATIONAL shipping, billing, payer & sold to addresses

• • • • • Upper case
        • Type complete full legal company name in - abbreviate as follows (if applicable):
          
          • CO (Company)
          • INC (Incorporated)
          • CORP (Corporation)
          • MFG (Manufacturing)
          • LTD (Limited)
          • LLC (Limited Liability Corp)
          • LLP (Limited Liability Partnership)
        • Do not use punctuation
        • No spaces are to be entered for company names with alphabetical abbreviations
          
          • ABC COMPANY and not A B C COMPANY

Therefore, checks performed by the Data Controller:

• • Move address into correct field (Street or other) if submitted in field "Name"

Account group (mandatory)

Definitions

The account group is used to determine the roles a customer can play in sales transactions, its number range and the zones which are mandatory or optional.
Account groups have been defined according to the following criteria:

• • • the country or regional area where the customer is located;
    • the different roles the customer may have in ERP transactions.

Four main roles have been defined:

• • • Payer: 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.
    • Sold-to-party: 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: customer who receives the goods. Only one ship-to-party can be created per company / address (same company and same address). When several sub-addresses or departments exist, different unloading points must be used for the same ship-to-party. Exceptions may be done if the same ship-to is used by different customers with different texts. Only exists at General Level.
    • Bill-to-party: customer who receives the billing documents. Only exists at General Level.

Account groups list

Account group check

The rules described below for the payer and Payer-bis must also be applied for the new account groups (Z**4 and Z**5).
The Data controller must check if the requested account group can be created according to the rules below:

• • • If a "Payer" is requested and that a payer already exists (with different address) for the same juridical entity, the data controller must propose to the requester to create a "Sold-to-party" or a "Payer-bis", (this last one only when really needed by the requester);
    • If a "Payer-bis" or a "Sold-to-party" is requested and that no "Payer" already exists for the same juridical entity, the data controller must propose to create a "Payer". 

The account group must not be modified without the agreement of the requester.

Payer: If a Payer or a payer only has been requested with a similar name (the address is not relevant for this matter), but the new one is marked by the requester as "not subject to VAT," and that the old one has a VAT number, confirmation should be asked. If it is not the same Legal Company, there can be 2 different Payers.

If no Payer exists, the data controller can change the account group from "Payer-bis" to "Payer", indicate in the information area that it was changed, and accept the request

An important rule concerning the Payer is that only one payer can exist for a legal company.
Some exceptions can exist, principally for customers belonging to the Solvay Group, and they always must be managed by GAC-Data Management.

If a request is made to create a Payer that already exists for the same legal entity, but with a different address, the Data controller can change the request through transaction "Z1S_CWF_CHANGE" before the validation, to create a Payer-Bis, instead of reject the request. An information should be added in the communication area to inform request that the customer will be created as Payer-Bis, due to Main-Payer already exists.

Payer-bis: 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.
If a "payer-bis" is required, the code of the payer must be indicated in the Communication Area, at the attention of the credit manager.

Sold-to: When the Data Controller receives a request for the creation of a Sold-To (Z**8), but that a Payer-Sold-Ship-Bill (Z**1) already exists, the Data Controller must *approve the request. Also, if a Payer-Bill (Z**4) or a Payer-Bill-Bis (Z**5) is required, but that a Z**8 already exists, the request must also be approved.

Ship-to: Does not need a Payer. Only checked at address level (no VAT needed).
There is only one type of Ship-to: Account group Z7Q2. It can be created even if "mandatory" fields (City, Street, etc) are blank or replaced by a "." (point).

When some customers need to change the fiscal address, they can submit a request to create a new ship-to/bill-to (Z**2). This new ship-bill contains the new fiscal address of the customer and that information must be included into the bill (the field "Fiscal Address", to be accessed after the customer – ship-bill – creation). The new ship-bill when inserted in this field will appear in the bill as a fiscal address.


In Ship-to , 2 or more customers can exist, if they must contain different transportation zones. 

If no indication is given by the requester, the data controller should return the request in order to confirm possible duplication. If a mention of need to use a different transportation zone is mentioned by the requester, then the request can be accepted, even if it is a duplication (with the exception of the Transportation Zone code).


SPAIN Fiscal address is used only in 87 payers.

-   In RCS, as Payer-bis does not exist, it is authorized to have 2 Payers created if one is the main payer and the other is to act as payer-bis.
-   In PRS only 1 Payer is authorized: if needed a Payer-bis can be created.

The link between Payers in RCS is: Main-payer will be Z**4 in PRS and the other payer (the payer-bis) will linked with the PRS payer-bis.

Existing customer in another account group

The table below indicates the action which must be done by the data controller when the customer (same VAT code (or other legal identification number), same name, same address) already exists with another account group.

Customer

It contains the customer's code after its creation.
Therefore is pure informative and automatically filled by the system.
A double click allows the data controller to check the result of the transaction.
No specific check performed by the Data Controller.

Head Office

This field contains the customer's code of the head office.
If the requested customer is a " sold-to-party ", this field must contain the customer's code of the "Payer". In this case, the data controller must check that the code entered corresponds to the right payer (Same legal entity). The Payer must be from the same country than the Sold-to .
 
When requesters need the creation of a new customer, they now have to ask for the creation of one Payer and one Sold-to, sometimes with:

• • • The same address;
    • Sometimes with another address.

In this second case, they have to enter 2 different requests. So, when a request for the sold-to is submitted, the Payer is generally not created yet, so it is not possible to indicate the Head Office.

Therefore, checks performed by the Data Controller:

• • • Must accept requests for creation of Sold-to even if the Head Office is blank.
    • But, if the requester indicates a Head Office, the Data Controller has to check that it belongs to the same legal company as the sold-to.

Language (mandatory)

Usual language of the customer (mandatory), in which all the documents will be addressed to the customer.
No specific check performed by the Data Controller. By default, the option should be English.

Search Term (mandatory)

The "search term" (mandatory) contains the most common abbreviation concerning the customer name.
It is used for search by matchcode in the customers' database. Thus the search term must be typed with care, without misspelling.
In case a customer changes its name (without changing its tax code or VAT registration number), it is good practice to check if the search term should be adjusted accordingly.

DACH : mutated vowels and other special characters are written with 2 characters:
Ö = OE,
Ä= AE,
Ü=UE,
ß = SS

Non- Interco Search Term

Since PO2 there was the need to duplicate some Interco codes and create as a regular customers to help the flow between the 2 companies - Solvay and Syensqo.

In the frame of the project and to help to identify these customers was decided that Search Term of the regular customers include the Trading Partner of the Source Code (Interco customer) + /STD

Regarding another type of customers that also was the need to replicate - Sub Leasing codes - the Search Term will be Trading Partner of the Source Code (Interco customer) + /SUBLE

Below is the image with detail example:

Physical address area

Care/of

This additional information may be inserted in the address block and will be generally printed before the "main street" line.

Used to add another party or intended recipient.

 It is applicable to all Solvay GBUs, except Specialty Polymers, Composite Materials and Intercompany accounts in Brazil. If any of SPP, CM, IC BR accounts has been updated in mass by mistake, you can revert the change but for the rest of GBUs this is a mandatory requirement going forward. 

Street

Main official street name, without "House Number" (e.g., box, floor, room or office number). This which must be filled in the respective field "House Number".

  Even if the SAP field contains 40 characters, only the 35 ^th first must be used, the last 5 digits will be not printed on some documents.

  According to the country, the address may contain such words as "RUE", "AVENUE", "STREET", "ROAD", "CARRETERA", "CALLE"…

CHINA: Address information is to be approved as is (the location is given by building number, not by street).

S. KOREA : Regarding the street, you can find several types of suffixes that are either roads, neighborhoods, towns:

• • • -eup, -myeon, -dong, -tong, -ri, -ban, -ro

DACH: mutated vowels and other special characters are written with 2 characters:
Ö = OE,
Ä= AE,
Ü=UE,
ß = SS

USA (North America):

Abbreviations to be used:

• • • ST (Street) RD (Road) DR (Drive) CT (Court) AVE (Avenue) Blvd (Boulevard) LN (Lane) HWY (Highway) PKWY (Parkway) PL (Place)
    • S (South) E (East) W (West) N (North)
    • SE (South East) NE (North East) NW (North West) SW (South West)
    • 1ST 2ND 3RD 4TH 5TH etc.

Therefore, checks performed by the Data Controller:

• • • Verify if a "House Number" is not included in "Street" field. If included, information is corrected (possible exception for France).

House number

House and letterbox numbers, including their "natural" supplement (e.g. "19bis" or "25/R"). This field is printed on the "Street" line, before or after the street, according to the local use in the country.

 No specific check performed by the Data Controller.

Street 4

This field may be used to enter a supplementary street line . This line will be generally printed after the "main street" line.

No specific check performed by the Data Controller.

District

This additional data represents a subdivision in a city. It is printed:

• • • after the city, on the same line (FR, IT, BE, NL, ES, PT…)
    • or before the "Main Street" line (DE,…)
    • or before the "City" line (GB,…)
    • or not printed (US,….)

The requester must check the result trough the button "preview" in the procedure.

JAPAN: Building name (including building number, floor, room, if any).

S. KOREA: District = town (suffix -SI) or city district (suffix -GU or KU)

No specific check performed by the Data Controller.

Postal code

Required field if postal codes have been activated for that country in the country table customizing. Only official postal codes must be used. . The list can be found in:

  http://teamsites.solvay.com/sites/FinOpProc/DBM Docs Public/Post_codes_structure (per Country).xls

USA (North America): DOMESTIC shipping addresses only

• • • Enter 5 digit zip code or 5 digit "-" four digit when available

→ 08520 or 08520-3022

City (mandatory)

The official name of the locality must be entered, in the local language, whenever possible.
Additional information, such as the province, can be recorded after the name, if required by the local postal authorities and not provided by the region code.

ITALY: Italian zip codes (postal codes) and cities can be checked on website:
http://www.posteitaliane.it/online/cercacap/
No specific check performed by the Data Controller.

S. KOREA : City = name of the province or metro city

DACH : mutated vowels and other special characters are written with 2 characters:
Ö = OE,
Ä= AE,
Ü=UE,
ß = SS

Country (mandatory)

Official country code must be recorded according to the ISO codification.

No specific check performed by the Data Controller.

Region

The region represents the main administrative division of a country (e.g. department in France, province in Spain, state in the United States, federal state (Bundesland) for Germany and Austria, canton for Switzerland). Whenever possible, official codes are used, with a preference for ISO codes when they exist.
The region code is mandatory (not an SAP rule) in some countries: USA, Italy (non exhaustive list) and whenever it is used.
DACH: For Germany there exists a XLS-file to allow finding the correct federal state assigned to German cities and also to perform a cross-check if the Region is in accordance with the City:
{+} http://teamsites.solvay.com/sites/3Se/CODIF/Federal%20States%20for%20Germany.XLS+

BRAZIL: Region is mandatory for Brazil.

Therefore, checks performed by the Data Controller:

• • • Verify existence of region code for countries where it is used (e.g. US, EU countries, BR or AR). If does not exist, request is returned back and asked for missing code.

Transportation zone

The "transportation zone" often uses the same subdivision of the countries as the region. It may be different in some countries (e.g. Germany) or when a customer's specific zone is required

Possibility of existing several Ship-to's , if for different Transportation Zones. (please see Account group check )

DACH: For Germany the transport zone consist of the 2 first digits of zip (postal) code.
Account group check
JAPAN: 2 characters numeric or begin by "Z".

THAILAND: numeric 4 digits) have been implemented for customers. The old ones (2 digits) cannot be used anymore

Control on the transportation zone: the "state/province/estado" transportation zones of NAFTA countries and "ZZ" zones of the major countries will no longer be allowed.
They can be identified by a + S + o + D+ o + O + at the end of their description.

returned to the requester for modification”, with the explanation that the [transportation zone is no longer][ZD contact person is mandatory] valid due to the implementation of a new release.

Therefore, checks performed by the Data Controller:

• • • Verify if transportation zones of NAFTA countries and "ZZ" zones of the major countries are empty (+ S + o + D +  o + O +). If not, request is returned with the explanation that the transportation zone is no longer valid due to the implementation of a new release.

Railway Stations (Pending IT Developments) 

In order to store in the customer its corresponding railway station code and name. It can therefore be completed only in account groups allowing the function 'Ship-to' and if 'Ship-to' is delivered by rail (meaning ship-to has a dedicated transportation zone).

  The option 'by Rail' must be selected, so that the specific transportation zone code for rail (Rail T. Zone) is available to be entered.

Railway station code in format XX S 1234567 ZZZZZ, where:

• • • XX being country of customer;
    • S for railway station;
    • 1234567 railway station code;
    • ZZZZ station name

Note: Example: DES190793 Ludwigshafen, (Rhein) BASF

Length of field: 25 (maximum)

Websites to check the Railway station codes:
http://www.uic.org/spip.php?article378 (UIC website, requires log on registry)

http://fret.sncf.com/fret/87-nomenclature_des_gares.html (website to look for code if you have no logon on UIC)

Therefore, checks performed by the Data Controller:

• • • Must only be completed in relevant cases;
    • Must be completed in correct format

Postal address area

PO Box

Only the P.O. Box number must be entered. Mentions as "P.O. Box", etc, must not be entered as they are automatically printed when necessary by SAP.

  Therefore, checks performed by the Data Controller:

• • •  Correct if needed, by removing expressions such as "P.O.Box", "B.P.", etc…

PO Box Postal code

This field is linked to the "PO BOX" field: official postal code as used in the country, for the P.O. Box address.
The postal code of the PO Box is required if it is different from the postal code of the physical address.

FRANCE : Postal code of the CEDEX in France is filled in this field.

No specific check performed by the Data Controller.

PO Box city (postal address)

This field must be used to indicate the name of the city corresponding to the "P.O. Box Postal Code" is located, if different from the "City" itself.
No specific check performed by the Data Controller.

General data 2 - Control Data

Screen shot example:

Tax information

VAT Registration number

This field concerns only customers belonging to the European Union, it must be left empty for other countries . If the customer has a VAT registration number, it has to be recorded.

By principle, a VAT registration number will never be updated (unless an initial error, or national exceptions). Updating a VAT registration number, or erasing it, must be explained and justified by the requester in the Communication Area ( see chapter VAT Registration number ).

For customers, in the account groups "Payers" (Z**1), a user-exit blocks the creation of a customer with a VAT identification for which a customer already exists with the same account group.
The data controller must check that a value has been entered for all the customers "Payer", "Payer-bis" and "Sold-to" in the European Union.

The VAT ID for " Payer " (Z**1; or Z**3, or Z**4, or Z**5) must never be changed.
Note: If the VAT IDs were to be changed, the VAT reports sent by Solvay each month to European Tax Authorities might be wrong.

Concerning " Sold-to " (Z**8), the VAT ID is only used for internal purposes of data maintenance, so, it can be changed (but it must always correspond to the reality). This field can also be empty; and does not need to match the head-office it belongs to.

And, concerning " Ship-to/Bill-to " (Z**2), the VAT ID is not mandatory. It can be changed or removed.

When a customer changes its VAT registration number, a new customer must be recorded, in order to prevent from any confusion between its old and new fiscal identification. When appropriate, the old customer must be blocked and suppressed, after its company views and purchasing views have been blocked and suppressed in PF1, meaning that all relationship has been terminated.

When a customer changes its name and/or address and/or Tax Code 1 without changing its VAT registration number, those fields can be updated without creating a new customer in the database, respecting rules on modifications (see chapter Specific Rules on requests for modifications ).


The validity of the VAT registration number in Europe can be checked on the website:

http://ec.europa.eu/taxation_customs/vies/vieshome.do?selectedLanguage=EN

ITALY: check if Tax Code 2 is inserted. If yes, then a VAT must also exist. If not inserted, the Data Controller must return the WF asking for it.

JAPAN: VAT number, Tax code1, and Tax code2 are not relevant for Japan

CROATIA: from the 1^st of July 2013, Croatia is a part of the EU. Hence, after Croatia's entry into European Union, the assigned OIB shall be added with "HR" in front of the eleven numerical digits in order to make it suitable for international monitoring purposes.

OIB is the Personal Identification Number (or abridge in Croatian OIB) is an eleven digit numerical mark through which all taxpayers in Croatia.
OIB bearers are all natural persons and legal entities.

The OIB may be assigned by the authorised TAX Administration. The authorisation of a certain branch office is determined according to a person's place of residence, legal entity's headquarters.

The OIB certificate is a document provided to all OIB bearers and is considered a public document. It is issued by the Tax Administration, and the bearer is obligated to keep the certificate.
(Starting from January 1st 2010 all the natural persons and legal entities must have the OIB number shown on their documents, invoices etc.).

More VAT button

VAT registration in Europe: button " more VAT " allows recording more than one VAT reg number, in other countries than the country of the vendor.

It is accepted that something is recorded in "more VAT" even if the field "VAT" is blank.
Additional VAT numbers does not identify the customer himself but the fiscal representative of the customer in another country.
So, changing a fiscal representative VAT number is allowed.

The VAT code in column "VAT numbers" must begin by the country code, even if the country code is also mentioned in column "Country" (see example in red).

Therefore, checks performed by the Data Controller:

• • • Check country code in column 1;
    • Check full VAT registration code in column 2;
    • Check that the same country does not appear more than once;

It has to have the VAT code of all the Fiscal Representatives in the field "OTHER":

Additional comments per country (this list is not exhaustive):

BELGIUM : the VAT registration number is the Enterprise number, prefixed by BE. The Enterprise number can be checked on the website:
http://kbo-bce-ps.mineco.fgov.be/ps/kbo_ps/kbo_search.jsp?lang=fr&dest=ST Note that the VAT number format has been changed some time ago from 11 to 12 digits. Existing VAT numbers have been updated, adding a 0 between the country (BE) and the old number. For example, VAT number BE459728629 has been replaced by BE 0 459728629. As the database has not been updated yet, the VAT numbers may appear with 11 digits and 12 digits.

ITALY : the VAT registration number may be checked on website:
http://www1.agenziaentrate.it/servizi/vies/vies
http://ec.europa.eu/taxation_customs/vies/vieshome.do?selectedLanguage=EN
SPAIN : The VAT registration number for "S.L." is always letter "B" after country code. For "S.A.", it is always "A". For "Natural Person" (that are not Juridical entities) the first character is never a letter and has always a random letter at the end of the VAT code.
The VAT registration number may be updated when a corporation changes its type (e.g. from "S.L." to "S.A."). In that case, the VAT registration number only changes in one letter.

Natural persons' in Spain must have a VAT number. Therefore, the VAT number must be asked even if the natural person indicator is ticked.

UK and SWEDEN : Different companies may have the same VAT registration number, since it is not an identification of the customer itself.

FRANCE : For France, Pharmacies customers have VAT numbers but many of them (99%) are currently missing in the customers file.
The VAT Register and Tax Code 1 are mandatory.

DACH: The VAT code of EU customers which are located outside Germany have to be validated by the German "Bundeszentralamt für Steuern (BZSt)" (Federal Authority for Taxes). This validation must be a qualified validation . Only Z**1 customers (Payer / head office) must be validated by a qualified validation.

Through this site there can exist either a simple or a qualified request. When choosing the qualified request , the answer automatically will be sent to the respective German company which is referred in that request (that means at least to CCTAX Germany).
In addition the VAT registration numbers must be check regularly (once a year should be enough).

SWITZERLAND : VAT is only for countries belonging to the European Union (and not Europe's geographical area). E.g. Switzerland does not have a VAT code. In fact, Switzerland has a VAT Code but this VAT code must be registered in the field Tax code 1, never in the field VAT Code.
The Data Controller can nevertheless, accept creation of customers without the VAT number being inserted.

Examples of Customers not using VAT:
Physical persons, Administrations, Universities, Public Hospitals, Associations, and some other specific customers are generally not concerned by VAT registration.
These exceptions are depending on each country and there is no rule to know if a customer has or not a VAT number. For example, Public hospitals generally do not have VAT code, but some of them have one.

Therefore, checks performed by the Data Controller:

• • • Verify if submitted codification respect rules in this chapter. If not, request is returned back and asked correction to the requester.

Tax code 1

This legal fiscal identification is required by some national authorities and is used for reporting to the tax authorities, according to the use defined by SAP. Its definition varies among countries (see chart). This field is mandatory for some countries (i.e. Spain), but only for customers that have one.

Chart for Tax Code 1

In some countries, Tax Code 1 is coupled with the VAT registration number (e.g. in France a company has a VAT registration and a Tax Code 1, or none). Erasing a Tax Code 1 must be explained and justified by the requester in the Communication Area.

This field is mandatory for "Payer" and "Payer-bis" according to the country, as mentioned in the table above.
Concerning "Sold-to" (Z**8), the Tax Code 1 (as the VAT) is only used for internal purposes of data maintenance, so, it can be changed (but it must always correspond to the reality). This field can also be empty; and does not need to match the head-office it belongs to.

Comments on tax code 1 in some countries:

FRANCE: In France, VAT and tax Code 1 represent similar information. If it not subject to VAT, then the request of tax Code 1 is not necessary. Two customers cannot have the same SIRET (same Tax Code 1 of 14 characters). In case of duplicate, check on the website. SIREN\SIRET codes can be found under the website:
http://avis-situation-sirene.insee.fr/avisituV2/jsp/avis.jsp


SIRET/SIREN may have 14 or 9 digits but when it has 9 the system shows an attention remark. The request can be saved anyway and the Tax Code 1 can be accepted this way. The Tax Code 2 must always be blank for France.

IBERIA: Tax Code 1 to insert is the VAT number without the Country Code.

ITALY: The Tax Code 1, in Italy, is the fiscal code. If the company is a Juridical Entity, sometimes is equal to VAT ID., sometimes is a different number, but anyway they are always a numerical code.
For a " Natural Person " (that are no Juridical entities) it is an alphanumeric code of always 16 positions (egg, MSTGNN53A13L736E).To check the VAT CODE (Italy):
http://www1.agenziaentrate.it/servizi/vies/vies

For Juridical entities (companies) the code is fully numeric.

Tax Code 1 can exist fully numeric and without VAT for [non-exhaustive list]:

• • municipality/prefecture/association/federation;
  • religious entities (e.g. churches);
  • embassy;
  • Non Profit organizations.

CHINA: No tax code defined.

SINGAPORE: The Goods and Service Tax code (e.g. M09-0008879-T) is to be placed in the Tax Code 1 area.

BRAZIL: The data related with CNPJ can be checked in the official BR government site:
http://www.receita.fazenda.gov.br/pessoajuridica/cnpj/cnpjreva/cnpjreva_solicitacao.asp

EGYPT: Project recommendation is to have a "flexible" check: the Egyptian tax authority does not have a very logical strategy. Hence it can be changed.


Therefore, checks performed by the Data Controller:

• • Verify if submitted codification respect rules in this chapter. If not, request is returned back and asked correction to the requester.

Tax code 2

This legal fiscal identification is required by some national authorities. Its definition varies among countries (see chart) . This field is mandatory for some countries.

Chart for Tax code2
Legal fiscal identification needed by the national authorities, according to the use defined by SAP.

THAILAND: corresponds to withholding tax code (optional also), the format depends on the type of third party:

• • Personal Income TAX (TAX no. 1XXXXXXXXX or 2XXXXXXXXX)
  • Legal entity (TAX no. 3XXXXXXXXX)
  • Independent entity (TAX no. 4XXXXXXXXX)
  • Blank on TAX number 2 is Vendor no withholding TAX

Concerning "Sold-to" (Z**8), the Tax Code 2 (as the VAT) is only used for internal purposes of data maintenance, so, it can be changed (but it must always correspond to the reality). This field can also be empty; and does not need to match the head-office it belongs to.

Therefore, checks performed by the Data Controller:

• • Verify if submitted codification respect rules in this chapter. If not, request is returned back and asked correction to the requester.
  • if the field is empty for countries not in this list

Tax code 3

Tax code 3 is used in Russia to enter the KPP code (Registration reason code).
This tax code is mandatory, its structure is: 9 digits, numerical.

Tax Code 3 is mandatory for Companies in Brazil (for "Natural Person" it should be left empty).

EGYPT:

Tax code 4

Tax code 4 can be used in Russia for internal use (FI reports).
This tax code is optional, its structure is: 10 digits, numerical.
Data controller must check that this field is empty when the customer's country is not RU.

EGYPT: Tax office corresponds to the customer code previously created as the Tax Office for the customer being created.
This Tax Office number (customer code) if not already available in the system, must be created before the customer being submitted.

Natural Person

This indicator may be filled in if the customer is a physical person relevant for tax purposes (e.g. Doctor).
Indicator used to distinguish between natural and legal persons for tax reporting.

SPAIN: Please check the VAT Reg. point for specificity concerning VAT number when Natural Person tick is selected.

Note: The field "Natural Person" is now totally independent from the VAT number and has to be used each time the customer is a natural person, irrespective of the country and the existence of a VAT registration number.

RUSSIA: For natural persons the only mandatory field is INN which should consist of 12 digits in this case

Therefore, checks performed by the Data Controller:

• •  Verify if coherence exists with the customer name. If not, request is returned back and asked confirmation to the requester.

Reason No VAT ID

The 'Reasn No VAT ID' field must be used to indicate the reason why a customer located in one of the countries of the European Union is not liable for VAT.

It is mandatory for all the customers from European Union not liable for VAT which are either:

• • 'Payer' (account group Z7*1 or Z7*4)
  • 'Payer-bis' (account group Z7*3 or Z7*5). 

It can be used (but not mandatory) for Sold-to if needed.
It must be blank for all other countries.

The possible values are:

• • WAI: customer is liable for VAT, but has not received yet its VAT number from the tax administration.
  • CIP is exclusively reserved to french health establishment who have a CIP number (mainly Pharmacies and hospitals). Thus, it cannot be used for Chemicals and Plastics customers.
  • According to the country, and to the cases, some 'Associations', 'Physical persons', or 'Public establishments' are liable for VAT. Therefore, the use of this field is strictly reserved to customer really not liable for VAT.

The validity of this information is under the responsibility of the requester .

Therefore, checks performed by the Data Controller:

• • Verify globally that the use of this field is coherent with the name of the customer (e.g. Ministry of Health" cannot have reason "Physical person"). 

Marketing

Customer classification

It is the commercial classification of the customer. It is used for the determination of the risk category and credit management for "Payers" (Z**1 or Z**4), and for statistics for all the customers.
For the 'Sold-to' the classification must be equal to the Payer it belongs to.

Therefore, checks performed by the Data Controller:

• • • Check the global coherence;
    • Check if the value "P" (Private hospital) cannot be used for a Chemical products company;
    • Check if Small Med. Device, Private Hospital and Public Hospital are only for Pharma;
    • Check if the value "G" (Belonging to the Solvay group) is entered when the field "Group" contains the value 0000800001;
    • Check that the value "X" (not relevant for customer classification) is only used for "Ship-to-party/Bill-to-party" (account group Z**2). As this field is only used for credit control, and the Ship-to does not have credit, it must be classified as Undetermined.
    • 'Cannot be blocked' and 'required for follow-up' are not options in ERP and should be replaced by "Small account".

Industry code 1

Market segment of the customer.

No specific check.

Group

Industrial group the customer belongs to (not mandatory except if intragroup*).
Industrial groups are defined by the SBUs' Marketing Managers according to juridical, financial and commercial considerations.
The code 0000800001 shows that the customer belongs to the Solvay group but the workflow is not used for creation of intra-group customers (*done by CODIFHQ).
Therefore, checks performed by the Data Controller:

• • • If the request code 0000800001 is used, the Data Controller must return explaining this code is only valid for intra-group customers and in this case, the requester must insert in the Customer Class field "G" (for the request to be addressed to CODIFHQ).
    • If other than the Solvay group code, the team checks via ZPRA if the code corresponds to the customer master data (e.g. 0000801130 is SHELL)

Account control

Vendor

If the customer is also a vendor, the field may contain the vendor's code.
If a value has been entered by the requester, check that the code really concerns the same juridical company.
This field shows that the customer is also a vendor. Then it contains the customer's code.

Trading partner

This field contains the "Cheops enterprise code" for partners belonging to the SOLVAY group. This code is the same as the one used for company codes.
Currently this field is only used for the Solvay Group.

Authorization group

Identification of the codification team responsible for the customer's country
No action possible.

DUNS Code

Contact Support

Escalation Rules

When a request is re-submitted for a third time by the requester (after a second return by the Data Controller) for the same reason, the case is escalated to Jean-Paul Charnet (GAC Team).

  In this case, the request remains unprocessed by SBS Data Controller awaiting instructions from Jean-Paul Charnet (GAC Team).

Attachments

Scope of Customer & Vendors Data Management

The following document is attached to this SOP, containing the list of countries under the scope of SBS CODIF Data Controllers:
  http://teamsites.solvay.com/sites/FinOpProc/DATA%20MANAGEMENT%20CUSTOMERS%20AND%20VENDORS/Customers%20and%20Vendors%20Data%20Management%20handled%20by%203S%20DATA%20CONTROL%20TEAM.aspx

Customers maintenance by Account Groups

(*) : For account groups Z7Q*, the request for creation must be accepted or rejected according to the country, as defined in the list below.
Note: For Chemicals/Plastics Z9J*, Z9I* and Z9C* must be used.

Account groups by country:  
 
  http://teamsites.solvay.com/sites/FinOpProc/DBM Docs SemiRestricted/Account groups by country.xls  
 
Exchange letters and e-mails with Rusvinyl for insertion/modification of bank accounts on Rusvinyl customers: