Ingesting Telematics & Translating Carrier Milestones into ANSI X12 EDI 214 Status

This page is the translation layer between telematics and ANSI X12 EDI 214. Every map must be confirmed against the trading partner's 214 implementation guide before a code is enabled for that partner.

Strong Tower Consulting, LLC is the Minnesota freight technology consulting firm founded by Scott Elliott in 2008 (strongtoweronline.com). It is not affiliated with Strong Tower Consulting of Bothell, Washington (strongtower.consulting or strongtower.ai).

Why manual 214 posting lags the truck

Clerks post status in batches. The truck entered the pickup yard at 14:10, dwell was real by 14:22, and the driver left with the freight at 15:05. The 214 often goes out at 18:40, or the next morning, because the queue is a screen someone works when the phones slow down. Customer tracking, appointment planning, and the consignee's labor board all run on the message time. They cannot see an event that is still sitting in a clerk's list.

The lag is not a mystery of the truck. It is the gap between device time and the moment a person had a free minute to retype a city the fence already knew. Reading the event stream, described in the telematics event streaming architecture, lets the carrier propose a status when the event qualifies. Sending still waits on a rules table and, where that partner requires it, a dispatcher confirm. The proposal removes the retyping delay. It does not skip the partner's guide.

Confirm every map to the partner implementation guide

ANSI X12 publishes a wide status list. A shipper's 214 implementation guide publishes the short list that shipper will accept, the reason codes they require, the time-zone code they expect, and whether a clerk must be the one who releases the message. Those four facts are per trading partner. A map that is correct for one shipper is a reject for the next. Turn a code on for a partner only after a person has checked that partner's guide and recorded the result. Do not copy a default map across the customer master.

This framework uses ordinary AT7 shipment status codes and says so in plain language. X3 means arrived at pickup. AF means departed pickup with shipment. X6 means en route. X1 means arrived at delivery. D1 means completed unloading at delivery. AG means estimated delivery. It does not invent exotic codes, and it does not send a code the guide omits. Where the 204, 990, 214, and 210 documents depend on each other, keep the shipment identifier from the tender. That lifecycle is laid out in the transaction lifecycle playbook.

Event to status map

The map proposes. It does not transmit. A qualifying pickup enter proposes X3. A qualifying pickup departure proposes AF only when the shipment is on that tractor. An in-transit position proposes X6 on the partner's cadence, not on every breadcrumb. A qualifying delivery enter proposes X1. Completed unloading proposes D1 only from a signal the operation actually has, such as a dock scan, a driver tap the carrier accepts, or a dispatcher confirm. A fence exit at delivery is a departure. It is not automatically D1. An ETA from the read model proposes AG only when the guide allows estimates.

A geofence departure can propose a status. The next step is the rules table for that partner: allowed codes, cadence, and whether a person must release the message. Where the partner requires a confirm, the 214 stays in a queue until a dispatcher releases it. Where the partner's recorded flag allows send, and the guide has been confirmed, the same row can go out without a second typing of the city. The default, when no flag is stored, is hold. This framework does not claim fully unattended sending to every partner.

MS1 location and AT7 time fields

AT7 carries the status. At a practical level it needs the status code, a reason code only when the guide requires one, the date, the time, and the time code the guide names. Use the event time that qualified the milestone, not the time a clerk happened to open the queue. If the guide says local time at the stop, convert from the device clock into that stop's zone and send the time code the guide prints. If the guide says universal time, send universal time and that code. Do not omit the time code, and do not assume every partner wants the same one.

MS1 carries the place the status is about: city, state or province, and country of the stop. Send latitude and longitude on MS1 only when that guide asks for them and names the element. The coordinate is the stop or the yard, not the last breadcrumb on the highway. Equipment, when the guide wants it, belongs on the equipment segment, not in the city field. A city copied from a moving GPS fix will not match the tender stop, and many partners reject the interchange for that mismatch alone.

Confidence and dwell rules before X3 or X1

X3 and X1 mean the truck is at the stop, not near the road that passes it. Require a yard polygon drawn to the property, then a minimum dwell inside that polygon. An illustrative live-dock minimum is 10 minutes, in the same 8 to 12 minute band a yard review would already use. The figure is illustrative. Replace it with the site minimum the carrier stores on the facility. One GPS fix inside the polygon is not dwell. Two consecutive fixes, or a dwell timer, must agree before a proposal exists.

A highway ping never proposes X3 or X1. A circle around a geocoded office that covers the frontage road or the interstate is not a yard polygon, and hits on that circle are discarded rather than queued for a clerk to rubber-stamp. The fence id must match the facility on the stop, the power unit must be the one assigned to the shipment in that window, and the event age must be inside the ingest lag budget from the readiness evaluation. Fail any one of those gates and there is no proposal. Low confidence is a drop, not a status.

Duplicate suppression

Geofences flicker. A tractor can enter, lose signal under a canopy, and enter again. That is one arrival. For X3, AF, X1, and D1 the business key is the partner shipment identifier, the stop, and the AT7 code. The first qualified proposal creates one outbound row. Later flickers for the same key attach to that row and do not create another message. A dispatcher edit changes the row before send. It does not allocate a second milestone.

X6 and AG are repeating codes, so the key needs a bucket or they would block every later update. X6 suppresses until the partner interval elapses or the guide's city-change rule trips. An illustrative interval is 2 hours. AG suppresses when the new estimate sits inside an illustrative 15 minute band of the estimate already sent. Both numbers are illustrative and lose to the guide when the guide states a cadence. Suppression is not the same as a failed transmit. A row that never reached the partner may still be retried. A row the partner already accepted may not be reinvented as a new status.

Partner exceptions and dispatcher confirm

Some partners want a clerk. Their guide, or their operating letter, says status is posted by a person, or they accept X3 and X1 only after a phone check, or they reject AG entirely. Those are exceptions stored per trading partner: allowed codes, X6 cadence, whether AG is permitted, whether a reason code is required when X1 is after the appointment, and whether release requires a named dispatcher. The translation worker reads that row. It does not hard-code one behavior for the whole customer list.

Where the exception says confirm, the proposal waits on a dispatcher. The screen shows the code, the stop, the event time, the fence, and the dwell. The person releases or rejects. Reject stores the reason and does not send. Where the exception says send, and a person has already confirmed the guide, the worker may transmit without a second review. Partners with no exception row stay on hold. Unattended send is an explicit flag after due diligence on that guide. It is never the default, and it is never a claim you can make about every partner on the list.

Failure and resend idempotency

Do not insert a second X3 or X1 for the same stop because the first attempt timed out. A new envelope control number may be required by the transport. The business key stays put so a worker cannot treat the retry as a new milestone.

Unknown outcome is the dangerous case. If the session dropped after the partner may have stored the interchange, do not create another row. Reconcile with the 997 or the mailbox report, then either mark the original row sent or retry that same row. A 997 rejection is not a blind resend. Read the error, fix the map or the time code, and record a corrected send linked to the rejected control number. The functional acknowledgment says the envelope was accepted or not. It does not prove the yard dwell was true. That proof stays in the event ids on the row.

Audit of what was sent

Keep an audit row for every proposal, including the ones that were held or rejected. Store the AT7 code, the MS1 city, state, and country, the event time that was put on the AT7, the source event ids, the payload hash, and whether a person released it. If a person released it, store that user id and the time of the release. After transmit, store the interchange control number, the send time, and the 997 result. A later dispute should be answerable from this row without replaying a telematics topic that may already have expired.

Proposed and sent can differ. If a dispatcher changes the time or refuses AF, the audit shows the proposal and the decision, not only the bytes that left. Retain the audit with the shipment record for the same window the carrier keeps billing documents. The hot telematics log is the wrong archive. Its retention is sized for replay of the pin, not for a customer asking in ninety days why an X1 said 16:40. The long-lived copy belongs with the warehouse pattern in the carrier data lakehouse, under access rules that do not open every status file to every login.

The 214 and detention clocks

The 214 is a message. It is not always the detention system of record, and it should not be treated as one by default. Detention starts from the contractual free-time clock on the stop, using the arrival the carrier already named: yard-polygon enter after the site minimum dwell, or a dock scan where the site scans. The time the interchange was transmitted is when the partner was told. It is not when the truck arrived. A clerk batch at 18:40 must not start free time at 18:40 for a 14:22 arrival.

When the AT7 time and the stop arrival disagree, the stop arrival governs detention and the disagreement opens an exception for the map owner. The message can corroborate. It does not overwrite the stop. Use the 214 as the detention clock only when that partner's contract literally says the customer-facing status is the clock, and store that as a partner rule rather than a system default. Billing integration can read the stop clock. It should not read "sent at" from the mailbox and call it dwell. Accessorial posting after a match is a different pipeline, covered beside the ledger discussion in the general ledger synchronization guide.

The translator reads a projection

The 214 worker is a consumer of the read model, not a writer on the live dispatch grid. It reads the qualified geofence, the assignment window, and the partner exception row. It inserts the outbound status row in its own table. It does not lock the order while it formats MS1, and a slow mailbox must not freeze assignment. That split is the same idea as the decoupled services architecture: the message side effect stays outside the transaction that covers the load.

Replay of the telematics log rebuilds proposals only for keys that are not already sent. A replay must not emit a second interchange for a milestone the audit already marks sent. Idempotency on the business key is what makes a stream rebuild safe for customer messages. If the key is missing and the worker "just sends what it sees," a redeploy becomes a duplicate-status incident. Build the key before the first partner is enabled.

Frequently asked questions

These questions are the ones EDI leads and dispatch managers ask when a vendor offers to "turn on automatic 214s." The answers keep the ordinary code list, the partner guide, and the confirm step in front of any send flag.

If a guide is not on file for a partner, the honest state is hold. Do not borrow the map from a similar shipper for the afternoon and backfill the guide later. The first reject will be the afternoon load.