Welcome to Internet Parts Ordering! By implementing the IPO standards, your company will join a broad industry coalition that is working to improve the speed and efficiency of the automotive aftermarket.

This Web page was developed to assist companies wanting to create an electronic ordering mechanism with their suppliers and customers. It describes Internet Parts Ordering (IPO) standards, developed under the direction of the Automotive Aftermarket Industry Association (AAIA) to promote electronic commerce between participants in the automotive aftermarket.

For implementer support, discussion forums, education, testing facilities and downloads of the IPO standard please navigate to www.ipoportal.com. Registration is required for access to the support
portions of the IPO Portal.

The following Resources are available from this page:

• Related Resources
• IPO Process Overview
• Business Object Document (BOD) Basics
• IPO Web Services  

This page addresses functional considerations and, as such, is written for these audiences:

IT project managers who will lead and coordinate implementation efforts
• Software solution providers who can assist with integration into back-end computer systems, e.g., quoting and purchase-order processing, sales-order and invoice processing, and shipment applications.
• Business managers within your company who can prioritize which features are necessary for an effective electronic exchange
• Business managers at your customers and/or suppliers who can provide information on the capabilities of their back-end computer systems
• IT architects and developers who will implement these standards

Herein you will find descriptions of the "public" processes between business partners as well as the details of the electronic documents that are exchanged between buyer and seller.  The IPO specification does not address the internal integration with back-end applications that is required for successful implementation.

How This Standard Was Developed
The Electronic Commerce Committee of the Automotive Aftermarket Industry Association develops standards and best practices to lower costs throughout the aftermarket and increase the efficiency of supply chain technology. The committee recognized that part availability inquiries and associated special order transactions occurred many thousands of times each day at all levels of the aftermarket. These transactions were conducted by phone, fax and a growing number of negotiated electronic transaction formats.

In the interest of providing an open industry guideline for this business process the AAIA committee identified Internet Parts Ordering as a project in the fall of 2002 and a workgroup was formed from interested parties. The Internet parts ordering standards in this document were developed with broad industry participation from representatives of:

• Manufacturers including ArvinMeritor, Dana Corporation, Gates Corporation, Global Accessories (formerly Saddleman), and Hunter Engineering;
• Distributors and retailers including Advance Auto Parts, CARQUEST Auto Parts, CSK Auto (which also does business under the Checker, Schuck�s, and Kragen brands), Genuine Parts Company, and O�Reilly Auto Parts;
• Software providers including ALLDATA, BayMaster, GarageOperator, and Wrenchead.

After thorough exploration of alternatives, this group decided to base the AAIA standards upon those developed by the Open Applications Group Incorporated (OAGI). OAGI is a not-for-profit industry consortium whose purpose is to promote interoperability among business software applications through a standardized data exchange methodology. Some advantages of using OAGI�s proven methodology are:

• High re-use, i.e., less �reinventing the wheel�
• Faster development
• Smaller learning curve
• High consistency among business partners of architecture and terminology

OAGI�s standards have found international acceptance in a variety of industries. The STAR (Standards for Technology in Automotive Retail) interchange methodology supported by automotive OEMs, new-car dealers, and providers of dealer management systems is among those based upon OAGI�s work.

AAIA has selected Web Services as its implementation framework, in other words, the technical mechanisms for transporting, securing and describing the IPO interactions. For more information about the Implementation Framework, see the IPO Technical Implementation Guide document. 1.3.

Related Resources
In addition to this document, readers may wish to consult the following:

• Web services interoperability documents located http://www.ws-i.org/ Use cases, sample architecture, and implementation tools are among the documents available.
• Formatting guidelines published by the World Wide Web Consortium, which may be found at http://www.w3c.org/
• OAGIS 8.0 specifications, which includes documentation and samples of XML, XML Schema, and XSL. They may be found at http://www.openapplications.org/downloads/oagidownloads.htm
• STAR data transfer specifications, which may be found at http://www.starstandard.org/sigs/dts/default.cfm

While the OAGI and STAR documents may be of general interest, please note that the standards contained in this and related AAIA documents should be used without modification. Otherwise, interoperability with other members of the automotive aftermarket will not occur.  View a Presentation on Internet Parts Ordering Update for the OAG.

Process Overview
At the highest level, ordering a part requires a series of conversations between buyer and seller. Typically, these conversations involve the exchange of written documents such as a quote, a purchase order, or an advance shipment notification. Internet parts ordering replicates this familiar process, but eliminates much manual keying and review for both buyer and seller.  

Figure 1: Physical parts flow in the aftermarket

Within the automotive aftermarket supply chain, manufacturers may act in two capacities, selling to the distribution channel and buying from component suppliers.  Distributors, jobbers, and retailers also act as both buyers and sellers.  Installers act only as buyers, since vehicle owners are not considered part of the supply chain.

In the non-electronic world, the document exchange between buyer and seller progresses through these stages:

In the world of Internet Parts Ordering, the same process occurs.  However, each part of the conversation is represented by an electronic document known as a BOD (Business Object Document).  In Figure 2 below, each arrow is a BOD.

Figure 2: High-level view of Internet Parts Ordering                            

The actual set of BODs used for Internet Parts Ordering, as well as their interaction, is a little more complicated and will be described later in more detail.

Business Object Document (BOD) Basics
BODs (Business Object Documents) are the messages that exchange data between applications and companies. The BOD provides a common architecture that bridges different software providers, different companies, even different industries. The BOD contains the business content � the purchase order, for example �and is independent of the communication mechanism. As such, a single BOD standard can be used with various types of transport protocols such as SOAP and ebXML. IPO has selected a Web Service Implementation framework that uses SOAP messaging.

All BODs have two high-level parts: the Application Area and the Data Area. The Application Area contains information that can be used by the infrastructure to communicate the message. This includes information about the sender with authentication through a digital signature if desired, the date and time of creation, and information about the destination or recipient.

Information within a BOD is represented in eXtensible Markup Language, or XML. In XML, data elements are enclosed by a beginning tag that looks like <TagName> and an ending tag name that looks like </TagName> . Careful selection of tag names makes the message self-describing: The list price of an item, for example, could be tagged as <ListPrice> while the distributor price could be tagged as < DistributorPrice > .  

Individual data elements can be (and typically are) nested to form a hierarchy, so that a data element contains other data elements. A data element�s position within a hierarchy helps describe its meaning. Seeing <Model> contained within <Vehicle>, we would expect to see information such as �Monte Carlo� or �Tahoe�. Seeing <Model> contained within <Fashion> , we would expect information such �Claudia Schiffer�.

In a BOD, the set of information about an automobile might look like this:
 

Some data elements have �attributes� that provide supplementary information about their contents. In the illustration above, an attribute of <Displacement> tells us in the units of measure for the displacement data provided.

A BOD�s Data Area is made up of the Verb and Noun. The Verb identifies the action being performed, e.g., Add, Change, Cancel. The Noun � e.g., PurchaseOrder, Quote � contains the specific business data that are being acted upon, such as purchase order number, the parts being ordered, when delivery is expected, and so on.

The information in a Noun, in turn, generally is organized into Components such as Header and Line, as shown in Figure 3. The components allow us to organize the required data into logical groups. For example, the <Vehicle>component above groups all information requirements for describing a vehicle; a component named <OrderItem>could contain all information about an item being ordered, such as manufacturer, part number, description, warranty and so on. Certain components, such as a PurchaseOrder Line, may be repeated multiple times within a single BOD. Components may contain other components, just as <Vehicle>contains <Engine>in the preceding illustration. The actual business data are stored in Fields, such as <Year>.

The contents of a particular Noun will vary with the Verb. For example, to Add (i.e., create) a PurchaseOrder you would need to list all the items you want to buy and the prices you expect to pay. To Cancel a PurchaseOrder, you might need to include only the number of the purchase order being cancelled.

Figure 3: Block diagram of a Business Object Document  

From Document Exchange to Service Oriented Architecture
Traditional Business-to-Business (B2B) standards have focused on the exchange of documents between trading partners without focusing on the service that will process the document. Messages are passed from one trading partner to another with the expectation that each partner will have a B2B gateway that will examine each incoming document and determine what kind of processing is required.

IPO on the other hand, implements a service oriented architecture (SOA) based on web services. In fact a service oriented architecture (SOA) turns the paradigm around, making the service and operation the most important aspect and the messages exchanged an attribute.

IPO has used a methodology which identifies the services that sellers and buyers must implement. In web services model, a service comprises multiple related operations Figure 4 shows the relationship between the Web service � called IPOWebService and the operations that the Web Service exposes � Quote, CreatePurchaseOrder and ChangePurchaseOrder.

Figure 4 - IPO Web Service Legend

The messages that the operations process are indicated with labeled arrows � For example, the Quote Operation accepts a request message: Add RequestForQuote and produces a response message: Add Quote.

In the OAGIS methodology, the Verb (Add for example), is intended to help the receiver determine how to process the noun (RequestForQuote). However, in a Web service implementation, the Web service name (Internet Parts Order), describes the type of services offered, and the operation name (ChangePurchaseOrder for example) defines the type of functionality exposed. The verbs in the messages, (OAG BODs) need not be relied upon to help the receiver understand how to process the message. It is implicit in that the client has called a specific operation on a Web service and must pass the predetermined request message otherwise the operation will reject the request.