Вы находитесь на странице: 1из 67


The OTM Demurrage Enhancement is a very robust feature that serves multiple
purposes to meet the needs of different clients. Clients who use carrier owned assets
can manage their expenses for holding the assets longer than the free time that is
allotted. Shippers, who use OTM and own assets that they provide to the customers
as temporary storage can use this feature to charge their customers for excess time
over the contracted free time. Also clients who must deal with shippers who ship too
early in carrier assets which accrue excess demurrage can use the feature to both pay
the carrier and to back-charge the shipper at different rates if desired. The basis of
the enhancement is a unique record that is called the Demurrage Transaction. This
record contains a complete account of all relevant events, dwell times, and charges as
well as the commercial information for related shipments. This provides a one place
lookup of information for both operations and financial users to manage their tasks.

The presentation is broken down into 4 basic parts. They are the overview, key
components, business examples, and configuration.

This is the overall process flow for demurrage. Tracking events can be entered
manually through the UI or can be imported from a vendor of event data. Both
sources are essential since this provides the capability for the suer to insert local
events manually. Additionally, any feed of events that can be constructed
electronically can be imported through the integration interface. A Tracking Event is
created for each event ad stands independently. Tracking Events can be received for
empty cars that have not yet been assigned to shipments. There is no requirement
that an event be associated with a shipment. An agent is configured to listen to each
event based on the status code of the event. This agent will contain the actions that
are necessary to match, create, and update demurrage transactions as needed.
Demurrage transactions are the basis for the financial or business user to process into
charges and to use these for charges for payabes or receivables. A report is also
provided to organize and display the charges.

The demurrage feature was designed to be a generic feature that was not specific to
any mode. Although rail demurrage is the role model for much of the configuration,
other modes like domestic and international intermodal can also be accommodated
since the rules are very similar. The user is able to name the charge using special
services. While the user is able to configure the charges and rules, we have
established 3 public charges to use for common scenarios. Demurrage is typically the
used as the charge for excess time that a patron, or railroad customer, may hold onto
the car while loading or unloading. Here, we associate demurrage with a carriers
charge for a carriers asset. When the carrier transports shipper owned assets, they
cannot charge demurrage sinc they are not recovering their cost of ownership of the
asset. Instead they call the fee for holding the car on carrier owned property the
storage fee. Typically the patron who pays storage does not have sufficient room to
hold all of their assets and must rely on the carrier to hold them. There is also a
charge for shipper owned assets that are leased or loaned to consignees during
unloading. This is called detention. It allows the shipper to sell to customers who do
not have storage facilities and typically use the car for product storage while it is
being sold or consumed. The charge allows the shipper to recover the cost of the
asset that is not covered in the sales agreement for the product.

Tracking Events are the key input to demurrage but not all tracking events are
relevant to demurrage. Here is the typical flow of an asset from the shipper on the
left to the consignee on the right. Demurrage will automatically be accounted for at
both locations when events are received. It is important to note that the role of the
client who has implemented OTM will determine the relevance of where and how the
demurrage is calculated. If the shipper in this example, Snowflake Stud Mill has
implemented OTM and is interested in the management of the empty cars that have
been provided for loading, they will only be interested in demurrage in Snowflake, AZ.
However, if Buena Building Supplies in La Mirada has implemented OTM, then they
are interested in the management of inbound load to La Mirada. The events in
between end points are for visibility only.

In this example, Buena Building Supplies is interested in managing the demurrage of
inbound loads. This graphic shows the events that are of interest during the cars
residency at the destination location. Please note that the events happen at the
station of La Mirada and NOT at the Buena Building Supply company location. This is
because events come in with a geographical reference which is NOT a location. The
reference can be a city, state, and country or a SPLC Code. SPLC stands for Standard
Point Location Code and is a recognized geopolitical coding convention. OTM has to
make sure that all relevant events happen at the same location so a generic location
with the role of RAIL STATION is created and there is a query that finds this UNIQUE
location. The unique location is essential because you could have multiple locations
that share the same city or SPLC. However, we do not lose track of the actual
destination either since the shipment data is also blended into the demurrage
transaction record.

The events that are received for any residency of an asset can be varied. Some may
be skipped and some may come in out of order. It does not matter since the
demurrage transaction collects them and they are arranged in order for later use
during the calculation process. Here is a list of possible events from the empty to
load sequence. Constructive placement can happen only once but it can happen at
a serving yard or right outside the consignees facility. Depending on the actual
sequence of events, the D event for arrival at the destination station can happen
either before or after the constructive placement. A typical sequence could be A
Arrival at Serving Yard, D arrival at the destination station, Y constructive
placement, Order In which is a user event, Z actual placement, and W the release.
Since the release is the only loaded move, this is where the outbound shipment ID
is attached to the demurrage record. After this happens, all events can now be
viewed in the context of the outbound shipment through the demurrage transaction.

Cars are sometimes bad ordered and not loaded. This demurrage transaction is
important to note because the shipper does not have to pay demurrage for a
defective car. There is no shipment involved either. The demurrage transaction does
not have to have a shipment attached. The tracking events do not have a shipment
reference either. This record had no context of any other OTM object, either
shipment or asset.

This sequence of events is similar to the bad order but differs in the fact that there is
a charge for ordered but not used. A Non Freight shipment would be generated to
support that charge.

As noted before, demurrage happens at generic locations and not at customer
locations. This is primarily due to the fact that events are reported at generic cities
and not customer locations. In fact the CLM, Car Location Message, does not include
any customer reference at all. In OTM we need a unique location reference when we
do demurrage by location so we need to create specific locations for the standard
open and prepaid stations and populate these with city, state, country and SPLC, if
SPLC is used. The saved query looks for these locations by the location role of rail

These locations are not required since the demurrage location can be simply
described by CITY, STATE, and Country and the matching process uses these. But
since there are spelling errors and also since the events can have variations in the
spelling, SPLC is the most secure and positive way to specify where the event
happens. But people do not talk SPLC so the translation to the location provides
for user friendliness.

Demurrage, Storage, Detention, and any other user named charge can be used for
any mode. The current configuration has a calculated duration in days and this
does not allow hourly charges. While this presentation is geared to a rail user, there
are no set events that must be used. The user is free to configure the rules to
recognize any series of events to start and stop charges as well as to report on those
events. This allows the user to manage ocean container charges from a steamship
line or domestic intermodal containers from a rail intermodal operation.

A user who wants to manage rail and intermodal can do so because OTM can
distinguish between rail and intermodal by the internationally recognized initials that
end in U or Z. This will be an aid to separate the records for reporting.

The next section talks about key components of the demurrage solution.

The key components of the demurrage solution are Tracking Events, Agents, The
Demurrage Transaction, The Demurrage Rules, the NFRC shipments, and the
Demurrage Reports. Tracking Events are the source of data for both visibility and
demurrage. Agents listen for each event code and perform actions to match, create,
and/or update the demurrage transaction record. The Demurrage Transaction is the
inventory record that is created that the business users will work with for details. The
Demurrage Rules are setup and maintained for the business of managing demurrage
and detention. The NFRC shipment is the object that is created to hold the charges
because only shipments can be rated by the rating engine. The Demurrage Report is
primary instrument that the business user will use for settlement based on this

Tracking Events are the primary source of information for demurrage. These events
can be received through integration from carriers or vendors of carrier data. Users
can also enter events in place of missing events and for events that are not carrier
related. One example is the order in event which is when the user tells the RR that
they want specific cars which are held in storage or constructive placement. It makes
a record of when the user orders in the car in case of a dispute on the actual
placement time if the RR is late with placement.

The Car Location Message is the industry standard for a public record with no
commercial reference. This makes the matching of shipments in OTM very difficult
because multiple shipments could be associated with that car. The best way to match
shipments is not through the Shipment ID because Rule-11 shipments span more
than 1 shipment but they do share a common Bill of Lading number. Vendors of data
can provide this BOL number as appended data to the CLM message or can provide
an EDI 322 format which does include that data. Also there are vendors that will
provide the message in XML and this is just another element. The BOL is a critical
data element to a successful implementation of Tracking Events. Other data
elements can be provided if needed.

The Key elements for events are the standard Who, What, Where, When, and By
Whom. We usually dont care about the WHY but in the case of the bad order, the
comb field does tell why. The key to the industry data is the initial and number
because the industry moves the assets and not the contents. The SCAC of the
reporting carrier is also critical since this is never assumed to be the service provider
since railroads hand off cars to other carriers during trips and the carrier SCAC is
key to matching the correct shipment, especially when it is Rule-11. We have already
discussed the use of City, State, and Country or SPLC, but did you know all messages
start out as SPLC and are translated to the City format for customer usability. The
Event code in the industry is a 4 digit code and it too is translated into Constructive
Placement or Released. OTMs data structure allows the user to directly improtb the
code but the user only sees the name so this is invisible. The date and time are
crucial and even more so is the TIME ZONE. Most providers will want to skip this, but
they do have the ability to look this up and to provide it. OTM requires this for
reliable reporting. LOCAL TIME is not good enough. As mentioned before the BOL
number is also key. It is a key piece for the release message after unloading as well as
it associates itself with the inbound shipments. This is also a standard industry
capability that must be asked for from the vendor. The Loaded flag is critical to
demurrage. The Destination City or SPLC is also critical for the Constructive
Placement logic.

The standard configuration requires that Tracking Event Agent be set up for each
event status code because each code has different action that must be configured.
We have provided examples as public data and the users should either copy and
modify these or create their own but not use the public agents.

This slide shows the details of a tracking agent. The actions in the red circle are used
for demurrage. The actions that precede the demurrage actions are primarily used
for the tracking event to establish the links with shipments and assets as well as to
set the agent variables that are used in both objects.

The first action to MATCH DEMURRAGE TRANSACTION is designed to see if there

already is an existing demurrage transaction for the residency. If one is found, we do
not create another one.

The next action to CREATE/UPDATE DEMURRAGE TRANSACTION has parameters that

are sensitive to load and empty for linking shipments based on the L flag on the
Tracking Event. A public saved query is provided for the ease of configuration.

The Demurrage Transaction is the primary object that contains the relevant data for
the residency of the asset. Some of the fields are de-normalized data to provide
information for the user without clicking the links to related objects and to also
provide faster, simpler queries for the finder/results and for the reports.
The user can configure which event or events that can be used to start the record and
to end the record. Agents are used to update the record with event information and
shipment information.
The user can select actions to run to process the record to complete the sections
of the record that are used to monitor and settle the charges that have accrued.
Each of the sections will be explained in detail.

The demurrage transaction header contains the location and asset information. The
information that is displayed here is based on an example where the event location is
represented by a SPLC code as the input. The Tracking Event agent finds the location
ID for the SPLC code and populates it on the Tracking Event. The City, State, and
Country are auto-populated from the Location. This adds to the usability from both
the functional perspective and from the user perspective. If the user decided to only
use CITY, STATE and COUNTRY, the other fields would be null. The matching between
the Tracking Event and the Demurrage Transaction use these fields and this is
The initial and number are required input. The AAR car type and Equipment ID would
be carried over from the Tracking Event if populated there. The Equipment type
come either from the Asset record if there is one or frm the join table with the
equipment group on the shipment when a shipment is matched.
The mode type is generated based on the initials. It is rail unless the initials end in U
or Z.

This tab contains the staring and ending events. The purpose of these events are to
set the status values for processing the liability and settlement reports. The L flag
on the starting and ending is used to determine the Activity Type which is used to
select the sub-part of the rule. The Activity Type is populated here when charges are
The event section contains the events the order of date and time. It does not matter
if they were received out of order as they are first grouped to the residency and
then used by the event status code.
Please Note that the status values are key to the processing of the transactions since
the Calculate charge action can only be performed on demurrage transaction having
DT_APPROVAL.DT_APPROVAL_NOT_APPROVED. These events control the start and
end states of the first status type. The user controls the second status type.

The tab for the Line Items is not populated until the Calculate Charge action is run.
We provide the ID of the best rule that was picked as well as all of the charges that
were generated. This example shows that more than one charge can be generated.
This if for the business case where the consignee is running OTM and they are paying
demurrage to the railroad. They are also annoyed with a shipper that ships too early
for their consumption which causes them to accrue excess demurrage. This charge
allows them to back-charge for the excess demurrage at whatever rate that they
desire. They can even cut the supplier a break with an extra day or so of free time.
When the charge is opened, the record contains the details that are important to the
charge calculation. The special service from the rule is populated. So are the dwell
days, credit days and debit days. Also the rate record that was used. IF the user
wants to edit any of this they MUST use the Recalculate Charge action.

The remarks tab is where the reference number and involved party will be
populated. Reference numbers and Involved parties are used for the shipper and
consignee rules. Typically, the agent that populates this is a Demurrage Transaction
type of agent. The agent that is configured in the test domain only fires upon create.
This assumes that there is a shipment in the system already. A consignee rule works
at the consignees location which is a shipment destination and there will always be a
shipment here for the loaded car. However, for a consignee to use a shippers rule, it
is advisable to get a Business to Business EDI transaction that is inserted as a
shipment as work (SAW) in place in advance of the cars arrival. This way the loaded
car will have a in this case will also have shipment that can be referenced. The
shipment must also have the reference number that the RR is using.

This tab contains the inbound and outbound shipment IDs and their details. These
details are de-normalized data and are provided for user convenience as well as for
the ease of finder queries and results population and also for the ease of report
generation. Since this demurrage transaction is an independent inventory, it can be
used for a number of operational purposes such as a list if all of the cars on CP at
Stockton with Paper Bags. A mentioned before, the demurrage does happen at a
generic location, but with this information, the user can zero in on a specific facility.
This is helpful if the OTM client has multiple facilities at the same station.

Demurrage Rules are highly configurable. They accommodate the widely different
rules that each carrier publishes for demurrage and storage. There is no standard
for demurrage although there are commonalities. Free time can vary by carrier as
well as holidays that are exempt. Times and charges can vary for the product and/or
car type as well as by location. Not all rules are system wide.
The design allows for the construction of rules for different situations. The context of
the user is most important in the design of the rule since they can be specific or
general and the best applies. When there is a tie based on the criteria, then the
first rule found will apply. Some criteria are hierarchical in design and the will be
discussed on the next slide.

This slide shows the criteria for the Demurrage Rule. The logic will select the best
rule based on the criteria. The rule is hierarchical in design. The contract number has
the highest priority followed by the involved parties. These rules are invoked by the
owner of the implementation and are overrides to any normal railroad rule. As with
example here, the consignee intends to pay the RR and create a back-charge so this
has a higher priority than the rule that just has RR demurrage. Regions are used
exactly like they are used elsewhere by the geo-hierarchy rule. The car type, owner
type, and the initials (marks) can be used for any rule. These can narrow down the
applicability of the rule. The equipment group profile and the flex commodity profile
need to be implemented with the care that your would take with profiles. There is no
all so you cannot have a null profile as a generic and a filled in profile as a specific
override. Instead you need to use the Negative Profile for any other or to
enumerate all possible commodities that may apply. OTM will pick the first rule that
works. The last line of criteria are for intermodal when the trailer is brought back to a
different facility that it was taken from.
Rates must be specified. There is NO lookup for rates. The user must specify the one
to work with the rule.

The charge detail is just a subdivision of the rule which allows multiple charges to be
created at the same time. This is the required solution that works with finding the
best rule since there cannot be 2 best rules. The activity type is the key to finding
the right charge. RR demurrage rules will have both load to empty and empty to
load. This example has 2 rules for load to empty since one is for the back-charge
and the other is for the charge. Remember, the L flags on the Demurrage
Transaction will determine the activity type. Shipment links are not used for this.

For shippers who use carrier supplied assets, the most common activity type will be
empty to load. This means that the inbound empty is not yet assigned to a load.
There is no BOL number so there is no shipment link to be created. The Tracking
Event stands alone. The Demurrage Record with be automatically created and linked
to the Tracking Event. The first event could be Constructive Placement or Actual
Placement. The last event will likely be Released. When the last event is received,
it will be because the shipper has released a loaded car to the carrier and the carrier
now has the BOL number. This message will now append the outbound shipment
information to the demurrage transaction.
There is one major assumption. This is that the CLMs for the empty cars that are
enroute will be in your event feed. The vendor of information that is providing the
event stream must implement a parametric trace to catch these records. It does
absolutely no good to start collect CLMs after the car has been shipped if you want to
manage your inbound empty car demurrage.

This slide shows the details of the charge days that could also be called a sub-rule.
The activity type is used as a primary criteria but also in the logic for how the free
days are used. For example a load to empty rule would only look an unloading days
plus the bonus days for own switching days that some railroads provide for patrons
that have their own switch locomotives and crews. The special service that is to be
used for this charge is specified here. The public data provides DEMURRAGE,
STORAGE, and DETENTION. The user is free to create any that they like. The Rate
Offering ID can also be defined on each charge and is not mandatory as it overrides
the Rate Offering on the Demurrage Rule. Likewise, the Rate Record ID can also be
defined on each charge. It is not mandatory and overrides the Rate Record on the
Demurrage Rule. This allows the rate record to be specified at the charge level since
they will always be different.

The demurrage rate record contains the typical elements that any rate record would
contain. The difference is that the rate record is not found by the standard process
but is specified by the rule since they are required fields. A new Rate Basis Item
was created for this enhancement that rates the duration of special services. This can
also be used as a conditional when modeling Marginal Rates. This slide shows the
read only UI for the Rate Record and it should be noted that the times are
expressed in seconds. The next slide will show how the rate is configured in the edit

The Basis MUST contain the special service because that is specified on the charge
and must match. It is very likely that a carrier will have charges for demurrage and
storage. Even though the rate record is specified, there is validation that is part of the
general rating workflow.
The new Rate Basis Item (RBI) for Shipment Special Service Duration is configured in
DAYS since the time that is passed into the rating engine is only specified as days.
This is part of the logic that uses the free days, the dwell, and the offset to calculate
the chargeable days.
When the user wants to model rates that escalate, the RBI must be used as a
conditional and the Marginal Cost flag must be checked.

The offset is the most complicated part of demurrage since the charges do not begin
at precisely the time that the cars was placed and end at the time that the car was
released. Charges are based on full days and not fractions. Typically, they start at
the first midnight after placement but this is also qualified by the day of week and
any holiday. The technical definition is provided as a note for those who may be
interested in the details and as an aid to setting up the this object. It will not be part
of the narritive.

Notes: Not part of the narritive.

The Offset API is used to determine the offsetdatetime of given starteventdatetime
for given offset ID. The determination of offsetdatetime will be done as follows.
First, it will check if the given datetime falls between any eventstartdate and
eventenddate defined in the offset override definition of given offset ID. If so, it will
take the offset days defined for it and append it to the starteventdatetime, and
further it will set the time of starteventdatetime to offsettime defined. Suppose, if
the starteventdatetime is 21st,May 9:30 and if offset days defined as 2days and time
as 18:00 then, the offset datetime will becomes 23rd,May 18:00.
If no overide definition mathces with given OffsetId and starteventdatetime, the it
will get the dayofweek of starteventdate and check if it matches any dayofweek
defined in the offset definition. If so, it will take the offset days defined for it and
append it to the starteventdatetime, and further it will set the time to offsettime
Finally, if no overide/definition matches, it will simply return the given
starteventdatetime as offsetdatetime with out any change.
This API will be used in while determining the dwell days and freedays in
calculatecharges functionality. 36
Remember that demurrage and storage charges are not part of the transportation bill
from a carrier. They are based upon a separate agreement for service at a siding at
a specified location. The patron, which is the railroads term for a customer, enters
into an agreement to abide by certain rules that include the payment of demurrage
or storage charges. These are settled periodically and independently of any other
charges. When the client implements OTM, they will most likely fit the description of
a shipper or a consignee but sometimes both. Typically they will use either RR
supplied cars or private cars but sometimes both. OTM can handle all combinations.
For illustration purposes, it is easier to talk about the 3 primary cases. These are the
shipper who is concerned with INBOUND empty cars. The next is the consignee who
is concerned with INBOUND loads. And the third case is the shipper with private cars
that is trip leasing cars to customers who will hold these shipper owned or leased
cars as temporary storage while the product inside is either sold or consumed.
An additional benefit of the enhancement is inventory visibility since the demurrage
transaction is also an independent, perpetual inventory record.

The most critical key to the management of demurrage is a good supply of event
messages that include the arrival of the car to start the demurrage clock. Since ALL
demurrage, storage, or detention charges have a starting event, it does no good to
start capturing data when the cars is released.
A good vendor of event data is capable of providing the service to parametrically
capture the events of cars that are waybilled to a patron based on the patrons ID
which is usually a DUNs number. This is also based on internal railroad waybill data
that is not available to the public. Alternatively, shippers that order cars can track the
cars that the railroad has assigned to them in fulfillment of each days order. The date
of want is also considered the want date. If this date is entered into the demurrage
transaction, OTM will also consider it.
For inbound loads, it is recommended that a shipment be entered into OTM prior to
the arrival. This does not have to be an OTM generated shipment although some
clients do model their inbound. The easiest way to do this is to request an EDI
business to business message that will be imported as a SAW. It is important that
this shipment contain the BOL reference that was passed to the railroad or carrier so
that their reporting can be directed to that shipment if it is desired to make the link
automatically. We have also provided the ability to edit the Tracking Event and to
reprocess if this is must be done.

The examples that are provided are for railroad demurrage at both the shipper and
the consignee. Also and example is provided for shipper collected detention. The
back-charge example was used as the illustration for the demurrage transaction.

A railroad demurrage rule is usually implemented as both inbound and outbound
although some clients may not need to do this because only one activity type applies
in their case. As you know by now, OTM will automatically create demurrage records
for every case where there is a CP, AP, or Release or where you have configured a
rule. For shippers, a demurrage rule can be very useful to calculate and monitor
customer car retention time or monitor inventor at customers even though you have
no position in the payment of either storage or demurrage charges. The data can be
harvested through a report.
This example is for fictitious demurrage charges that Union Pacific would levy for
railroad owned covered hoppers as defined by the equipment group for the
commodity of beans. The charge applies system wide. The flexibility of the definition
of parameters allows the user to be as generic or specific as needed to match the
published tariff.

This shipment resulted in the automatic creation of 2 demurrage transactions. The
first was at the shipper in Menomonie, WI and the Second at the consignee in
Stockton, CA. A query based on the car initial and number pulled these results. The
finder screen has many, many fields which allow the user to define an endless array
or finder saved queries for quick retrieval of results. Only the header from one
demurrage transaction is shown.

In this slide, we see that the shipper received an empty car on 6/5 and released it as a
load on 6/11. There were 6 days of dwell. The rule, UP RR COVERED HOPPER BEANS,
allows one free day for loading so we calculate 5 debit days at a cost of $105 per day.
The demurrage transaction now contains the charges. As mentioned before, the
outbound shipment details are provided. This provides ample information to
formulate reports as well as to pay the railroad for the demurrage.

In this slide, we see that the consignee received an loaded car on 6/26 and released it
as a empty on 6/30. There were 4 days of dwell. The rule, UP RR COVERED HOPPER
BEANS, allows two free days for unloading so we calculate 2 debit days at a cost of
$105 per day. The demurrage transaction now contains the charges. As mentioned
before, the inbound shipment details are provided. This provides ample information
to formulate reports as well as to pay the railroad for the demurrage.

A shippers detention rule is usually implemented as a one activity type since it
deals with the use of the car by consignee. The rule can be setup to apply to any
shipment made specified contract number or to a consignee at a specific location or
at any location. It does NOT have to be on a specified RR although it could be so
qualified if desired. This rule applies to a specific consignee for private cars that
contain beans anywhere in North America. Since this is not a railroad rule, the
shipper can define the starting and stopping events, free time, and charges as they
see fit. The railroad would only be able to collect storage charges on private cars
because they do not own them and the storage rule would have different start and
stop events.

This shipment would result in the automatic creation of 2 demurrage transactions.
The first would be at the shipper in Menomonie, WI and the Second at the consignee
in Stockton, CA. We only modeled the second transaction for this example. A query
based on the special service of detention for the customer at Stockton pulled these
results. The finder screen has many, many fields which allow the user to define an
endless array or finder saved queries for quick retrieval of results.

In this slide, we see that the consignee received an loaded car on 3/5 and released it
as a empty on 3/12. There were 7 days of dwell. The rule, MENOM DETENTION
BEANS CORN PROD, allows four free days for unloading so we calculate 3 debit days
at a cost of $75 per day. The demurrage transaction now contains the charges. As
mentioned before, the inbound shipment details are provided. This provides ample
information to formulate reports as well as to collect payment from the consignee.

The user of demurrage will most likely not be the one who configures the agents but
will most likely work with the demurrage transactions and the demurrage rules.
However Rules could also be for a specialized user but that wont be a given since
the business of using this functionality is not narrowly defined. For example, a client
that is interested in the management of RR demurrage will have a person use the
transactions to create reports that look just like the RR supplied invoices. The format
of the report will allow the validation of individual transactions and user will have the
capability to flag bad transaction or correct the transaction and reprocess, or
approve the transaction by setting the state. Then the report can be run and settled.
Bad transactions can still be pending with the demurrage transaction holding the
evidence to dispute a charge.
Other users who are in the business of managing receivables for detention charges
that their customers have accrued will likely be configuring the rules and rates as well
as drawing the reports. None of this would require a request to the IT department.
However the report creation would require their skill sets.
Operational users will find the perpetual inventory very handy and will be able to use
this record and its external status capabilities for yard management of assets as well
as the generation of switch lists and messages to extrenal parties. The tools that
have been provided will allow the implementer to configure these capabilities with
reasonable effort.

The finder criteria is very extensive. In the last 2 examples we made one search using
the Initial and Number. We made another search using special service which
represents the charge name and the consignee name and station. All of these
queries can be saved as saved queries and given names so that users can simply run
the query when needed.

This screen is customizable so that different versions can be saved as different screen
sets and named for the user that would use the finder and results tools.

These actions are provided for the user to manipulate the demurrage transaction
records by adding charges, changing states, and sending messages. The action to
Calculate Charges works when the transaction has not yet been approved by the user
as that would lock any additional changes. The action finds the best rule, calculates
the debit days, and calculates the charges. It also creates an new NFRC shipment each
time it is run. The Recalulate action will not search for a new rule but it is helpful
when the DT has been edited like to change the days. The action to Change External
Status will be used to set the approval from ON HOLD to APPROVED. It will also be
very useful if the user has set up their own external status types and values to
manage their inventory. Send Interface tranasaction is standard functionality and is
how the user sends a message that would include a list of demurrage transactions.
The user would have to customize the message to only include the selected fields.

The reports us the standard Oracle BI Publisher report functionality. There are two
primary types of reports that would be used. These are the settlement report and
the liability report. The key is the approval status. When a record has been created
by the CP or AP but the car has not been released, the user can calculate charges
based on releasing today. This would create a deemed release date and the
charges would reflect the liability that has accrued to date. Once the car has been
released and the user has approved the charges by setting the approved state, the
demurrage transaction record would be picked up in the settlement report. The key
is that the report criteria contains the approval status. Reports are usually run on a
periodic basis. The reports will look like the carrier reports and the user can perform
a line by line validation of charges.

This slide shows the search criteria for the demurrage report that is found in the
Business Process Menu for the Report Manager. This example is for a Detention
report for all customers in Stockton. The assumption is that a shipper is the
implementer of the OTM instance and the context is that they are the shipper.

The report contains a header and detail section for each unique combination of
contents in the categorical fields that are shown above. The reason that there are 2
section breaks here is that the equipment type is different. There are 2 series of
leased cars and there may be different rates for each. If there were more cars for
each equipment type, there would be more rows under the mini-header.

There is one action to match the Tracking Event to The Demurrage Transaction and
make the link. The Matching Method is configurable by the parameters that are
shown on the next slide. The Matching Location is not the same for Actual Placement
and Constructive Placement. That is why the dropdown is provided and the car
destination location is used for the Constructive Placement. This is because if the CP
location is different from the AP location, we are going to only count the demurrage
at the actual location because this is where the release will happen.

These planning parameters are for the user to establish preferences. The contract
number needs to be copied to the demurrage transaction where we use it as a
criteria. Since the copy function was revised to include translation abilities, that
makes that job easier. However we do need to tell the logic the qualifier to use for
the lookup. The default rule set is exposed in the rule set parameter and this can be
changed if needed. The matching criteria are also configured here.

The agent action to create or update the demurrage transaction must follow the
action to find an existing transaction. If one is found, then there is no need to create
a new one. This action was developed with the intend that it would fit all events with
changes to the configuration. The first choice is if the event represents a start or end
event to start the Demurrage Transaction and set the status values. The check box
for the CP location is only applicable to the CP event. The demurrage location is
always the location of the actual placement and release but for CP, we must use the
destination location since that is where the demurrage will be charged. The next
choice configures where the related shipment should be placed. If there is an
inbound load, then the shipment is an inbound shipment. The last field has to do
with the report and it controls the column where the date is to be placed. Column
placement if for the report only and is not looked at by the rules.

This query is part of the agent logic and will likely be used by everyone so it has been
provided as a public saved query.

This action is now configurable translate the qualifiers when copying reference
numbers and involved parties from one object to another object. In this example
the inbound shipment had a reference number with a qualifier of CONTRACT_NO and
it was desired to use this same value in the Demurrage Transaction as reference
number with a qualifier of CONTRACT_NUMBER.

This is an example of a Demurrage Transaction type of agent which runs upon create
since it is intended to work only with inbound loads. Involved parties and reference
numbers are copied at the same time.

This action, which has been previously described in the agent slide uses a saved query
to fetch the location with the role of rail station. The data is setup so that there is
only 1 location that is returned by the query. The user does not have to take this
approach as the matching is not mandatory by location. It does make sense to do
this when bringing in locations by SPLC because the quality of the data is much higher
since with city there can be spelling variations even from the same carrier. This is
all about reliability.

OTM specific resources including TOIs, Education, and My Oracle Support information are
listed on the next few slides.