Transfer Order or Transfer Journal in D365FO, What’s the Difference? (Video)

TRANSCRIPT

Katalin: Hello everybody, and welcome to our webinar about Transfer order versus Transfer journal – What is the difference? My name is Katalin Kegel, and I am a Senior Business Solution Analyst and Project Lead here on Encore Business Solutions. And I have been implementing Dynamics 365 for finance and operations and previous versions of the program for about 12 years now. My main focus is operations, training and logistics and a little bit of manufacturing. And I am very excited to bring this subject to you today.

So, let’s dive in right away. Some of you might have attended an earlier webinar I presented about different inventory options available in this system. And today’s subject I’m presenting is a little bit similar in a manner, but it also might seem very basic. And you’re probably wondering how can I make this subject into a full hour? But the reasons for me to present this, the differences and the appropriate business scenarios for both the transfer order and the transfer journals are the same as they were for presenting the inventory adjustment options. And that is because I’ve come across these functionalities being misused way more often than I would like to. So if I can help there, that would be wonderful.

It is very important to understand that the D365 F&O and previous versions of this system offers the two distinct functionalities for physically moving inventory between inventory dimensions. And please note that I did not say storage dimensions, I indeed say inventory dimensions. And we will talk about what that means exactly a little bit later. These two functionalities sound very similar, except one is an order and one is a journal. But do not let those similar names fool you because they are pretty different indeed. They were designed to handle completely different business scenarios. And if we apply one or the other under the wrong circumstances, they might feel cumbersome and might not even satisfy all our requirements.

So, today, we are going to be talking about the appropriate business scenarios for both of these options. We will go over the steps involved in using both of these functionalities. Then we’re going to talk about some tips and tricks regarding both the transfer order and the transfer journal. And then we’re gonna do a quick review of what we talked about today. And then we are going to have a Q&A at the end of the session. So if you have any questions, please feel free to either enter into the question panel in the meeting or just wait for the Q&A at the end when we are going to unmute you if you raise your hand within time to ask a question.

So let’s start this by talking about the transfer orders. The transfer orders are a much more complex functionality than transfer journals and they do cater to completely different situations. When I am in a position to implement these two functionalities for my customers, the three main pointers I usually bring up to describe the scenarios where a transfer order is the right option are the following. When two warehouses, whether they are on the same site or different sites are far enough away from each other physically, that the transit time between them is significant. This creates the need to be able to ship the goods out of the originating warehouse at one point in time and potentially by one user in that warehouse and then keep track of them, of this inventory, during the transit. And when the transit is over, receive them into the destination warehouse at the time when it gets there. And of course, that would mean a different user likely.

Based on this, another point is that shipping documentation is required to accompany the goods during the transport. And the last one is more from an operational perspective when these orders fall under the regular tasks of the warehouse staff and should be handled as such. Which means on the shipping side, the warehouse staff is expected to pick, register, and pack and ship the outgoing shipment and the receiving side the warehouse is expected to register and receive the incoming goods. So, if these requirements are present, the transfer order is the right option. To achieve these goals the transfer order uses the same three-step pick, pack process as the sales order does. You may release picking lists to the floor with the same filtering and grouping logic that you use for sales orders then register the pick and then finally ship the order.

You may also skip the picking process and ship the goods with the ones the packing slip if that is what your settings allow for. On the incoming side, it also appears on the arrival overview form for processing if the filters are set appropriately. Now, please note that the confines of today’s session don’t really allow me to discuss the use of advanced warehousing functionality related to transfer orders but the principles of shipping and receiving transfer orders through advanced warehousing are the same and they apply and advanced warehousing works very, very well with the transfer orders. If you have any particular questions about that, please feel free to reach out to us and we would be more than happy to or I would be more than happy to help you with that.

Okay. So what happens between the two steps, the shipping and then the receiving being performed is what helps us achieve the traceability and the transparency during the shipment of these goods on a transfer order? The transfer orders use what we call the transit warehouse. And so if you look at the screen, the first thing you will notice is that the second red box was placed on the wrong field, and I apologize about that because it’s highlighting the quarantine warehouse when, in fact, it should be highlighting the transit warehouse, which is the field to the right of the quarantine warehouse.

So what you’re seeing here is that we would create a warehouse that would be off type transit. That is a standard configuration warehouse type in the system. And then once we’ve created the transit warehouse, what we’d have to do is go back to our standard default warehouse, which will be the originating warehouse in a transfer order, and that’s very important. And then assign the transit warehouse to be the transit warehouse for that originating warehouse. I also need to mention that the transit type warehouses were designed to only be used in this particular context and automatically by the system when transfer orders are shipped or received. They are not meant to handle manual shipments and transactions into and out of that warehouse. So please keep that in mind and don’t ever design a process where you’re using transit warehouses manually.

Okay. So, items when they are shipped out of the originating default type warehouse, they move into this transit warehouse. And they stay there until they are received at the destination, okay? The items in this warehouse remain at all times hard reserved against the transfer order. And why that is very important is because that means we do not have to worry about the costing because the cost is not being recalculated within the transit warehouse even if there are multiple shipments of that particular item sitting in there, and you’re using moving or weighted average. The costing remains strictly linked to those particular products. Okay.

When the full processing of the transfer order happens there are four inventory transactions created. And let’s take a look at them. So what you see on your screen now, is on the top there’s our transfer order. On the header section, you see the originating warehouse, the destination warehouse information, transfer order number, ship dates, receive dates, and you see that the status of the order is received. Now, what I need to mention is that is the final status for a transfer order. Then you look at a purchase order or sales order, there is one more status, right, which is the financial update. But the reason why we don’t have a financial update on the transfer order because any inventory that we are moving, we’re only moving within our books. So they were already on our books when we own the inventory, at least physically, when we started shipping them and we still own them when we receive them, it’s an internal transfer. So there’s no need for financial update, meaning a received transfer order is a finalized transfer order.

Okay, below there, on the transfer order line section, you see which item, what quantity and a couple more details. If you look at the bottom screenshot, then what you see is the four distinct transactions created during the processing of the transfer order. So what happens is that when you ship the transfer order two transactions are generated. The first transaction on the screen is the one on the top, it sells it out off Warehouse 32, which in this case is the default type originating warehouse. And then the second transaction is generated automatically, which is a purchased transaction into the transit warehouse. So if we look at this, then we can imagine it as the originating warehouse has sold these products to the transit warehouse, that at the very moment, the third transaction also gets generated, which is going to be at that point a transfer order receive typed reference transaction in the transit warehouse that is an expected issue transaction.

Okay, so that at that point, we’ll have the issue status reserved physical because the goods are reserved physically in that transit warehouse against their outgoing shipment, but they have not yet been processed. And the fourth transaction that also gets generated at that point is in the destination warehouse, which on this screen is Warehouse 11. And at that point, it’s we have a receipt status ordered, meaning it’s an expected incoming quantity. The reason for all these transactions with these statuses being generated at the time is so when you’re looking at your own hand inventory inquiries, these can already be taken into account. So if you look at your ordered quantities in Warehouse 11, because you would like to see what quantities are you expecting to come in whatever the source, whether it’s a purchase order, a production order or a transfer order, the system will have these numbers to work with. Then when you post the receipt side, and you’re receiving it into the destination warehouse that the last two transactions get updated with physical and financial dates as well as the issue and the receipt status gets updated. And that’s when it turns into sold out of the transit warehouse and purchased into the destination warehouse. Okay, I hope that makes sense.

So moving on. By running reports on the inventory and its value in these transit warehouses, we have at any given time a clear snapshot, whether it’s month end or just a time when we would like to have information of our inventory without the inventory value and quantities being added to where they aren’t anymore, or where they aren’t yet. I hope that makes sense. It does sound like a wonderful functionality. And it really is. But let’s not forget that if none of those criteria that we talked about is true for the business scenario, then the transfer order might be an overkill and it might make things really difficult and cumbersome. The processing time of the transfer order going through the whole shipping process and then the whole receiving process is significantly longer than that of the transfer journal.

And if these steps involved do not provide the benefits that they are intended to provide, then all we’re doing is we’re just increasing the overhead costs associated to processing our data. And when we talk about the transfer journals, you will see that the transfer journal will create way less inventory transactions. So we have that to deal with as well that we are generating a large number of essentially redundant inventory transactions if we use the transfer order in a situation where we shouldn’t be using the transfer order.

So I have promised you some tips and tricks. Couple of things to keep in mind when you are using the transfer order functionality. So if you look at the screen, you’ll see that the transfer order screen itself offers the option to do the shipping and the receiving directly from this screen, right? But what we need to remember is that this if you do it through this form, if you perform these actions through this form, it leaves very little room for manipulating the data. So if you’re dealing with a transfer order where the shipped quantity and the received quantity is the same, there’s no partial shipment, there’s no partial received, you don’t have to worry about batch numbers, you don’t have to worry about for example, at the receiving end, splitting the quantity into several receiving bin locations, etc., then, by all means, use the shipping and the receiving functionalities right here on the transfer order form. But it 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 in the system. And whether those are advanced warehousing or whether those are WMS One, it doesn’t matter. If registration is mandatory for the items on the transfer order when they are received, if you’re using this form, it has to be done line by line on this order form before receiving. If any modification to default receiving locations or quantities needs to be done, it also has to be done line by line through the registration form. So that becomes really, really cumbersome. So make sure that if you use transfer orders and use them in the right context, you design your warehouse receiving and warehouse shipping processes to deal with the transfer orders, okay?

And the other thing that I need to mention, and sorry, the above screenshots just show you that these warehouse functionalities are very, very equipped to deal with transfer orders. And then there is a last sentence on the bottom of this screen, which I’m actually going to elaborate on a little bit. So one very, very important thing that we need to be aware of is that once a transfer order ships, a transfer order sits. And what it means is that while on sales orders and purchase orders, we do have the ability to cancel a packing slip or a product received anytime before a financial update, an invoice is issued based on it. We do not have this ability on the transfer orders, okay?

The idea is that, because users have to go through the pick-pack process, this process provides ample opportunity to catch any mistakes. So if the shipping of the transfer order is posted, there is no way to undo that. It has to go through the receiving at the destination. And then if it turns out that the quantities were incorrect, then we need to deal with them there and figure out how to potentially virtually send extra quantities back to the originating warehouse, or write them off. But at that point is when we need to think about the solution, okay? So the one obvious thing about this is that this creates a lot of extra manual work, right? But then there is another aspect of it that we need to consider. And that is, that this will have an impact on your costing. If you’re using weighted average or moving average calculation in the system.

Because as soon as you receive the quantities at the destination warehouse, that automatically calculates the inventory value in that warehouse. And then, when you are shipping any surplus that was not physically on that truck, you’re shipping it virtually back, you know on a transfer journal or another transfer order in the system, what it will do is it will take it out of the recalculated cost. So you might not be sending it back at the same cost as you brought it over to the destination warehouse at. And then once at that changed cost, you receive it back to the originating warehouse that automatically triggers the recalculation on that end as well. So what I’m saying is best to be careful and make sure that you have a process in place to eliminate any errors or as many errors as possible.

So that was all about the transfer orders. And now let’s move on to the transfer journals. The transfer journals are way simpler and in a way much more versatile functionality in the D365 F&O. And you may use them in the following scenarios. When items need to be transferred within the same warehouse between bin locations, then items need to be transferred between two warehouses, but these two warehouses are so close to each other, that there is no need for transparency of the items during the shipment or transfer documents. And then the other thing is that warehouse personnel don’t necessarily need to handle the transfer as part of their daily standard operation of receiving and shipping, okay?

Why we need to know about the transfer journal is that as opposed to the transfer order, it is an instantaneous transfer. So when creating the journal, you identify the from and the to dimensions. As you can see on the screenshot, I’m sorry that’s the inventory transactions, you won’t see that on the screenshot. But if you open up a transfer journal, you will see that you’re identifying the from warehouse, the to warehouse. The from bin location, the to bin location and so on on the same journal line. And then as soon as the journal is posted the system takes care of both the negative and the positive transaction at the same time, okay? So it’s deducted from the originating dimensions and it’s added to the destination dimensions with the click of a bottom.

The processing time is a fraction of what the processing time of the transfer orders is. However, there is no way to indicate the time frame between the shipping and the receiving as a consequence to that. There is no tracking of inventory and there is no option to allow two different users potentially at different physical locations to process the deductions and then the addition transactions separately. So in addition to the scenarios that I mentioned above, the majority of users often forget a very, very important use of the transfer journals. It is if items are received onto inventory with the wrong inventory dimension, any kind of inventory dimension. And that doesn’t just mean storage dimensions, that means tracking dimensions, which is batch and serial numbers, and product dimensions as well, color, size, configuration.

All inventory dimension values in this system are created with the need of precise tracing options, right? Let’s not forget that this is a system where the traceability satisfies the requirements of the pharmaceutical industry, right? So that means it’s very sophisticated and also very strict. Tracing in D365 for finance and operations is based on transactions and transactional history. So any new transaction which involves inventory with that particular dimension will be listed and creates a trail for tracing purposes and a tracing audit trail. If an accidental wrong tracking number could just be simply overruled by the user, it would lose that traceability. So that’s the importance of this.

So let’s put it into a real-life scenario context. Imagine that a shipment was received, and the wrong batch number was entered on it. And now it’s sitting on your inventory with that wrong batch number. Of course, you could do what most people would do, which is adjust the inventory out with an adjustment journal and then bring it back in again with the correct batch number, right? And it is an option, but it is a lot of manual data entry. And it can create some issues with costing, right? D365 F&O adjusts the inventory out with the running weighted average value of the inventory at the time was the posting of that journal. And this might be different at that time of the posting of this adjustment journal than what it was where the purchase value of those exact items were. Now of course, unless you’re calculating your weighted average within the batch dimension, and there was only one receipt and so there’s a lot of factors that play in here, but I just wanna raise your attention to the possibility of having costing implications.

So there is and then the other important thing here is that at that point, you completely lose the traceability because the moment you adjust out the inventory with the wrong batch number, it is in no way linked anymore to the inventory that you adjust back in with the right batch number. And so that one will in no way be linked to the original purchase order, okay? And that is an important link that we’re losing there. So there is a simpler way. And that is to use the transfer journal and to transfer the inventory, not between physical storage dimensions, but between tracking dimensions. Create a line where the site warehouse bin location combination is the same on the from and the same on the to side of the transaction. Meaning you’re not physically moving them, the originating locations are the same as the destination locations. But then identify the wrong batch number in the From batch number field and then identify the good batch number in the To batch number field.

Okay, be careful, however, and then post the journal and you will see that it will just simply move that inventory from one batch to the other. Be careful, however, if you’re using the batch dimension for value[SP] calculation, as this will impact the cost of the batch you are transferring into inventory. So that is another one of those subjects where if you need our help, please contact us and we will be very happy to go into the details. But I can’t talk about all of those within the confines of this session. So what will happen as a result of posting this transfer journal? Whether you’re starting your trace with the wrong batch number or the new right batch number, this transfer transaction will create the link between the two and will display both of them, okay? So you are seeing an example on the screen there where there is an inventory dimension change to an inventory transfer.

Okay. So what it does is it keeps that transaction history and then when you start tracing back anything that you’ve even made with the inventory that now has the right batch number, it will never lose the link. And then there will be a section of the trace where it will show you that transfer journal and show you that right batch number, in fact, was originally a wrong batch number which, in fact, came from a particular purchase order. Okay, hope this makes sense.

So, we have gotten to pretty much the end of our session, where we’re going to summarize a couple of key points of what we talked about. Transfer orders are used for physical transfers where the distance between the from and the to locations are long enough to have the need to process shipping and receiving steps at a separate time by separate people at separate physical locations. There is a need to track inventory while it’s on the road and there is need for documentation.

The transfer journals, however, are used for instantaneous transfers, where the from and the to locations are in very close proximity to each other, for example, bin locations within the same warehouse. The two transactions when we use transfer journals are posted at the same time, there is no tracking of the inventory between the deduction and the addition transactions. The transfer journals come with significantly less processing time, no documentation. And let’s not forget that they are also used for changing tracking and product dimensions on inventory.

And now we have come to our Q&A. So if you have any questions, please feel free to raise your hand and then you will be unmuted to have the ability to ask your question. Or I am going to ask my coworker Melissa to see if we had any questions entered in the panel during the presentation.

Melissa: Hi there. Yeah, I’m just taking a look at the question pane here. And I don’t have any that have come in right now.

Katalin: Okay, sounds good. So we’re gonna give it a couple more seconds in case anybody is going to raise their hands. But while we’re waiting, I’m going to move on to the last slide which is going to give you our contact information, my contact information. And I would like to encourage you to get in touch with us if you have any questions about any subject that we discussed today and we would be more than happy to help you out. And if there is no questions coming in, then I will thank you very much for your attention and have a lovely day, everybody.

Melissa: Thanks, Katalin.

Katalin: Thank you. Bye now.