Back in the old days, a carrier’s data belonged to the carrier.  We’re talking about tracking equipment, primarily the truck.  Satellite tracking then, cell phones or on-board units using cell service today.  What has changed is access to the data.

With the advent of service companies like FourKites, MacroPoint, and 10-4 Systems, data regarding the truck’s location is made available to the owners of the shipments, the shipper.  How?  The carrier provides a skinny data file to the service company (say FourKites) with the shipper name, shipment ID, and truck number.  If necessary, the file will also include the drivers cell phone number.  With this skinny file, the service company will ping the on-board device database (i.e. Omnitracs, Rand McNally, etc.) to gather the location data, then report it to the shipping customer.  If no on-board device exists, then the driver’s cell phone will be pinged for the current location.  Either way, the service company can report the location of all shipments to the shipping customer in near real time (ok every 15 minutes, but not bad).

Some carriers will ask, why do the shippers have to know exactly where the truck is? To update a nice visual on a computer screen?   This may be round one.  Round two is focused on predicting a shipment’s arrival to its destination.  Not 100% as of this posting, but it’s in the works.

You may wonder, can’t carriers simply pass this data directly to their shipping customers?  Of course they can, and they do.  But that is a lot for a shipper to coordinate, especially if they work with lots of carriers.  Some shippers do exactly that, but others now have the option of using a service company as described above.  Makes for a one stop shopping, convenient approach.

But back to the carrier.  Will drivers submit to being tracked all the time?  Do they have a choice?  Given the current high turnover of truckload trucking, this latest trend will likely not help the situation.  But as with all process changes, people learn to adapt.

Are functional acknowledgements for EDI invoices a useful business process?

Whenever a company implements EDI invoicing, the question comes, “do I need 997’s for these?”   To this question, I almost always say yes.  While the 997, i.e. functional acknowledgement, is not perfect, it does provide some value.

First, a little background to set the context.   Every so often, as in once a year or once every two years, I’ll get a call from an irate customer suggesting we dropped the ball on their EDI.  I ask, “what is the problem, can you give me some details?”   Sometimes it comes right up or sometimes it only surfaces after some lengthy Q&A.   The issue is, “my customer is not paying their bills and it’s causing some serious cash flow issues around here.”   When this happens, we review processes, talk with the trading partner, and emphasize checking the 997s.

Here’s how it works.   When a company sends out EDI invoices, a response of acceptance comes back, ideally within a few minutes, but almost always within a day.  The response, the 997 functional acknowledgement, provides feedback at the invoice level, whether an invoices is accepted or rejected based on syntax.  This is very helpful as an indication of passing the first hurdle.  There is still an additional step to take if the invoices are accepted, but if they are rejected based on syntax, the issue is readily rectified.

While the 997 is of considerable value in determining the acceptance of syntax, it does not and cannot relate the acceptance of the charges within the invoice.  The 997 is a technical review, but there is still the business review that comes later.

To determine the acceptance of the charges on an invoice, the customer must be consulted.  Ideally this is through a vendor based web site.  Less optimal is simply receiving an e-mail stating the issues they see.   And of course, the worst case is no correspondence or visibility at all.   In this last case, the vendor only knows there is an issue based on an aging report.  Upon consulting, the issues come out, not an ideal situation.

But given that it’s a two-step process to confirm payment, the important take away is to address processes.   The 997 is easily checked internally via reporting from the EDI system, but once this is addressed, it’s a natural follow on check to confirm payment, something vendors have been dealing with for years, EDI or no EDI.  The EDI process simply speeds up the cycle which can be a good thing provided everything flows without issue.

One final point on this process that is worth mentioning is the role of third party paying agents in the flow of data.  Some of these companies are very reputable, engaging in good business practice as described above.  But this is not always the case.  At times some of these third parties lack good tools and then blame the vendor when slow payment or no payment results.  This is never a positive situation.  The vendor sending the EDI invoices to the third party usually has no say about the involvement of said third party.  But certainly documenting the flow of data step by step can help to reduce the no or slow payments.  Sharing this information with the customer (who has engaged the third party) is sometimes a necessary step.

EDI invoicing is more often than not, a very useful technology.   But engaging in good process to support the flow, including the 997, helps to ensure a successful implementation.

Have you ever wondered how truckload carriers stack up against parcel carriers in the notification of a shipments in-route status?   Actually, they can and do provide more precise information when it’s important to do so.  Whereas parcel carriers typically focus on the time/date a package is shipped or when it arrives or departs one of their facilities, truckload carriers are more focused on the pickup and delivery of a full truckload.  The value of the truckload is usually far higher than a single package and the route is rarely to a home address, but rather a plant or distribution facility.

Truckload carriers have learned over time how to provide quality status reporting because of the importance to do so.  Most of these type carriers have either satellite tracking units or some kind of cellular communications.   With these tools, they connect to the home office on a frequent basis the date/time of pickups and deliveries, plus in-route status every few minutes.

This data is collected in the carriers dispatch system, then made available to the shipping customer via the EDI 214 transaction.  The question then becomes, how much data does the shipper want?  Does it really make sense to keep on record in every transportation management system (TMS) that receives 214 data, the minute by minute location of their shipment?  Probably not, unless it’s a really high value shipment.   So the amount of in-route data is typically paired down to every couple of hours or maybe twice a day.  On occasions, when the status reporting data is not enough, the phone is still a reliable means to track that critical shipment that has to get there on time.   Truckload carriers provide customer service just like parcel carriers.

What is important to note is that truckload carriers with reasonably good dispatch systems, can and do provide very accurate and up-to-the-minute status on a shipment.