Scenario 40 - Request for Quote and Quote Exchange - Through an Intermediary

40.0 Overview

Scenario #40 describes the integration of business software components involved with the Request for Quote (RFQ) and Quote processes.

The purpose of this scenario is to enable the visualization of the participants in the process and the dialogs between them for this specific integration. This scenario is not meant to be the only model for integrating these applications. This is simply one model that may be used to guide one’s own integration efforts.

Many applications contribute to the generation of RFQs and the resulting quotes. Some that are involved with the distribution of RFQs and Quotes are:

  • Engineering product data management
  • Purchasing / Procurement
  • Order management
  • Sales force automation

40.1 Scenario Diagram

The scenario below contains the participants involved in the interaction, the dialog flows or conversation between them, certain assumptions about the sequence of events, and assumptions about the technical approach, for example, publish and subscribe.

This is a model to be used as a design recommendation, not a required approach.

40.2 Assumptions

This scenario assumes a loosely coupled, asynchronous approach with transaction management required but not explicitly defined.

This scenario describes a model for one or more purchasing software installations integrating with another purchasing or sales order management software. The environment for this integration may be with a single external organization or several external organizations. There may be instances where all of the data is contained in the documents and other instances where additional binary information accompanies the RequestForQuote and Quote documents.

This scenario assumes that the procurement / purchasing component owns the request definition and the instances of data within it. The release may be to a known set of partners, open to response from new partners or issued to an intermediary such an independent trading exchange.

This scenario does not cover the activity between the acceptance of a quote and the issuing of a purchase order.

Similarly, this scenario does not cover the activity between releasing the quote and generation of the sale order. Both activities are assumed to be supported by normal activity of a vendor application.

This scenario does not cover the framework for transmission of binary data documents between software components.

This scenario assumes that the details of these transfers are captured in the user definable sections or within vendor specific implementation of OAGIS.

40.3 Component Definitions

This Scenario contains two major participants, the purchasing or procurement application of the buyer and the sales order management application of the supplier.

The evolution of eCommerce has yielded independent trading exchanges and other intermediaries between buyers and suppliers. Requirements and operations for intermediaries should be similar to direct links between the two components.

The definitions and details of these applications are left to the designer but are assumed to contain the functionality as defined by what is commonly sold in the commercial market place today. This definition is broadly accepted by the scenario designers and is a direct result of the decision not to define how the processing takes place within any individual application.

Each application must be able perform the services defined by the message BOD (business object document), but the internals of the application are not required or desired to be exposed at this level of standardized abstraction.

The most important factors in defining these participants is to ensure that an integration designer can communicate the requirements precisely enough to detail the interfaces needed and their interrelationships.

40.4 Business Workflow (Sequence)

The business workflow is graphically represented by starting at the Scenario top and reading from top down and from left to right.

The exchange of RequestForQuotes and Quotes may follow several different workflows. The process depends on the type of product or products involved and the entities exchanging the documents. The diagram below illustrates the workflow stages involved with the RequestForQuote / Quote process.

To Do List

All workflows within the overall scenario have at least two major events in the workflow sequence. The diagram above illustrates the life cycle of the RequestForQuote / Quote process.

The Nomination and Preparation phases are sometimes merged into a single event. The Quote and Award phases may be merged as well.

  1. The first business event in the integration scenario is the request using the RequestForQuote document. This request may be followed by a period of supplier nomination or culling suppliers into a manageable short-list. Alternatively, suppliers may be known partners eliminating the need for the nomination phase. Within the RequestForQuote event, the sequence of events depends on the nature of the request and the type of partners involved.
  2. The second business event in the integration scenario is the response to the request from partners/suppliers in the form of a Quote. The quote usually matches the line items specified within RequestForQuote, but may not contain responses to every item. Following the quote delivery may be a period of negotiation or evaluation of supplier responses. A quote often represents a binding document that may change based on negotiations between the buyer or RequestForQuote owner and the seller responding to the RequestForQuote. These details of these negotiations should be captured for future reference.

These workflow sequences focus on the pre-purchase activity for:

  • Quantities of finished items, parts and/or materials
  • Custom, built-to-order items and/or materials
  • Use of an intermediary to manage the exchange activity for RequestForQuotes and Quotes

Quantities of Finished Items The workflow sequence for quantities of standard items involves the fewest BODs. The buyer focus involves finding the best price based on large quantities of individual items and/or aggregate items. BODs typically involved include:

  1. Add RequestForQuote releases a request to one or more partners providing deadlines for response and item details. ADD is used when the recipient takes ownership of the RequestForQuote source data. Sync RequestForQuote is used when the RequestForQuote data persists in multiple systems
  2. Add Quote response by a seller / supplier to one or more items detailed within an RequestForQuote. Sync Quote is used when the RequestForQuote data persists in multiple systems.
  3. Respond Quote a buyer may respond to the quote with questions or issues.
  4. Change Quote a supplier may alter a quote during negotiations in an effort to win the order.

The result of these activities would be a purchase order and sale order that are covered within other OAGIS Scenarios.

Custom, Built-To-Order Items The workflow sequence for custom, built to order involves more activity than that of finished goods. The buyer*s focus involves finding the best price for an item or quantity of items that are not currently available. A long-term business relationship is often involved leading to expectations that must be addressed within the quote. Customized products require a higher level of specification. Individual supplier inquiries may be answered formally for all participants to insure competitive parity. Conversely, buyers may have questions related to an individual quote that lead to a change. BODs typically involved include:

  1. Add / Sync RequestForQuote * releases a request to one or more partners providing deadlines for response and item details. Add is used when the recipient takes ownership of the RequestForQuote source data. Sync RequestForQuote is used when the RequestForQuote data persists in multiple systems.
  2. Respond RequestForQuote * suppliers respond with questions and/or clarification issues.
  3. Change RequestForQuote * a request is modified to include answers to questions or clarification of specifications.
  4. Add Quote * response by a seller / supplier to one or more items detailed within an RequestForQuote. Add Quote is used when the recipient takes ownership of the Quote source data. Sync Quote is used when the Quote data persists in multiple systems.
  5. Respond QUOTE * buyer response to an individual supplier with questions, clarifications or issues.
  6. Change Quote * a supplier may alter a quote during negotiations in an effort to win the order.

The result of these activities would be a purchase order and sale order that are covered within other OAGIS Scenarios.

Using Intermediaries To Manage RequestForQuote/Quote Exchange Activity Much of the additional activity follows from the aggregation provided by an intermediary. Multiple RequestForQuotes and quotes could reside with the intermediary. The process for both suppliers and buyers is similar but involves RequestForQuote or quotes respectively. The list below outlines the steps that may be involved.

  1. Supplier or buyer requests a list of documents - RequestForQuote or quote (GetList RequestForQuote)
  2. List is sent to the requester (List RequestForQuote)
  3. One of the items in the list is selected for review (Get RequestForQuote)
  4. The full RequestForQuote or quote is sent (Show RequestForQuote)
  5. The supplier or buyer sends questions or comments about the document (Respond RequestForQuote)
  6. Changes are made to the RequestForQuote document. (Change RequestForQuote)
  7. Process continues as noted for finished or custom goods and materials.
  8. Occasionally, business changes may require that the business process stop; the originator cancels the operation with the intermediary (Cancel RequestForQuote).

Note: Ending the RequestForQuote/Quote activity as part of its natural conclusion would be accomplished using the Change verb.

Additional BODs identified above include:

  1. Get RequestForQuote - a request for a RequestForQuote from a buyer or intermediary
  2. Show RequestForQuote - a RequestForQuote is sent in response to the GetRequest.
  3. GetList RequestForQuote - request for a list of RequestForQuotes
  4. List RequestForQuote - List of RequestForQuotes sent in response to - GetList request
  5. Get Quote - a request a Quote from a buyer or intermediary
  6. Show Quote - Quote is sent in response to the - GetRequest.
  7. GetList Quote - a request for a list of Quotes
  8. List Quote - a List of Quotes sent in response to GetListRequest
  9. Cancel Quote - eliminates the request from consideration

The result of these activities would be a purchase order and sale order that are covered within other OAGIS Scenarios.

40.5 Exception Handling

Exception handling is highly localized as the result of an implementation’s infrastructure, management and business rules. As such, this section of the Scenario documentation is planned to be used as a guide to help understand the additional intent of these Scenarios. If no exceptions are noted here, then it can be assumed that the Scenario designers agreed that the Scenario is straight forward and has no additional needs:

  • Note that the Confirm BOD is not shown in the scenario and that it is the most obvious method for providing an application level exception and feedback mechanism between business software components. Full Confirm BOD use is described in other OAGIS documentation in detail, but it should be noted that the specific use of the Confirm BOD may vary significantly from scenario to scenario and from integration to integration.

  • The Confirm BOD is typically intended to be used by the original receiving application to communicate to the sending application that the information it sent in the message BOD (business object document) was received and understood and can be processed.

  • If the information was not received or nor understood, or contained errors of any type, it is accepted practice for the OAGIS users to presume that the data was not acted on and in the absence of a Confirm BOD within a partnership previously agreed to time limit to resend the original message again.

  • As errors and assumptions are the bane of any implementation, it is strongly recommended that the Confirm BOD be used to prevent any potential problem although it is not a requirement by OAGIS use.

Feedback

OAGi and its members welcome your feedback.