We are getting this error on Inv Transfer:
This transaction will result into a negative FIFO onhand quantity. Transaction not allowed.
Here’s what we are attempting:
Problems:
Refresh Part Quantities And Allocation does not resolve the problem.
Any thoughts to push me in the right direction?
Check the costs tab on Part Tracker. What cost method is this part?
Thanks @markdamen
Should be standard but here is what I show:
I have no idea what any of this means.
I’m not sure if it’s related or not, but we have an updateable dashboard that has to do with inventory and we’ve run into problems where a field in the grid, even though it’s not set to updateable, will write when saving the information. So what happens is that if an inventory change was made, and the dashboard isn’t refreshed before saving, bin location and overall on hand don’t match. I’m taking a wild guess and thinking that your customized screen has done the same thing with the fifo cost. You might be able to fix it with a UBAQ.
This is a widespread problem that has something to do with the migration from 10.1.400 to 10.1.600
Comparing data from the previous version I can see clearly there is a difference in the costing type of the parts. Regardless, you would think a costing type of NULL would be a red flag.
So I am curious:
What could have caused these discrepancies in the upgrade process?
How do I correct them? As I understand I have to 0 inventory to change costing type on a part.
Luckily I have some experience in automating the manipulation of inventory - trying to be positive here…
Expert opinions?
Seems the Cost Method has been lost somehow, and your onhand quantities on the FIFO screen don’t match actual on hand. Check your backups to see if you can find what cost method was set to.
Still suspecting you might need a data fix from Epicor to sort out the FIFO layers.
In my test environment - an easy fix was disabling FIFO layers in the costing.
I’ll have to talk to accounting to see if this is even a feature they use.
The response I got:
System is working as intended. Epicor was contacted at that time and they said it is functioning properly.
System does not allow you to transfer more than what is in the TOTAL WAREHOUSE. In the Example below – they only have a total of 99 on hand:
Broken out in the 3 bins below:
KASAI ASM 98
MAIN -360 (yes, negative, the system lets a BIN go negative, but the warehouse as a total can NOT go negative)
w-11-e-1 361
Any thoughts on how to get around this?
can you do smaller quantities per transaction? Moving won’t change your total, so move 99 or less at a time?
It’s a one time fix isn’t it? If you keep going negative with FIFO costing, your costing is going to be screwed up. So once you fix all of the negatives, you shouldn’t have to do it again. RIght? So smaller quantities in the transaction would be a lot easier than forcing some code wouldn’t it?
Note - their description of working as intended must only apply IF FIFO layers is enabled. Disabling it causes the issue to go away.
What exactly is the purpose of FIFO layers on STD costing? Seems like it serves no purpose because you are manually setting a price with STD right?
Additionally - if we don’t do any physical separation of the “FIFO” materials that are presumably different prices - what difference does it make?
?? accountants like things complicated???
If it wouldn’t slow the flow of people to the thread - I’d totally accept that as the solution! 
Just read through and am a little confused. Can you tell me what costing method your finance department uses?
Sure afaik, all costing is STD.
That is what I was hoping you would say!
FIFO layers are not required for STD costing. You can turn that off and be fine.
But to answer your original question, you have to do a quantity adjustment to bring the negative bin to 0 and the positive bin to 1. Like you found out, you can’t do an inventory transfer.
FIFO layers are not required for STD costing. You can turn that off and be fine.
Now how to convince accounting? 
It seems the FIFO layers only have any use if you are actually creating the pricing layers - my next step is to try to build a baq that shows parts with multiple fifo cost layers (or lack thereof) as evidence for my case.
Good luck! If your accounting department does not already know that FIFO layers are not needed for STD, then you are facing an uphill battle.
If your parts are truly transacting in a STD environment, you can always get back to actual on the individual transactions (variance plus standard). You would never go a look at the FIFO layers as that would be misleading (FIFO layer would only show the actual with no variance or standard).
