JTM supermarket scenario


This is a reconstruction of a two-page example that was used to try and explain how JTM might be applied in an non-RJE scenario. I can no longer remember where it was used or what reaction it invoked (mostly, "hmm, if there were implementations, then ...", I think). It was drafted by someone (me, 10 years ago) who knew JTM but did not have real experience of the commercial world. I have deliberately kept the original wording - the layout is a bit different because it did not seem worth making a very complicated webpage for this - the italic text in dark red was originally in call-out boxes to the side of the main text.
 
 

JTM and supermarket replenishment

Scenario

A supermarket store, having worked out which items need to be replenished, sends an order to a warehouse. The warehouse system then works out the loading list for the warehouse staff, lists of what is going on the lorry, and so on.

JTM would be an appropriate mechanism for transmitting the (electronic) documents involved - the store system creates a work-specification to pass the order document (a standardised document type) to the warehouse system. The warehouse system contains an "execution agency" that processes the order and generates several documents - the list of exceptions (items not available etc) the loading for the lorry (1 copy printed locally, one copy to go to the store), invoice. Instructions for the warehouse staff are not visible to JTM - they are considered to be part of the internal processing. JTM reporting allows the store to keep track of where the request has got to.
 

Advantages of JTM

Clearly the length of time it will take to fulfil the order makes it impractical to deal with the entire ordering process online. On the other hand, the distribution of the resulting documents needs to be under the contorl of the initiator of the order (i.e. the store system). This could be done by including the specification of the onward routing in the documetn, but using JTM provides a clean separation between the processing information and the specification of the distribution of the documents. JTM also provides facilities for the further distribution of an indefinite number of documents, distinguished by document type and name, which can be handled independently if desired.
 

Specification of the warehouse system

The following might be the information supplied to describe the JTM access to a warehouse system. Some JTM terminology is used.

The system supports a single execution agency with an agency name of SUPPLY.

Incoming work specifications should carry a single document of type <ORDER>. It is assumed that some other standard or register defines the document types that are represented as <ORDER>, <LOAD> and <INVOICE>. These document types do not include any of the routing or communication information

The work specification must include an authorisation element for the <Ae-title of warehouse system>, with the userid allocated by the warehouse management. Either the corresponding password must be supplied or the element may indicate that it has been checked at the store, in which case the transmission must be by authenticated meands. JTM has several features that support identification mechanisms, some of which make use of underlying authentication mechanims.

If the authorisation and the document are acceptable, the agency will give AGENCY-ACCEPTANCE commitment. The following documents will be available immediately:
 
 
Document name Type Contents
EXCEPTION <ORDER> Items unavailable, that will be NOT be supplied to this order
SUPPLYING <ORDER> Items that will be supplied

When the order (or part of it) is ready for despatch, the following documents will become available
 
 
LADING <LOAD> Items in the consignment

If the order is fulfilled in more than one consignment, all but the last LADING document will become available after a demand spawning with a proforma name CONSIGN. The lorry driver will have a copy of this document with hm, but the document is also available to JTM. Demand spawning - a JTM proforma can be spawned in response to a signal from the executing task, as well as at the beginning and end of the execution

On completion of the order, in additon to a last (or only) LADING document, the following document is available:
 
INVOICE <INVOICE> Invoice for supplied items

Proformas in work specifications

The following proformas would be appropriate in a work specification sent to the warehouse system. The proformas are "spawned" (become independent work specifications) at various points during the processing at the warehouse. Each can pick up documents made available by the processing.
 
 
Proforma when spawned use
one arrival picks up document EXCEPTION, sends to store system, where it goes into a file (ready to be modified and sent to an alternative supplier perhaps) but also prints hardcopy in the buying office
two arrival picks up document SUPPLIED, and sends it to store system, into a file
CONSIGN on demand picks up document LADING, returns to store, accessible to (printed and/or filed) at goods-inward, to be checked against the lorry driver's copy
four completion similar to CONSIGN, apart from the spawning control
five completion picks up document INVOICE, and sends it to the accounts department at the store (or possibly at its head-office)

(the proforma name CONSIGN must be that used in the demand spawning)

Where a document is to be copied to different systems (other than the warehouse system), there will be two proformas with similar <source references> with the first specifying COPY for the document, the last specifying MOVE. Where the document goes to more than one destination within a system (e.g. to file and to printer), only one proforma is needed, but the work specificaiton specifeis that the document is duplicated on arrival. Any of the proformas could also generate further automatic processing when they arrive at their destination.


Peter Furniss
sometime in about 1990, probably