Objective and Scope

Objective of this Procedure 
Miscellaneous

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 Operations Team based in Riga is responsible to handle all Vendor Master Data from NAM, LAM, APAC and EMEA regions, except for Intercompany general data, 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 Operations.

Reference Document

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

1.1 Roles & responsibilities of each actor

1.1.1 The initial requester

Requests for new vendor additions and changes can be received through SAP system Business Workplace (Workflow functionality), FreshDesk and as an e-mail to datamanage@solvay.com.

Change requests can also be requested from AP via Work Cycles.

1.1.2 Data Operations Team (Part 1)

Every request for a vendor setup or maintenance should be reflected in the Freshdesk. Requests received through Data Operations Mailbox or Workflow system should also be entered into Freshdesk.

For cases when initial requests (new vendor creation, purchasing data change / extension) are received through Freshdesk ticketing system DMO team will ask the requester to contact the Site Buyer and ask them to initiate the vendor workflow. DMO team will provide the correct Site Buyer according to the company code, vendor type - direct, indirect and plant is specific cases. List of Site Buyers’s and buyers to be contacted can be found in Appendix 10.

For exceptional cases please see following chapters:

• 1.7 Remediation process
• 1.8 Miscellaneous creditors process

1.1.3 Site Buyers

Site Buyers and Category (or Corporate) 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.

1.1.4 Data Operations 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 (Site Buyers) will receive an email confirming the completion of their request. DMO Team responsibility is to also close Freshdesk ticket in order for the initial requestor to receive information that requested changes have been processed in SAP. 

1.2 Overview

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

1.2.1 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).

1.2.2 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 Operations:

• WARP – PRS company code for Remediation Process (trigger internal 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
• 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
• 7774 – Cytec Specialty Chemicals (Thailand) Ltd
• 7786 – Cytec Australia Holdings Pty Ltd
• 7788 – PT Cytec Indonesia
• 7988 – Cytec Korea

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.

1.2.3 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, but if an intermediary bank has to be added upon new supplier creation, vendor should be extended to company code manually. 

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;
• General data should not be updated manually in CICC.

Detailed description can be found in Chapter 1.6.

1.3 Vendor creation/modification through Workflow

1.3.1 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 Operations 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.

1.3.2 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 WebForm – When the WebForm 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. 

1.3.3 Checks necessary before approving a request for a new VWF record

Before sending the requests to local Site Buyers’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?

1.3.3.1 Required Documents

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

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

EMEA region:

• No mandatory document is required, but for every new bank detail addition, we need Company letterhead / invoice / e-mail from supplier / SBI or equivalent, containing:

  • Name
  • Remittance address [best practice]
  • Bank details
  • VAT registration number + tax information (when applicable)

Both VAT number and IBAN number must be validated as described in – Validations For Customer And Vendor Master Data – 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 Data.

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.

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 Data.

1.3.3.2 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. Additional information on Webforms can be found on the presentation here or via freshdesk ticketing tool. 

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 bank details should be clarified by GCC team, except Governmental Institutions. For Governmental Institutions the requester should provide bank account, contact ID and source of bank account.
  • If one of above mentioned information is missing, PSL Approver will reject the VWF but if by any chance one approves it, Data Operations should request the VWF informing the user to provide the missing information;
  • In case of a bank data update request arrives from a Solvay User, the user must provide the Bank Account and source of the same.
  • If the request arrives directly from the Supplier, CAM (Country account manager) or delegated is contacted to confirm if the information and request are accurate, for this a Clear and Specific Template have been created. No Outbound will be performed at all.
    

"Dear Company Accounting Manager or Company Controller,

We have received a request to proceed with the Update of Bank Account for the Miscellaneous Creditor xxxxxxxx - NAME, for the Company Code yyyy for which you are assigned as an approver on the Miscellaneous Creditor tool.
Taking this into consideration we would like to obtain your confirmation to proceed with this update in order to do not delay the payment. Please be informed that no update will be made until your confirmation is obtained."

• • You can use this file to support you to determine who is the proper Plant Controller for the site mentioned on the invoice.
    
  • If Bank data is provided on the VWF Creation process the Outbound is triggered. In the case of the absence of attachment, no action is taken by Data Operations.

Exceptions:

• 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;
• 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;
• If IBAN can be validated here GOV.PL for Poland.
  

Fraudulent Bank Details added in the system: 

• Once fraudulent bank details have been removed from the system, please contact Payments team to ensure that no payments was made to the fraudulent bank account. 
  
• To ensure that the bank data have been copied to PI1 (CICC), please check the system and if necessary manually remove fraudulent bank details.

Webform Creation 

Data Operations 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 should 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 AP Specialists NAM, PTP AP LAM)
• APAC vendors should be contacted by GCC Apac (PtP HD APAC)
• EMEA vendors should be contact by GCC Lisbon (PtP Provisioning EMEA)
• For countries Poland, Finland, United Kingdom, Latvia, Kazakhstan contacted by GCC RIGA (PTP HD RIGA)

Process specifics for LAM.

• For interns bank details can be accepted from HtR team.

Freshdesk ticket for contacting GCC

In order to contact GCC team, please submit request for following request type/process.

With following group:

• NAM/LAM vendors should be contacted by GCC Curitiba (PTP AP Specialists NAM, PTP AP LAM)
• APAC vendors should be contacted by GCC Apac (PtP HD APAC)
• EMEA vendors should be contact by GCC Lisbon (PtP Provisioning EMEA)
• For countries Poland, Finland, United Kingdom, Latvia, Kazakhstan contacted by GCC RIGA (PTP HD RIGA)

Please see below the points of what should be added in the ticket:

1. Vendor ID and Country (in Freshdesk ticket subject)
2.  SAP Vendor Master Data contacts

3. Vendor contacts from official page in the Internet

4. Which data needs to be confirmed (VAT, Contacts, Bank account, Bank ABA routing number, check remit address for US payments by check,...)

5. If SBI/RIB/Evidence is required (Vendor Creation Required Documents)

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 we have received that outbound has not been successful and there are no banking details in the system, we can proceed with bank detail addition. After, informing internal requester and category buyer that the bank details were added but were not confirmed. 
• If we have received that outbound has not been successful and there are banking details in the system, we do not update the system, we leave bank details as is.  After, informing internal requester and category buyer that the bank details were not confirmed

1.3.3.3 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.

1.3.4 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.

1.3.4.1 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:

• 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.

1.3.4.2 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.
• 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
  • MPI – Main Remittance Address

• 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.

Possible options for Search Term 2:

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

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  section should be used.
• Suppl.: Additional address information, such as floor, apartment etc.
  • For the following countries postal code is not mandatory: BO, CD, CM, CW, HK, JM, MN, LA, PE, SR, ZM.
• District: District where the vendor is located in
  • Mandatory for China
  • Mandatory for Brazil
  • Populated automatically based on postal code and city for US.
• Time zone: Automatically determined by the system.

• 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.

• 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)

• City: Mandatory for all vendors;
• Region: state/province/county (mandatory for all vendors);

• 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;

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:

1.3.4.3 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 requester 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

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

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 Data 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

1.3.4.4 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 Freshdesk ticket number or Workflow number to justify vendor creation/changes.

1.3.4.5 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 6).

1.3.4.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.

1.3.4.7 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.

1.3.4.8 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 Purchasing 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.

1.3.5  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.

1.3.5.1 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.

1.3.5.2 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.

1.3.5.3 Bank

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

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

1.3.6 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;

1.3.7 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 Operations 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:
• 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 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.

• 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.

1.3.8 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.

1.4 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 11.

1.4.1 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.

US STARS vendors should always be created under segment code P204 with payment method checks. Vendor WorkFlow should be managed by Samantha Ettelman as she is the Site buyer for Princeton and the requester is Jennifer Turner. 

1.4.2 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:

• 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.

1.4.3 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.

1.4.3.1 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

1.4.3.2 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
  • MPI – Main Remittance Address

Possible options for Search Term 2:

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

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  section 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 :
  • • • 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.

• 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)

 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.
• 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.

• English for US and TH;
• Portuguese for BR;
• Spanish for other LAM countries and MX.

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 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.

1.4.3.3 Create Vendor: Control

• Customer: In cases mentioned below this field is populated with SAP number of customer counterpart of supplier:
• Subcontracting:
  
  • Opened for RM P.org 3006, 3014, 3022, 3030.
  • Segment code should be P103.
    
• Vendor Returns (request comes from planners and direct buyers).
  

• 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)

1.4.3.4 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 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 (CICC).
  • If SWIFT code in existing bank key needs to be updated you have identified the vendors which are impacted by that change and you need to ensure the same is reflected in the Vendor Master Data.

• 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 (CICC).
• 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

1.4.3.4.1 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 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 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 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 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 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)

1.4.3.4.2 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 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 5.
  • Peru – bank code (3 digits). Can be found in Appendix 5.
• SWIFT/BIC: SWIFT code of the bank branch. Validation of SWIFT code is described in Appendix 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.

1.4.3.4.3 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
• 7723 – Cytec de Mexico SA de CV
• 7180 – Cytec Engineered Materials Inc
  
• 7794 – Cytec Industries BV
• 7752 – Cytec Canada 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
• CN – 4009699 JPMORGAN CHASE BANK (CHINA)
• BG – 502562995 NG WHOLESALE BANKING  AMSTERDAM

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 23 90EOM5th;
  • 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 90EOM5th;
  • Transaction SQ00 group 
  • Run query
    
  • Add company code in order to determine in which Purch Org or Plants Payment terms must be changed;
    

• • Check the Purchasing Organization where Vendor is currently created;
    
  • Proceed with the extension to the Plants impacted accordingly (WP1);
    

• • After all steps above and no issue was identified, proceed with the update of active contracts for the company code mentioned;

  • When all steps were done, inform requester asking if (for cases when not provided yet):

  • Open PO must be updated (if answer is Yes transfer request to Provisioning stating the Purch Org. and Plants impacted);

  • Open items must be updated (If answer is Yes transfer request to AP);

NOTE!  If there is a need to change the PI party for a SFP supplier, Nathalie Manirakiza needs to be inform and the following steps done:

• New code should be flag as SFP; 

• Payment terms to be updated.

1.4.3.5 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 Data 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 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.

1.4.4  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.

1.4.4.1 Create Vendor: Accounting information

• Recon. Account: 
  • defaulted to “40100100”  for WP1_400;
  • defaulted to “2300000000”  for PI1_020 (CICC).
• Sort Key:
  • defaulted to “009” for APAC entities and PI1_020 (CICC);
  • 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 for WP1_400;
  • “A2” if the country of the vendor is different from the one for the Company Code for WP1_400;
  • “A7” if the vendor is Financial supplier (Z011) for WP1_400;
  • BEVCICC - CICC vendor for PI1_020 (CICC);
  • BEVNAFTA - NAFTA vendor PI1_020 (CICC).
• Thailand Branch details: company’s branch number. For HQ use “00000”.

1.4.4.2 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..”). Not Mandatory for PI1_020 (CICC). 
• Chk Double inv.: Must be always flagged
• Payment methods:

Note! All request for setting up a Vendor with Payment Method Direct Debit, no matter if payment is made by Treasury (PI1 companies 0231 or 4044) or made locally (PF1_20 and WP1), unless they are coming from Larissa Duval, the user should be informed to follow the link below and to select the option mentioned, submitting a form to Treasury Team who will analyze the request.

My Solia Services:

• 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 (CICC) 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

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 (CICC).
2. Add the justification for the manual exception – “Manual Payments”

Payment method supplement

Payment supplement should always be populated for company code 7779 Cytec Nibras Llc:

This is a mandatory field for all payments in AED.

1. Payment supplement can be determined based on the invoice. If invoice is not available then we can check the segment code and based on that populate the supplement.

• E0 Air Transport (ATS)

• E1 Computer Services (ITS)

• E2 Construction (SCO)

• E3 Goods Bought (imports) (GDI)

• E4 Information Servic(media)(IFS)

• E5 Insurance Services (INS)

• E6 Profess&Mgt Consult Serv.(PMS)

• E7 Rent payments (RNT)

• E8 Repairs and maintenance (GMS)

• E9 Sea transport (STS)

• EA Engineering & oth.service(TTS)

• EB Telecommunication Service(TCS)

• EC Transport (other modes) (OTS)

• ED Travel (excl air) (STR)

• EE Utility Bill payments (UTL)

2. If it is impossible to determine the supplement, we go to requester and ask him/her to advise on the supplement. If requester can't help, then we ask CAM.

3. New supplement codes can be requested to IS.

1.4.4.3 Create Vendor: Correspondence Accounting

• Clerk Abbrev: must be filled in with country initials for all vendors opened for following companies:
  • 7725 – CL
  • 7722 – PE
  • 7734 -  CN
  • 7788 – ID
  • 7988 – KR
  • 7774 – TH 
  • 7180 – US
  • 7188 – US 
• 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 (CICC) (transaction FK02):
  • If specific e-mail has not been noted for remittance advices, please use the general e-mail.
  • In case of change – update in PI1_020 (CICC), transaction FK02. For more details please see Chapter 1.6.1.
  • Companies 7722, 7725, 7788, 7988, 7188 and 7774 will not use factoring, therefore remittance contact information should be populated in WP1 only.

1.4.4.4 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

Information should be provided in vendor workflow. In case of questions correct finance representatives can be found in 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.

1.4.5 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.

For Intercompany vendor addition to non-PO vendor list, no approval is required. 

Press “New Entries” and populate Company code and Vendor number. Site field is optional and usually is not populated.

1.4.6 Purchasing Organization view creation

1.4.6.1 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 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
• Returns vendor:
  • Should be flagged only if returns vendor has been created. Check marked only after returns vendor has been added in control data.
    

1.4.6.2 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.

In case CASS INFORMATION SYSTEMS INC are added as an PI party it should always be marked as default.

Cass Information Systems Inc is a company, which handles payments to freight forwarders and carriers used by Cytec/Solvay. Vendor account created for a specific freight forwarder or carrier is being used creating PO’s (both customer and vendor). Payments for these vendors are being made to Cass Information Systems Inc. If new vendor creation is requested from Logistics Team, most likely CASS needs to be added as a PI party. If asked to update bank data/address for forwarder/carrier - changes should be done to PI party of the forwarder/carrier. CASS account should be updated only if specified.

1.5 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.

• Vendors marked with GTBU are only blocked after informing the Key user.

•  When requested the block/deletion of an ARIBA vendor the ARIBA team needs to be informed before blocking (Ariba.Enrolment@solvay.com).

For inactivation where replacement account is available please follow the steps below:

1. Change vendor name to  PRS number #123456# VENDOR NAME (apply only when payments aren't made by CHEQUE);
2. Change search term to “****”;
3. Add note in Comments “FD #123456 123456” (apply when payments are made by CHEQUE);
4. Perform open item checks described in the following chapters:
   1. If open items can be and are moved apply “Deletion Flag” and proceed with step 7;
   2. If open items cannot be moved proceed with step 5;
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”.

6. Wait for open items to be processed;

7. Block vendor for posting and purchasing;

8. Change vendor name to #123456# VENDOR NAME (in case it was not done beforehand);

9. Remove bank account(s).

Aero Specifics 

1. If subcontractors VN location is not the same as GS location the GS account has been set up as separate VN.
   

1.5.1 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 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 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 Operations, 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.

1.5.1.1 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 not flagged – a record exists only in PRS and RCS.

1.5.1.2 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 a VN has a separate PI party, then VN should be opened to purch.org a+ company code, but PI party should be opened only to the company code. 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 the appropriate buyer by segment code form the list.

Please note that in rare cases duplicate accounts for freight vendors may be required due to system restrictions.

1.5.1.3 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”.

1.5.1.4 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 [WP1] not maintained by Data Operations Riga [Industrial Supplies]:

• Freshdesk ticket for other Data Operations team should be created.
  • Data Operations Curitiba;
  • Data Operations Lisbon;
  • Data Operations Bangkok; 

PIR’s created for purchasing organisation [WP1] 3012; 3020; 3028; 3004 [Industrial Supplies]:

• Created / Inactivated by Data Operations Riga team.
  • Create FD ticket to Data Operations Riga and mention that Site Buyers or Store Room Owner in charge 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: "SAP WP1 Contract & PIR Maintenance".

PIR’s created for other Purchasing Organizations [WP1]:

• Maintained by Site Buyers’s and/or Data Operations Riga [Raw Materials] for Technology solutions & composite materials.

PIR's created in PF1_020 are maintained locally, buyers should be contacted based on this list.

1.5.1.5 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.

1.5.1.6 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 (Indirect).

Reach out to appropriate buyer (Direct)

For PF1_020, please reach out to the site buyer.

In case replacement account should be used reach out to the appropriate person / 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 appropriate person / 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.

1.5.1.7 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” columns, 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 (CICC) system using the same transaction. For details please check Chapter 1.6.

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.

Note! Once AP has “moved” open invoices from one account to another, a clearing has to be done by the Payments team in CICC (PI1). We need to wait once all invoices will be cleared and only then close/block the vendor account.

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 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.

1.5.2 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 (CICC) 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.

1.5.3  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 (CICC) 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.

1.5.4 Additional steps

When inactivating the supplier following steps should be taken:

• Add replacement vendor number at the beginning of Name, e.g., “#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 FD reference and replacement vendor number (if any) “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.

1.6 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
  • 7180 – Cytec Engineered Materials Inc

• EMEA
• 7794 – Cytec Industries BV
• 7764 – Solvay Business Services Latvia Sia
• 7726 – Cytec Belgium Bvba
• 7210 – Umeco Ltd
• 7714 – Cytec UK Holdings Ltd
• APAC
• 7786 – Cytec Australia Holdings Pty Ltd

Data Operations is using PI1 (CICC) for the following activities:

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

Login:

• CICC - Production - PI1 (CICC)
• Client 020

Transactions:

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

1.6.1 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 (CICC) 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.

1.6.2 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.

1.6.3 Creating link between PF1 and PI1

There might be cases when vendor information has not successfully copied to PI1 (CICC). 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.

1.7 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:

• A 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.

1. 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.

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".

1. Provisioning 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.

Note! Remediation WF should follow the rules below:

• Company code: WARP
• Class: D
• Text: Should contain text “Remediation” and company code
• Purchasing organization: must be added
• Payment terms: Y030 (If not provided)

1. Data Operations 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.
2. Data Operations 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..

Related documents:

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

Note! If Vendors class needs to be changed from D to C, it should be done manually in the system as it is not possible to change by VWF. Before making any changes in the system, approval should be asked from the appropriate buyer. 

1.8 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.

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

1. Requester creates VWF using Miscellaneous creditor tool. If vendor creation request has been received outside VWF please direct them to PSL portal.
2. Data Operations 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 Operations 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.9 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 cuSite Buyersit 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 – 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 4 - 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 5 – Bank codes for Brasil, Chile, Peru and Mexico

Most popular LA Banks with Bank Codes:

 Appendix 6 – Transportation zone

Transportation zone should be populated for vendors located in USA, Canada and Brazil.

Please use “Transportation zones” file to identify the correct transportation zone for a vendor.

There are three tabs in the file:

Once the correct Transportation Zone found, please populate it at the vendor’s Extra Master Data” level.

• For US, the transportation zone can be determined based on the Region and the first three digits of Postal code.

Find the required region and postal code range:

The correct transportation zone in this case is “0000CA0100”

If there’s no required Region/Postal code combination, Transportation field can be left blank.

• For Canada, the transportation zone can be determined based on the City and Region combination.

• For Brazil, the transportation zone can be determined based on Postal code range.

 Appendix 7 – SAP Purchasing organizations