Physical Inventory Process and Transferring between Locations

Thank you for your reply. This was very helpful. 
 

So if I’m interpreting this correctly, the standard process will allow you to enter as it physically exists, and at the end of the process will automatically make the transfers to the correct locations without any further entries needed outside of the standard physical inventory process, right?

@markusray17 I hope it’s ok to ask a few more questions as we are diving deeper into this.

1. how strict is the location field? Is it like warehouse, where it's essentially carried through on every document where a serial is allocated with all different allocation restrictions? Or is more of a display type field used for tracking and general knowledge without all of the same  restrictions that accompany warehouse mgmt?

2. For example, is location required every time you allocate a serial to a document? And if you if so, will sales orders for example, error if you try to process a sale for a serial out of the same warehouse but a different location?

I hope i’m making sense, but if not, let me know and i can try to provide more clarity.

I will load all the locations because some items may put to a location that is a empty location in the system. I will unable to scan the location if I didn’t put it on the PI list. 

@ckwiat46 I didn’t get your point. 

I guess you don’t understand what’s the allocation?  Allocation you can think it’s a states that the items are on the way and hold the inventory by some document(Waiting to picking, picked and back to shipping area or transfer item between warehouse )

Location is tell you where you to pick your item. The location is not requested when you submit SO. The location will generated by system when you create shipment. Based on your inventory level, system will give you one or more location to pick item.  

I can’t speak to scanning or serials/lot numbers as my company does not use those and I haven’t looked into them much.

On the web client it does let you add a row to the PI for additional locations(that is empty in the system). And yes if you enter the count as it physically exists the system will generate an adjustment that will correct the system inventory to match the physical count.

SO Allocations don’t use a location(Shipment lines do). On the shipment it will default based on your location setup as well as current stock levels however you can change it to any location that shows having stock in the system. 

I’m not certain I understand the question on locations but, you can restrict locations on the Warehouse page(Locations tab) and those restrictions will follow through on any page that uses locations. On Sales Orders for instance it will affect the available quantity the system shows if you were to untick the Include in Available Qty option.  

Ok, thank you for this information, all very helpful.

I think you got a good answer to your original questions, but this one hit a nerve with me as it’s pretty near and dear to me as well.  We run FIFO costing, and many people don’t.  For that, “how does the system work” is only half the issue.  Maybe I’m reading more into your question, but I think you wanted more insight into what others may do in this case. If that’s not the case, feel free to skip reading the book below.

The system has its way of working, but the business side can be impacted significantly by the choices you make in handling this situation if your configuration is similar to mine.  Short version, I recommend either swapping the parts physically to match the system or count as the system states and follow up with a stock move afterwards.  A feature to perform a correcting stock move during physical inventory would be EPIC!!!  In my configuration, adjusting out and back in is very, very bad financially.  Explanation why is below.

Physical inventory is designed to verify inventory and correct discrepancies.  It does so by IN Issue for inventory shrinkage and IN Receipt for gains.  If you are running standard cost or don’t care about inventory value on hand, this may not be a big issue as cost is pretty static.

If you are running FIFO and maintain different values for the cost of each unit on the shelf, this can have catastrophic impact on inventory value.  For instance, imagine having a serialized item on the shelf that costs $40k new and another on the shelf that is valued at a $5k repair cost.  Swapping the locations on these under FIFO via physical inventory will result in a $40k shrink and a $5k shrink, but it is very likely that the net of the offsetting receipts will not be $45k by default.  If performed via a stock move, the cost layers are PRESERVED, and my work life stays far easier.

Having spent time working in the storeroom to reconcile physical inventory (and daily cycle counts), I can attest to the practice of physically moving the parts in some cases to match the system to preserve the value in the system.  Eventually, we implemented in our legacy system a “reject this one from the count” functionality to throw the item out of the count, fix it via stock move, and then add another functionality to add the item back into the existing count.  It took extra effort, but it was far less painful as an end user to do either of these approaches than to explain why I inflated or deflated inventory value when the part was neither really lost nor found.  We have not implemented such functionality in Acumatica yet, but we likely will need to do so if we can’t create an “in PI stock move” customization.

We have a similar question - but ours also entails us bringing in a return product as the product it was sold as to ensure that the customer is receiving the credit for what they purchased.  As we bring in product, we have it go to the “returns” warehouse, but our problem is that the product consists of several unique sellable items within a Kit.  We need it to disassemble, move 1 or 2 of the parts to the Returns with a different Sku# and then to move the 3rd part to be scrapped as we cannot re-sell it or treat it as a sellable unit.  The 1 or 2 sellable units are tested and then moved back into the default inventory as a sellable unit and either assembled into another kit or sold as is.  Our challenge is looking to have something that is a bit more automated to get the financials to all align, but also to move the items into the proper “location”.  The last twist is that there are some products that if never opened can move directly into a sellable unit in the default location.  Any ideas on how to best address?

@annekseymour, if you really wanted to bring in on physical inventory, you could credit the customer manually.  However, in what you describe, my personal preference (wearing my quality manager hat) would be to isolate those materials outside of the physical inventory and then complete the SO Return as you normally would after completion of the physical inventory.  This allows all your standard business processes to be followed without having to make exceptions to your business processes.  Once the SO Return is completed, you could disassemble the part and scrap the unsellable components.  This allows visibility that the transaction occurred as a return from a customer rather than an untracked inventory change that requires an untracked (to the source) adjustment created by physical inventory.

I tend to like very traceable transactions to what changes inventory.  In my world, an adjustment in physical inventory means someone screwed up in following procedure and there may be a need for retraining, process improvement, or in extreme cases disciplinary action.

Hi @Brian Stevens ,

Thank you very much for this detailed write-up, and apologies to everyone else to tag this already answered question. 

Brian, could you go into a little more detail around the workaround you have implemented to throw items out of the count, and then get them back into the count at a later stage?

We’re sitting with a very similar situation, where our items are all tracked using FIFO, and we’ve recently implemented lot tracking on items. So over and above the FIFO complexity, we now have to contend with lot tracking as well. To further complicate matters, we have a retail outlet, and thus all stock is located on 1 location (shopfloor), and therefore the lots are all thrown into this 1 location. this is going to be fun to deal with in a stock take process.

Our current thinking to ‘solve’ this, is to have a Scan & Count screen that sits above the regular physical inventory screens and perform the counts grouped by SKU. After the count is completed, this count would then be distributed among all of the lots in the actual physical inventory review, taking FIFO principles into account.

What would your thoughts be on such an approach?