Oracle R12 eBTax – EMEA VAT SELECTION PROCESS Finally faster!

This blog should affect every single entity using Oracle in the EU but as we usually find, the majority of tax configuration for Oracle R12 has been badly done by the various integration partners and the EU reporting functionality completely missed and nowhere to be seen! Oracle have provided an excellent solution with the European Tax Reporting Ledger but it is often completely missed. But for those of you who have set your solution up correctly, you will often be frustrated by how long the EMEA VAT: Selection Process takes to run and for some large companies we have done work for, the times can be more than 24 hours! Something completely unacceptable for busy tax departments.

But fear not, Oracle now have a fix.


The bug summary:

Performance Issues in EMEA VAT Selection Process  

Added a new optional parameter to EMEA VAT Selection Process called 'Minimum Tax Reporting Date' to resolve the performance issues 

The re parameter looks like this:

EMEA VAT Selection Process

Most companies will use the ‘GL date’ to report their tax with but some eastern EU countries require the ‘Tax date’ and we normally encourage the use of the ‘Transaction date’. So the term ‘Minimal Tax Reporting Date’ is badly defined because according the bug details; “Abstract: GL DATE LOW PARAMETER REQUIRED TO AVOID PERFORMANCE ISSUE” which would indicate that it should be the ‘Minimum GL Tax Reporting Date’!

Further information as to why they needed to put this patch in place is What happens is that the package ZX_AR_EXTRACT_PKG needs only the latest information from the table RA_CUST_TRX_LINE_GL_DIST_ALL.  This table can be very large for Oracle customers who are using EBS for a long time.  So, if the query that is dynamically built in the lines 3100 etc. of that package must consider the complete table, it may take a very long time.  The parameter “minimum tax reporting date” of the EMEA VAT Selection process should take care of this performance issue, if it is communicated from the main package JG_ZZ_VAT_SELECTION_PKG to JG_ZZ_AR_EXTRACT_PKG. 

This communication should be unconditional. There are, indeed, many cases in which the EBS users may want to neglect previous transactions, which are not “known” by the EBS program (based upon 15 years of experience) 1. It happens
often that tax reporting an EBS customer only starts using the EMA VAT Reporting unitility from a particular point in time, sometimes many years after the first use of EBS; 2. Sometimes, EBS users may decide to use another (bespoke)program outside EBS to declare its monthly VAT for some periods (e.g. since the EMEA vat reporting  utility does not cover the complete
Belgian legislation); 3. Many EBS users do not use the final reporting concurrent request at all.  If this parameter is used in an unconditional way, as I propose here, this may result in a situation in which some transactions are never declared for VAT; the EBS users will be responsible for using the parameter in such a way that this never happens; they should have closing procedures that include all modules as well as the VAT declaration.  The default value of the parameter should be the lowest possible date, to prevent EBS users to inadvertently run into such a situation.  In fact, we have two types of EBS users: (1) novices, with a relatively small number of rows in RA_CUST_TRX_LINE_GL_DIST_ALL, who can use the parameter with the default value, and (2) experienced EBS users, who will take advantage of the paramater to optimize performance, but will be conscient about the consequences (and have a proper closing procedure in place).

In reality, it is a rare case when a GL period is re-opened and transactions changed, particularly those that may affect the indirect tax. So this is a welcome fix and when it comes to putting in the ‘Minimum Tax Reporting Date’, to be on the safe side, put the GL date of the first of the previous month or the first of the year, depending on how much data you have.