Enhancement Requests

Oracle eBTax, removing the need for a separate tax rate to allow for inclusive tax


I had a discussion with a senior Oracle developer at openworld where they saying about changing the way the tax logic worked for the inclusive tax so that rather than having to create a separate tax rate that is set as inclusive, you would just use a tick box on the invoice. His reasoning was that the tax rate should not need to be duplicated just to be able to change the ‘standing’ of the rate. You really cannot have it as a manual tick box in the tax details as this would slow down users especially when rules are often needed to drive whether the tax is inclusive or not. However, I think from the design of the tax solution, I think removing the need to set the tax rate as inclusive or not is an excellent step forward but I think you need to go further.

Continue Reading

Will we ever have DFFs as Tax Determining Factors?

We all know the limitations with the tax module, primarily with the limitations that the determining factors give us. Many of us who have worked with eBTax for a while have asked for the ability to have DFFs as determing factors.

But, will we ever have DFFs as Tax Determining Factors?

The answer is probably not. Having spoken with Oracle Product development at this years Oracle Open World, the key issue is that a DFF that maybe linked to a Purchase order line is not going to be available in the AP workbench meaning that the tax engine wont have the same info in AP that it had in PO!

Its a fair comment and I understand the limitations.

 So… Whats the alternative?

At present I am not at liberty to say but Oracle development do have a unique concept that would allow a very similar approach that would get over the issue of DFFs not being available to all modules. So, watch this space for further updates.

Oracle eBTax – How to populate the Tax Date automatically

For some reports for European VAT, the Tax Date of a transaction needs to be populated. This is an unreasonable task to expect users to do as it can only be done manually meaning that for every order that is imported, the transaction would need to be uncompleted and the tax date would have to be manually updated!

Oracle offer a patch for the supported countries to populate the tax date from Orders but this does not work if you do not have the localisations turned on which could be the case if you are a German entity who has a site in Hungary and charges Hungarian VAT when they ship from there. The Operating unit is German and the localisation country would be Germany but the tax in this instance is Hungarian! Another reason why this does not always work is that for any manual transactions, these would also need to be manually updated.

So, how can we automate this?

Very simply!

Create a request that does the following “update jg_zz_vat_trx_details set tax_invoice_date = trx_date where tax_invoice_date is null“. Then create a request set which first has the EMEA VAT SELECTION PROCESS and then your request to update the tax date.

Now there is no need to populate any of the tax dates as these will automatically take the transaction date if the tax date is NULL but is the user does put in a tax date manually, then this will be chosen instead.