EPURCHASING P2P (PURCHASE TO PAYMENT)

EPURCHASING PURCHASE 2 PAYMENT (P2P) EPURCHASING P2P (PURCHASE TO PAYMENT) Origin/Author : Capgemini Supplier Adoption Team This Version Created : July 2015 Capgemini UK plc Toltec 1120 Park Avenue Aztec West Almondsbury Bristol BS32 4SX Phone +44(0) 1454 612 211 Fax +44(0) 1454 873 636 Approved By Job Title Signature Date Approved Sarah Nunn TPTO team Leader Version 9.2 July 2015

Contents 1. Introduction 4 1.1. Purpose and Scope 4 1.2. References 5 1.3. P2P Transition Arrangements moving to e-trading with the MOD 6 1.4. MOD Security Marking on P2P data 7 1.5. HM Revenue & Customs Requirements for Trading Partners 7 2. P2P - An Introduction 8 3. P2P Process Outline 9 3.1. Requisition Sent to P2P Buyer (Flow 1) 10 3.2. Create & Send P2P Purchase Order to TP (2) 10 3.3. Order Acknowledgement / Confirmation (3) 10 3.4. Purchase Order Amendments 11 3.5. Advanced Shipment Notice (ASN)/Despatch Advice (4) 11 3.6. Deliver Goods (5) 11 3.7. Send Invoice (6) 11 3.8. Receipt Information Sent to P2P (7) 12 3.9. Match Invoice, Purchase Order and Receipt 12 3.10. Send Validated Invoice to DBS Finance 12 3.11. Payments made by DBS Finance (8) 13 3.12. Confirmation of Payment passed back to P2P 13 3.13. Catalogues within P2P 13 4. P2P Connectivity Options 14 4.1. Introduction 14 4.2. Message Standards 14 4.3. Connectivity Overview 14 4.4. Connection over the Internet via Exostar 15 4.5. Connection via EDI VAN 16 4.6. Connection via HTTPS 18 4.7. Summary of Connectivity Options for new Trading Partners 18 4.8. Message Security Considerations 19 4.9. Message Translation/Processing Options 20 5. Functional Implementation Guidelines 21 5.1. Purchase Order message 22 5.2. Purchase Order Change 24 5.3. Order Acknowledgement 25 5.4. Advance Shipment Notification 26 5.5. Invoice 27 5.6. Request for Quotes 28 5.7. Quotes 29 5.8. TaxCon Message 30 5.9. The Delivery Label 30 5.10. Receipt matching 30 5.11. Invoice matching 30 6. Communications 32 6.1. System Operations 32 2

6.2. Security Procedures & Services 33 6.3. Message Processing 34 6.4. Exception Handling 34 APPENDICES 35 Appendix A: General EDI Interchange Handling Requirements 36 Appendix B: General XML Interchange Handling Requirements 39 Appendix C: Glossary 40 Appendix D: Document Control 42 THIS DOCUMENT CONTAINS 43 PAGES INCLUDING TITLE PAGE Capgemini UK plc 2013 3

1. Introduction 1.1. Purpose and Scope This document provides MOD epurchasing Trading Partners with a guide to the Purchase to Payment (P2P) service. It aims to provide: A brief introduction to the P2P service An overview of the purchasing cycle and the related message flows A guide to the current connectivity options for communicating with epurchasing Functional (business) descriptions of the P2P message set and key factors to be addressed when implementing the full trading cycle Technical standards, operating procedures and requirements for inter-communication with the P2P service Who should read this guide? The P2P Service Implementation Guide (SIG) is intended to give information to the Trading Partner s P2P implementation team in the first case it will be of most benefit to the Trading Partner s Project Manager. Various sections of the guide will give more technical details to assist in the implementation at the Trading Partner end. Such sections will be more suited to IT staff. The SIG is not intended as an end user guide depending on the connectivity option chosen, there will be more appropriate user documentation available (see next section for references to such materials) Further information about P2P can be obtained from: MOD Commercial Officers; d2btrade.com website; Supplier Seminars; The Capgemini Supplier Adoption Team. Before the MOD will trade electronically with a supplier, the supply contract must contain an electronic agreement (Defform 30) which covers the commercial implications. The Defform 30 will either be signed at a corporate level, or individual contract level. The P2P Service Implementation Guide is a living document that will evolve as P2P develops. The intention is that the SIG will be regularly updated to reflect changes in epurchasing and P2P operation, usage and functionality as they impact on the Trading Partner. 4

1.2. References The following documents comprise the complete hierarchy of documentation for the P2P service, and are either referenced within this document or provide important related information. All of the documents can be found via the d2btrade website, or on request via the Capgemini Service Desk. When a supplier registers and selects a connectivity option they will be sent the appropriate reference documents. The epurchasing website www.d2btrade.com Provides up to date news and information on epurchasing, also contains Frequently Asked Questions on a number of topics. P2P Service Implementation Guide (P2P SIG) (this document) Provides information on the P2P service and its implementation by Trading Partners. P2P EDIFACT Message Implementation Guides (MIG) Provides detailed technical specifications on the implementation of the epurchasing P2P EDIFACT messages. Copies of these technical specifications are available on the d2btrade.com website. The MIG is currently at Version 201. The complete P2P MIG consists of: An umbrella document (titled the epurchasing P2P Message Implementation Guide ) purely to enable easy referencing of the detailed message guides (below) from contractual documents 1287_ePurchasing_P2P EDIFACT ORDERS Message Implementation Guide 1288_ePurchasing_P2P EDIFACT ORDCHG Message Implementation Guide 1289_ePurchasing_P2P EDIFACT INVOIC Message Implementation Guide 1290_ePurchasing_P2P EDIFACT ORDRSP Message Implementation Guide 1291_ePurchasing_P2P EDIFACT Envelope Specification 2212_ePurchasing_P2P EDIFACT DESADV Message Implementation Guide 2216_ePurchasing_P2P EDIFACT REQOTE Message Implementation Guide 2217_ePurchasing_P2P EDIFACT QUOTES Message Implementation Guide P2P OAGIS XML Message Implementation Guides (MIG) Provides detailed technical specifications on the implementation of the epurchasing P2P OAGIS V9 XML messages. Copies of these technical specifications are available on the d2btrade.com website. The MIG is currently at Version 302. The complete P2P OAGIS XML MIG consists of: An umbrella document (titled the epurchasing P2P XML Message Implementation Guide ) purely to enable easy referencing of the detailed message guides (below) from contractual documents 2329_ePurchasing_P2P Order OAGIS v9 Message Implementation Guide.doc 2328_ePurchasing_P2P Invoice OAGIS v9 Message Implementation Guide.doc 2327_ePurchasing_P2P Order Acknowledgement OAGIS v9 Message Implementation Guide.doc 2332 _epurchasing_p2p Envelope OAGIS v9 Message Implementation Guide.doc 2326_ePurchasing_P2P Advance Shipment Notification OAGIS v9 Message Implementation Guide.doc 2330_ePurchasing_P2P RFQ OAGIS v9 Message Implementation Guide.doc 2331 _epurchasing_p2p Quotation OAGIS v9 Message Implementation Guide.doc 5

P2P Delivery Label Specification Provides details of the accompanying hard copy information that suppliers may need to provide for any item or service delivered where the originating purchase order was raised through P2P, particularly for inventory contracts. Speak to your MOD contact in the first instance for details and requirements on labelling for your contract(s). The epurchasing website www.d2btrade.com links to external documentation that MOD have provided regarding label specifications (e.g. P2P Delivery Label - DEFFORM 129J DEFCON 129J and DEFCON 5J). epurchasing P2P EDI Connectivity Guidance for Suppliers Provides detailed guidance for Trading Partners choosing to connect to epurchasing with EDI, particularly those wishing to integrate the epurchasing message set with their own internal systems. epurchasing P2P EDI Connectivity Testing Guidelines Companion document to the EDI guidance above to assist in the testing phases of the implementation. epurchasing Catalogue Supplier Engagement Guidance Document Provides technical detail for suppliers wishing to provide electronic catalogues for the MOD to purchase from via P2P. Please refer to www.d2btrade.com or further information on catalogue functionality. Third Parties involved with epurchasing Connectivity Exostar provides proprietary software that allows connectivity to epurchasing. Outline information on this organisation can be found via the d2btrade website, and more detail will be found directly from the organisation at www.exostar.com 1.3. P2P Transition Arrangements moving to e-trading with the MOD To assist DBS finance in a smooth transition to P2P and to ensure payments are made promptly and accurately, it is essential that Trading Partners are clear about what is expected of them for orders placed prior to, and after, their P2P go live date. For orders placed on Trading Partners prior to their P2P go live date: - It is essential that the Trading Partner annotates his Form F640 or AG173 with the date of order, obtains a receipt on the bill and then submits to DBS Finance in the normal manner. For orders placed on Trading Partners via P2P: - It is essential that the Trading Partner is aware that they MUST NOT raise paper Forms F640 or AG173 for receipt and submission to DBS Finance. N.B. The Commercial Branch will send DBS Finance a list of all invoices which may be paid on paper after the contract has migrated to P2P. This is known as the Transactions in Being Template. If any paper documents are submitted which are not on this list, they will be returned to the Trading Partner for submission via P2P. The terms and conditions for payment will be specified to the Trading Partner in the contract with the MOD. These will allow for both existing and new documentation to be used. Trading Partners will be notified separately how and when the new invoices should be used for payment. It should be noted that legacy orders for which electronic trading has not been introduced would still be progressed through legacy systems and dual payment methods may exist on these contracts. To clarify the use of Dual Contracts - there are a number of instances where the MOD may use a Dual Contract, and so allow dual payments: 6

a) The contract has a large number of demanders some of whom are not connected to P2P. b) There is a joint agency contract and an agency that is P2P enabled can be identified separately. c) A contract includes both Inventory and Non-inventory items and they are not all on P2P. If the Trading Partner complies with the above it will ensure that payments continue to be made promptly and accurately as both the receipting officer and DBS Finance will be able to process their invoices speedily. If the Trading Partner has any queries regarding this they should contact the DBS Finance Help Desk on 0151 242 2000 or their MOD contract owner. 1.4. MOD Security Marking on P2P data All electronic or hard copy data held, processed, or transmitted in relation to contracts discharged using the P2P system is classed as UNCLASSIFIED but must be treated by the Trading Partner in accordance with DEFFORM 30. 1.5. HM Revenue & Customs Requirements for Trading Partners If a Trading Partner moving to P2P is submitting electronic invoices for the first time their representative should contact their VAT office (or whichever office handles their VAT) by letter to confirm the change to electronic invoicing and to establish what notification is required. They should make it clear that the invoices are being submitted by a secure, resilient (MOD security accredited) channel rather than e-mail. Further information can be obtained from www.hmrc.gov.uk (the relevant advice is VAT Notice 700, Chapter 6, Section 16). 7

2. P2P - An Introduction Purchase 2 Payment (P2P) provides the MOD with a centralised, tri-service procurement solution, and represents an important step in enabling the MOD and their Trading Partners to meet key strategic e- commerce objectives. The P2P service: Provides a single tri-service process for the MOD purchasers, with all orders recorded in a central orders database. Captures demands from MOD users, converts them into orders and then routes them electronically to the appropriate MOD Trading Partner. Enables Trading Partners to communicate electronically with the MOD via epurchasing, submitting order acknowledgements, and invoices etc. Enables accelerated matching of invoices with orders and receipts and allows more timely payment. The P2P service will remove the need for the F640 and AG173 form sets. Dual payment schedules may apply to contracts under circumstances as described in section 1.3. Will allow visibility and use of contracts across the MOD. Will allow visibility and use of Catalogues across the MOD where appropriate. Will provide consolidated Management Information at Category, Supplier, Contract and User level to support forward procurement decisions and supplier management Benefits of the P2P service to a Trading Partner include: Paperless Trading Process Faster Processing of business transactions MOD will be responsible for obtaining receipts No more lost MOD Forms 640 or AG173 Quicker Payment Improved Accuracy Opportunity of a single interface for all electronic Purchasing A Trusted Third Party A Secure Environment MOD fund the epurchasing service itself (which provided the benefits above), though a Trading Partner may incur cost for their chosen method of connection. P2P was implemented initially for what MOD term non inventory purchasing this is where purchase orders are created directly on P2P by MOD buyers. P2P now also has the capability to process purchasing requirements generated by the MOD s Inventory Management Systems. MOD buyers can also raise inventory purchase orders directly on P2P, without first receiving a demand from the legacy system. 8

3. P2P Process Outline The diagram below provides a high-level overview of the P2P purchasing cycle and the sections following briefly describe each step in the process diagram. Further relevant detail on the various stages is given later in this document. epurchasing P2P High Level Processes To set the scene, we first need to introduce the key activities which are involved in the P2P process. Firstly, we have a Requisitioner who has a requirement for goods or services that needs to be met, and he is supported by a Buyer for those goods or services which require purchase action. For much of the initial P2P activity both will reside within an Integrated Project Team (IPT). Increasingly as catalogue usage is extended Requistioners could reside anywhere across the MOD. Next, we have a destination or receipt point which may be within a warehouse, but could equally be a unit receiving direct delivery, or it could be a department that is receiving a service. Then we have a Payment Authoriser, located within the DBS Finance. 9

3.1. Requisition Sent to P2P Buyer (Flow 1) The purchasing process starts with a requirement and the raising of a Requisition either by an IPT directly in P2P, possibly by selection from an electronic catalogue, or, for inventory, generated by an inventory system. Within P2P this requisition goes to a Buyer for approval. The MOD Buyer will allocate the requisition to a contract. Within the new process buyers can electronically access existing Contract details through P2P rather than searching through paper contracts. However it should be noted that the creation of the Contract agreement itself remains an off-line process by MOD Commercial Staff with Trading Partners. Details of such agreements will be loaded to the P2P database to enable purchasing transactions to take place. In respect of inventory, requirements from MOD inventory systems will pass through an electronic interface into P2P and in most cases will be automatically processed through P2P using autosourcing rules. 3.2. Create & Send P2P Purchase Order to TP (2) A Purchase Order is either raised electronically by the Buyer from the requisition within P2P, therefore reducing transcription errors and saving time, or the system will automatically create Purchase Orders against existing Contractual agreements where it has been configured to do so. (This is known as autosourcing ). For e-catalogues, items are often auto-sourced, in line with the quick turnaround required for the items and the general desire to streamline the purchasing process. Non auto-sourced requisitions will require MOD interaction and approval before Purchase Orders are created The P2P system will generate a Unique Order Identifier (UOI) for each Purchase Order shipment created. This UOI will enable purchase orders, invoices and receipts to be automatically linked and matched later in the process. The UOI has three parts: The first part is a unique Purchase Order identifier generated by the system, the Purchase Order Number. The second part is the Purchase Order Line Number. The third part is the Shipment detail - the Purchase Order Line Shipment No. Additionally, for those requisitions raised via the stores inventory system a Unique Receipt Reference Indicator (URRI) will be allocated. The P2P system will generate an alphanumeric URRI for each Purchase Order shipment/line created. Trading Partners need to build the capability to identify and store the UOI and URRI in their systems as they need to be returned by them in messages to P2P, and on delivery documentation that accompanies deliveries of goods and services to the receiving points. The Purchase Order is transmitted to the Trading Partner via their chosen epurchasing connectivity option. 3.3. Order Acknowledgement / Confirmation (3) On receipt of the purchase order the Trading Partner needs to confirm that they are able to meet the order. They do this by sending a positive electronic confirmation back through epurchasing. This message will be received and imported into P2P. The buyer now knows that the order has been accepted and can expect the goods to be delivered Where the order cannot be met in full on the required date Trading Partners are to send PO acknowledgements with amendments or cancel/reject (i.e. negative acknowledgements. This may entail the 10

cancellation or amendment of the original order.) This does not mean that the Trading Partners cannot make contact with the MOD nominated Order Manager to discuss options and agree how to proceed. This process should be initially agreed. 3.4. Purchase Order Amendments Where amendments are permitted within the contract, MOD can access the Purchase Order in P2P and make amendments or cancellations. The Purchase Order Amendment will be transmitted to the Trading Partner via their chosen epurchasing connectivity option, as per the original order. The Trading Partner is expected to acknowledge the amended order, as he did the original. Note that in EDI terms, the message used to acknowledge orders and order amendments is exactly the same message. 3.5. Advanced Shipment Notice (ASN)/Despatch Advice (4) For those Trading Partners who have inventory contracts an Advanced Shipping Notice (ASN) may be required. Trading Partners send an electronic message (ASN), containing information on the expected delivery dates. This message will be received and imported into epurchasing P2P and commodity managers will be notified of any exceptions raised. For Fleet orders, the ASN s will be forwarded to the MOD Warehouse IT System (WITS) receiving system, based on delivery location. WITS will receive this message from epurchasing and directly load this message into the receiving system to use as a basis for the receiving points pre-receipt processing. 3.6. Deliver Goods (5) Goods, or services, are delivered to the requested receiving points by the Trading Partner at which point they are either receipted into P2P manually with reference to the Unique Order Identifier/URRI, or scanned into the separate MOD receipting system (as in the case of most inventory suppliers). Depending on the terms of the Trading Partner s contract, and the nature of what is being delivered, the receipting process may require the capability to electronically scan delivery note details from MOD Delivery Labels. The label should present key information on the delivery including the Unique Order Identifier or URRI (for inventory suppliers), contract number and quantity. The UOI/URRI should also be contained within the barcode on the delivery label unless otherwise stipulated by contract. 3.7. Send Invoice (6) Trading Partners send Invoices to P2P via their chosen epurchasing connectivity option once the delivery has been made. (Invoices should not be input before delivery is made.) The invoiced quantity should be equal to the delivered quantity - any difference will result in a failure of the invoice match. Invoice information must include (amongst other data) Supplier s GAX code (see below) The Unique Order Identifier Invoice Quantity Gross Invoice value Various VAT data items, including the trading partner s VAT registration number. 11

Once a contract is migrated to P2P (either partially or fully), the Trading Partner must only invoice any P2P part of that contract electronically they must not additionally send a MOD Form 640 or AG173 for a P2P order. Commercial style invoice numbering is supported, provided invoice numbers are unique within the Trading Partner/Trading Partner Pay Site (i.e. unique within the GAX code). When supplying an Invoice Reference number, Trading Partners should be aware that P2P will only retain the first 14 characters for UK Invoices and the first 10 characters for non UK invoices. Invoice amounts should be entered to 2 decimal places and invoice shipping quantities to a maximum of 3 decimal places. Where suppliers have integrated to their own systems they should have the capability to Re-invoice where necessary. Note: Trading Partners making changes to their name and/or title must notify DBS Finance, Commercial Services Group (Abbey Wood, Bristol BS34 8JH) and epurchasing immediately to avoid delays in the payment process. The GAX code is provided by the SDV Team and the format must be 1234500, i.e. a 7 digit number, without any embedded spaces. Supplying an incorrect GAX code format will result in delayed payment. The first 5 numbers are the specific GAX code (Contractor Code) and the last two digits are the pay site identifier (Address Code). For Trading Partners with a single pay site, the address code will normally be 00, but it should not be assumed to be so. Trading Partners unsure of their GAX code should contact their MOD commercial officer, or the MOD SDV team in Liverpool. 3.8. Receipt Information Sent to P2P (7) Receipts made into P2P at the delivery points identify the quantity delivered against the Unique Order Identifier. The receipt quantity is matched against the original purchase order and the supplier invoice, when that is received in P2P. For some Trading partners in the inventory sector, the MOD systems send receipt of goods information to epurchasing, which includes the URRI and NATO stock no (NSN). These are used to match the receipt to the epurchasing Purchase Order. 3.9. Match Invoice, Purchase Order and Receipt The Invoice, Purchase Order and Receipt quantities and values are matched in P2P, and validated invoices will be notified to DBS Finance. Any invoice mismatches, e.g. quantity mismatches against Purchase Order, Receipt and Invoice, will normally be identified by DBS Finance via the P2P Invoices on Hold report. These would then be resolved, in conjunction with the Order Managers where necessary. For more information on the matching processes see section 5 of this document. 3.10. Send Validated Invoice to DBS Finance DBS Finance login to P2P and perform a payment run. This identifies successfully validated invoices. The payment run generates a file of payment details, which is transmitted to the DBS Finance systems. 12

3.11. Payments made by DBS Finance (8) DBS Finance will make payments, by the standard method, to the Trading Partners for the validated invoices forwarded by P2P. These P2P payments will be included within a Trading Partner s overall payment from DBS Finance and will still be accompanied by a remittance advice containing the details of all the invoices, P2P or non-p2p, included in the payment. Note that the payment process is not part of epurchasing. 3.12. Confirmation of Payment passed back to P2P Once payments have been released by DBS Finance, a payment confirmation feed is passed to P2P. This will therefore be visible to the MOD users, but not to Trading Partners. Trading Partners notification of payment is limited to the remittance advice. 3.13. Catalogues within P2P As the catalogue browsing and purchasing is a buyer side process, catalogue orders when sent out by P2P do not appear by any different mechanism to non-catalogue orders to a Trading Partner although some of the data content of messages vary as the items are not necessarily MOD P2P items. Such detail should only impact EDI and XML traders integrating to internal systems, and advice is given in the EDI and XML Connectivity Guidance for Suppliers documents. 13

4. P2P Connectivity Options This section provides an introduction to the connectivity methods and options available to P2P subscribers. More detail on each of the options, including costs, the business factors that might influence the connectivity decision and links to relevant external suppliers, can be found on the epurchasing website www.d2btrade.com. 4.1. Introduction In simple terms, the secure electronic transfer of business documents between computer systems requires: A standard format for arranging and presenting the business data within the message. Examples include traditional EDI standards such as EDIFACT, and emerging standards such as XML. A communication mechanism for transporting the message between the parties, in a secure and reliable fashion. Examples include the use of commercial EDI network providers, or use of the Internet. Systems or procedures in place at each end to receive, translate, process and reply to messages. Examples range from manual procedures (such as printing/re-keying message into back-end systems), to complex message transformation and brokering systems with automated interfaces into a range of enterprise systems. The standards supported by epurchasing and the options available to P2P subscribers for each of these are outlined in the following sections. 4.2. Message Standards The P2P solution provides a number of connectivity options, all of which utilise either the United Nations EDIFACT standards, or XML OAGIS v9 as the basis for defining electronic interchanges with Trading Partners. 4.3. Connectivity Overview In general, a communication mechanism for transporting a message electronically between two parties must provide the following: A network infrastructure connecting the systems in question. A standard protocol for transferring the message itself between systems. For Trading Partners, epurchasing is currently accessible via three routes: Access via the Exostar Exchange this is an internet based option; A commercial EDI Value-Added Network (VAN) provider (e.g. GXS Global exchange Services); A direct connection using HTTPS 14

The choice of connectivity option depends on a number of factors; keys ones being Volume of transactions expected Location of users (co-located or spread over multiple sites) Cost of connectivity Desire/need to integrate with internal IT systems Existing infrastructure or capabilities Type of workload i.e. inventory suppliers; 4.4. Connection over the Internet via Exostar 4.4.1 Overview A business-to-business trading exchange provides an electronic marketplace to its subscribers and so offers a number of services that support business-to-business interactions, such as purchasing, catalogues, and auctions. Subscribers typically access the services of the exchange using a web browser over the Internet. In concept, the ideal scenario is for different trading exchanges to interact in much the same way as the global telephone network, where a message that is sent from one company to epurchasing Secure ebusiness Solutions for the world of Defence Exostar Over the internet Enables users to manage MoD orders alongside orders from other buyers using same Exostar interface Requires Internet access and web browser Low cost & minimal IT requirements Simple, quick registration process epurchasing Secure Environment Exostar Users can view and acknowledge orders and raise invoices using the MOD SCP web portal another may be routed through exchanges belonging to different companies before arriving at its final destination. The aspiration for the MOD is that, whatever exchange a subscriber is connected to, they will be able to receive their orders from the MOD, and send back order acknowledgements and invoices through the normal trading functionality provided by that exchange. In the Aerospace and Defence industry, one of the key trading exchanges is Exostar. The Exostar service relevant to Trading Partners wishing to trade with the MOD is Supply Chain Platform (SCP). For more detail on Exostar and SCP including charging scales based on volumes of business processed, refer to the Exostar website www.exostar.com Whilst this option is ideal for Trading Partners who already have an Exostar SCP account, it is also a good option for those who want to use an Internet connection, or those expecting a low volume of MOD orders. 4.4.2 What do I need to connect? Any Trading Partner wishing to connect via Exostar needs to obtain an account via the Capgemini Trading Partner take on team. They can be contacted through the Capgemini Service desk on 0870 241 3569 in order to ensure P2P linkage via epurchasing. 15

Trading Partners connecting via Exostar do not actually connect to epurchasing they connect to, and trade on, the Exostar hub, and the Exostar hub makes the connection to epurchasing. This way, only the ExostarePurchasing connection needs to be secured, rather than each individual Trading Partner s connection. Consequently, Exostar SCP allows Internet connectivity to trade with the MOD without the requirement additional security such as smartcards. Connection to Exostar therefore just requires an Internet connection and a web browser. Full details of the connection requirements can be obtained from the Exostar website, as above. SCP connections are made by accounts a Trading Partner subscribes to an account, and can then create as many users as they wish to on that account. 4.5. Connection via EDI VAN 4.5.1 Overview A Value-Added Network (VAN) provides an electronic post-office service to its subscribers, usually for the exchange of EDI messages. Subscribing companies use a single VAN connection to send data to an electronic mailbox, which frees companies from having to maintain separate connections (often with different communications protocols). Typically, VANs levy charges per message sent, but in return VANs provide a level of security and accountability (e.g. message delivery assurance) not currently provided by the Internet. Connection to a VAN will usually require some form of User Agent to access the system and to send/receive messages. Often this User Agent will be a PC with communications software specifically configured for the VAN in question. Precise requirements vary according to the VAN, since each has its own method of providing its service. Usually, each company subscribing to a VAN will be allocated some form of VAN mailbox address, to which its trading partners can send messages. The VAN effectively provides a closed group of subscribers. However, where a company wishes to communicate with trading partners who subscribe to a different VAN, the VAN provider will normally provide an interconnect service to forward messages onto other networks. 16

4.5.2 epurchasing VAN Connection epurchasing has a connection to the GXS (Opentext) Trading Grid. Existing users of GXS Trading Grid can communicate with P2P by simply providing the relevant mailbox address during the epurchasing registration process. Existing users of other VANs will need to contact their VAN supplier and request a VAN interconnect facility to allow them to communicate with epurchasing. More information on this can be supplied during the epurchasing registration process. Trading Partners without a VAN connection could consider subscription to a VAN supplier (and set-up VAN inter-connect if that supplier is not GXS Trading Grid). 4.5.3 Message Transfer via EDI VAN epurchasing communicates with the GXS Trading Grid using X.400 message standards. The mechanism by which a Trading Partner connects to the VAN will vary according to the VAN s connectivity offerings and the TP s capabilities. Typically, a Trading Partner might access the VAN via an analogue dial-up connection or the internet, and use proprietary software (supplied by the VAN provider or a third party) to collect messages from the VAN mailbox and submit messages to the VAN for onward transmission. To communicate with epurchasing via EDI VAN, the Trading Partner requires a connection to the same VAN or to a VAN provider that is capable of setting up a VAN interconnect arrangement with GXS Trading Grid. epurchasing has a dedicated communications link to GXS Trading Grid, and communicates with this VAN via the X.435 protocol over TCP/IP. However, most VANs provide a variety of access mechanisms (e.g. X.400, FTP, OFTP etc). Therefore the technical requirements and options for communicating with epurchasing via VAN will vary according to the VAN provider. Information on communications requirements should therefore be sought from the VAN provider in the first instance. See Appendix A for further information on EDI Message Standards. 17

4.6. Connection via HTTPS 4.6.1 Overview The Direct Connection using HTTPS involves traffic over the Internet using an HTTP connection over an encrypted Secure Sockets Layer (SSL). This option is intended for Trading Partners expecting a large volume of Purchase orders that they will feed into their back-end systems Trading Partners wishing to connect via HTTPS will need an internet connection HTTPS utilises the OAGIS v9 XML standards, as the basis for defining electronic interchanges with Trading Partners epurchasing Secure ebusiness Solutions for the world of Defence HTTPS Direct Link using XML Messages Exchange of structured messages via a direct link between epurchasing and the supplier Use of XML messaging Assured delivery and high degree of resilience Can process high transaction volumes XML Messages can be actioned by a user using software, written by a 3 rd party or in-house epurchasing Secure Environment Messages can be passed directly into back-office systems for processing Suppliers Connection software B2B connection software will be required to handle the HTTPS connection it is not possible to just connect using a web browser. 4.7. Summary of Connectivity Options for new Trading Partners The current options for establishing communications with the epurchasing infrastructure and enabling the exchange of messages with the Purchase 2 Payment service are summarised below. Exostar Exchange Connection Requirements: Registered with Exostar ISP subscription Web browser software Reasonably low volume of transactions (low 100s per year. System will permit unlimited number of transactions, but with too high a volume these become unmanageable for a user) Advantages: All orders (MOD and non-mod) managed through a single interface Easy access Web access without Smartcards Low cost if low volume, through transaction based subscription Multiple user accounts per subscription Allows trading with other Exostar buyers Supports Inventory requirements Produces Shipping label 18

Connection via EDI VAN Requirements: VAN subscription (provides dedicated mailbox on VAN network). Communication software/hardware and communication link (e.g. dial-up) as required by VAN. VAN-interconnect arrangement if not subscribing to GXS Trading Grid. Where suppliers have integrated to their own systems they should have the capability to Reinvoice. They should also be able to hold and turn-round data items, e.g. unique order identifier. Advantages: Particularly suitable for existing EDI VAN subscribers Proven, widely-used technology Assured delivery Integration to supplier s own systems Good for high volume use (1000s + per year) VANs typically support intermittent/dial-up connections. Supports inventory requirements Connection via HTTPS Requirements: ISP subscription Web browser software. B2B connector software will be required to handle HTTPS A client and server certificate issued by Trustis Advantages: Easy access No subscription/3 rd party involved Good route for high volumes 4.8. Message Security Considerations For the Exostar Exchange, a secure connection exists between Exostar and epurchasing. In the case of the VAN however the MOD have agreed that UK EDI VAN connectivity is secure and hence will not require further encryption. Requirements for delivery assurance are specific to the connectivity method adopted. For HTTPS, connection will be via the internet using Trustis Client and Server Certificates. Trading Partners must ensure that data transferred to/from epurchasing is hosted on a secure site. For more details please see document epurchasing Trading Partner HTTPS Connection Guide. 19

4.9. Message Translation/Processing Options The electronic transfer of business documents requires systems or procedures in place at each end to receive, translate, process and reply to messages. It is likely that Trading Partners who already participate in EDI networks will already have systems and/or procedures in place. For those that do not, the range of possible approaches includes: Manually driven procedures e.g. checking a VAN mailbox via a dial-up connection using applications provided by the VAN, Developing direct interfaces from ERP/sales order/production systems to EDI VANs and HTTPS Utilising message transformation and brokering systems to connect multiple ERP/sales order/production systems to EDI VANs and HTTPS. 20

5. Functional Implementation Guidelines This section summarises the key information about the usage of P2P for all connectivity options and any particular business processes/rules to be followed within the trading cycle. Note that this is not a full listing of data fields or usage, for those Trading Partners requiring such data (e.g. those choosing to connect via EDI VAN or HTTPS and integrate with internal systems), the EDIFACT and OAGIS XML message specifications are available on the d2btrade.com website. The full P2P message set consists of seven EDI message types Purchase Order, Purchase Order Change, Purchase Order Acknowledgment, Advance Shipment Notice, Invoice/Credit, Request for Quotes and Quote. Below is a Table of the different connectivity s and the message types that they support: Purchase Order Purchase Order Change PO acknowledgement Advance Shipment Notice Invoice/Credit Request for Quote Quote Exostar Yes Yes Yes Yes Yes TBC TBC EDI Yes Yes Yes Yes (from Yes Yes ver 201) (from ver 201) HTTPS Yes Yes Yes Yes Yes Yes Yes Yes (from ver 201) Trading Partners taking the message options (e.g. EDI/HTTPS) and integrating into internal systems should endeavour to deal with all message types. Certain MOD commercial departments and contracts may agree a limited message set (e.g. no Acknowledgement, or Order Change) but Trading Partners developing their systems with such restrictions should be aware that they may be limiting their ability to trade with other MOD areas outside the contract in question. The only way to maintain full flexibility is to implement processing for the full message set. The P2P e-catalogue system uses the same messages as standard non-catalogue P2P. The P2P message set is fully defined in the Message Set Version 201 for EDIFACT Messaging and Message Set Version 302 for HTTPS messaging respectively both of which are available on the d2btrade website, and are referenced in more detail in appendix A and appendix B. 21

5.1. Purchase Order message General Information Purpose: Conveys the MOD requirements Sent from/to: From P2P to Trading Partner Structure & Summary of Key Fields Header P2P system generated Order Number (Order numbers will be purely numeric for P2P orders) Legacy Purchase Order numbers for inventory orders which originated in MOD stores systems Order Revision Number (for order amendments) Order Release Number (for releases against a blanket order) MOD Contract Number Supplier NCAGE code Payment Terms Order currency Header level note to supplier Line Description of the goods and/or services required, together with one or more of the following: NSN (NATO Stock Number sent as NSC + NIIN, fields to be combined) MOD item number with CPV (Common Procurement Vocabulary) category coding for noninventory items (i.e. not NATO codified) CPV categorisation of goods/service required. Suppliers Item Number Unit of Measure Purchase Order Price Line level note to supplier Shipment Original File Reference (Line No./Shipment No.) Originators Reference (Unique Order Identifier P2P Order-Line-Shipment reference). Sometimes referred to as the JIGSAW reference. URRI Number (Unique Receipt Reference Identifier) when applicable (i.e. where the order emanates from one of the MOD s inventory stores management systems. The URRI numbers sent in Purchase Order messages for Air orders are 5-character alphanumeric. URRI numbers for Navy orders are prefixed with the letter S, Land orders with an L, and BIWMS with a B, and are therefore 6-character alphanumeric Address Code: Either UIN (Unit Identification Number the goods and/or services are intended for. The address may vary for a given UIN e.g. where a unit is deployed overseas) or NCAGE (if goods are to be shipped directly to a supplier address rather than a MOD location, or for services at the address where the service is to be performed). Ship To Address Order Quantity 22

Need by date Shipment level note to supplier Business Rules Purchase Orders (POs) will represent either an acceptance of a contractor s Offer or an Offer of Contract by the Authority to the contractor in accordance with the Terms and Conditions of the contract e.g. DEFCON 615A. Where Offer and Acceptance has already taken place outside of the P2P environment a PO message conveys to the contractor the information required to produce the Delivery Label and an Invoice message e.g. DEFCON 615B. In all circumstances the Terms and Conditions of the contract shall have precedence. Purchase Orders can have multiple lines with multiple shipments per individual line, and the shipments could all be to different locations Certain information on the order needs to be returned to the MOD on the resulting invoice in the same format and case as sent e.g. the Payment terms, and the Unique Order Identifier. MOD has the capability to send notes to suppliers with the header, every line and every shipment on the order. These are 80 character free text fields in P2P (for line and shipment) and 240 characters for the header note. Trading Partners will need to consider the practicalities of receiving orders with notes, particularly if they are integrating automatically to internal systems. MOD will not use the notes fields to vary commercial terms but there could be important information held in these notes. MOD also has the facility to supply large text fields formatted on a contract by contract basis (by agreement between MOD and Trading Partner). 23

5.2. Purchase Order Change General Information Purpose: Conveys modification to MOD Requirements Sent from/to: From P2P to Trading Partner Structure & Summary of Key Fields Same as Purchase Orders. Amendments can be identified by the serially numbered revision number. Business Rules In accordance with DEFCON 503, Purchase Orders Amendments (POAs) can represent either an acceptance of a contractor s Offer of Amendment to Contract, or an Offer of Amendment of Contract by the Authority to the contractor in accordance with the Terms and Conditions of the contract. Where Offer and Acceptance has already taken place outside of the P2P environment a PO message conveys to the contractor the information required to produce the Delivery Label and an Invoice message e.g. under DEFCON 615B arrangements. In all circumstances the Terms and Conditions of the contract shall have precedence. When an order change is sent from P2P, the whole amended order is re-sent, not just the amended lines/items/data. 24

5.3. Order Acknowledgement General Information Purpose: Response to Purchase Order. From MIG version 201 onwards and XML OAGIS V9 AcknowledgePurchaseOrder message. Negative acknowledgment declines Purchase Order or parts there of. Positive acknowledgment accepts purchase order. Sent from/to: From Trading Partner to P2P Structure & Summary of Key Fields MOD Contract Number P2P Order Number (as sent on the original order or order change) Legacy Purchase Order number (for inventory suppliers, as sent on the original order or order change) Order revision and release numbers Acceptance code Business Rules - Dependent upon the purpose of the order or order change, an Order Acknowledgement represents either an acceptance of an offer or confirmation of receipt of the message. In all circumstances the Terms and Conditions of the contract shall have precedence. - Acknowledgement at Header level but applies to all line-shipments in the PO - Use free text to identify reason for rejection or amendment and identify which line/shipment(s) are involved. - Some MOD contracts do not require acknowledgements at all, some only require negative acknowledgements and others require both positive and negative acknowledgements. - Notes to commodity manager should be provided if the line is not accepted. - For EDIFACT Acceptance codes should be either 27 (Not accepted), 29 (Accepted without amendment) or 30 (Accepted with amendment) see 1290_ePurchasing_P2P EDIFACT ORDRSP specification.doc for further detail. - For XML OAGIS Acceptance codes should be Accepted, Rejected or Modified see 2327_ePurchasing_P2P Order Acknowledgement OAGIS v9 Message Implementation Guide.doc for further detail. 25

5.4. Advance Shipment Notification General Information Purpose: Sent from/to: Provides despatch advice. From Trading Partner to epurchasing P2P Structure & Summary of Key Fields Header Supplier NCAGE code Freight terms Line NSN (Nato Stock Number) Contract Number (As sent from epurchasing. NB the Air format differs) P2P Order Number (as sent on the original order or order change) Legacy Purchase Order number (for inventory suppliers, as sent on the original order or order change) Intermediate delivery location (codified) URRI Number (Unique Receipt Reference Identifier). URRI numbers sent in the Advance Shipment Notification message will prime the MOD receipting systems to accept deliveries with a matching Shipping Label URRI barcode. All requirements to be satisfied in a single shipment require that the URRI numbers are sent back to epurchasing with a suffix A, thereby becoming 6 or 7 alphanumeric combinations. If multiple shipments are to be made against a requirement, Trading Partners will need to increment the URRI suffix for each part-shipment, letter A being associated with the first shipment, B with the second etc. This is only required for inventory. Business Rules No limit to the number of shipments detailed in an ASN A maximum of 26 part-shipments can be made against a requirement, as Z is the final suffix available. Trading Partners should contact the MOD to agree an order amendment or other action to resolve this type of issue ASN s can relate to shipments from different Purchase Orders for a single contract. Trading Partner must return the Nato Stock Number NSN (on LIN segment) from the equivalent LIN segment on the order - but this may be blank for non inventory items 26

5.5. Invoice General Information Purpose: Requests payment from the MOD. Sent from/to: From Trading Partner to P2P Structure & Summary of Key Fields Header P2P Purchase Order Number (as on the original order) Supplier GAX code with GAX suffix. Suppliers will be informed of this by the MOD during the P2P take-on process. The code should be entered in the format 1234500, i.e. a 7 digit number, without any embedded spaces. The first 5 numbers are the case specific GAX code (Contractor Code) and the last two digits are the pay site identifier (Address Code). For Trading Partners with a single pay site, the address code will normally be 00, but it should not be assumed to be so. Suppliers VAT number Buyers VAT Number (GB888 805068 for MOD) Name and address of buyer Payment Terms (exactly as sent out on order) Line The full Unique Order Identifier order number/line number/shipment number, as presented on the original order) Line Item Amount Quantity (to a maximum of 3 decimal places) Line Item Price Line Tax Code Line Tax Rate Line/Shipment Number Invoice Summary Total Invoice Amount (Gross Total Amount including VAT entered to 2 decimal places) Total VAT payable in sterling Total VAT payable in invoice currency (even if sterling) Taxable Amount (i.e. the invoice value without VAT) Business Rules In all circumstances the Terms and Conditions of the contract shall have precedence. There is no limit to the number of invoice lines per Invoice message but all lines must relate to a single Purchase Order. Invoice quantity should match the delivery quantity. Invoices should not be submitted until goods or services have been delivered. Purchase Order shipments may be part invoiced. 27

5.6. Request for Quotes General Information Purpose: Request for a Quotation (RFQ) Sent from/to: From P2P to Trading Partner Structure & Summary of Key Fields Header RFQ Number automatically generated RFQ number from P2P RFQ date RFQ description Contract number NCAGE Buyers name Line Line description RFQ line number Business Rules In all circumstances the Terms and Conditions of the contract shall have precedence. There may or may not be a target price The Trading Partner being sent the request must be on P2P and have an existing contract 28

5.7. Quotes General Information Purpose: Provides price offer to the MOD against request for goods or services Sent from/to: From Trading Partner to P2P Structure & Summary of Key Fields Header - Quotation number assigned by Trading Partner - Quotation date - Contract number - RFQ number - NCAGE - Supplier name - Buyer name - Line - NATO Stock number (NSN) - Line item description - Unit of Measure - Quantity quoted for - Line number as per RFQ - Line revision number as per RFQ - Business Rules - In all circumstances the Terms and Conditions of the contract shall have precedence - Line and revision number must match the line and revision number on the RFQ - Quote must be in response to a Request for Quote sent by the MOD 29

5.8. TaxCon Message The TaxCon message is not required for electronic Invoice messages sent by Trading Partners to the MOD via epurchasing. If Trading Partners need to include a TaxCon message e.g. to be consistent with their other EDIFACT implementations, it will be ignored by the epurchasing EDIFACT interface software. In this case it would also be advisable to inform Capgemini so that unnecessary support calls do not get raised. 5.9. The Delivery Label The Delivery Label is specified by the MOD in DEFFORM 129J for use by Trading Partners responding to P2P orders for both goods and services. Trading Partners will need software to produce the Delivery Label and a range of commercial packages are available which can do this. It may be beneficial for Trading Partners to discuss this requirement with their MOD commercial offers depending on the nature of business and the contracts involved, there may be flexibility particularly for non-inventory goods and services. However, for full compliance with P2P trading, and to ensure that a Trading Partner does not limit their ability to trade with anyone in the MOD, the full DEFFORM 129J specification would need to be followed. For inventory suppliers the Shipping label has additional information on it such as the URRI numbers. Trading Partners must contact their MOD commercial officer for information on the requirements for the label. 5.10. Receipt matching The Unique Order Identifier on the Delivery documentation (one per consignment) will be input with other information (such as the delivered quantity) directly into P2P for non-inventory receipts. For inventory, receipts will be made in the MOD (legacy) receipting systems and then forwarded to P2P. Each receipt will be matched against Purchase Order information held within P2P using the following fields: - - Unique Order Identifier/URRI - Quantity - NSN - Purchase Order Number Receipts that are consistent with order/shipment requirements will be available for invoice matching. Mismatches or inconsistencies will be reported to commodity managers to action with Trading Partners. Multiple part-shipments will be accepted until the shipment total is matched. If the quantity of goods received by the MOD does not match the quantity stated on the delivery documentation, the actual quantity delivered will be recorded. 5.11. Invoice matching Any invoice received on P2P before a receipt has been made will be held until a receipt has been made to be matched against. Invoice matching in P2P will be carried out as a batch process several times each day. The fields used are: - Unique Order Identifier Order Value Quantity Ordered 30

Quantity Receipted Invoice Value Invoice matching in P2P is based on a quantity match between order-shipment quantities with receipted quantities and a price match between invoice value and order price. If these are successful then payment will be made on the basis of agreed terms. Any discrepancies will be actioned by commodity managers and/or DBS Finance. Care should be taken to ensure that quantities invoiced match quantities delivered. Where suppliers have integrated to their own systems they should have the capability to Re-invoice as necessary. 31

6. Communications This section details the standards and requirements for communicating with the epurchasing platform, for each connection method. 6.1. System Operations All Trading Partners should test and maintain their equipment, software and services necessary to effectively and reliably connect to epurchasing. 6.1.1 epurchasing Change and Configuration Management A comprehensive configuration and release management process is used to manage changes to the epurchasing environment. Changes and upgrades to epurchasing components are subjected to a controlled release cycle, moving through a number of environments and platforms before being applied to the live environment. All key components of the live epurchasing environment are continuously monitored for failure via an enterprise systems management tool, which raises alerts if exceptions occur. Any reported faults are recorded, and their resolution tracked through the standard Capgemini service desk tools and procedures. 6.1.2 epurchasing Availability The epurchasing agreement between Capgemini and the MOD includes a Service Availability Schedule, setting out availability targets for various aspects of the epurchasing service. For the message delivery service this is 98% of operational time where operational time is 24x365 less any planned down time. No distinction is made between service availability to the MOD or to the Trading Partners. From time to time, planned down-time will be required to carry out essential work not possible whilst the Service is operational. There is also a housekeeping window booked every month, normally the second Tuesday of the month between 18:00 and 22:00. This has been agreed with the MOD in order to carry out routine maintenance tasks and hence the service will be unavailable during this period. This will not be subject to notification as it will happen every month and so does not fall under the planned downtime for notification. Such non-availability of systems will, wherever possible, be scheduled outside of the normal working day. Except in an emergency such non-availability will be agreed with the MOD in advance. Details of planned downtime will be notified to Trading Partners either via details published on the epurchasing website at www.d2btrade.com and/or by direct communications (email or telephone) with the Trading Partner contacts nominated during the epurchasing registration process. 6.1.3 Trading Partner Validation Testing Each Trading Partner connecting to epurchasing will go through a validation test prior to live trading, as part of the take-on process. Trading Partners should make available the appropriate systems, resources and personnel, as required, to undertake this validation testing in a timely fashion. Trading Partners developing their own software to receive and process P2P messages will be expected to fully test this before entering into a final test stage with Capgemini. Testing guidelines and generic test data can be made available to the Trading Partner, in line with the P2P EDIFACT and P2P HTTPS XML Message Implementation 32

6.1.4 Trading Partner Training Trading Partners connecting via the Exostar Exchange should refer to www.exostar.com where they will find downloadable documents such as user guides and recorded training sessions. EDI and HTTPS XML Trading Partners are expected to be interfacing epurchasing messages to their own systems and so are assumed to already have documentation and training materials for these systems. 6.1.5 Trading Partner System Changes & Availability If, at any time, a Trading Partner is unable to trade with the MOD via epurchasing, the Trading Partner is responsible for ensuring that the MOD is informed accordingly and advised of any impact on their business. If a Trading Partner s system is unavailable - such that the Trading Partner will not be able to receive or respond to epurchasing messages in their usual timescales the Capgemini Service Desk should also be informed accordingly. Similarly, Trading Partners should inform the Capgemini Service Desk, in advance, of any significant changes to the Trading Partner systems that might impact or alter their ability to transmit or receive messages to/from epurchasing. The Capgemini Service Desk can be contacted on 0870 241 3569 or by email to epurchasing.servicedesk.uk@capgemini.com. Once a Trading Partner has successfully undergone the validation testing for connection to epurchasing and been declared P2P Ready, the responsibility for ensuring continuing compatibility with epurchasing rests with the Trading Partner. If, as a result of changes made to its systems, the Trading Partner wishes to repeat the epurchasing Trading Partner Validation Testing, the Trading Partner may be expected to bear the costs of such tests. 6.2. Security Procedures & Services The d2btrade.com website describes the security measures built-in to epurchasing and specifies the general security obligations upon the Trading Partner. This section sets out additional information and technical requirements. Trading Partners are strongly recommended to apply the Security Controls specified in ISO 27001 to ensure that their systems are not misused in a manner which could disrupt, or attempt to disrupt the provision of the epurchasing service. In particular, industry best practices should be adopted to ensure that: All messages destined for epurchasing are free of viruses Any systems connecting directly to epurchasing via the Internet are secured from the Internet by the use of firewalls and other devices installed to industry best practice. No attempt is made to connect to systems or services within the epurchasing infrastructure other than those agreed to when establishing the connection. 33

6.3. Message Processing Trading Partners should check for and process messages from epurchasing in a timely fashion. Where response times are defined in business agreements between the parties (i.e. MOD and Trading Partners) these will take precedence. However, as a minimum, it is recommended that epurchasing messages should be processed at least once per day, Monday-Friday. 6.4. Exception Handling 6.4.1 Notification The Capgemini Service Desk should be contacted by a Trading Partner experiencing an exceptional interruption to normal service including, for example: Significant hardware, software, system or network failures Failures of third party services used by the Trading Partner (e.g. VANs, Internet Service Providers) Loss or corruption of data Security breach Denial of service attack Virus infection Similarly, Trading Partners will be informed of any exceptional interruptions to the epurchasing services either via details published on the epurchasing website at www.d2btrade.com and/or direct communications (email or telephone) with the Trading Partner contacts nominated during the epurchasing registration process. 6.4.2 Recovery and Contingency Arrangements Comprehensive recovery and contingency processes have been developed for the epurchasing environment, to address potential failure of any of the epurchasing components. However, certain failure scenarios could result in the following occurrences: Duplicate messages sent from epurchasing. Trading Partner systems and processes should be capable of recognising a duplicate message (e.g. Purchase Order) and handling this in an appropriate fashion. Requests for re-transmission of messages to epurchasing. Trading Partners may be asked to re-transmit messages to epurchasing. Trading Partners should ensure that copies of sent messages are retained in a manner that allows re-transmission. Trading Partners should ensure that they have recovery and contingency processes in place for their interactions with epurchasing. epurchasing is capable of recognising and processing duplicate messages received from Trading Partners. If a Trading Partner requires a message to be re-sent from epurchasing, this can be requested by logging a call with the Capgemini Service Desk. 34

APPENDICES 35

Appendix A: General EDI Interchange Handling Requirements This section sets out the specifications for certain technical and procedural requirements for use of the P2P service. EDI Message Standards epurchasing uses the UN/EDIFACT standards for electronic data interchange with P2P. EDIFACT Directories The UN/EDIFACT directories used are Version D, Release 99B and Release 02B. Syntax and Character Set The application-level syntax is the EDIFACT default level A (UNOA) version 1. However, note that epurchasing additionally supports (and will send) both UPPERCASE and lowercase character sets. The case in which a field is sent can be significant The following characters are reserved for use as control characters within the UNOA character set and their use in data elements should be avoided if possible. If their use within data cannot be avoided, the Question Mark (?) character can be used to escape any separators that are part of the UNOA character set. (Apostrophe) segment terminator + (Plus sign) segment tag and data element separator : (Colon) sub-element separator? (Question mark) release character 36

Message Set The following messages are used. Refer to the relevant Message Implementation Guide for full definitions of the usage of each message. P2P Document EDIFACT Message Type Message Implementation Guideline Purchase Order ORDERS 1287_ePurchasing_P2P EDIFACT ORDERS Message Implementation Guide Order Acknowledgement ORDRSP 1290_ePurchasing_P2P EDIFACT ORDRSP Message Implementation Guide Purchase Order Amendment ORDCHG 1288_ePurchasing_P2P EDIFACT ORDCHG Message Implementation Guide Advance Shipment Notice DESADV 2212_ePurchasing_P2P EDIFACT DESADV Message Implementation Guide Invoice INVOIC 1289_ePurchasing_P2P EDIFACT INVOIC Message Implementation Guide Request for Quote REQOTE 2216_ePurchasing_P2P EDIFACT REQOTE Message Implementation Guide Quote QUOTES 2217_ePurchasing_P2P EDIFACT QUOTES Message Implementation Guide EDIFACT Envelope Interchange envelopes (also known as Service Segments) enclose all EDIFACT data segments being sent to the same destination. The envelope contains the identity and electronic mailbox address of the sender and the receiver and holds a count of the number of transactions taking place. The P2P interchange does not handle combinations of messages from a Trading Partner within an EDIFACT envelope. Individual files must be created i.e. one for invoices and another for order acknowledgements, for each party the messages are to be sent to. Refer to the P2P EDIFACT envelope specification for full implementation details see document 1291_ePurchasing_P2P EDIFACT Envelope Specification. EDI Address Both epurchasing and Trading Partners are required to supply an Interchange Identifier or EDI identifier which uniquely addresses their particular organisation, and optionally, a specific system within the organisation. If connecting over a VAN, the VAN provider can issue the EDI identifier to the Trading Partner. Existing VAN users will use their existing identifier. It is also possible for both parties to mutually define their own named ID to represent themselves. This would apply for Trading Partners not using a VAN (i.e. connecting via the Internet) or if for some reason the VAN provider is unable to provide the identifier. 37

P2P Purchase Orders and Purchase Order Amendments will include a routing address or sub-address element (EDIFACT composite/element S002/0008). Return messages sent to epurchasing by the Trading Partner must include the same routing address or sub-address. Refer to the P2P EDIFACT envelope specification for full details of the identifiers used and required see document 1291_ePurchasing_P2P EDIFACT Envelope Specification. Further Information For general information on the EDIFACT standard message types, refer to the United Nations Directories For Electronic Data Interchange For Administration, Commerce And Transport, which can be found at http://www.unece.org/trade/untdid/. 38

Appendix B: General XML Interchange Handling Requirements This section sets out the specifications for certain technical and procedural requirements for use of the P2P service using XML. XML Message Standards epurchasing uses the OAGIS v9 XML standards for electronic data interchange with P2P. Message Set The following messages are used. Refer to the relevant Message Implementation Guide for full definitions of the usage of each message. P2P Document Purchase Order Purchase Order Amendment XML Message Type ORDERS ORDCHG Message Implementation Guideline 2329_ePurchasing_P2P Order OAGIS v9 Message Implementation Guide.doc Order Acknowledgement ORDRSP 2327_ePurchasing_P2P Order Acknowledgement OAGIS v9 Message Implementation Guide.doc Advance Shipment Notice DESADV 2326_ePurchasing_P2P Advance Shipment Notification OAGIS v9 Message Implementation Guide.doc Invoice INVOIC 2328_ePurchasing_P2P Invoice OAGIS v9 Message Implementation Guide.doc Request for Quote REQOTE 2330_ePurchasing_P2P RFQ OAGIS v9 Message Implementation Guide.doc Quote QUOTES 2331_ePurchasing_P2P Quotation OAGIS v9 Message Implementation Guide.doc XML Envelope All OAGIS v9 XML messages must contain a header (or envelope) known as the Application Area, which directly precedes the message content (known as the Data Area). Refer to the P2P XML envelope specification for full implementation details see document: 2332 _epurchasing_p2p Envelope OAGIS v9 Message Implementation Guide.doc Further Information For general information on the OAGIS standard message types, refer to http://www.openapplications.org/global/intro.htm 39

Appendix C: Glossary The following is a list of the terms, acronyms and abbreviations relevant to this document: Phrase Description 24 x 365 24 hours, 365 days of the year ADMD Administration Management Domain. X.400 Message Handling System public service carrier identifier. ASN Advance Shipment Notice BOD Business Object Document CNAC Contractor s Name and Address Code CRISP Comprehensive RNSTS Inventory Systems Project Fleet environment Inventory Management System CPV Common Procurement Vocabulary. This is a standard categorisation of goods and services being introduced for EU wide Public Procurement DBS finance An Agency of the MOD responsible for the payment of bills to defence contractors. EDI Electronic Data Interchange - The exchange of standardised document forms between computer systems for business use. EDIFACT Electronic Data Interchange for Administration, Commerce and Transport UN standards for EDI epurchasing The Electronic Purchasing service EMS Electronic Messaging Service ERP Enterprise Resource Planning - Any software system designed to support and automate the business processes of medium and large businesses. This may include manufacturing, distribution, personnel, project management, payroll, and financials. FTP File Transfer Protocol - A client-server protocol which allows a user on one computer to transfer files to and from another computer over a TCP/IP network. GAX (code & DBA Contractor Code and Address Code required on all electronic suffix) invoices. This will be given to suppliers by the MOD as part of the P2P take-on process. GS IPT General Stores Integrated Project Team Formerly known as the NPPO (Non Project Procurement Office) HTTP Hyper Text Transport Protocol - The client-server TCP/IP protocol used on the World-Wide Web for the exchange of HTML documents. IAC Internal Account Code INVENTORY Refers to goods supplied using NATO stock numbers. IP Interim Purchasing IPV Industry Prime Vendors P2P Purchase 2 Payment ISP Internet Service Provider JIGSAW Joint Implementation Group for Systematic Automation of Work MIG Message Implementation Guide detailed technical specifications of the EDIFACT messages used to trade with P2P 40

MIME MOD MTA NCAGE NEDI NPPO NIIN NSN OAGi OAGIS PRMD PPQ RLI SIG S/MIME SCCS SMI SMTP SS3 SSL TP UIN URRI VAN XML Multipurpose Internet Mail Extensions - A standard for multi-part, multimedia electronic mail messages and World-Wide Web hypertext documents on the Internet. Ministry of Defence Message Transfer Agent. The program responsible for delivering e-mail messages. Upon receiving a message from a Mail User Agent or another MTA it stores it temporarily locally and analyses the recipients and either delivers it (local addressee) or forwards it to another MTA (routing). In either case it may edit and/or add to the message headers NATO Commercial or Government Entity this code uniquely identifies the name and location of each supplier site (supersedes CNAC codification of Customer Name and Addresses) Naval Electronic Data Interchange Non Project Procurement Office NATO Item Identification Number. This is the NC/IIN section of the NSN, 9 characters, and is used as the item identifier in P2P. NATO Stock Number. Thirteen digit concatenated code (comprising NSC/NC/IIN) which uniquely identifies a particular item in the inventory and the nation which codified it. Open Applications Group Inc. Open Applications Group Integration Specification Primary management domain. The component of an X.400 electronic mail address that gives the organisation name Primary Packaged Quantity Restricted LAN Interconnect Service Implementation Guide this document is the P2P SIG. Secure Multipurpose Internet Mail Extensions - A specification for secure electronic mail. S-MIME was designed to add security to e-mail messages in MIME format. The security services offered are authentication (using digital signatures) and privacy (using encryption). Supply Central Computer System Strike (Air) environment Inventory Management System Secure Managed Interconnect - a gateway that provides access to the RLI Simple Mail Transfer Protocol - A protocol used to transfer electronic mail between computers. Stores System 3 Land environment Inventory Management System Secure Sockets Layer - A protocol designed to provide encrypted communications on the Internet. Trading Partner. A supplier connected to epurchasing and ready to trade electronically with the MOD is known as a Trading Partner. Unit Identification Number. Code by which a unit is designated for computer and accounting purposes. Unique Receipt Reference Identifier Value Added Network Extensible Mark-up Language 41

Appendix D: Document Control External Version History Version Date Comments 0.5 23 Apr 2002 First Issue with caveats re. P2P security classification 1.4 31 July 2002 Incorporated changes for DECS Purchasing Portal, Shipping Label, Exostar 1.5 12 May 2003 Incorporate changes relating to DEFFORM30 1.6 30 June 2003 Incorporates changes for RLI connectivity via SMTP and DECS Purchasing Portal. 2.0 10 July 2003 Incorporate changes following MOD internal review of the SIG on 2 nd July 2003. 2.1 15 April 2004 Updated for Capgemini company name change 2.2 3 May 2004 Updated to include reference to catalogues. 5.0 18 Nov 2004 Generally reviewed and updated. Re-versioned for sign-off and publication on d2btrade.com 6.0 4 April 2006 Reviewed and updated to reflect new P2P message set and generally refresh content 7.0 2 nd Oct 2007 Reviewed and updated for compatibility with P2P MIG 201 ( Inventory Ready P2P messages). References to IP (Interim Purchasing) removed. DECS Purchasing Portal connectivity via PKI and RLI removed. RLI SMTP messaging connectivity option removed. References to DBA amended to DGFM Exostar SupplyPass migration to SCP reflected. Kewill plc no longer referenced as they no longer provide a P2P compatible product 7.1 December 2008 Addition of HTTPS XML connectivity Removal of Exostar Supplypass Update to Delivery Label 8.0 January 2009 Document released under CHMN00025839990, with advised amendments. 9.0 July 2013 Amended in line with service change from DECS to epurchasing. Also updated details about DEFORM30s. Changed phone number for DGFM. Changed MIG version numbers from 301 to 302. Updated additional areas in line with current processes. Removed details on previous message sets. Changed Service desk name and email address. 42

9.1 April 2015 Change of contact details for Gax codes, removal of machine link. Change of name from DGFM to DBS finance. 9.2 July 2015 Removal of any reference to Requisite. Document Distribution Name Location Responsibility Tony Cole Capgemini Toltec epurchasing Service Delivery Manager Alison Holvey Capgemini Toltec Supplier Services Manager Capgemini Capgemini Toltec Trading Partner Take on Team Document Reviewed By Name Location Responsibility Sarah Nunn Capgemini Toltec Trading Partner Take on Team Leader Source File Location epurchasing 1407_ePurchasing_P2P Service Implementation Guide.doc 43