Dynamics 365 Transportation Management - Simply Explained

Hello and welcome to another episode of Microsoft Knowledge Nuggets here on M365FM. I'm your host, Mirko Peters. Today's topic is one that almost everyone who works with supply chains has heard of, but few people truly understand. Dynamics 365 Transportation Management. Here's the problem. A customer places an order, stocks sits in the warehouse, a carrier needs a pick-up time, the customer expects delivery, and later a freight bill lands on someone's desk. For years, those steps lived in separate spreadsheets, phone calls, rate sheets, and handoffs between teams out, and that creates gaps. The warehouse might prepare goods before transport has a plan. Finance might see a bill without knowing what anyone agreed to pay. So what exactly is transportation management? In plain English, it's the transportation desk inside Dynamics 365 Supply Chain Management. It connects warehouse doors, vendors, customers, and carriers. Will plan loads, choose routes and rates, ship goods, and check freight charges? By the end of this episode, you'll see how all these pieces fit together to make your work life easier. Why transportation management exists? Let's start with the basic truth. Physical goods don't move just because a sales order exists on the screen. They need a truck, a trailer, a container, or another way to travel. Someone needs to know where the goods start, where they need to arrive, how much space they take up, when they need to leave, and what the trip should cost. Now when you picture one box going to one customer, it sounds simple. But a real company might send many orders from the same warehouse on the same day, receive goods from several vendors and move stock between its own sites at the same time. Each movement has people, dates, space, and money attached to it. Without a shared system, each team sees only its own piece. Sales sees the customer order. Purchasing sees the vendor order, warehouse staff see the items they need to pick, pack, receive, or put away. The transport team sees a list of things that must move often after everyone else has already done their part. That's where delays and confusion start. Here's a concrete example. Imagine a warehouse has 10 customer orders ready for the same city. If nobody connects those orders before booking transport, the company might arrange several partly filled trips, or the carrier might arrive before the warehouse knows which goods belong on the vehicle. The goods are ready, but the movement isn't planned. So transportation management gives that movement a place inside Dynamics 365 Supply Chain Management. It's not a separate consumer shipping app where you type in a tracking number and watch a parcel move across a map. Instead, it works with the business records already inside the connected platform, and order creates the need for goods to move. Warehouse work prepares the goods. Transportation management plans, how those goods travel between locations. Think of it like the transportation desk in an office building. The sales team brings a customer request to the desk. Purchasing brings news that a vendor will send goods in, the warehouse brings the actual stock and the loading doors. The transportation desk connects those requests to the company's transport plan. There are two main directions. Inbound transportation means goods travel into your business. You've ordered items from a vendor, and those items need to reach your warehouse. Sometimes the vendor controls that trip, sometimes your company arranges it, either way you need a clear plan for getting the goods to the right place and receiving them when they arrive. Outbound transportation means goods travel out of your business. A customer has ordered products, the warehouse prepares them, and a carrier or company vehicle takes them to the customer. Both flows deal with movement, but the starting point differs. Inbound starts with a purchase order and a vendor. Outbound starts with a sales order and a customer. There's also a third type that beginners often miss. Transfer orders. Transfer order moves stock between your own company locations. Maybe one warehouse has too much stock and another warehouse needs it. No customer purchase is involved, but the physical goods still need transport. In Dynamics 365 Transportation Management, transfer orders belong to the outbound scenario and can be planned alongside sales orders. That makes sense when you picture the loading dock. Oh, whether a pallet travels to a paying customer or to another company warehouse, somebody still needs to arrange the vehicle, reserve space, and send it out from the same door. So this connected approach replaces the old chain of separate lists and phone calls with shared information. The order tells the system what needs to move, the warehouse prepares the items. Transportation management turns that need into a transport plan. Once goods need to move, the system first needs a workable shipping plan. Planning the load. Today's knowledge nugget is about something every logistics team needs, but often explains differently. Planning a load. You can start planning transportation from either orders or shipments, or myicopeters from M365, FM, and let me clear up a myth right away. A shipping plan doesn't start from scratch. It starts from records you already have. A sales order holds what a customer bought. A purchase order lists, what a vendor needs to send, a shipment groups, those items into a more focused shipping record, ready to be combined with others. So which starting point should you use? That depends on how your company works. Some teams plan early, looking directly at order lines. Other teams create shipments first, then decide what travels together. Both parts lead to the same question. What should go on the same vehicle? Here's the simplest definition. A load is the digital record for a planned movement of goods. You can picture it as one truck, one trailer, one container, or one collection of shipments that travel together. It gives you one place to see which goods belong together before physical work starts. Now here's something many people get wrong. A load doesn't mean every item fits inside one physical box. It means the system groups goods around one transport plan. Several customer shipments may share one truck. A large order might fill a whole trailer by itself. A container arriving from a vendor can also become a load. Even before your warehouse receives the goods. The point is to stop treating each order as its own trip. Imagine a distributor has six customer orders ready for Friday delivery. All six sit in the same area, and each order fills only part of a truck. Sending six half empty vehicles, wastes, space, and creates six separate transport jobs. The team can instead group compatible shipments into one load. Compatible means they can reasonably travel together. They leave from the same warehouse, need to go around the same time, fit within vehicle limits, and follow your shipping rules. The system helps bring those records together instead of relying on someone to spot the pattern in a spreadsheet. That group now has a shared plan. A warehouse sees what belongs on the load. The transport planner sees the total space and wait. People don't need to rebuild the same list in emails, notes, or a separate file. But here's the thing. Grouping goods isn't just about putting more items together. A truck has limits, wait, floor space, height, a container has its own rules. If the system groups goods without checking those limits, the load may look fine on screen, but fail at the loading dock. Dynamics 365 uses load templates to help avoid that. Think of a load template as a reusable set of limits for a type of vehicle or container. Create one for a small delivery truck, another for a larger trailer, another for a shipping container. Each template holds limits for weight, volume, height, and other rules your company needs. The template gives the load a shape before you start filling it. So if a shipment weighs too much or takes up too much room, the planner sees it doesn't belong on that load. The answer might be a second vehicle, a different template, or a different grouping of shipments. The software doesn't lift pallets, but it does give your team a clearer plan before physical work begins. One built-in approach is called volume-based load building. That sounds more technical than it needs to. It means the system uses the maximum height and weight from your load template when building or suggesting a load. In plain English, it checks whether the goods fit within the limits you set. Those values aren't locked forever. A planner can override them when real world needs change. Maybe a carrier sends a different trailer. Maybe a trip allows a different height. The template supplies the normal rule, and the override handles the exception without rebuilding everything. Let's return to those six customer orders. Each alone might take up 15% of a truck. Plan separately, you could send six mostly empty vehicles. Grouped into one load, the same orders may fill most of one truck with room left for more. That's a better use of space. Now, the same idea works both directions. For inbound planning, create a load around items coming from a vendor. The transport plan connects to the expected receipt, so the warehouse knows what's due and prepares for arrival. Instead of learning about a delivery only when it appears at the gate, the receiving team has a planned record. For outbound planning, select warehouse items that need to leave for customers and group them into a load. The warehouse prepares those goods based on the load details, not a disconnected list. One full load still needs a way to travel, a company to move it and an expected charge. Roots, carriers and rates. The load now tells you what needs to travel together. Next, you need to decide who moves it, which service they use, and what that trip should cost. The company that moves your goods is called the carrier. It can be an outside transport company that collects and delivers your freight. It can also mean your own fleet if you run your own trucks and drivers. Either way, the carrier is responsible for the physical trip. That distinction matters because you still need a plan, even when the truck belongs to you. With an outside carrier you agree on prices and services ahead of time. With your own fleet, you may still want the transport charge calculated, especially if delivery costs appear on customer orders. Dynamics 365 transportation management supports both situations. Then there's the route. A route is the planned path from pick up to destination along with the service choice. It answers practical questions. Which warehouse does the carrier collect from? Which customer or location receives the goods? Which carrier service handles the trip? Picture a delivery leaving your main warehouse for a customer across the country. One route may use standard road freight that costs less but takes longer. Another may use a faster, more expensive service. Same starting and ending point, but the transport choice changes. A rate is the expected charge for that choice. It's not a random number typed in at the last minute. Rates come from pricing agreements with carriers, combined with shipment or route details. Where the goods start? Where they go? The service used. The amount transported, so a route tells you how goods should move. A rate tells you what you expect to pay. Those two ideas belong together because a cheap route may miss your delivery promise, while speed may cost more than the order supports. Transport planning isn't just finding a truck. It's choosing a service that fits your customer commitment and the company's cost rules. Dynamics 365 includes the rate route workbench. The name sounds formal but the purpose is simple. It gives planners a place to compare route and rate choices for a shipment side by side. Instead of checking one carrier table, then another and comparing in a separate file, you review the choices connected to that shipping need. Maybe one option reaches the customer sooner. Maybe another costs less. The system doesn't know every customer values speed more than cost, because businesses work differently. A customer may have paid for urgent delivery, so the faster route makes sense. Another accepts longer delivery and the lower charge fits better. People still make the decision. Transportation management gives you agreed choices and expected costs, while your business decides which trade-off works. Here's what the built-in module actually does. Rate information comes from rate tables, your company enters and maintains in Dynamics 365. Think of these tables as stored records of agreed carrier prices and route rules. If you've negotiated a price for a certain service in lane, that information sits in the system and supports planning. That works well when your rates follow known agreements. For example, work with a few regular carriers, serve familiar routes, and update prices when contracts change. Transport planner uses rates already recorded instead of hunting through old emails, but here's something many people misunderstand. The built-in module doesn't act like a live shopping site connected to every carrier. It doesn't automatically pull fresh prices from live feeds and compare across a broad network in real time. If your company needs multi-carrier rate shopping, live booking links, or deeper shipment status updates, you normally connect a third party system. That's not a failure of transportation management. It defines its job clearly. These tools handle structured transport planning, inside supply chain management, using the carrier, route, and rate information your company maintains. And it's also not a consumer-pastel tracking website. You won't use it like a map where you enter one tracking number and watch a vehicle icon travel down a road. This module focuses on business transport decisions before and around the shipment, which goods move together, which carrier handles them, which route applies, what the trip should cost. Once your company selects that plan, the warehouse and transport teams need to carry it out. From warehouse door to customer door, a transport plan only helps when people can actually turn it into a real shipment. For an outbound order, the flow usually starts when a customer buys something. The sales order tells the business what the customer wants, where it needs to go, and when it should arrive. That order becomes a shipment, and the shipment joins a planned load with other goods traveling on the same trip. Then the warehouse takes over. Workers pick the items from storage, pack them, and bring them to the right loading area. Because the shipment belongs to a load, the team can see which goods need to leave together, and which carrier will collect them. When the vehicle arrives, the goods move from the warehouse to the carrier, and the carrier takes them to the customer. Every step connects to the same movement record. That sounds ordinary, but imagine the old way. A picker might work from a printed order. A transport planner might hold a separate list, and someone at the loading door might search through emails to check which carrier should take which pallets. If one detail changed, everybody needed the updated version. With transportation management, the load gives the teams a shared record out. The warehouse can see the items connected to the load, the transport planner can see the shipment details, and the person arranging the pick up can see the planned carrier and service. Instead of passing around several paper lists, people work from information linked to the same order and shipment. Here's a simple example. A warehouse has orders for several customers in the same delivery area. One customer ordered cartons of cleaning supplies, another ordered paper products, and a third ordered a small batch of equipment. Each order needs picking and packing, but the transport team doesn't have to treat them as completely separate trips. They assign the shipments to one planned load. Warehouse staff pick each order, pack it correctly, and prepare it for the loading area. The load record tells them that all those shipments travel together. When the carrier arrives, the team hands over the goods for one planned movement instead of trying to match loose pallets to a driver at the last minute. The customer still receives their own order. Behind the scenes, though, the business planned that delivery as part of a larger movement, that link helps the warehouse work with the transport team instead of working ahead of it or waiting for instructions that arrive too late. Inbound transportation follows the same connected idea, just in the other direction. A purchase order tells you that your company expects goods from a vendor. When your business arranges the transport, a planned inbound load connects the incoming items to the trip before the goods reach the warehouse. The vendor sends the shipment, the carrier brings it to your site, and the warehouse receives it. Receiving staff can prepare because they know what should arrive. They can check the planned load against the goods that turn up at the dock, oh, much clearer than a truck appearing with little warning and someone trying to work out which purchase order the pallets belong to. Transfer orders fit this process too. One company site sends stock out while another company site receives it. The first warehouse prepares the items and ships them and the second warehouse expects the same items and receives them into its stock. No outside customer sits at the end of that trip, but the company still needs a clear hand off between the two locations. The load connects the sending and receiving work around one planned movement. Customer delivery choices also stay connected to the shipping decision. If a planner chooses a faster carrier service because a customer needs goods quickly, that choice connects to the shipment. If the business uses a lower cost service because the delivery date allows it, that choice connects to it. People can trace the delivery cost back to the route and carrier choice that created it. The vehicle may leave the dock and the goods may arrive safely, but the work still isn't finished. The carrier sends a freight bill afterward and somebody needs to check it. Freight costs and reconciliation. The goods have left the warehouse and the delivery may even be complete. Then the carrier invoice arrives. That invoice needs checking because the amount on the bill should connect back to the transport choice the company planned earlier, a/o, including the carrier, route, service, load details and expected freight charge. During planning, Dynamics 365 can calculate and expect a transport charge from the company's rate information. That expected amount gives the business a starting point before the carrier asks for payment. Later the carrier sends its freight invoice. Freight reconciliation means comparing that invoice with the rate and shipment details already recorded in the system. In plain English, the company checks whether the carrier charged what the company expected for the service that actually moved the goods. Imagine the plan showed a charge of $500. The carrier invoice also shows $500 and the shipment details match. That bill has a clear path through the checking process because the planned record and the invoice agree. But invoices don't always match the plan. Maybe the rate table was wrong, maybe the carrier billed for a different service, or maybe the load changed after planning and a charge needs an explanation. Without a connected record, finance may only see an invoice number and an amount, then spend time asking the warehouse and transport team what happened. Our management keeps the transport decision connected to that check. Rules can compare the carrier invoice with the expected amount and plan shipment information. When the details fit within the company's accepted rules, the invoice can move forward. When the details don't fit, the system sends the difference for someone to review. That means people don't approve every freight charge blindly. A transport planner may need to confirm that the carrier used a different service, or someone in finance may need to ask why an extra charge appeared. The point isn't to assume every mismatch is wrong, are you? The point is to notice the mismatch before payment. This joins operations and finance around the same shipment. The transport team chooses a carrier and service, that choice creates an expected cost, the warehouse sends the goods, and finance checks the later invoice against the record of what the company planned. Each team sees a different part, but they are looking at connected information. The built-in process has a clear scope though. Companies that need large scale, highly automated freight auditing, often add a third-party transportation management system. Those tools can bring deeper carrier connections and more automated checking rules. The built-in module handles the planned cost and reconciliation work inside supply chain management, while another system can extend that work when the business needs more. Put all of these building blocks together and the full picture starts to appear, where it fits and what it doesn't do. So where does transportation management actually live? It belongs inside Dynamics 365 supply chain management, running on the finance and operations apps. That's its home. It's a company that needs a structured way to plan inbound deliveries, outbound customer shipments, stock transfers between companies, all using their own carrier records, rate tables, and load rules. Now let's clear up a common point of confusion. Business central is different. Business central doesn't include this built-in transportation management module. If you're on business central and need transport planning, you're looking at a third-party transportation management system. That's the boundary, let's also keep the boundary clear on the other side. A built-in module doesn't replace every carrier portal, live traffic service, or advanced tracking tool. When a business needs live rates from many carriers, wider carrier choices, or deeper tracking after goods leave the dock, it connects a third-party TMS. Those tools handle the outside activity. Think back to the office building. Transportation management is the transportation desk inside that building. It connects to orders, warehouse work, and finance. It keeps the company's own transport plan together. Outside carrier tools may handle activity beyond that desk. Two different layers working together. Conclusion. Next Knowledge Nugget. Here's the simplest way to think about it. A transportation management turns business orders into planned movement of goods. Then it connects that movement to the freight costs the company checks afterwards. That's the full loop. Subscribe on your favorite podcast platform. Share this knowledge nugget with someone learning Dynamics 365, Supply Chain Management. Then explore our warehouse and inventory episodes next. Every load still depends on the stock sitting behind the warehouse door.