Authorizations & Roles

Modifications

Table of contents
Objective and Scope
Reference Documents
Definitions
Process Flow
1.1 Roles & responsibilities of each actor
1.1.1 The initial requestor
1.1.2 Data Management Team (Part 1)
1.1.3 Local Procurement Representatives (LPR)
1.1.4 Data Management Team (Part 2)
1.2 Overview
1.2.1 PF1_050 (PRS)
1.2.2 WP1_400 (RCS)
1.2.3 PI1_020 (CICC)
1.3 Vendor creation/modification through Workflow
1.3.1 Description of transaction "Business Workplace" in PRS client
1.3.2 Description of Vendor Workflow functionality
1.3.3 Checks necessary before approving a request for a new VWF record
1.3.4 Approving a Request to create a new vendor (Without Webform)
1.3.5 Approving a Request to create a new vendor (With Webform)
1.3.6 Completing new vendor creation
1.3.7 Modifying an existing vendor in PRS
1.3.8 Blocking/unblocking and marking/un-marking for deletion
1.4 Manual vendor creation/modification
1.4.1 Requirements
1.4.2 Main Rules to create a vendor
1.4.3 General data creation
1.4.4 Company Code view creation
1.4.5 Financial vendor addition to non-PO vendor list
1.4.6 Purchasing Organization view creation
1.5 Blocking and/or marking for deletion
1.5.1 Open item checks required before vendor inactivation
1.5.2 Block
1.5.3 Mark for deletion
1.5.4 Additional steps
1.6 PI1_020 – CICC
1.6.1 Clrk's internet addition/change
1.6.2 Checking open items before vendor inactivation
1.6.3 Creating link between PF1 and PI1
1.7 Remediation process
1.8 Miscellaneous creditors process
1.9 How to check and create IDocs
Appendix 1 – Requirements for Tax Number 1- 5
Appendix 2 - European VAT identification number structure
Appendix 3 – IBAN structure
Appendix 4 - SWIFT code lookup
Appendix 5 – Bank codes for Brasil, Chile, Peru and Mexico
Appendix 6 – Transportation zone
Appendix 7 – SAP Purchasing organizations
Appendix 8 – Plant level (Alternative data)
Appendix 9 – Checking partner functions
Appendix 10 – LPR's/contact persons
Appendix 11 – Transactions
Objective and Scope 4
Reference Documents 4
Definitions 4
Process Flow 5
1.1 Roles & responsibilities of each actor 6
1.1.1 The initial requestor 6
1.1.2 Data Management Team (Part 1) 6
1.1.3 Local Procurement Representatives (LPR) 6
1.1.4 Data Management Team (Part 2) 6
1.2 Overview 7
1.2.1 PF1_050 (PRS) 7
1.2.2 WP1_400 (RCS) 8
1.2.3 PI1_020 (CICC) 9
1.3 Vendor creation/modification through Workflow 10
1.3.1 Description of transaction "Business Workplace" in PRS client 10
1.3.2 Description of Vendor Workflow functionality 12
1.3.3 Checks necessary before approving a request for a new VWF record 14
1.3.4 Approving a Request to create a new vendor (Without Webform) 21
1.3.5 Approving a Request to create a new vendor (With Webform) 30
1.3.6 Completing new vendor creation 31
1.3.7 Modifying an existing vendor in PRS 31
1.3.8 Blocking/unblocking and marking/un-marking for deletion 31
1.4 Manual vendor creation/modification 32
1.4.1 Requirements 32
1.4.2 Main Rules to create a vendor 33
1.4.3 General data creation 34
1.4.4 Company Code view creation 52
1.4.5 Financial vendor addition to non-PO vendor list 61
1.4.6 Purchasing Organization view creation 62
1.5 Blocking and/or marking for deletion 64
1.5.1 Open item checks required before vendor inactivation 64
1.5.2 Block 74
1.5.3 Mark for deletion 76
1.5.4 Additional steps 78
1.6 PI1_020 – CICC 79
1.6.1 Clrk's internet addition/change 79
1.6.2 Checking open items before vendor inactivation 81
1.6.3 Creating link between PF1 and PI1 83
1.7 Remediation process 84
1.8 How to check and create IDocs 85
Appendix 1 – Requirements for Tax Number 1- 5 88
Appendix 2 - European VAT identification number structure 91
Appendix 3 - VAT validation (Europe) 92
Appendix 4 - Tax ID (PE, BR, TH) validation 93
Appendix 5 – DUNS verification 95
Appendix 6 – IBAN structure 98
Appendix 7 – IBAN validation (Europe) 101
Appendix 8 - SWIFT code lookup 102
Appendix 9 – Bank codes for Brasil, Chile and Peru 103
Appendix 10 – Routing number validation (USA) 105
Appendix 11 – Transportation zone 106
Appendix 12 – SAP Purchasing organizations 108
Appendix 13 – Plant level (Alternative data) 109
Appendix 14 – Checking partner functions 114
Appendix 15 – E-mail maintenance in MN05 116
Appendix 16 – LPR's/contact persons 119
Appendix 17 – Transactions 121

Objective and Scope

Objective of this Procedure
This document describes the process to handle Vendor Master Data to create, modify and extend a new/existing vendor account in PRS (PF1_50) and RCS (WP1_400) environment and describes the roles and responsibilities of each actor in this process.
Scope
Data Management Team based in Riga is responsible to handle all Vendor Master Data from NAM, LAM, APAC and EMEA regions, except for Intercompany general data, and Commission Agent and Patent and Trademark vendor records.
Requests for Intercompany creation/name, address and bank detail change and Commission Agent vendor records creation/modification should be forwarded to Lisbon SBS team using Fresh Desk ticketing system.
Intercompany records company code and purchasing organization data can be done by Riga Data Management.

Reference Documents

SBS-OP-DPtP-05-03-xxx DA NAM-LAM Vendor Workflow
SBS-OP-DPtP-05-03-009 DA NAM-LAM Vendor Master Data Purchasing Organization Creation
SBS-OP-DPtP-05-03-009 DA NAM-LAM Vendor Master Data General View Creation
SBS-OP-DPtP-05-03-009 DA NAM-LAM Vendor Master Data Company Code View Creation

Definitions

Process Flow

Roles & responsibilities of each actor

The initial requestor

Requests for new vendor additions and changes can be received through SAP system Business Workplace (Workflow functionality), FreshDesk , Self Service Helpdesk Portal (http://sde.cytec.com/helpdesk/) and as an e-mail to datamanage@solvay.com. Change requests can also be requested from AP via Web Cycles.
Change requests can also be requested from AP via Workeb Cycles.

Data Management Team (Part 1)

Every request for a vendor setup or maintenance should be reflected in the Self Service Helpdesk PortalFreshdesk. Requests received through Data Management Mailbox or , Workflow system or FreshdeskFresh desk should also be entered into Self Service Helpdesk PortalFreshdesk.
For cases when initial requests are received through SDE Freshdesk ticketing system DMO team member will perform required validation checks and will send an email to LPR or Buyer with the request to initiate a workflow. List of LPR's and buyers to be contacted can be found in Appendix 16Appendix 10.
For exceptional cases please see following chapters:
1.7 Remediation process
1.8 Miscellaneous creditors process

Local Procurement Representatives (LPR)

Local Procurement Representatives (LPR) and Buyers are responsible for submitting requests via Vendor Workflow Tool.
When submitting requests via Vendor Workflow, the following requirements have to be strictly respected:

• The requester should check if vendor already exists in the system;
• Mandatory documentation described in Chapter 1.3.3.1 should be attached to the request.
• 
  

Data Management Team (Part 2)

The VWF arrives to DMO Team after approval of the Domain Manager. DMO is responsible for receiving the request in PRS / Transaction SBWP (Business Workplace), checking and approving it.
Before approving the request in PRS, the personnel, who do so, must perform all the checks necessary in order to avoid duplicate vendors set up on the system. It is under DMO Team responsibility to check whether all the required information was provided to set up a vendor account.
Once the request is completely processed, the requester (LPR) will receive an email confirming the completion of their request. DMO Team responsibility is to also close SDE Freshdesk ticket in order for the initial requestor to receive information that requested changes have been processed in SAP.

Overview

Vendor master data is being maintained in four systems – PF1_050, PF1_020, WP1_400, PI_020.

PF1_050 (PRS)

PRS - Permanent Reference System, PF1_050, is SAP System_Client, which is used to maintain vendor general data – name, address, tax ID, general contact information and bank data. This information will be automatically distributed to rest of the systems mentioned above.
Vendor WorkFlow (VWF) functionality is used in PRS for vendor creation and changes. It allows requesters to fill in creation/change template directly into the system. If needed these changes are routed for approval to Domain Manager, and after DMO review and approval automatically implemented in the system. For more details please see Chapter 1.3.1.
In case of new vendor creation VWF is used only to create main vendor (VN party), additional remittance and/or ordering address can be created manually.
It is important to remember that following information needs to be filled in manually:

• Search Term 2;
• Bank details (in cases when WebForm is not used).

WP1_400 (RCS)

RCS - Rhodia Core system, WP1_400, is SAP System_Client which is used to maintain vendor company code and purchasing organization information. PIR's, purchase orders, invoices etc. are recorded in RCS by the respective departments.
PF1 - Solvay Legacy system, PF1_020, is SAP System_Client with similar functionality to RCS, but used by different Solvay companies.
New creations and changes made in PRS will be distributed to one or both of the systems mentioned above.
Company code data is usually created manually by DMO after general data has been distributed to RCS from PRS. All the changes in Company code are done manually.
If a PO is created for vendor with no company code and in the PO partner functions the same vendor has been set as remittance party, the company code will be created by the system with default values.
Company codes maintained by Data Management:

• WARP – PRS company code for Remediation Process (trigger internal PtP PSL approval and class D)
• NAM
  • 7008 – Cytec Industries Inc
  • 7752 – Cytec Canada Inc
  • 7723 – Cytec de Mexico SA de CV
  • 7426 – Cytec Global Holding Inc
  • 7427 – Cytec Technology Corp
  • 7030 – Piney River Recovery Corp
  • 7031 – Garret Mountain Insurance Co
  • 7180 – Cytec Engineered Materials Inc
  • 7188 – Cytec Defense Materials Llc
• LAM
  • 7725 – Cytec Chile Ltda
  • 7722 – Cytec Peru SA
• EMEA
  • 7794 – Cytec Industries BV
  • 7764 – Solvay Business Services Latvia Sia
  • 7726 – Cytec Belgium Bvba
  • 7792 – Cytec Luxembourg Sarl
  • 7796 – Cytec Lux Int Hldgs Sarl (merged with 7792)
  • 7210 – Umeco Ltd
  • 7714 – Cytec UK Holdings Ltd
  • 7785 – Strata – Solvay Advanced Materials Joint Venture Llc
  • 7779 – Cytec Nibras Llc
  • 7772 – Cytec Engineered Materials GmbH
  • 7771 – Cytec Engineered Materials Ltd
• APAC
  • 7734 – Cytec Industries (Shanghai) Co Ltd
  • 7776 – Cytec Engineered Materials Co. Ltd, Shanghai (merged with 7775)
  • 7774 – Cytec Specialty Chemicals (Thailand) Ltd
  • 7786 – Cytec Australia Holdings Pty Ltd
  • 7788 – PT Cytec Indonesia
  • 7988 – Cytec Korea
  • 7776 – Cytec Engineered Materials Shanghai Co Ltd

Purchasing Organization data usually is created/changed using WorkFlow functionality. Please keep in mind that it does not include Partner Functions, which have to be maintained manually.
In case of manual vendor creation Purchasing Organization data can be added manually.

PI1_020 (CICC)

CICC - Coordination Internationale des Crédits Commerciaux, PI1_020, is the in house bank. This SAP platform is linked with both PRS and RCS and is used for processing payments. It is applicable to company codes for which Factoring (paying via CICC) is enabled, the rest of the payments are being done through RCS or PF1_020 using SWIFTNET.
New creations and changes made in PRS will be transferred to CICC. It will be automatically opened for company code when the first invoice will be posted for payment.
It is important to remember, that for companies using factoring:

• Remittance e-mail address should be maintained also in CICC company code data;
• FBL1N transaction in CICC should be checked for open items in case of vendor inactivation.

Detailed description can be found in Chapter 1.6.

Vendor creation/modification through Workflow

Description of transaction "Business Workplace" in PRS client

The PRS client is integrated in the RCS System and is compounded of four transactions for vendor maintenance requests management.
Getting logged in PRS
In the PF1 System log on PRS client (code 050).

Once logged in you can access your Business Workplace by:

• Entering transaction code SBWP;
• Pressing Inbox icon ;
• Or using Ctrl+F12 shortcut.

Functions explanation
You will find the requests by clicking on "Inbox" then on "Workflow". You will be able to see all requests assigned to "Procure-to-Pay" for approval and are not being worked on by other users.
VWF's are divided between Business Service centers based on company codes. List of company codes maintained by Riga Data Management can be found in Chapter 1.2.3.

When you select a line you can check some basic information about the request at the bottom of the screen:

• Type of request (Creation or Modification);
• Vendor Country;
• Company code selected;
• Requester.

Below you can find short description of most often used options:
- refresh the VWF list.
- execute the VWF (you can also double click on the VWF line).
- release the VWF. VWF will be automatically assigned to you upon opening it. Use this option to remove it from your inbox and enable other users to access it.
- change the VWF inbox layout.
- sort the VWF list.
- filter VWF list.
- search in VWF list.

Description of Vendor Workflow functionality

Vendor Workflow serves as a built in vendor creation/change template. After VWF approval the information will be distributed to PRS and other target systems noted in the VWF.
VWF Request header
We can have four different types of VWF:

• Create a new Vendor (without web form) – in this VWF the requester fills out all information to create the new vendor. In this type of request, bank data should be sent as an attachment;
• Create a new Vendor (with web form) – in this VWF the requester fills out some data and sends a link to the supplier to fill out the main information as address, bank data, contact details and name;
• Modify an existing Vendor – in this VWF the requester can change or add vendor information as address, name, contacts, and purchasing organization.
• Block/Unblock and mark/unmark for deletion of supplier account – in this VWF the requester can ask to add or remove block or mark for deletion for the supplier.

Select the request that is in your scope and double click on it. In the VWF header you will see basic information about the request such as Requesters Name and e-mail; Request Number; Segment Code; Company Code.

Also in the header of the VWF we have a group of buttons that will command the actions we take in the request.
- used to check all the VWF changes log;
- used to approve the VWF (only after all checks have been completed). This will trigger the changes to be implemented in PF1_50 and WP1.
- used to reject the VWF. It will open a new window were you can write a message to the requester explaining why you are rejecting it. The VWF Request could be rejected when you find a duplicated vendor or when the requester asks us to reject it;
- Used to edit the request. When we identify some mistyped information, special character or to correct any information in the request;
- used to return the VWF to the requester. It will open a new window were you can write a message to the requester explaining why you are returning it. The VWF Request can be returned when you need to ask any additional information or when you need for the requester to complete any information in the request. Note that when you use this option, the request will need to be approved again by the Approver after the updates;
- Appears only for modification requests – used to check what modifications are being requested for the vendor;
- Appears only for creation requests with webformWebForm – When the webformWebForm link is sent to supplier and he does not answer within 3 days DM Team should send it again to the supplier by clicking on this button.
By clicking on button you can see in which queue the VWF is placed.

By clicking on button you can see in who is the approver for this request

VWF that is already completed or is in an inbox of another user can be viewed using transaction Z1S_VWF_REQUEST.
You can view requests by request number.

Checks necessary before approving a request for a new VWF record

Before sending the requests to local LPR's and approving Vendor Workflow that will trigger the required changes/creations in SAP please perform required checks:

• Is required documentation in place?
• Are any duplicate accounts already in the system?

Required Documents

A request for vendor setup/maintenance must be accompanied by following documents:

• Completed template for all new creations requested via SDE Freshdesk ticketing system.

EMEA region:

• Company Letterhead / Invoice or any official documentation, which contains vendor's name, VAT number, additional registration numbers (if applicable), IBAN and remittance address. An e-mail from vendor can also be accepted, if it contains all mandatory details. If vendor is not VAT registered written communication should be arranged.

Both VAT number and IBAN number must be validated as described in Appendix 7 – IBAN validation (Europe) and Validations For Customer And Vendor Master Data Appendix 3 – VAT validation (Europe) and IBAN validation (Europe).
NAM region:

• Company Letterhead / Invoice or any official documentation, which contains vendor's name, address, bank information (if applicable). An e-mail from vendor can also be accepted, if it contains all mandatory details.
• W-9 form except for:
• Applicant interview expense reimbursement;
• Donation payments (local charities, sponsor youth groups activities, etc.);
• Employees;
• Vendor setup for manual payment request to pay back a customer who has a negative balance;
• Amounts received as damages for personal physical injuries or physical sickness (liability settlements for asbestos);
• State institutions, taxes, garnishments
• Contingent workers, if the reason of payment are awards or recognitions;
• Vendors located in Canada – they do not have W-9 form.
• For vendors located in Canada W-8 form (if applicable)

Suppliers falling under W-9 form exceptions should be created as FI (financial vendors) under ZZCD account group in PRS (Z011 a/g in RCS) with default setup details:
Payment terms: Y022 (10D from invoice date)
Payment method: Electronic transfer.
Routing number for US vendors should be validated as described in Validations For Customer And Vendor Master DataAppendix 10.
LAM region: the request for a new vendor setup must be accompanied by:

• Company Letterhead / Invoice or any official documentation which contains vendor's name, the official registration number, address and bank information (if applicable), mandatory for Mexico. An e-mail from vendor can be used instead of letterhead if vendor has indicated companies name, address, bank info and registration number.

CNPJ number for Brazil, RUT for Chile and RUC for Peru should be validated as described in Validations For Customer And Vendor Master Data.Appendix 9Appendix 4.
APAC region: Detailed view can be found here.
Thailand, South Korea, Singapore, China, Japan:

• Business License containing:
• Name;
• Registration number (with an exception of Japan);
• Address;
• Branch (Thailand);
• Representatives name (South Korea);
• Type of business (South Korea);
• Type of industry(South Korea);

• Bank Document containing:
• Bank name;
• Bank branch (Thailand,Singapore, China);
• Account;
• Account holder (Thailand, China)
• Bank Code (Singapore)
• Bank branch code (Singapore)

• Approval from William Lee for Exceptional payment terms

Rest:

• Company Letterhead / Invoice or any official signed documentation which contains vendor's name, the official registration number (if applicable), address and bank information (if applicable).
• Approval from William Lee for Exceptional payment terms

Tax Id for Thailand must be validated as described in Validations For Customer And Vendor Master DataAppendix 4.

Bank detail verification

Due to Solvay audit requirements for bank detail addition/change requests bank information needs to be verified with the supplier. It is done by creating a Vendor WorkFlow with Webform. Additonal information on Webforms can be found on the presentation here.
E-mail templates can be found here.
For bank detail addition/changes:

• Use the email address mentioned at the company code level (Clerk's internet field);
• If email address is not available at the company view, use the one in the general data;
• If email address is not available in the vendor master, check this company in Google and use that email address;
• If email address can't be found in the internet (sometimes companies have only Online web forms for contacting them), contact the responsible buyer;
• Do not send e-mail to the address mentioned on the invoice.
• For Z011 suppliers perform outbound call once, in case no answer / confirmation is obtained, insert the provided bank data. Note! You must inform the Requester and the Approver that bank details were not confirmed.

Exceptions:

• New vendor creations (vendors located in US and Canada only);
• E-mail domain used by supplier to provide new bank account matches Vendor Master Records.
• E-mail used by supplier to provide new bank account matches Vendor Master Records;
• E-mail mentioned in the supporting documentation with new bank account matches Vendor Master Records;
• Vendors located in China, India, Japan, as banking information is being checked during the payment run.
• For Interns bank details can be accepted form HtR.

Data Management will verify bank details by creating a Workflow with webform using transaction Z1S_VWF_REQUEST. Option to Request bank data needs to be selected and vendor number needs to be added.

Once inside the Webform, company code needs to be added. Populate only company 7764 as that way these webforms are easily distinguished between service centers and responsible Team.

In Webform section of the WorkFlow, contact information must be filled. Vendor contact name can be taken from General data – name, vendor contact e-mail can be taken from Phone/Fax/Mail section – E-mail address.
E-mail language must be chosen according to the vendor, as in this language the Webform and defaulted webform text will be sent.

On E-mail body section, Bank E-mail Text is filled asking the supplier to press on the sent link, populate their bank details, add attachment with the Bank account information.
We need to mention the actual Solvay entity with which the supplier is working with – Cytec Canada Inc, Cytec Industries Inc etc.
After saving the webform, new popup window will appear showing the newly created Workflow number. Be sure to note it somewhere as it may come handy.
When webform is sent to the supplier, supplier needs to be contacted by call. FD ticket can be created to GCC Team (PtP HD XXX) asking to contact the supplier and guide them through the links for the webform to help the supplier to fill in the bank data.
This should be done by GCC Team based on the vendor location:
NAM/LAM vendors should be contacted by GCC Curitiba (PtP HD LAM/NAM)
APAC vendors should be contacted by GCC Apac (PtP HD APAC)
EMEA vendors should be contact by GCC Riga (PtP HD RIGA)
Note! For languages not maintained by GCC Riga (French, German, Italian, Dutch etc), please turn to GCC Lisbon (PtP HD EMEA).
The template for this communication can be found in the following links:

• US and Canada
• [Chile
• Peru|https://drive.google.com/open?id=1RKvgeBoiuUMCfL1ZUo7GSfuVQcn301mDfquOeeXaJAU]
• Mexico
• EU
• Latvia
• found here for US and Canada, here for Chile, Peru and Mexico, here for EU, here for LV.

For bank detail addition/changes:

• Use the email address mentioned at the company code level (Clerk's internet field);
• If email address is not available at the company view, use the one in the general data;
• If email address is not available in the vendor master, check this company in Google and use that email address;
• If email address can't be found in the internet (sometimes companies have only Online web forms for contacting them), contact the responsible buyer;
• Do not send e-mail to the address mentioned on the invoice.
• For governmental institutions (Z011) that don't answer to outbound contact Company Accounting Manager. The correct CAM can be found ;For Z011 suppliers perform outbound call once, in case no answer / confirmation is obtained, insert the provided bank data. Note! You must inform the Requester and the Approver that bank details were not confirmed.

Exceptions:

• New vendor creations (vendors located in US and Canada only);
• E-mail domain used by supplier to provide new bank account matches Vendor Master Records.
• E-mail used by supplier to provide new bank account matches Vendor Master Records;
• E-mail mentioned in the supporting documentation with new bank account matches Vendor Master Records;
• Vendors created for and located in China, India, Japan, as banking information is being checked during the payment run.
• For Interns bank details can be accepted form HtR.

Process specifics for Latvia.
For vendors located in LV and created for 7764, please call the supplier prior sending the e-mail, to let them know of the process.
Process specifics for LAM.
In case we are struggling to get confirmation for banking details from LAM suppliers (due to language barrier), please ask PtP HD LAM/NAM team to contact supplier in local language.
For interns bank details can be accepted from HtR team.

Process specifics for APAC.
New vendor creation or banking information change when e-mail matches e-mail in SAP:

• DM notifies requester asking to inform vendor that Solvay will contact the vendor to confirm banking information;
• DM contacts SPOC GCC asking to contact the supplier (FD ticket: PTP HD APAC). Include requesters/buyer's name;
• SPOC GCC contacts vendor;
• Vendor confirms banking info;
• SPOC GCC forwards supplier's confirmation to DM. Some documentation should be attached (e-mail is not considered as official document);
• DM adds banking info.

Banking info change when banking info comes from e-mail address that differs from the e-mail address in SAP:

• DM notifies requester (LPR, buyer, someone from AP team) asking to inform vendor that Solvay will contact the vendor to confirm banking information;
• DM contacts SPOC GCC asking to contact the supplier. We should advise on the remittance, general, ordering e-mail addresses from SAP, indicating that we received banking info from different e-mail. Include requesters/buyer's name.
• SPOC GCC will use e-mail addresses from SAP to confirm bank data. If no answer received, then SPOC GCC will contact buyer/LPR explaining that supplier does not reply and we have to perform banking info update in the system and will ask requester/LPR to provide valid contact details
• SPOC GCC uses e-mail address provided by requester/LPR to confirm banking info;
• SPOC GCC forwards supplier's confirmation about bank data DM. Some documentation should be attached (e-mail is not considered as official document);
• DM adds banking info and updates remittance e-mail in SAP.

Fresh desk ticket for contacting SPOCGCC
In order to contact SPOC GCC team, please submit request for following request type/process.

With following group:

GCC Team's Procedure.
If the GCC Team receives anything related to bank details, they will transfer the ticket to Data Team to determine the necessary actions as only Data will be able to better tell if an outbound is required, which team should perform it and if necessary, transfer the ticket back to GCC for outbound.
If the outbound from GCC has been unsuccessful after their 3 attempts, the ticket will be transferred back to Data Team for further actions:

• If there is no Bank Data in Vendor Master, the new provided Bank Details are to be inserted to ensure payment on time and e-mail to the requester and Domain Manager is sent, informing that it was not possible to confirm bank details but to ensure payment on time the same was inserted without verification.
• If there already is Bank Data in Vendor Master, payment is performed to what we already have and no changes are made until further contact from the supplier.

Duplicate Check

Duplicate check must be performed, and if necessary the master data of the vendor has to be updated.
To check if the vendor already exists in the system, execute the transaction XK03. The check should be done in both systems: PRS and RCS.
Please follow the guidelines below in order to determine whether two vendor accounts are duplicated. Note that when we have suspicion of outdated information in the system supplier must be contacted.
VN - HQ address. Account for which PO's can be created.
OA - ordering address. Can refer to both Z009 and Z010.
PI - remittance address. Used for paying the supplier.
VN
Two VN accounts can be considerate duplicates, if they have the same name and Tax ID. In case of several branches (divisions, DBA's, T/A etc.) regional office should be contacted (FD PTP RO Provisioning)
OA
Two OA accounts can be considerate duplicates:
In WP1 - if they have the same name, address and contact details.
In PF1_020 - if they have the same name, address, contact details and are used for same P.Org.
PI
Two PI accounts are considerate duplicates, if they have the same name, address and Tax ID. In case of matching Bank details additional checks should be made in order to ensure, that all remittance addresses in the system are up-to-date.

In case when duplicated account has been located, please follow the guidelines described here.
It's advised to use three types of searches:

• by Name
• by Address
• by Tax Information

The search should be done with multiple searches using different spots in order not to limit your search. The main spots are:

• Name;
• Postal code;
• PO Box;
• Tax Number 1: Federal Tax ID (US) / RFC (MX) / CNJPJ (BR) / CUIT (AR);
• Tax Number 2: Social Security ID (US) / CPF (BR) / NIP (AR).

Remember to use "{}{*}" with the significant part of the vendor name to look for it, this will show all vendors that have any character written after or before the name typed. This can be used also for address and tax fields.

For example:

You will receive all records beginning with the "BRUZZONE".

In order to access search go to XK03 and click on the field vendor then click on match code or just press "F4":


In PRS you should use the tab "Vendor (General)" and tab "Vendor by Tax Information".

In RCS you can use only the tab "Vendor (General)" that will give you the necessary fields.

For EMEA vendors, please switch to "Vendor by Tax Information) view:

If the vendor is not created in our system, you can proceed with its creation. If it is already created, check for possible updates and inform the number to the requester.

Approving a Request to create a new vendor (Without Webform)

Once you are inside the request, you should check all tabs to validate the information and align it to the rules that we have. The complete description of each tab will be presented below.

Main Rules to create a vendor

When approving a new VWF request, there are some rules that must be strictly followed:

• All the information must be entered in upper case;
• No special characters are allowed, such as:

  "	'	`
  <ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="90d10f72-f9e7-45b3-b1f5-eedcafed41d6"><ac:plain-text-body><![CDATA[	( )	[ ]	< >	]]></ac:plain-text-body></ac:structured-macro>
  ***	^	*\\\\*
  =	,	.

  
  
• FOR US: Type complete company name unless the company name begins with "THE". If the company name begins with "THE" do not use.

Example: THE BASF CORP, enter the name in RCS as "BASF CORP".

• Abbreviate as follows (if applicable):

• No spaces are to be entered for company names with alphabetical abbreviations, example, ABC CO and not A B C CO.
• FOR US: When vendor has another name like a DBA (Doing Business As) mentioned in the W9-form, this name should be written in the second line with "DBA" in the beginning.

General Data 1

On the first tab check the following information:

Vendor

• Name: The legal name of the vendor as on the W-9 form (US) / "Cartão CNPJ" (BR) / RFC (MX) or as in the form (if available).
  • If the name has more than 35 characters, it should be split in two lines.
  • Sometimes the requester can fill another line that is used to enter other names the vendor is known as. E.g.: DBA, C/O, FKA etc.

• Account group: based on vendors location and type. More detailed description can be found in Chapter 1.4.3.1.
• Vendor: vendor number in PRS. Empty for new vendor creation.
• Language: List of supported languages can be found here. If in doubt use English.
  • English for US and TH;
  • Portuguese for BR;
  • Spanish for other LAM countries and MX.
• Search Term 1: Should capture the "essence" of the vendor's name. Usually first 10 digits from company's name.
• Search Term 2: Used to indicate vendor's roles. Example: VN,OA,PI,GS (no spaces, use comma as a separator).
  • VN – role assigned to vendors Headquarters (corporate) address
  • GS – Good supplier address (usually is the same as VN unless specified otherwise)
  • PI – Remit to Address/Invoicing party
  • OA – Ordering Address

Possible options for Search Term 2:

• • • • • VN,OA,PI,GS
        • VN,OA,GS
        • VN,PI,GS
        • VN,GS
        • OA,PI
        • PI
        • OA

For Financial vendors (PRS= a/gZZCD = RCS a/g Z011) this field is not populated.
For Ordering Address only vendors (PRS = a/g ZxAD = RCS a/g Z009) Search Term2 field can be used to indicate VN vendor number it is linked with (not advised for shared with PF1/already created records).
Physical Address

• c/o: 'Care of' / 'Attention to' name (if applicable). Part of the address if the recipient is different from the occupant and the names are not similar. Starts with "C/O" or "FAO", else blank.
• International version: filled in for Korea and China. More details can be found in Chapter 1.3.4.2.1.
• Street: Main field for street address of vendor (w/o house number)
  • 
    
  • This fields is mandatory, therefore put "." "#", if only PO Box address is available.
  • For PO Box addresses sectonsection should be used.
• House Number: Part of the address that indicates house number. If it's not clear which part of the address indicates house number, populate everything in "Street" field.
• Suppl.: Additional address information, such as floor, apartment etc.
• Postal Code: Postal/ZIP code. SAP provides standard postal code format checks depending on the country maintained :
  • Enter 5 digit zip code or 5 digit "-" four digit when available for US. (08520 or 08520-3022)
  • Enter 5 digit "-" three digit zip code for Brazil. (80240-280)
  • For the following countries postal code is not mandatory: BO, CD, CM, CW, HK, JM, MN, LA, PE, SR, ZM.
• City: Mandatory for all vendors;
• Region: state/province/county (mandatory for all vendors);
• District: District where the vendor is located in
  • Mandatory for China
  • Mandatory for Brazil
  • Populated automatically based on postal code and city for US.
• Tax Jurisdiction Code: If the district and postal code fields are correctly filled, the Tax Jurisdiction code will be automatically filled in according to SAP database;
• Time zone: Automatically determined by the system.

FOR US

• If you have issues with the Tax Jurisdiction Code for US you can access the website: http://www.zip-info.com/search/zipcode.htm

• Mark checkbox 'county name and FIPS code' and enter the vendor postal code in the text box. Then hit 'Go'. The County name (District) will be given:

Postal Address
Can be left empty, if requester provided physical address.

• PO Box: Filled in, if PO Box is provided. If PO Box city and postal code matches the information provided in Street Address, these fields can be left blank.

International translation

For following domestic APAC vendors International Translation must be provided:

• Korea
• China

Option to add International Translation is available in the workflow in cases when supplier is located in one of mentioned countries.

Same information should be provided as in the English version, if not filled in please turn back to the requester:

General Data 2

Tax information – registration numbers of the suppliers. Each country/region has a specific code as in the examples below. Detailed description of mandatory and optional fields can be found in Appendix 1.
FOR NAM (US)

• Social Security: Should be filled by requeserrequester if the vendor does not have a Federal Tax ID;
• Fed Tax ID: Should be filled by requester. .
• 
  
• Note - When a W-9 is received with mention of a disregarded entity, if there is an FEIN number detailed on row 2, that number should be maintained in the system when creating the vendor master record.  The number to be used is highlighted in yellow for the case below. If there is not an FEIN in row 2, then the FEIN supplied in row 1 would be used.
• .

FOR NAM (MX)

• RFC: Registration number of the legal entity.

FOR EMEA (FR)

• VAT Registration No: Registration number for companies registered in EU;
• Reasn No VAT ID:
• PHY – Physical Person;
• ASS – Association;
• PUB – Public Institution.
• SiretAdditional registration numbers (SIRET, SIREN etc): registration number of the entity specific to the countryRegistration number of the legal entitiy, specific to France.

FOR LAM (BR)

• CNPJ: Registration number of the legal entitiy, specific to Brasil;
• CPF: Substitutes the CNPJ for phisical persons (not legal entities)
• Inscrução Estadual: Mandatory number filled by the requester;
• Inscrição Municipal: Optional number filled by the requester;

FOR LAM (CL)

• RUT: Registration number of the legal entity, specific to Chile.

Segmentation – filled in automatically based on segmentation code provided in the documents header. In case this information needs to be changed contact gps.pur@solvay.com.

• Domain Code: Based on the segment code;
• Class: Defaulted to C, unless specified otherwise.

Reference data – populated for US forwarding agents (carriers)

• SCAC code: The Standard Carrier Access populated for forwarding agents (carriers) in North America. In cases when carrier has different addresses (e.g. remittance address is different), SCAC code should be populated only for main vendor – VN party. For OA/PI parties (if they have different SAP numbers), this field should be left blank.
• Car.freight grp: Defaulted to '001' unless requested differently. Similarly to SCAC code, populated only for the main vendor (VN)

Codes – DUNS registration numbers as can be found in D&B. Please see Validations For Customer And Vendor Master DataAppendix 5 for detailed description.

• DUNS direct code: DUNS registration number
• Reason absence DUNS: reason for missing DUNS number:
  • TBD – To Be Determined
  • UKN – Not found in DUNS
  • SGL – Single location

Phone / Fax / Mail

More than one phone/mobile phone/fax/mail can be entered; however one of them has to be defined as default.

• Telephone: Vendors main telephone number without country code and special characters.
• Fax: Vendors main fax number without country code and special characters.
• E-mail: Vendors main e-mail address. This will be the e-mail address to which PO's will be sent, unless noted differently in OA party
• Notes: Used to indicate SDE/ Freshdesk ticket number or Workflow number to justify vendor creation/changes.

Distribution

This is the tab where the requester chooses to which system the vendor should be sent: ERP (PF1) or RCS (WP1_400). For companies described in this Work Instruction only RCS system should be used.

To successfully transfer record to RCS following fields must be filled:

• Account Group: RCS vendor account group
  • Z010 – regular supplier
  • Z009 – ordering address
  • Z011 – Other third Party
• Tft RCS: X, sends data to RCS
• RCS Transportat: RCS Transportation zone. Must be filled for US, Canada and Brazil (Appendix 11Appendix 6).

Communication Area

In this tab, the requester can insert any additional information or instructions regarding the creation of the vendor. The messages could be for an action for DM Team or any useful information to the approver.

File Attachments

The W-9 Form, the Vendor Creation Form and any other documentation that is considered relevant, such as e-mails, government and other legal documents has to be attached in this tab.
Validations should not be attached.

Purchase

In this tab the requester selects all the purchase organizations that vendor should be extended for. All information regarding Purchasing view is filled in this tab.
The Purcahsing view is automatically created in RCS when the request is approved.

You can use button for detailed P. Org. view.

• Order Currency: currency in which PO's will be issued;
• Terms of payment: always use p/t codes that begins wit "Y..". Dropdown will provide only preferred payment term codes, but other codes can be used, if they exist in the system.
• Incoterms and Incoterms 2: If not provided – put PPD in Incoterm field and "." In Incoterm 2 field
• Pricing Date Control:
  • defaulted to "2", if P.Org. is 3002, 3006, 3010, 3014, 3018, 3022, 3026, 3030;
  • defaulted to "1" for the rest
• GR-Based Invoice Verification: Should be flagged for all vendors, except for the following P.Orgs.: 3008, 3016, 3024, 3032
• Acknowledgment Reqd: should be always flagged
• Automatic purchase order: should be always flagged
• Doc.index active: should be flagged if porg: 3002, 3006, 3010, 3014, 3018, 3022, 3026, 3030; defaulted to blank for the rest
• Shipping Conditions: mandatory for P.Org. 3002, 3006, 3010, 3014, 3018, 3022, 3026, 3030.

Approving a Request to create a new vendor (With Webform)

The main difference from the request without webform is that with this request vendor will be the responsible for filling in some fields. The tabs in this request are very much the same as the ones described in a previous chapter with addition of three tabs that will be described below.

Web Form

This is the tab where requestor fills his Name and contact details.
Contact info for General data: contact information form this field will be copied to General data of the vendor.
Contact info for Bank data: contact information should be added to company code data. This was the e-mail to which request to fill in the bank details for the Webform was sent.

E-Mail body

In this tab will be the email sent to vendor and also any other email that was sent related to this request.
For US and Canada text field is used to clarify that the validity date below is in the European format.

Bank

In request with Webform vendor is able to fill in his bank account.

NOTE: Data Management team is not able to insert, change or delete bank data in VWF. The bank data should be managed in PRS through transaction XK02.

Completing new vendor creation

After approving Workflow for new vendor creation following steps should be made:

• Bank data needs to be added in PRS (if applicable) or modified if neceesary (for more details please see Chapter 1.4.3.4);
• When data has been distributed to RCS supplier needs to be opened for company code requested (for more details please see Chapter 1.4.4);
• If vendor has additional ordering or remittance addresses they need to be manually created in PRS and linked to the main RCS account in partner functions. Please see Chapter 1.4 for details on manual vendor creation.
  • Please note that only remittance party should be opened for company code and contain bank details;
  • In case vendor has several remittance/ordering parties one should be set as default;

Modifying an existing vendor in PRS

When we receive a request to modify a vendor that already exists in the system, the requester will send us the Vendor Workflow with the needed modifications. Data Management team will be responsible to validate the data format and validate legal information before approving it.
We can check the modifications made by clicking on button .

Details

• Tax Code changes (Federal Tax ID, Social Security ID, CNPJ, RFC, etc):
  • New account setup is required as supplier changes their legal entity. This can be done directly in the system outside the WF, with the same setup details as the old account.
  • Following exceptions for Tax Code changes have been allowed:
    • When the vendor was set up without a Tax Code, it can be added later.
    • When it is clear there has been a typo, then an amendment is allowed.
• Ordering address: Any changes in OA parties of vendors found listed here should be approved by the buyer indicated in the same file.
• Remittance address:
  • In case it seems that separate PI party has to be created, reach out to supplier to clarify whether it replaces existing address first.
  • In case new PI party has been created please inform Provisioning teams to update open PO's with the new information (Appendix 16Appendix 10).
• Bank Data changes – follow outbound procedure as described in Chapter 1.3.3.2.
• Duplicate accounts:
  • Any changes to consolidate duplicate accounts can be done directly in the system outside the WF.
  • In case of different setup details, the ones of the remaining account should be maintained.
• Intercompany records:
  • Only company code and purchasing organization data is maintained by Riga DMO;

Standard payment terms are Y024;
Standard purchasing organization is 3200, but different extensions can be requested;
All changes can be performed directly in the system.
IMPORTANT:
The Tax Codes (Federal Tax ID, Social Security ID, CNPJ, RFC) must never be changed since it changes the legal entity. Only following exceptions have been allowed:

• When the vendor was set up without a Tax Code, it can be added later.
• When it is clear there has been a typo, then an amendment is allowed.

In any other situation a new vendor account has to be set up.

Blocking/unblocking and marking/un-marking for deletion

The requester can submit a Vendor Workflow asking to add or remove bocks or deletion flags for the supplier by using Unblock a vendor/Block a vendor option. For re-activation of existing account the same documentation should be provided as for new creation and checks should be done according to Chapter 1.5..

Manual vendor creation/modification

All vendor records are created in PRS (PF1_050) system and then distributed to RCS (WP1_400) system, where they are extended for required company views and/or purchasing organizations.
Main transaction codes:
XK01 - Vendor creation
XK02 - Vendor change
XK03 - Vendor display
XK06 - Mark vendor for deletion (centrally) – should be performed in PRS
XK05 - Block vendor (Centrally) – should be performed in PRS
All available transaction codes related to vendor maintenance can be found in the Appendix 17Appendix 11.

Requirements

Usually all records should be created through the workflow, manual creation is allowed only in exceptional cases, e.g. a vendor has different headquarters/ordering/remittance addresses or vendors registration number has changed. In such cases Vendor Workflow is created for headquarters address only and after a required approval is received, ordering address (OA) and/or remittance address (PI) are created manually in SAP and linked to the main vendor (VN) at the partner function level.
In case of manual creation, all supporting documentation should be provided and the existing data should be checked for possible duplicates (for more info, please refer to Chapter 1.3.3).
General data related creations/modifications are done in PRS, while Company and Purchasing Organization views should be maintained in RCS.

Main Rules to create a vendor

When approving a new VWF request, there are some rules that must be strictly followed:

• All the information must be entered in upper case;
• No special characters are allowed, such as:

  "	'	`
  <ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="0972e9ef-e875-4c8b-8953-993ff110ea43"><ac:plain-text-body><![CDATA[	( )	[ ]	< >	]]></ac:plain-text-body></ac:structured-macro>
  ***	^	*\\\\*
  =	,	.

  
  
• FOR US: Type complete company name unless the company name begins with "THE". If the company name begins with "THE" do not use.

Example: THE BASF CORP, enter the name in RCS as "BASF CORP".

• Abbreviate as follows (if applicable):

• No spaces are to be entered for company names with alphabetical abbreviations, example, ABC CO and not A B C CO.
• FOR US: When vendor has another name like a DBA (Doing Business As) mentioned in the W9-form, this name should be written in the second line with "DBA" in the beginning.

General data creation

Transaction XK01 is used for manual vendor creation in PRS.
Vendor number - assigned automatically by the system; therefore "Vendor" field should be left blank.
Company Code – blank
PurchasingOrganization - blank
Account Group – populated based on vendors location and type as described in the next paragraph. Determines available and mandatory fields as well as number range for new supplier.

Note: Chile and Peru Interns should be created as regular Z012 employees, but Mexican interns should be created as Z011 vendors through Workflow. Request for Mexican interns can be accepted from HR assistant with Cytec Mexico entity's address and bank details entered in Workflow.

PRS/RCS account groups

This field is a fundamental element in SAP for piloting the creation of a new vendor. Each requester has a choice among three possible values:

• Zxyy is a code specific to country, or group of countries, of a regular vendor.

This code depends on the country, where the xyy letters correspond to a country or a group of countries, like: ZBEN for Belgian suppliers, Z3U0 for US suppliers, Z3M0 for Mexican suppliers, ZQ00 for vendors of all countries not represented by a specific code.
It is equivalent to Z010 Standard Vendors within RCS

• ZxAD is a code intended to cover addresses in specific functions in SAP.

This code allows recording companies only for the purpose of sending documents, such as SAP contracts, SAP purchase orders etc. Only address and contact data is being maintained. The same vendor may have one record in group Zxyy and one more, or several, in account group ZxAD. Use ZQAD for vendor of all countries not represented by a specific code.
It is equivalent to Z009 a/g for Ordering addresses within RCS

• ZZCD is for miscellaneous creditors and thus is not in the scope of Purchasing.

This code is intended for creditors that bill expenses that are not purchases, such as taxes, non-negotiable fees, etc. The same company may have a record in Zxyy as a vendor, and a second one in ZZCD as a miscellaneous creditor (for example, a law company may bill law consulting and also legal non-negotiable fees). In order to avoid duplication in the system it is advised that in such cases only Zxyy account group should be maintained.
It is equivalent to Z011 Other third Party within RCS and after creation it should be added to ZWFA05Q table, see Chapter 1.4.5.
The correct account group should be chosen based on vendor's location (country) not the company code we're creating it for. For example, if you're creating Belgian vendor for company 7008 (Cytec Industries INC), you should chose a/g ZBEN.
Current PRS account groups and their equivalents in RCS

Create Vendor: Address screen

The following fields should be populated in this screen in CAPS.

Name

• Name: The legal name of the vendor as on the W-9 form (US) / "Cartão CNPJ" (BR) / RFC (MX) or as in the form (if available).
  • If the name has more than 35 characters, it should be split in two lines.
  • Sometimes the requester can fill another line that is used to enter other names the vendor is known as. E.g.: DBA, C/O, FKA etc.

Search Terms

• Search Term 1: Should capture the "essence" of the vendor's name. Usually first 10 digits from company's name
• Search Term2: Used to indicate vendor's roles. Example: VN,OA,PI,GS (no spaces, use comma as a separator).
  • VN – role assigned to vendors Headquarters (corporate) address
  • GS – Good supplier address (usually is the same as VN unless specified otherwise)
  • PI – Remit to Address/Invoicing party
  • OA – Ordering Address

Possible options for Search Term 2:

• • • • • VN,OA,PI,GS
        • VN,OA,GS
        • VN,PI,GS
        • VN,GS
        • OA,PI
        • PI
        • OA

For Financial vendors (PRS= a/gZZCD = RCS a/g Z011) this field is not populated.
For Ordering Address only vendors (PRS = a/g ZxAD = RCS a/g Z009) Search Term2 field can be used to indicate VN vendor number it is linked with (not advised for shared with PF1/already created records).
Street Address

• C/O: 'Care of' / 'Attention to' name (if applicable). Part of the address if the recipient is different from the occupant and the names are not similar. Starts with "C/O" or "FAO", else blank.
• Street: Main field for street address of vendor (w/o house number).
  • Steet 1 and Street 2 should not be used for vendors located in Thailand.
  • This fields is mandatory, therefore put "." "#", if only PO Box address is available.
  • For PO Box addresses secton should be used.

• House Number: Part of the address that indicates house number. If it's not clear which part of the address indicates house number, populate everything in "Street" field.
• Suppl.: Additional address information, such as floor, apartment etc.
• District: District where the vendor is located in
  • Mandatory for China
  • Mandatory for Brazil
  • Populated automatically based on postal code and city for US.
• Postal Code: Postal/ZIP code. SAP provides standard postal code format checks depending on the country maintained :
  • Enter 5 digit zip code or 5 digit "-" 4 digit when available for US. (08520 or 08520-3022)
  • Enter 5 digit "-" 3 digit zip code for Brazil. (80240-280)
  • For the following countries postal code is not mandatory: BO, CD, CM, CW, HK, JM, MN, LA, PE, SR, ZM.
• City: Mandatory for all vendors.
• Country: Country code, mandatory from system perspective. Drives PRS account group. If vendor's address and particularly country is changing, a new vendor code must be created.
• Region: state/province/county (mandatory for all vendors);
• Time zone: Automatically determined by the system.
• Tax Jurisdictn: : If the district and postal code fields are correctly filled, the Tax Jurisdiction code will be automatically filled in according to SAP database.

If you have some issue with the Tax Jurisdiction Code for US you can access the website: http://www.zip-info.com/search/zipcode.htm

Mark checkbox 'county name and FIPS code' and enter the vendor postal code in the text box. Then hit 'Go'. The County name (District) will be given:

• Internat. versions: used to provide address details in the local language for domestic vendors for the following countries
  • Korea
  • China

Same information should be populated as in the English version. In case of manual creation please copy the information from the checklist provided.
PO Box Address

• PO Box: Filled in, if PO Box is provided. If PO Box city and postal code matches the information provided in Street Address, these fields can be left blank.

Communication

• Language: List of supported languages can be found here. If in doubt use English.
  • English for US and TH;
  • Portuguese for BR;
  • Spanish for other LAM countries and MX.
• Telephone: Vendors main telephone number without country code and special characters.
• Fax: Vendors main fax number without country code and special characters.
• E-mail: Vendors main e-mail address. This will be the e-mail address to which PO's will be sent, unless noted differently in OA party.
• NOTE: For standard vendors (Z010) at least one contact option must be provided.

It is possible, but not advised to enter several Phone/Fax numbers or emails per one vendor. Please note that in such cases one entry must be set as default.
This window can also be used to alter country code for phone/fax numbers.

• Comments: Used to indicate SDE Freshdesk ticket number or Workflow number to justify vendor creation/changes.

International translation

For following domestic APAC vendors International Translation must be provided:

• Korea
• China

Please copy the name and address information to the Internat. Versions tab from the checklist.
Same information should be provided as in the English version, if not provided please turn back to the requester.

Create Vendor: Control

• Authorization: Currently does not have any functionality, but is mandatory from system perspective
  • HQ - when created manually;
  • Vendor's country when created via workflow.
• Tax Number 1-5: Populated with company's Tax information, see Appendix 1 for specifics.
• 
  
• Note - When a W-9 is received with mention of a disregarded entity, if there is an FEIN number detailed on row 2, that number should be maintained in the system when creating the vendor master record.  The number to be used is highlighted in yellow for the case below. If there is not an FEIN in row 2, then the FEIN supplied in row 1 would be used.
• 
• 
  
• VAT Reg. No: Company's VAT number (should be always validated).
• Last Ext.Review: The date of creation
• SCAC code: The Standard Carrier Access Code is populated for forwarding agents (carriers) in North America. In cases when carrier has different addresses (e.g. remittance address is different), SCAC code should be populated only for main vendor – VN party. For OA/PI parties (if they have different SAP numbers), this field should be left blank.
• Car.freight grp: Defaulted to '001' for forwarding agents (carriers) unless requested differently. Similarly to SCAC code, populated only for the main vendor (VN)

Create Vendor: Payment Transactions

This screen should be populated only for vendor records that will be used as PI (Invoicing Parties). Such records should be also opened for Company view in RCS.
Note! Before making any changes in the system please make sure that outbound procedure has been followed as described in Chapter 1.3.3.2.

• Ctry: Country code of the Bank;
• Bank Key: the unique identification code of a bank in a country. It can design a specific bank agency (such as in Germany, France, Italy) or a group of agencies (such as in Belgium).
  • When there is official bank identification in the country, it is used as "bank key".
  • For countries with IBAN bank key can be found in Appendix 6Appendix 3.
  • In the other cases, the SWIFT code or national codification is used. Full list of bank key rules can be found here.
  • In case intermediary bank is provided, please use the details of the final bank. For company codes using CICC please inform PTP SC Payments EMEA and ask them to add the intermediary bank in PI1.

• .
• It must contain at least 8 characters; the last 3 characters can be added if needed.
• Full list of bank key rules can be found here.

Bank Account: Account number.

For countries with account number longer than 18 digits please see the specifics below:

• • Russia, Uzbekistan – first two characters should be placed in "AK" field;
  • Venezuela – last two characters should be placed in "AK" field;
  • Rest – "Reference details" field should be used for additional characters.
  • In case intermediary bank is provided, please use the details of the final bank. For company codes using CICC please inform PTP SC Payments EMEA and ask them to add the intermediary bank in PI1.
• Account holder: The account name. If it matches the vendor name can be left blank with the exceptions below:
  • China (in local translation)
  • Indonesia
  • Australia
  • Singapore
  • Japan (in local translation)
• AK: this field is populated for:
  • several European bank accounts based on IBAN structure,
  • Brazilian bank data (see Chapter 1.4.3.4.1),
  • Mexico bank data (see Chapter 1.4.3.4.1),
  • Japan bank data:
    • 01 – savings account
    • 02 - current account
  • 
    
• BnkT: Currency + sequential number (e.g. EUR1, USD1), "1" indicating the newest or main account.. If bank account is used for several currencies, use "ZZZ1".

• Reference details:
  • Remaining part of the bank account for bank accounts exceeding 18 characters
  • Populated, if vendors reference is a fixed value
  • For US (upon request):
    • CCD – remittance is sent by Solvay bank account 4044 or local account
  • CTX – remittance is sent by suppliers bank
• AK: this field is populated for:
  • several European bank accounts based on IBAN structure,
  • Brazilian bank data (see Chapter 1.4.3.4.1),
  • Mexico bank data (see Chapter 1.4.3.4.1),
  • Japan bank data:
    • 01 – savings account
    • 02 - current account

Specifics for Mexico and LAM

MEXICO 
The CLABE (Clave Bancaria Estandarizada) is a banking standard for bank account structure in Mexico. CLABE consists of 18 characters:

• • • 3 digit bank code (list of most popular bank codes can be found in Appendix 9Appendix 5)
    • 3 digit branch office code
    • 11 digit account number
    • 1 control digit
• Bank key: SWIFT (already existing Banks and Solvay Legacy vendors can have different Bank Keys, but for new creations please use SWIFT)
• Bank account :
  • for BANAMEX/CITIBANK bank accounts please populate 11-digits account number

• • for non-BANAMEX/CITIBANK accounts please populate CLABE number

• Account Key (AK):
  • should be populated with "01" values for all vendors unless requested otherwise
  • in some special cases the vendor requires a numeric or alphanumeric reference (info gathered and provided by Local Finance):
    • • Value '99' to indicate that vendor expects a value in the alphanumeric reference field in the XML (max 20 characters);
      • Value '98' to indicate that vendor expects a value in the numeric reference field in the XML (max 10 characters);
      • Value "96" if the vendor expects two references (a numeric and an alphanumeric) in the XML with the numeric reference stored in the master data (field reference details), and the alphanumeric one in the document;
      • Value "97" if the vendor expects two references (a numeric and an alphanumeric) in the XML with the alphanumeric reference stored in the master data (field reference details) and the numeric one in the document.
• BnkT field is used to populate bank account's currency:
  • Currency code + sequential number (Ex. MXN1)
  • ZZZ + sequential number for multi-currency accounts (Ex. ZZZ1)
• Reference details: If vendor's reference is a fixed value, it needs to be put at the Vendor Master Data level. Populated only upon a special request from Finance.

CHILE
There's no specified structure for Chilean bank accounts:

• 3 digits bank code (list of most popular bank codes can be found in Appendix 9Appendix 5)
• account number can be up to 15 digits
• Bank key:
  • SWIFT (already existing Banks and Solvay Legacy vendors can have different Bank Keys, but for new creations please use SWIFT)
  • 3-digits bank code is also populated at the Bank Master level in the Bank Branch field.
• Bank account :
  • remaining bank account number (without branch code)
  • for CITIBANK/BANCO DE CHILE accounts expected length is 10 digits
• BnkT field is used to populate bank account's currency:
  • Currency code + sequential number (Ex. CLP1)
  • ZZZ + sequential number for multi-currency accounts (Ex. ZZZ1)

PERU
The structure of the beneficiary account for interbanks in Peru (CCI) is 20 characters:

• 3 digits bank code (list of most popular bank codes can be found in Appendix 9Appendix 5)
• 3 digits branch office code
• 12 digits account number
• 2 digits control key
• Bank key:
  • SWIFT (already existing Banks and Solvay Legacy vendors can have different Bank Keys, but for new creations please use SWIFT).
  • 3-digits bank code is also populated at the Bank Master level in the Bank Branch field.
• Bank account :
  • Remaining 17 digits of the bank account number (without branch bank code)
  • for CITIBANK PE accounts expected length is 10 digits
  • 
    
  • 
    
  • 
  • 
• BnkT field: is used to populate bank account's currency:
  • Currency code + sequential number (Ex. PEN1)
  • ZZZ + sequential number for multi-currency accounts (Ex. ZZZ1)

BRAZIL

• Bank key: Bank code (list of most popular bank codes can be found in Appendix 9Appendix 5) + the branch number;
• Bank Account: All digits up to the dash;
• AK: Space + digits after the dash.

• BnkT field is used to populate bank account's currency:
  • Currency code + sequential number (Ex. BRL1)
  • ZZZ + sequential number for multi-currency accounts (Ex. ZZZ1)

Bank data maintenance

Usually, when bank key does not exist, system automatically prompts user to create bank details upon adding vendor account. But this information can also be maintained using the following transactions:

• FI01 – bank key creation
• FI02 – bank key change
• FI03 – bank key display
• FI06 – mark for deletion
• FI08 – manually transfer bank details to target system

• Bank Country: country of the bank;
• Bank Key: is the unique identification code of a bank in a country. It can design a specific bank agency (such as in Germany, France, Italy) or a group of agencies (such as in Belgium).
  • When there is official bank identification in the country, it is used as "bank key".
  • For countries with IBAN bank key can be found in Appendix 6Appendix 3.
  • In the other cases, the SWIFT code is used. It must contain at least 8 characters; the last 3 characters can be added if needed.
  • Full list of bank key rules can be found here.

• Bank name: official/full name of the bank
• Region: region of the bank (not mandatory)
• Street: street and house number of the bank branch. In case address or name is too long you can access additional address fields using .
  • • NOTE: for China, Japan and Korea local translation needs to be provided.
    • For China address line 5 must contain CNAPS number.
• City: ZIP code and City of the bank branch.
• Branch:
  • • Russia – Official codification of the bank branch
    • Chile – bank code (3 digits). Can be found in Appendix 9Appendix 5.
    • Peru – bank code (3 digits). Can be found in Appendix 9Appendix 5.
  • SWIFT/BIC: SWIFT code of the bank branch. Validation of SWIFT code is described in Appendix 8Appendix 4.
    • NOTE: Never record (creation or update) a BIC code (SWIFT) with a "1" in the 8th position, even if given by the supplier (or customer): these are "non connected" BIC that cannot be used for payment. If such input appears, an email must be sent to CICC BO (bo.cicc@solvay.com) to ask to check with the Solvay Group bank (BNP), the bank name, city, the IBAN code (or bank account) and the correct "connected" BIC associated. CICC will afterwards provide a confirmation of the correct SWIFT code to use.
  • Bank Number: National codification of the bank :
    • Bank Identification used in the IBAN codification. If this information has not been populated automatically, please fill in the correct information manually;
    • National Identification for Argentina, Brazil, Canada, Japan, Russia and USA;
    • Full list of bank number rules can be found here.

Alternative/Permitted Payees

Permitted Payee will be the account to which the payments are physically made. It is usually used for:

• Mexican vendors using custom agents, which should be set up as permitted payees.
• Chilean vendors using broker services (brokers are paying to suppliers in advance), which should be set up as permitted payees.
• Vendors participating in SFP program.

In order to add Permitted Payee choose button and add the party to which payments should be made.
NOTE! Permitted Payee information is not automatically transferred from PRS to RCS and it should be added in RCS manually.

NOTE! Permitted payee should not be used as the PI party for the same supplier.

SFP Program

For a vendor to appear at the SFP (also referred to as Supply Chain Finance) reports on SAP, it is necessary to make some changes at the Master Data level. This setup will ensure that payments are being made directly to the bank not the supplier.
Company codes using SFP program:

• • 7008 – Cytec Industries Inc

NOTE! No changes should be made to SFP flagged vendors unless the request comes directly from purchasing.
Setup in PRS
Extra Master Data
In PRS Purchasing segmentation field add SFP.

Payment transactions
The Permitted Payee at the General data level for SFP vendor should have the JP Morgan information, otherwise the payment instead of going to the bank, will go directly to the vendor.
Currently we have following JP Morgan accounts available:

• US – 2113681 JPMORGAN CHASE BANK, NA
• GB – 2823930 J P MORGAN CHASE BANK
• BR – 9901018838 BANCO J P MORGAN S A

Setup in RCS
Supplier Financing Cockpit
Using one of the following transactions maintain SFP cockpit:

• Go to:
  • Z1Y_SFP_COCKPIT_ERP
  • Z1Y_SFP_SEL_MANT
• Choose "Customizing-Alternative Payees" and press "Run";

• Add new Company code, Vendor, Payee combination:

Vendor Master data

• At the company code level
  • check, if the payment terms are set up according with the contract. Standard payment terms for SFP are NET90;
• check, if the correct payment method has been set (ACH/Bank transfer);
• At the purchasing organization level check if, the payment terms are set up according with the contract. Standard payment terms for SFP are NET90. Please note that payment terms should not be changed for whole purchasing organization, but only adjusted in plant level.

If there are any invoices already posted on the vendor account that need to be included in the SFP, it is necessary to change the due date and the payee directly on the posted document. Contact Finance department and ask them to perform necessary changes.

SFP Program

For a vendor to appear at the SFP (also referred to as Supply Chain Finance) reports on SAP, it is necessary to make some changes at the Master Data level. This setup will ensure that payments are being made directly to the bank not the supplier.
NOTE! No changes should be made to SFP flagged vendors unless the request comes directly from purchasing.
Setup in PRS
Extra Master Data
In PRS Purchasing segmentation field add SFP.

Payment transactions
The Permitted Payee at the General data level for SFP vendor should have the JP Morgan information (vendor # 2113681), otherwise the payment will not go to bank, it will be paid directly to the vendor.
Setup in RCS
Payment Transactions Accounting
At the company code level check, if

• the payment terms are set up according with the contract;
• the correct payment method has been set (ACH);
• the alternative payee field has the Alternative Payee code:

If there are any invoices already posted on the vendor account that need to be included in the SFP, it is necessary to change the due date and the payee directly on the posted document. Contact Finance department and ask them to perform necessary changes.

Create Vendor: Extra Master Data

Before saving a vendor, Extra Master data must be populated.

DUNS

• DUNS direct code: DUNS registration number. DUNS registration numbers as can be found in D&B. Please see Validations For Customer And Vendor Master DataAppendix 5 for detailed description.
• Reason absence DUNS: reason for missing DUNS number:
  • TBD – To Be Determined
  • UKN – Not found in DUNS
  • SGL – Single location, to be used when DUNS direct code is populated

Solvay Cross.Reference

• RCS Vendor code: automatically populated with RCS vendor number when link between both systems will be created
• Transfer RCS: "X", creates link between PRS and RCS. All updates done in PRS will be reflected in RCS after some time.

Purchasing Segmentation
This tab is automatically populated if vendor is created via workflow. When manually creating PI/OA parties this can be manually populated based on the VN record.

• VIP Vendor: SFP (for suppliers participating in SFP Program, for details turn to Chapter 1.4.3.4.3.1).
• Segment code: segment code of the vendor as requested;
• Class: "C" – unless requested otherwise

Others

• RCS Transportation Zone: RCS Transportation zone. Must be filled for US, Canada and Brazil (Appendix 11Appendix 6).
• RCS Vendor Account Group:
  • Z010 for Commercial Vendor account group
  • Z011 for Financial Vendor account group
  • Z009 for Ordering Address account group
• Reason of absence of VAT ID:
  • PHY – Physical Person
  • ASS – Association
  • PUB – Public Institution

Press Save . System will generate SAP number that will be transferred to RCS in 20-30 minutes, and then you'll be able to proceed with company code and purchasing organization views.

Company Code view creation

Once vendor appears in RCS, use transaction XK01 to create required extensions for Company code and Purchasing Organization.

Reference section can be used to copy values from an existing vendor. Please note that remittance e-mail and partner functions as well as additional data are not being copied.

Create Vendor: Accounting information

• Recon. Account: defaulted to "40100100"
• Sort Key:
  • defaulted to "009" for APAC entities
  • defaulted to "001" for the rest
• Cash mgmnt group:
  • "A1" if the country of the vendor is the same as the one for the Company Code;
  • "A2" if the country of the vendor is different from the one for the Company Code;
  • "A7" if the vendor is Financial supplier (Z011).
• Thailand Branch details: company's branch number. For HQ use "00000".

Create Vendor: Control

• Payment terms: Must be filled as informed on the form or in Vendor Workflow (always use p/t codes that begins wit "Y..")
• Chk Double inv.: Must be always flagged
• Payment methods:

• Payment block: Used to prevent payments from being made. Usually populated upon request form AP. Populate "A-Part payment block" in order to block payments.
• House Bank: Will be automatically filled with FACT once invoices will be posted in PI1, for companies using CICC in house bank.

• Pmt meth.supl.: Used to provide more information concerning the type of payments. This field is not mandatory and should be populated only upon a special request from Finance. Can be left blank if one vendor delivers multiple services (depending on the invoice).

• Individual pmnt: Notes that open items are not grouped together for payment.
  • Marked for company 7722 with payment method "L" and payment supplement "P8"
  • Can be marked by special request, in cases when separate payments are required.
  • Blank in all other cases

• Alternat.payee: filled in for vendors participating in SFP program. For more details please see Chapter 1.4.3.4.3.

Manual exception

For company 7723, there can be exceptional cases when no bank data is available (e.g. taxes). In such cases payment method can be set as "H" and following steps should be performed.

1. Remove FACT from House Bank field if populated.

1. Go to Factoring Master Data.

1. Check "Manual Exception" box in the Factoring Master Data Section. This will prevent payment being handled via PI1.
2. Add the justification for the manual exception – "Manual Payments"

Create Vendor: Correspondence Accounting

• Acctg. ClerkClerk Abbrev: must be filled in with country initials for all vendors opened for following companies:
  • 7725 – CL
  • 7722 – PE
  • 7776/7734 - CN
  • 7788 – ID
  • 7988 – KR
  • 7774 – TH
• Clrk's internet – e-mail address to which remittance advice should be sent. For suppliers using factoring this information upon request should be populated in PI1 (transaction FK02):
• If specific e-mail has not been noted for remittance advices, please use the general e-mail.
  • In case of new vendor creation – please add the e-mail address here.
  • In case of change – update in PI1_020, transaction FK02. For more details please see Chapter 1.6.1.
  • Companies 7722, 7725, 7788, 7988 and 7774 will not use factoring, therefore remittance contact information should be populatdpopulated in WP1 only.

Create Vendor: Withholding tax Accounting

US
Populated for US W9 reportable vendors. Vendor is considered reportable in all cases except the following:

• if company is a Raw Material supplier;
• if "Corporations" or " Incorporations" is checked on the W-9 form;
• Box is checked next to "Limited liability company", but in the comment is letter "S" or "C" = Corporation.

• WH Tax Country: US;
• With.t.type: FE – Federal 1099 withholding tax reporting;
• W/tax code: 03 – Other Income;
• Liable: Check marked.

LAM and Mexico
Upon new vendor creation finance representative should be contacted for the information to be populatedInformation should be provided in vendor workflow. CIn case of questions correct finance representatives can beorrect contact persons can be found in Appendix 16.Appendix 10.
APAC
If requester doesn't provide us this info we process the request and in the resolution we ask to provide it. We do not chase the requester, as when AP will process the invoice, they will see that vendor is taxable, will call him and then will submit ticket to data providing WHT value for this supplier.
APAC (TH)
Recipient Type is mandatory in case WHT data is populated for 7774 company. It is used to identify whether vendor is an individual person or a legal entity.
If Tax ID starts with:

• 0 – legal entity
• 1-9 – individual person

Other
Populated upon request.

• WH Tax Country: Country of the company code;
• With.t.type: as requested;
• W/tax code: as requested;
• Liable: Check marked.

Financial vendor addition to non-PO vendor list

When new Financial vendor is created (account group Z011) it should be added to the table ZWFA05Q in WP1. This list determines suppliers which do not require PO's.
Z010 vendors can be added to this list upon special request from finance (e.g. utility vendors that do not have PO's). Such requests should be approved by the site controller.
Press "New Entries" and populate Company code and Vendor number. Site field is optional and usually is not populated.

Purchasing Organization view creation

Create Vendor: Purchasing Data

• Alternative data: can be used to define Purchasing data and/or partner functions on plant level. Detailed description on how to use this function can be found in Appendix 13Appendix 8.
• Order Currency: currency in which PO's will be issued;
• Terms of payment: always use p/t codes that begins with "Y..";
• Incoterms and Incoterms 2: If not provided – put PPD in Incoterm field and "." In Incoterm 2 field
  • Pricing Date Control:
  • defaulted to "2", if P.Org. is 3002, 3006, 3010, 3014, 3018, 3022, 3026, 3030;
  • defaulted to "1" for the rest

• GR-Based Invoice Verification:
  • Blank for the following P.Orgs.: 3008, 3016, 3024, 3032;
  • Flagged for the rest.
• AutoEvalGrSetmt Del.: flagged upon request, if Self Billing is used.
• AutoEvalGrSetmt Ret.: flagged upon request if Self Billing is used.

Note: Self Billing - Contrary to the usual process, the customer creates the invoice, based on its own recorded goods receipts, service acceptance, freight costs, invoice plans, consignment stock withdrawals and sends the (auto)-invoice to the supplier. In all cases, auto-invoicing needs to be negotiated with the supplier. Invoicing Plan is a type of self-billing in which regular due costs such as fees, rents or contributions are fixed in an invoicing plan in the purchase order and are invoiced.

• • 
    
• Acknowledgment Reqd: should be always flagged
• Automatic purchase order: should be always flagged
• Doc.index active:
  • • Should be flagged if porg: 3002, 3006, 3010, 3014, 3018, 3022, 3026, 3030;
    • Defaulted to blank for the rest
  • Shipping Conditions: filled in for P.Org. 3002, 3006, 3010, 3014, 3018, 3022, 3026, 3030

Create Vendor: Partner functions

By default vendors will have four partner functions: OA, VN, GS, PI

In case there are a different SAP numbers for Remittance address (PI) or Ordering Address (OA) there can be either changed or added this screen.
In case there are several PI/OA partners, please mark one as default.

Blocking and/or marking for deletion

Blocking vendor for posting and/or for purchasing prevents users from using company code and or purchasing data.
Marking supplier for deletion indicates that all data in this master record is to be deleted. This flag is used to warn users that no new items should be posted on this account.
There are several cases when vendor inactivation might be necessary:

• Supplier has gone out of business;
• We are no longer in business with the supplier;
• Registration number change has taken place;
• Account is a duplicate.

There also might be cases when vendor needs to be blocked/marked for deletion only for specific purchasing organization/company code:

• Supplier has been opened for incorrect P.Org;
• Supplier has been opened for incorrect company code;
• Separate PI party has been added for VN party, and VN account should cease to serve as invoicing party.
• 
  
• Duplicate accounts and Tax ID change
• 
  
• Please make sure that remaining/replacement account duplicates:
• P.Org. and company codes of the inactivated account;
• Partner functions (in the sense of addresses/e-mails maintained). Make sure to default OA, PI, GS parties for specific plants in alternative data, if needed.
• For inactivation where replacement account is available please follow the steps below:
• Change vendor name to #USE 123456# VENDOR NAME (apply only when payments aren't made by CHEQUE);
• Change search term to "****";
• Add note in Comments "SDEFD #123456 USE 123456" (apply when payments are made by CHEQUE);
• Perform open item checks described in the following chapters:
• If open items can be and are moved apply "Deletion Flag" and proceed with step 7;
• If open items cannot be moved proceed with step 5;
• Apply "Deletion Flag";
• Note! Any changes in Purchase orders (e.g. PI party change) or invoices should be done prior addition of the "Deletion Flag".
• Wait for open items to be processed;
• Block vendor for posting and purchasing;

1. Change vendor name to #USE 123456# VENDOR NAME (in case it was not done beforehand);
2. Remove bank account(s).

Open item checks required before vendor inactivation

In order to proceed with vendor inactivation, a procedure is in place to ensure that no invoices/source of supply/open PO's will remain active.
Before inactivating the supplier please check it's its partner functions and to whom it has been linked, to make sure that all related vendor accounts are covered. This can be done using SQ00 query (Appendix 14Appendix 9). Following checks should be performed for all relevant vendor parties.

Please contact Freshdesk PtP Data & Analysis team for open items that are outside the scope of Riga Data Management, e.g.,
invoices opened for other company codes,
PO's created for non-Legacy Cytec sites,
contracts created for non-Legacy Cytec sites,
Vendor is in E-Catalog,
Vendor has EDI (maintained by D&A Lisbon), .
In next chapters we will review an example of RCS Vendor code and the steps to be taken in order to inactivate (block and mark for deletion) this record in WP1.

Verification if there is a link between PRS and PF1_020

In RCS you can check for PRS vendor code in Extra Master Data Solvay Cross Reference tab.

In order to verify whether the record exists in PF1_020 as well, go to PRS vendor account, Extras, Deletion flags.

If vendor record has "General Data" box flagged – this record exists in PF1_020. If such is the case same checks as described in further chapters should be done in PF1_020 as well. Create a Fresh desk ticket with the request to perform such checks in PF1_020 and finalize the deletion of the record.
If it's unflagged not flagged – a record exists only in PRS and RCS.

Check if vendor is an approved carrier

Check, if vendor is among approved carriers. List of approved carriers can be found here.
In order to successfully use vendor for carrier purposes, it must be open for both company code and purchasing organization. In case vendor has been identified to be among approved carriers used for creating routes, please do not block it for company code in case of PI party change.
If full inactivation is required for one of the vendors in the list referenced above:
In case vendor is open for P.Org. 3008 - Trans/Logist. Europe please reach out to EMEA Logistics team (gbsfreighteu@solvay.com) in order to inform them of the replacement account (if any) and arrange confirmation that we can proceed with the inactivation.
For the rest, please reach out to OTC LOGISTICS team using Freshdesk in order to inform them of the replacement account (if any) and arrange confirmation that we can proceed with the inactivation.
Please note that in rare cases duplicate accounts for freight vendors may be required due to system restrictions.
Check if vendor is added to non-PO vendor list
Before vendor inactivation check if vendor exists in table ZWFA05Q. This list determines which suppliers do not require PO`s. If the vendor exists, the vendor should be removed from the list and replacement account added. Please note approval is not required for such case.
Press "New Entries" and populate company code and vendor number. Site field is optional and usually is not populated.





To remove the specific entry, press on the line and then press "Delete".

Check for Active/Inactive PIR (ME1L)

Info Records can be seen using transaction ME1L.
In the search use the vendor number that should be inactivated.


When reviewing the results of the report please keep in mind the following:

• Info Record can have a deletion flag at master level and/or at purchasing level.
• Info Record can also be inactive i.e. without price. For these cases PIR should not be replicated to the new vendor.
• Only active Info records should be considered for replication (and only if the vendor in process of deletion is being replaced by a new one).

When replacing PIR you need to ensure that the master data for new PIR is fully completed. For that you can use an extraction provided by Mass transaction ZWPU06A.
It will provide you only the active PIR and the inactive PIR with purchasing data (assigned to a specific plant). PIR's marked for deletion as well as Information without purchasing data will be excluded. Please see an example for extraction in the following file . Active records can be recognized by End Date past the current date and price in the Rate field.
In order to run the report:

• Add vendor number in Run Step 1 – File creation / Step 1 – Selection criteria for identifying PIR to update section.
• Set file location in Step 1 – File Creation.

Once the report is completed you will receive confirmation from the system:

Transaction ZWPU06B can be used to get more detailed PIR information, but please note that for this report validity date and Purchasing Organization is mandatory.

How to proceed with open items?

PIR's created for plants not maintained by Riga Data Management:

• Freshdesk ticket for D&A team should be created.

PIR's created for 3012; 3020; 3028; 3004 – Industrial Supplies:

• Created Created/Inactivated by Riga Data Management team.
• Approval from the LPR or Store Room Owner in charge should be received before inactivating PIR and/or replicating it for the new vendor number.must be informed of any inactivation's and creations of new PIR's in case of Duplicate accounts/Tax ID changes.
• For more detailed information on PIR creation/inactivation please consult the respective Work Instructions: "Industrial supplies materials creation and management"

PIR's created for other Purchasing Organizations:

• Maintained by LPR's (indirect)/Provisioning(direct) for Technology solutions:
  • gbsprocurementindirect@solvay.com for NA and EU indirect spend P.Orgs.
  • gbsprocurementna@solvay.com for NA direct and packaging P.Orgs.
• For the rest Freshdesk request should be submitted.

Check for active contracts (ME3L)

After PIR check vendor should also be checked for active contracts. This can be done using transaction ME3L.


Check the validity date on the contract that can be found on the header of the document. In order to replicate an active contract for new vendor number an approval from the responsible buyer needs to be arranged.


The output might be too big, depending of the existing contract details. As you only need the header information, in order to verify the contract validity date, you may access it using the following transaction:
SQ00 query PURCH_CONT_HEA in ZW_PU Group

How to proceed with open items?

In case replacement account should be used reach out to the following contacts and ask for the existing contract to be cancelled and replacement to be created on new account:
For Technology solutions Direct Spend provisioning team;
Freshdesk ticket for D&A team for the rest.
Contracts created for plants not maintained by Riga Data Management:

• Freshdesk ticket for D&A team should be created.

• • Contracts for plants maintained by Riga Data Management:
• Maintained by LPR's:
  • gbsprocurementna@solvay.com for NA direct and packaging P.Orgs.
• For the rest Freshdesk request should be submitted.

Check for open PO's (ME2L)

Open PO's can be located using transaction ME2L. ME2N can also be used.
Scope of List: determines that system will search for all PO's for this supplier;
Z_ALV_BEST for WP1
ZZ-ALV-BES for PF1
Selection Parameters: narrows the search down for PO's with open invoices.
RECHNUNG for WP1
WE103 and WE101 for PF1_020


Please use button to add following columns:

• To be inv.: shows amount that still needs to be invoiced;
• POrg: purchasing organization for which PO has been created;
• PGr: purchasing group ($07 – Riga indirect);
• Plant: plant for which PO has been created;

Vendor has open PO's, if there are any records with amount different from 0.00 in either "To be del." or "To be inv." tab.

How to proceed with open items?

• Provisioning team should be contacted for moving/changing open items.
• 
  
• In case replacement account should be used reach out to the appropriate provisioning team and ask for the existing PO to be cancelled and replacement to be created on new account.
• If open PO's cannot be moved please:
• Ask provisioning team to update PI party in order to ensure that payments will be made to the new vendor account;
• We can check for the current PI party in PO's using SQ00 – group ZW_PU, query PURCH_ORD_PART.
• Apply "Deletion Flag". This will enable Goods Receipt, but will also warn Provisioning, that new PO's should not be placed.
• NOTE!
• All changes to PO (such as PI party change) must be done before applying the deletion flag;
• In case AP needs to reverse invoices, deletion flag can be applied only after the reversal is completed.
• In case provisioning needs to update some details afterwards the deletion flag can be temporary removed.

In cases when there is an output from the system the supplier should only be only blocked (PRS), not marked for deletion.
Deletion flag can only be applied when all PO's are invoiced.

In case different PI party should be used for PO's for sites maintained by Riga Data Management contact local LPR's to ensure that open PO's are updated accordingly:

• gbsprocurementindirect@solvay.com for NA (except Mexico) and EU indirect spend P.Orgs.
• gbsprocurementna@solvay.com for NA direct and packaging P.Orgs.
• For the rest Freshdesk request should be submitted (PGr or Plant is outside the scope of Riga).

In case different PI party should be used for PO's for sites not maintained by Riga Data Management contact Freshdesk D&A team.
NOTE! Any changes to PO need to be done before adding Purchasing block.

Check for open invoices (FBL1N)

Use transaction FBL1N to check for open invoices.

ZFR9 company code should be excluded as we don't have authorization to check open activities for this company. Use company code selection to perform this action:


If you receive notification, there are no open invoices for this vendor code.
Open invoices will have red indicator in "Stat" columscolumns, but check Doc. Date there might be very old invoices that were not closed properly:

Please note that this report might miss invoices already posted and pending for payment. Another check should be done in PI1_020 system using the same transaction. For details please check Chapter 1.6.
Different company codes are being used in PI1 (depending on region):

• Payments for 7008, 7752, 7723 are being handled via company code 4044;
• Payments for 7764 are being handled via company code 0231.

How to proceed with open items?

In cases when replacement account has been created, invoices should be moved to the correct account. For this action AP team should be contacted:

• 7008; 7752 - apinquiriesna@solvay.com
• 7764 - apinquirieseu@solvay.com
• Rest – Freshdesk ticket for AP should be created

In cases when there is an unreasonable amount of invoices already posted for payment and payment information for the vendor is correct, we can wait until they have been processed. In order to ensure that no new invoices are posted please ma:

• Replace name with "****" in search field (PRS);

• Add SDE reference and replacement vendor number "USE 123456" in notes (PRS);

• Mark vendor for deletion in company code view (RCS), this will prompt a warning message for AP, when they will try to post new invoice.
• Note! If central deletion flag has been applied in the previous step there is no need to apply it for selected company code.

Block

In order to block vendor select transaction code XK05.
In PRS only vendor number should be filled in:

Posting block - prevents users from using company code data (e.g. posting invoices).
Purchasing Block – prevents users for using purchasing data (e.g. posting purchase orders).
Note: These blocks will be distributed to WP1, PI1 and PF1_020.


In RCS fill in the company code and/or purchasing organization for which the block should be added:

In RCS only blocks for Selected co. code and Selected purchasing organization should be used.

Mark for deletion

In order to mark vendor for deletion select transaction code XK06.
In PRS only vendor number should be filled in:

Deletion Flags – marks vendor for deletion. Is used to warn users, that vendor is going to be blocked and allows:
Goods receipt in PO's;
Posting of invoices;
Invoice payments.
Note: This deletion flag will be distributed to WP1, PI1 and PF1_020.














In RCS fill in the company code and/or purchasing organization that should be marked for deletion:

In RCS deletion flags should be used only for Selected co. code and Selected purchasing organization.

Additional steps

• When inactivating the supplier following steps should be taken:

• Add replacement vendor number at the beginning of Name, e.g., "#USE 123456# VENDOR NAME". Apply when:
• Payments are not made by CHEQUE;
• Purchasing and posting block is applied;
• 
  
• Replace name with "****" in search field (PRS);

• Add SDE FD reference and replacement vendor number (if any) "USE 123456" in notes (PRS);
  • Payments are made by CHEQUE;
• Only Deletion flag is applied

Remove bank details. Please note that this action must be performed only after posting block is applied.

PI1_020 – CICC

PI1_020 (CICC - Coordination Internationale des Crédits Commerciaux) is the in house bank. This SAP platform is linked with both PRS and RCS and is used for processing payments. It is applicable to company codes for which Factoring (paying via CICC) is enabled, the rest of the payments are being done through RCS or PF1_020 using SWIFTNET.
Factoring is being used for the following companies:

• NAM
  • 7008 – Cytec Industries Inc
  • 7752 – Cytec Canada Inc
  • 7723 – Cytec de Mexico SA de CV
  • 7427 – Cytec Technology Corp
  • 7030 – Piney River Recovery Corp
  • 7031 – Garret Mountain Insurance Co
• EMEA
  • 7794 – Cytec Industries BV
  • 7764 – Solvay Business Services Latvia Sia
  • 7726 – Cytec Belgium Bvba
  • 7792 – Cytec Luxembourg Sarl
  • 7210 – Umeco Ltd
  • 7714 – Cytec UK Holdings Ltd
• APAC
  • 7786 – Cytec Australia Holdings Pty Ltd

Data Management is using PI1 for the following activities:

• Maintenance and change of e-mails used for remittance advices;
• Checking open items before vendor inactivation.

Login:

• CICC - Production - PI1
• Client 020

Transactions:

• FK02 – change vendor;
• FK03 – display vendor;
• FBL1N – display open invoices.

Clrk's internet addition/change

E-mail used for sending out remittance advices should be the same that is used, in WP1, but as this information is not transferred automatically to PI1 it is populated manually via transaction FK02.

• Vendor: usually number of the vendor in PRS. In case you have only RCS vendor code please use search option "Vendor by country and Duns and Cross Reference".
• Company code: company code of the vendor. Please note that these company codes are different from the ones used in RCS and are based on vendors location:
  • 4044 – used for payments to North American banks;
  • 0231 – used for payments to European banks;
  • 7786 – used for payments to Australian banks;
  • 7418 – used for payments to Japanese banks;
  • 6062 – used for payments to Singapore banks.

NOTE! Company code is automatically generated once the first invoice is posted for payment.

• Correspondence: screen containing Clrk's internet.

• Clrk's internet: e-mail address to which remittance advices will be sent.

Checking open items before vendor inactivation

Invoices can be reviewed using transaction FBL1N.

• Vendor account: usually number of the vendor in PRS. In case you have only RCS vendor code please use search option "Vendor by country and Duns and Cross Reference".
• Company code: company code of the vendor. Please note that these company codes are different from the ones used in RCS and are based on vendors location.
  • 4044 – used for payments to North American banks;
  • 0231 – used for payments to European banks;
  • 7786 – used for payments to Australian banks;
  • 7418 – used for payments to Japanese banks;
  • 6062 – used for payments to Singapore banks.

NOTE! Company code is automatically generated once the first invoice is posted for payment.

• Open items: all invoices that are posted for payment at the date selected. Used to check if any invoices are still open.
• Cleared items: all invoice that have been paid on the date/time span selected.
• All items: both – open and closed items.

• Dynamic selection: gives the ability to add additional filer criteria. For example, in the Assignment field RCS company code can be selected.

When searching for open items you will receive a report with information on pending payments. Useful options:
- Show chosen document in detail;
- Display check information
- Filter/sort the search
- Adjust the layout

• Affiliate/Assignment: RCS company code (company on which behalf the payment was made).
• DocumentNo: number of either invoice or clearing (processed payment) document.
• Amount in DC: invoice amount. If the amount has "-" to it, it means that the invoice has not been paid. Paid invoices should have corresponding line with clearing document number and same invoice amount.
• Net due date: date when invoice should be paid.
• BnkT: number of the bank to which the payment was made.

Creating link between PF1 and PI1

There might be cases when vendor information has not successfully copied to PI1. If we receive request that vendor is not linked with PI1 (CICC in house bank) we should check if there is a link in Extra Master data in PI1_020.

If there is none go to PRS and use transaction Z2RA. Input the PRS number of the vendor with the missing link and choose PI1_020. After some minutes the information will be transferred to PI1.

Remediation process

Remediation process is used in cases when there is a document from a provider of goods or services without purchase order (please do not mistake it for Z011). It might be applied in the following cases:

• In case a nA non-qualified and non-approved carrier is used by sites,
• One time vendors that cannot be paid with p-card,
• AP has received invoice with no PO reference.

Remediation process will be used to pay any outstanding invoices without involvement from purchasing.
In case vendor is not found in the system following steps are performed. and block vendor so it is not used in the future. There is no need of Purchasing approval for the vendor creation that is why specific approach should be taken to create a VWF correctly. Please find below detailed description.

Usually the need for remediation process, will be recognized by requester or AP team when they receive an invoice with no PO reference.
Note! If request for new vendor creation outside WF please double check with the supplier, if this will be a one-time payment:

• if request for new vendor creation is supported by an invoice;
• if request is for new carrier creation.

1. In case of one-time payment please advise requester to go through SRM7 tool to create Remediation Shopping cart for the invoice he wants to pay. Brief process overview can be found here.

1. Requester submits remediation shopping cart using SRM7.

Note! If user does not have access to SRM7, FD ticket should be created to grant access - assign to group "PtP D&A SRM".

Provisioning will arranges the required documentation and submits vendor WF for new vendor creation following remediation process. An invoice should be always be added in attachments.. E-mail or phone number (both for EMEA) should be provided.

1. 1. Note! Remediation WF should follow the rules below:
      1. Company code: WARP
      2. Class: D
      3. Text: Should contain text "Remediation" and company code
      4. Purchasing organization: must be added
      5. Payment terms: Y030
2. All new carrier requests should be double checked with the requester:
   • For recurring payments please follow the usual process;

For one time payments following Remediation shopping cart needs to be submitted.
Data Management will review the data, approve the VWF and create vendor in company code requested. Same documentation and processes should be followed, e.g. outbound by sending Webform.

1. Data Management will trigger the process to collect Tax ID documentation and bank account information, by contacting GCC Team to obtain Tax ID doc and support the supplier in filling the Webform for Bank Data that we have sent.. Note! In case of missing documentation please contact provisioningPlease advise requester to go through SRM7 tool to create Remediation Shopping cart for the invoice he wants to pay. Brief process overview can be found here.

1. If user does not have access to SRM7, FD ticket should be created to grant access - assign to group "PtP D&A SRM".

Related documents:

• • Procure to Pay portal
  • Leaflet for submitting remediation shopping cart
  • User guide

Miscellaneous creditors process

Miscellaneous creditors are created under ZZCD account group (corresponding WP1 account group is Z011). Please see below the differences between standard vendors and Miscellaneous creditors.

* All entities that are providers of goods and services to Solvay (including Solvay companies)

• 
  
• Includes: Leasing (phone, car etc..), Banks*; Factoring*; Trademarks and patents*; Legal (lawyers, bailiffs, etc...); Insurances
• 
  

• - in some cases the involvement may be very limited / borderline (with banks, patents), but the supplier creation must be properly authorised (with segment attributed) and with the way to handle the invoicing (with or without PO) known and defined by Purchasing function.
  The submission of an invoice from a standard vendor should follow Remediation Process.Standard Vendors * Entities for which there is no direct trade of goods and services to Solvay, but there is a payable obligation or commitment
• 
  
• Includes: Public third parties (Treasury, agency customs, etc...); Social third parties (pensions, social security contributions, etc...); Civil associations (subscriptions, donations, etc...); Trade associations (corporate committee, charges, etc...)
• 
  

These vendors need to be limited to the scope defined and not to be used to avoid ordering system + in the request it needs to be explained the reason why the request is being submitted and why a misc. .creditorMiscellaneous creditors

In case vendor is not found in the system following steps are performed:

Requester creates VWF using Miscellaneous creditor tool. If vendor creation request has been received outside VWF please direct them to PtPPSL portal.

Data Management will review the data, approve the VWF and create vendor in company code requested.

Note!

In case of missing documentation please reach out to the supplier directly.

If you have exhausted all the possibilities to confirm the bank details with the supplier / external entity (where at least the phone call step is mandatory) then, finally, the master data should be updated with information in the Vendor Workflow. You must inform the Requester and the Approver that bank details were not confirmed.

If no payment method or terms are mentioned in the communication tab please use:

• • Payment Terms: Y022 (10D from invoice date)

Payment Method: Electronic Transfer

In case approver for existing vendor is not found in the system Data Management will receive request to add approver to Table of Approvers (ZWFA010) in WP1. This can be done via transaction ZWFA02F.
Requirements for additions/changes to ToA:
Approval - either request is sent by the CAM/delegated or his/her formal authorization by email is required
Template
Press "New Entries" and fill in the following fields:
CoCd – company code as provided
Index – automatically will be set as 0 for new entries, next available number, if several entries for the same company are added at the same time
Crcy – currency as provided
Lower Limit Amount – as provided

• Higher Limit Amount – as provided

WEB CYCLE user – Web Cycle user name. Should be created, if is not available.
Active – check marked.

Related documents:

• • Purchasing Service Line portal
  • Miscellaneous creditor tool

User guide
WI for table maintenance in Confulence

1. Once Remediation cart is submitted, Purchasing will receive this info to create a WF with the following information:

1. As per above, we will need to check the invoice, go through Outbound procedure, if necessary, and create manually vendor for the required company.

1. Please pay attention to the company code "WARP" used in WF. As only in this case WF will go for approval only to Finance, and not to Purchasing.

How to check and create IDocs

Sometimes changes will not be automatically duplicated in WP1. The reason for this can be checked in WP1 transaction BD87.
Select the date when the changes were done and set PRS_020 as the Partner System.

Check Application documents not posted dropdown Z_CRE_RCS and the messages that can be found there.

Double click on the issue will open the following window in which you will be able to see the following. Double click on the IDoc number to see detailed description.

In Data records you will be able to find vendor number to which this IDoc is related.

The messages should be checked one by one until the culprit has been found and the issue corrected.
If, after the correction of the issue, the changes still are not being transferred to RCS a new IDoc needs to be created in PRS transaction BD14.
Following information must be populated:

• PRS vendor number;
• Message type – Z_CRE_RCS;
• Target system – WP1_400

Appendix 1 – Requirements for Tax Number 1- 5

Appendix 2 - European VAT identification number structure

Appendix 3 - VAT validation (Europe)

On the website mentioned here under:
http://ec.europa.eu/taxation_customs/vies/
Select the Member state of the supplier. Enter the vendors VAT number without the country code and press Verify.


If the VAT number is valid you will see the following screen which should be saved in .pdf format.

If VAT validation shows vendors VAT number invalid please contact requestor asking to clarify this information. VAT number can be entered in the system only after an official confirmation of VAT correctness has been received from the supplier. In case supplier is not VAT registered official confirmation of this fact should be provided.

Appendix 4 - Tax ID (PE, BR, TH) validation

BRAZIL
Brazil CNPJ number can be validated in the following link:
http://www.receita.fazenda.gov.br/pessoajuridica/cnpj/cnpjreva/cnpjreva_solicitacao.asp
Enter CNPJ number with no dots or dashes and verification and press "Consultar":

If the CNPJ is valid you will receive information about the company – name, address etc.
Please check if the registration number is active. If it is not marked as active please reach out to the requester for clarification.

PERU
Peruvian Tax ID number can be validated using the following web page:
http://www.sunat.gob.pe/cl-ti-itmrconsruc/jcrS00Alias
Enter company's Tax ID (RUC), a security code and click on "Buskar" button:

Company's information will appear below.


You will receive the following screen with the vendors details.
THAILAND
Thailand Tax ID number can be validated using the following Web Page:
http://www.rd.go.th/publish/313.0.html
It will not give you a valid/invalid status, like for most validations, but company's name and address can be verified as well as branch number.

Appendix 5 – DUNS verification

Use Internet explorer to open D&B webpage:
https://solutions.dnb.com/usgrs/jsp/EN-GB/GRSFrameLogon.jsp?news_country=1073

Possible Login details:
User ID: marc.steyaert@solvay.com
Password: Welcome2018
NOTE: please do not forget to log off after search is completed, otherwise no one else could use it. Also, to use this site please turn off Pop-up blocker. 

Enter company's name:

In case of several matches choose the correct one based on company's address.

Appendix 36 – IBAN structure

Please find the Bank Key to be used in red. For some countries bank key has not yet been determined, if in doubt please contact Payment Team.
★ Andorra (24) IBAN format: ADkk BBBB SSSS CCCC CCCC CCCC
::B = bank code, S = sort code, C = account No. ★ Austria (20) IBAN format: ATkk BBBB BCCC CCCC CCCC ::B = bank code, C = account No. ★ Belgium (16) IBAN format: BEkk BBBC CCCC CCCC ::B = bank code, C = account No (the last 12 digits are used as an account). ★ Bosnia and Herzegovina (20) IBAN format: BAkk BBBS SSCC CCCC CCKK::B = bank code, S = sort code, C = account No., K = check digits
★ Bulgaria (22) IBAN format BGkk BBBB SSSS DDCC CCCC CC::B = alphanumeric bank code, S = Branch (BAE) number, D = numeric account type, C = alphanumeric account No. digits ★ Croatia (21) IBAN format: HRkk BBBB BBBC CCCC CCCC C ::B = bank code, C = account No. ★ Cyprus (28) IBAN format: CYkk BBBS SSSS CCCC CCCC CCCC CCCC::B = bank code, S = sort code, C = account No. ★ Czech Republic (24) IBAN format: CZkk BBBB CCCC CCCC CCCC CCCC::B = bank code, C = account No. ★ Denmark (18) IBAN format: DKkk BBBB CCCC CCCC CC::B = bank code, C = account No. ★ Estonia (20) IBAN format: EEkk BBBB CCCC CCCC CCCK
::B = bank code, C = account No., K = check digit ★ Faroe Islands (18) IBAN format: FOkk BBBB CCCC CCCC CC::B = bank code., C = account No. ★ Finland (18) IBAN format: FIkk BBBB BBCC CCCC CK::B = bank code, branch number and account type, C = account No., K = check digit. ★ France (27) IBAN format: FRkk BBBB BGGG GGCC CCCC CCCC CKK::B = bank code, G = code guichet (branch), C = account No.
★ Germany (22) IBAN format: DEkk BBBB BBBB CCCC CCCC CC::B = sort code (BLZ), C = account No. ★ Gibraltar (23) IBAN format: GIkk BBBB CCCC CCCC CCCC CCC::B = first part of BIC, C = account No. ★ Greece (27) IBAN format: GRkk BBB BBBB CCCC CCCC CCCC CCCC :: B = bank code and branch number, C = account No. ★ Greenland (18) IBAN format: GLkk BBBB CCCC CCCC CC::B = bank code, C = account No. ★ Hungary (28) IBAN format: HUkk BBBB BBBB CCCC CCCC CCCC CCCC::B = bank code, C = account No. ★ Iceland (26) IBAN format: ISkk BBBB CCCC CCCC XXXX XXXX XX::B = bank code, C = account No., X = the account holder's unique ID number, issued by the Bureau of Statistics.
★ Republic of Ireland (22) IBAN format: IEkk AAAA BBBB BBCC CCCC CC::A = start of the SWIFT, B = bank code, C = account No. ★ Italy (27) IBAN format: ITkk ABBB BBCC CCCX XXXX XXXX XXX :: KK = is the CIN EU, A = CIN IT, B = is the ABI, C = is the CAB, X = account No. ★ Latvia (21) IBAN format: LVkk BBBB CCCC CCCC CCCC C::B = bank code, C = account No (which can include both letters and numbers). ★ Liechtenstein (21) IBAN format: LIkk BBBB BCCC CCCC CCCC C::B = bank code, C = account No.
★ Lithuania (20) IBAN format: LTkk BBBB BCCC CCCC CCCC::B = bank code, C = account No. ★ Luxembourg (20) IBAN format: LUkk BBBC CCCC CCCC CCCC::B = bank code, C = account No.
★ Kazakhstan (20) IBAN format: KZkk BBB CCCCC CCCC CCCC::B = bank code, C = account No. ★ Republic of Macedonia (19) IBAN format: MKkk BBBC CCCC CCCC CKK::B = bank code, C = account No., K = check digits ★ Malta (31) IBAN format: MTkk BBBB SSSS SCCC CCCC CCCC CCCC CCC ::B = fist part of BIC, S = sort code, C = account No.
★ Monaco (27) IBAN format: MCkk BBBB BGGG GGCC CCCC CCCC CKK::B = bank code, G = code guichet (branch), C = account No., K = check digits ★ Morocco (24) IBAN format: MAkk BBBA AACC CCCC CCCC CCKK ::B= bank code, A= Area code, C = Account number, K = check digits ★ Netherlands (18) IBAN format: NLkk BBBB CCCC CCCC CC::B = bank code, C = account No. ★ Norway (15) IBAN format: NOkk BBBB CC CCCCC::B = bank code, C = account No. ★ Poland (28) IBAN format: PLkk BBBB BBBk CCCC CCCC CCCC CCCC :: B = bank code (1-3 institution ID, 4-7 branch), C = account No., k = check digits. ★ Portugal (25) IBAN format: PTkk BBBB BBBB CCCC CCCC CCCK K::B = bank code (1-4 bank, 5-8 branch; some banks use '0000' for digits 5-8), C = account No., K = check digits. ★ Romania (24) IBAN format: ROkk BBBB CCCC CCCC CCCC CCCC::B = bank code, C = account No. ★ San Marino (27) IBAN format: SMkk ABBB BBCC CCCX XXXX XXXX XXX::kk = is the CIN EU, A = CIN IT, B = is the ABI, C = is the CAB, X = account No. ★ Serbia (22) IBAN format: RSkk BBBC CCCC CCCC CCCC CC::B = bank code, C = account No. ★ Slovakia (24) IBAN format: SKkk BBBB CCCC CCCC CCCC CCCC::B = bank code, C = account No. ★ Slovenia (19) IBAN format: SIkk BB BBB CCCCCCCC KK::B = bank code (2 digits) and branch (3 digits), C = account No, K = check digits
★ Spain (24) IBAN format: ESkk BBBB GGGG KKCC CCCC CCCC::B = bank code, G=Branch/office number, K=Check digits, C = account No. ★ Sweden (24) IBAN format: SEkk BBBB CCCC CCCC CCCC CCCC::B = bank code, C = account No. ★ Switzerland (21) IBAN format: CHkk BBBB BCCC CCCC CCCC C::B = bank code, C = account No.
★ Turkey (26) IBAN format: TRkk BBBB BRCC CCCC CCCC CCCC CC::B = bank code, R = 0, C = bank branch and account No.
★ Tunisia (24) IBAN format: TNkk BBBB BCCC CCCC CCCC CCCC::B = bank code, C = account No. ★ United Kingdom (22) IBAN format: GBkk BBBB SSSS SSCC CCCC CC::B = alphabetical bank code, S = sort code (often a specific branch), C = account No.
★ Ukraine (29) IBAN format: UAkk BBBB BBCC CCCC CCCC CCCC CCCC C::B = bank code, C = account No.

Appendix 7 – IBAN validation (Europe)

Before you enter the IBAN number of the bank(s) to which we must pay the invoices of the vendor. You must validate the IBAN number. Use the website http://www.ibancalculator.com/:

You will receive a report which looks like this:

Website {+}https://www.iban.com/calculate-iban.html+ is friendlier for UK banking details, it provides correct SWIFT code.

Appendix 48 - SWIFT code lookup

Swift codes can be looked up and validated in the following site: https://www2.swift.com/bsl/index.faces
Enter SWIFT in BIC field to see the corresponding bank information or bank name in Institution name field to see all SWIFT codes belonging to the specific bank.

Appendix 59 – Bank codes for Brasil, Chile and, Peru and Mexico

Most popular LA Banks with Bank Codes: