EDI 210/410: Load Invoices

Load invoices are sent from and received by the TMS as EDI 210 transactions. Rail invoices are received as inbound EDI 410 transactions.

Motor Carrier Summary Freight Bill Manifests are received as inbound EDI 224 transactions.

For EDI REST: See additional documentation for payload examples and other endpoint information.

For EDI SOAP (deprecated): See the EDI Specification Guide for payload examples.

EDI 210

Carriers and Vendors send EDI 210 transactions (inbound) to the Revenova Partner VAN, who then send them to the TMS, and the TMS sends the queued EDI 210 transactions (outbound) to the Partner VAN.

Inbound Transactions

For EDI REST: When the EDIJob batch process runs, all outbound EDI 210 transactions are queued with a Pending status. Partner VANs call the POST EDI Service endpoint to send transactions to the TMS in the request body. Each payload in the body contains the load invoice details, with ediCode set to 210 and inbound set to true.

[
        {
        "ediCode": 210,
        "inbound": true,
        "payload": { ... }
        }
]

For EDI SOAP (deprecated): When the EDIJob batch process runs, the GetLoadInvoices API call is made. All accumulated EDI 210 transactions are returned to the TMS from the Partner VAN in a payload.

Inbound EDI 210 transactions are received in the TMS and either create a new Vendor Invoice record or match to an existing Vendor Invoice. Individual carriers may have an identical PRO Number, so Loads are matched based on the PRO Number and the carrier (carrierTradingPartnerId).

Note: EDI 210 transactions support the following date formats:

• YYYY-MM-DD

• MM/DD/YYYY

• MMDDYYYY

• YYYYMMDD

If a date does not following one of the following formats an error email is generated and sent with the payload for troubleshooting.

Inbound 210 Matching Logic

The TMS attempts to first match to the Load record and then creates a new Vendor Invoice or updates an existing one based on the following logic:

Inbound EDI 210 Load Record Matching Flow

Note: Any searches that result in no matches create an Unmatched EDI Transaction record. Manage Unmatched EDI Transaction records with the Unmatched EDI Transaction LWC.

When a transaction is successfully matched to a Load, the TMS compares all Vendor Invoice records for the Load to determine if the EDI 210 transaction matches to an invoice based on the Invoice Number and the Carrier/Vendor on the Load record:

Inbound EDI 210 Vendor Invoice Record Matching Flow

• If no invoice is matched, a new Vendor Invoice is created.

• If the invoice is in a Pending status, it is updated with the data from the EDI 210.

• If the invoice is NOT in a Pending status, the invoice is NOT updated with the data from the EDI 210. A failed EDI 210 transaction is logged.

For EDI SOAP: If no match is found, the EDI Administrator receives an email for an EDI batch job error.

Caution: The Invoice Date and Invoice Due Date fields in the payload must be formatted correctly to properly match. A separator must be included for both fields between the month, day, and year.
Example: 2024-08-12 refers to August 12, 2024.

Note: Accounting Seed orgs follow the same matching logic. Instead of Vendor Invoices, Payable records are created or updated.

Outbound Transactions

The TMS Admin → Configuration EDI Shipment Id field is used primarily for outbound transactions.

Note: The TMS sends Load stop information including those with the same location for multiple stops on a single Load.

For EDI REST: Partner VANs call the GET EDI Service endpoint to receive queued outbound EDI 210 transactions from the TMS. Each payload in the body contains the Load invoice details, with ediCode set to 210 and inbound set to false.

[
    {
        "ediCode": 210,
        "inbound": false,
        "payload": { ... }
    }
]

Once the VAN picks up the EDI transactions, the status of the events is set to Success. If there is a failure in processing determined by the VAN, they may call the PATCH EDI Service endpoint can update the status of the EDI transaction with an error message.

[
    {
        "ediTransactionId": "a19E2000005sxOPIAY"
        "status": "Failure",
        "failureMessage": "Deserialization Error - invalid field shipmentId"
    }
]

For EDI SOAP (deprecated): The TMS runs the SendLoadInvoices API call and sends the queued EDI 210 transactions to the Partner VAN.

EDI 410

EDI 410 transactions follow the same format as inbound and outbound EDI 210 transactions, with additional fields for rail invoices.

The following fields are saved to the Vendor Invoice record from the EDI 410 transaction:

• ultimateShipper

• ultimateConsignee

• billTo

Inbound 410 Matching Logic

The TMS attempts to first match to the Load record and then creates a new Vendor Invoice or updates an existing one based on the following logic:

Inbound EDI 410 Load Record Matching Flow

Note: The inbound EDI 410 matching logic follows the same format as the EDI 210 matching logic with an additional search for the Waybill Number on the Load record.

1. Search for EDI Location record match: The TMS attempts to match the carrierTradingPartnerId field from the payload to an existing EDI Location record. The Trading Partner (Account) field of existing EDI Locations is compared.

   • If no match is found, an exception prevents any further logic from matching. The TMS cannot create an Unmatched EDI Transaction record without a Carrier Account.

     • For EDI REST: The EDI Transaction record has the Status field set to Failure with an error message in the record.

     • For EDI SOAP: When no match is found for the carrierTradingPartnerId, an email is sent to the EDI Admin.

2. Search for PRO Number match: A Trading Partner (Account)/carrierTradingPartnerId match is found. The TMS then matches the proNumber from the payload to the PRO Number field to Load records.

   • If multiple Loads are matched, an Unmatched EDI Transaction record is created.

   • If no Load matches the payload’s proNumber, another search is performed using the waybillNumber from the payload.

     • If no Load matches the payload’s waybillNumber, another search is performed using the shipmentId from the payload and the Load Number from Load records to compare and match.

       • If no Load Number matches or multiple Load Number matches are found, an Unmatched EDI Transaction record is created.

3. Search for Waybill Number match: For EDI 410 transactions that do not contain a proNumber, the TMS matches the waybillNumber from the payload to the Waybill Number field to Load records.

   • If multiple Loads are matched, an Unmatched EDI Transaction record is created.

   • If no Load matches the payload’s waybillNumber, another search is performed using the shipmentId from the payload and the Load Number from Load records to compare and match.

     • If no Load Number matches or multiple Load Number matches are found, an Unmatched EDI Transaction record is created.

4. Search for Load match with shipmentId: For EDI 410 transactions that do not contain a proNumber AND a waybillNumber, the TMS searches for Loads by shipmentId and compares the Load Number to the Load records.

   • If no Load Number matches or multiple Load Number matches are found, an Unmatched EDI Transaction record is created.

Note: Any searches that result in no matches create an Unmatched EDI Transaction record. Manage Unmatched EDI Transaction records with the Unmatched EDI Transaction LWC.