Overflow in calculation of 2147480030 + 10000

bolko

Hi,
When I post SO or PO ...
"Overflow in calculation of 2147480030 + 10000"
How can I fix it? seem that the posting is correct but still showing the message..
Thanks,

DenSter

Looks to me like you want to put a really big number in an integer, and you just hit the maximum value.

bolko

Thanks,
But why happened when I posted SO and PO where I have to go to fix it..
directly to the code unit?...

DenSter

You must have orders with insane numbers of lines. I have not seen this happen before, even on orders with thousands of lines.

It feels like this is caused by a customization, since the number 2147480030 is not a 10000 increment. The least you should do is debug the problem and see what the program is trying to do when it errors out.

Kowa

This error usually appears in very large journals. It is somewhat strange that this happens when a PO/SO is posted. Are there any journal lines ( for barcodes etc. from an add-on ) automatically created when posting takes place ?
All you can do in this case is to delete/post the journal lines so the line number starts at 10000 again.
If this happens frequently it is possible to decrease the line number increment from 10000 to 10 , but then you can only insert a few new lines between already existing ones since the Line Number is part of the primary key, but this shouldn't be a problem in an automatic journal.

bolko

kowa,
You right.. It is a modification, I have a SerialNumber table that the last line number is " 2147480030 " ..
Could I decrease that number...

Kowa

First, you will have to run a report that renames the primary key to decrease all the line numbers in this S/N Table.
Then , to prevent this happening again the increment coding for the line number must be changed to a smaller interval.

:roll:

DenSter

Or, the code that creates the journal lines could be changed to not use that serial number as the basis to calculate the line number.

Kowa

If you are using a 3.6 or higher client/server on the financials database, you can also use BigInteger field instead of an Integer Field in the table, but then you will probably need to change the code ( integer variable ) too.

bolko

I'm using 2.6..
but I will run a report to change the SN line ( to lower #), and then modify rpt. "Post SN Journal"..
changing 10000 to 10
what do you think?

***

IF SNLedgerEntry.FIND('+') THEN
SNCounter := SNLedgerEntry."Line No." + 10000
ELSE
SNCounter := 10000;
SNLedgerEntry.INIT;
SNLedgerEntry.TRANSFERFIELDS("SN Journal Line");
SNLedgerEntry."Line No." := SNCounter;
SNLedgerEntry."Posting Date" := WORKDATE;
SNLedgerEntry.INSERT;

Kowa

If SNLedgerEntry."Line No." is part of the primary key then a RENAME is necessary(modify the "Line No." in the first few records manually (10000,20000,30000.. to 10,20,30.. ) to prevent insert errors, then step through the table renaming all the records, otherwise if "Line No." is not part of the primary key create a second variable SNLedgerEntry2, stepping through the first one and writing the other.
something like :
SNLedgerEntry2.INIT;
SNLedgerEntry2.TRANSFERFIELDS("SN Journal Line");
SNCounter += 10; // or even 1
SNLedgerEntry2."Line No." := SNCounter;
SNLedgerEntry2."Posting Date" := WORKDATE;
SNLedgerEntry2.INSERT;

You can delete the old records afterwards by filtering on the "Line No.".

bolko

THANKS, FIXED!