Oracle R12 eBTax – French Deferred (tax encaissement / au debit)


Question

 Hi Andrew
with the move from R11 to R12 it was decided not to retain the double tax rate code deferred / non-deferred ( encaissement / au debit ) anymore reasoning being that it’s a supplier based trigger and therefore filing should depend on supplier  and not tax rate code
so tax rate code   FRNBU is being used for instance for FR Regime , Standard Vat , Business Related transaction and when the FR Regime is filed , non-deferred suppliers transactions are included triggered upon booking and deferred supplier transaction triggered upon payment  
it now happens that the accountants of the FR company came up with the request to have the accounting of the deferred ones different from the non-deferred one, which was inherent  in R11 but not in R12. 
solution is an SLA rule to change tax line accounting ( the account segment ) based upon the deferred / non-deferred identifier which happens to be the registration_reason_code in the zx_registrations record.
Rgds 

Response

Hi,
I would be pushing back to the business to insist that we have a separate rate for the deferred amounts.
If you have done a technical upgrade from 11 to 12 then you really want to rip out the 11i solution and start again. You should only have
FR VAT and FR OFF as your 2 functioning taxes then you will have to manage just one set of rules under FR VAT.
For those suppliers that are deferred, create a simple party classification code that drives the deferred rate. So you can have the normal rules that determine the status, i.e. FR VAT STANDARD or FR VAT REDUCED LOW then a separate rate rule for each of those taxes that drives the deferred rate (FR VAT STANDARD (DEFERRED) based on the supplier using it. I never default taxes from the supplier or customer site, in fact I never default a tax rate from anywhere as its too high risk for getting the wrong code and instead all the tax logic is  handled by the rules.
No SLA would be needed in this case. The users never need to worry about the actual rate as they never have to choose it as it should be automatic, when the rate changes, we are looking at a 5 minute change to the rate rather than changing any default rules and the reporting is much clearer.
In this case, I think the use of SLA is a bad choice as Oracle already has standard functionality with the tax rules to do what you need.