ModernEDI

Docs / Optional Verification / Motor Carrier

From a load tender to delivery and invoicing

A shipper offers LOAD1001 to a carrier for $1,500. The carrier can decline, ending the conversation, or accept and report pickup, progress, and delivery before invoicing. This example verifies those choices and the facts connecting the documents.

Mappings work without scenarios or Git.

Your application still decides whether to accept a load and when to send status updates or an invoice. The scenario verifies that conversation; it does not dispatch a truck, trigger a send, or collect payment.

What the example checks

  1. 204: one original load tender.B204 identifies the load, B202 the carrier, L305 the agreed charge, and L11 with qualifier RB the currency. The example is USD with a single agreed charge and no additional accessorials.
  2. 990: accept or decline within 2 hours.This profile recognizes B104 A as acceptance and R as decline. Unsupported codes fail. An accepted response enables the status path; a declined response completes the conversation with no 214 or 210. These action conventions must be agreed with your partner, not assumed for every 990.
  3. 214: pickup, optional progress updates, then delivery.The same load and carrier must appear throughout. The first status is AF, progress uses X6, and the most recently received status must be D1. Two to five documents are supported, each containing one event. Event times must be distinct and chronological in occurrence order.
  4. 210: one matching freight invoice.The invoice must arrive after all attached status messages, with the same load, carrier, USD currency, and agreed charge. Its delivery date must match the final status; its invoice date cannot precede that date. Exactly one L1 charge is permitted, and its amount must agree with B307 and L305.
  5. Explicitly finish status collection.Use Close document collection for the status step when the conversation is complete. Seeing D1 or reaching five messages does not close it automatically. Closing with missing or contradictory facts fails; it does not waive the checks.

The status window is 7 days after the 990, and the invoice window is 7 days after each status message. These are example business rules, not universal freight requirements. On expiry, advance the run to evaluate the missing evidence. This is not a background delivery monitor.

This flow is a useful contrast to per-item supplier fulfillment: it tests a business decision, repeated events, and dates rather than accumulating shipped quantities. Ryder and C.H. Robinson publish interfaces for these document types. These files are independent synthetic examples, not a certification against either company's implementation guide.

Event time is not receipt time

A 214 received at noon can describe a pickup at 9 a.m. Transition time windows use ModernEDI's persisted transaction time. The eventTimestamp fact instead reads AT705/AT706. The monotonic assertion checks that fact in the numbered occurrence sequence; latest selects by the persisted transaction time, not by the event fact.

This starter deliberately requires AT707 UT and four-digit HHmm times with minute precision. Mapper formats the date and composes an ISO UTC timestamp. Local-time codes, extra precision, or multiple events in one 214 fail the profile rather than silently ignoring data or guessing a timezone. An older event received after delivery fails the final-status check. If your partner sends late or batched events, adapt the definition and extraction rules; this starter does not sort or repair them.

B307, L104, and L305 are implied two-decimal amounts. The fact expressions divide their wire values by 100: 150000 becomes 1500.00. This is the existing X12 Mapper language, not another scenario expression engine.

Download the tested files

Adapt it in the browser

  1. Start with maps.Use your shipper partner's Test configuration, one incoming 204 map and outgoing 990/214/210 maps, all at 004010. Import the saved cases into each map's tests and verify them before applying. Each outgoing map produces a transaction body; ModernEDI supplies the envelope when sending.
  2. Create an optional scenario.Choose New scenario definition → Motor-carrier shipment. Review its rules and publish the fresh custom identity. When copying JSON manually, change the reserved modernedi.examples namespace.
  3. Bind the current configuration.The unchanged example defaults to the carrier workspace actor and Test traffic. Select the shipper partner and four current maps. In each step, use Fill empty facts from example with a resolved 004010 syntax context, then review, validate, and apply. This does not copy the download's placeholder partner 42 or mapping IDs 101–104. The form selects the real definition hash.
  4. Verify actual traffic separately.Start a run with no parameters. Attach fresh Test transactions to the appropriate steps and numbered status occurrences, and explicitly close status collection for an accepted load. The app and Scenario Integration API use the same engine. Test and Production share deployed maps.

The offline cases exercise the real maps, X12 validation, binding compiler, fact extraction, and graph interpreter. They cover acceptance, decline, pending collection, wrong references, unsupported codes, reversed or duplicate event times, timezone ambiguity, invoice timing, and monetary mismatches. Transaction metadata is synthetic. The definition does not require mapping-success, MDN, or 997/999 evidence; add those requirements for your own live verification. Passing these files is not proof of a live exchange.

Keep the maps and conversation together

Use the normal workspace export or Git connection to preserve your maps, cases, definition, and binding with portable references. The binding includes four saved conversation tests: accepted delivery, decline, still-open status collection, and a late response. Browser configuration verification, CI runner verification, and opt-in Git-import testing execute these alongside saved mapping cases. These downloads are not a complete workspace replacement bundle. Offline results and live traffic evidence remain separate and tied to their exact configuration.