 |
|
|
Abstract
This paper describes the development of the functional specification for messages needed to support e-procurement interoperability across the UK public sector. The scope of the project is the procurement cycle from first enquiry to payment, between government buyers and third party suppliers. The methodology is based on the Office of the e-Envoy's e-service development framework, using a single UML model. The use of a single model has ensured coherence, while allowing the domain to be partitioned vertically using packages and horizontally by use cases. Packages include party, document, line, item and financial. 15 transactions (use cases) have been defined. This process-driven approach, covering the whole procurement cycle from beginning to end is somewhat different from other efforts which have focussed primarily on particular transactions such as purchase orders or invoicing. The use of a single model ensures a coherent structure that is necessary to support the re-use of data throughout the procurement cycle, such as the three-way match between purchase order, fulfillment notification and invoice, before authorising payment. Automating the three-way match, which is the core role of the accounts payable section, is one of the keys to realising productivity benefits for the buyer organisation. The overall specification is comprehensive, but a simple sub-set - "vanilla" purchase order and invoice - has been developed to meet the minimum needs of public sector buyers.
Keywords
Table of Contents
This paper describes the development of the functional specification for messages (schema) required to support e-procurement interoperability across the UK public sector.
The specification supports several key UK Government initiatives, including:
a ministerial level aspiration for the UK to be the best place to do e-business;
a target of 100 per cent of Government interactions with businesses and citizens to be available electronically by 2005;
the generation of efficiency savings as set out in the Review of Civil Procurement in Central Government chaired by Peter Gershon, April 1999; this Review set a target of £1 billion in savings, based on an estimated total annual expenditure in excess of £12.9 billion across Central Civil Government. The potential savings in local government and the NHS are of the same order of magnitude.
The greatest potential offered by the specification lies in the automation of purchasing, sales and accounting processes through standardising message content and, thereby, requiring manual intervention only for business reasons. One important example of automation is the three-way match between Purchase Order, Goods Receipt and Invoice; automating this back-office function is key to realising productivity benefits and reducing the costs of procurement for the buyer organisation, and to Government's paying suppliers on time.
The requirements and specification have been developed using a single UML (unified modelling language) model. Each message is one view of the underlying model. This use of a single model is in line with the Model Driven Architecture (MDA) approach advocated by, among others, the Object Management Group (OMG). A key benefit of using a single model is that it guarantees consistency and coherence.
This development of the requirements and specification has been undertaken within the Office of Government Commerce (OGC) e-Commerce team, reporting to a joint OGC / Office of the e-Envoy (OeE) eProcurement Interoperability Working Group. A working group compiled the basic requirements with representation from the cross-Government Purchasing community including local authorities and the NHS. These requirements have been refined through public consultation on GovTalk and meetings with IT suppliers and experts involved in relevant international standards and trade associations.
The methodology employed is based on the Office of the e-Envoy's e-Service Development Framework (eSDF) http://www.govtalk.gov.uk/interoperability/eservices_document2.asp?docnum=497, using a single UML model, developed using Poseidon for UML http://www.gentleware.com The use of a single model ensures coherence, while allowing the domain to be partitioned vertically using packages and horizontally by use cases.
The first step in the development process was to determine the scope of the project. The scope covers the entire procurement cycle, adopting a process-driven approach. This approach differs significantly from other efforts that have focussed on specific messages (or use cases), such as Purchase Orders or Invoices.
The second step in the process was to develop detailed storyboards with domain experts. These storyboards describe realistic situations in detail, covering instances when things go wrong as well as success scenarios. A dozen narrative storyboards were developed into activity diagrams.
The domain was analysed using the headings of the Government Common Information Model (GCIM), which has the following headings:
Service Interactions - user goal level use cases (e.g. Purchase Order);
Subject - the entities (parties, roles and objects) involved
Location - all of the possible origins and destinations of information and/or goods;
Identifiers - unique identifiers of Parties, Documents, goods etc.;
Evidence - information that needs to be available before a message is sent;
Outcome - the possible results of each transaction;
Rules - business, legal and tax rules that apply.
This check list was found to be helpful in eliciting and structuring information from domain experts and led into the development of a detailed process model, illustrated by an activity diagram of the entire eProcurement cycle.
Fifteen different types of Document were identified in the purchasing cycle. These are:
Catalogue Update;
Request for Quotation (RFQ);
Quotation;
Draft Supply Requisition;
Purchase Order (including 'vanilla' Purchase Order - see below);
PO Response;
Fulfilment Notification (despatch and/or delivery note);
Receipt Notification;
Rectification Note;
Invoice (including 'vanilla' Invoice - see below);
Invoice Response;
Debit Note;
Credit Note;
Remittance Advice;
Statement.
The next stage was the development of a static model (using class diagrams) of the content for the whole domain with each message as a separate diagram. The single UML model for the whole eProcurement domain provides a unified structure by which the re-use of data throughout the procurement cycle is supported.
Each Document contains one or more Lines; every Line has a Line Number. The combination of Document identifier and Line Number uniquely identifies a specific Line on a specific Document, and serves as a cross-reference point between Documents.
Links between Documents, such as relating an Invoice to a Purchase Order, are handled at the Line level. For example, an Invoice Line should relate to a single Purchase Order Line; note that one Purchase Order Line can be referenced more than once. Two exceptions to this rule are the Remittance Advice and Statement. Only in these Documents do their associated Lines refer to other Documents at Document level e.g. a Line on a Remittance Advice refers to a complete Invoice (rather than a single Invoice Line). Sub-lines are not supported; this is to simplify automated processing.
Most Documents contain Item Lines that refer to items of goods or service being purchased. Every Line has a Line Number, a quantity (qualified by a quantity unit) and a status. Each Line relates to a single type of Item.
Item includes information about products, goods and services. It contains information about the category of Item, including Item Name, Item Description, Item Quantity Units and Commodity Class. Item may include an Item Price, any number of Item IDs, Aspect and Instance.
Items can be identified by a Global Trade Identification Number (GTIN) according to EAN/UCC specifications.
All Items must have an approved commodity code, such as the United Nations Standard Product and Service Code (UNSPSC). This is required for data mining and the provision of management information on procurement activity within Government Departments and across the public sector.
The specification provides for information about a particular instance of an Item supplied including serial number, batch number, supplier reference, registration number, date of manufacture, date of registration and date of expiry.
In some cases the Item ID represents the "part number" of the item, such as a catalogue number, a suppliers part number or an Original Equipment Manufacturer's reference. Item ID includes strings for the identifier itself and for its source.
eProcurement is a process or cycle beginning with the identification of the goods or services needed to meet a demand and ending with final payment for the provision of the same. The two most important messages in this process are the Purchase Order and the Invoice. It is envisaged that these two messages will be the first to be adopted by the procurement community and that others will follow incrementally.
In recognition of this, simplified message specifications (referred to here as 'vanilla' messages) have been developed; these cater for the most basic public sector eProcurement requirements as regard Purchase Order and Invoice. The 'vanilla' messages are incorporated within the unified model at package level for consistency and ease of maintenance.
This summary of requirements focuses on these simplified specifications, rather than the more complex requirements of the entire model, which has been fully defined.
Diagram Figure 1 shows the top-level structure of the model.
The next two diagrams illustrate the UML class diagrams for the 'vanilla' Purchase Order Figure 2 and 'vanilla' Invoice Figure 3 .
Readers who are unfamiliar with UML should note that each diagram is best read by following the arrows, from Document (Purchase Order or Invoice) outwards. Two principal types of UML arrows are used:
association - diamonds at one end and navigation arrows (open) at the other. Associations indicate that the class at the diamond end contains the properties of each class at the arrow end e.g. Purchase Order includes Purchase Order ID
specialisation - triangles at one end and nothing at the other. Specialisation indicates that the class at the triangle end is specialisation of the class at the blank end e.g. in Figure 2, the Purchase Order ID is a specialisation of Document ID and inherits all of its properties, such as the attributes documentID, documentDate, documentStatus and GUID (globally unique identifier).
Optionality is indicated by numbers in brackets e.g. (0..1) indicates that an item need not be present but, if it is, there must only be one. If optionality is not shown, the item is mandatory.
This summary of requirements is Document-centric. The focus is on the specification of the functional requirements for Documents that are exchanged between buyer and supplier. Internal processes within the buyer and supplier organisations are out of scope.
All Documents must be explicitly identified with a Document identifier, date and status (e.g. 'original', 'copy' or 'test') and include details of the sender and intended recipient. Documents also contain a number of optional data elements, including a Document note, reference to a framework agreement (contract) and terms and conditions.
There is a requirement to include a wide range of "non-standard" information, which cannot safely be processed by computer by both sender and receiver systems. This data may be exchanged in human-readable format in Document and Line note fields.
One of the complexities of the purchasing cycle is that Documents do not have a simple one-to-one relationship with each other. For example, a single Purchase Order may give rise to more than one delivery and Invoice. Similarly, a supplier may consolidate several Purchase Orders into a single delivery and Invoice. Providing linkage between Documents at the Line level solves this many-to-many relationship between Documents and provides the potential to automate processes associating with matching Documents.
The 'vanilla' Documents do not support additional, structured, product specific data such as size, colour, weight and volume. This information can be added using attribute value combinations of aspect name, aspect value and aspect value unit.
Financial and tax information is required at both Document and Line levels. Document totals include Grand Total and Sub-total Attributes, currency information and one or more Tax Type Totals, and may include any number of Document Charge Discounts. The 'vanilla' Purchase Order and Invoice handle charges and discounts at the only at the Document level.
Line Values provide the Line level financial information including Extended Net and Gross Line Values, Extended Gross Line Value Currency information. Lines may also include Line Tax; Line Tax includes Tax Amount and Standard Tax Data (Tax Type, Tax Band and Tax Per Cent).
Every Document references two or more Parties; the sender and the receiver, one from the buyer side and one from the supplier side. Other Parties may also be referenced. Every Party has a name, and may have a number of optional attributes including:
shared, universally recognised identifiers such as the EAN/UCC GLN (Global Location Number);
the customer reference (allocated by the supplier) and the supplier reference (allocated by the buyer);
name;
electronic addresses - telephone (direct line, switchboard, fax and mobile) and email;
physical address;
registered office and tax (VAT) details
The specification makes extensive use of the concept of Role. A Role is a job carried out by a particular Party. One individual can carry out any number of Roles for either the buyer or the supplier or different people in different places may be represented by the appropriate Role at any given point in the purchasing cycle.
Buyer side Parties include:
Purchasing Manager; responsible for constructing framework agreements and maintaining or overseeing the maintenance of catalogue content subsequently made available to Originators and Order Points;
Originator; responsible for identifying demand and, where appropriate, creating a RFQ and internal requisitions leading to Purchase Order;
Order Point; responsible for the placing of the Purchase Order;
Delivery Point; responsible for processes relating to the acceptance or rejection of goods and services;
Invoice Point; responsible for buyer side financial and accounting processes.
Supplier side parties include:
Sales Point;responsible for all sales processes to the point of Purchase Order acceptance or rejection;
Despatch Point;responsible for dispatch of goods;
Customer Service; responsible for rectification of delivery errors;
Accounts Receivable; responsible for billing and supplier side accounting processes.
Third Parties include:
Carrier; a Party, neither the buyer nor supplier, responsible for physical delivery of goods;
EFT Address; details representing the buyer's or supplier's bank;
Factor; a Party appointed by the supplier to carry out Accounts Receivable functions.
As described above, a detailed UML model has been developed; the full model is available on http://www.govtalk.gov.uk.
The public sector has tens of thousands of ordering points, dealing with hundreds of thousands of suppliers. This is a many-to-many electronic data interchange (EDI) challenge on a huge scale. EDI requires senders and the receivers to interpret every data element in precisely the same way. Traditionally this has been achieved by representatives of the sender and the receiver coming to a unilateral agreement on how to achieve exact correspondence; but that approach is not scalable. The only practical way to achieve many-to-many communication is to specify messages precisely, with the absolute minimum of optionality.
Buyers and suppliers are expected to introduce these messages incrementally, starting with the Purchase Order or Invoice, and then adding additional services as required. This is an essential requirement. All messages, at every stage of the procurement cycle and at different levels of sophistication need to represent the same elements in precisely the same way.
The wide range of eProcurement scenarios cannot be covered by a single 'one-size-fits-all' specification; different 'flavours' will be needed. The term 'flavour' is used to describe different categories of requirement; the alternative term 'level' is not used because it implies a predefined hierarchy of complexity, which may not be stable. For example, international trade is not always more complex than domestic trade.
Examples of 'flavours' include:
vanilla;the simplest specification that meets the buyer requirements for automated processing for most straightforward transactions within the UK, with a single invoice point. This is the focus of initial implementation trials;
best practice - a specification that reflects best buying practice for most public sector requirements, including, for example, centralised ordering including multiple invoice points and multi-currency cross-border trade.
The overall specification is comprehensive, modular and extensible. It may be adopted in an incremental way; few users will want to implement all 15 types of message immediately.
The focus is on the information content of messages exchanged between buyers in the public sector and external suppliers, not on the internal processes at either buyer or supplier.
The messages will be implemented as electronic Documents, exchanged between buyer and supplier, marked-up using XML (extensible markup language) and validated using XML schema, as set out in the e-Government Interoperability Framework (e-GIF). Few assumptions are made (other than good business practice) about how either the buyer's or the supplier's internal systems are designed or work; they are 'black boxes'. However, care has been taken to ensure that the message data is structured in a way that facilitates automated electronic processing and, consequently, productivity benefits to buyers and suppliers. Full details of the specification and model are on http://www.govtalk.gov.uk
  |
Design & Development by deepX Ltd. |
