Can You Transact on Not Yet Received Quantities in D365 F&O and AX?

The Pitfalls of Registered Inventory

This blog focuses only on the product versions: Dynamics 365 Finance & Operations & Dynamics AX 2012

Registering incoming inventory is a step that is mostly known to be used in conjunction with mandatory incoming quarantine requirements. However, even those companies that do not use mandatory incoming inspection often implement the multistep receiving process in the system and on the floor, registration being the first step.

Also it’s important to note that if you are only using WMSI and not the Advanced warehousing module, the Arrival overview form is designed to utilize the registration as a mandatory and necessary part of the receiving process. When the arrival journal is posted, the transaction is in a registered status until the product receipt gets posted.

This blog post will talk about some situations you need to be aware of when using registered inventory to make sure you do not end up in a costing pickle. It is by no means meant to talk you out of using registration, as it is a fantastic functionality as long as it is utilized properly. I will be talking about a WMSI situation and not involve advanced warehousing – some of these situations might be looked at differently in that context. I also need to note before we dive into it, that marking the warehouse as a physical dimension does not make a difference in the example scenarios and that these are built on the hypothesis that negative physical inventory is not enabled.

What is Registration Meant to Represent in a Business Context?

• It indicates that the inventory is physically present at your location – it has arrived and has been taken off of the delivery vehicle. However, your company has not yet taken physical and/or financial ownership of it legally.
• As a result, it does not have an estimated physical value yet (no GL postings happened), although the quantity is indicated on your on-hand inquiries.
• The registration can be cancelled without leaving an actual trace in your system – if the goods are found not to be acceptable. This is also the reason why users are able to register against a PO that is not confirmed, but are not permitted to receive.

An example would be when the warehouse team responsible for put-away has not yet gotten to these goods yet, however you did not want the truck to stay at your location for any longer than the allotted free time before you start paying wait fees to the transportation company.

The Problem

Considering all of the above, particularly the fact that registered inventory represents goods not yet in your company’s legal possession, it would be a logical assumption that inventory in a registered but not yet received state would not be available for transactions. But the reality is, that nothing in the system actually prevents that. (Again please note, this is not the case if registration is used along with mandatory quarantine requirements. In that situation, the registered inventory is physically reserved against the quarantine order and as such, is prevented from being accessed by another transaction.)

The concerns around transacting on this inventory can be grouped into two categories; those that are system related and those that are business related. Looking at the system aspect, the biggest concern would be inventory costing – considering your company is using one of the periodic inventory costing methods (FIFO, LIFO, weighted average or weighted average date). Take for example when inventory is registered into warehouse #1 without the product receipt being posted on 2020-11-19. That very day somebody transfers this or part of this quantity into warehouse #2 on a transfer journal. The journal has both physical and financial dates and GL postings with 2020-11-19 dates, as a journal is a finalized transaction as soon as it is posted. Then the product receipt is posted with a 2020-11-21 date. This means we have a financial date on the transfer transaction that is earlier than the physical date on the original incoming transaction.

The solution is that if you are allowing a business practice to transact on registered inventory, you must make sure to backdate your product receipt to the same date as the registration. This way when you are running inventory close, it will appreciate the right order of the transactions. That is easy enough of a work around, right?

Now let’s talk a little bit about concerns outside of the system, which represent a bigger problem. As mentioned at the beginning of the post, a purchase order that is not confirmed does not allow receiving against it. When you confirm a PO in D365 F&O, what you are indicating is that your vendor has confirmed the conditions of the sale (such as item, quantity, price, delivery date, etc.) and the two companies are now in a legally binding buy-sell agreement. If the goods show up at your location before this happens, signing the bill of lading/packing slip indicates that you have decided to take legal ownership of the goods. Then the vendor comes back with a much higher unit price on the invoice and indicates that it has never confirmed the price you had on your PO, and indicates that by receiving the goods you have agreed to pay what they were charging. And the legal back-and-forth begins. The system provides a safety net against these accidental situations by making sure the warehouse is not able to receive against an unconfirmed PO. However, as registration does not constitute as legal possession, there is no restriction on registering against a confirmed PO.

This registered inventory can now be consumed into a production order without a problem. So the bottom line is, this is a loophole. Especially in situations where consumption/transfer etc. are automatic and there is no manual interference to check the status of the inventory that is available for the transaction. The conclusion is still that registration is a useful functionality and you should not be scared to use it. But being clearly aware of all the potential rabbit holes means we can design our processes and system configurations to avoid them.

If you have questions about Dynamics 365 Finance and Operations, please feel free to contact us.

Read Next: 18 Warning Signs Your Business Need the Cloud

This post first appeared first on Encore Business Solutions.