vorose
Member
We are having problems with rounding problems in our AP batches. When posting AP vouchers in 2W and 3W matching for the PO module we get batches in error and have to manually change the batch. Is anyone else experiencing this problem?
BrendaD
Member
We logged the following issue back in 2002
When matching a logged voucher to purchase order we are getting the following warning message:
Tax amounts do no balance - warning
Error: Amount Does Not Balance to Gross
This appears to be due to the logged voucher entry and the purchase order entry rounding the GST differently
After many e-mails to explain the issue these are the replies we got from JDE:
1. The programmer and I sat down and tested your issue today with the same data that you had sent to me. The programmer explained to me that when entering the logged voucher you should be entering the taxable amount
rather than the gross amount.
When I enter the taxable amount of 245.00 the taxes are calculated to be 30.63. When I enter the gross amount of 275.62 the taxes are calculated to be 30.62. If you want to continue entering the gross amount on the logged voucher then you can correct the tax amount in the voucher match screen. When it shows that you are out .01 you can go to the tax amount field and change it by the .01 to put it in balance.
I tried pressing the programmer about why it is calculated differently based on what field you put the numbers in. The explanation got rather technical and ended with entering the tax amount it how the program was designed and is how it is tested in development. Based on that response I would definitely recommend changing the way you enter vouchers and letting the system calculate the gross amount since that is how the software is being tested.
2. I e-mailed the programmer about this issue again. He said the only thing that can be done is to make the correction in the voucher match screen to bring the tax amount in balance. He was not completely sure how the system is doing the calculation when the gross amount is entered however, he again stated that entered the gross amount is not supported when it comes to reporting problems. Sorry I didn't get more specifics from him.
= NO RESOLUTION FOUND !!!! =
When matching a logged voucher to purchase order we are getting the following warning message:
Tax amounts do no balance - warning
Error: Amount Does Not Balance to Gross
This appears to be due to the logged voucher entry and the purchase order entry rounding the GST differently
After many e-mails to explain the issue these are the replies we got from JDE:
1. The programmer and I sat down and tested your issue today with the same data that you had sent to me. The programmer explained to me that when entering the logged voucher you should be entering the taxable amount
rather than the gross amount.
When I enter the taxable amount of 245.00 the taxes are calculated to be 30.63. When I enter the gross amount of 275.62 the taxes are calculated to be 30.62. If you want to continue entering the gross amount on the logged voucher then you can correct the tax amount in the voucher match screen. When it shows that you are out .01 you can go to the tax amount field and change it by the .01 to put it in balance.
I tried pressing the programmer about why it is calculated differently based on what field you put the numbers in. The explanation got rather technical and ended with entering the tax amount it how the program was designed and is how it is tested in development. Based on that response I would definitely recommend changing the way you enter vouchers and letting the system calculate the gross amount since that is how the software is being tested.
2. I e-mailed the programmer about this issue again. He said the only thing that can be done is to make the correction in the voucher match screen to bring the tax amount in balance. He was not completely sure how the system is doing the calculation when the gross amount is entered however, he again stated that entered the gross amount is not supported when it comes to reporting problems. Sorry I didn't get more specifics from him.
= NO RESOLUTION FOUND !!!! =
vorose
Member
Hi Brenda. Thanks for the information it sounds logical but when we=20
match a logged voucher to a purchase order we can't access the taxable=20
amount.=20
Can you?=20
Please respond to JDELIST Applications Discussions <[email protected]>
Sent by: [email protected]
To: [email protected]
cc:=20
Subject: Re: Rounding differances
We logged the following issue back in 2002
When matching a logged voucher to purchase order we are getting the=20
following warning message:
Tax amounts do no balance - warning
Error: Amount Does Not Balance to Gross
This appears to be due to the logged voucher entry and the purchase order=20
entry rounding the GST differently
After many e-mails to explain the issue these are the replies we got from=20
JDE:
1. The programmer and I sat down and tested your issue today with the same =
data that you had sent to me. The programmer explained to me that when=20
entering the logged voucher you should be entering the taxable amount
rather than the gross amount.
When I enter the taxable amount of 245.00 the taxes are calculated to be=20
30.63. When I enter the gross amount of 275.62 the taxes are calculated=20
to be 30.62. If you want to continue entering the gross amount on the=20
logged voucher then you can correct the tax amount in the voucher match=20
screen. When it shows that you are out .01!
you can go to the tax amount field and change it by the .01 to put it in=20
balance.
I tried pressing the programmer about why it is calculated differently=20
based on what field you put the numbers in. The explanation got rather=20
technical and ended with entering the tax amount it how the program was=20
designed and is how it is tested in development. Based on that response I =
would definitely recommend changing the way you enter vouchers and=20
letting the system calculate the gross amount since that is how the=20
software is being tested.
2. I e-mailed the programmer about this issue again. He said the only=20
thing that can be done is to make the correction in the voucher match=20
screen to bring the tax amount in balance. He was not completely sure how =
the system is doing the calculation when the gross amount is entered=20
however, he again stated that entered the gross amount is not supported=20
when it comes to reporting problems. Sorry I didn't get more specifics=20
from him.
=3D NO RESO!
LUTION FOUND !!!! =3D
XE B7333 SP20 Update 1 (tonns of ESU\'s)
Fat Clients Thin Clients - Citrxi & Portal
Windows NT & 2000 SQL2000
--------------------------
To view this thread, go to: http://www.jdelist.com/ubb/showthreaded.php?Cat=
=3D&Board=3DApps&Number=3D64652
This is the JDELIST Applications Mailing List. To stop receiving these=20
messages, login to http://www.jdelist.com/forums, click Control Panel, the=
n click Edit by "Subscribe / Unsubscribe from=20
receiving board posts by email, change message notifications, etc." and=20
adjust your subscription preferences. JDEList is not affiliated with=20
JDEdwards=AE
match a logged voucher to a purchase order we can't access the taxable=20
amount.=20
Can you?=20
Please respond to JDELIST Applications Discussions <[email protected]>
Sent by: [email protected]
To: [email protected]
cc:=20
Subject: Re: Rounding differances
We logged the following issue back in 2002
When matching a logged voucher to purchase order we are getting the=20
following warning message:
Tax amounts do no balance - warning
Error: Amount Does Not Balance to Gross
This appears to be due to the logged voucher entry and the purchase order=20
entry rounding the GST differently
After many e-mails to explain the issue these are the replies we got from=20
JDE:
1. The programmer and I sat down and tested your issue today with the same =
data that you had sent to me. The programmer explained to me that when=20
entering the logged voucher you should be entering the taxable amount
rather than the gross amount.
When I enter the taxable amount of 245.00 the taxes are calculated to be=20
30.63. When I enter the gross amount of 275.62 the taxes are calculated=20
to be 30.62. If you want to continue entering the gross amount on the=20
logged voucher then you can correct the tax amount in the voucher match=20
screen. When it shows that you are out .01!
you can go to the tax amount field and change it by the .01 to put it in=20
balance.
I tried pressing the programmer about why it is calculated differently=20
based on what field you put the numbers in. The explanation got rather=20
technical and ended with entering the tax amount it how the program was=20
designed and is how it is tested in development. Based on that response I =
would definitely recommend changing the way you enter vouchers and=20
letting the system calculate the gross amount since that is how the=20
software is being tested.
2. I e-mailed the programmer about this issue again. He said the only=20
thing that can be done is to make the correction in the voucher match=20
screen to bring the tax amount in balance. He was not completely sure how =
the system is doing the calculation when the gross amount is entered=20
however, he again stated that entered the gross amount is not supported=20
when it comes to reporting problems. Sorry I didn't get more specifics=20
from him.
=3D NO RESO!
LUTION FOUND !!!! =3D
XE B7333 SP20 Update 1 (tonns of ESU\'s)
Fat Clients Thin Clients - Citrxi & Portal
Windows NT & 2000 SQL2000
--------------------------
To view this thread, go to: http://www.jdelist.com/ubb/showthreaded.php?Cat=
=3D&Board=3DApps&Number=3D64652
This is the JDELIST Applications Mailing List. To stop receiving these=20
messages, login to http://www.jdelist.com/forums, click Control Panel, the=
n click Edit by "Subscribe / Unsubscribe from=20
receiving board posts by email, change message notifications, etc." and=20
adjust your subscription preferences. JDEList is not affiliated with=20
JDEdwards=AE
cyberscout
Active Member
This was one of the biggest issue we had with OneWorld. Our consultant didn't know any possibilities so I started to test the whole program to find a solution.
We had different problems:
1. Sometimes, as described in Brenda's post, theres a difference of 0.01 between the tax amount on the invoice and the calculation of the program. A warning is for us absolutely useless because the user just press again ok and for them the problem is solved.
2. We have some supplier in Switzerland which send goods to us in Switzerland (with tax) and to a branch in Germany (without tax). So the invoice is sometimes without tax, but the purchase orders are always with tax. If you try to match the purchase order with tax with the invouce without tax there will no error appear. Just the batch isn't balanced and you need SQL again.
Our solution for that problem:
1. I made 2 fields in the P4314. In the first field is the tax displayed which the invoice has been booked. In the second field is the tax amount from the chosen purchase orders. That's the total of all lines on this form. The user can easy see if there's a difference or not.
2. In the event rules of the ok-Button you can made an if-rule which looks if these fields have the same value and if they haven't there will displayed an error (not just a warning).
3. If in the tax is a difference of 0.01 but there is no remaining amount you can take one of the lines to match in the grid and change the value in the amount field +.01 or -.01 (just try). Then if this isn't more than .02 or less than -.02 this amount will completly put on the tax, so you have the tax changed, but not the amount taxable and the remaining amount is still 0.
With this arrangements we have only a few batches they aren't balanced. And I don't need to use SQL for a half day in a week as it was in the first some months we used JDE.
I hope I could help you and please excuse my bad english.
cyberscout
We had different problems:
1. Sometimes, as described in Brenda's post, theres a difference of 0.01 between the tax amount on the invoice and the calculation of the program. A warning is for us absolutely useless because the user just press again ok and for them the problem is solved.
2. We have some supplier in Switzerland which send goods to us in Switzerland (with tax) and to a branch in Germany (without tax). So the invoice is sometimes without tax, but the purchase orders are always with tax. If you try to match the purchase order with tax with the invouce without tax there will no error appear. Just the batch isn't balanced and you need SQL again.
Our solution for that problem:
1. I made 2 fields in the P4314. In the first field is the tax displayed which the invoice has been booked. In the second field is the tax amount from the chosen purchase orders. That's the total of all lines on this form. The user can easy see if there's a difference or not.
2. In the event rules of the ok-Button you can made an if-rule which looks if these fields have the same value and if they haven't there will displayed an error (not just a warning).
3. If in the tax is a difference of 0.01 but there is no remaining amount you can take one of the lines to match in the grid and change the value in the amount field +.01 or -.01 (just try). Then if this isn't more than .02 or less than -.02 this amount will completly put on the tax, so you have the tax changed, but not the amount taxable and the remaining amount is still 0.
With this arrangements we have only a few batches they aren't balanced. And I don't need to use SQL for a half day in a week as it was in the first some months we used JDE.
I hope I could help you and please excuse my bad english.
cyberscout
