Transfer Order or Transfer Journal? And What is the Difference Anyway?

It is very important to understand that Dynamics 365 for Finance and Operations offers two distinct functionalities for moving inventory between inventory dimensions. That is right, I didn’t say storage dimensions, I said inventory dimensions. I’ll explain later what this means exactly.

The two functionalities sound very similar, except that one is an order and the other is a journal. But do not let the similar names fool you, they are pretty different indeed.

Transfer orders are a much more complex functionality and cater to the following situations:

• When two warehouses (either at the same or at different sites) are so far away from each other that the transit time is significant and there is a need to be able to ship the goods out of the originating warehouse, keep track of them during transit and then receive them into the destination warehouse when it gets there.
• This being said, when shipping documentation is required to accompany the goods.
• When these orders fall under the regular tasks of the warehouse staff and should be handled as such; the warehouse is expected to pick – pick register – pack/ship the outgoing shipments and to register – receive the incoming ones.

To achieve these goals, the transfer order uses the same three step pick & pack process the sales order does. You may release picking lists to the floor with the same filtering and grouping logic you use with sales orders, then register and finally ship them. You may also skip the picking process and ship the goods in one step if your settings allow for it.

Note: this blog post does not discuss the use of advanced warehousing functionality but the principles of shipping and receiving a transfer order through the warehouse apply with advanced warehousing as well.

It also appears on the Arrival overview for processing if the filters are set properly.

To achieve the traceability and transparency during the delivery, it uses the transit warehouse, which is assigned to the originating (!!!) warehouse. The items in this warehouse remain at all times hard reserved against the transfer order, so we do not have to worry about their cost being recalculated if we are using moving or weighted average as our costing method.

By running reports on the inventory and its value in these transit warehouses, we have a clear snapshot at month end without the inventory value being added to where it isn’t anymore or where it isn’t yet.

Sounds like a wonderful functionality, and it really is. However, there are a couple things we have to be aware of before using the transfer orders:

• First and foremost, if none of the above mentioned criteria is true, the transfer order might be an overkill as the processing time of a transfer order is significantly longer than that of a transfer journal.
• When receiving a transfer order, although the system offers the option directly on the transfer order form, it leaves very little room for manipulating data. This form is not meant to deal with high volume receiving of transfers. The point of the transfer order is that it would be processed through warehousing functionalities (whether it to be advanced or simple WMSI). If registration is mandatory for the items to be received, it has to be done line by line on the order from this form before receiving. If any modification to default receiving locations or quantities needs to be done, it has to be done through the line by line registration.
• Once a transfer order ships, it sits. While on sales orders we do have the ability to cancel a packing slip any time before an invoice is issued based on it, we do not have the ability to do this with transfers. Users have to go through the three step pick & pack process and this process provides ample opportunity to catch any mistakes. If the shipping of a transfer is posted, there is no other way to ‘undo’ that than receiving it at the destination and ‘sending’ it back in some transfer format. This is because the inventory and its value are sitting in our books throughout the whole process, it merely changes location/cost center etc, it leaves very little negotiating room for dealing with quantity errors. This however does not only add manual work but will also have an impact on the weighted/moving average calculation as the system will recalculate when inventory is received at destination and then again when it is received back in originating warehouse. So best to be careful.

Transfer journals on the other hand are a way simpler and much more versatile functionality in Dynamics 365 for Finance and Operations. You may use them in the following situations:

• When items need to be transferred within a warehouse between bin locations.
• When items need to be transferred between two warehouses which are so close to each other that there is no need for transfer documents and/or transparency of items during shipment.
• Warehouse personnel doesn’t need to handle the transfer as part of their daily standard operation of receiving / shipping.

In addition to this though, the majority of users often forget that transfer journals are also used if items are received into inventory with the wrong tracking number (batch or serial). Tracking numbers are created with the need of precise tracing options. Tracing in Dynamics 365 for Finance and Operations is based on transactions – any new transaction which involves inventory with the dimension will be listed and creates a trail for tracing purposes. So if an accidental wrong tracking number could just be simply overrode by the user, it would lose the traceability.

Now of course adjusting the inventory out and bringing it back in again with the correct numbers is an option, but it is a lot of manual data entry and can create issues with the inventory cost. Dynamics 365 for Finance and Operations adjusts inventory out with the running weighted average value of the inventory at the time of posting the adjustment. This might be different at the time of posting than what the purchase value of those exact items were (unless you are calculating weighted average within the batch dimension and there was only one receipt into the batch or multiple receipts with the same price). A simpler way is to use the transfer journal to transfer the inventory not between storage (physical) dimensions but between tracking dimensions. Create a line where the site – warehouse – bin location combination is the same on both the ‘from’ and the ‘to’ side of the transaction but the wrong batch number is identified on the ‘from’ side and the correct one on the ‘to’ side.

Be careful however if you are using the batch dimension for financial cost value calculation as this will impact the cost of the batch you transfer to.

When you are tracing either the wrong batch or the new batch, this transfer transaction will create the link and will display both.

If you have any questions about using Microsoft Dynamics 365 for Finance and Operations, please connect with us!