1

Welcome to the Oracle Transportation Management Transfer of

Information session explaining the enhancements to tracking events in
the OTM 6.3 release. This functional overview provides a high-level
description of the key changes in tracking events for the OTM 6.3
release.

This session will prepare you to:

Identify the new functionality in this release
Learn how the new features address business needs
Understand any dependencies or interactions
Find additional release information and resources

In this session we will cover the changes that were made to tracking
events in OTM 6.3. But before we do this, we will first look at the
history of this feature so that we can understand why these changes
were important. By first reviewing a background on shipment events
and tracking events we will better understand the limitations of
tracking events before the release of OTM 6.3, leading up to the
changes that were implemented in this release.

First, lets review the background of shipment events.

OTM has historically depended on shipment events to record events

against a shipment. Traditional shipment events include PICKUP,
DELIVERED, and DELAYED messages. These messages play an
important role in providing visibility to the status of a shipment and
allow planners and customer service personnel to manage changes to
the plan.
When shipment events are submitted they can simply update the
shipment with an event or they can additionally raise lifetime events to
perform other actions. OTM uses a special automation agent called
the Shipment Event Tracker to raise these lifetime events. Next well
look at the Shipment Event Tracker in more detail.

The SHIPMENT EVENT TRACKER automation agent is used to

specify how OTM should react to a buy shipment event. For example,
if a shipment event comes in that reports a delay, another lifetime
event can be raised to notify interested parties or to redrive the
shipment using the new information provided. New appointments or
stop times can be calculated and new internal statuses can be set.
Shipment statuses can be updated based on the shipment events
received such as shipment COMPLETED or shipment ENROUTE
statuses.
OTM ships with one main PUBLIC Shipment Event Tracker
automation
t
ti agentt which
hi h covers th
the mostt common buy
b shipment
hi
t eventt
actions. There are also shipment event tracker PUBLIC agents for sell
side shipments and shipment groups which are not covered in this
TOI.

Here is a view of the agent body of the PUBLIC SHIPMENT EVENT

TRACKER automation agent. From the screen images we can see that
there is logic to manage many typical shipment scenarios. This logic
can be customized to meet your specific requirements as needed.

10

How does the Shipment Event Tracker work?

First a shipment event is received which specifies a status code. A
status code could be Delayed, Departed, Traffic Delay, etc.
Status codes are collected into event groups, depending on the
attributes which describe them. For example, PICKUP and DEPART
are part of an event group called DEPARTED. Traffic and Customs
delays are part of the DELAYED event group.
Each of these event groups has attributes which describe them
when a status code is recorded the attributes of its associated event
group are raised. The SHIPMENT EVENT TRACKER listens for
activity among these Event Group Attributes and responds
accordingly.

11

Here is an example of an event group called ARRIVED. There are

four status codes which are a part of this Event Group: AR, BA, X1
and X3. These are listed in the first red box.
The second red box highlights the attributes which are part of this
event group. Any of these four shipment statuses, when received, will
raise the ARRIVAL
ARRIVAL_OR_DEPARTURE
OR DEPARTURE attribute and
ESTIMATE_OR_ACTUAL attribute for further processing by the
shipment event tracker.

12

Now that weve reviewed the background on shipment events and the
shipment event tracker, well look at tracking events and how they
differ from shipment events.

13

Tracking events were introduced in OTM 6.0 as a replacement

method for submitting shipment events in OTM. Unlike shipment
events, which only apply to shipments, tracking events were designed
to be generic enough to apply to multiple business objects within
OTM. As of OTM 6.0, tracking events could be used against
shipments, order releases, order bases, equipment, power units, or
drivers.
Another advantage of tracking events is their ability to be
reprocessed, meaning that they can be edited and/or resubmitted if
processing of an event failed for any reason. This is not possible with
shipment events.
Because both shipment events and tracking events are sent into OTM
g the same XML file,, yyou needed to select which type
yp of event to
using
use to process your shipment events. This selection was made via a
global property called glog.shipmentevent.processingflow. Once
configured, incoming events would be directed to the appropriate
workflow.
If the property was set to trackingEventAgent, OTM would process
incoming
g events as tracking
g events. In this initial release of tracking
g
events, you needed to configure all rules matching events to their
respective shipments.

14

With the growing use of tracking events came the need for more
flexibility. Rather than configure the shipment event workflow at a
global level, customers such as logistics service providers needed the
ability to have only certain domains, roles, or users implement tracking
events, with the remainder of their implementation using shipment
events. In 6.2.2, OTM introduced a parameter called USE TRACKING
EVENT AGENT FOR PROCESSING FLOW to allow for this flexibility.
Even with this additional flexibility there were still many improvements
needed in the tracking event feature. These improvements centered
around providing functional equivalence between shipment events and
tracking events. These improvements will be the focus of the remainder
p
of this presentation.

15

Next, lets review some of the limitations of tracking events in previous

versions of OTM.

16

Because tracking events were intended to replace shipment event

functionality, at a very minimum they needed to have parity with
shipment events. The gaps between these two features include:
1. Missing fields on the Tracking Event page, including: the Notify button, a
Communications and Remarks section, order base details and ship unit
quantities. We will review these gaps in greater detail on the next slide.
2. The inability to automatically match to shipments. Tracking events require
you to create a matching automation agent,
agent even if the shipment-related
shipment related
tracking event was entered via the Shipment Manager.
3. An inability to raise shipment-specific lifetime events via the SHIPMENT
EVENT TRACKER automation agent. Without this ability you could not
reproduce the detailed responses to shipment-related events that the
shipment event functionality provided.
4. An inability to filter the list of responsible parties on a tracking event. These
responsible parties control the status codes and reason codes that appear in
their respective drop-down boxes. You can see the Responsible Party dropdown list in this screen shot.

17

Here is a close-up of the major differences between shipment events

(via the Add New Event page) and Tracking Event page.
1. In the Event Reason section of the Tracking Event page, the Notify button is
missing. This button is used to immediately compose and send a message
from the event entry page.
2. The Communication and Remarks section is missing from the Tracking Event
page. Here you would enter a contact name and comments.
3 The third red box on the Add New Event page highlights the Order Base ID
3.
section which appears for shipment events but is missing from the Tracking
Event page. In this section, you can enter details about the Order Base.
4. Finally, the Tracking Event page is missing the Enter Ship Unit Info section,
containing Ship Unit ID, Packaged Count and metric information. This is often
used to send in actuals information about the shipment.

18

Next, lets review the changes made to tracking events in OTM 6.3.

19

Now well start reviewing the changes made in 6.3.

As expected, the gaps shown on the previous two slides have now
been closed:
1. All missing fields are now available on the Tracking Event page.
2. You can now match Tracking Events to more objects using the Match Object
by Tracking Number agent action
action, including shipment ship unit
unit, shipment ship
unit line, order release ship unit, and order release ship unit line. You can also
match events to two new OTM objects, namely documents and demurrage
transactions. For more information about these new objects please see the
related TOI presentations. Also, notification capability has been added for all
supported objects.
3. All shipment event logic can be written directly as tracking event automation
agents now, so the full capabilities previously offered to only shipment events
are now available to tracking events. All event group attributes are available
as variables on the tracking event automation agent.
4. You can use either event groups or status codes to define tracking event
automation agents. By comparison, shipment event automation agents could
only be configured using event groups. You would set these up using the
Restrictions section on the automation agent. Well look at this more closely
next.

20

Not new for 6.3, but an important concept to convey is that you can use
the Restrictions field in the Agent Events section to limit the codes used
to trigger an automation agent. Whereas you might be used to seeing
typical Restrictions values of Internal, Integration or User, a tracking
event processing request agent event has Restrictions which will
allow you to select specific status codes.
In this example we have chosen six status codes to restrict the
triggering event: X4, X5, X6, X7, X8 and X9. Only events with these
codes will trigger this automation agent.

21

 In addition to closing the noted gaps, several general enhancements were also
made to tracking events.
The PROCESSING FLOW property and parameter the ones that told OTM to
process the incoming event as either a shipment event or a tracking event
have been removed. All incoming messages are now processed as tracking
events.
You can now configure the list of responsible parties that can be selected on a
tracking event. With this capability comes the ability to dynamically control the
available list of event codes and reason codes that are displayed when you
create a tracking event. A special note to consider: this feature limits the
available codes against all objects, not just shipments, so limiting the
Responsible Party drop-down list to include only shipment-related codes will
mean that other codes will be unavailable for non-shipment-related events.
In order to ease the transition away from shipment events we have introduced a
new manager called the Shipment Tracking Event manager which is
essentially
ti ll a customized
t i d version
i off the
th Tracking
T ki E
Eventt manager tto make
k it llook
k
like the former Shipment Event manager. This manager can be further
customized via the familiar custom manager layout controls.
With this change also comes the removal of all shipment event-related options in
the main menu and actions menus. If necessary, these shipment event menu
options can be added back in via customization; however the preferred path
forward is via the use of tracking events.

22

On the right is a view of the new Shipment Tracking Event manager.

Those that are used to the former shipment event manager should find
a similar look and feel in this layout. As mentioned in the previous slide,
all references to shipment events in the default menus have been
updated to now point to the new Shipment Tracking Event manager
layouts.
To access the Shipment Tracking Event manager, select a shipment
and go to Actions > Shipment Management > Events and select either
Add Shipment Tracking Event or Add Tracking Event.

23

Although it is strongly advised that you migrate from the use of

shipment events to the use of tracking events, we recognize that a
transition period may be necessary to make this change. In order to
facilitate this transition, a new automation agent has been created to
allow tracking events to be processed like shipment events, effectively
allowing you to continue using all existing shipment event-related
agents. This new automation agent is called the LEGACY SHIPMENT
MATCHING automation
t
ti agentt and
d iis iinactive
ti b
by d
default
f lt iin OTM
OTM.
When activated, it will match the tracking event to a shipment using the
shipment GID, shipment reference numbers, an equipment number, or
an integration saved query. If a match is found, a SHIPMENT_STATUS
TRACKING event will be p
published for the event g
groups
p that have the
IS_TRACKING attribute set to Y. This in turn triggers the PUBLIC agent
SHIPMENT EVENT TRACKER (if it is active) or any other agents that
are listening to this event.
Only one instance of this automated agent is needed. Once activated it
applies to all shipment event
event-related
related agents
agents.

24

If you do decide to continue to use shipment events there are some

additional things to consider:
First of all, shipment events in 6.3 are technically processed as tracking events.
The LEGACY SHIPMENT MATCHING agent that we just discussed simply
enables certain shipment-related tracking events to be processed by the legacy
shipment event agents.
You are strongly urged to recreate all event workflow using tracking event
agents.
agents
There is no advantage to using the traditional shipment event links. All of these
links have been recreated as shipment tracking event links and all functionality
has been preserved via the use of tracking events.
Adding shipment event links back into OTM should be considered a temporary
change as it is Oracles intention to completely deprecate this code in a future
release.

25

It is possible to make additional customizations to the Shipment

Tracking Event manager layout and to make this new layout available to
users. In order to do this you should follow these steps:
1. First, create a custom manager layout.
2. Second, create a custom screen set and assign the custom
manager layout
l
t created
t d in
i step
t one.
3. Finally, assign this screen set to the user via Manage User Access
under User Configuration. In the Manage User Access screen youll
find a User Access Type drop-down with a value called Field Screen
Set. When you edit this User Access option you would either create
or edit the Query ID called SHIPMENT_TRACKING_EVENT and
provide
id the
th S
Screen S
Sett ID you created
t d iin step
t ttwo.
This custom layout will then be used for this user.

26

And finally, lets review some additional resources.

27

28

OTM specific resources including TOIs, Education, and My Oracle

Support information are listed on the next few slides.

29

30

31

32