Scenario 37 - Catalog and Price List Exchange

37.0 Overview

Scenario #37 describes the integration for order management, inventory control, catalog management and purchasing software.

The information flows can be viewed from the following three perspectives:

Catalog Publisher

The Catalog Publisher should be able to publish catalog information to a customer or agent including, but not limited to;

  • Description of Product or Service
  • Party Specific Part Identifiers, including:
    • Supplier’s Part Number
    • Manufacturer’s Part Number
    • Customer’s Part Number
  • Global Part Identifiers, including:
    • UPC Code
    • EAN Number
  • Part Classification, including;
    • EAN Number
    • Commodity Code
    • Hazard Class
    • Specifications:

For example, electrical test products might be specified by:

  • Accuracy ‘5% of reading’ 1 digit
  • Supply voltage 110/240V*10% 50/60Hz
  • Power consumption 10/220VA (excluding run test)
  • Pricing Information agreed on either: Purchase Agreements, Price Lists
  • Delivery Information
  • Related Items and Accessories
  • The degree to which any given piece of information is mandatory will be dependent of the subscriber.

Catalog Subscriber

The catalog subscriber should be able to subscribe to one, many or all updates to item information from a vendor agent or a vendor for a catalog or catalogs that they maintain.

Catalog Searcher

A Catalog Searcher should be able to request catalog information for a Part or service Identifier including:

  • Description of Product or Service
  • Party Specific Part Identifiers, including:
    • Supplier’s Part Number
    • Manufacturer’s Part Number
    • Customer’s Part Number
  • Global Part Identifiers, including:
    • UPC Code
    • EAN Number
  • Part Classification, including;
    • EAN Number
    • Commodity Code
    • Hazard Class
  • A list of products or services that:
    • Provide a given feature
    • Have specifications equal to, less then or greater than a given value
    • Have a specific range of values

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.

37.1 Scenario

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.

37.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 catalog components integrating with a procurement system.

The environment for this integration may be within a single enterprise, or across enterprises. There are many possible business applications in several environments that may use this capability. For example, a manufacturing, distributor, or reseller business application could use this to communicate requirements to synchronize a catalog. It may also be necessary to support component supplier management (CSM) scenarios. In such a scenario a company will provide a service of sourcing and codifying the products of many companies and publishing a consolidated catalog. A customer purchases the product from the catalog provider. They have the capability to do comparison shopping from the catalog. Supplier certification may be provided by the catalog provider.

37.3 Component Definitions

This scenario contains four major participants; order management, inventory control, catalog management, and a purchasing application.

The definitions of these components 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. The following assumptions are made regarding the components:

  • The order management application maintains item pricing information
  • The inventory system maintains the item masters of the existing inventory
  • The catalog management system application represents the catalog management system of the catalog provider
  • The purchasing application represents the purchasing system of a customer or a catalog subscriber

Additional 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 are to ensure that an integration designer can communicate the requirements precisely enough to detail the interfaces needed and their interrelationships.

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

This scenario contains the following events in the workflow sequence:

  1. Syncing of the item master data from the inventory system to all the other systems
  2. Syncing of the catalog between the order management and catalog systems
  3. Syncing of the pricing to the catalog system
  4. Show of both the catalog and the pricing to the purchasing system

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