The Revenova TMS supports sending and receiving EDI Transactions through REST APIs. View and test API endpoints in the API documentation section of the knowledge base.
Partner VANs send and receive EDI Transactions by calling a series of endpoints that are configured for each Revenova customer org. Each customer org is managed on a per-client basis by the partner VAN.
Support for both the existing and new REST architectures ensures backward compatibility for current EDI users.
All EDI Transactions are in JSON format.
The time zone used by the REST API process is the Automated Process User’s time zone. Time zones are first determined based on the time zone specified in the EDI Transaction. When a time zone is not specified, or a location update does not contain a time zone, the time zone of the API User/context user set for the VAN on the Load is used to determine the time zone.
Process Flows
The Revenova TMS supports two distinct process flows when moving Loads by EDI. Both flows support typical EDI Transaction processes for truck and rail use cases. The number of Load Tender Responses and Load Status Updates shown below is for example only.
Trading Partner: The Trading Partner is tied to a Shipper/Consignee/Customer Account. Load Tenders originate from Trading Partners and are received in the TMS.
Carrier Trading Partner: The Trading Partner is tied to a Carrier Account. Load Tenders originate from the TMS and are sent to Carrier Trading Partners.
The flow diagrams shown below describe an overall workflow. Multiple transactions may be sent, particularly for Load Status Update transactions.
Depending on configuration and timing, an EDI 990/824 Tender Response may not send for every 204 Load Tender received. This is the case when an updated Load Tender is received and processed before the original Load Tender Response is sent.
Settings & Configuration
The Stop Carrier Status Reason field picklist is sent in outbound EDI 214 status transactions. Picklist values may be deleted from the field, but do not add to or modify existing entries.
Configuration
Navigate to TMS Admin → Configuration → Platform Events and check the EDI 990 Outbound and EDI 214 Outbound fields.
EDI 214 outbound transactions are created and queued when a Stop date or time is adjusted OR when a Carrier arrives or departs a Stop. (X6 location updates)
The following Stop Date or Time fields create an outbound EDI 214 transaction:
Appointment Time
Arrival Date
Departure Date
Expected Date
Loading/Unloading Complete Date or Time
EDI 990 outbound transactions are created and queued when the EDI Transaction Status field is set to either Accepted or Declined.
Navigate to TMS Admin → Configuration → EDI Setup and set the following org-wide EDI values.
The following field settings are required:
Check the EDI Enabled box to send and receive EDI transactions.
Select an EDI Administrator user to receive error emails related to the EDIJob batch process.
Enter a value in the EDI Run Frequency (Minutes) field to set the amount of time between job runs. 30 minutes is the default value.
Select an EDI Shipment Id Field from the available TMS fields to include for each transaction.
This field identifies the Shipment/Load in EDI transactions. The PO Number field is commonly set as the EDI Shipment ID by the EDI trading partner(s) sending Load tenders.
REST API Settings
Check the Use REST API for EDI field to use the REST endpoints for EDI transactions.
Transaction processing cannot be mixed. All EDI Transactions are processed via the REST architecture when this field is checked.
Select the EDI Context User for Kleinschmidt/Cleo/Custom EDI as necessary.
This user is the API User created for the External Client App and assigned the TMS EDI API permission set. A unique API/context user is required for each External Client App/EDI Partner VAN.
An integration license works for this API User.
Multiple Custom EDI VANs are not supported.
Note: The EDI Transaction Logging Types fields are hidden automatically when the Use REST API for EDI field is checked. All EDI Transactions records are logged with the REST architecture.
Optional Settings
Set the following optional fields as necessary.
Check the Display EDI References on Carrier Docs field to add Carrier Rate, Load Confirmation, and Driver Instructions to those documents.
Enter a value in the EDI/ASI ID value into the Trading Partner ID field when necessary.
Enter a value in the EDI Freight Charges Code field to send the freight charges code in outbound EDI 210 transactions.
Enter a value in the EDI Fuel Surcharge Code field to send the fuel surcharge code in outbound EDI 210 transactions.
DataCleanUpJob Settings
The DataCleanupJob batch process deletes EDI Transaction records older than the number of days set in the following field values. The EDI Transaction Last Modified Date field indicates when the transaction was deleted. When no value is entered, the EDI Transaction records are not deleted.
EDI 204 Inbound Transaction Exp (Days)
EDI 204 Outbound Transaction Exp (Days)
EDI 990 Inbound Transaction Exp (Days)
EDI 990 Outbound Transaction Exp (Days)
EDI 214 Inbound Transaction Exp (Days)
EDI 214 Outbound Transaction Exp (Days)
EDI 210 Inbound Transaction Exp (Days)
EDI 210 Outbound Transaction Exp (Days)
Accessorial Charges
While freight and fuel charge codes are set on TMS Admin → Configuration, Accessorial records may have charge codes set on a per-record basis. These charge codes are included in outbound 210/410 Invoice EDI Transactions. These charge codes may be used to provide consistency across systems beyond the TMS. Complete the following steps to include the codes for accessorial charges:
Navigate to TMS Admin → Accessorials.
Choose the Edit link for the desired accessorial record.
Enter a value in the Customer Charge Code field.
Click Save.
Perform steps 2-4 above for each accessorial record as necessary.
Rail Setup
The Revenova TMS supports the following inbound and outbound EDI Transactions to support Rail/Intermodal process flows. Rail support is enabled on a per-Mode basis. The 404, 322, 824, 410, and 998 EDI Transactions are processed identically to the corresponding Truck-related transactions with additional support for EDI 998.
Enable EDI Rail transactions by navigating to TMS Admin → Modes.
Find the desired Mode record and check the Rail box.
Custom Modes are supported when the Rail field is checked.
Click Save.
Repeat as necessary for each Mode to send and receive Rail EDI transactions for each Mode type.
EDI Rail transactions are used when the following criteria are met.
The Carrier Service has a Mode with the Rail field checked.
The Carrier Quote contains one of the Rail-enabled Carrier Services.
The container length may be added to rail EDI Transactions by including the value in the Equipment Type Name for Rail Modes. Perform the following steps to edit the Equipment Type names.
Navigate to TMS Admin → Equipment Types.
Choose the Edit link to view the record field values.
Add the container length to the Equipment Type name field.
Example: Container 53’.
Click Save.
EDI Locations
EDI Location records define each EDI trading partner. They consist of a trading partner name, address, and code. Each trading partner must have an EDI Location record to send and receive EDI Transactions to and from the TMS.
See EDI Location information to create and configure trading partners.
Batch Processes
The following batch processes control how the TMS manages inbound and outbound EDI Transactions. Run or schedule the batch processes below to process EDI transactions appropriately.
EDIWatcherJob
The EDIWatcherJob monitors and starts the EDIJob. Confirm the EDIWatcherJob is running to process EDI Transactions.
Warning: Check the Enabled field for one of the existing EDI Partner VAN Credentials cards (Kleinschmidt, Cleo, or Custom EDI) to enable the EDIWatcherJob on the Job Monitor.
EDIJob
CUSTOMER TRANSPORTATION PROFILE
Set the Location Update Send Frequency field on each customer Transportation Profile to control how often the TMS generates the EDI Transactions below. Once the EDI Transactions are created, they are queued for pickup by the partner VAN. EDI Transactions remain in a Pending Status until the partner VAN requests them for processing.
Run the EDIWatcherJob to start the EDIJob. The EDIJob completes the following tasks.
Creates and queues outbound Load Status (214/414) EDI Transaction location updates for in-transit Loads.
Creates and queues outbound Load Tender Response (990/824) EDI Transactions for trading partners that Auto-Accept 204 transactions.
DataCleanupJob
To manage data volume, the DataCleanupJob deletes EDI Transaction records older than a specified number of days. Enter the field values in TMS Admin → Configuration to set the amount of time an EDI Transaction record is retained in the TMS. EDI Transactions are separated by inbound and outbound direction.
Note: EDI 998 rail transactions are deleted according to the the EDI 204 inbound/outbound transaction type expiration settings.
When scheduled, the DataCleanupJob runs at 4:00 A.M. and deletes any EDI Transaction records older than the settings-defined threshold. The EDI Transaction Last Modified Date is used to determine the record age.
When a Load record is deleted, the associated EDI Transaction records are not deleted.
Components
The following Lightning Web Components provide additional functionality for managing EDI Transactions.
The EDI Order Update Console allows the return of updated Load tender information. When enabled, the Console is available on a tab within the default EDI Transaction record. Load tender updates from the Console are only available on update transactions.
From the App Launcher, search for Unmatched EDI Transactions to view the list of unmatched EDI Transaction records. The component allows for matching EDI Transactions to Load records.
Transactions
The EDI REST architecture contains three endpoints for managing EDI Transactions in the TMS. All inbound and outbound EDI event always creates an EDI Transaction record. View all EDI Transaction records by searching the App Launcher and selecting the tab.
View EDI Transactions for a given Load with the EDI Transaction related list. Add the related list to the Load Lightning Record Page where desired.
Bulk Accept or Reject Tender transactions from the EDI Transaction list view. Outbound transactions are set to Pending Status, awaiting retrieval by the VAN.
POST (inbound): The POST endpoint receives transactions from the partner VAN where they are then processed in the TMS. The endpoint supports transactions as described.
A single request may contain up to 200 transactions of any EDI Code and up to 100 transactions for the same Load to process them in order. Transactions are queued in batches of 100 to ensure processing in the correct order.
Duplicate EDI 204/404 are processed correctly.
Mixed transaction types may be sent in the same request.
All transactions must pass validation to the queue. If a single transaction in the request fails, the entire request fails. The partner VAN must correct the transaction(s) and resubmit the request to the endpoint.
The EDI Transaction Status is set to either Success or Failure depending on the processing by the TMS. Transactions with no payload, an invalid JSON object, or a missing shipmentId will fail and must be corrected by the partner VAN and submitted again.
Inbound transactions include 1 timestamp when they are created in the TMS.
GET (outbound): The GET endpoint provides the partner VAN with the queued outbound transactions.
Transactions are queued with an EDI Transaction Status of Pending. When the partner VAN requests the queued transactions, the Status is updated to Success.
Up to 1000 transactions may be requested at once from the TMS's queued transactions. Partner VANs may recall the endpoint multiple times as necessary to request all queued transactions.
Outbound transactions include 2 timestamps. The first is when the transaction is created and queued for processing. The second timestamp is when the partner VAN retrieves the transaction.
PATCH (outbound): The PATCH endpoint allows partner VANs to update the EDI Transaction Status value for transactions received from the GET endpoint that fail processing.
The partner VAN may include an error message to assist in troubleshooting.
The partner VAN may update the EDI Transaction Status to Pending to requeue the transaction.
Outbound transactions include 2 timestamps. The first is when the transaction is created and queued for processing. The second timestamp is when the partner VAN retrieves the transaction.
Troubleshoot transaction issues by viewing EDI Transaction records and identifying the timestamp(s) for insight. Re-process transactions by setting the Status to Pending. Inbound transactions are re-processed immediately and outbound transactions are re-queued for VAN request.
View transaction-specific information by following the links below.
Rail Loads
The following information is applicable when creating and moving rail Loads. Rail EDI transactions follow the same process flow as the truck logistics flows described above.
Create Rail Loads using the Freight Plan Console to create Freight Plans with one customer moved by multiple Carrier Loads. Typically, the Rail Freight Plan consists of a customer Load moved by the following Carrier Load types.
One Drayage Carrier Load
One Rail Carrier Load
One Drayage Carrier Load
EDI Rail transactions assume one customer Load per Carrier Load. For outbound EDI 404 transactions, Carrier Loads in a Freight Plan include the Customer Bill To from the customer Load on the Freight Plan. In cases when one Freight Plan Carrier Load is associated with multiple customer Loads, one Customer Bill To is selected.
EDI 998 transactions are only sent when removing a Carrier from a Load with the Remove Carrier modal on the Carrier Banner.
Rail Technical Specifications
This section contains information for configuring a custom rail EDI implementation.
Entity Identifier Codes
Entity Identifier Codes may be set based on customer preference for the following values.
SH (Shipper in the N1 Loop)
CN (Consignee in the N1 Loop)
Revenova does not send specific Account information for these values.
The table below contains the relationships between the TMS fields and web service for EDI transactions with the corresponding Entity Identifier Codes.
Entity Identifier Code | TMS Value | Web Service Element |
|---|---|---|
SF | First Stop Account (from Customer Load in a Freight Plan) | ultimateShipper |
PV - Party Performing Certification (in the N1 Loop) | Shipping/Receiving Contact for First Stop of the (from Customer Load in a Freight Plan | ultimateShipper |
UC (in the N1 Loop) | Last Stop Account (from Customer Load in a Freight Plan) | ultimateConsignee |
Last Stop Shipping/Receiving Contact (from Customer Load in a Freight Plan) | ultimateConsignee Contact | |
N1 (in the N1 Loop) | Accepted Carrier (on the next leg in a Freight Plan) | notifyParty |
Tender Contact on the Carrier Service (on the next leg in a Freight Plan) | notifyParty Contact | |
N1 (in the N1 Loop) | *Account associated with the Load Notify Party field (Load not part of a Freight Plan) | notifyParty |
Contact associated with the Load Notify Party field (Load not part of a Freight Plan) | notifyParty Contact | |
PF - Party to Receive Freight Bill (in the N1 Loop) | Carrier bills for moving the Load (from Carrier Load in a Freight Plan) | billTo |
BN - Beneficial Owner (in the N1 Loop) | Customer Account billed for moving the Load (from Customer Load in a Freight Plan) | customerBillTo |
Billing Contact on the associated Account with the Load Customer Bill To field) | custeromBillTo Contact | |
CB (in the N1 Loop) | Contact sent based on the Transportation Type field.
| customsBroker |
Text field for Pricing Authority Information (PI Segment)
| quoteContractId | |
Origin route information for the Rail move (R2 Route Information Segment)
| originTerminalLocation | |
Destination or Interchange information for the Rail move (R2 Route Information Segment)
| destinationTerminalLocation | |
The level of transportation service requested from the Rail in the Tender. (R2 Route Information Segment) Example: R2*CSXT*S*CHGO**25*X | movementType |
*If no Account is populated, no values are sent in the EDI transaction.
TMS Value | TMS Fields Included |
|---|---|
First Stop (from Customer Load in a Freight Plan) | Appointment Required Appointment Time Expected Date Shipping/Receiving Hours Time Zone (Local Time) |
Last Stop (from Customer Load in a Freight Plan) | Appointment Required Appointment Time Expected Date Shipping/Receiving Hours Time Zone (Local Time) |
quoteContractId | Carrier Quote - Quote/Contract ID |
Deprecated VAN Integrations
The Revenova TMS supports backward compatibility for customers who continue to use the deprecated EDI architecture. Customers are strongly recommended to upgrade to the EDI REST architecture. The benefits of the REST architecture include faster EDI Transaction processing, the ability to handle a larger volume of transactions, and the ability to allow partner VANs to report outbound transactions as failed or processed.
The following links provide information for the deprecated integrations to EDI partner VANs.
Note: The linked integration information is provided as a reference only. Limited support and development is available for continuing to use the workflows described.
Deprecated EDI Transaction processing is supported by the TMS after the Winter ‘26 TMS release. The following functionality is included.
EDI Transaction records are retained, but cannot be re-processed. New and existing EDI Transaction records are deleted based on the DataCleanupJob settings.
The Load field on the EDI Transaction record is updated to a lookup field. This field is no longer a Master-Detail(Load) relationship.
All EDI events are logged as EDI Transaction records, and payloads are converted to JSON format.
All outbound EDI Transaction date fields follow the ISO 8601 (yyyy-MM-dd) format.