i receive this error when i try to post the invoice for the received Purchase Order as the system does not show the packing slips for some of the Purchase Orders. this problem is in very few Purchase orders rest are working fine..
Please suggest
i receive this error when i try to post the invoice for the received Purchase Order as the system does not show the packing slips for some of the Purchase Orders. this problem is in very few Purchase orders rest are working fine..
Please suggest
I have similar message yesterday, then I compare the table "inventtrans", comparing the success and un-success transaction. I found 2 different status.
For unsuccess >>> STATUSRECEIPT=0 and DATESTATUS = '1900-1-1'
For success >>> STATUSRECEIPT=2 and DATESTATUS = '2012-11-30'
Update both of field then the invoicing running well.
Had a similar message yesterday: "Physical updating quantity in the unit Lbs must be other than zero," when trying to post a PO invoice.
NOTE: The item causing the issue is ordered in Lbs and stocked in Ea. The unit conversion (Iventtory Mgmt / Item Detail, Setup/Unit Conversion) is "Lbs * 15.3144 + 0 = EA, Round off". Using DAX 2009, kernel version 5.0.1500.2116.
PO sequence: ordered 32Lbs, posted PO / changed order to 64 Lbs, re-posted PO / pack slip posted 64Lbs / invoiced 32Lbs / error on invoice of 2nd 32Lbs.
Cause of error: rounding error, off by .000001 Lbs
Classes\InventUpd_Financial\initUpdate
At line 23, insert -- info(strFmt('%1', str2Num(physical, 0,10,0,0) ));
Result: "0.0000010000" - this is the Remaining Physical Qty and gets rounded to zero in InventMovement, causing the "must be other than zero" error.
Temporary resolution:
Waited until after hours, applied following edits, posted invoice, then commented out these edits: Still need to find out what the proper rounding should be before I leave it in there.
Classes\InventUpd_Financial
method initUpdate, insert at line 23:
if(abs(physical) < 0.00001)
physical = 0.00;
method updateFinancialReceipt, insert at line 41:
if(abs(addQty) < 0.00001)
addQty = 0.00;
Permananet Solution:
Still need to track through the code to see where the value is rounded. The variable "physical" is used in InventUpd_Financial\updateNow to determine if class InventUpd_Physical needs to be called - somewhere in InventUpd_Physical this number is rounded and InventUpd_Physical/checkUpdQty throws an error message with @SYS19586. My gut says that rounding the calculations to the same precision will solve the problem, but my schedule says it'll be a while before I can do that, hence the "get this PO invoiced & paid for" dirty solution.
I am getting the same error- "Physical updating quantity in the unit must be other than zero" at purchase order invoicing but my unit of measure for the item is set to each and it does not have any conversion factor. Any idea why this error..
Here is what we have done to resolve the issue when it has come up:
Found the problem - the conversion factor from CASE to OZ had to many decimals thus creating a false impresion that the Physical remaining was something other then zero. I think the problem was that the unit conversion was .044 and then switched to .44 . I went to the po, and set the units to lb then back to can. That fixed the problem.
Had this problem today. 05/18/10 The problem was caused when the po was created then the unit conversion changed since then.On the PO , I switch the units to LB, then back to CASE for all of the items and that fixed the problem.
08/02/10 I think this was caused because the unit of measure conversion factor was changed after the po was created.The Po was created at 4:32pm and the unit conversion was changed at 4:37pm. There were 208 on order which was incorrect, I deleted the PO line and recreated it and it put 200 on order.To find that out I went to the "Inventory" Button and went to "Transactions" I went ahead and posted the purchase order.
Hi,
You mean you were trying to post Packing slip with Zero Qty?
Regards.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
André Arnaud de Cal... 290,339 Super User 2024 Season 2
Martin Dráb 228,177 Most Valuable Professional
nmaenpaa 101,148