Payables

How to Transfer Invoice Tax Variances in Average Costing Organization

Oracle Payables will calculate Invoice Tax Variances when there is a non-recoverable tax that has been calculated at AP invoice entry that was not included on the Purchase Order.    In an average costing organization this tax variance should be transferred to the inventory valuation to ensure that the correct item cost is calculated.     Please see attached video for a demonstration of this functionality in Oracle R12.

Oracle R12: The problem with using Legal Entities for Tax!

So, here is my problem. We have a client who has a UK legal entity but has several locations globally that are registered for local indirect tax and some other reporting but are not legal entities in their own right. According to Oracle, these are legal entity Establishments.

Oracle Definition of Legal Entity Establishment

“Legal Establishment: First party legal entities identify your organization to the relevant legal authorities, for example, a national or international headquarters. First party legal establishments identify each office, service center, warehouse and any other location within the organization that has a tax requirement. When you create a legal entity, the system automatically creates a legal entity establishment. You can create additional legal establishments according to your needs. For each legal establishment there are one or more tax registrations, depending upon the tax requirements of the applicable tax authority.”

More can be found at note 1064366.1

So what is wrong?

Continue Reading

Oracle R12 eTax: APP-SQLAP-97733 tax distribution error

If you get the following error when trying to look at distributions or validate your AP invoice, then this is caused by a currency issue.

ZX_GENERIC_TEXT

invoice validation issue

Continue Reading

Oracle R12 How to change a paid invoice when you need to make a tax corrections

Changing the tax rate or recovery rate on a paid invoice

First you need to make sure you know the policy of adjusting a paid invoice as many companies do not want to allow this option and by default it should certainly be set to NO. However, we have found that when a user applied the wrong tax code to a transaction and a correction is needed, it is far easier, cleaner and more accurate to change that invoice even if it has been paid.

Changing the original transaction instead of applying a credit note and reentering the invoice has many more benefits. Firstly, the time taken is much less than having to create a credit memo and a new invoice, both of which then have to be paid. Continue Reading

Oracle R12. What is the Usage and Purpose of the Customer Taxpayer Id for eBTax?

Metalink Note (this is deailing with AP transactions only)

From Metalink, article ‘

The issue has been analyzed on Bug.8418407:  R12 CUSTOMER TAXPAYER ID FIELD ON INVOICE WORKBENCH, USAGE AND PURPOSE
Per R12 design the operating unit and legal entity do not hold one-to-one relationship anymore, which is in sharp contrast to 11i. Now one operating unit can be attached to many legal entities in a ledger. Under General Ledger (GL) responsibility, Setup : Financials : Accounting Setup Manager, all the legal entities of a primary ledger or secondary ledger can be found.

Here, customer refers to the Apps deploying agency that is liable to pay a supplier invoice and is accountable to legal authorities for it. So once the “customer taxpayer id” is selected at the header then the system doesn’t default legal entity on the basis of “bill to location” of the selected supplier site and the invoice liability account. The “customer taxpayer id” gives a way to explicitly override the default legal entity derived from supplier site and liability account and default org id. “Customer taxpayer id” is the unique reg. number used to identify an LE. Also “Customer Taxpayer ID” can be used for any type of invoices. The system does not consider it to be mandatory.

In summary, the customer taxpayer id is used to explicitly override the default legal entity derived from supplier site. On the contrary, the taxpayer id is used to enter tax information about the individual or legal entity, which can be a corporation or a partnership.

So the Legal entity that is chosen is first determined by the balancing segment value that is linked to the liability account and then the legal entity that has that balancing segment associated to it is chosen. You can then mnually change this by choosing the value in the ‘Customer Tax Payer ID’

How does this affect ebtax?

You can link the tax regime to either the OU or the LE and therefore use this as the way for driving the tax for your AP transaction. Ideally, you will have a solutoin where there is only one LE linked to your OU and in this case youc an only ever choose one value for the customer tax payer ID so you would never have to choose it as it will be the default. But if you do have more than one LE linked to your OU then you can only determine the place of supply for the tax regime rules with the bill to or ship to. As there could be multiple ship to values then it the only other approach is to change the bill to and to do this you need to change the legal entity (customer tax payer ID).

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.