Tuesday, November 1, 2011

Setting up Tax in R12 Payables

Step 1: Create the Tax Regime
The tax regime is the highest/ultimate level that taxes are rolled up to, typically, a specific country. In this step, the Controls and Defaults must be set. The Control section outlines 4 options. Once the tax is made live, the control options cannot be changed.
The Defaults section will default as applicable to the tax, status, jurisidiction, and tax rate levels, but they can be changed at each level.
Step 2: Create the Tax
One Tax Regime can have multiple taxes defined under it. The tax type, e.g. sales, VAT, use, is determined when the tax is set up. Taxes can be set up by geography type, which allows for taxes at different levels.. For example, in the US, there is can be a tax levied at the State level, one at the County level, and one at the City level.
Step 3: Create the Tax Status
This is used primarily in the UK to define reduced rate, zero rate, etc. taxes. All taxes must have at least one tax status defined, and one of those must have the "Set as Default Status" option checked.
Step 4: Create the Tax Jurisdiction
A tax jurisdiction is a geographic area for which a tax is levied, e.g.Colorado, California, Florida, El Paso County, Los Angeles.
There must be at least one Tax Jurisdiction for each Tax Status with the "Set as default Tax Jurisdiction" selected and the "Default Effective Date" supplied.
Step 5: Create the Tax Rate
Create specific tax rates to be applied for a geography. There must be at least one default tax rate. The tax accounts are also set up in this step.
Step 6: Define Tax Rules
Set defaults for the following rule types:
Place of Supply
Registration
Taxable Basis
Calculate Tax Amounts
Step 7: Make the Tax Live for Transactions
Return back to the Tax created in step 2, and select the Make Tax Available for Transactions option. If it is not available to be checked, the tax is not set up correctly. Any missed setups will need to be completed before this can be setup.

Monday, October 17, 2011

Data Derivation for Auto Invoice

1. Date Derivation In AutoInvoice: How It Works
During the process of AutoInvoice you can enter the General Ledger (GL) date and the Transaction date for a particular transaction explicitly in the relevant columns of the RA_INTERFACE_LINES_ALL table or you can allow the AutoInvoice process to derive the dates.If the dates are provided, AutoInvoice will typically use them. There are a few scenarios where dates cannot be provided as input parameters; these scenarios are discussed in section 2.e titled GL Date Validation.If the dates are not provided, they will be derived. Date Derivation of the General Ledger date and Transaction date during the process of AutoInvoice depends on the following:
1. The columns that are populated in the RA_INTERFACE_LINES_ALL table, namely
· GL_DATE
· TRX_DATE
· SHIP_DATE_ACTUAL
· SALES_ORDER_DATE
· RULE_START_DATE
2. Selection of the Derive Date Option in the Accounting Information Tab of the Transaction Sources window.3. Whether or not Invoicing Rules and Accounting Rules are used.4. Setting of the GL Date in a Closed Period option in the AutoInvoice Options tab of the particular Transaction Batch Source.5. Default Date entered while submitting the AutoInvoice Program.Once imported as a transaction in receivables, the GL date used by AutoInvoice is stored in the table.column: RA_CUST_TRX_LINE_GL_DIST_ALL.GL_DATE.

Primary and Secondary Ledger vs Reporting Currency

Primary Ledger Vs Secondary LedgerUse secondary ledgers for supplementary purposes, such as consolidation, statutory reporting, or adjustments for one or more legal entities within the same accounting setup. For example, use a primary ledger for corporate accounting purposes that use the corporate chart of accounts and subledger accounting method, and use a secondary ledger for statutory reporting purposes that use the statutory chart of accounts and subledger accounting method. This allows you to maintain both a corporate and statutory representation of the same legal entity's transactions in parallel. Reporting Currency Vs Secondary LedgerReporting Currencies are not the same as secondary ledgers. Looking at the 4 C's that define a ledger, we have a chart of accounts, calendar, accounting method, and currency. If you only need multiple currencies to support your reporting requirements, use reporting currencies. If you need to account for your data using different calendars, charts of accounts, accounting methods in addition to currency, use a secondary ledger.

Oracle Accounting Setup Advantages