Publishing to OTM
Once all required approvals are in, loading starts automatically. The row moves Approved -> Queued for OTM -> Processing -> Completed.
How the data reaches OTM
Records are sent in batches, table by table, in dependency order - supporting records first, then the records that reference them:
XLane -> Rate Service -> Rate Offering -> Service Time -> Rate Geo -> Rate Geo Expiry
For large files, Rate Geo is split into batches of 2,000 records that run one after another, so OTM is never asked to commit everything at the same moment. Batches are sent at a steady pace rather than all at once, so the integration is not flooded on a big file.
OTM's own processing rate is the limit, not GoRate's. A 40,000-record file typically takes around 45-60 minutes. A file sitting at Processing for half an hour is working normally - the Status Tracker shows which batch it is on.
One upload at a time
Only one upload per project loads at a time, whatever it carries. A second approved file waits at Queued for OTM and starts on its own when the first finishes.
This holds for rates, capacity, commitments and allocations alike: two files writing into OTM at once is what the queue exists to prevent, and it also means each run can be told apart from the one before it.
Business hours
If the project's upload type is Business Hours, an upload approved inside the window is held at Staged. Everything held is released at the project's Execution Time, then loads one after another as above. Execute Now on the row runs one immediately. See GoRate Setting.
When a batch does not load
A batch can fail in two places, and both are shown the same way.
| Where | What happens |
|---|---|
| OTM rejects records | The records OTM refused are counted as rejected, with OTM's reason |
| The integration does not accept the batch | It is tried up to 3 times. If it is still refused, it is recorded as a failed batch and the run carries on with the rest of the file |
A failed batch is never dropped silently:
- the Status Tracker names it under its table - Batch 7 of RATE_GEO (2000 records) was not accepted ... - with the reason;
- the completion email counts its records as not loaded;
- the Transmission log keeps the batch's data, so support can load it by hand.
If a batch was sent but no answer came back in time, it is not sent again - it may already have been accepted, and a second copy could load it twice. It is recorded as failed with that explanation, so someone can check OTM before reloading it.
Completed or Failed
The outcome follows what actually reached OTM:
| What happened | Status |
|---|---|
| Every record loaded | Completed |
| Some loaded, some rejected or failed | Completed - the email lists what did not load |
| Nothing loaded | Failed |
While batches are still reporting back, the file stays at Processing rather than being settled early.
Expire & Process (EP)
If the template's Rate Geo action (Template Manager - Settings - Tables to Upload) is Expire & process, loading does two things: it loads your new rates and expires the rates they supersede.
| Situation | What happens to the existing OTM rate |
|---|---|
| Same effective date as the new rate | It is inactivated, and the new rate is loaded alongside it under a suffixed ID |
| Earlier effective date, still running | Its expiration is shortened to the day the new rate begins, so the two never overlap |
| Starts on or after the new rate | Left untouched - a rate that starts later cannot be superseded by this one |
This is the one load mode that modifies existing data rather than only adding to it. Confirm the template's action with your administrator before running a large EP file.
The expiry work appears as its own step, Rate Geo Expiry, at the end of the run, and as its own row - RATE_GEO (expiry) - in the completion email and the tracker, so the expiries are never mixed in with the new rates.
Following it step by step
The row's Status Tracker in Upload Manager shows each OTM table with its batches, loaded and rejected counts. For logs and payloads, open Transmission.
What "rows written" means
One record writes several rows across several OTM tables. A single rate creates its rate geo, its cost group, its costs, its weight breaks and its lane.
So the row counts reported after a load are legitimately larger than the number of records in your file. See Emails for how to read the two tables in the completion email.