Error:Amount does not balance to gross - P4314 - after changing tax rate

[Cathy Wilbur]

As of July 1, 2006 one of our taxes went from 7% to 6%. Peoplesoft said all we had to do was take our old taxes and end them as of June 30, 2006 then key in a new tax that would take effect as of July 1, 2006. Before tax used to look at GL date but we also had to change the processing options to look at Invoice date (was also a requirement to pick up the proper tax rate as per Peoplesoft and government tax regulations).

The problem is that in the PO Match program P4314, the Service Tax Date match on the PO behind the scenes is still going to G/L date instead of invoice date so we are getting an amount does not balance to gross error in P4314.

Has anyone else had this problem and if so how did you go about fixing it. We cannot match any PO's whatsoever. Peoplesoft asked us to apply ESU JE9789 to pick up SAR 7677575 but when I look at this ESU on their web site there are well over 200+ SAR's in there. This ESU was just put out there June 13, 2006. It has a note NOT TO APPLY THE ESU because the status is on hold. We applied ESU JE9731 to see if this would correct the problem and we still have the error occuring.

Is anyone in the same predicament? We have no idea how to fix this. If anyone could help us it would be greatly appreated.

 

[Cathy Wilbur]

Has anyone applied ESU's to help fix amnt not balancing to gross error I am encountering in P4314. Our problem seems to reside with objects XT4314ZN, or X00TAX, or B0900049.

"Strangely, the logs do not show the error we see displayed interactively, the 0088 Amount Does Not Balance to Gross error. The logs do show two business functions endi in error, B0900049 (F0911FSEditLine) and XT4341ZN (F4314EditDoc).

ESU Recommendations
=======================
So far I have installed ESU JE9731 but this did not resolve the problem.

Another company told us that it was recommended that they install JE5203 (system 04), JE9028 (system 44), JE9768 (system 42) now superceeded by JE9841, JE9772 (system 43B) now superceeded by JE9824.

Only JE5203 and JE9824 apply to us (have not applied either of these yet).

Peoplesoft is now asking us to apply JE9561 which I am doing now. Has anyone had this problem in A/P and had to install some ESU's to fix the problem. Please advise.

Peoplesoft said we should also apply JE9824 to fix problem.

What ESU's did people apply to help with the change in tax rates.

 

[Cathy Wilbur]

We have now applied the following ESU's and it still has not fixed our problem ESU JE9731, JE9561, JE9824, JE5510, JE9841. After applying all of these ESU's the problem still persists. Oracle/Peoplesoft now wants us to apply ESU JE9860 to pick up SAR 8176861.

The Processing option for P0400047 has Service/Tax date set to "1" which means use invoice date. So what am I missing?

When we use P4314 to match an order for those orders where we want to use the old tax rate we change the invoice date to sometime in June then we match the order but we leave the GL Date with the current date which is currently a July date. For some reason the calculations in the code are not calculating the tax properly. We ended the old tax effective June 30 and took a copy of the old tax and made it start effective July 1st with the new tax rate. Both the old tax and the new tax entry defined have the exact same name.

We have had this problem for 4 weeks now. Can anyone shed any light at all on this problem?

If we match an order with an Invoice date of July then everything is fine. If picks up the new tax rate.

If we match an order with an Invoice date of June but the GL date is July then an error pops up "Amount does not balance to gross". When we look at the tax calculated and the gross amount on the screen everything calculates successfully. The online popup msg gives the error in B0900049.c in line 2615 and lists the data item in error as AG-Amount-Gross

Has anyone come across this problem and how did you fix it?

 

[pfd]

Do you have any tolerance rules setup for Voucher match or in your tax rules that could be causing this?


Thanks,

Matt

 

[Cathy Wilbur]

We looked at tolerance and that was not causing the problem (we tried working with tolerance off and on and it did not make any difference).

This problem was just resoved late yesturday so we spent the day testing it and checking the database updates this morning. After a webex with Oracle and working with the accounting group and the purchasing group Oracle was able to recreate the problem.

As it turns out in P4314, in Processing Options, under the retainage folder, we had both options 1 and 2 set to "1". As it turns out the calculation of the retainage and taxes is what was causing the problem. There is a bug in that when the second option is set to "1" it tries to calculate tax on retainage and it is not calculating the old tax rate properly if we change our invoice date to before July 1.

Oracle asked us if we use their retainage and we said no we key in our own retainage lines. So they told use to turn this retainage off (set both processing options to blank).

Oracle put a SAR in on our behalf and the SAR # is 8187009. This explains exactly what was happening. It also explains work-arounds for those of us that do use the retainage function.

Since we spent many weeks trying to resolve this problem with Oracle I did not want anyone else to have to go thru this since we came across a resolution.

I hope this helps. Thanks for all the input. Refer to the SAR 8187009 for details.

 

[SheilaV]

With respect to P4314 amount open not equal to gross amount, we had a similar issue with foreign currency Voucher Match transactions when the Tax Explanation Code changed from C to E when there was two or more pay items in the document. This was also occurring on foreign F0411 transactions as well. We applied the code from SAR8027937 and it repaired the problem.