The content can be provided to ORACLE iprocurement in basically 3 ways:

Transcription

1 BT Procurement and Supply Chain 3 Catalogues and Content Options 3.1 Introduction The default method of ordering on ORACLE iprocurement is non-catalogue ordering or Special Requirements. This is a basic purchase requisition facility where the customer has to be regarded as informed. They need to know what they are buying; the procurement category under which they are purchasing, the BT agreement, the supplier and what address the order needs to go to within the supplier s organisation. This creates productivity problems for the user, provides no opportunity for Procurement to communicate what is available and does not validate information prior to an order being created. It is therefore BT Procurement s strategy that all our agreements, which will be accessed via ORACLE iprocurement, will be provided on iprocurement as structured content. In this way, by the use of a search facility, or by navigation, the user can find and select the commodity they need using key words. All products and services fitting their requirement can be displayed and the particular product or service automatically linked to the appropriate category, contract and supplier. This will ensure a full validation and control are provided. The content can be provided to ORACLE iprocurement in basically 3 ways: Local Catalogue A catalogue loaded directly onto the ORACLE iprocurement system by loading in an Excel spreadsheet or XML catalogue provided to a specification. Ideal for where the content is reasonably stable and updates are not more frequent than monthly. Punch-out to an Exchange (Procserv - Zanzibar, ORACLE Exchange, UK Procure) The system is configured only with browsing catalogues to aid navigation. The users will then punch-out to content held on an ORACLE compatible exchange. After selection of the items in their shopping cart the user will be returned to iprocurement where a requisition will be created containing the selected information. Ideal for content managed directly by a supplier (with Buyer approval) If you are already subscribing to Exchanges for other clients let us know which ones you are using. Punch-out to a Suppliers Web Site or Configuration tool. The supplier provides a typical shopping cart or a configuration application compatible with the ORACLE punch-out specification. The user will leave iprocurement and use the supplier s application to select or configure an order. However rather than proceed with an order on the suppliers site the user returns with their collection to iprocurement where a Purchase Requisition is automatically created for the order. This option is ideal for dynamic content where there are frequent changes to content, configuration is needed or a complex relationship of items exists. The management of the content will be devolved under appropriate arrangements. All three options allow for Purchase Requisitions to be created against validated data but still provide for appropriate approval and control in BT as well as registering all commitments on our financials ready for invoicing. System Strategy Catalogues 1

2 3.2 Buyer Created Catalogues Where a contract has a small defined list of products or services or options then the BT buyer has access to a Catalogue Content Team which will facilitate the creation, and updates to Catalogues. Because these catalogues use contract information and confirmed ORACLE standing data the confidence of level of loading into ORACLE will be 100% and loading to ORACLE will be automated via a central BT team. Where the buyer requests catalogue detail from a supplier, which will then be subsequently rekeyed into this application the supplier does not need to provide the catalogue in any fixed format. Key fields will be Product Code, Short Description, Long Description, EOM and price. 3.3 Supplier Catalogues Local Catalogues The Supplier can provide a Local Catalogue to BT in either Excel or in XML format for load to ORACLE. Standard routines exist for this to be imported and each BT Organisation Unit may have their own Catalogue(s). There are however some links that need to be created to ensure the information is linked correctly to the Supplier and the Contract Purchase Agreement we have with the Supplier. Therefore for Supplier will need to be provided by the template to complete the catalogues. A process to test, verify and load catalogues has been agreed within BT. In all cases catalogues or their updates will be submitted via or with the approval of the supplier s BT commercial contact Punch-out Management On ORACLE Exchanges Exchange Marketplaces are setup in ORACLE iprocurement as Supplier Hubs. Setting up a Supplier hub allows BT to punch-out to that Hub and download punch-out enabled suppliers from that hub. If you are a supplier that has already enabled a punch out to your Products and Services via an exchange to your web store, we can use this setup to download that setup information into iprocurement. Once we have completed this setup we will be able to punch out from our iprocurement to the supplier s web store and add items to the shopping cart from the site and then return the shopping cart to iprocurement to go through the approval process Punch-out directly to a Suppliers Site We can also punch-out to a Suppliers Application, which supports the ORACLE punch-out specification. Currently this is contained in the ORACLE iprocurement Punch-out Guide, which may be appended to this guide. ORACLE needs to be configured and the supplier provided some key data to use on the transaction but once this is setup then any changes can be reflected on the supplier s site with no further development required by BT. System Strategy Catalogues 2

3 3.3.4 Content Providers Where a supplier does not have expertise in catalogues they may wish to engage the services of specialist Catalogue Content Providers who provide a service of catalogue creation and conversion. The value they provide is in collecting catalogues from chosen suppliers in a variety of formats and "cleansing" them to ensure standardisation and enhancing data to ensure quality and search ability. They also provide content management software, which allows suppliers selfservice access to a hosted instance. As a general guideline: Catalogues of strategic suppliers (high volume, where no punch-out link is being developed) should be converted into XML format by Content Providers. Catalogues where the price of the items fluctuate frequently and/or where goods are configurable (e.g. PC equipment) should not be converted but should be considered for integration via punch-out Catalogues containing items which have very precise descriptions and which could easily be mistaken for other items should be converted - especially telecommunications items. Catalogues with low volumes should be maintained internally (in the Purchasing application) or by the Supplier via a spreadsheet. Oracle have a working relationship with a number of the UK s leading Content Management and Catalogue Hosting companies. If a supplier needs assistance in Catalogue preparation for BT they may wish to avail themselves of the services. Content Providers are unlikely to be engaged directly by BT unless some assistance is required with the Catalogue Administrator role described above Supplier Hosted Catalogues Supplier Hosted Catalogues are particularly appropriate where a supplier has dynamic pricing such as IT or telecommunications equipment. In this case prices may fluctuate by the hour or day, the maintenance of such a model would be totally unworkable if hosted internally. In addition the maintenance of these catalogues rests with the supplier rather than the buyer organisation resulting in significant overhead savings. While creating a requisition, users can also navigate to and select items from external 3 rd party catalogues (which may be hosted by a supplier or content provider). In this case, users can consciously select a link on the Procurement Home Page for the desired Supplier (e.g. Computacenter), "punch-out" to the supplier s own web-site. Alternatively, Keywords can be defined for each punch-out supplier, which means the link to punch-out suppliers can be included in the standard catalogue search. For example, keywords such as switch, router, and racking could be associated with supplier Cisco. When the requisitioner enters a search string containing any of these keywords, the punch-out link for Cisco will be displayed along with any catalogue items matching this search string. After punching out to the Supplier s catalogue, the requisitioner searches directly on their site, selects items and then returns a shopping cart back to iprocurement where they can request additional items from any other catalogue source, make changes or complete their order. Oracle iprocurement supports Punch out from Oracle iprocurement directly to a supplier or Punch out from Oracle iprocurement to a supplier, using punch out definitions on any Oracle Exchange. An exchange could either be Oracle s own exchange, exhange.oracle.com, or one hosted by another 3rd party that the supplier already subscibes to. Once the punch-out definitions are defined they can be applied to any exchange. Therefore Suppliers may consider the wider use of these techniques with their other larger clients so that any system development can be maximised. System Strategy Catalogues 3

4 3.3.6 Summary of content management approaches Model Advantages Disadvantages Internally Hosted Best suited for commodity-type items (such as office supplies), products with pre-negotiated or stable prices, MRO items, products built to a predetermined specification (such as mass produced mechanical parts). Presentation of items in the catalogue is controlled by the Buying organisation. All Internally hosted catalogues are accessed through one search engine, common view across Suppliers. Realms functionality can be used to restrict access based on certain attributes within the catalogue Catalogue items can be added to a favourites list Supplier avoids managing a complex web site and web content. Simple to implement using a variety of techniques e.g. spreadsheet load Not suited for products requiring a high degree of configuration, or products with fluctuating prices. Catalogue administration overhead. Supplier Hosted System Strategy Catalogues Best suited for products requiring a high degree of configuration (such as computer hardware), specialized services e.g. Temporary Staff, products with fluctuating prices. Supplier closely manages the content presented to buyers. Reduces Buying organisation catalogue administration overhead. Supplier can provide online Security and architectural issues must be addressed Supplier has to manage a complex web site and web content. Expensive technology investment for supplier Different search engines and presentation of items for different Suppliers. Dependency on category 4

5 availability checks. structure unity e.g. UNSPSC (may require additional mapping in ecommerce Gateway) Up to date prices Automatic application of discounts and price breaks Sophisticated order configuration software with user-specific pricing models (e.g. Cisco) Marketplace Hosted Full access to any additional product information Best suited for commodity-type items (such as office supplies), MRO items, products built to a predetermined specification. The Supplier, reducing catalogue administration for the buyer, maintains catalogue content. All marketplace hosted catalogues are accessed through one search engine, common view across Suppliers. Supplier avoids managing a complex web site and web content. Supplier can provide online availability checks Not suited for products requiring high degrees of configuration. System Strategy Catalogues 5

6 3.3.7 Catalogue Template Layout Language Section* EN-US Catalogue Section Supplier* Title Contract Reference Buyer Contract Number Item Price Section Category* Action* Supplier Item* Description* Pricelist SYNC Cont. Buyer Supplier Site Unit* Unit Price* Currency* UNSPSC Code Cont. Manufacturer Manufacturer Item Alias Lead Time Image Cont Image URL Attachment URL Long Description Comments System Strategy Catalogues 6

7 3.3.8 Roles and Responsibilities The BT Buyer will complete negotiations with the supplier and either receives the items for the catalogue from the supplier or request the supplier provides a catalogue to the template. Where a large catalogue is involved or where there will be an exchange or punch-out requirements the Buyer will seek assistance from the Procurement systems team. The Buyer shall ensure their agreements are set up and that the Vendor, Site and CPA references are available Catalogue File Content Naming Convention of the Template File All templates must be saved according to the following file naming convention NNNNNNNNNN.CC.txt where NNNNNNNNNN = Contract Number as per QDS CC = Country Code (UK).txt = file extension type = text Fields The BT Buyer will also be required to validate and fill in the additional fields required on the template. Template Field Description Value Supplier Name of the Supplier as defined in Oracle (Supplier Header) Buyer This is the operating Unit Name as defined in Oracle. Not the Buyer Name. See Lists of Defined Operating Units for correct Name Contract Number Contact as per the CPA in ORACLE PURCHASING Category Category as per iprocurement E.g. Stationery and Office Supplies Action SYNC = Synchronise DELETE = Delete Use SYNC when adding new items or updating an existing catalogue Use Delete to remove an item from the catalogue Supplier Item Suppliers Item Number Description Description given by supplier Price List One Price List is allowed for each combination of supplier Operating Unit and Currency. Buyer Supplier Site System Strategy Catalogue Options Example CISCO_BT_UK_515_GBP BT Buyer to name the price List This is the operating Unit Name as defined in Oracle. Not the Buyer Name. See Lists of Defined Operating Units for correct Name (Same as previous one) Supplier site associated with the CPA and vendor as per Oracle 7

8 Unit Unit Price Currency UNSPC Code Manufacturer Manufacturer Item Alias Lead Time Image Image URL Attachment URL Long Description Comments System Strategy Catalogue Options Purchasing Supplier supplies the UOM. This field needs to be validated against the UOM used in Oracle. If required the BT Buyer will have to map this field to an ORACLE UOM. If UOM does not exist in Oracle a request needs to be submitted to Catalogue Administrator to set up the new UOM as per UNECE standard. Price as agreed per the contract. BT Buyer to validate prices. Currency of the contract The United Nations Standard Product and Service Code Name of the manufacturer of each item or service. Typically, you would complete this field only if you are not the manufacturer of the listed item or service. Manufacturer-assigned part number of each item or service. Typically, you would complete this field only if you are not the manufacturer of the listed item or service. Alternate description or identifier for each item or service that people can enter when performing a search. For example, an alias for soda might be pop. To enter more than one alias, simply separate each alias with a comma - for example: soda, pop, cola. Amount of time, expressed in days, between the order date and the shipment date. For the value, specify the name of the image for the item. The image must reside on the local server, in an image directory XX.YYYYimaged.jpeg XX = Country Code (UK) YYYY = Contract Number as per QDS. When the images are saved on the SERVER they have to have the same name as specifies in the template. URL at which an image of each item can be viewed. Include the full URL - for example: URL at which an attachment for each item or service can be viewed. Include the full URL Detailed description of your item or service. Information about line item (Used to indicate why a line is changed) Not recommended. Use URL instead. 8

9 BT Contract Number Contract number as per the QDS system Catalogue Load Gifs Required If Gifs are required it will be the buyers responsibility to request the gifs from the supplier and forward these to the catalogue administrator. If the files are large the supplier can save the gifs onto a CD and this can be passed on to the Procurement system team. See table for naming convention of Gifs Notify Users of Successful Load The buyer will only notify all users when a catalogue has been successfully loaded into the system. Successful File Loaded into the system A Copy of the successful file loaded into the system should be sent to the BT Buyer and stored on a server. The reason for keeping a copy of this file is that if the item needs updating the successfully loaded file can be modified and then reloaded. If a copy of this file is not kept the errors will be repeated and the file will have to be reworked to resolve errors if there are Save a Copy of the Successfully Loaded File When the buyer receives conformation that a catalogue has been loaded successfully he must ensure that he has received a copy of the successfully loaded file and save it to Livelink. The reason for this is that when changes need to be made to the catalogue (for example delete items, update prices or changes description etc) the errors will be reduced because the file has been successfully loaded previously. Resolve Errors with Supplier The data that the supplier supplies can also have errors for example duplicate supplier item numbers it will be the buyers responsibility to resolve these errors with the supplier and forward the catalogue administrator with a new file. Supplier Item Data Errors Example of this error can be a duplicate supplier number these errors will have to forwarded back to the BT Buyer who in turn will have to request the correct information from the supplier General Errors The most of these errors will occur if no validation is performed before the catalogue is loaded. Examples of these errors include Incorrect UOM Supplier Does Not Exist Invalid Buyer Invalid Contract Number Contract Status etc Content Management Team (CMT) Role Loading Images CMT will receive a file with images from the catalogue administrator or the BT buyer for loading. These files will be loaded onto the Unix directory under a specific path in the temp directory. Example could be in the temp directory to create the supplier name as a separate directory and load all images related to that supplier in that directory. Gif files should be saved using the naming convention as per the temple descriptions Additional Error Messages Required Occasionally CMT will need to provide the Catalogue Administrator with more information about the error from the Unix Log Files. System Strategy Catalogue Options 9

10 BulkLoader CMT will develop monitoring scripts and will ensure that the bulk loader is running continuously. If the bulk loader is not running the catalogue administrator will log it as an issue using GK front office in the production environment. Proposed Future Development For CMT to manage the system they require that the catalogue be loaded automatically using Control M scripts. In the feature this will mean that CMT will be responsible for loading the catalogues as indicated in the process flow diagram. CMT will receive file from the BT and the file will be loaded directly into the system. Once the file has loaded CMT will notify the catalogue administrator and if there are errors CMT will send the catalogue administrator a description or log of the error of the error. This will not be ready for go live and CMT will have to raise a change request for the development of this work. List Of Operating Unit Names The BT Buyer will provide the relevant Operational Codes to the supplier. Any item shared across Operating units needs to be replicated in the catalogue. 3.4 Technical considerations for Punch-out iprocurement to an Exchange User logs onto iprocurement and clicks an Oracle Exchange punch-out link. iprocurement establishes an HTTPS connection with the Exchange by comparing the server level digital certificate from the Exchange server with a list of trusted certificates. Once verified, iprocurement sends via this connection an XML document, which contains the username & password with which to connect to the Exchange and the URL of the Server on which to validate the user origin. Once the Exchange has validated the username and password the Exchange establishes a session through which the user will connect to the Exchange and passes this information back to iprocurement. iprocurement opens a new browser window on the users terminal iprocurement opens a new browser window on the users terminal and the users HTTP connection is redirected to the Exchange. Once the user has finished shopping on the Exchange, they press the checkout button and the items selected from the catalogue are transferred back to iprocurement to be checked out in the usual way. System Strategy Catalogue Options 10

11 3.4.2 iprocurement to Supplier Site via an Exchange using through punch-out Buyer Exchange Supplier Å Ö à Ü ÅÇ Exchange É Ñ Supplier Portal User 6 iprocurement Server â á Supplier Hosted Catalog The user connects to the iprocurement server by opening a browser window When the user clicks the link to a supplier hosted catalogue the iprocurement server connects to the Exchange server and sends an HTTPS XML document requesting the supplier authentication information and supplier portal URL. The Exchange then sends an XML Punch-out request document to the supplier portal via HTTPS this request includes information about the user, and the password with which to connect to the supplier site. Once the supplier has validated the user and password information the supplier portal responds with an HTTPS XML document detailing the URL and session to which to connect to their site. The Exchange will then communicate the URL and session information to the iprocurement server via an HTTPS XML document. The iprocurement server will then redirect the users browser The iprocurement server will then redirect the users browser to the supplier s catalogue site. Once the user has finished shopping on the Exchange, they press the checkout button and the items selected from the catalogue are transferred back to iprocurement. Having translated any mapped codes, and if necessary converted the shopping cart to native ORACLE XML the shopping cart will be handed back to iprocurement to be added to a requisition in the usual manner. System Strategy Catalogue Options 11

12 3.4.3 XML Protocols Oracle s punch-out messages are based on either the Open Applications Group (OAG) XML or the commerce extensible Markup Language (cxml) standards. Other standards will be considered on a case by case basis Supplier Software Requirements To become punch out enabled a Supplier must have a web store, which can support catalogue content. It does not matter whether the Supplier or a 3rd Party hosts the web store. Suppliers who have already configured their web store for direct punch out from Oracle iprocurement can automatically enable punch out via an Oracle Exchange. Suppliers who have configured their web store using cxml for procurement applications such as Ariba Buyer can also utilise their existing configurations to support punch out via an Oracle Exchange. BT s current preference is a direct punch-out from our iprocurement application to the Suppliers site. However if a Supplier has previously implemented a punch-out via an exchange model and therefore wishes to use the same mechanism for trading with BT then that can be considered. For suppliers who have not enabled punch out for any procurement application, we recommended the OAG XML protocol be implemented to allow punch out via an Oracle Exchange and/or directly by Oracle iprocurement. Essentially the Supplier s web store needs to be able to: Read and validate the initial inbound XML punch out request providing details of the iprocurement user requiring connection to their web store. Construct and send an XML punch out response document, detailing the URL and session to which the user will connect to their site. Construct and send an XML Punch out Shopping Cart document with the content of the order. To do this, the Supplier must have an XML Parser, such as Oracle XML Parser for Java, Apache XML Xerces Java Parser, or another commercially available XML Parser. In addition, the supplier must copy the XML document DTDs (Document Type Definitions) for the inbound XML Punch out Request, outbound XML Punch out Response, and outbound XML Punch out Shopping Cart to their web server. These DTDs need to be used when parsing the inbound documents and constructing the outbound XML documents Security Punch-out requires firewall setup to let http/https connection to outside the firewall for server-toserver http/https connection. This connectivity is required to be able to send the login request document from IProcurement server to either an Exchange server or a supplier s server. The outgoing network traffic from IProcurement server to Exchange/Supplier server and the incoming response from Exchange/Supplier server to IProcurement server should be provided via network setup. Using IP addresses of involving servers will provide better network security. System Strategy Catalogue Options 12