Oracle R12 e-Business Tax – Russian VAT
Oracle eBusiness Tax: Russia VAT considerations
Setting up Oracle in Russia is not easy and it helps to get a resource who speaks the language and understands the localizations needed to successfully implement Oracle.
Oracle eBTax for Russia is different in terms of its complexity but not because of the nature of Russian VAT but because the configuration of the solution is restricted completely by the reporting requirements, primarily with the Russian book of purchase and the book of sales. These reports are so rigid in their design that in order for them to work, the Russian VAT setup has to be done in such a way that as if walking through a mine field, one step out of line and things are not going to work. If you don’t know the Russian book of purchase or the Russian book of sales and are attempting to setup Russian VAT in Oracle for the first time then you are going to get very confused and frustrated very quickly.
I pride myself on putting an indirect tax solution together that not only meets the clients existing requirements but also those in the future and as such when I design a solution I follow a best practice that I have developed over the last 7 years. This means I can pretty much follow the same naming convention and structure of every VAT/GST based tax for every regime I setup. But with Russian VAT this is not possible. I have to setup the solution in a particular way so that the reports will work! From what I can see, it looks like the localised reports were built over an appalling Russian VAT solution and as such, anyone who wants to get the seeded localized reports working have to also follow this appalling design. In fact, from what I can work out, the R12 Russian reports for tax were created based on an upgraded 11i to R12 solution. Those that are used to R12 eBTax will know that an upgraded solution creates multiple ‘Taxes’ often with one ‘STANDARD’ Status and then multiple rates – very much in line with a US Sales and USE tax solution but not for a VAT setup. Well, this appears to be the case with the Russian requirements because tax reporting codes that could otherwise be linked to a rate are instead linked to a Tax! This means that a minimum of 3 taxes are needed just to assign the book of purchase tax reporting codes. Further to this, it appears that the EXEMPT tax rate code is also hard coded into the reports meaning and to make it worse, it is used by both AP and AR transactions so the only solution to get this working is to have a separate tax, status and rate just for an EXEMPT tax rate!
Its a case of lazy developers hard coding the reports based on an upgraded 11i solution thus forcing all other RU VAT setups to follow the same route and in the process reducing the functionality available for eBTax.