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.

It will be sold as the easy, fast and cheapest way to go from Oracle 11i to R12 but is upgrading the right choice?

Unless my client has an extremely well refined 11i ERP solution working without fault with almost no customisation nor any country localisations, I would always say that a re-implementation is the right way forward. Time and time again, when working on upgrade projects, things are always a lot harder than if the project was being implementeded. I liken an 11i to R12 project to a house renovation. Consider 11i to be your house now and R12 to be the super environmentally friendly completely modern house of the future. If you have a very basic house that has been well constructed and has a great layout then making the renovation is straight forward, however, if that house is old, of a poor design and construction that needs all the pipe work and wiring replaced, making it extremely hard to get the underfloor heating in that you wanted, surely it would be better to knock it down and start again? Of course this is where my comparisons end because the costs of knocking down a house are usually the biggest factor as are the costs of any IT project, the 11i to R12 upgrade being one of them. But will the cost be any greater by doing a reimplementation instead of an upgrade? In the long run, with the delays to the project or the late surge in additional resources to fix the issues, update the customisations and ensure that the localisations are working to meet local fiscal policy, the upgrade becomes as costly, if not a higher cost than a clean re-implementation!

I will be putting together a document with all the pitfalls of doing an upgrade over an implementation based on mine and other colleagues experiences. But pleae feel free to comment with issues that you may have faced that support either option.

With the introduction of Oracle R12 and the greater emphasis on shared service centres, can you afford not to use multiple Operating units?

Intro

The challenged faced by any company implementing a new ERP solution, whether a single entity or a global conglomerate, is to capture the complex business requirements and yet keep the structure as simple as possible. Creating a highly complex organisation structure is likely to lead to greater data processing needs as well as a more labour intensive maintenance requirements. There is also a risk that the solution initially designed to help the company, ultimately leads to issues that end up consuming more resource.

Any solution architect will be considering this when they design the organisation structure deciding the best approach for the number of ledgers, what legal entities will use these ledgers and how many operating units will be needed to capture the data from the sub ledgers such as the Payables or Receivable modules. Continue Reading

If you don’t use the correct solution right first time then you are going to create a lot of issues later on.

A recent client of mine had a heavily customised eBTax solution which was heavily intertwined with the rest of the ERP setup. The problem is that the original tax solution was poorly designed in the first place and where eBTax functionality existed to handle most of the client’s requirements, it was not used and so customisations were used instead to drive the tax. Now we are faced with the task of correcting the eBTax solution to a fully automated one but we have to take the approach like peeling back the layers of an onion as we don’t know how deep the customisations go and whether removing the customisation effects other functionality.

Due to the complex nature of the clients business processes there was always going to be a requirement to customise the tax solution but the customisations should have been about customising the data used by the tax engine and not customising the tax engine itself.

Had the client set up the correct tax solution platform in the first place, then the customisations would have been minimised and the extent the customisations affected other modules would be almost non-existent.

So, make sure the ‘base’ tax solution follows best practice and then build around this, rather than putting in a partial tax solution and customising it to fit around the business processes.

The reason why I say this is that the majority of financial institutions use their own bespoke solutions to manage the trades taking place, and this is usually only recorded in Oracle as a GL entry. Is it even possible expect that Oracle could handle the huge volumes that are generated by the trades?

Having worked at some of the biggest financial institutions, I am fully aware of the ’empire’ building that takes place by certain individuals so that their own billing solutions will never be replaced, but these banks and brokerage firms should start consolidating their back end systems, so that instead of having 14 separate systems all generating invoices to their clients, they should feed the transactional data into Oracle and then have just one system creating the invoices. Not only will this reduce the maintenance and time taken for month closing but will open up the way to allow Oracle to be used for the tax calculation including both VAT and the new Financial Transactions Tax.

What is the best way to drive your taxes from an AGIS transaction?

One of the primary drivers for the AGIS (Advanced Global Intercompany Solution) module was to ensure that the correct tax was calculated for transactions that were created by journals. The problem, from an eBTax point of view, is that the useable tax information is restricted by an AGIS generated transaction that originates from GL.Take for example the requirement under EU law to separate out the sale of Goods and Service for intra-EU trades. The only way to do this in Oracle, for the Oracle eBusiness (eBTax) tax engine, is to first create a dummy tax rate called ‘SERVICE ITEM’, and then assign this rate to the tax classification code field on an AR memo line. In turn, this memo line is linked to the AGIS Transaction Type. Rules are then used to drive the correct tax, i.e. if the transaction is between two EU entities and the SERVICE ITEM is used then ‘Intra EU Sales Services’ will be calculated rather than the ‘Intra EU Sales Goods’.

When the AGIS AP invoice is created, you need to pull the same Tax Classification Code through, i.e. ‘SERVICE ITEM’ so that the correct AP ‘Intra EU AP Sales Services’ is calculated.

But how else can AGIS be used for tax calculations? is there an enhancement to allow not only a memo line to be added to an AR transaction type, but also to allow additional information for tax purposes such as ‘Intended Use’ or the ‘Fiscal Classification’ that can be used by AP and AR?

How can Oracle Fusion be improved to better enhance the visibility of Tax Rates calculated and whether it is a service, asset or inclusive without the need for additional rates?

Like any ERP solution, a good eTax consultant will design the way the eTax module is setup based on how the tax needs to be reported, often resulting in additional tax rates being required in order for these rates to be clearly visible. The design of the Tax engine with Oracle Fusion is looking at improving the way tax can be reported and thus reduce the number of rates needed. For example, in Europe, it is important to be able to report the sale of goods, services and also triangulation separately. Oracle offers ‘Tax Reporting Codes’ to do this with one ‘Intra EU Rate’ but when the tax is calculated, it is extremely difficult for a user to see what type of ‘Intra EU rate’ has been calculated until it has been reported – often too late.

It is too late to change R12 to accommodate changes to make the reporting easier but what can be done to Oracle Fusion to enrich the tax reporting so that at the point the tax is calculated, the user knows what tax rate is being used, whether it is a service or inclusive or an asset or even a ‘Self Assessed’ tax immediately.

One potential way is to have a Flexfield type structure that can be driven by the tax rules so that a single tax such as ‘Intra EU Rate’ can have the values of ‘Service’ or Triangulation’ attached to it. It needs to be clearly visible when the tax is calculated and it needs to be picked up on reports. Additional segments would indicate if it is inclusive, the recovery % or whether it is an asset.

In Belgium, a client recently requested that a rate be created to accommodate the fact that the tax was both an asset and a service. It would have been better to have been able to have had one rate with attached flags rather than several rates to capture all the possible combinations.

AP Triangulation Tax. this is the scenario: Your organization in Finland is selling goods directly to an end customer in Estonia but the goods are being shipped directly from your organization in Ireland to Estonia. The organization in Finland will raise a zero rated invoice which the end customer in Estonia will reverse charge. Your organization in Ireland will raise a zero rated intercompany invoice to your organization in Finland. In AP the organization in Finland does not need to reverse charge the I/C invoice from Ireland as the goods were not supplied to Finland so there is not an equivalence requirement. The verification of the correct tax rate needs to be identified but this would mean a requirement to capture the ship to country as a country – not a stored location. We cannot use a ship to location because the Supplier may have drop shipped directly to our Customer so we would not even have that location setup nor available to us. Having a field where we can populate just a country value would be a massive benefit to the ebtax solution in both AP and AR particularly for EU VAT.

Issue when setting up tax zones:

Once you have set up a tax zone, run the following SQL query – select * from hz_geographies g where g.GEOGRAPHY_USE = ‘TAX’ You will see that the end date is defaulted to 31-DEC-2012 even if you had set no value! On testing it does not appear to have a negative effect on creating tax conditions but its something to be aware of.

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.