Scenario 39 - Request for Quote and Quote Exchange

39.0 Overview

Scenario #39 describes the integration for business software 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 general ledger applications to a budget 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 components involved with the distribution of RFQs and Quotes are:

  • Engineering Product Data Management
  • Purchasing / Procurement
  • Order Management
  • Sales Force Automation

This is not a complete list but is meant to be a representative sample of activities that generate data involved with the RequestForQuote/Quote process.

39.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.

39.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 components integrating with another purchasing or sales order management component. 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’s application.

39.3 Participant Definitions

This scenario contains two major components: the purchasing or procurement component of the buyer and the sales order management component of the supplier.

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.

Note that 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.

39.4 Business Workflow (Sequence)

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

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.

39.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.