TMS Freight Rate Shopping & Load Building

The problem

The transportation management module in Dynamics 365 Finance & Operations gives you the data model — loads, shipments, rate masters, rate engines, freight bills — but it expects somebody to populate and maintain that model. In practice, most shipper implementations end up with a rate master that was loaded once from a spreadsheet, a rate engine that returns a number nobody trusts, and a shipping desk that keeps a browser tab open on each carrier's own portal to get a real quote. The result is a daily routine where a planner reads a load out of F&O, retypes it into two or three carrier sites, picks the cheapest, and types the carrier and cost back into the load.

That manual loop costs money in three separate ways. Rates go stale, so the accrued freight on the load never matches the freight bill and accounts payable spends its month-end reconciling variances. Loads are built by whoever is on shift, so trailer cubic capacity and weight limits are approximated rather than optimised and you pay for air. And tendering is done by phone or email, so there is no timestamped record of who was offered the load, who declined, and how long they took — which is exactly the evidence you need when a carrier disputes a service failure.

What ECOSIRE builds

We build an X++ extension model deployed into your Dynamics 365 Finance & Operations environment. No overlayering — the solution is a separate model in its own package, using extension classes, chain-of-command, table extensions and form extensions against the standard TMSLoadTable, TMSShipmentTable, WHSLoadTable and the transportation rate engine framework.

Live rate shopping

We implement a custom rate engine class deriving from the standard transportation rate engine base, so your rating appears everywhere F&O already calls a rate engine — the load, the shipment, the rating workbench, and the sales order freight estimate. Instead of reading a static rate master, the engine calls your carriers' rating endpoints at the moment of the request, normalises the responses into a single comparable structure (linehaul, fuel, accessorials, discount, total, transit days, service level), and writes the returned options into a new rate-shopping table linked to the load. The planner sees every carrier's price and transit time side by side and selects one; the selection stamps the carrier, service, quoted amount and quote identifier onto the load so the accrual is the real quoted number.

Carrier connections are built per carrier. We implement an abstract carrier adapter class and one concrete adapter per carrier you name in scoping — LTL, parcel or truckload, REST or SOAP, whatever the carrier publishes. Credentials are held in a carrier configuration table and, where you prefer, in Azure Key Vault referenced from that table. Adding a carrier later is a new adapter class, not a rewrite.

Load building and optimisation

We add a load building workspace that takes open sales order lines, transfer order lines or released warehouse work and proposes loads against your equipment definitions. The builder respects item weight and volume from the released product, unit of measure conversions, stackability and hazmat flags carried on product dimension groups or on fields we add, plus your trailer profiles held in a new equipment table. It produces candidate loads with utilisation percentages by weight and by cube, lets a planner drag lines between candidates, and commits the accepted plan by creating standard WHSLoadTable records through the supported load APIs so downstream warehouse work, wave processing and the warehouse mobile app behave exactly as they do today.

Multi-stop routing is supported: loads can carry ordered stops with sequence, address, appointment window and per-stop weight, and the rate request is built from the full stop sequence rather than a single origin-destination pair.

Tendering

Tendering is implemented as a state machine on the load with an auditable history table. A tender is offered to a carrier through that carrier's adapter or, where the carrier has no API, by a generated email with a signed acceptance link served by a custom service endpoint. Every offer, acceptance, rejection, expiry and re-tender is written with a timestamp and the user or system account responsible. A batch job in the standard batch framework escalates to the next carrier on your routing guide when a tender expires, so the load keeps moving overnight without a human watching it.

Financial integration

Freight accruals post through the standard freight bill and freight reconciliation objects so your existing ledger dimensions, main accounts and posting profiles are respected. We do not invent a parallel posting path. Where a carrier returns an invoice electronically, the extension matches it to the freight bill on the load and flags variances above a tolerance you configure per carrier and per legal entity, routing the exception through a workflow you approve.

Data, integration and reporting

All new tables are exposed as data entities in the data management framework with OData enabled, so rate history, tender history and load utilisation are available to Power BI, Excel add-in refresh, and any downstream system. We ship data packages for the configuration tables so promoting settings between environments is an import, not a retype. Long-running work — nightly rate refreshes for planning, tender escalation, freight bill matching — runs as batch jobs with proper batch server task splitting rather than as synchronous user-blocking calls.

Who this is for

Shippers running Dynamics 365 Finance & Operations who move freight on more than one carrier and more than one mode. Distributors and manufacturers whose planners rate loads manually today. Organisations with several legal entities where each entity has its own carrier contracts and needs its own routing guide, but wants one operational view. If you ship exclusively parcel on one account with negotiated flat rates, this is more machinery than you need.

How delivery works

Scoping call. We walk your current shipping process, list the carriers and services you actually use, confirm which of them expose an API and which need the email tender path, review your equipment types, and look at how freight posts to the ledger today. We also confirm your F&O version, your environment topology and who owns your LCS project.

Fixed quote. You receive a written scope with the carrier adapters named individually, the load building rules stated explicitly, the tendering behaviour described, and a fixed price and delivery window. The quoted price is the price; scope changes are quoted separately before any work happens.

Build. ECOSIRE develops the model against a build environment on your F&O version. You get access to the source, a demonstration at the halfway point, and a second demonstration before handover.

Install in test. We produce a deployable package and hand it to your LCS project, or apply it ourselves if you grant access. It goes into your sandbox first. We configure the carrier adapters against carrier test credentials, load your equipment profiles and routing guides, and run your real loads through rate shopping and tendering with your planners in the room. Nothing is signed off on our test data — it is signed off on yours.

Production. After your acceptance, the same package is promoted to production through your normal release process. We attend the go-live and stay on the call while the first real loads are rated and tendered.

Support. A defined support window follows go-live for defect correction, adapter adjustments when a carrier changes a field, and questions from your team.

Build-to-order means nothing here is sitting on a shelf. The extension is written for your carriers, your equipment and your posting setup, and typical delivery is one working week from a signed quote depending on how many carrier adapters are in scope.