Archive for July, 2013

Oracle R12 Setting up Tax Calendars for eBTax

Setting up Tax Calendars

For VAT reporting, the calendar that is required for your reproting is often going to be different than the corporate calendar being used in GL. This setup will show how you can add addtional calendars for VAT reporting.

First, check to see if the calendar type exists and if it does not create it yourself.

Navigation: General Ledger>Setup>Financials>Calendar>Type


Once Created, you now need to create your calendars.

Navigation: General Ledger>Setup>Financials>Calendar>Accounting

oracle ebtax


Oracle R12 eBtax EMEA VAT SETUP Menu configuration

Adding the EMEA VAT SETUP to the Tax Managers Menu

Oracle R12 Tax

This setup is needed to be able to set up tax reporting correctly for your EU VAT, however, due to the number of reports available, you can also setup non-EU entities and be able to use the reports for these countries too.
Navigation: Sysadmin>Applications>Menu
Then search for the Menu belonging to the ‘Tax Managers’ Responsibility – this is the seeded responsibility so check to see if your company is using their own version.

Oracle R12 eBTax
Save your work.
Your Navigation should now show this in the menu for Tax Managers

Oracle R12 – Using percentage in the tax rate


My second question ( more a point to note)  was related to a point you made in the UKOUG Financials SIG in Manchester.
I think  you mentioned that it is better to put the tax rate value in the Name of the Status Code. That is define the Tax Status code as ‘Standard 20’, instead of ’Standard’.
Our experience was quite the opposite. We had defined Tax Statuses with the rate in the name initially. That is we had defined ‘Standard 15’, Standard 17.5’etc. When the VAT Rate changed from 17.5% to 20%, We had quite a cumbersome task to create a new Tax Status and change all the Tax rules to now use the new Tax Status ‘Standard’.  If the VAT Rate changes now again ( to say 22.5%, looking at the way UK Debt is not getting tamed), we will just have to end date the existing Tax Rate under the ‘Standard’ Tax code and enter a new row, with the new rate.  No changes to Tax rules required. It seems a far neater way to do it.

Continue Reading

Can we not use SLA rules to derive / modify the accounting for E-Biz Tax accounting?


Can we not use SLA rules to derive / modify the accounting for E-Biz Tax accounting? “Sometime back we were trying to setup a new company in under an existing Operating Unit. This meant that we had more than one Balancing segment value ( which we have labelled Business Unit) in the same Operating Unit. In AR we created new Transaction Types to be used for the new Business Unit ( Company).  The Business Unit value for Revenue and Tax accounting had to change based on the Transaction type. We tried using SLA to derive the Tax accounting based on the Transaction Type on the AR Invoice but found that we could not build SLA rules for Tax accounting. That to me seemed restrictive and odd. We eventually found that we can modify the Auto Accounting configuration for Taxes and sourced the Business Unit value from Transaction Type even when Ebiz tax is used and used that.  However I was very surprised I could not do the same with SLA , which seems like the right place to do this.” 


You can use SLA but the tax accounts are only changed during the posting to the GL so the user will not really know if the correct account has been used during import. I have not tried it but the autoaccounting rules for the balancing segment should work.

The other approach is to set the tax logic up to use the Legal entity for the tax, rather than the OU. This means in your case you would have had 2 legal entities under the one OU and you need to set the ‘inherit from legal entity’ to yes for the party classifications for the OU. you can then create a tax rate and link it to the configuration owner – that being the LE instead of making the tax rate global.

I would always push for a separate OU for each new legal entity set up as with MOAC, there is too many benefits for having the separate OUS and in this case you just set the taxes up as globally owned rather than LE owned. Also – you need to set the tax rates up using the tax configuration–> tax rates rather than doing them with the regime to rate function otherwise you cannot set them to a different LE. Another downside to this is that you need to create the tax rates for every LE and rules also.

In AP – you can change the LE used by changing the value in the ‘Customer Taxpayer ID’ field.

So it is possible but messy.