Objective and Scope

Objective of this ProcedureProcedure 
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.

...

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

...

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

...

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.

...

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

...

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 Ltd7776 – Cytec Engineered Materials Co . Ltd, Shanghai (merged with 7775)
• 7774 – Cytec Specialty Chemicals (Thailand) Ltd
• 7786 – Cytec Australia Holdings Pty Ltd
• 7788 – PT Cytec Indonesia
• 7988 – Cytec Korea

...

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

...

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

...

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

...

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:

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

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

...

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

E-mail templates can be found here for Z011 supplier bank detail clarification.

 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 Data Operations to ensure that outbound is made within the same dayGCC 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.
    

...

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

...

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

...

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.

...

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.

...

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

Process specifics for APAC.

New vendor creation or banking information change when e-mail matches e-mail in SAP:

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

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

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

Freshdesk ticket for contacting GCC

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

Image Removed

With following group:

 Image Removed

...

Freshdesk ticket for contacting GCC

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

Image Added

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:

...

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 there is no Bank Data in Vendor Master, Data Operation will inform Vendor WF requester that they were not able to confirm the Bank Account and due to that the same will be empty until the first invoice will be received and posted. When this is done, invoice is posted and blocked with "M"and then the supplier will have an Invoice Reference to identify why we have contacted them. If there already is Bank Data in Vendor Master, payment is performed to what we already have and no changes are made until further contact from the supplier.

1.3.3.3 Duplicate Check

...

Duplicate check must be performed, and if necessary the master data of the vendor has to be updated.

...

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.

...

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

...

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:

...

...

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

...

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

...

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.

...

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

...

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

...

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

...

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

...

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

...

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

...

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:

...

Company	CO	Street	ST	Suite	STE
Incorporated	INC	Road	RD	Building	BLDG
Corporation	CORP	Drive	DR	Apartment	APT
Manufacturing	MFG	Court	CT	South	S
Limited	LTD	Avenue	AVE	South East	SE
Limited Liability Corp	LLC	Boulevard	BLVD	East	E
Limited Liability Partnership	LLP	Lane	LN	North East	NE
Public Limited Company	PLC	Highway	HWY	North	N
1ST 2ND 3RD 4TH 5TH etc		Parkway	PKWY	North West	NW
		Place	PL	West	W
		Plaza	PLZ	South West	SW

...

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

...

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:

...

It is equivalent to Z010 Standard Vendors within RCS 

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

...

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.

...

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

...

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

...

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

...

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

...

• 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 please contact Karine Vermeylen form Treasury Operations via email bo.ihb@solvay.com for confirmation. 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 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:

...

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

...

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

...

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

...

NOTE!  If there is a need to change the PI party for a SFP supplier, Tanguy Moentack needs  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

...

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

...

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:

Image Added

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

...

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

...

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
  • 7776/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:

...

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

...

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

...

• 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

...

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.

...

• 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

...

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

...

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.

...

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 OTC LOGISTICS team using Freshdesk 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.

...

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.

...

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

• Freshdesk ticket for D&A 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 Riga Data OperationsOperations 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:
  “Industrial supplies materials creation and management”
  • "SAP WP1 Contract & PIR Maintenance".

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

• Maintained by Site Buyers’s (indirect)/Provisioning(direct) for Technology solutions:For the rest Freshdesk request should be submittedand/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.

...

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).Henrijs Lapins or PO creator for moving/changing open items

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.

...

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

...

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

...

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:

...

Note: This deletion flag will be distributed to WP1, PI1 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:

...

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

...

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

...

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.

...

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

...

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

...

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.

...

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.

...

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

...

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

...

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

Appendix 1 – Requirements for Tax Number 1- 5

...

Country	VAT ID	Tax 1	Comments	Tax 2	Comments	Tax 3	Comments	Tax 4	Comments
ARGENTINA	Blank	Yes	CUIT number or CUIL number		NIP number or CM number
AUSTRIA	Yes
BELGIUM	Yes				Enterprise number
BRAZIL	Blank	Yes	CNPJ number. Tax code 1 and tax code 3 are mandatory for companies. For “Natural Person” they should be left empty”, only tax code 2 has to be filled in	Yes	CPF number: for “Natural Person” only (tax code 1 and tax code 3 should be empty)	Yes	State tax Nr (inscrição estadual) (add ISENTO if missing). For “Natural Person” it should be left empty		populated for municipal entities - OPTIONAL
BULGARIA	Yes	Yes	United identification code	Yes	Legal persons: tax number;  Natural person: personal number
CHILE	Blank	Yes	RUT number
CHINA	Blank	Yes	TAX 1 : Old Tax ID number (15 numeric digits) TAX 5: New Tax ID number (18 alphanumeric digits; fitst 17 digits are number and the last digit is alphabet)
COLOMBIA	Blank		NIT number
CROATIA	Yes		Legal persons: company identification number. Natural perdsons: JMBG number
CYPRUS	Yes
CZECH REPUBLIC	Yes		DIC number		ICO number
DENMARK	Yes
EGYPT	Blank		Tax registration number (XXX-XXX-XXX) Project recommendation is to have a "flexible" check: the Egyptian tax authority does not have a very logical strategy. Hence it can be changed.		Tax ID card number: XXX-XXX-XXX  (new format = to Tax Code 1) or YYYY or YYYYY (old format)		Tax file number (format: X-XXXXX-XXX-XX-XX)		Tax office corresponds to the vendor code previously created as the Tax Office for the vendor being created. This Tax Office number (vendor code) if not already available in the system, must be created before the vendor being submitted.
ESTONIA	Yes
FINLAND	Yes
FRANCE	Yes	Yes	SIRET number. Two vendors cannot have the same SIRET (same tax code 1 of 14 characters).  Two vendors may have the same SIREN (first 9 positions of tax code 1) and the same VAT if they have the same name.		SIREN (first 9 positions of tax code 1)
GERMANY	Yes
GREECE	Yes		Personal ID		AFM number
HUNGARY	Yes		Tax number
INDIA	Blank			Yes	PAN code	Yes	GST code
IRELAND	Yes
ISRAEL	Blank			Yes	VAT number
ITALY	Yes	Yes	Tax number. The Tax Code 1, in Italy, is the fiscal code. If the company is a Juridical Entity, sometimes is equal to VAT ID., sometimes is a different number. For a “Natural Person” (that are no Juridical entities) it is an alphanumeric code of always 16 positions (egg, MSTGNN53A13L736E). For Juridical entities (companies) the code is fully numeric. Tax Code 1 can exist fully numeric and without VAT for [non-exhaustive list]: -municipality/prefecture/association/federation; - religious entities (e.g. churches); - embassy; - Non Profit organizations.	yes	Codice fiscal
LATVIA	Yes
LITHUANIA	Yes
LUXEMBOURG	Yes
MALTA	Yes
MEXICO	Blank	Yes	RFC number
NETHERLANDS	Yes		KVK number
PERU	Blank	Yes	RUC number
PHILIPPINES	Blank		Taxpayer identification number
POLAND	Yes		NIP number
PORTUGAL	Yes	Yes	NIF number
ROMANIA	Yes		Tax number
RUSSIAN FED.	Blank	Yes	INN (Identification number of tax payer) – 10 digits	Optional	OKPO number (General Classifier of Enterprises and Organizations) – 8 or 10 digits, for statistical purposes	Yes	KPP code		Can be used in Russia for internal use (FI reports) - OKF number (public bodies)
SINGAPORE	Blank	Yes	Goods and Service Tax Code (GST) 10 alphanumeric symbols (first 9 symbols are numerical, las one - letter)
SLOVAKIA	Yes		DIC number		ICO number		ICO number
SLOVENIA	Yes		Tax number
SOUTH KOREA	Blank		Natural persons identification number (13 digits)	Yes	VAT registration number (10 digits, legal entity)
SPAIN	Yes	Yes	NIF number (VAT registration number without the Country Code)
SWEDEN	Yes				Organization registration number
SWITZERLAND	Blank		New VAT codification: CHE + 9 digit + P (P is a check number)		Old VAT registration number
TAIWAN	Blank		GUI registration number		Tax registration number
THAILAND	Blank	Yes	Withholding tax code. Corresponds to withholding tax code (optional also), the format depends on the type of third party (13 digits): 1. Personal Income TAX (TAX no. 1XXXXXXXXX or 2XXXXXXXXX) 2. Legal entity (TAX no. 0XXXXXXXXX) 3. Independent entity (TAX no. 4XXXXXXXXX) 4. Blank on TAX number 2 is Vendor with no withholding TAX			Yes	Same as Tax 1
TURKEY	Blank		Name of business partner’s tax office		Tax number
UKRAINE	Blank		Taxpayer identification number		Legal persons: USREOU number Natural persons: SRNP number
UNITED KINGDOM	Yes				Nl number
USA	Blank	SSN mandatory	Social security number	EIN mandatory	Employer identification number
VENEZUELA	Blank		RFI number		NIT number

Appendix 2 - European VAT identification number structure

...

Member State	Structure	Format*
AT-Austria	ATU999999991	1 block of 9 characters
BE-Belgium	BE09999999992	1 block of 10 digits 3
BG-Bulgaria	BG999999999 or BG9999999999	1 block of 9 digits or1 block of 10 digits
CY-Cyprus	CY99999999L	1 block of 9 characters
CZ-Czech Republic	CZ99999999 or CZ999999999 or CZ9999999999	1 block of either 8, 9 or 10 digits
DE-Germany	DE999999999	1 block of 9 digits
DK-Denmark	DK99999999	1 block of 8 digits
EE-Estonia	EE999999999	1 block of 9 digits
EL-Greece	EL999999999	1 block of 9 digits
ES-Spain	ESX9999999X	1 block of 9 characters
FI-Finland	FI99999999	1 block of 8 digits
FR-France	FRXX999999999	1 block of 2 characters, 1 block of 9 digits
GB-United Kingdom	GB999999999 or GB9999999999995 or GBGD9996 or GBHA9997	1 block of 9 digits; or the above followed by a block of 3 digits; or 1 block of 5 characters
HU-Hungary	HU99999999	1 block of 8 digits
IE-Ireland	IE9S99999L	1 block of 8 characters
IT-Italy	IT99999999999	1 block of 11 digits
LT-Lithuania	LT999999999 or LT999999999999	1 block of 9 digits, or 1 block of 12 digits
LU-Luxembourg	LU99999999	1 block of 8 digits
LV-Latvia	LV99999999999	1 block of 11 digits
MT-Malta	MT99999999	1 block of 8 digits
NL-The Netherlands	NL999999999B99	1 block of 12 characters
PL-Poland	PL9999999999	1 block of 10 digits
PT-Portugal	PT999999999	1 block of 9 digits
RO-Romania	RO999999999	1 block of minimum 2 digits and maximum 10 digits
SE-Sweden	SE999999999999	1 block of 12 digits
SI-Slovenia	SI99999999	1 block of 8 digits
SK-Slovakia	SK9999999999	1 block of 10 digits
HR – Croatia	HR99999999999	1 block of 11 digits

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

...

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

Country	Bank Name	Bank Code	SWIFT
PE	Banco De Credito	002	BCPLPEPL
PE	Banco Internacional Del Peru (Interbank)	003	BINPPEPL
PE	Citibank Del Peru	007	CITIPEPL
PE	Scotiabank	009	BSUDPEPL
PE	Banco Continental	011	BCONPEPL
PE	Banco De La Nacion	018	BANCPEPL
PE	Banco De Comercio	023	BDCMPEPL
PE	Banco Financiero	035	FINAPEPL
PE	Banco Interamericano Bif	038	BIFSPEPL
PE	Banco Del Trabajo	043	BDTRPEPL
PE	Mi Banco	049	MIBAPEPL
PE	BNP Paribas	050
PE	HSBC	053	HBPEPEPL
CL	Bco De Chile	001	BCHICLRM
CL	Bco Internacional	009	BICHCLRM
CL	Dresdner Banque Nationale	011
CL	Bco Del Estado De Ch	012	BECHCLRM
CL	Scotiabank Sud Am.	014	BKSACLRM
CL	Bco De Credito E Inv	016	CREDCLRM
CL	Bco Do Brasil	017	BRASCLRM
CL	Bco Central De Chile	018	BCECCL**
CL	Itau Corpbanca (formerly Corpbanca)	027	CONBCLRM
CL	Banco Bice	028	BICECLRM
CL	Edwards	029
CL	HSBC Bank USA	031	BLICCLRM
CL	The Bank Of Tokyo-Mitsubishi	045	BOTKCLRM
CL	Coopeuch	672
CL	Banco Santiago	035
CL	Bco Santander-Chile	037	BSCHCLRM
CL	Itau Corpbanca (formerly Banco Itau Chile)	039	ITAUCLRM
CL	JP Morgan Chase Bank	041	CHASCLRM
CL	Bco De La Nacion Argentina	043	NACNCLRM
CL	Bco Abn Amro Bank	046
CL	Bco Security	049	BSCLCLRM
CL	Banco Falabella	051	FALACLRM
CL	Deutsche Bank(Chile)	052	DEUTCLRM
CL	Banco Ripley	053	RPLYCLRM
CL	Rabobank Chile	054	RABOCLRM
CL	Banco Monex	055	MNEXCLRM
CL	Banco Penta	056	BPENCLRM
CL	Banco Paris	057	BCNPCLRM
CL	Bbva Banco Bhif	504	BHIFCLRM
CL	Bco Del Desarrollo	507	BADECLRM
CL	Banco Conosur	734
BR	Banco do Brasil	001-9
BR	Santander	033-4
BR	Caixa Economica Federal	104-0
BR	Credibanco	109-0
BR	Multi-Banco	148-1
BR	Nossa Caixa Nosso Banco	151-1
BR	Pactual	208-9
BR	Banco Bandeirantes	230-5
BR	Banco Boa Vista	231-1
BR	Banco Bradesco	237-2
BR	Banco Cidade S/A	244-5
BR	Banco Cacique	263-1
BR	Banco Itau	341-7
BR	Santander Brasil	353-0
BR	Banco Real	356-5
BR	Banco Mercantil do Brasil	389-1
BR	Banco Mercantil de São Paulo	392-1
BR	Banco Safra	422-7
BR	Banco Rural	453-7
BR	Banco Votorantim S/A	655-6
BR	Citibank	745-5
BR	Banco Modal S/A	746-3
BR	Banco Cooperativo do Brasil	756-0
BR	Banco Banrisul	041-8
MX	Banco Nacional de México, S.A.	002
MX	BBVA Bancomer, S.A.	012
MX	Banco Santander, S.A.	014
MX	Banco Nacional del Ejército, Fuerza Aérea y Armada, S.N.C.	019
MX	HSBC México, S.A.	021
MX	GE Money Bank, S.A.	022
MX	Banco del Bajío, S.A.	030
MX	IXE Banco, S.A.	032
MX	Banco Inbursa, S.A.	036
MX	Banco Interacciones, S.A.	037
MX	Banca Mifel, S.A.	042
MX	Scotiabank Inverlat, S.A.	044
MX	Banco Regional de Monterrey, S.A.	058
MX	Banco Invex, S.A.	059
MX	Bansi, S.A.	060
MX	Banca Afirme, S.A. AFIRME R	062
MX	Banco Mercantil del Norte, S.A. BANORTE R	072
MX	ABN AMRO Bank México, S.A. ABNAMRO RC	102
MX	American Express Bank (México), S.A. AMERICAN EXPRESS R	103
MX	Bank of America México, S.A. BAMSA RC	106
MX	Bank of Tokyo-Mitsubishi UFJ (México), S.A. TOKYO RC	108
MX	Banco J.P. Morgan, S.A. JP MORGAN RC	110
MX	Banco Monex, S.A. BMONEX RC	112
MX	Banco Ve por Mas, S.A. VE POR MAS R	113
MX	ING Bank (México), S.A. ING RC	116
MX	Deutsche Bank México, S.A. DEUTSCHE RC	124
MX	Banco Credit Suisse (México), S.A. CREDIT SUISSE RC	126
MX	Banco Azteca, S.A. AZTECA R	127
MX	Banco Autofin México, S.A. AUTOFIN R	128
MX	Barclays Bank México, S.A. BARCLAYS RC	129
MX	Banco Compartamos, S.A. COMPARTAMOS R	130
MX	Banco Ahorro Famsa, S.A. FAMSA R	131
MX	Banco Multiva, S.A. BMULTIVA R	132
MX	Prudencial Bank, S.A. PRUDENTIAL RC	133
MX	Banco Wal Mart de México Adelante, S.A. WAL-MART R	134
MX	Banco Regional, S.A. REGIONAL R	136
MX	BanCoppel, S.A. BANCOPPEL R	137
MX	Banco Amigo, S.A. AMIGO R	138
MX	UBS Banco, S.A. UBS BANK R	139
MX	Banco Fácil, S.A. FÁCIL R	140
MX	Banco del Ahorro Nacional y Servicios Financieros, S.N.C.	166