Oracle R12 eBTax ‘Query has exceeded 200 rows. Potentially more rows exists, please restrict your query’

What should you do if you receive this error message whilst trying to update look  up codes?

‘Query has exceeded 200 rows. Potentially more rows exists, please restrict your query’


To resolve this you need to update the profile value of

FND: View Object Max Fetch Size to equal 2000

Why eBiz answers succeed where the big four don’t

The primary reason why eBiz Answers succeeds where others don’t is because we know both VAT and Oracle so we bring the solution with us.
Our lead consultants have 20 years’ experience on global solutions implementing and supporting Oracle ERP projects and all have a financials background that provides the ability to really get into your business to best identify the source information that will ultimately determine your tax. Because we bring the solution with us, rather than wasting your time and money documenting the existing process flows and then trying to manually build your solution from scratch we provide a the solution then we work on the gaps if there are any. Just as any other third party tax solution on the market, we know that tax is tax, the same rules apply to everyone and so we have pre-built these rules.

We have a repository of country tax regimes with all the rates and rules that are needed to meet the majority of your needs but unlike any third party product, all our set up is in Oracle, all standard functionality all within your existing Oracle licence. Our in-house developed ‘eBTax Rapid Install™‘ tool means that we can have you setup, with a fully automated tax solution within minutes that would usually take weeks to manually do. We use this same tool to then migrate the tax solution from instance to instance saving time and ensuring 100% accuracy. We know the Oracle tax engine inside out and more importantly, we know what it can’t do so if we have not already got a work around to missing oracle functionality, we will know the best way to get one.


Oracle eBTax Exempt, Zero or Out of scope – does it make a difference

Unfortunately there is a big difference between ZERO and EXEMPT. If we were to sell everything as EXEMPT then we would not be able to recover any tax at all, if we sold everything as ZERO then we can recover 100% of the tax. Because banks sell many things as either EXEMPT or out of Scope (Exempt, Out of Scope and Zero are 3 very different rates) they can only recover a certain amount of tax, the amount could be as low as just 1%. Luckily in AP, if we accidentally put something as Zero when it should be EXEMPT then it does not matter so much.


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

Oracle eBtax for Dummies

I have had a couple of requests for a guide on ebtax to make the setup simple but unfortunately this is not possible. Why? well because it depends so much on what you are trying to do. The tax solution for the US as apposed to the UK is completely different as chalk and cheese and then between the UK and FR again brings many nuances that there is no simple solution or user guide.

At eBiz answers we have developed a best practise solution that we have enhanced over the 7 years we have been doing ebtax and whilst our solution is proven to work and that we can roll it out over and over again to all our clients, its not just the set up that will make your solution work because part of our solution is also linked to the localisations, reporting and integration. So its not a case of being able to get a quick reference guide to shove in a solution but rather a good understanding of the ebtax options available to you and the fiscal requirements that are governing the legal implications behind the tax.

But check the other blogs and hopefully you will get enought information to put your ebtax solutoin together.

Using the Legal Entity to drive your tax?

This is the situation,
One Operating Unit with 2 Legal Entities assigned to it. One Legal entity is in France, the Other is in Spain.

The Operating Unit has the location of France linked to it so when we enter an AP invoice, we use the ‘Bill to’ as the place of supply but this only points to France. If we change the ‘Customer Taxpayer ID’ to be the Spanish Legal Entity then this does nothing to change the ‘Bill-To’ value. So, ignoring the fact we could use the Ship-To, is there any way of using the Legal Entity to drive the place of supply for the Oracle eBTax engine?

How can the ‘Customer Taxpayer ID’ be made to be useful for the Oracle eBTax Engine?

The answer is that for the Party Tax Profile for the Operating Unit, you need to select the ‘Use Subscription of the Legal Entity’


By doing this, the ‘Bill-To’ is now the address of the Legal Entity and not that of the Operating unit Location.

Mid-Month Go-live – good idea?

What are the tax implications of doing a mid-month go live?

From a Oracle ebusiness tax point of view, you could be heading for a lot of complications for that first months reporting. It’s rare that you won’t have any issues with the migrated data and if done correctly, the migrated data will retain the legacy tax codes but any newly entered transactions will use the new tax rates. So how will this look when you try and run the VAT reports for that month as you are pulling data from different transactions and the old legacy rates are unlikely to be linked to the correct reporting codes that are needed for a lot of the tax reporting. I would always suggest that it is better to run the old VAT reports in the old system and then the new reports in the new system and this way, all the open migrated transactions should have already been processed for the monthly VAT returns leaving the new month and the new eBTax solution to handle the new transactions and the next VAT return. But this won’t be possible with a mid-month solution – or is it? please discuss.

Offset Taxes on AR transactions?

A colleague of mine recently called me to ask how to setup offset taxes for receivables. I had never come across the requirement before so I was interested to find out why the request came about and it turned out that they only needed it for reporting purposes. So it would be interesting to find out if anyone else has had a similar requirement and if so why? And what other solutions are available for using taxes for reporting only in AR. There is a ‘reporting only’ tax option that can be setup when creating a Tax but this is used for AP purposes only.

Oracle ebtax, can we use a currency amount as a determing factor?

I am coming across a situation where a certain type of tax is only applciable if the order amount is over €5000 but how can this be done in oracle ebusiness tax?