The following scenario has been raised and should be considered subject to change:
• Create a purchase order for item Y into warehouse X.
• Receive the purchase order.
• Crete a transfer order for item Y from warehouse X to warehouse Z. Both warehouses are warehouse-management-processes enabled.
• In the transfer order header, select delivery terms that have the ‘Add transportation charges to orders’ parameter turned on.
• Navigate to the load planning workbench and create a new load for the transfer order.
• Click on ‘Rating and routing’ and open the rate route workbench.
• Click on ‘Rate shop’ and make sure that at least one rate is returned without exceptions.
• Select a rate and click ‘Assign’.
• Reserve the inventory, release the load to the warehouse and perform all the transfer issue work.
• Confirm the outbound shipment.
• Although the following miscellaneous charges are set up, the transportation charges are not applied back to the transfer order line.
The charges should be visible in the transfer order lines as these are visible in the purchase order lines.
Currenlty the functionality is not as richly built in transfer order scenarios and many customer's would very much benefit from expanding this area.
Suggested by Microsoft – Under Review – 1
Category: Transportation managementIt is not possible to combine different order types in planning a load, for example combining sales orders and transfer orders. But a distribution company with their own trucks and many facilities from which they deliver to customers, are doing this routinely to make sure trucks are as full as possible. The load planning workbench today cannot combine sales and transfer orders but when the FROM to address is the same, it should allow this. total weight and volume will be indicated as usual and the user can make correct load planning decisions
KB 4010426 added the ability to rate route plan with change management enabled - previously, you would receive error:
“Change to the document are only allowed in state Draft, because Change management is activated.”
You can now rate after installing the KB, however, you cannot have charges flow back to the PO ("Add Transportation Charges to orders") with change management enabled. The same error occurs.
This has been determined to be a feature gap that requires a design change. Please vote up if this is something that your business needs.
It should be possible to process one invoice for transportation services that includes more than 1 freight bill. Transport vendors send invoices that include more than 1 contracted service, this can be daily or monthly. They don’t send one invoice per freight bill.
Now in D365fO you can only generate one invoice per freight bill and you cannot use the same invoice number for another one.
There is a workaround about adding lines to the previously created freight invoice with the details of your other freight bills. However the lines need to be filled out manually. So they can just go back to the Freight invoice details form, click New on the line and enter the information there.
The process should be easier and more automatic.
Many D365 customers use either standard purchase order / invoice match logic or invoice match in ISV products like exflow. It's therefore not optimal to have second invoice reconciliation process for Freight invoices in TMS. Instead of using TMS freigt invoice reconciliation, TMS could generate a Freight purchase order based on freight bills and thereby allowing invoice match of freight invoices to be performed using standard D365 invoice match process or ISV products.
It is typical for distribution companies to reconcile an outbound load when a truck returns to the distribution centre (DC). Typical requirements for this reconciliation process include:
1. Ability to create / post invoices from the Load planning workbench
2. Link all sales invoices to a load such that on return to the DC users can register the invoices brought back. This helps users to monitor / audit / control that all the invoices on truck (load) have been addressed / returned from the delivery run
3. Ability to post a credit note for an entire invoice to reflect an uncompleted delivery - example shop closed when truck arrived to deliver at shop
4. Ability to record the total payments received for a specific load (this means that a driver deposits an amount of money with the clerk - this money reflects the money collected during the delivery), issue receipts to driver for the money collected
5. Ability to record total undelivered quantities - customers may not accept items on invoices. To record these items / quantities in a load reconciliation process
6. Reconcile each invoice on truck : allocate payments (from deposit amount to customer), undelivered quantities, credit notes used to pay invoice, etc
7. Display variances to reconciliation clerk - help to identify the variances by invoice
8. Automatically generate credit notes, payments and settle the same to the invoice being reconciled
This issue has been reported through our CSS system and is made available for voting.
In the transit time engine where the transit time is specified as from and to
zip-code and country, and maybe also state, it is not possible to specify the
to-part with a range of zip-codes.
In the rate base the to-part is specified as a Drop-off postal code from and a Drop-off postal code to, and as the transit time is related to the rate is very illogical that the transit time engine do not follow the same concept.
Our customer has several carriers shipping to most of the world imagine to number of records to create, not the mention the maintenance work or the impact on response time.
Against an inbound shipment, route rates for landed costs can be added in the currency that those costs will be received. When the inbound shipment is confirmed, the route rates are written as charges to the PO line, but the charges are written in the currency of the PO rather than the currency that the route rates were added to the shipment. When the PO is invoiced, the postings to the shipment cost accrual account are in a different currency than the postings created when the freight invoices are processed. This makes reconciliation of the shipment charges accounts impossible, due to a) different currencies used on the 2 different postings, b) normal exchange rate movements between the 2 postings. If the currencies were the same on both postings, this would simplify postings for reconciliation purposes.
Need charges written to PO in the currency that they are captured in the route rate details form
When opening products there are 3 fields that is seldom used by most customers:
NMFC code (NATIONAL MOTOR FREIGHT CLASSIFICATION)
These fields are on the table : WHSEcoResProductTransportationCodes
This table is only configured with configuration key "WHSandTMS"
The functional footprint for these fields are very low, and it would be nice to have a separate configuration keys to disable these fields. It seams these fields originate from the old WAX/TRAX solution. and is only used for the US car industry ?