# DMT Adjust QTy - NEG?

I had to ZERO inventory and pulled the On Hand Qty from PartBin. I don’t know if there is something way after the decimal but when I tried to run it in DMT i got a message that it will cause it to go Negative. How can it go negative when it is the number I pulled? This is in a test environment so no transactions.

I assume there is no lot or S/N tracking, and this bin is not “Non-Nettable”.

What happens if the DMT file has one less than the the qty you think is in the bin. Like if PartBin.OnHandQty say 25, and you do a dmt adj of -24 (or -24.9) ?

# Edit

another thing to try… Does it work (using the displayed QOH) in Quantity Adjustments?

I am thinking there is a decimal. Can you get SQL to show real number and not round?

Even if you can’t get it to display to the nth decimal, you could make a BAQ to returns boolean value if

``````IIF(PartBin.OnhandQty <> ROUND(PartBin.OnhandQty, 2), true, false)
``````

Adjust that 2nd parameter in ROUND() as needed

I don’t want rounding. I thought SQL would pull it without rounding.

How do I get no rounding in BAQ or SQL?

That was just to see if the value had any far out decimal places.

If OnhandQty = 24.99999999999, but displays as 25, you could compare its orignal value to the rounded value. If they are equal then there is no extra decimals.

ROUND(24.99999999999, 2) would return 25.00, which is not equal to 24.99999999999. Indicating that there are deciamls out past 2 places.

1 Like

oh…

Ok, evidently I don’t know what I am doing…UGH

two things …

1. The data type shouldn’t be Decimal
2. use Operators -> If x Then y Else z in the Functions pane, for the If statement (which won’t be implemented as an if statement)

# EDIT

calc field should be

``````(case when PartBin.OnhandQty <> ROUND(PartBin.OnhandQty,2) then 1 else 0 end)
``````

(using 1 and 0, instead of true and fals)

Did you try doing a manual Quantity Adjustment?

@Kimberley you are using IF and not IIF (2 I’s.) and it looks like your type should be Boolean not decimal if you are returning true/false, otherwise use decimal and return 1, 0.

I get the message that I will have Neg on Hand if I try to manually adjust it…UGH. I am just in my test environment but I need know how to pull the corrected numbers for when I go live. I originally pulled them in SQL.

OK I added this and I don’t know why I need a true false Statement. I am just trying to find the correct value of the QTY on hand.

BTW - DMT Qty Adj does include a boolean field you can optionally use called ‘AllowNeg’ (or something like that), when set to true will tell DMT to process to negative when the BO responds with the Negative warning (which is caused by your Part Class setup for the part).
If you want to adjust the exact amount, the rounding is being controlled by your UOM setup.
I have a client that had EA once setup to allow decimals and then disabled that (EA really should not allow decimals and no rounding), but there were already values of .99999999. To fix it, we had temporarily enable decimals to the furthest place and manually make the adjustment (After logout/in the decimals will display in the UI). Then we shut decimals AND rounding off and then going forward DMT adjustments were not a problem, after we corrected all the decimal data.

1 Like

Not sure if it matters, but that bin is “non-nettable”?

I was able to do some tests and found that the PartBin file can use decimal places out past the settings in your company setup.

Forget about that calculated field with the case statement. Just change the format of the OnhandQty column to: `->>>,>>>,>>>,>>9.9999999999`

If that doesn’t show anything, make a calc field with:
Name: MegaOHQ
Type: Decimal
Format: ->>>,>>>,>>>,>>9.99
Label: ExtOHQ
Formula: `PartBin.OnhandQty * 1000000`

and see if that shows any far out decimal places

In the pict below,

• I tweaked (via SQL) part AN-0001 to be 57795.999999990 (well past the 2 digits we’re setup for). It normally shows as 57,796.00 on all forms(“On Hand” in the BAQ below).
• OHQ is that same value but with the format set to `->>,>>9.999999999`
• MegaOHQ is a formula of `OnhandQty * 1000000`, with the column format just 2 decimal places

Hope this helps

2 Likes

more than likely that will be our problem. But I can’t change it to Rounding to see the correct QTY because it is serial tracked.

I will get with them and see what they want to do. I may just let it go negative for now…

If that were serial tracked, the Qty Adj window should have enabled the Lot Number field.

If it truly is serialized, you should enter a value of -1, then select the lot or S/N to remove. And repeat for the remaining 2 units in stock.

I think Calvin is on to something with the non-nettable. The grayed-out on-hand quantity says zero in Kimberley’s screenshot (for the warehouse quantity), even though the (only) bin on-hand quantity is 3. I know the warning is about the bin, but somehow it’s not believing the 3 OH.

This is what made me question it.

Since Non-Nettable bins are intended to be excluded from QOH, maybe there is a bug with respect to this. The QOH in that Bin is 3, but the available QOH is 0. So subtracting 3 (in the Bin) from the 0(“On Hand”) could be causing the issue.

@Kimberley try transferring those 3 from that bin to a nettable bin. Then see if

1. Bin `HARDW` still shows a qty. Note: it shouldn’t appear at all. If it does but shows zero, then theres some far out decimal
2. You can issue the 3 from the newly selected bin
1 Like

I adjusted out 3 and allow go negative. I could change the BIN to Nettable. I added back qty of 3 for now. I have another environment I can play with this to I can nail it down for Production.