Operating Units

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.

No Operating units for Party Tax Profiles

The ledgers and OUs are all set up, You have set the MO Security profiles for the tax manager, added the ledger set, done everything possible but for some reason, you cannot select an OU for the tax managers–>party tax profile.

Try this,

1. Receivables -> Set up -> System -> Organizations.
2. Query the OU used.
3. Check the location tab and the address.
4. See if country and address are populated correctly.

I have blanked out the client info but hopefully you will get the idea

Oracle 11i to R12 – Upgrade or Re-implement?

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.

Oracle eBTax and Operating units

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


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

The importance of setting up your eBTax solution correctly first time

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.