Scenario 90 - Scale Ticket for Inbound Bulk Delivery

90.0 Overview

Scenario #99 describes the integration of business software involved with the process of a supplier transporting a bulk shipment of raw material. The value of the bulk raw material is determined by destination weights and grades.

The purpose of this scenario is to describe the participants in a mainstream business process, and to illustrate how the business systems of those participants can be integrated through messages exchange to realize the goals of that business process. This scenario is not meant to be the only model for integrating customer applications to lab information management applications. It is simply one model that may be used to guide one’s own integration efforts.

Since the function and composition of the business software components that might be used to produce or exchange the information described in the scenario vary widely, specific software components will not be described. Software components which might be involved in realizing this scenario include:

  • Enterprise Resource Planning system/ Receiving
  • Farm Management Information Suystem
  • Inventory Management System
  • Integrated Certified Scale with Load cell

This is not a complete list but is meant to be a representative sample of systems that might be involved in generation or exchange of the information involved in the Scale Ticket for Inbound Bulk Load process.

90.1 Scenario Diagram

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

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

90.2 Assumptions

This scenario depicts a loosely coupled, asynchronous approach with transaction management required but not explicitly defined. Most modern implementations will use a RESTful approach.

This scenario describes how one or more components of a Supplier’s business system can interact with the Customer’s business application for the retrieval of a scale ticket for a specific shipment.

The scale used for measurements of gross and tare weight has been certified and it has been calibrated to specification.

The scale ticket does not include contract allocation(s) for the shipped raw material, the splits between these contracts, and splits between parties. It also does not fully address rail or barge shipments.

If a scale is NOT integrated with a process control system and subsequently the ERP used by the end customer, manual data entry of scale measurements are used.

One can also leverage the Scale Ticket for outbound shipments from a Supplier to Customer, where origin weights and grades are allowed. The tare weight is measured first, and the gross weight measure after the raw material is loaded.

90.3 Participant Definitions

This scenario contains two major application: Enterprise Resource Planning (ERP) and Farm Management Information System (FMIS). The FMIS can be a fit-for-purpose ERP to manage the farm, or as simple as a mobile application. The definitions and details of these applications are left to the designer but are assumed to contain the functionality as defined by what is commonly sold in the commercial marketplace today. This definition is broadly accepted by the scenario designers and is a direct result of the decision not to define how the processing takes place within any individual application.

Typical capabilities of these participants are described:

  • Customer is the participant that receives the raw material or commodity shipped in bulk.
  • Supplier can be a farmer, or other raw material provider that has a purchase contract with the customer.

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

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

Note that the evolution of eCommerce has yielded independent trading exchanges and other intermediaries between business operations and inventory management providers. Requirements and operations for intermediaries should be similar to direct links between the two components.

90.4 Business Workflow (Sequence)

The business workflow is graphically represented by starting at the Scenario top and reading from top down and from left to right. The arrows in a sequence diagrams shows the message exchanged, and the response to the message.

The sequence diagram illustrates the data exchanges involved within the business process specification for an shipment inbound to a Customer.

  • The first business event in the integration scenario is where the Supplier sends a NotifyShipment BOD to the Customer, which identifies the shipment identifier, and the raw material that is sent in bulk.
  • On arrival of shipment, a truck positions itself onto a certified scale with the raw material in the Shipment Unit (container). The gross weight measurement is captured.
  • Samples are taken similar to the Incoming Inspection scenarios for Inspection Order, which is not shown. Depending on the raw materials, different tests may be performed.
  • Test results are recorded in the Customer’s ERP.
  • After the clearance, the driver / operator will unload the raw material in the manner required by the Customer. This can be a dump into a pit for agricultural commodities, which are then routed to storage bins.
  • After unload of the Shipment Unit, the driver is instructed to ‘scale-out’ to obtain the tare weight of the vehicle and shipment unit without the raw material.
  • The Net Weight is calculated and recorded in the ERP.
  • The digital Scale Ticket is provided to the Supplier, providing the scale measurements and results of the tests performed.

What is not shown in the diagram are the instructions related to the physical movement of the samples to the laboratory if required for certain raw materials.

90.5 Exception Handling

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

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

  • If the information was not received or understood, or contained errors of any type, it is accepted practice for the OAGIS users to presume that the data was not acted on.

  • In the absence of a Confirm BOD within a previously agreed time limit (e.g., SLA, normally defined in an out-of-band agreement), the originator will resend the original message.

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

Feedback

OAGi and its members welcome your feedback.