Tax Rate Changes and crediting at old tax rate

sean_gilbert

Well Known Member
Our federal tax rate is being reduced from 7% to 6%

We have set the tax rate area "GST" at 7% to expire on June 30, 2006 and setup a new "GST" tax rate area record at 6% with an effective date of July 1st 2006.

This works fine for sales orders but the problem is how to handle returns for products purchased prior to the rate change.
(ex. a customer purchased goods in June and we charged them 7% GST on the invoice now in July they return those goods and expect a full refund including the 7% tax not the new 6% tax)

The invoice print R42565 and sales update for my credit order uses the current effective tax rate which is 6%.

The only option I have identified is to create a new tax rate area GSTC - GST Credit. effective july 1st at 7%. Then for any credit orders that need to be credited at the old 7% tax rate users will manually override the credit order tax rate area.

Can anyone think of anything better than this manual solution?
Thanks Sean
 
Hi Sean,

The easiest way to solve this is creating new tax area ex. OGST (for Old GST). Then when creating a credit order, override the tax area to OGST if the credit is for items purchase before July 1.

I have tested it and it works fine.

Hope this helps.
 
Yes this is what I have been telling my clients to do. I was just hoping to find something a little more automated for them.
 
Unless someone else has an another option, this is the only way I found.
 
We have had the same challenge, and we are doing the same thing as suggested by Sean.

"The only option I have identified is to create a new tax rate area GSTC - GST Credit. effective july 1st at 7%. Then for any credit orders that need to be credited at the old 7% tax rate users will manually override the credit order tax rate area."

So far so good, but if anyone has other suggestions they are welcome!
 
Hi guys,

I have another question related to the GST change. We are having problem if the Order date is less than July 1 by ship after July 1, the wrong tax rate -- it seems to be using the order date instead of ship date to recalulate the Taxes.

Is there a processing option or system setting or do we have to go change the order dates on the Outstanding orders.

Thanks
 
Are you running an old version of E1. By old I mean XE or earlier? In my tests on 8.9 and 8.12 the invoice calculates the taxes based on the invoice date. However one client (on B7332) did say that their invoices also seemed to use order date for the tax effective date. I haven't been able test this myself nor find any old SARs stating that JDE was changing the way tax deffective dates were determined. So just double check that the invoice for your release is using the Order Date.

My suggestion again would be creating new codes:

1)Starting now for new orders the "GST" code at 7% should be expired June 30th and "GST" code at 6% should be efective July 1st.

2)For those orders dated prior to July 1st. Create a new tax rate/area (ie GSTO - GST Old Orders)at 6% make it effective from your earliest order date and expire on June 30th. The run a SQL update to change the tax rate/area on all those old orders.

3)And of course your other GSTC - Credit old rate for entering and manually overriding the rate/area on credits that need to be refunded at the old rate of 7%
 
Thanks Sean,

Yes, one site is on B733.2 and the other is on XE.

That is why I could not finding it because the other site is 8.10.

Thanks
 
If the service/tax date option (MB P03B0011) is setup to look at invoice date, set the invoice date of the return to be the date of the original invoice and the old rate should apply. The GL date for the invoice would be in the current month and with the old rate.
 
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.

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

I also posted this as a new thread because my problem is slightly different but I thought I would post it here as well.
 
We switched the Processing Option 'Service/Tax Date' on the Voucher MBF P0400047 to 1 (use invoice date) and the service tax date for P4313 was based off of the Invoice Date on the voucher. Was your change in setup different?
 
We already changed processing options on P0400047 to use invoice date. What other propram should we be specifying a service tax date of invoice date? Do you mean in the P4314 CURRENCY tab?

Do you not mean P4314 instead of P4313. Where do I set P4314 service tax date to be based on the invoice date in the processing options? I do not see that anywhere. Please advise.

Cathy Wilbur
[email protected]
OW B7334 ERP 8 SP22 Updt 1 Unix RS6000 Oracle 9 Create!Form
 
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.
 
In the Processing Options for P4314, you need to specify the version of P0400047 to use on the Versions tab. The Processing Options for that version of P0400047 is where you specify the Service/Tax Date.
 
We did exactly what you said.

In P4314 we specify the version we want to use for P0400047 and in that version of P0400047 we specify that we want to use invoice date.

We also took our old tax of 7% and copied it to a new tax. We then put an expiry date on the 7% tax of 2006/06/30. We took the new created tax and changed the rate to 6% that started effective 2006/07/01.

When AP period moved to July and G/L period was still in June we were fine. As soon as the G/L period moved to July we started getting errors in the tax calculation. It is almost like the system is still using the Service tax date of GL date instead of Invoice date.

All the AP supervisor did was change the processing options on "PD" on the full client. Any ideas....

I think that somehow the system is not picking up her processing option change even though when I go into that version of P0400047 I see the change. To be safe the AP supervisor went into every version of P0400047 in "PD" and changed the Service Tax Date processing option to "1" for Invoice date.

Do we have a problem in that the processing option is not the same as the program on the server???

We had a problem a while back in another program R43500 when we changed the processing options the server still had the old processing options. Should I just submit the specs to the server?

I did not think we had to submit specs to the server for an interactive version. Once you changed the processing options then the full client and the web client should get the new processing options since it is an interactive program. Is that right or wrong?
 
Back
Top