ORACLE FIXED ASSETS

Subledger Accounting Impact

• Oracle Assets is fully integrated with SLA, which is the common
accounting platform for all E-Business Suite sub ledgers
• It enables you to comply with multiple legislative, industry or
geography requirements concurrently in a single instance through
configurable rules.
Enhanced Mass Additions • Populate depreciation attributes directly in the FA Mass Additions
interface table or via Web ADI rather than accepting default values
from the asset category. This means complete automation of legacy
conversions.
• Asset life, depreciation method, prorate convention, bonus rule
ceiling name, depreciation limit are some of the attributes that have
been added to the interface table in Release 12.
Automatic Preparation of Mass Additions • Default rules and public APIs can be used to populate expense
account, asset category and other required fields to complete the
preparation of mass addition lines automatically
• Significantly reduction in the overhead associated with manual
preparation of mass addition lines.
Fixed Assets Cont.

Automatic Depreciation Rollback • Depreciation is rolled back automatically when any transaction is
performed on an asset if the period has not yet been closed.
• No longer required to run depreciation rollback program manually.
• Executed only on select assets as required and not on the entire
asset book; resulting in a faster period close.

Flexible Reporting using XML Publisher • Ability to generate report in PDF, Word, RFT or HTML
Enhanced Functionality for Energy Industry • Process consideration for energy entities.
 ORACLE ASSETS PROCESS CHANGE

• Prepare Mass Additions process provided in Release 12 automatically populates all the required information for mass
additions lines. Mass additions data may be optionally verified before posting the mass additions lines.

• New SLA Accounting report and online account inquiry provided. The Account Drill Down report has been replaced the
Account Analysis report.

• The Create Journal Entries and Rollback Journal Entries programs are now obsolete. Create Journal Entries has been
replaced by Create Accounting.

• The Create Deferred Depreciation Journal Entries program is now obsolete. Users now need to run Calculate Deferred
Depreciation followed by Create Accounting.

• During upgrade, transactions in the current fiscal year in Assets books will have their accounting lines migrated to the
Subledger Accounting model. Accounting for current period depreciation will be upgraded only if depreciation has
already run for the period, and the period remains open. After the upgrade, you can run the SLA post-upgrade process to
update accounting for past transaction data as needed

• Prior to Release12, accounting records were not created until after depreciation had run. For example, if you added an
asset and went to the Transaction History form, you would not see any addition accounting lines if depreciation had not
been run. Post upgrade, however, these records would appear in the Transaction History form for additions, backdated
additions, backdated transfers and retirements.
 CONFIGURATION CHANGES – FIXED ASSETS
New configurable rules for automatic • You can use default rules provided by Oracle where the expense account is
preparation of mass additions. derived from the clearing account by replacing the natural account
segment from the asset category.
• In addition, default rules populate the asset category based on the clearing
account from the asset category setup.
• If the default rules do not satisfy your requirements, you can create
custom logic coded in a public API to pre-populate these values.
CONSIDERATION
• Review the asset clearing account of the all asset category setups if you are planning to use default rules for automatic
preparation of mass addition lines. If you have been using the same clearing account across different categories, the
default rules will not work effectively.
• In Release 12, Oracle continues to support Account Generator functionality for existing asset books. However, the
common SLA platform provides many opportunities to implement complex accounting rules without customizations.
For instance, some of our customers have requirements where the retirement account is different based upon the
type of retirement (missing, sale, theft, etc). These accounting rules can be configured in SLA without complex
customizations on your part.
 CASH MANAGEMENT
New Key Features • Centralized Internal Bank Account Model.
• Bank Account Transfers.
• Bank Account Balances and Interest.

CONFIGURATION CHANGE
• There is new user interface in Oracle Cash Management for bank, bank branch and bank account maintenance.
• Privileges to maintain bank accounts are granted to a user role by legal entity in the Oracle User Management security wizard.
• Internal bank accounts are owned by legal entities. Any operating unit under the same legal entity can be granted access to the same bank account.
• Bank account reconciliation parameters are now defined at the bank account level.
• Before you can enable bank account usage in Oracle Treasury, you will need to link a bank-counterparty in Treasury to the bank branch in Cash
Management, using Treasury’s Counterparty Profiles window.
• The system supports country specific validations for the bank account and address format.

CONSIDERATION

• During the upgrade, existing internal bank accounts defined in Oracle Payables and Oracle Treasury are migrated one-to-one into the new bank account
model in Oracle Cash Management.

• If you previously had to create two separate bank account records to represent the same real life bank account because it was used by two different
operating units, after the upgrade you will have the option to disable the duplicate bank account and allow both operating units to use the single bank
account. This will simplify bank account maintenance and bank reconciliation.
 CASH MANAGEMENT - BANK TRANSFER
In Release 12, users can create cash transfers between internal bank accounts, settle them through Oracle Payments
and account for them using Oracle Subledger Accounting
PROCESS CHANGE
• New user interface is available for capturing and, separately authorizing bank account transfers.
• Bank account transfers can be created intra-company (between two bank accounts belonging to the same legal
entity) or inter-company (between two bank accounts belonging to two different legal entities).
• Reusable bank account transfer templates can be created for accelerated data entry
CONFIGURATION CHANGE
• Privileges to create bank account transfers are granted to a user role by legal entity in the Oracle User Management
security wizard.
• Accounting configuration for bank account transfers is done in Subledger accounting. Seeded journal line definitions
are provided for bank account transfer clearing and un-clearing. Users can define additional journal line definitions
for bank account transfer creation and cancelation.
• Settlement of bank account transfers is done via Oracle Payments.
• If you plan to create inter-company bank account transfers, you will need to define inter-company accounts in
Oracle Advanced Global Intercompany System in order to create proper journal entries.
 BANK ACCOUNT BALANCE AND INTEREST
Oracle Cash Management provides robust functionality for bank account balance reporting, both online and via
concurrent programs with Oracle BI Publisher. Bank balance interest can be calculated for bank fee or credit.
PROCESS CHANGE
• There is new bank balance maintenance user interface in Oracle Cash Management.
• Bank balance maintenance in Oracle Treasury is disabled
• Data Is replicated between Cash Management and Treasury for bank accounts used in Treasury, so that the interest
accrual and settlement can still be performed in Treasury
CONFIGURATION CHANGE
• There is a new user interface to manage interest rate schedules.
• bank balance interest can be calculated, interest rate schedules have to be defined and assigned to bank accounts.
• Basis, Interest Rounding, Day Count Basis and Interest Includes parameters, previously defined at the bank account
balance level in Oracle Treasury, are now a part of the interest rate schedules in Oracle Cash Management.
• Portfolio Code, Pricing Model and Limits, previously defined at the bank account balance level in Treasury, are now
a part of the internal bank account definition in Cash Management.
CASH MANAGEMENT – CONSIDERATION
• Interest amount can be calculated for both standalone bank accounts and notional cash pools.
• Projected closing bank account balance can be saved alongside actual bank account balances using the new button
in the Cash Position window.
• For each bank account and balance date, you can keep track of multiple balance types
 GENERAL LEDGER
• Oracle General Ledger enhances:
 Support multi-national companies and shared services centers.
 Perform simultaneous accounting for multiple reporting requirements.
 Gain processing efficiencies by setting up, accessing, and processing data across
multiple ledgers and legal entities from a single responsibility.

• Release 12 highlights
 Centralized Accounting Setup
 Data Access Sets
 Ledger / Ledger Set Architecture
 Replacement for Disabled Accounts
 GENERAL LEDGER :CENTRALIZED ACCOUNTING SETUP
• The Accounting Setup Manager centralizes the setup and maintenance of common accounting-related setup that is
shared across Oracle Financials applications.
• Definition of legal entities and associated accounting setup to meet different accounting principles and reporting
requirements of multiple countries using different currencies, charts of accounts and/or calendars.
• Secondary ledgers and reporting ledgers to create alternate accounting representations automatically.
GENERAL LEDGER: PROCESS CHANGE
• Accounting Setup Manager is used to create and maintain accounting setups.
 Legal Entities: HR Organizations classified as GRE/LEs in Release 11i will be upgraded legal entities in Release 12.
 Operating Units: All HR Organizations classified as operating units will be preserved in Release 12
 Primary Ledger: Most sets of books in Release 11i will become primary ledgers in Release 12.
 Secondary Ledgers: Multiple-posting set of books (Global Accounting Engine) will upgrade to secondary ledgers
 Reporting Currencies: Reporting sets of books become reporting currencies in Release 12.
 Subledger Accounting Method: Ledgers will have a Subledger accounting method assigned during the upgrade.
GENERAL LEDGER: CONFIGURATION CHANGE
• Create legal entities and assign them to accounting setups – either assigned to ledgers or mapped to balancing
segment values.
• Create primary and secondary ledgers and mappings for alternate accounting representations from single
transaction (replacement for the Global Accounting Engine Dual Posting solution in Release 11i).
 GENERAL LEDGER: DATA ACCESS SET
Data access sets allow users to access multiple ledgers and ledger sets within GL from a single responsibility
This allows you to:
 Secure user access to data by ledger, balancing segment value or management segment value.
 Grant read-only user access, or read and write access.
PROCESS CHANGE
Process changes do not directly impact users, but rather control GL security behind the scenes.
 Security allows you to secure users’ access to data, or portions of data.
 Privileges allow you to grant users’ read only or read/write access to specific Balancing segment values within a
ledger, or to specific ledgers.
 Data access sets work with cross–validation rules and flexfield value security rules.
CONFIGURATION CHANGE
 The General Ledger Accounting Setup Program automatically creates a data access set for each ledger and
reporting currency (journal level or Subledger level) assigned to a completed accounting setup.
 Manually create data access sets to further control read and write access to ledgers, ledger sets, or specific
balancing segment values or management segment values for a ledger or ledger set.
 To associate data access set to a responsibility, you must assign a data access set to the GL: Data Access Set profile
option at the Site, Application, or Responsibility level
GENERAL LEDGER: LEDGER / LEDGER SETS ARCHITECTURE
Sets of books are upgraded to ledgers in Release 12. Ledger sets allow grouping of ledgers with the same chart of
accounts and calendar / period type, to allow processing across multiple ledgers simultaneously.

Ledger sets facilitate the following accounting operations across ledgers:

 Open / close periods for multiple ledgers simultaneously
 Submit concurrent programs for all ledgers in a ledger set
 Cross ledger allocations, recurring journals and year-end closing journals
 Currency translation for multiple ledgers simultaneously
 Financial reporting (FSGs) across ledgers
 Account inquiry across ledgers
CONFIGURATION CHANGE
 Create ledger sets to group ledgers with the same chart of accounts and calendar / period type.
 Assign ledger sets to data access sets for user access and security.
 The system automatically creates a data access set each time you define a new ledger set.
 The system generated data access set provides full read and write access to the ledgers in the ledger set.
 Before you can begin using the ledgers contained in your ledger set for transaction processing, you must assign the
ledger set to the profile option GL: Data Access Set.
GENERAL LEDGER: REPLACEMENT OF DISABLED ACCOUNTS

 Prevent errors and reduce manual intervention in the journal import process by defining a replacement account
for disabled accounts.

 If specified, the alternate account is used by the Journal Import process and the Create Accounting program in
Subledger Accounting to replace the original account combination if it is disabled or end-dated.

CONFIGURATION CHANGE

 Define alternate accounts when creating GL account combinations

 ORACLE PAYABLES
Oracle Payables has made some significant changes in the following areas.
 Supplier Representation in Trading Community Architecture.
PROCESS CHANGE
 New user interface presents a clear distinction between the supplier’s company details and terms and controls for
the trading relationship.
 Managing the attributes specific to particular functional areas such as Oracle Payables, Purchasing and Receiving
can be controlled with the use of Function Security.
 Adding new locations or relationships with additional operating units is streamlined.
 Each supplier is associated with a party and each supplier site is associated with a party site.
 Addresses can be entered and formatted based on country specification.
CONFIGURATION CHANGE
 When new suppliers are created the system creates a TCA party behind the scenes.
 Procurement and Payables specific attributes like terms and conditions, accounts etc. are maintained in the
supplier sites tables.
 Some payment and tax related information is no longer maintained in the supplier sites tables - it was moved to the
appropriate product tables (Oracle Payments, Oracle E-business tax).
PAYABLES: INVOICE LINES
 The addition of invoice lines allows Oracle Payables to better model the paper or electronic business document by
representing the goods or services, as well as tax, freight and other charges.
PROCESS CHANGE
 The new Invoice Workbench now contains a multi-record block to represent the invoice lines.
 Redesigned matching windows for PO/Receipt matching can be invoked from the Invoice Workbench.
 New windows support price/quantity/invoice corrections.
 Freight/miscellaneous lines are created automatically via request to the matching process from the matching
windows do not automatically generate distributions at line creation time.
 Tax, freight, and miscellaneous type invoice lines can be prorated to all item lines on an invoice.
 Users can enter freight at the invoice header and then prorate it across all item lines on the invoice.
CONFIGURATION CHANGE
 Users can also do a quick match by entering just the PO number on the invoice header. In this case, the invoice lines
are automatically created.
 With the new invoice lines model, the R12 multi-period accounting is realized at the invoice line level.
 ORACLE PAYABLES: PAYMENT PROCESS ENHANCEMENTS
The payment process has been significantly enhanced in Release 12. The following are some of the new enhancements
that were made in this release:
 More robust and flexible payment processing engine
 Improved visibility into payment processing via the centralized Payments dashboard
 Improved pay run automation
 Improved pay run management tools:
• Enhanced cash management report
• Comprehensive selected invoice information
• Improved online inquiry of selected invoices
 Process payments for multiple operating units from single responsibility
PROCESS CHANGE
 A selected Invoices page displays summary and detail information and analyze invoices selected in a pay run.
 Powerful search tools improve online inquiry to invoices to review, modify, or remove from a pay run.
 Users can now view invoices that were not selected due to various reasons (not validated/approved).
 A Payment Dashboard empowers your payment manager to monitor all current pay run processing and gives them
visibility to payment processes that require attention.
 The Payment Process Request template enables you to predefine invoice selection criteria, thereby simplifying
payment processing.
 ORACLE PAYABLES CONT: CONFIGURATION CHANGE
 All payment related setup has now been moved to the new Oracle Payments module.
 In prior releases, Oracle Payables seeded four payment method types (Check, Electronic, Wire, and Clearing).
 In Release 12, customers can setup their own payment methods
CONSIDERATION
 Scheduled Payment Selection report cannot be run for historical data.
 Custom document categories for payments will not be upgraded.
 Disbursement type has been made obsolete and hence, it has been removed from all reports.
 IMPORTANT: All custom payment formats must be migrated to XML in order to work in R12.
 Check Payments and the Electronic Payments document categories have been retained in Release 12.
 ORACLE PAYABLES: AP – AR NETTING
 The AP-AR Netting feature allows you to offset balances in both Oracle Payables and Oracle Receivables to reduce the
outstanding debt owed either from an internal company or from a customer.
 It also supports foreign currency netting.
 Accounting for netting is handled in the same way as if it had been closed in the Subledger.
 This feature allows you to optionally give the trading partner the opportunity to review and approve transactions
before they are posted.
PROCESS CHANGE
 A netting batch needs to be created using the Receivables responsibility. It can include various parameters like
operating unit, netting agreement, settlement date etc.
 Once the batch has been set up, submit the netting batch.
 Query the netting batch and view the proposed AP/AR netting amounts online.
 Users can view the Receivables and Payables transactions that were selected for possible netting.
 User can run AP/AR netting report.
 Optionally, users can review the netting batch. In this process users can review, remove or add transactions before
submitting it.
 Submit the netting batch and view the final netting report.
 Netting agreements will be created for every existing customer and supplier relationship that is migrated. Agreement
name will be created using customer id and customer name
ORACLE PAYABLES CONT: AP – AR NETTING
CONFIGURATION CHANGE
 Both customers and suppliers must be setup as a trading partner in TCA.
• Here are some of the additional steps that are required:
Create a netting agreement.
Create a netting bank account.
Create a netting control account in General Ledger as well as exchange rate types if using multi-currency
netting.
 Establish a paying relationship for the customers in Accounts Receivable.
 Associate the bank account used in the netting agreement with the AP/AR netting receipt class.
CONSIDERATION
 An internal dummy bank account will be seeded which will process receipts generated in Oracle Receivables.
 When creating a netting agreement, if the (supplier?) site information is left blank, then the system includes all the
sites for the trading partner.
 If the option to include trading partner approval is selected, only one approver can be selected. The approver name
list of values is derived from the customer contact information.
 No netting batch information will be upgraded
 ORACLE RECEIVABLES
Oracle Receivables streamlines the invoice, receipt and customer deduction processes while simultaneously improving
cash flow, increasing efficiency and optimizing customer relationships.
 Revenue Management Enhancements:
• Enhancements in the Revenue Management area include the ability to distribute revenue in a more granular
fashion which includes full and partial periods.
• Organizations may create their own revenue deferral reasons to ensure revenue is recognized in accordance with
applicable revenue recognition policies.
PROCESS CHANGE
 New configurable accounting rules to determine the treatment of revenue allocations for partial periods.
 Enhanced event-based revenue management allows users to define revenue deferral reasons and corresponding
revenue recognition events specific to their business practices.
• Ability to create user defined revenue contingency definitions seeded
 New Revenue Manager responsibility that provides the revenue analyst a central location to set up and maintain
revenue policies and rule assignments.
 Seeded revenue assignment rules have been replaced by a new window that enables the user to create process specific
revenue assignment rules.
 New Contingency tab offers the ability to review and manually manage contingencies from the Revenue Adjustment
Manager (RAM) wizard.
 New Cost of Goods Sold (COGS) and Revenue Matching feature synchronizes the recognition of revenue with
recognition of associated COGS.
REVENUE MANAGEMENT: CONFIGURATION CHANGE
 Creation of new accounting rules allows for revenue recognition that meets accounting standards and contractual start
and end dates.
 Ability to create user defined Revenue Assignment Rules.
 New Application Programming Interface (API) automates revenue & COGS matching.

REVENUE MANAGEMENT: CONSIDERATION

 COGS and Revenue Matching report has been retired.
 No longer necessary to create manual journal entries for revenue & COGS matching.
 Uptake of SLA does not impact timing and amounts for revenue recognition. It only provides the ability to override the
accounts defaulted via auto-accounting.
 Upgrade script will convert the contingency ID from prior releases to the new contingency removal event code
 SLA can only be used to override the accounts created via autoaccounting.
 ORACLE RECEIVABLES: LINE LEVEL CASH APPLICATION
With the introduction of line level cash application, receipts can be applied against specific transaction items such as
individual lines, group of lines or tax or freight buckets.
PROCESS CHANGE
 New cash application tree to choose the appropriate application level.
 Receipts can be applied against:
o one or more transaction lines
o all transaction lines
o a specific group of transaction lines
o a specific transaction line type such as tax, freight, late charges or any combination thereof
 Ability to un-apply and re-apply receipts. Un-apply and re-apply can be done against an entire transaction or to a
specific transaction line.
CONSIDERATION
 Line level applications apply to manual cash application only.
o However, automated line level application is available via lockbox.
 Receipts cannot be applied at the line level against invoices migrated from Release 11i, as line level balances were not
stored prior to R12.
 Available only for invoices, debit memos and chargebacks with line details.
 Cannot apply against invoices with installments.
 ORACLE RECEIVABLES: CUSTOMER STANDARD USER INTERFACE
The new HTML based user interface provides a streamlined and intuitive customer data management flow. Data quality
management tools allow users to maintain the integrity of customer data.
PROCESS CHANGE
 Provides functionality to create a new customer, customer account, customer account site, and a business purpose
for the customer account site.
 Tight integration with TCA allows users to take advantage of the Data Quality Management)feature. DQM allows the
user to perform advanced searches for parties and customer accounts with user defined criteria.
 Ability to classify customers based on industry, location, size, credit worthiness, business volume and payment cycles.
CONFIGURATION CHANGE
 The new Customer Standard UI replaces the five functions that used to exist in prior releases.
o The pages are built using TCA CPUI (Common Party User Interface) components.
 By using TCA components, the cost of maintenance is lowered.
CONSIDERATION
 The Customer Standard menu item will launch the new HTML customer form.
 No data is affected
 Display of data has been enhanced to represent the TCA model
 E-BUSINESS TAX
E-Business Tax is a new product introduced that provides a single point solution for managing transaction tax
requirements across several E-Business Suite products.
The key components of E-Business Tax are:
• Configuration Options and Provider Service Subscriptions
• Tax Configuration Manager
• Tax Determination Services
• Tax Reporting
• Tax Simulator
PROCESS CHANGE
 Each entity within an organization can subscribe and use a single common configuration source for all transactions.
 Entity can use the common configuration source with overridden tax set up specifically required to meet its own tax
regulations.
 In Release 11i, the option to integrate with tax service providers was restricted to Vertex and Taxware. In Release 12
that restriction no longer exists: you can choose to integrate with your preferred tax partner
CONFIGURATION CHANGE
 If all entities in your enterprise are subject to the same tax regulations you can setup tax only once, under the Global
Configuration Owner, and have all your entities subscribing that common tax setup;
 If any entity within your enterprise requires special tax handling that differs from the common tax setup, you can
either override the common tax setup that is owned by the GCO or create and maintain specific tax setup for that
entity that becomes a Configuration Owner itself.
 You can optionally subscribe services of external providers to handle tax configuration and tax calculation, using
standard API’s.
 TAX CONFIGURATION MANAGER

 The Tax Configuration Manager component is responsible for creating and maintaining the structural foundation
of Tax such as taxes, tax jurisdictions, fiscal classifications, tax rates, tax rules.
 In Release 12 there is an explicit association between tax setup and Legal Entities or Operating Units.
 Tax setup is uniformly created in a common User Interface for all Oracle products. Tax regulations are defined only
once and applied consistently across products.
 Legal and business tax regulations are mapped to flexible tax rules and other components of E-Business Tax.
 Tax setup is uniformly created in a common User Interface for all Oracle products. Tax regulations are defined only
once and applied consistently across products.

PROCESS CHANGE

 There is a unique tax setup flow and common user interfaces across products. You no longer need to enter tax
setup in multiple product.
 Tax setup creation and maintenance is done in new User Interfaces
 You have multiple options for defining tax setup in Release 12.
 Manually enter your tax setup.
 Use the Tax Configuration Library with modifications.
 Integrate with tax content providers
 E-BUSINESS TAX: CONFIGURATION CHANGE
 Prior to Release 12, you could define Legal Entities in multiple, sometimes ambiguous, ways. With the new Legal Entity
model you now have to explicitly define your legal entities as well as the association with the appropriate tax setup.
 Instead of creating tax setup in various products, like Oracle Payable or Oracle Receivables, you create a single tax
setup that is applied consistently across products.
 Central setup and maintenance is now performed in new User Interfaces dedicated to your tax personnel.
 The Tax Rules flow makes it easy for you to change existing tax rules and tax rates and/or create new rules and rates,
without modifying the product.
 You have the option to run taxes in Release 12 similarly to how you did it in Release 11i and gradually migrate to the
new E-Business Tax model, when you have the time or the need to adopt the new capabilities of E-Business Tax.
CONSIDERATION

 Cannot update tax exclusiveness at invoice header or invoice line levels.

 Tax reporting configuration is associated with a Legal Entity and Tax Registration Number. It is not integrated with the E-
Business Tax internal subscription model.
 Tax reporting configuration not shareable across Legal Entities or Operating Units;
 E-BUSINESS TAX: TAX DETERMINATION SERVICE
The Tax Determination Services component calculates transaction taxes based on transaction details and tax setup
information. This component carries the following benefits:
 Automation of tax processing through a central tax engine. It improves the operation efficiency of your company
and reduces errors.
 The central tax engine uses a common set of tax rules applicable to all your business entities. Ensures the accuracy
of tax calculation for all tax regimes your company is subject to.
 Covers standard Procure-To-Pay and Order-To-Cash transaction taxes, with the exception of withholding taxes and
those taxes handled by the Latin Tax Engine solution.
PROCESS CHANGE
 Instead of disparate tax services provided by multiple products, the central tax engine uniformly delivers automated
tax services through a single application interface to:
• Procure to Pay - Oracle Purchasing, Oracle Consigned Inventory, Oracle Internet Expenses and Oracle Payables
• Order to Cash - Oracle Order Capture, Order Management, Oracle Trade Management, Oracle Project
Accounting and Oracle Receivables
• General Ledger - Oracle General Ledger
 E-Business Tax replaces the following Release 11i tax solutions:
o Procure to Pay – Automatic Tax Calculation and payables and Purchasing
o Order to Cash – Global Tax Engine
o General Ledger – General Ledger Automatic Tax Calculation
 Users no longer have to enter the correct tax code at transaction entry point: E-Business Tax determines the
applicable tax or taxes for each transaction and automatically calculates the tax amount(s). Only your authorized
users can override calculated tax amounts.
 E-BUSINESS TAX: TAX DETERMINATION SERVICE CONT.
CONFIGURATION CHANGE
 There are distinct flows for tax setup and for operational activities such as entering transactions;
 Tax determination and tax calculation are fully automated, based on tax setup previously defined by the tax manager;
 Clerks whose main responsibility is to correctly enter transactions in the system can rely on the product to get the correct
taxes applied to transactions. They no longer have to enter the relevant tax codes for each transaction because EBusiness
Tax does that for them, reducing the risk of human errors.
TAX REPORTING
 Tax Reporting and auditing rely on a single tax repository that stores both reference data (taxes, tax jurisdictions, fiscal
classifications, tax rates, tax rules) and transactional data.
 The single tax repository, tax reporting and auditing take advantage of the XML Publisher reporting tool that facilitates
output manipulation.
 Tax reporting was largely enhanced with features which can be used by countries in other regions with the same type of
requirements.
PROCESS CHANGE
 Reference data and transactional data are now available from a central Tax Repository. You no longer need to search for
tax information in multiple products.
 Enhanced tax reporting configuration with dedicated User Interfaces where you define all reporting rules for your
Reporting Entities.
 Business users can easily update templates delivered in the core product or create new templates without changing
code. The majority of tax reports are converted to XML Publisher.
E-BUSINESS TAX: TAX REPORTING.
CONFIGURATION CHANGE
 Ability to run tax reports by Legal Entity and Tax Registration Number. In Release 12 you can still run tax reports by
Balancing Segment Value.
 Definition of reporting categories to report transactions by different business angles: sales, purchases, goods, services,
stocks, assets, domestic, import, export, etc.
 Tax reporting based on tax calendar that can different from the accounting calendar.
 Reporting based on a user definable tax reporting date.
 Preliminary versions of tax reports to be run in order to support corrections and reallocations prior to finalizing the
reports (declarations) to tax authorities.
 Final reporting
 Close tax periods after final reporting to prevent updating or reporting twice transactions already finally reported.
CONSIDERATION
 Core tax reports run by Invoice Date only.
 Tax calendars, alternative tax dates, preliminary and final reporting, tax reporting categories (or tax boxes) only used by
EMEA VAT Reports.
 In order to meet reporting requirements, some of the EMEA countries have to define multiple tax rate codes with the
same tax rate.
 Multiple Reporting Currencies support not available in all tax reports.
 Tax Repository does not store General Ledger tax journals.
 A few tax reports were not converted to XML Publisher (still available in rdf).