Integration Scenarios

Introduction

This chapter depicts the sample integration scenarios that the content of the Open Applications Group Integration Specification (OAGIS) supports.  These scenarios are intended to be used as models for designing ones own solutions based on the integration content in OAGIS.  They are not meant to be used only as shown.

These models may be used as examples and modified for the specific needs of your organization.

Please Note:

Some of these integration scenarios have details concerning their workflow, assumptions, and exception requirements while others do not.  We are working to add these details quickly. 

If you have any questions concerning these or the use of them, please contact us at info@openapplications.org.  Thank you very much for your patience in this matter.

 


Integration Scenarios. 1

1.0 General Ledger to Sub-Ledger Scenario Description.. 6

2.0 General Ledger to Budget.. 10

3.0 Order Management to Accounts Receivable.. 11

4.0 Order Management to Accounts Receivable.. 12

5.0 Order Management to Accounts Receivable.. 13

6.0 Order Management to Accounts Receivable.. 14

7.0 Purchasing to Accounts Payable.. 15

8.0 Purchasing to Accounts Payable.. 16

9.0 Project Accounting Synchronization.. 17

10.0 Feeder Applications to Project Accounting.. 18

11.0 Human Resources Integration.. 19

12.0 Purchase Order Process. 20

13.0 Plant data Collection – Warehouse Management (Cycle Counts) 21

14.0 Plant Data Collection – Warehouse Management (Issues) 22

15.0 Plant Data Collection – Warehouse Management (Transfers) 23

16.0 Plant Data Collection – Warehouse Management (Receipts) 24

17.0 Plant Data Collection – Warehouse Management (Production Orders) 25

18.0 Plant Data Collection – Warehouse Management (Work in Process) 26

19.0 Plant Data Collection – Warehouse Management (Shipping) 27

20.0 Plant Data Collection – Warehouse Management (Time and Attendance) 28

21.0 Manufacturing to Purchasing – Receiving and Inspection in Manufacturing  (Publish/Subscribe Model) 29

22.0 Manufacturing to Purchasing – Receiving and Inspection in Manufacturing (Request/Replay and Publish/Subscribe) 30

23.0 Manufacturing to Purchasing – Receiving and Inspection in Purchasing (Publish/Subscribe) 31

24.0 Manufacturing to Purchasing – Receiving and Inspection in Purchasing (Request/Reply and Publish/Subscribe) 32

25.0 Manufacturing to Order Management – Financials with Logistics, (Make to Order, Build to order) 33

26.0 Manufacturing to Order Management – Financials with Logistics, (Engineer to Order, Configure to order) 34

27.0 Manufacturing to Order Management – Financials with Logistics, (Mixed Mode Manufacturing) 35

28.0 Manufacturing to Order Management – Financials with Manufacturing, (Make to Order, Build to Order) 36

29.0 Manufacturing to Order Management – Financials with Manufacturing, (Engineer to Order, Configure to Order) 37

30.0 Manufacturing to Order Management – Financials with Manufacturing, (Mixed Mode Manufacturing) 38

31.0 Invoice Matching, Matching in Purchasing, Invoices entered in Purchasing   39

32.0 Invoice Matching, Matching in Purchasing, Invoices entered in Accounts Payable (Publish/Subscribe) 40

33.0 Invoice Matching, Matching in Purchasing, Invoices entered in Accounts Payable (Request/Reply) 41

34.0 Invoice Matching, Matching in Accounts Payable, Invoices entered in Accounts Payable (Publish/Subscribe) 42

35.0 Invoice Matching, Matching in Accounts Payable, (Request/Reply) 43

36.0 Synchronize Sales Orders for Shipping.. 44

37.0 Sales Force Automation to Order Management, Updating orders in Order Management.. 45

38.0 Sales Force Automation to Order Management, Inquiring on orders in Order Management.. 46

39.0 Sales Force Automation to Order Management and Shipping.. 47

40.0 Supply Chain Integration, Manufacturing to Purchasing, Order Management, Billing, Shipping, and Financials. 48

41.0 Customer Service Integration, Field Service, No Returns. 49

42.0 Manufacturing to Order Management, Financials with Manufacturing, Make to Order with Credit Checking.. 50

43.0 Manufacturing to Purchasing, Receiving and Inspection in Manufacturing, Request/reply Model.. 51

44.0 Production Synchronization.. 52

45.0 Purchase Order Integration.. 53

46.0 Production Routing synchronization.. 54

47.0 Human Resources Integration.. 55

48.0 Hr to Time Data Collection.. 56

49.0 Engineering Changes Scenario Description.. 57

50.0 ERP to Finite Scheduling and Manufacturing Execution Scenario Description   62

51.0 Computerized Maintenance Management System (CMMS) to Field Devices  66

52.0 Catalog Exchange Scenario Description.. 67

53.0 PriceList Exchange Scenario Description.. 74

54.0 Item Unit-Of-Measure (UOM) Integration Scenario.. 79

55.0 Buyer and Supplier RFQ - Quote Scenario Description.. 89

56.0 Forecast Exchange Scenario Description - Revision 001. 98

57.0 Production to Manufacturing Execution Scenario Description   104

58.0 Supply Chain Execution Scenario Description.. 111

59.0 Ledger Actuals Scenario Description.. 115

60.0 Vendor Managed Inventory (Consumption) Scenario Description   119

61.0 Full Cycle Purchasing (non-production) 123




1.0 General Ledger to Sub-Ledger Scenario Description

1.0 Overview

This chapter describes the integration scenario for sub-ledger business software components to integrate with a general ledger business software component.

The purpose of this scenario is to enable the visualization of the components and the dialogs between components for this specific integration domain.  This scenario is not meant to be the only correct model for integrating sub-ledger components to a General Ledger business software component.  This is one model that may be used to design one’s own integration based on the specific needs of an organization or group of organizations. 

Many applications create data that cause changes in the account balances of a general ledger application.  Some components that have activity which will be reflected in a general ledger application are:

1.    Benefits

2.    Costing

3.    Human Resources

4.    Inventory Control

5.    Manufacturing

6.    Payroll

7.    Production

8.    Treasury

 

This is not a complete list but is meant to be a representative sample of activities that generate a journal entry.

1.1 Scenario Diagram

The scenario diagram below contains the components involved in the interaction, the dialog flows or conversation between the components, certain assumptions about the sequence of events, and assumptions about the technical approach, for example, publish and subscribe.  The next three sections will give a brief overview of the components, the sequence of events, and the environment. 

Again, this is a MODEL to be used as a reusable design document, not a required  approach.

1.2 Assumptions

This scenario assumes a loosely coupled, asynchronous approach to the integration.  Transaction management is implicitly required but not explicitly defined.

This scenario describes a model for one or more sub ledger components integrating with a common general ledger component.  The environment for this integration may be within a single enterprise, or across several divisions.  There may be instances where the amount of information sent to the general ledger is enough, and they may be times when the sub ledgers need to send the detail transaction data to a cost accounting component.

This scenario does not cover posting to a cost accounting component.  This scenario also assumes that the details of the financial transactions will be kept in the sub ledgers and the drill back mechanism from the general ledger component to the sub ledger components is described in the PostJournalEntry Business Object Document in chapter 1, section three of OAGIS.

1.3 Component Definitions

This scenario contains two major components, the general ledger component and the sub-ledger component.  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. 

This heuristic definition is broadly accepted by the designers of the integration scenario and is a direct decision not to define how the processing takes place within any individual component.  The component must be able perform the services defined by the business object document, but the internals of the component are not required or desired to be exposed.

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

1.4 Business Workflow (Sequence)

This scenario has two major events in the workflow sequence. 

1) The first business event in the sequence may be the synchronization of the financial chart of accounts.  This scenario assumes that the general ledger component “owns” the chart of accounts definition and the instances of data within it.  The sub ledger applications have several choices for validation of account numbers and other fields in the complete chart of accounts structure.  One of these choices is to synchronize the chart of accounts structure and data from the general ledger application to all of the sub ledgers.

The synchronization process can ensure that all of the components in the integration scenario will have the same data necessary to communicate.

NOTE:  This step is not required and some designers may choose to send the required information on the PostJournalEntry BOD without synchronizing before hand.  There are several ways to perform exception handling in this case and they will be described in the next section.

2) The second business event in the integration scenario is the posting process itself. this process flows in the direction of the general ledger component from the sub ledger components based any number of possible business event.  Some of these possible business events are described in the introduction to this scenario.

1.5 Exception Handling

This section is not intended to fully define the only acceptable methods for exception handling for this scenario.  It is intended to be used as a guide by the designer to understand the intent and think through the issues the creators of this model had in mind.

The Confirm BOD shown in the scenario is the most obvious method for providing an application level feedback mechanism between business software components.  This Confirm BOD is described in detail in section three, chapter two of OAGIS, however the specific use of the Confirm BOD may vary significantly from scenario to scenario.

The Confirm BOD in this scenario is intended to be used by the general ledger component to communicate to the sub ledger that the information it sent was received and understood.  If the information was not received or not understood, or contained errors of any type, the financial tracking for the organization may be incomplete or incorrect.

It is strongly recommended that the Confirm BOD is used in this scenario to prevent this potential problem.

2.0 General Ledger to Budget

 

 

 

 

 

 

 

 

 

3.0 Order Management to Accounts Receivable

 

 

 

 

 

 

 

4.0 Order Management to Accounts Receivable

 

 

 

 

 

 

5.0 Order Management to Accounts Receivable

 

 

 

6.0 Order Management to Accounts Receivable

 

 

 

7.0 Purchasing to Accounts Payable

 

 

 

 

 

 

8.0 Purchasing to Accounts Payable

 

 

 

 

 

9.0 Project Accounting Synchronization

 

10.0 Feeder Applications to Project Accounting

 

 

 

 

11.0 Human Resources Integration

 

 

 

12.0 Purchase Order Process

 

 

 

 

 

 

13.0 Plant data Collection – Warehouse Management (Cycle Counts)

 

14.0 Plant Data Collection – Warehouse Management (Issues)

 

 

 

15.0 Plant Data Collection – Warehouse Management (Transfers)

 

16.0 Plant Data Collection – Warehouse Management (Receipts)

 

 

 

17.0 Plant Data Collection – Warehouse Management
(Production Orders)

 

 

 

 

 

18.0 Plant Data Collection – Warehouse Management
(Work in Process)

 

 

 

19.0 Plant Data Collection – Warehouse Management
(Shipping)

 

 

 

20.0 Plant Data Collection – Warehouse Management
(Time and Attendance)

 

 

 

 

21.0 Manufacturing to Purchasing –Receiving and Inspection in Manufacturing
(Publish/Subscribe Model)

22.0 Manufacturing to Purchasing – Receiving and Inspection in Manufacturing
(Request/Replay and Publish/Subscribe)

23.0 Manufacturing to Purchasing – Receiving and Inspection in Purchasing
(Publish/Subscribe)

24.0 Manufacturing to Purchasing – Receiving and Inspection in Purchasing
(Request/Reply and Publish/Subscribe)

25.0 Manufacturing to Order Management – Financials with Logistics,
(Make to Order, Build to order)

26.0 Manufacturing to Order Management – Financials with Logistics,
(Engineer to Order, Configure to order)

 

 

 

 

27.0 Manufacturing to Order Management – Financials with Logistics,
(Mixed Mode Manufacturing)

 

 

 

28.0 Manufacturing to Order Management – Financials with Manufacturing,
(Make to Order, Build to Order)

 

 

 

 

 

 

29.0 Manufacturing to Order Management – Financials with Manufacturing,
(Engineer to Order, Configure to Order)

 

 

 

 

30.0 Manufacturing to Order Management – Financials with Manufacturing,
(Mixed Mode Manufacturing)

 

 

31.0 Invoice Matching,
Matching in Purchasing, Invoices entered in Purchasing

 

 

 

 

 

 

 

32.0 Invoice Matching,
Matching in Purchasing, Invoices entered in Accounts Payable (Publish/Subscribe)

 

 

 

 

 

 

 

33.0 Invoice Matching,
Matching in Purchasing, Invoices entered in Accounts Payable (Request/Reply)

 

 

 

 

 

 

 

34.0 Invoice Matching,
Matching in Accounts Payable, Invoices entered in Accounts Payable (Publish/Subscribe)

 

 

 

 

 

 

 

 

35.0 Invoice Matching,
Matching in Accounts Payable, (Request/Reply)

 

 

 

 

 

 

 

 

36.0 Synchronize Sales Orders for Shipping

 

 

 

 

 

 

 

 

37.0 Sales Force Automation to Order Management, Updating orders in Order Management

 

 

 

 

 

 

 

 

38.0 Sales Force Automation to Order Management, Inquiring on orders in Order Management

 

 

 

 

 

 

 

 

39.0 Sales Force Automation to Order Management and Shipping

 

 

 

 

 

 

40.0 Supply Chain Integration, Manufacturing to Purchasing, Order Management, Billing, Shipping, and Financials

 

 

 

 

41.0 Customer Service Integration, Field Service, No Returns

 

 

 

 

 

 

42.0 Manufacturing to Order Management, Financials with Manufacturing, Make to Order with Credit Checking

 

 

 

 

43.0 Manufacturing to Purchasing, Receiving and Inspection in Manufacturing, Request/reply Model

44.0 Production Synchronization

 

 

 

 

 

 

 

45.0 Purchase Order Integration

 

 

 

 

 

 

 

46.0 Production Routing synchronization

 

 

 

 

 

 

47.0 Human Resources Integration

 

 

Sync Field is used to synchronize codes used in the integration of Human Resource information.

 

 

 

48.0 Human Resources to Time Data Collection

 

 

 

49.0 Engineering Changes Scenario Description

49.0 Overview

This chapter describes the integration scenario for managing engineering information flows.  Such flows may originate from many departments within an organization, including, but not limited to:

1.       Contracts Administration -For new customer contract requirements for and Engineer to Order contract

2.       Compliance -For new regulations for product safety

3.       Manufacturing - For difficulty in mass production of a prototype that work in limited production.

4.       Logistics - For items that are difficult and expensive to transport and handle.

5.       Field Service - For items that fail in the in the field or have high warranty costs.

6.       Marketing - For new customer requested features.

This is not a complete list but is meant to be a representative sample of activities that generate a engineering changes.

The purpose of this scenario is to enable the visualization of the components and the dialogs between components for this specific integration domain.  This scenario is not meant to be the only correct model for integrating Product Data Management components to a other business software components.  This is one model that may be used to design one’s own integration based on the specific needs of an organization or group of organizations. 

49.1 Scenario Diagram

The scenario diagram below contains the components involved in the interaction, the dialog flows or conversation between the components, certain assumptions about the sequence of events, and assumptions about the technical approach, for example, publish and subscribe.  The next three sections will give a brief overview of the components, the sequence of events, and the environment. 

Again, this is a MODEL to be used as a reusable design document, not a required  approach.

 

 

49.2 Assumptions

This scenario assumes a loosely coupled, asynchronous approach to the integration.  Transaction management is implicitly required but not explicitly defined.

This scenario describes a model for one or more Design Engineering components integrating with other common Manufacturing and Distribution components.  The environment for this integration may be within a single enterprise, or across enterprises.  There may be instances where the information in an engineering change request can be at the level of requirements, and desired behavior.  As the engineering change moves through it’s lifecycle, the information must become more and more detailed.  As the information moves into  the Engineering change order phase, it must contain all the information needed to manufacture the item or items

49.3 Component Definitions

This scenario contains three major components.  Design Engineering, Manufacturing Requirements Planning and Manufacturing Execution.  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. 

This heuristic definition is broadly accepted by the designers of the integration scenario and is a direct decision not to define how the processing takes place within any individual component.  The component must be able perform the services defined by the business object document, but the internals of the component are not required or desired to be exposed.

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

49.4 Business Workflow (Sequence)

This scenario has two major events in the workflow sequence. 

1) The First Business Event is the request for an Engineering Change that is made from any client department.

The synchronization process can ensure that all of the components in the integration scenario will have the same data necessary to communicate.

2)      The second Business Event is the Creation of the Engineering Change request in the Engineering systems.

3)      The Third Business event may be that the engineering change is communicated broadly to a set of contributors to a design.

4)      The fourth business event may be that the engineering change is believed by the designers to meet the requirements stated in the specification.  A notification is sent out to a list of approvers to sign off on the change before it can go to the next stage.

5)      The fifth business event is that the approvers send in their approvals and the design change can be sent to manufacturing engineering to make any modifications to the assembly operations for any effected parts, or equipment.

6)       The sixth business event is that manufacturing engineering are informed that the authorized method of manufacture has changed.

49.5 Exception Handling

This section is not intended to fully define the only acceptable methods for exception handling for this scenario.  It is intended to be used as a guide by the designer to understand the intent and think through the issues the creators of this model had in mind.

The Confirm BOD shown in the scenario is the most obvious method for providing an application level feedback mechanism between business software components.  This Confirm BOD is described in detail in section three, chapter two of OAGIS, however the specific use of the Confirm BOD may vary significantly from scenario to scenario.

The Confirm BOD in this scenario is intended to be used by the general ledger component to communicate to the sub ledger that the information it sent was received and understood.  If the information was not received or not understood, or contained errors of any type, the financial tracking for the organization may be incomplete or incorrect.

It is strongly recommended that the Confirm BOD is used in this scenario to prevent this potential problem.

 

50.0 ERP to Finite Scheduling and Manufacturing Execution Scenario Description

50.0 Overview

This chapter describes the integration scenario in order to enable the execution of  Manufacturing Systems business software components to integrate manufacturing systems.

The purpose of this scenario is to enable the visualization of the components and the dialogs between components for this specific integration domain.  This scenario is not meant to be the only correct model for integrating sub-ledger components to a General Ledger business software component.  This is one model that may be used to design one’s own integration based on the specific needs of an organization or group of organizations. 

Several applications can provide a Dispatch List to the manufacturing system. The scenario diagram below shows an integration that involves Finite Scheduling as the source of the Dispatch List.

Possible sources for a Dispatch List may be:

1.    Finite Scheduling

2.    ERP

This is not a complete list but is meant to be a representative sample of activities that generate a journal entry.

 

50.1 Scenario Diagram

The scenario diagram below contains the components involved in the interaction, the dialog flows or conversation between the components, certain assumptions about the sequence of events, and assumptions about the technical approach, for example, publish and subscribe.  The next three sections will give a brief overview of the components, the sequence of events, and the environment. 

Again, this is a MODEL to be used as a reusable design document, not a required  approach.

50.2 Assumptions

This scenario assumes a loosely coupled, asynchronous approach to the integration.  Transaction management is implicitly required but not explicitly defined.

This scenario describes a model for production planning.

The environment for this integration is typically within an enterprise and within a division.

This scenario also assumes that one application will maintain the master data for integration. The Business Object Documents in the scenario diagram are described  in section three of OAGIS.

50.3 Component Definitions

This scenario contains four components.

1.    The production planning component

2.    The manufacturing component,

3.    The manufacturing execution component, and

4.    The ERP component.

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. 

This heuristic definition is broadly accepted by the designers of the integration scenario and is a direct decision not to define how the processing takes place within any individual component.  The component must be able perform the services defined by the business object document, but the internals of the component are not required or desired to be exposed.

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

50.4 Business Workflow (Sequence)

This scenario contains the following events in the workflow sequence. 

1)       The first business event is an order is received from an external customer. When a new Item is added to the ERP system, it is automatically synchronized out to the other applications.

2)       The next step is to create a production order from the sales order from the customer.

3)       These Production orders are then sent to Capacity Analysis component, and Scheduling component, this includes the Production order, Bill of Materials (BOM) and Routing.

4)       The Scheduling component creates a list of tasks to be done, a Dispatch List, by the manufacturing Execution system in order to fulfill production orders.

5)       If a disruption occurs in the manufacturing process a Manufacturing system can request to Get the Dispatch List and receive a Show of the Dispatch List.

6)       Upon completion of these tasks, the Manufacturing system updates the ERP and Capacity Analysis systems are updated with the WIP in progress and the confirmation of issues of materials.

50.5 Exception Handling

This section is not intended to fully define the only acceptable methods for exception handling for this scenario.  It is intended to be used as a guide by the designer to understand the intent and think through the issues the creators of this model had in mind.

The Confirm BOD shown in the scenario is the most obvious method for providing an application level feedback mechanism between business software components.  This Confirm BOD is described in detail in section three, chapter two of OAGIS, however the specific use of the Confirm BOD may vary significantly from scenario to scenario.

The Confirm BOD in this scenario is intended to be used by the components to communicate the information it sent was received and understood.  If the information was not received or not understood, or contained errors of any type, the financial tracking for the organization may be incomplete or incorrect.

It is strongly recommended that the Confirm BOD is used in this scenario to prevent this potential problem.

51.0 Computerized Maintenance Management System (CMMS) to Field Devices

 

52.0 Catalog Exchange Scenario Description

52.0 Overview

This chapter describes the integration scenario for managing catalog information flows.  Such flows may originate from many departments within an organization, including, but not limited to:

1.       Marketing

2.       Sales Administration

3.       Procurement

This is not a complete list but is meant to be a representative sample of activities that generate Catalog Information flows. 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

·         Suppliers Part Number

·         Manufacturer’s Part Number

·         Customer’s Part Number

·         Global Part Identifiers, including:

·         UPC Code

·         EAN Number

·         Part Classification, including;

·         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 dependant of the subscriber.

You should be able to secure a requestor to specific catalogs.

Catalog Subscriber

The catalog subscriber should be able to subscribe to

·         One

·         Many

·         All

updates to item information from a

·         Vendor

·         Agent for a Vendor

for a catalog or catalogs that you 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 Numbers, including

·         Suppliers Part Number

·         Manufacture's Part Number

·         Customer's Part Number

·         Global Part Numbers, including:

·         UPC Code

·         EAN Number

·         A list of Parts within a given classification, including

·         Commodity Code

·         A list if all Products or Services that

·         Provide a given feature

·         Have a specification

·         Equal to

·         Greater than

·         Less than

·         a Given, Value, List of Values Range of Values

The purpose of this scenario is to enable the visualization of the components and the dialogs between components for this specific integration domain. This scenario is not meant to be the only correct model for integrating catalog components to a other business software components and between enterprises.  This is one model that may be used to design one’s own integration based on the specific needs of an organization or group of organizations. 

52.1 Scenario Diagram

The scenario diagrams below contain the components involved in the interaction, the dialog flows or conversation between the components, certain assumptions about the sequence of events, and assumptions about the technical approach, for example, publish and subscribe.  The next three sections will give a brief overview of the components, the sequence of events, and the environment.

This diagram show the Electronic Catalog which is a more robust structure that allows the features and pricelist to be carried in a single BOD structure. This allows for the initial load of the catalog for the BOD to contain everything that is needed by the receiving Catalog system.

Again, these MODEL is to be used as a reusable design document, not a required  approach.

52.2 Assumptions

This scenario assumes a loosely coupled, asynchronous approach to the integration.  Transaction management is implicitly 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 the requirement to synchronize a Catalog.

It may also be necessary to support Component Supplier Management (CSM) scenarios.  In this 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.

 

52.3 Component Definitions

This scenario contains five major components.  Order Management, Product Data Management (PDM), Planning, Catalog Management System, and Purchasing.  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 component maintains Item pricing information. The PDM component maintains item master information, item Cross-reference information, item classification information, and item specifications. The Planning component maintains information regarding product availability. The Catalog Management System component represents the Catalog Management system of the catalog provider. The Purchasing component represents the Purchasing system of a customer or a catalog subscriber.

This heuristic definition is broadly accepted by the designers of the integration scenario and is a direct decision not to define how the processing takes place within any individual component.  The component must be able to perform the services defined by the business object document, but the internals of the component are not required nor are they desired to be exposed.

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

52.4 Business Workflow (Sequence)

This scenario has the following major events in the workflow sequence. 

1)      Sync ElectronicCatalog
This event is the publication from the order management system of a catalog to the Catalog Management System. 

2)      Get PriceList
The Catalog Management System quotes a price list that does not exist in the Catalog Management System causing the Catalog Management System to request the price list.

3)      Show PriceList
This event is the publication from the order management system of the Price List that accompanies the catalog.

4)      Get ItemMaster
The price list quote items that are not yet in the catalog causing the Catalog Management System to request the new item definitions from the PDM Systems.

5)      Show ItemMaster
The PDM system publishing the item definition into the Catalog Management System.

6)      Get ItemCrossReference
The Catalog Management System quotes a set of cross references that are not currently in the catalog.  The cross references may be either

Alternate Identifiers of the Products in the Catalog such as

·         EAN Numbers

·         UPC Codes

or they may be Related Items such as

·         Accessories

·         Spares

·         Consumables

The Cross Reference document may flow from either the purchasing system of the selling system to let the Catalog Management System be aware of the identifiers used by all buying and selling parties

7)      Show ItemCrossReference
The PDM system publishes the cross references for the Item into the catalog.

8)      Get ProductAvailability

The Catalog Management System requests product availability from the Planning systems. 

9)      Show ProductAvailability
The Planning system publishing the availability of the products in the catalog.

10)  Sync Price List
This event is the publication from the order management system of the Price List that accompanies the catalog.

52.5 Exception Handling

This section is not intended to fully define the only acceptable methods for exception handling for this scenario.  It is intended to be used as a guide by the designer to understand the intent and think through the issues the creators of this model had in mind.

The Confirm BOD shown in the scenario is the most obvious method for providing an application level feedback mechanism between business software components.  This Confirm BOD is described in detail in section three, chapter two of OAGIS, however the specific use of the Confirm BOD may vary significantly from scenario to scenario.

The Confirm BOD in this scenario is intended to be used by the general ledger component to communicate to the sub ledger that the information it sent was received and understood.  If the information was not received or not understood, or contained errors of any type, the financial tracking for the organization may be incomplete or incorrect.

It is strongly recommended that the Confirm BOD is used in this scenario to prevent this potential problem.

53.0 PriceList Exchange Scenario Description

53.0 Overview

This chapter describes the integration scenario for managing Price List information flows.  Such flows may originate from many departments within an organization, including, but not limited to:

1.       Marketing

2.       Sales Administration

3.       Procurement

This is not a complete list but is meant to be a representative sample of activities that generate Price List Information flows.

The purpose of this scenario is to enable the visualization of the components and the dialogs between components for this specific integration domain.  This scenario is not meant to be the only correct model for integrating Price List components to a other business software components and between enterprises.  This is one model that may be used to design one’s own integration based on the specific needs of an organization or group of organizations. 


53.1 Scenario Diagram

The scenario diagram below contains the components involved in the interaction, the dialog flows or conversation between the components, certain assumptions about the sequence of events, and assumptions about the technical approach, for example, publish and subscribe.  The next three sections will give a brief overview of the components, the sequence of events, and the environment. 



Again, this is a MODEL to be used as a reusable design document, not a required  approach.

53.2 Assumptions

This scenario assumes a loosely coupled, asynchronous approach to the integration.  Transaction management is implicitly required but not explicitly defined.

This scenario describes a model for one or more price list 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 the requirement to synchronize a Price List. It may also be an instruction from a customer that an update from the supplier for the prices supplied to the customer have expired.

It may also be necessary to support Component Supplier Management (CSM) scenarios.  In this 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. It may also be a request from the component supplier managment company (CSM), to suppliers to update their catalog contents into the CSM’s catalog.

 

53.3 Component Definitions

This scenario contains five major components.  Order Management, Product Data Management (PDM), Planning, Catalog Management System and Purchasing.  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 component maintains Item pricing information. The PDM component maintains item master information, item Cross-reference information, Item classification information and item specifications. The Planning component maintains information regarding product availability. The Catalog Management System component represents the Catalog Management system of the catalog provider. The Purchasing component represents the Purchasing system of a customer or a catalog subscriber

This heuristic definition is broadly accepted by the designers of the integration scenario and is a direct decision not to define how the processing takes place within any individual component.  The component must be able perform the services defined by the business object document, but the internals of the component are not required or desired to be exposed.

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

53.4 Business Workflow (Sequence)

This scenario has the following major events in the workflow sequence. 

1)      Sync ElectronicCatalog
This event is the publication from the order management system of a catalog to the Catalog Management System. 

2)      Get PriceList
The Catalog Management System quotes a price list that does not exist in the Catalog Management System causing the Catalog Management System to request the price list.

3)      Show PriceList
This event is the publication from the order management system of the Price List that accompanies the catalog.

4)      Get ItemMaster
The price list quote items that are not yet in the catalog causing the Catalog Management System to request the new item definitions from the PDM Systems.

5)      Show ItemMaster
The PDM system publishing the item definition into the Catalog Management System.

6)      Get ItemCrossReference
The Catalog Management System quotes a set of cross references that are not currently in the catalog.  The cross references may be either

Alternate Identifiers of the Products in the Catalog such as

·         EAN Numbers

·         UPC Codes

or they may be Related Items such as

·         Accessories

·         Spares

·         Consumables

The Cross Reference document may flow from either the purchasing system of the selling system to let the Catalog Management System be aware of the identifiers used by all buying and selling parties

7)      Show ItemCrossReference
The PDM system publishes the cross references for the Item into the catalog.

8)      Get ProductAvailability
The Catalog Management System requests product availability from the Planning systems. 

9)      Show ProductAvailability
The Planning system publishing the availability of the products in the catalog.

10)  Sync Price List
This event is the publication from the order management system of the Price List that accompanies the catalog.

53.5 Exception Handling

This section is not intended to fully define the only acceptable methods for exception handling for this scenario.  It is intended to be used as a guide by the designer to understand the intent and think through the issues the creators of this model had in mind.

The Confirm BOD shown in the scenario is the most obvious method for providing an application level feedback mechanism between business software components.  This Confirm BOD is described in detail in section three, chapter two of OAGIS, however the specific use of the Confirm BOD may vary significantly from scenario to scenario.

The Confirm BOD in this scenario is intended to be used by the Order Management component to communicate to the Purchasing System that the information it sent was received and understood.  If the information was not received or not understood, or contained errors of any type, the financial tracking for the organization may be incomplete or incorrect.

It is strongly recommended that the Confirm BOD is used in this scenario to prevent this potential problem.

54.0 Item Unit-Of-Measure (UOM) Integration Scenario

54.0 Overview

This document describes the integration scenario for supporting Unit-Of-Measure (UOM) information flows associated with items being managed as inventory.

In the latest version of OAGIS, the Sync Item 002 BOD declares:

The Unit of Measure (UOM) field identifier refers to the stocking unit of measure and is the only unit of measure addressed for synchronization in this Business Service Request.  The units of measure values are user defined.

This integration scenario extends OAGIS by addressing the need for applications to exchange alternative UOM information beyond the stocking UOM.  

While the stocking level UOM provides for basic inventory accounting functionality, it may not be the most efficient, common or natural UOM for manufacturing, purchasing, selling or handling the item.  The item may be packaged into standardized or supplier-specific bulk quantities for import/export, wholesale, or retail sales (for example: Each, Box, Case, Pallet, etc).  The item may be also utilized in manufacturing, inspection or other processes in fixed quantity amounts that may be both common (Pair, Dozen, Gross, etc) or item-specific (Tray, Set, Spool, etc). 

The materials management, inventory control, warehousing and receiving/shipping departments within an organization require the packaging relationship details between UOMs and the handling characteristics for each UOM to effectively manage the flow and storage of inventory. 

The UOM information flows in this integration scenario also incorporate the Uniform Code Council's "best practices" for item and packaging container identification standards by supporting a unique bar code identifier at each packaging level. 

While many are familiar with the UCC's Universal Product Code (UPC) bar code on most consumer retail items, few persons outside the industry are aware of the complementary standard UPC Shipping Container Code (SCC-14) frequently used on the inner carton & outer case packaging containers for an item.

The SCC-14 bar code permits the automated identification of both the item and packaging level of goods being handled.  For example, when receiving user scans the SCC-14 bar code on a shipping container the inventory application not only obtains the identity of the item, but also the packaging UOM and quantity -- via the UOM packaging reference detail information enabled by the BSRs in this scenario.

See the UCC's Application Standard for Shipping Container Codes - June 1996, or ANSI/UCC6-1996, for additional information.

54.1 Scenario Diagram

The following scenario diagram illustrates the BODs and information flows that may be used to support the transfer of item UOM information between a master source component and one or more subscribing client components.

 

The Sync Field BOD is unchanged from the current OAGIS specification.

The Sync & Show UomGroup BODs have been created to transfer the UOM relationships independent of the item definition.

The Sync & Show Item BODs have been extended to support zero or more ITEMUOM Data Types to convey multiple UOM relationships along with the item definition.

See the UomGroup & Item BOD definitions for additional detailed structural information.

54.2 Assumptions

This scenario assumes a loosely coupled, asynchronous approach to the integration.  Transaction management is implicitly required but not explicitly defined.

This scenario describes the model for a central materials management component to communicate information about items and their associated UOM relationships to one or more subscribing components.  

This scenario is designed to support both event-driven (using Sync and Show BOD verbs) and request/reply (using Get, Show, GetList and List BOD verbs) modes of application-to-application communication. 

The flow of item and UOM information is generally outward toward the subscribing components.  However, the Sync verb does permit bi-directional flow, allowing for the possibility of a subscribing system to attempt to synchronize certain item characteristics on the master database.   This scenario assumes that central master application will only update auxiliary item attribute information that it does not "own" (per the original scenario diagram processing notes for Sync Item 002).  In such a bi-directional sync scenario, the determination of item characteristic ownership and update processing rules is left to the designer of the specific implementation.

The environment for this integration is application-to-application (A2A) within a single enterprise, or extended across enterprises where there is a single master application that manages the assignment of all item identifiers. 

For business-to-business (B2B) environments where there is no master or common set of item identifiers, an item catalog containing item cross-reference information is required to correlate item definitions between business partners.  See the Catalog Exchange Integration Scenario more information.

54.3 Component Definitions

In this integration scenario, the Materials Management component is considered to be the owner and source of all item and UOM information.  For example, the Materials Management component may be the material/inventory management subsystem of a SAP R/3 or Oracle Applications ERP system.

A subscribing application with an independent data store for item/UOM information would typically function in event-driven mode, receiving synchronization updates at an "as required" or periodic interval.

A subscribing application without an independent data store for item/UOM information would typically function in request/reply mode.

The Materials Management component or other subscribing applications may manage the item's UOM & packaging relationships as an intrinsic part of each item definition (item-dependent) or as entirely separate groupings that are later associated with one or more items (item-independent). 

The item-dependent UOM methodology tends to be found in some legacy inventory management applications, while the item-independent UOM methodology reflects a more modern, normalized data approach. However both methodologies are commonly found in various applications present in today's marketplace.

The Sync & Show Item BODs are intended for use when the Materials Management component or the subscribing application only supports the item-dependent UOM methodology.

The Sync & Show UomGroup BODs are intended for use when both the Materials Management component and subscribing application mutually supports the item-independent UOM methodology.  The Sync & Show Item BODs are still used to transfer item attribute information and a reference to the UOM relationship.

The following example may help explain the differences between the item-dependent and item-independent UOM methodologies:

Pre-recorded Digital Versatile Disks (DVDs) from the same vendor/distributor are quite likely to have the same bulk packaging relationship regardless of the information contained on the disks.  Suppose the UOM packaging relationship is:

§         25 DVD disks per inner pack Box

§         4 inner pack Boxes per Case

§         20 Cases per Pallet

 

For inventory systems managing many DVD titles with an item-independent UOM methodology, the above packaging relationship only needs to be defined and sent to a subscribing application once.  Additional DVD title item additions or updates only reference the existing packaging relationship.

For inventory systems managing many DVD titles with an item-dependent UOM methodology, the above packaging relationship must be repeatedly entered and sent for each item definition. 

The item-independent UOM methodology can significantly reduce the amount of redundant UOM & packaging data that must be maintained and sent, especially in an inventory situation having many thousands of similar items.

54.4 Business Workflow (Sequence)

Event Driven Mode (using Sync and/or Show BODs)

1.    The first business event is definition of a UOM code value (such as "Each", "Case" or "Pallet") in the Materials Master component.  

This communication flow is only necessary if the subscribing component requires UOM code values be defined prior to the definition of UOM quantity relationships.

2.    The next business event is determined by the item-dependent or item-independent nature of the materials management component.

If item-dependent, the item and its attributes are typically defined prior to, or at the same time as, the item's UOM relationships in the component.

 

If item-independent, the UOM relationships are typically defined prior to the item definition.


Request/Reply Mode
(using Get, Show, GetList and List BODs)

54.5 Exception Handling

This section is not intended to fully define the only acceptable methods for exception handling for this scenario.  It is intended to be used as a guide by the designer to understand the intent and think through the issues the creators of this model had in mind.

The Confirm BOD is the multi-purpose BOD used for providing an application level feedback mechanism between business software components.  This Confirm BOD is described in detail in section three, chapter two of OAGIS.

Please note that the specific use of the Confirm BOD may vary significantly from scenario to scenario.

The Confirm BOD in this scenario is intended to be used by the receiving component to communicate to the sending component that the information it sent was received and understood.  If the information was not received or not understood, or contained errors of any type, the dialog may be incomplete or incorrect.

It is strongly recommended that the Confirm BOD be used in this scenario to prevent this potential problem.

 

55.0 Buyer and Supplier RFQ - Quote Scenario Description

55.0 Overview

This chapter describes the integration scenario for 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 components and the dialogs between components for this specific integration domain.  This scenario is not meant to be the only correct model for integrating a buyer’s business software components to supplier’s business software components.  This is one model that may be used to design one’s own integration based on the specific needs of an organization or group of organizations. 

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

9.    Engineering Product Data Management

10. Purchasing / Procurement

11. Order Management

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


55.1 Scenario Diagrams

The scenario diagrams below contain the components involved in the interaction, the dialog flows or conversation between the components, certain assumptions about the sequence of events, and assumptions about the technical approach, for example, publish and subscribe.  The next three sections will give a brief overview of the components, the sequence of events, and the environment. 

 

Again, this is a MODEL to be used as a reusable design document, not a required approach.

55.2 Assumptions

This scenario assumes a loosely coupled, asynchronous approach to the integration.  Transaction management is implicitly 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.

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 the OAGIS.

55.3 Component 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 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 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. 

This heuristic definition is broadly accepted by the designers of the integration scenario and is a direct decision not to define how the processing takes place within any individual component.  The component must be able perform the services defined by the business object document, but the internals of the component are not required or desired to be exposed.

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

55.4 Business Workflow (Sequence)

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.

 

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 chapters of the OAGIS.

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 chapters of OAGIS.

Using Intermediaries To Manage RequestForQuote/Quote Exchange Activity

The workflow sequence for scenarios using intermediaries involves additional activity over the scenarios listed above. An intermediary may be independent or an extension of a large organization.

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 requestor (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 bout 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 – request an RequestForQuote from a buyer or intermediary

2)       Show RequestForQuote – RequestForQuote is sent in response to the “Get” request.

3)       GetList RequestForQuote – request for a list of RequestForQuotes

4)       List RequestForQuote – List of RequestForQuotes sent in response to “GetList” request

5)       Get Quote – request a Quote from a buyer or intermediary

6)       Show Quote – Quote is sent in response to the “Get” request.

7)       GetList Quote – request for a list of Quotes

8)       List Quote – List of Quotes sent in response to “GetList” request

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 chapters of OAGIS.

55.5 Exception Handling

This section is not intended to fully define the only acceptable methods for exception handling for this scenario.  It is intended to be used as a guide by the designer to understand the intent and think through the issues the creators of this model had in mind.

The Confirm BOD is the multi-purpose BOD used for providing an application level feedback mechanism between business software components.  This Confirm BOD is described in detail in section three, chapter two of OAGIS.

Please note that the specific use of the Confirm BOD may vary significantly from scenario to scenario.

The Confirm BOD in this scenario is intended to be used by the receiving component to communicate to the sending component that the information it sent was received and understood.  If the information was not received or not understood, or contained errors of any type, the dialog may be incomplete or incorrect.

It is strongly recommended that the Confirm BOD be used in this scenario to prevent this potential problem.

56.0 Forecast Exchange Scenario Description - Revision 001

56.0 Overview

This chapter describes the integration scenario for managing forecast, planning, shipping and sequence scheduling information flows.

The following diagram shows the context of the Forecast Scenario. 

 

56.1 Scenario Diagram

The scenario diagram below contains the components involved in the interaction, the dialog flows or conversation between the components, certain assumptions about the sequence of events, and assumptions about the technical approach, for example, publish and subscribe.  The next three sections will give a brief overview of the components, the sequence of events, and the environment. 

Again, this is a MODEL to be used as a reusable design document, not a required  approach.

56.2 Assumptions

This scenario assumes a loosely coupled, asynchronous approach to the integration.  Transaction management is implicitly required but not explicitly defined.

56.3 Component Definitions

This scenario contains two major components.  The Supplier Scheduling Application, and the Buyer Release Management 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 Supplier Scheduling Application maintains schedules regarding Planned demand, Shipping and Sequence of delivery.  The Release management Application drives the MRP, the shipment and the sequence schedules in the Suppliers ERP application.

This heuristic definition is broadly accepted by the designers of the integration scenario and is a direct decision not to define how the processing takes place within any individual component.  The component must be able perform the services defined by the business object document, but the internals of the component are not required or desired to be exposed.

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

The Relationships between the components are shown in the following context diagram. Each of the grey boxes on this diagram will be described in the BOD’s as a component

56.4 Business Workflow (Sequence)

This scenario has the following major events in the workflow sequence. 

1)      Sync PlanningSchedule
This event is the publication from the supplier scheduling application of a Planning schedule to the buyer release management application.

2)      Sync ShipmentSchedule
This event is the publication from the supplier scheduling application of a Shipment schedule to the buyer release management application.

3)      Sync SequenceSchedule
This event is the publication from the supplier scheduling application of a Sequence Schedule to the buyer release management application.

4)      Get PlanningSchedule
The supplier Management Application quotes a Planning schedule that does not exist in the Demand Management Application causing the Demand Management Application to request the Planning Schedule.

5)      Show PlanningSchedule
This event is the publication from the Supplier Scheduling Application of the Planning schedule.

6)      Get ShipmentSchedule
The buyer Demand Management Application quotes a Shipment Schedule that does not exist in the Demand Management Application causing the Demand Management Application to request the Shipment Schedule.

7)      Show ShipmentSchedule
This event is the publication from the Supplier Scheduling Application of the Shipment schedule.

8)      Get SequenceSchedule
The buyer Demand Management Application quotes a Sequence Schedule that does not exist in the Demand Management Application causing the Demand Management Application to request the Sequence Schedule.

9)      Show SequenceSchedule
This event is the publication from the Supplier Scheduling Application of the Sequence Schedule.

56.5 Exception Handling

This section is not intended to fully define the only acceptable methods for exception handling for this scenario.  It is intended to be used as a guide by the designer to understand the intent and think through the issues the creators of this model had in mind.

The Confirm BOD is the multi-purpose BOD used for providing an application level feedback mechanism between business software components.  This Confirm BOD is described in detail in section three, chapter two of OAGIS.

Please note that the specific use of the Confirm BOD may vary significantly from scenario to scenario.

The Confirm BOD in this scenario is intended to be used by the receiving component to communicate to the sending component that the information it sent was received and understood.  If the information was not received or not understood, or contained errors of any type, the dialog may be incomplete or incorrect.

It is strongly recommended that the Confirm BOD be used in this scenario to prevent this potential problem.

57.0 Production to Manufacturing Execution Scenario Description

57.0 Overview

This chapter describes scenarios which would enable integration of disparate manufacturing systems business software components.

The purpose of this scenario is to enable the visualization of the components and the dialogs between components for this specific integration domain.  This scenario is not meant to be the only correct model for integrating execution system components to an ERP business software component.  This is one model that may be used to design one’s own integration based on the specific needs of an organization or group of organizations. 

The first scenario diagram below shows an integration that involves a manufacturing execution system (MES) and a central ERP system. The MES is shown as the source of production events and activities. The ERP is shown as the source of related setup events which occur prior to production.  The second scenario diagram below shows an integration that involves an ERP system of a manufacturer and an ERP system of a subcontractor or contract manufacturer who receives purchase orders from the manufacturer. In this scenario, setup events are arrived at through collaboration between the two organizations.

This is not a complete list but is meant to be a representative sample of activities that constitute a manufacturing business process.

 

57.1 Scenario Diagram

The scenario diagrams below contain the components involved in the interactions, the dialog flows or conversation between the components, certain assumptions about the sequence of events, and assumptions about the technical approach.  The next section gives a brief overview of the components, the sequence of events, and the environment. 

Again, this is a MODEL to be used as a reusable design document, not a required  approach.

 


 

57.2 Assumptions

These scenarios assume a loosely coupled, asynchronous approach to the integration.  Transaction management is implicitly required but not explicitly defined.

These scenarios describe a model for production execution.

The environment for this first integration is typically within an enterprise and within a division. The environment for this second integration is typically between two enterprises.

These scenarios also assume that one application will maintain the master data for integration. The Business Object Documents in the scenario diagrams are described in section three of OAGIS.

57.3 Component Definitions

The first scenario contains two components.

1.        The manufacturing execution component, and

2.        The ERP component (Production WIP).

 

The second scenario contains two components. 

1.       The manufacturer ERP component, and

2.       The subcontractor ERP component.

 

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. 

This heuristic definition is broadly accepted by the designers of the integration scenario and is a direct decision not to define how the processing takes place within any individual component.  The component must be able perform the services defined by the business object document, but the internals of the component are not required or desired to be exposed.

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

57.4 Business Workflow (Sequence)

This scenario contains the following events in the workflow sequence. 

1.       The first business event is a production order created from any of a number of sources. When a new order is added to the ERP system, it is automatically synchronized out to the other applications.

2.       The next step is to begin to issue material and charge resource usage to the production order.

3.       The production orders move through operations on the shop floor.

4.       Throughout the production process, the order may experience a number of moves and splits or merges, and the creation of one or more bonus lots of material may possibly occur.

5.       The end of the manufacturing process is marked by completions of production lots.

6.       Upon completion of these tasks, the Manufacturing system updates the ERP system.

 

The diagram below contains the manufacturing events described above, the components involved in the interaction, and the dialog flows or conversation between the components.

 

58.0 Supply Chain Execution Scenario Description

58.0 Overview

This chapter describes scenarios, which would enable integration of Order Management and Receiving systems with External Supplier systems and Warehouse Management business software.

The purpose of this scenario is to enable the visualization of the components and the dialogs between components for this specific integration domain.  This scenario is not meant to be the only correct model for integrating supply chain execution system components.  This is one model that may be used to design one’s own integration based on the specific needs of an organization or group of organizations. 

The scenario diagram below shows an integration that involves an external supplier, an order management system, a receiving system, and a warehouse management system. The orders management system is shown as managing the interface with the external supplier partner. The order management system communicates to the warehouse management system the delivery. The warehouse management system informs the receiving system what to expect in a delivery. Once received the receiving system updates the order management system on what was received and acknowledges the delivery to the external supplier partner.

This is not a complete list but is meant to be a representative sample of activities that constitute a supply chain execution business process.

 

58.1 Scenario Diagram

The scenario diagrams below contain the components involved in the interactions, the dialog flows or conversation between the components, certain assumptions about the sequence of events, and assumptions about the technical approach.  The next section gives a brief overview of the components, the sequence of events, and the environment. 

Again, this is a MODEL to be used as a reusable design document, not a required  approach.


 58.2 Assumptions

These scenarios assume a loosely coupled, asynchronous approach to the integration.  Transaction management is implicitly required but not explicitly defined.

These scenarios describe a model for production execution.

The environment for this first integration is typically within an enterprise and within a division. The environment for this second integration is typically between two enterprises.

These scenarios also assume that one application will maintain the master data for integration. The Business Object Documents in the scenario diagrams are described in section three of OAGIS.

58.3 Component Definitions

The scenario contains four components.

3.        The external supplier partner,

4.        The material scheduling or order management,

5.        The warehouse management systems, and

6.        The receiving system.

Note:

The order management, warehouse management and receiving systems could be part of a single or possible within different ERP systems.

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. 

This heuristic definition is broadly accepted by the designers of the integration scenario and is a direct decision not to define how the processing takes place within any individual component.  The component must be able perform the services defined by the business object document, but the internals of the component are not required or desired to be exposed.

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

58.4 Business Workflow (Sequence)

This scenario contains the following events in the workflow sequence. 

1)       The first business event is a PlanningSchedule, ShipmentSchedule, and SequenceSchedule created and agreed to by the external supplier order system and the internal order management systems. Once these are agreed to and the supplier has either acquired or manufactured the item(s). These steps are not address in this scenario, but are described in earlier scenarios.

2)        The next step is to Ship the goods. Once the Shipment has been loaded on the transportation mechanism. A Shipment detail is provided to the Order Management system.

3)       The next step is for the Order Management system to communicate the Delivery information to the Warehouse Management System so that shelf space or and available inventory can be noted.

4)       The next step is for the Warehouse Management System to communicate to the Receiving system what to expect on the delivery.

5)       The step is for the transport to arrive the delivery is verified against what was expected. The Receiving system updates the Order Management system on what was received. It also acknowledges the delivery to the External Supplier. Also, the material received is stocked to the Warehouse.

 

59.0 Ledger Actuals Scenario Description

59.0 Overview

This chapter describes the integration scenario for the enterprise applications business software components to obtain and receive accounting data from the general ledger business software component.

The purpose of this scenario is to enable the visualization of the components and the dialogs between components for the financial domain.

Many applications create data that cause changes in the account balances of a general ledger application.  Some components that have activity which will be reflected in a general ledger application are: Billing, Allocations, Asset Mgmt, Budget, Accounts Receivable, Order Mgmt, Purchasing, Accounts Payable, Time and Labor, Travel Expenses and Human Resources. The diagram below contains the components involved in the interaction, the dialog flows or conversation between the components.

 

This is not a complete list but is meant to be a representative sample of activities that generate a journal entry.

59.1 Scenario Diagram

The scenario diagram (also known as a collaboration diagram) below contains the components involved in the interaction and the flow or conversation between the components.

This describes the Business Service Request named GetListLedgerActuals, the Verb being GetList and the Noun being LedgerActuals. The response to this request is the List LedgerActuals.

 

It also describes the Business Service Request named Get LedgerActuals, the Verb being Get and the Noun being LedgerActuals. The response to this request is the Show LedgerActuals.

 

Also shown is the PostJournalEntry Business Object Document.

1. GetListLedgerActuals:  The purpose of the GetListLedgerActuals Business Object Document is to request information containing summary information for one or more ledgers.  The response to this request is ListLedgerActuals.

2. ListLedgerActuals:  The purpose of the ListLedgerActuals Business Object Document is to publish one or more summary listings of ledger information.  This may be in response to a GetListLedgerActuals request or published proactively as a listing of summary ledger information for a business event. 

3. GetLedgerActuals: The purpose of the GetLedgerActuals Business Object Document is to request specific ledger information.  The response to this request is ShowLedgerActuals.

4. ShowLedgerActuals:  The purpose of the ShowLedgerActuals Business Object Document is to supply the requester with the specific ledger information requested.  This may be used as a to a GetLedgerActuals request or as a push notification of an event (updated general ledger data).

5. PostJournalEntry:  The purpose of the PostJournalEntry Business Object Document is to transmit data necessary to create a journal entry from any enterprise application to the general ledger application.

59.2 Assumptions

This scenario is not intended to reflect when applications create data that causes changes in the account balances of a general ledger application.

This scenario does not cover posting to a cost accounting component.  This scenario also assumes that the details of the financial transactions will be kept in the sub ledgers.

59.3 Component Definitions

This scenario contains two major components, the general ledger component and the enterprise applications component.  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. 

This definition is a direct decision not to define how the processing takes place within any individual component.  The component must be able to perform the services defined by the business object document, but the internals of the component are not required or desired to be exposed.

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

59.4 Business Workflow (Sequence)

This scenario has two major events in the workflow sequence. 

1) The first business event in the sequence is the request/response style of messaging which the enterprise application sends a request message and expects to receive a response message back.  The general ledger application receives the request message and produces the response message that is sent back to the enterprise application.  The general ledger application uses information in the request message to know how to send the response message back to the enterprise application.  This scenario assumes that the general ledger component “owns” the chart of accounts definition and the instances of data within it.

2) The second business event in the integration scenario is the posting process itself. This process initially flows in the direction of the general ledger component from the enterprise applications based on any number of possible business events.  Some of these possible business events are described in the overview to this scenario.

59.5 Exception Handling

No exception handling for this scenario has been identified at present.

60.0 Vendor Managed Inventory (Consumption) Scenario Description

60.0 Overview

This chapter describes scenario, which would enable integration of Vendor Managed Inventory Consumption of goods. Showing the interface points between a Buyer and Supplier.

The purpose of this scenario is to enable the visualization of the components and the dialogs between the buyer and supplier.  This scenario is not meant to be the only correct model for integrating supply chain execution system components.  This is one model that may be used to design one’s own integration based on the specific needs of an organization or group of organizations. 

The scenario diagram below shows an integration that involves a Buyer and Supplier.

60.1 Scenario Diagram

The scenario diagrams below contain the components involved in the interactions, the dialog flows or conversation between the components, certain assumptions about the sequence of events, and assumptions about the technical approach.  The next section gives a brief overview of the components, the sequence of events, and the environment. 

Again, this is a MODEL to be used as a reusable design document, not a required approach.

The picture below visualizes a possible use of this BSR for supply chain integration.

The purpose of this scenario is:

1)       For a buyer of goods to inform the supplier that goods have been consumed, and replenishment will likely be required;

2)       For a retailer to inform the vendor that retail sales of goods have been made; and

3)       For plant data collection systems and warehouse management systems to inform inventory systems that goods have been consumed and inventory records should be adjusted accordingly.

 

 

60.2 Assumptions

These scenarios assume a loosely coupled, asynchronous approach to the integration.  Transaction management is implicitly required but not explicitly defined.

These scenarios describe a model for production execution.

The environment for this first integration is typically within an enterprise and within a division. The environment for this second integration is typically between two enterprises.

These scenarios also assume that one application will maintain the master data for integration. The Business Object Documents in the scenario diagrams are described in section three of OAGIS.

60.3 Component Definitions

The scenario contains two roles:

Roles:

1.        Buyer – The party that is purchasing

2.        Seller – The party that is providing a good or service.

Note:

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. 

This heuristic definition is broadly accepted by the designers of the integration scenario and is a direct decision not to define how the processing takes place within any individual component.  The component must be able perform the services defined by the business object document, but the internals of the component are not required or desired to be exposed.

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

60.4 Business Workflow (Sequence)

This scenario contains the following events in the workflow sequence. 

1.       Overall purchase, replenishment or vendor managed inventory agreement is in place.

2.       Message is sent to supplier, distributor or third party logistics provider, that material has been consumed.  This is done in response to events such as these, depending on implementation context:

·         Material is replenished to line side at manufacturing facility.

·         Material is assembled into final product.

·         Material is purchased and removed from facility by customer.

3.       Supplier, distributor, third party logistics provider replenishes material, using information provided in the Show Consumptn message, the demand and shipment forecasts, and the terms of the overall purchase or vendor managed inventory agreement.

61.0 Full Cycle Purchasing (non-production)

61.0 Overview

This chapter describes scenarios, which would enable integration of Full Cycle Purchase of non-production goods. Showing the interface points between a Buyer and Supplier systems.

The purpose of this scenario is to enable the visualization of the components and the dialogs between components for this specific integration domain.  This scenario is not meant to be the only correct model for integrating supply chain execution system components.  This is one model that may be used to design one’s own integration based on the specific needs of an organization or group of organizations. 

The scenario diagram below shows an integration that involves an buyer with a Purchasing System, Receiving System, and an Accounts Payable System; on the supplier side there is a Order Management System, a Shipping System, and a Billing System.

The Buyer places an order through the Purchasing System, to the Seller’s Order Management System the order is acknowledged. The Inventory system the inventory system fulfills the order internal to the Seller the Shipping system notifies the Buyer that the Shipment has been made the Buyer’s Receiving system receives this and the shipment. The Seller’s Billing system issues an Invoice.

 

61.1 Scenario Diagram

The scenario diagrams below contain the components involved in the interactions, the dialog flows or conversation between the components, certain assumptions about the sequence of events, and assumptions about the technical approach.  The next section gives a brief overview of the components, the sequence of events, and the environment. 

Again, this is a MODEL to be used as a reusable design document, not a required approach.

 


 61.2 Assumptions

These scenarios assume a loosely coupled, asynchronous approach to the integration.  Transaction management is implicitly required but not explicitly defined.

These scenarios describe a model for production execution.

The environment for this first integration is typically within an enterprise and within a division. The environment for this second integration is typically between two enterprises.

These scenarios also assume that one application will maintain the master data for integration. The Business Object Documents in the scenario diagrams are described in section three of OAGIS.

61.3 Component Definitions

The scenario contains six components along with two roles:

Roles:

1.        Buyer – The party that is purchasing

2.        Seller – The party that is providing a good or service.

Components:

1.        The Buyers Purchasing System

2.        The Buyers Receiving System

3.        The Buyers Accounts Payable System

4.        The Seller’s Order Management System

5.        The Seller’s Shipping System

6.        The Sellers’ Billing System

Note:

The Buyers systems (Purchasing, Receiving, and Accounts Payable) could be part of a single or possibly within different ERP systems within the Buying enterprise. Likewise the Seller’s systems (Order Management, Shipping, and Billing) could be part of a single or possibly separate ERP system in the Sellers enterprise

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. 

This heuristic definition is broadly accepted by the designers of the integration scenario and is a direct decision not to define how the processing takes place within any individual component.  The component must be able perform the services defined by the business object document, but the internals of the component are not required or desired to be exposed.

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

61.4 Business Workflow (Sequence)

This scenario contains the following events in the workflow sequence. 

1)       The first business event is something with in the Buy party identifies the to purchase something a Supplier is found. These steps are not addressed in this scenario, but are addressed in earlier scenarios found in this document. A Purchase Order is issued the Supplier it is received by the Suppliers Order Management System.

2)        The next step is for the Order Management System to accept, reject, or suggest modifications to the Purchase Order this Acknowledgement of the Purchase Order is sent back to the Buyer and received by the Buyer’s Purchasing system. From here there can be a series of exchanges to address terms conditions and availability. This dialog can occur using the ChangePurchaseOrder not shown in this workflow. For this Workflow assumes that the order is accepted and confirmed with the Acknowledge PurchaseOrder.

3)       The next step is for the Order Management system to communicate the order to the Inventory System such that the order can be pick and sent to Shipping. Since this communication is internal to the Seller it is not shown here.

4)       The next step is for the Shipping system to pack the order in to containers and send via a carrier. Once the order is packed and Advanced Shipping Notice (ASN) is sent to the Buyer via the Show Delivery BOD.

5)       The next step is for the Receiving system to receive the ASN and prepare for the shipment followed by the actual physical shipment. The Shipment then would be stored in inventory. It may also be sent to inspection depending upon the situation.

6)       The next step is for the Seller ‘s Billing System issues the Invoice for the goods sent according to the terms agreed to in the Purchase Order. The Buyer’s Accounts Payable System receives the Invoice.

7)       The next step is for the Buyer’s Accounts Payable System to pay the Invoice.