‘Standing’ Orders in JDA Transport

I’m often asked by clients whether the JDA Transport module is capable of handling ‘Standing Orders’ or ‘Static Orders’ (meaning orders that repeat on a set frequency, often daily, and usually to the same origin:destination). My response has historically been ‘no’, but lately I’ve been saying ‘it is possible.’

Here is a summary of the scenario or business requirement – Give us (the client) the ability to replicate our standing orders daily without a feed from the host order management system. These orders always go from the same origin to the same destination, and often have the same pickup and delivery time window.

And my approach – First create an ITEM:COMMODITY that will represent the ‘generic’ commodity. You can also utilize an existing ITEM:COMMODITY if that makes sense as well. Then manually create the Static Order template in the Transport Order UV (or Transport WEB) with the following properties:

    Assign this ‘template’ order an Order ID with some logic behind it (ID must be unique, e.g. SYSDATE+ID+ORIGIN_LOC_ID)
    Assign the order to the correct SCHEDULE
    Assign the order to a specific ORDER GROUP (e.g. STATIC)
    Flag the order as UNALLOCATED
    Give the order the appropriate PICKUP and DELIVERY WINDOWS (use your own EA,LA,ED,LD logic)
    Set the appropriate ORIGIN and DESTINATION LOCATION
    Enter the generic ITEM and appropriate QUANTITIES for this order
    Save / commit to the database

Okay, that’s most of the base-data setup that you will have to do. You will setup one order template for each unique ORIGIN:DESTINATION combination (or maybe multiples, depending on your business situation). Next comes the ‘customization’ piece which will require some basic DB code development.

At a high-level, you will want to select only the STATIC orders (either select GROUP_NAME or some other ‘tag’), and only orders that are NEW or UNSCHEDULED and make a copy of each. The tricky part of the copy is likely the Order ID – being able to easily generate a sequential counter to apply as a prefix or suffix to the ord.id field would be very helpful. At the same time, apply some ‘constant’ (e.g. SYSDATE) to one or more of the Order Date fields, and map the remaining 3 dates and times against that value. The rest should be pretty easy.

From a business process standpoint, the users will see these Static Orders like normal orders and have the opportunity to consume (schedule) them manually or through an ASD. However, because the orders are ‘tagged’ as Static – they can be queried separately and managed independently of the normal HOST orders. If a Static order is not used within some pre-determined time period, I would update the status of these to CANCELLED, and then run a weekly script to remove CANCELLED orders from the active tables. There are many different approaches that can be applied here, and you can be creative with the flexibility.

The only drawback to using these Static orders is that they are not HOST managed orders. The Transport database becomes the system of record, and therefore communicating order or load information back to other OMS (SAP, Oracle, etc.) or to a downstream WMS could be challenging from a design standpoint. In a nutshell, you will have to find some way to either make these orders exist in your external systems, or figure out an approach that will allow you to circumvent them without negatively impacting business requirements.

So, aside from the tricks to the customization and some fancy footwork on the business process design side – this is a fairly simple and straightforward way to add some very valuable functionality to the Transport application. I encourage any comments, ideas, or other applications of this methodology either here on the blog, or in the forums.

About Brad Forester