We have a customer that has raised a question about inventory availability that I haven't thought about before, and frankly, don't know how to respond to. Here are the steps to recreate the scenario (The customer is using NAV 2009 R2 classic):
1) Let's say the customer would like to purchase item no. ABC on 06/10. This item has never been purchased before. So, they create a purchase order, and place this item on the PO, marking the document and posting dates as 06/10. They would like to receive this item into location M.
2) Once the order is received, they would like to create a transfer order for item no. ABC and and move it from location M to location P.
Assume step 1 was successfully completed. Therefore, as of 06/10, we expect to have item no. ABC in stock. However, when creating the transfer order in step 2, they *mistakenly* set the Posting Date to 06/06. They proceed to post the shipment and receipt together. Lo and behold, the transfer order posts successfully as well.
So imagine the customer's surprise when they realize that item no. ABC has sat in stock for -4 days in location M! Their question: Shouldn't NAV prevent the transfer order from posting, since the purchase receipt is dated on 06/10 and the transfer order is set to post on 06/06? From a chronological standpoint, how does the system allow the transfer of inventory that's not officially there?
I'm sure there is a valid and logical reason for why base NAV 2009 R2 allows for this; I just haven't been able to find it.
Your help is appreciated.
Mohamad El-Sadek, MCP, MBSS, MCTS
G.R. & Associates, Inc.
0
Comments
standard functionality A) doesn't let you ship and receive at the same time, and can't ship unless you have a positive quantity in that location.
Good call on point A. I do see a sneaky little mod that was undocumented from the previous VAR where the "Ship and Receive" option was added in Codeunit 5706, but it's nothing more than calling the TransferPostShipment and TransferPostReceipt functions one after the other.
Regarding point B, I verified this scenario in a CRONUS database and I got the same results as in our customer's environment. Even though the purchase receipt was posted on a MUCH later date (i.e. the quantity was received on 06/10/14) to BLUE location, the transfer order was carried out successfully with no issues (shipped and received on 06/10/12) from BLUE to RED.
So it seems that NAV 2009 R2 allows this type of behaviour to happen by default? Am I missing something here?
G.R. & Associates, Inc.
Using your scenario, I posted a purchase receipt for qty 5 on today's date. I try to post a transfer on 6/1/14 with a qty of 10, and i get a stockout warning saying I don't have enough to meet the demand and the date filter shows ..06/01/14. They quantity says 5, but on 6/1 I had 0.
I can't really see how this would happen in the real world, unless it was a mistake, which is what you indicated had happened. I would reverse the transfer and then post it correctly. IMO, while it might be a "bug," sometimes it's better to leave the ones that aren't supposed to happen in the normal course of business anyways, unless if it damages data.