I hear you - I already know what I am in for. We’ve already been round and round about how why my idea of issuing ACTUAL usage is more accurate then their backflushing ESTIMATED. They don’t want to hear it 
That’s the whole reason we are going negative (on the reg) in the first place.
if you ask me, Epicor got the logic slightly wrong. No offense intended.
They call this:
this.LibProcessFIFO.NegativeFIFOTest(this.ttInvTrans.PartNum, vLotNum, vPlantCostID, this.ttInvTrans.TransferQty, this.Part.IUM, out vError);
But instead of passing TransferQty,which ensures that it doesn’t exceed WH onhand, it should pass the delta of the proposed transaction: (actually - don’t even do that, just use this as a condition whether to call the method above)
| From Xfer Qty | To Bin Qty | Delta | IsFifoChecked |
|---|---|---|---|
| 10 | -10 | 0 | FALSE |
| 10 | 10 | 20 | TRUE |
| 5 | -10 | -5 | FALSE |
| 10 | -5 | 5 | TRUE |
| 10 | 0 | 10 | TRUE |
This way you would only FIFO check if the delta is greater than 0 because otherwise you are just reconciling a bin (and only to 0 it out). For example - if you try to move more than the bin requires to 0 - it requires FIFO
| From Xfer Qty | To Bin Qty | Delta | IsFifoChecked |
|---|---|---|---|
| 20 | -5 | 15 | TRUE |
A more basic way would say, just ignore FIFO checks if you are moving into a bin with negative qty, but what fun is that.
Now I’ve got to figure out how to change this - I’ve found my base processing code but I am pretty confident it’s not as easy as copy/pasting into a base-processing BPM. I’m also assuming injecting code into the server DLL is a relatively bad idea 
@Bart_Elia Who do I harass @ Epicor for this type of info?
so you need permission to change a FIFO setting, but drilling into the server code to circumvent everything, no problem? wow.
Well circumventing everything is a strong statement. I found they really are using the fifo costing - the issue occurs because we are also backflushing which is causing negatives.
I understand the initial logic behind the fifo check but it is flawed as I mentioned above because it does not take into consideration those negative bins. I am slightly modifying the code to take that into consideration because we would be circumventing it manually either way. The problem that occurs is that the qty you can move in one transaction is limited by the perceived onhand in the warehouse. So if I do nothing, my people are forced to breakdown transactions to reconcile these negative bins.
In the case of the following bins qty’s:
+1000
-1000
10
The perceived onhand is 10 - so it would take 100 transactions of 10 to resolve this - NO WAY! The other way would be by using inventory adjustments but we limit that power to only a few, not the standard emps on the floor - so this would dump extra work onto the supervisors.
We had similar issues, and Epicor sent us an SQL script that corrects the FIFO quantities. For 10.1.400 it was called “CR34092MPS_10140024_SQL”, which is part-specific.
Have you also tried running “Refresh PartBin QUH From PartTran”?
Would setting the part class to stop on negative qty prevent this, or would backflushing still require negatives?
Thanks for the input. Refresh PartBin fix had no effect.
We have to be able to retain the ability to process the negatives - unfortunately this is due to our choice of backflushing instead of issuing.
Regarding the fix from Epicor - it stinks that it is part specific - I know we have multiple parts that are being affected. I wonder what the fix actually does.
do you have the backflush bins specified in the resource groups? If you remove those, it will look for bins that have on hand quantities and backflush from there. which bin it takes them from is a coin flip I guess, but it would reduce the negatives problem.
@Banderson Which leg do you prefer to cut off? lol
haha, yeah, that’s pretty much why backflushing and FIFO don’t really go together… (like you’ve already alluded to)