Oracle Apps Knowledge Varsity.

How to update the Period status to Future-Enterable , can not see new peiords on the open/.close form

2011-12-25T12:49:00.003-05:00

Issue: Not able to view future enterable periods.when a user opens the perior period (eg Dec11) before we defined the next year calendar when you open the period users will not be able to see the future entereable periods. i.e We created new periods after the last period defined was opened. Now we can not see those new periods on the Open/Close form.

Solution:
1.Make sure that the periods are setup for the next 2years.
2. Query the Set of books setups and make a note of the number of future periods.
3. When you open the next period it will automatically mark any future periods as future enterable to the number of periods given in gl_sets_of_books Future_Enterable_Limit.
If you didn't set up next years calendar before opening the last period of this year there is no mechanism in applications to open this. It will have to be done using sql

11i Fix:
======

1) Obtain SET_OF_BOOKS_ID and number of future enterable periods from GL_SETS_OF_BOOKS as follows:

select set_of_books_id, future_enterable_periods_limit, latest_opened_period_name
from gl_sets_of_books
where name = '&setofbookname'

a. make sure you have future_enterable_periods_limit greater than zero if not stop.
b. make sure that the latest open period name is still in the current year if not stop

2) select closing_status,period_name
from gl_period_statuses
where closing_status = 'N'
and set_of_books_id = &set_of_books_Id
and application_id=101;

a. Make sure the status is 'N' do not change it if its not 'N' or you will get corruptions

3) Update Period status to Future-Enterable as follows:
update gl_period_statuses
set closing_status = 'F'
where period_name = '&PERIOD_NAME' - period name you wish to update
and application_id = 101
and set_of_books_id = &set_of_books_Id
and closing_status = 'N';
Commit;

R12 Fix:
======
a) Obtain LEDGER_ID from GL_LEDGERS as follows:
SELECT ledger_id, name FROM gl_ledgers
WHERE name like '%bookname%';

b) Make sure the status is 'N' do not change it if its not 'N' or you will get corruptions.
select closing_status, period_name
from gl_period_statuses
where closing_status = 'N'
and ledger_id = &ledgeridabove
and application_id=101;

c) Update Period status to Future-Enterable as follows:
UPDATE gl_period_statuses
SET closing_status = 'F'
WHERE period_name = '&PERIOD_NAME_you_wish_to_update'
AND application_id = 101
AND ledger_id = &ledgeridabove
AND closing_status = 'N';
Refereces Mysupport:
1.Note# 135433.1-General Ledger FAQ for Open/Close Period

R12.1.X-Over all Changes (Business Group,L.E, Locations , Address....)

2011-08-16T01:10:00.001-04:00

Version 12.1.3 has some significant differences to earlier R12 versions impacting the behavior of the HR Locations records (which are important for the multi-org setup)

Business Group (used for employees and HR functions, no difference to 11I

Chart of Accounts – basis for all other operational and financial setups) – no difference in setup and structure.

Legal Entity – New Legal Entity Configurator Responsibility in Web-Form) - Lots of different setup and decisions to be made (very different from 11I)

Create Ledger - New Accounting Setup Manager Responsibility in Web-Form Lots of different setup and decisions to be made (very different from 11I). Formerly GL Set of Books.

Create Operating Unit and assign to Ledger New Accounting Setup Manager
Responsibility in Web-Form Additional restrictions and impacts, differences between R12 and 11I.

Responsibilities span multiple Operating Units for transactional capability
Legal Entity has now become relevant
UMX – User Management has a implicit role in some tasks
Multiple forms are now Java/HTML based; often the application jumps between these
XML Publisher - now BI Publisher is all over the place
You have to start with creating a Legal Entity to start a Ledger definition
You cannot use the same name for a Legal Entity
The key is the Tax ID Number (cannot be re-used)
You cannot delete these from the system, you can end-date them
Cash Management now “owns” Banks!
You need to log in to Cash Management to create Bank and Account Information (Note: 415529.1)
You MUST assign the Cash Management responsibility using UMX – User Management
This MUST be done using the SYSADMIN User, not the responsibility!
Customer form has changed drastically
The Customer form has been moved to the TCA architecture
Payment Manager is a new concept for Payment processing.

Location Addresses” or “Locations” – Terminology and challenges in visibility of data from both angles Java and Web-Form
No easy way to see table used in Web-Form
No easy way to see total number of records in Web-Form
Locations are not consistently visible across Java and Web Forms. We are not sure what it depends on. Possibly I can see in Web form only those that have been entered in Web-Form. In Java I can see all. Possible strategy is to enter what you can in Web-Form, especially locations, organizations
Locations in Java and 11I are called Addresses in Web-Form of 12
Business Group Needs Location (HR_Location)
Address Validation (HR Address Format and Validation Changes in 12.1.3 & one of patch - Patch 9871990)
Data entry through Java form or Web-form?
Address default United States – will cause validation (if site profile option is set for HR purpose).

Reference:
1104887.1 : How to Setup a Legal Address Using HR Address Formats in R12 Legal Entity Configurator

1064366.1 :How to Add a New Legal Entity, Ledger and Operating Unit for a New Country

GL Translation Process

2011-02-26T21:26:00.007-05:00

What is Tranlation:
Foreign Currency translation is the process that restates functional currency account balances in another currency.

Translation converts balances from your functional currency to a foreign currency, you can translate both actual and budget balances. if you have average balance processing enabled the system can translate average balances as well.
Tranlation is frequently used to prepare financial reports for consolidation into global financial statements. It is also used in highly inflationary economies to produce reports in a more stable currency.

When do you run translation:

Translation should be run at the end of the period, after all transactions have been processed and reconciled.

How does the system transalte balances:

- Assets and liabilities are translated by multiplying the YTD balance by the period end

How do I check that the translation has been carried out correctly?

Reconciliation of the Cumulative Translation Adjustment (CTA) Account:
1.Take the total of your P&L (Revenue and Expense) accounts and multiply this amount by the period average rate defined.
2.Take the total of assets and liabilities and multiply this amount by the period end rate.
3.Take the total of your retained earnings and use the historical amount or multiply by historical rate (whichever way you have defined it).
4.Add 1,2 and 3 together. This should equal the amount in your translation adjustment account.
5.Make sure no other entries have been made to the account. If there has been, they would have to be reversed in order to reconcile the amount.
Translation using Historical Amounts.?
In some situations, you may want to use Historical Amounts to translate certain accounts. However, when Historical Amounts are used in the very first period ever translated, this creates a large Rate Adjustment for the same amount which distorts the Cumulative Translation Adjustment account.
The translation code cannot distinguish between how much of the Historical Amount defined is attributable to the Beginning Balance and how much is attributable to rate fluctuation in the period, so the entire amount is thrown into the Rate Adjustment bucket.
For example, in the first period ever translated where there is no period activity for the account, when you use Historical Amounts, you may see:
Beginning Translated Balance = zero.
Rate Adjustment = the Historical Amount defined.
Ending Translated Balance = the Historical Amount defined.

By definition, when translating on YTD basis, the Historical Amount defined is equal to the YTD Translated Balance. You would like to know how to correct the situation so that you do not have a large Rate Adjustment in the first period translated.
The workaround is to "back into" an Historical Rate, based on the Historical Amount that you want to achieve for the period. You should use this Historical Rate in the first period ever translated, then in the subsequent months use the appropriate Historical Amount. This eliminates the large Rate Adjustment in the first period ever translated.

Does the Translation of Owner's Equity Accounts comply with FASB 52?
The profile option GL: Owner's Equity Translation Rule should be set PTD to comply with FASB 52.

Set to PTD:
Ending Translated balance = Beginning Translated Balance +
(Current month activity in Functional Currency * Current Month Historical Rate)

Set to YTD:

Translated Currency YTD = Functional Currency YTD * Rate
YTD translation of Owner's Equity Accounts calculation does not take into account the historical rates that were in effect at the time of each transaction in the account.

How to change Translation from Historical to Period Rates?
1. Delete the historical rate from the Historical Rate Form.
(Note if you have a Prior Historical Rate - this will have to be deleted. You may have a prior historical rate if you deleted the historical rate and reran translation without purging the original translations using the original historical rate).
2. Define a period-end rate in the Period Rates form.
3. Purge translated balances to get rid of the original historical rate.

The amount used depends on whether the account to which the historical rate or amount applies is a revenue/expense, asset/liability, or owners’ equity account:
Revenue/Expense: The amount is treated as translated net activity for the period.
Asset/Liability: The amount becomes the YTD translated balance for the
account.
Owners’ Equity: If the profile option GL: Owners Equity Translation Rule is set
to PTD, the amount is treated as translated net activity for the period. If the profile
option is set to YTD, the amount becomes the YTD translated balance for the
owners’ equity account.

Restating Balances Previously Translated with the Year–to–Date Rule
Older versions of General Ledger always translated owners’ equity accounts using the
Year–to–Date rule. If you subsequently switch to the Period–to–Date rule, your owners’ equity accounts will be translated using this rule for new translations only. Previously translated owners’ equity balances will not change. If you wish, you can restate your previously translated owners’ equity balances.

To restate your previously translated owners’ equity balances using the Period–to–Date rule:
1. Purge the old translated balances for each period to be restated.
2. Change the GL: Owners Equity Translation Rule profile option to PTD.
3. For each period to be restated, use the Historical Rates window to delete the rates used to translate owners’ equity accounts, as follows:
-- Retained Earnings: Delete any non–historical rates.
-- Other Owners’ Equity accounts: Delete any period rates.
4. Run translation. Your owners’ equity balances will be translated using the PTD rule.
Note: If you change a period rate after you’ve already run translation, you must retranslate your account balances for the period whose rate has changed.

Prior: General Ledger uses the most recently entered historical rate or amount for
your balance sheet accounts, and assigns it the rate type Prior. If you have average
balance processing enabled, General Ledger rolls this historical rate or amount
forward using the rate type Prior.

Period: If you have never defined a historical rate or amount for an owners’

equity account, General Ledger uses:
The period– average rate if the profile option GL: Owners Equity Translation Rule is set to PTD.
The period-end rate if the profile option GL: Owners Equity Translation Rule is set to YTD.

Calculated: This rate type is only used when the profile option GL: Owners
Equity Translation Rule is set to YTD. It is only applicable to the first period of
your fiscal year. If you have never defined a historical rate or amount for your
retained earnings account, General Ledger calculates a rate and assigns it the rate
type Calculated.

Profile related to Translation:
GL: Owners Equity Translation Rule
Specify the rule General Ledger follows to translate owners' equity accounts when you
have not entered specific historical rates or amounts.
The following values are available:
PTD: The Period-to-Date rule is used to translate owners' equity accounts. For
each period for which you translate owners' equity accounts, the historical rate is
set to the period-average rate.
YTD: The Year-to-Date rule is used to translate owners' equity accounts. For
each period for which you translate owners' equity accounts, the historical rate is
set to the period-end rate.
The default value for this profile option is PTD.

GL Transaltion : Revenue/Expense Translation Rule:
Revenue and Expenses are translated according to the GL Translation: Revenue/Expense Translation Rule Profile setting (PTD or YTD). If this is not set then Revenue and Expenses are translated by multiplying the PTD balance by the Period Average Rate

Purge, Transaltion and Retranslation:
Retranslation again will be done on the basis of the status column in the gl_translation_statuses table. If the status is current, there will be nothing that will be translated.
Translation will run in 2 phases. First phase gets the out of date records Translation Status - C.Here it translates only those records, which are out of date due to some adjustments.if it is the account adjustment all the foreign currencies need to be translated again. If it is a rate adjustment only that currency needs to be translated Second phase gets the records for periods, which have never been translated.

As an Example, if the Functional Currency is USD and translation is done into GBP, INR and CAD. If there is a change in the accounts in the functional currency, then Translation needs to be run for all the currencies. On the other hand, if there is a change in period rates or Historical Rate/ Amount for any currency, it will be sufficient if Translation is run for that particular currency.

Purge means Translation status for the period will always be Never Translated for the periods for which it is run. It will re-state the values in the gl_translation_tracking table. It essentially is translating every record whether or not that is current or out of date as the foreign currencies will not be there. In a way it can be said to be direct phase 2 of translation.

Running translation for the first time

You cannot translate in the first period in your calendar.

The first Consolidation must be performed as YTD not PTD for two reasons:

1.PTD will not generate a correct Opening Balance figure.

2.The Consolidation Journal maybe unbalanced by the amount of the CTA adjustment if there are Accounts defined with a Historic Conversion Rate.

Source: My OracleSupport.

R12 Legal Entity Configurator

2011-02-26T14:38:00.011-05:00

The Legal Entity Configurator allows you to define legal entities and establishments in the Oracle system to achieve legal compliance for business activities handled by the Oracle E-Business Suite.

In Oracle Ebusiness Suite 11i, the Legal Entity is tied closely to a set of books and operating Unit, so your Legal Structure has to be defined in the way you set up your apps partitions (OU, Set of Books etc.).

In R12 financials breaks away from that with the introduction of the Legal Entity Configurator allowing you to model your Legal Structure separately from the partitions in your ERP system. Then you mark certain items with an owning LE, rather than use the OU or set of books to derive the LE.

A Legal Entity is an entity identified through the registration with the legal authority. A Legal entity represents a legal company for which you prepare fiscal or tax reports. You assign tax identifiers and other Legal entity information to these types of organizations.

Legal Entities have the right to:

•Own property (assets, inventory, receivable, other LEs)
•Trade (borrow, sell, buy, incur expenses, employ)

Responsibility to:
•Repay debt (liabilities, equity)
•Pay Taxes
•Account for themselves (legal reports, audits) .

What we map Legal Entities to
1. Accounting Structures - Balancing Segment Values and Ledgers
2. Tax Rules in eTax - Who I am and where I am registered/located determines what tax I need to pay
3. Bank Account - Who owns that bank account and the cash in it
4. Payables and Receivalbes Invoicing - the owner of that transaction, sometimes referred to as LE stamping
5. Intercompany Accounts and Intercompany Processing Rules

The Features for Legal Entity are:
1.Legal Entity Setup
2.Establishments Setup
3.Legal Entity Search
4.Legal Authorities and Jurisdictions and
5.Legal Associations

Legal Entity setup : Is the main component within Oracle’s Legal Entity Solution to meet the enterprises’ global Legal requirements. To be able to operate, a Legal Entity may be required to register with different Legislative Authorities depending on the Legal Entity’s activity and locations in order to comply with the law in the territory of operation. Users will use the Registration User Interface pages to create registrations for a Legal Entity in the Oracle System. The Registration User Interface will enable users to enter required registration related information that is needed for legal compliance in a given Oracle Applications instance.

Establishments are made up of a Main Establishment and additional Establishments. Conceptually, the Legal Entity and Main Establishment are tightly coupled. Therefore, every Legal Entity must have a Main Establishment. Whenever a Legal Entity is created, a Main Establishment will automatically be created. A main Establishment is always located in the same Legal Entity’s country. Legal Entities may or may not have additional Establishments.

Additional Establishments are required only in countries where other Legal Entity location needs to register with legal authorities (e.g. India, Brazil, Germany). Some Establishment attributes are required to provide information for current functionality (e.g. Registration Number- SIRET for DAS2 in France). Additional Establishments may or may not be located in the Legal Entity’s country. Main Establishments as well as additional Establishments may follow different set of rules if they do business in different activities or are located in different areas.

Legal Entity Search page : The purpose of the Search Page is to manage Legal Entities, Establishments, and Parties. In order to avoid duplication, users can identify existing Parties of type Organization and update them to be Legal Entities or Establishments.

Users will be able to:
•Update existing Legal Entities or Establishments
•Update an existing Organization Party to be a Legal Entity or a Establishment
•Configure a Trading Community Architecture Party type of Organization as a Legal Entity or Establishment.

The Legal Entity Search Page only displays Trading Community Architecture (TCA) parties of type “Organization.”

All Legal Entities must be registered against a Jurisdiction that is governed by a Legal Authority. The Jurisdiction is a formulation of a legislative category and territory to which legal rules are grounded. The Legal Authority is an executive power that operates within the jurisdiction to enforce legal rules, collect fees/taxes, and make financial appropriations within the territory. In order to support the legal world on which the legal entity is founded, both the legal authority and jurisdiction is clearly defined as part of the Legal Entity Solution.

Legal Associations is part of the Legal Entity Solution which consolidates and provides a centralized solution for Legal Entity related data in Oracle Applications. Various processes like Tax calculation and intercompany transaction processing are dependent on the knowledge of the owning Legal Entity or Establishment. Given that the legal context is not directly stated in Applications transactions today, Legal Associations provides a method to derive the Legal Context by building associations between business and accounting information that are available on transactions and Legal context. Legal Associations will also provide the ability to build associations between Legal Contexts.

A legal entity is the organization unit level at which you report taxes and maintain the corporate banking relationships. The LEGAL_ENTITY_ID column is added to the transaction tables in 12, allowing the ability to track transactions at a Legal Entity level. In R12, you assign a Legal Entity to a Ledger instead of to a Set of Books. It is recommended that you assign one (or more) balancing segment values in your chart of accounts to a legal entity.

Territory:
The territory where the legal entity is registered. This list displays territories at the country level and shows only territories for which the identifying jurisdiction has been defined. Therefore, the territory determines the identifying jurisdiction to which the legal entity needs to register. The territory also determines the context for the information that needs to be displayed in the General Information region. For Canada the BIN number is one such field.

Organization Number:
The organization number is a number used to identify organizations. This field is displayed only when the HZ: Generate Party Number profile option is set to No. In this case, the main establishment organization number is built as a concatenation of the legal entity organization number and ETB (establishment). Otherwise it is not displayed and is generated automatically. For example, if the legal entity organization number entered is 12536, the establishment's organization number will be 12536ETB.

Legal Entity Identifier:
The identification number used to uniquely identify the legal entity. It is displayed only when the LE: Generate Legal Entity Identifier profile option set to No and you must enter it manually. If this option is set to Yes, the legal entity identifier is generated automatically based on the International Organization for Standardization (ISO) code of the country of registration, plus the registration number of the identifying jurisdiction, which qualifies an entity to be a legal entity in that particular territory.
Example:
Territory: Singapore
ISO Country Code: SG
Registration number of the identifying jurisdiction (RCN number) = 23231 (this is a user enterable field)

If the profile option is set to Yes, the legal entity identifier will be SG23231, otherwise you are required to enter the legal entity identifier manually. If you enter an identifier that is not unique, an error message will be displayed.

Registration Number:
The identifying jurisdiction determines the prompt for the registration number (in the U.S., the EIN/TIN). The Establishment registration prompt is displayed if it is defined for the identifying jurisdiction. In this case the main establishment is created with this registration number. The registration number must be unique within a jurisdiction.

Legal Address:
A Legal Address is the address a legal entity uses to register with a legal authority. A legal entity may use different addresses for different authorities and hence, may have more than one registered address. This legal address must be located within the territory governed by the legal authority.

Oracle Legal Entity Configurator has adopted the use of the HR Address formatting and validation Model

Place Of Registration: Optionally enter the place of the legal entity registration.
Inception Date Optionally enter the date of legal entity registration (creation). It can be on or before the system date and on or after legal entity's inception date but must not be a future date.

Source: My OracleSupport:
Note:396752.1Oracle Legal Entity Configurator Documentation Resources, Release 12
NOTE:1104887.1 - How to Setup a Legal Address Using HR Address Formats in R12 Legal Entity Configurator

How are the Transactions populated in the RA Interface table

2010-11-20T22:54:00.010-05:00

Invoice processing in Order Management is the process by which data from Orders and Returns is interfaced to Oracle Receivables.

1. After shipping the order, the order lines get eligible to get transferred to RA_INTERFACE_LINES_ALL.
2. Workflow background engine picks those records and post it to RA_INTERFACE_LINES_ALL. This is also called Receivables interface that mean information moved to accounting area for invoicing details.
3. Invoicing workflow activity transfers shipped item information to Oracle Receivables. At the same time records also goes in the table RA_INTERFACE_SALESCREDITS_ALL which hold details of sales credit for the particular order.
4. Sales order line status is closed and shipping line status is interfaced then RA_INTERFACE table will get populated.
5. Once all the data is in ra_interface_lines_all, Then Auto-invoice program imports data from this table which get affected into this stage are receivables base table. At the same time records goes in ra_customer_trx_all and ra_customer_trx_lines_all.

The Order Management Invoice Interface activity interfaces sales order line details to Oracle Receivables. Order lines with any of the following conditions are not eligible for Invoice interface:
1. Item with Invoiceable attribute set to No or
2. Item with Enabled Invoicing attribute set to No or
3. Included item type or
4. Configure item type or
5. Item inactivated.

For all conditions listed above, the Invoice Interface workflow activity is completed with a status of Not Eligible.

i) Order Hold: Order or return lines will not be interfaced to Oracle Receivables if there is a hold on the line or on the order. When the invoice interface activity encounters an order or return line with a status of On Hold, the Invoice Interface workflow activity will also complete with a status of On Hold. You can perform the manual ‘Progress Order’ concurrent program to continue with the order processing, or the order or return line will automatically be re-evaluated at a 12 hour interval after the hold is released.

ii) Detailed Flow Statuses for Invoice Interface:
These statuses/messages help you understand when the line is not progressed from invoice interface because of a specific reason.

When using the header level invoice interface, the order flow status is set to identify the Header invoice workflow status. For the header level only, the following statuses are set:
- Awaiting Invoice Interface -- On Hold
i) When at least one order line/header is on hold
- Awaiting Invoice Interface -- Incomplete Data
i) When at least one order line is not able to process due to incomplete data
-Invoice Interface – Complete
i) When all the lines are processed.

R12 Decision To Re-implement or Upgrade

2010-09-30T15:43:00.049-04:00

The information below offers best practices and advice to customers currently in 11.5.X who are not able to take decision to upgrade or re-Implement and who are in dilemma. After going through these details they can understand the benefits, pro and cons and decide either to upgrade or re-implement based on the business goals and requirements.

R12 is the latest and most advanced version of the E-Business Suite running on Fusion Middleware. Many of the technology components and new features in R12 will carry over to the Fusion Applications. For customers running earlier release of 11i, upgrading/Re-implementation to R12 will allow you to move to the Fusion Architecture in an incremental manner. Here are a few things to consider for R12

If you are moving from an existing release of Oracle E-Business Suite to Release 12, you should consider whether to perform a standard upgrade versus a reimplementation.

Let us understand the definition of Re-implementation and Upgrade.

Re-Implementation: If the legacy system from which you migrate your historical data is an earlier release of the E-Business Suite (i.e. Treat Current System as Legacy System) then your fresh implementation may be described as a “reimplementation”.

-Setup applications.

-Migrate data

-Migrate customizations

-Go live with small data

-Phased conversion of remaining data

Upgrade: Use of a process or Oracle Tool kit to ‘convert’ data from current Oracle Applications release to R12.

- Supported tools, utilities, and documentation used

- Entire data and application available after upgrade

- Clear, straightforward, proven method

Source: My Oracle Support
Note: Extended Support for Release 11i10 requires the minimum baseline patches defined in My Oracle Support Document 883202.1(Minimum Baseline Patch Requirements for Extended Support on Oracle E-Business Suite 11.5.10).

EBS Release Road Map:

Source:oracle open world/stevenChan

Release 12, which became available in January 2007, included major architectural improvements to the Financials products to support global and shared service operations, improve operational efficiencies, and reduce risk. It also incorporated the latest revisions to Oracle’s middleware and database technologies.

Release 12.1, which became available in May 2009, rounds out Release 12 with significant enhancements to the other product areas, including Procurement, Supply Chain Management, Human Capital Management, Customer Relationship Management and Master Data Management. It also contains usability improvements and centralized life cycle management.

There are few customers who are still in dilemma and not able to decide to go with Upgrade or re-Implementation but few customer based on the business goals and requirements have decided In favor of re-implementation and few in favor of upgrade

Gartner, the IT research and advisory firm, published research in February 2009 that advised caution and careful planning for the 11i to R12 transition. They found some customers experienced problems due to the architectural changes in the Financials, both with the end state software and with the transitional upgrade process. The paper recognizes that customers may use reimplementation as an opportunity to make fundamental changes to the configuration setups. “In a reimplementation, the user wants to leverage the new global financials functionality and may therefore revisit the whole conceptual design of their financials implementation.”

R12 has several important new capabilities, but this doesn't mean all customers should start planning an upgrade/Re-implement now. Existing customers should use the decision Criteria parameters to plan when they should consider moving to R12.

Decision Criteria:
- Current Oracle EBS Version.
- Oracle Skills
- Geographic’s Focus
- Legal Compliance and Market Force
- Implementation Scope
- Customizations
- Fusion Middle ware
- Risk Aversion
: Source: Gartner

Why should Companies move to R12:
- Stay in Oracle Support to eliminate the de-support risk since older versions of Oracle EBS applications are not supported by Oracle Suppoort.
- Obtain better support when patches currently.
- Take advantage of Tech Stack improvements.
- Change in business directions.
- New Features and functionalities to assist business
- Replicate customization with oracle standard features and retire RICE components
Get Ready for Fusion.

Driving Factors:
- IT Drivers: Supportability, Stability, Improved performance, New Features, Reduce , maintenance cost, Out of box use, Retire Customizations.

- Business Drivers: New modules, New features and functionality, New requirements, Operational efficiency, Design improvements, Opportunity to re-engineer,More business-handling Capabilities.

Upgrade vs Reimplementation:

Before suggesting any approach or its pros and cons we should understand the requirments, Issues and business goals by raising few questions like.
1. What are the issue in the current 11i Version.
2. What is the scope of the resounces availability
3. What are the key reasons to go to R12.
4. What is the budget.
5. What is the scope of the Project (any new additions to the business , any additions to the existing modules).

In upgrade if there are more number of customizations then it will take more time, oracle provided scripts for the entire standard /seeded components, the customization requires careful planning and development effort for non standard components. In Re-Implementation , taking the advantage of new features and functionalities customer have the opportunity to improve upon the existing components either by eliminating or retiring few of the RICE components.

Upgrade:

Pros:

- Least Expense option
- Less Implementation time with low customization
- Shared services will work as prescribed
- No Major Process changes
- No changes to COA, Currency, Calendar
- No major Business/organizational restructuring
- No Data conversion.
- Small team compared to re-Implementation.

Cons:

-User Interface overhaul will change to look and feel of the application.
-Limited ability to change configuration.
-Certain Modules have significant modifications and enhancements
-Critical upgrade issues require oracle support for fix/solution.
- Reporting tools have been impacted hence Technical/Development cost will increase.
- Have to leave with existing Issues.
- Continue use of Tax code.
- May not be able to use the new tax accounting and compliance model (EBtax).

Re-Implementation:
Pros:
1. Reconfigure of existing Process hence opportunity to correct mistakes and optimize process.
2. Opportunity to cleanup existing bad data.
3. Opportunity to change configuration may improve data quality and optimize process.
4. Opportunity to use new features and functionalities there by reduces issues.
5. Avoid catch-up Patching.
6. Opportunity to eliminate /retire RICE componets by using addded features and functionalites and centralized architecture .

Cons:
1. Implementation Time will be high.
2. Expensive cost option (Training/Development/Resource/tesing etc)
3. Configuration time willl be high
4. Data convertion would be required.
5. Big team size compared to Upgrade.
6. Most complicated and Resource intensive option.

Options available:

Stay put on 11.5.10, Not Ready for R12.X. Do not see the business benefits to upgrade . Delay and hope that 11i supported will be extended for another 2 – 3 years as the deadline comes closer. Ready to pay higher support cost for extended support as applicable..( 20 % to 25 % extra license fee post Nov 2012 ).
Ready for upgrade: Treat it as a necessary level. Do a Technical Upgrade with minimum cost and least disruption.
Embrace R12.X, as a Functional Upgrade; Treat it as a stepping-stone to Fusion. Adopt new processes, fusion middleware and new R12.X modules as applicable.
Re-implement to R12.X. Look to adopt more out of box solutions. Treat it as a Re-engineering exercise and simplifying business processes.
Expanding your Foot Print: You want to add more EBS Products to your footprint :Oracle recommends to move to the higher version R12.1.3 frist as there would be number of new features and change to data model and then implement the new Product.

Refer the following documents for more information on oracle my support:
1104163.1 - R12.1 Financials Pre-Upgrade, Setup, and Operational Tips
889733.1 - R12: Upgrade Considerations by Product (FINANCIALS)
987516.1 - Planning Your Oracle E-Business Suite Upgrade from Release 11i to Release 12.1
954704.1 - EBS: R12.1 Oracle Financials Recommended Patches
1127593.1 - R12.1: Oracle Financials Pre-Upgrade Patch Supplemental List for EBS CUP
•394692.1 -Oracle Applications Documentation Resources, Release 12

780989.1 -R12: Upgrade vs. Reimplementation (Financials)
1098650.1 Oracle E-Business Suite Technology Stack Release Notes for Release 12.1.3
•1080973.1 Oracle E-Business Suite Release 12.1.3
Upgrade Advisor: Oracle E-Business Suite Financials and Projects Upgrade from 11.5.10.2 to 12.1.3 and 12.1.2 [ID 256.1]
394692.1-Oracle Applications Documentation Resources, Release 12
747735.1 - Oracle Financials and Oracle Procurement: Functional Upgrade Guide: Release 11i to Release 12
806593 1 – R12 1 Info Supply
•806593.1 R12.1 Center
398877.1 – R12.1 Live Advisor
804373.1 – R12.1 Value Proposition documents
461709.1- Oracle E-Business Suite Upgrade Guide
557869.1 -EBS: R12.0 ORACLE FINANCIALS CRITICAL AND RECOMMENDED PATCHES
405627.1- Oracle Payables Release 12 Known Issues
549024.1 -11i Payment Documents Do not Exist in R12--How to create the payment documents from 11i data
578232.1-R12 Proactive Intelligence Center: Oracle Payables
471418.1-Oracle Payments Minimum/Dummy Setup For Direct Debit Funds Capture Processing
399362.1-Oracle Applications Release 12 Upgrade Sizing and Best Practices.
418649.1 -Advanced Global Intercompany (AGIS) in Release 12 - Setup, Transaction Processing and Reports
552745.1 R12: Unable to Update Location Address for Locations Created in Accounting Setups In GL
415529.1 R12: Unable to See the Legal Entity List of Value in the Bank Account Owner Field
•B31566-01-Oracle Applications Upgrade Guide: Release 11i to Release 12
810443.1 of the R12 E-Business Tax (EBTax) Upgrade for Order to Cash
733855.1 Inventory Structure (Chapter 2: R12 Inventory User's Guide in a Note)
463997 .1R12 New Business Group Not Shown in LOV when attempting to create Organization
784666.1TECHNICAL AND OPERATIONAL STANDARDS
987097.1 E-Business Suite Manufacturing Standalone Documentation - Release 12.1

Cost of Goods Sold Account

2010-07-30T15:58:00.010-04:00

What is Cost of Good Account:

The Cost of Goods Sold Account is used to determine the profit realized from selling a product. For each item in an inventory organization Oracle Applications has the ability to record the type and amount of costs to maintain the item. To view the associated cost for an item use the Item Costs Details form.
- Generate Cost of Goods Sold Account
- OM: Generate Cost of Goods Sold Account Both processes are used to derive account for cost of good sold (COGS). The workflow process will kick in when an item is shipped or returned.
- Generate Cost of Goods Sold Account the old process of 10.7 Oracle Shipping owns this process,
- OM: Generate Cost of Goods Sold Account is new and default process for 11i, Order Management owns this process.

• Inventory COGS Account Generator
– Item Type = INVFLXWF
– Display Name = ‘Inventory Cost of Goods Sold Account’
– Run by the concurrent program ‘Create Intercompany AP Invoices’, short name INCIAP

• OM COGS Account Generator
– Item Type = OECOGS
– Display Name = ‘OM : Generate Cost of Goods Sold Account’
– Run by the concurrent program ‘Interface Trip Stop’, short name WSHINTERFACE

Seeded Account Generators:

11i10 provides the ability to register custom processes for the following account generators:

OM: Generate Cost of Goods Sold Account (OECOGS) – generates the cost of goods sold
account when invoices imported into AR.
PO Account Generator (POWFPOAG) – used by Purchasing to derive the charge, budget,variance, and accrual accounting distributions for each PO line – MUST be customized ifusing Oracle Projects.
PO Requisition Account Generator (POWFRQAG) – used by Purchasing to derive thecharge, budget, variance, and accrual accounting distributions for each requisition line –MUST be customized if using Oracle Projects.
Inventory Cost of Goods Sold Account (INVFLXWF) – called while processingIntercompany Transactions.
Generate Cost of Goods Sold Account (SHPFLXWF) – Pre-11i Cost of Goods Sold AccountGenerator – see Metalink note 260697.1
AR: Substitute Balancing Segment (ARSBALSG) – updates the balancing segment duringvarious accounting activities against transactions and receipts.
PSB Account Generator for OLD Integration (PSBLDMAG) – Public Sector Budgeting –
used to derive accounts for positions with POETA charging instructions that are then
used to import salary distribution information from LD.
ITR Account Generator (ITRWKFAG) – Account Generator for self-service ITR. This
workflow will build creation and receiving accounts for ITR service lines.
IAC account Generator (IGIIACWF) – used in Public Sector Assets.
MHCA Account Generator (IGIAMAWF) – used in Public Sector Assets.
IGC Charge Account Generator (IGCACGNC) – Public Sector Contracts, this workflow is
used to generate charge account for contract commitment.
IGC Budget Account Generator (IGCACGNB) – Public Sector Contracts, this workflow is
used to generate charge account for contract commitment.
Project Budget Account Generation (PABDACWF) – used by Projects to generate
accounting combinations for all budget items in an integrated project budget.
FA Account Generator (FAFLEXWF) – used by Assets to generate the accountingcombinations for each asset transaction.
Project Supplier Invoice Account Generation (PAAPINVW) – used by Payables to derivethe invoice distribution accounting combination if the distribution is Project related –MUST be customized.
Project Web Employees Account Generator (PAAPWEBX)– used by iExpenses to deriveaccounting combinations for expense report lines that reference a project – MUST becustomized.

Days sales Outstanding(DSO)

2010-03-21T01:50:00.006-04:00

Days Sales Outstanding :
A measure of the average number of days that a company takes to collect revenue after a sale has been made. A low DSO number means that it takes a company fewer days to collect its accounts receivable. A high DSO number shows that a company is selling its product to customers on credit and taking longer to collect money.

Days sales outstanding is calculated as:

Accounts Receivables
= __________________ X Number of Days
Total Credit Sales

Conventional DSO = (Total outstanding receivables/Total sales for prior DSO days) * (DSO days)

OR

DSO FORMULA:
============

DSO = (TOTAL RECEIVABLES * System Option Value) / TOTAL SALES

Total outstanding receivables is calculated as sum of ACCTD_AMOUNT_DUE_REMAINING from payment schedule for classes 'INV', 'DM', 'CB','DEP' and 'BR'. The sum does NOT include ACCTD_AMOUNT_DUE_REMAINING for classes 'CM','GUAR' and 'PMT'..The same is true while calculating total sales for last DSO days.

The way you can use this column is to know how many days are in your period definition in System Options. If it is defined at 90 days, you as a collector should be able to divide this number by the DSO and know there has not been any purchases on the account for quite some time. Based uponthe functional balance due and the DSO column, they higher this number, the longer it's been since a sale was made to this customer.

This column is used as an indication of how delinquent a customer is and how frequent sales are made. The higher the number, the less sales in the number of DSO days you have set in the System Options. If this number is low, this is a indication the customer is a frequent buyer as well as current on payments.

Script for Days Sales Outstanding (DSO) :
==================================
In order to make sure that the value displayed is correct:

exec fnd_client_info.set_org_context(&org_id);

TOTAL OUTSTANDING AMOUNT:
=========================
select
SUM( DECODE(PS.CLASS, 'INV', 1,'DM',1, CB',1,'DEP',1, 'BR',1, 0)
* PS.ACCTD_AMOUNT_DUE_REMAINING ) * MAX(SP.CER_DSO_DAYS)
TOTAL_BALANCE_DUE,SUM( DECODE(PS.CLASS, 'INV', 1, 'DM', 1, 'CB', 1, DEP', 1, 'BR', 1, /* 10-MAR-2010 Implementation */ 0) * DECODE(SIGN (TRUNC(SYSDATE) - PS.TRX_DATE - SP.CER_DSO_DAYS), - 1, (PS.AMOUNT_DUE_ORIGINAL + NVL PS.AMOUNT_ADJUSTED,0)) * NVL( PS.EXCHANGE_RATE, 1 ), 0)) TOTAL_CREDIT_IN_DSO_DAYS, MAX(SP.CER_DSO_DAYS) DSO_DAYS
from
ar_payment_schedules ps,
ar_system_parameters sp
where
customer_id = &customer_id;

If the user was querying the Customer Accounts form based on customer and site then add the following where clause to the above sql :" and customer_site_use_id = &site_use_id".

The above script will give you the values for TOTAL_BALANCE_DUE and TOTAL_CREDIT_IN_DSO_DAYS.

To get the DSO value use the formula:

TOTAL_BALANCE_DUE / TOTAL_CREDIT_IN_DSO_DAYS

Another way of finding the DSO value is to run the following:

TOTAL RECEIVABLES
=================
select
sum(acctd_amount_due_remaining)
from
ar_payment_schedules_all
where
class in ('INV', 'DM', 'CB','DEP', 'BR')
and
customer_id = &customer_id;

TOTAL SALES
===========
select
sum(unit_selling_price*quantity_invoiced)
from
ra_customer_trx_all rct,
ra_customer_trx_lines_all rctl
where
rct.customer_trx_id = rctl.customer_trx_id
and
rct.bill_to_customer_id = &customer_id
and
trunc(trx_date) >=trunc(SYSDATE) -;

The System Option Value is the Number of Days defined in System Options (Miscellaneous tab) for the field Days in Days Sales Outstanding Calculation.

Currency Default using defaulting Rules

2010-02-28T14:54:00.029-05:00

Default USD Currency in Order Management for ABC Customers in ABC Operating Unit.

Define defaulting rules to determine the source and prioritization for defaulting order information to reduce the amount of information you must enter manually in the Sales Orders window.

You can create rules to determine the source and prioritization for defaulting order information to the Sales Orders window. Modifications to defaulting rules take effect for any new orders when you reopen the window

A defaulting rule is a value that OM automatically places in an order field of the sales order window. Defaulting rules reduce the amount of information one must enter. A defaulting rule is a collection of defaulting sources for objects and their attributes.

A defaulting rule includes these components:

Defaulting Conditions-Defaulting conditions are evaluated at run time to select the appropriate default source assignments of for all the object attributes
Sequence: the priority in which you want to retrieve the default for this attribute.
Source:
Entity: a region on the window
Attribute: individual fields of a particular entity.
Value: a constant defaulting value instead of a field that contains a value.
Defaulting Source/Value - Profile Option, constant value.

Responsibility: Order Management Super User
Navigation: Setup > Rules > Defaulting

Query for the Application: Order Management
Entity: Order Header

Put the Cursor on the attribute: Customer and click Defaulting Condition Template

Enter the Validation Temple Condition Name : CN USD Customers
Description : Canadian Customer Invoiced in USD
Enter the Validation Rules
Group#:1
Attribute: Customer
Validation Operation: =
Click Value String and enter the sold to customer (Note the customer#)

Defaulting Flex Field is displayed .

Put the Cursor on the attribute: Currency and click Attribute Defaulting Rule
Defaulting Condition:
Precedence:1
Defaulting Condition: Canada US Customers
Defaulting sourcing rule:
Sequence:1
Source Type: Constant Value
Default Source/Value: USD

Save the form and run the Generate Defaulting handler Package (Tools > Generate Defaulting Handler Package) a note is displayed as given below and a Default Generator concurrent job is run.

you will get a message given below click OK

click OK you will get a note message given blow:

click OK

Create a Order of the customer default currency will CAN as soon you enter the customer# in the order form the currency changes to USD.

Consolidation (GCS, HFM, FCH)

2010-01-31T11:24:00.017-05:00

Consolidation:

Consolidation is the period–end process of combining the financial results of separate subsidiaries with the parent company to form a single, combined statement of financial results.

GCS is a multi-source consolidation solution that can accumulate information from diverse financial systems, geographic locations, including Oracle and non-Oracle Applications. With GCS one can consolidate data from multiple SOBs, multiple instances and non-Oracle applications.

With Oracle General Ledger, you can consolidate any number of subsidiaries into parents represented by different sets of books – even those with different Chart of accounts, Currencies and Calendars.

•Consolidation of companies within a Set of books.
•Consolidation of companies across multiple Sets of Books in the same instance.
•Consolidation of companies across multiple Sets of Books across multiple instances.
•Accounting for some companies is maintained in non-Oracle applications.

What you can Consolidate:

1) Chart of Accounts: Map any subsidiary chart of accounts structure into your consolidated parent,regardless of differences in the account structure.
2) Level of Detail: Consolidate detail transactions, detail balances, or summary balances.
Balance Type: Consolidate actual, average, translated, budget, and statistical balances.
3) Calendar: Use any accounting calendar for the parent set of books into which you consolidate your subsidiaries.
4) Currency: Maintain subsidiary sets of books in a different currency than your parent. Simply revalue and translate balances as needed before transferring consolidation data to your parent.

GL Consolidation Steps:

1.Create Consolidation mapping: parent and subsidiary sets of books.
2.Post all Journals in subsidiary set of books.
3.Revalue foreign currency balances in subsidiary sets of books.
4.Translate subsidiary balances to the functional currency of parent set of books
5.Run and review trial balance report.
6.Transfer data from subsidiary to parent.
7.Run Journal import.
8.Post the consolidation journal in parent set of books.
9.Eliminate intercompany balances.
10.Run trial balance and other financial reports.

Steps to perform consolidation:

1.Map Consolidation Data.
2.Prepare Consolidation Data.
3.Transfer Consolidation Data.
4.Review and Post consolidation JE.
5.Generate and review eliminating Entries.
6.Report on Consolidated balances.
7.Analyze Consolidated Results.

Consolidation workbench:
The Consolidation Workbench provides a central point of control for consolidating an unlimited number of subsidiaries to your parent, while keeping you informed about each subsidiary’s consolidation status. The workbench also monitors subsidiary account balances for any changes that occur after the subsidiary data has already been transferred to your parent set of books.

Functional Step State Controller Buttons
Map Consolidation Data -- Mapping, Mapping Set
Prepare Subsidiary Data -- Translation Status
Transfer Consolidation Data --Transfer, Transfer Set
Post Consolidation Data -- Review Journal, Post
Eliminating Entries -- Eliminate, Elimination Set
Report on Consolidated Balances --Report

Consolidation Process:

1.Define Consolidation Charts of Accounts: Make sure your parent and subsidiary charts of accounts can help simplify the consolidation process.
2.Map Consolidation Data: The first step in an actual consolidation is to define how your subsidiary accounts map to your parent accounts. The mapping determines how your subsidiary balances roll up into the consolidated ledger.
3.Prepare Consolidation Data: You should revalue and translate any foreign currency amounts from your subsidiaries before consolidating them to the parent set of books.
4.Transfer Consolidation Data: Once your subsidiary data has been prepared, transfer it to the parent, where it will be consolidated.

Preparing Consolidation Data:

1.Revalue Balances: if any sets of books have balance sheet or income statement accounts denomination in a foreign currency.
2.Translate Balances: for any subsidiary books that use a functional currency that differs from the parent.
3.Run a trial balance: for each subsidiary set of books using the parent set of books functional currency.
4.Review: subsidiary balances before transferring them to the parent.

Foreign Currency Concept:
There are 3 Concepts in Oracle General Ledger that pertains to foreign Currency

Conversion: conversion refers to foreign currency transactions that are immediately converted at the time of entry to the functional currency of the set of books in which the transaction takes place.
Revaluation: Revaluation adjusts liability or asset accounts that may be understated or overstated at the end of a period due to a significant fluctuation in the exchange rate between the time the transaction was entered and the end of the period. It restates balances using proper period end rate.
Translation: Translation refers to the act of restating an entire set of books or balances for a company from the functional currency to a foreign currency.

Consolidation Methods
When the consolidation is run, consolidation journal entries are created in the parent set of books for all the subsidiaries selected.

•If you choose the Balances method, the resulting consolidation journal will include the account balances for all the subsidiaries that were run.
For example, if a subsidiary had five transactions that made up the balance of the sales account, the consolidation journal entry will include the balance of the sales account, and not the individual transactions (based on the mapping rules).

• If choose the Transactions method, the resulting consolidation journal will include the transactions for all the subsidiaries that were run.
For example, if a subsidiary had 5 transactions for the sales account, the consolidation journal entry will include each transaction.

When a Consolidation is run, Oracle General Ledger submits a Concurrent process that populates the GL_INTERFACE table with Consolidation data.

The table below lists all possible statuses for consolidation processes displayed in the status column.

Reports:

Use the FSG as the mechanism to sum up the subsidiaries to produce consolidated results in case of Single SOB.
In case of companies having multiple SOB / non-Oracle Application, use FSG to report on consolidated results.
Use the ADI to extend reporting to the spreadsheet environment. ADI allows to create and publish consolidated reports in HTML format to the Internet or corporate intranet.
Run a Trial Balance Report for each subsidiary after revaluation and translation.
Consolidation Rules Report.
Consolidation Unmapped Subsidiary Report
Disabled Parent Accounts Report.
Consolidation Rules Report.
Consolidation Journals Report.
Consolidation Audit Report.
FSG reports.

Oracle Hyperion Financial Management (HFM) is a financial consolidation and reporting application built with advanced Web technology, but used and maintained by the finance team. It provides financial managers the ability to rapidly close and report financial results, meet global regulatory requirements, reduce the cost of compliance and deliver confidence in the numbers.

Features:

•Simple to Customize
•Easy to Integrate
•Financial Data Quality
•Complete Audit Trails
•Flexible Workflow
•Powerful Reporting
•Finance owned & operated

Benefits:

•Confidence in the numbers
•Reduce cycle time
•Automate collection & validation
•Lower cost of compliance
•Speed and agility

Oracle Financial Consolidation Hub: (OFCH/FCH)
Oracle Financial Consolidation Hub is a key component of Oracle Corporate Performance Management, a comprehensive solution for improving performance across your business

OFCH is
•A comprehensive consolidation and reporting solution that brings together financial data from different sources to create a single, global view of financial information across the entire enterprise.
•A critical bridge between traditional financial applications and analytic applications by using Enterprise Planning and Budgeting

FCH Features:

Data collection from different sources
Automated consolidation processing
Flexible eliminations and calculations
Acquisition and disposal handling
Multi-dimensional reporting and analysis
Consolidation dashboard

FCH Big Picture:

Source: My OracleSupport

Accounting Method Builder (AMB) ,Event Classes and Event Types

2009-12-26T22:29:00.029-05:00

Subledger Accounting is a new set of tools, accounting engines and repsoitory. Accounting Method Builder is a part of Subleger accounting.

Accounting Methods Builder:

Toolset to define Journal Entry rules for the transactions and events of a subledger application.
Allows defining multiple sets of rules to be used concurrently for different requirements.

How Accounting Methods Builder works Journals are split into three main components:
1.Description
2.Line Types
3. Account Derivation Rules.

Event:
Subledger Accounting introduces the concept of events for the transactions. An event is the recording of a change of status in the transaction life cycle (for example, an invoice has been approved, a payment has been cancelled, a period has been closed, etc.). This is a fundamental component of the design to allow a clear separation between transactions and their accounting representations.Since events are the bridge between the transactions and the journal entries.

Event Model: Definition of the subledger transactions types and lifecyle.
Event Class: Classifies transaction types for accounting rule purposes.

Payables - Invoice, Debit Memo, Prepayment, Payments, Refunds.

Receivables - Invoice, Deposit, Receipt and Bill Receivables.

Purchasing - Requistion, Purchase Order.

Event Type: Accounting event types represent the business operations that can be performed on the event class. An accounting event always has an associated event type.

For each transaction type, defines possible actions with accounting singnificance.

- Payables Invoice - Validated, Adjusted, Cancelled.

-Receipt - Created, Applied , Unapplied , Updated , Reversed. Adjusted.

-Purchase Order - Created, Distributed, Cancelled, Rejected, Finally Completed.

Oracle Subledger Accounting introduces a new Subledger Accounting Rules Detail Listing Report to provide detailed information about accounting rules defined for a subledger accounting method. The report can be submitted from the individual subledger applications or from Oracle General Ledger.
In addition, the report can be submitted for custom applications registered within Oracle Financial Accounting Hub.Users can now use the new report to easily review the following setup details:
• Subledger Accounting Method
• Journal Line Definition
• Journal Line Type
• Account Derivation Rule
• Journal Header Description
• Journal Line Description.

R12.1.X New Features

2009-12-22T22:50:00.004-05:00

Ledger Architecture
- Ledgers: Define by Chart of Accounts, Calendars, Currency and Accounting Conventions.
- Ledger Sets: Group of Ledgers sharing the Same Chart of Accounts and Currency.

Centralized and Flexible Rules based Accounting Engine
- Ruled based engine with configurable accounting rules
- Single source of truth for accounting, reconciliation and reporting with common data model and repository and posting engine.
- Consistent data model and user interface across all subledgers.

Centralized Legal Entity Management
- Manage Legal Corporate Structure
- Link tax, intercompany, bank account and accounting functions
- Isolate legal compliance issues at legal entity from the management and security issues at operating Unit.

Centralized Banking and Payments
-Single user interface for all setup and maintenance related to banks and internal bank accounts.
-Centralized management of all funds capture and disbursements
-Centralized credit card management.

Centralized Global Tax Processing
-Centralized Tax Engine with single data model for rules and transations across geographes and applications
-Centralized tax repository for global visibility
-Simplified tax configuration across legal entities and oracle apps.

Advanced Global Intercompany system
- Centralized intercompany and intracompany accounts setup
- Fully configurable approval rules and invoicing options.
- Physical Payables and Receivables intercompany invoice generation.

Oracle General Ledger:

- Single Page for all accounting setup with Accounting Setup Manager.
- Prevent Accounting errors with Alternate accounts
-Replacement for Disabled Accounts
-Prevent unauthrized posting with Control Accounts
-Simplify security and Data Access and Definition Access sets.
-Sequential numbering of accounting entries
-Journal line reconciliation-Journal Batch Copy
-Historical Data initialization for new reporting currencies and secondary ledgers.

Oracle Payables:

- Pay on behalf of a different party with 3rd party payments
- Greater flexibility in defining and calculating discounts for quick payments.
-Application of withholding taxes at time of invoice validation and during payment
-Improved resolution for dispute processing with suppliers.
-Imporve invoice data entry and management with line level entry, approval, matching and tax calculation.
-Automated netting of Customer and Supplier balance
-Self-Service invoivce allows employees and suppliers to enter various invoice type online.
-New interface and data model for supplier managment in TCA.

Oracle Receivables:
-Streamlined receipt porcessing with cash application work queue.
-Enhanced performance for high volume receivables processing.
-Synchronize Cost of Goods Sold(COGS) with Revenue.
-Increased efficiency with line level cash application.
-Improved billing communcation with balance forward billing.
-Create standard late charge polices that can be assigned to customer accounts or account sites.

Oracle Advanced Collections:
- Assign bankruptcy status at the customer level
- Effetively manage later stage delinquency status assignment at case and contract level.
- Internal only comment visibility for dispute processing.
- Streamline system setup and operational maintenance with implementation checklist.
-Consolidation of collections features provides collections workbench
-Improved ability to collect with enhanced dispute management.

Oracle Assets:
- Flexible accounting configuration
- Automated depreciation rollback for selected assets
- Enhanced mass additions interface for legacy conversions
- Unplanned depreciation(impairments) for energy industry
- Unit of production and straight line depreciation methods for O&G industry.
- Flexible reporting with BI Publisher.

Source: My Oracle support

Auto Invoice Performance Improvement

2009-12-21T23:21:00.010-05:00

Setup Considerations for Performance:
===============================
System Options Setup
-Log File Message Level-Message Level 0 shows the following in the log file:

Product Name & Version
AutoInvoice Start Time, End Time, & Logical Steps
AutoInvoice Concurrent Request Arguments
Error and Warning Messages

-Message Level 1 shows time stamped function labels plus all of the above.
-Message Level 2 shows above entries plus:

Sizes of Allocated Arrays ,Dynamic SQL Statements , Number of Rows Updated, Inserted and Deleted

-Message Level 3 shows above plus Method IV SQL Array Values

Scenarios: You have number of transactions in the AR Interface table which are ready to get invoiced for the source order Management, you have run the auto invoice program and the process is taking long time to complete e.g more then 6 hrs for 3000 lines . What do you do and how do you improve the performance of the Auto invoice program.

To increase performance during the validation portion of AutoInvoice:

NOTE: You may want to back up this table before truncating if you need to review prior errors. Errors will be re-submitted into this table from any unprocessed invoice lines

Ensure that all indexes for the transaction flexfield are set up i.e indexes should be created on Transaction Flexfield columns.

Unique, concatenated indexes should be created on the following tables and columns:

RA_CUSTOMER_TRX_ALL
RA_CUSTOMER_TRX_LINES_ALL
RA_INTERFACE_LINES_ALL
RA_INTERFACE_DISTRIBUTIONS_ALL
RA_INTERFACE_SALESCREDITS_ALL
OE_ORDER_LINES_ALL

1.Truncate the table RA_INTERFACE_ERRORS_ALL.

sql> connect AR/AR

sql> truncate table RA_INTERFACE_ERRORS_ALL;

2. If your Line Transaction Flexfield is ORDER ENTRY. You need to create indexes for ALL columns used in the Line Transaction Flexfield.

First, drop existing custom indexes if you have any:

sql> drop index XXX_RA_CUSTOMER_TRX_LINES_A1;

sql> drop index XXX_RA_INTERFACE_LINES_A2;

Second, create the following indexes:

NOTE:You can use CREATE INDEX instead of CREATE UNIQUEINDEX if necessary.

SQL> CONNECT AR/AR

SQL> CREATE UNIQUE INDEX XX_RA_CUST_TRX_U1 ON RA_CUSTOMER_TRX_ALL (INTERFACE_HEADER_CONTEXT, INTERFACE_HEADER_ATTRIBUTE1, INTERFACE_HEADER_ATTRIBUTE2, INTERFACE_HEADER_ATTRIBUTE3, INTERFACE_HEADER_ATTRIBUTE4, INTERFACE_HEADER_ATTRIBUTE5, INTERFACE_HEADER_ATTRIBUTE6, INTERFACE_HEADER_ATTRIBUTE7, INTERFACE_HEADER_ATTRIBUTE8, INTERFACE_HEADER_ATTRIBUTE9, INTERFACE_HEADER_ATTRIBUTE10, INTERFACE_HEADER_ATTRIBUTE11, INTERFACE_HEADER_ATTRIBUTE12, INTERFACE_HEADER_ATTRIBUTE13, INTERFACE_HEADER_ATTRIBUTE14, INTERFACE_HEADER_ATTRIBUTE15);

SQL> CREATE UNIQUE INDEX XXX_RA_CUST_TRX_LINES_U1 ON RA_CUSTOMER_TRX_LINES_ALL (INTERFACE_LINE_CONTEXT, INTERFACE_LINE_ATTRIBUTE1, INTERFACE_LINE_ATTRIBUTE2, INTERFACE_LINE_ATTRIBUTE3, INTERFACE_LINE_ATTRIBUTE4, INTERFACE_LINE_ATTRIBUTE5, INTERFACE_LINE_ATTRIBUTE6, INTERFACE_LINE_ATTRIBUTE7, INTERFACE_LINE_ATTRIBUTE8, INTERFACE_LINE_ATTRIBUTE9, INTERFACE_LINE_ATTRIBUTE10, INTERFACE_LINE_ATTRIBUTE11, INTERFACE_LINE_ATTRIBUTE12, INTERFACE_LINE_ATTRIBUTE13, INTERFACE_LINE_ATTRIBUTE14, INTERFACE_LINE_ATTRIBUTE15);

SQL> CREATE UNIQUE INDEX XXX_RA_INT_LINES_U1 ON RA_INTERFACE_LINES_ALL (INTERFACE_LINE_CONTEXT, INTERFACE_LINE_ATTRIBUTE1, INTERFACE_LINE_ATTRIBUTE2, INTERFACE_LINE_ATTRIBUTE3, INTERFACE_LINE_ATTRIBUTE4, INTERFACE_LINE_ATTRIBUTE5, INTERFACE_LINE_ATTRIBUTE6, INTERFACE_LINE_ATTRIBUTE7, INTERFACE_LINE_ATTRIBUTE8, INTERFACE_LINE_ATTRIBUTE9, INTERFACE_LINE_ATTRIBUTE10, INTERFACE_LINE_ATTRIBUTE11, INTERFACE_LINE_ATTRIBUTE12, INTERFACE_LINE_ATTRIBUTE13, INTERFACE_LINE_ATTRIBUTE14, INTERFACE_LINE_ATTRIBUTE15);

SQL> CREATE UNIQUE INDEX XXX_RA_INT_DIST_U1 ON RA_INTERFACE_DISTRIBUTIONS_ALL (INTERFACE_LINE_CONTEXT, INTERFACE_LINE_ATTRIBUTE1, INTERFACE_LINE_ATTRIBUTE2, INTERFACE_LINE_ATTRIBUTE3, INTERFACE_LINE_ATTRIBUTE4, INTERFACE_LINE_ATTRIBUTE5, INTERFACE_LINE_ATTRIBUTE6, INTERFACE_LINE_ATTRIBUTE7, INTERFACE_LINE_ATTRIBUTE8, INTERFACE_LINE_ATTRIBUTE9, INTERFACE_LINE_ATTRIBUTE10, INTERFACE_LINE_ATTRIBUTE11, INTERFACE_LINE_ATTRIBUTE12, INTERFACE_LINE_ATTRIBUTE13, INTERFACE_LINE_ATTRIBUTE14, INTERFACE_LINE_ATTRIBUTE15);

SQL> CREATE UNIQUE INDEX XXX_RA_INT_SALESCREDITS_U1 ON RA_INTERFACE_SALESCREDITS_ALL (INTERFACE_LINE_CONTEXT, INTERFACE_LINE_ATTRIBUTE1, INTERFACE_LINE_ATTRIBUTE2, INTERFACE_LINE_ATTRIBUTE3, INTERFACE_LINE_ATTRIBUTE4, INTERFACE_LINE_ATTRIBUTE5, INTERFACE_LINE_ATTRIBUTE6, INTERFACE_LINE_ATTRIBUTE7, INTERFACE_LINE_ATTRIBUTE8, INTERFACE_LINE_ATTRIBUTE9, INTERFACE_LINE_ATTRIBUTE10, INTERFACE_LINE_ATTRIBUTE11, INTERFACE_LINE_ATTRIBUTE12, INTERFACE_LINE_ATTRIBUTE13, INTERFACE_LINE_ATTRIBUTE14, INTERFACE_LINE_ATTRIBUTE15);

Note: You only need to create the following indexes, if these tables are being populated with interface data. If you are not using sales credits or accounting distributions, then you do not need to create these indexes

SQL > create index ONT.OE_ORDER_LINES_A1 on ONT.OE_ORDER_LINES_ALL (to_char(line_id)) tablespace APPS_TS_TX_IDX;

3. Set the Log File Message Level = 1 Navigate to Setup > System > System Options and set this value = 1.

4. Set the Profile option AR:Maximum lines per AutoInvoice worker : 1000 (At Site level). Please set this to a value that approximates an even distribution of invoices lines per worker. For example if each invoice has approximately 800 to 1000+ lines and you process 5 invoices per Autoinvoice run (approximately 5000 invoice lines) you could set the value of this profile to 1000 which should distribute 1 invoice (800 to 1000+ lines) per worker, if you run with 5 workers. If you are unsure of the distribution, do NOT set this profile.

Note:

AutoInvoice inserts data into the tables, but never changes the data that is fed into the tables.
Review the RA_INTERFACE_ERRORS table for details on what is failing during import. Use this information to quickly search for known issues.
Review the Invalid Objects and Disabled Trigger Section to confirm correct setup.
Run Gather Schema Statistics from the SYSADMIN responsibility

5. If you do NOT see a performance gain after making these changes, Please raise an SR with Oracle Support and upload the log files and execution report from a run of Autoinvoice and the Auto invoice diagnostics script.

6. SQL Query to check the time taken to complete by Autoinvoice import prgram.

SELECT request_id, TO_CHAR(request_date,'DD-MON-YYYY') "Date", RPAD(user_concurrent_program_name,60) "Program Name", RPAD(argument_text,20) "Arg", RPAD(TO_CHAR(a.ACTUAL_START_DATE, 'hh24:mi:ss'),10) "Start", RPAD(TO_CHAR(a.ACTUAL_COMPLETION_DATE, 'hh24:mi:ss'),10) "End", RPAD(TO_CHAR( (TRUNC(SYSDATE) + ( a.ACTUAL_COMPLETION_DATE - a.ACTUAL_START_DATE)), 'hh24:mi:ss'),10) "Actual", c.user_name, status_code "S"FROM applsys.fnd_concurrent_requests a, applsys.fnd_concurrent_programs_tl b, apps.fnd_user cWHERE b.user_concurrent_program_name like 'Autoinvoice Import Program' AND a.concurrent_program_id = b.concurrent_program_id AND a.request_date >= 'DD-MON-YYYY' AND a.requested_by = c.user_idORDER BY request_id desc;

Note : 197213.1-Autoinvoice Performance Is Slow. Note:169935.1 - Troubleshooting Oracle ERP Apps Performance Issues.

Source: My OracleSupport

Oracle Application Patch Types

2009-12-13T14:49:00.022-05:00

Standalone (one-off) Patch:
Addresses a single fix or enhancement. Standalone patches are released only when there is an immediate need for a fix or enhancement that cannot wait until an aggregate bundling is available.The One-off patch category was common in the older versions R11 (11.0.x) and early releases of 11i. Typically, they fix single or isolated set of bugs.

Rollup Patch (RUP):
An aggregation of patches that may be at the functional level, or at a specific product/family release level. Roll-up patches are a special kind that started to become more common as 11i matured. They are collection of bugfixes for a specific product and relate to specific patchset level.

For example, a Receivables rollup patch contains all the latest patches related to Receivables at the time the patch was created. A Marketing Family 11.5.10 rollup patch contains all the latest Marketing patches released since, and applicable to, 11.5.10.

Product Patch sets /Minipack:
An aggregation of patches at the product level.Standalone patchsets were common in early releases of 11i. They can enhance functionality and typically fix a large number of bugs for a single product. Once a patchset is applied, it increments the patchset level of a product (the product is sometimes also referred to as module). There are around 250+ products integrated in EBS, and each product has specific patchset level. Minipacks are named in alphabetical sequence such as 11i.AR.M, 11i.AR.N 11i.AR.O, and so on.

Family Pack:
An aggregation of patches at the product family level. For example, Financials Family Pack G(11i.FIN_PF.G) contains all the latest patches for products in the Financials family at the time the family pack was created. Family product codes always end in "_PF" and family packs are given alphabetical sequence such as 11i.FIN_PF.E, 11i.FIN_PF.F and 11i.FIN_PF.G. Family packs are cumulative. Family packs are seta of product patchsets for a particular family (Financials, SCM, Project Suite, and so on). The family pack’s advantage is that the patchset levels were tested together, and should therefore be more stable.

Release Update Packs (R12) /Maintenance Pack:
An aggregation of patches for all products in the E-Business Suite. For example, Release 11.5.10 Maintenance Pack contains all the latest code level for all products at the time 11.5.10 was created. Maintenance packs are numbered sequentially such as 11.5.8, 11.5.9, 11.5.10, and are cumulative. In other words, 11.5.10 contains everything in 11.5.9, which contains everything in 11.5.8, and so on. Maintenance packs deliver a new version of a product. Unlike major release upgrades, maintenance packs change the release number, which is the third number in a version name (for 11i). They are still considered patches, but the changes they introduce are system-wide. Often they also bring in brand new products.

Diagnostic Patch:
Used to gather additional information when a product failure cannot be reproduced by Oracle. The additional information assists Oracle Support Services and Oracle Development in resolving the failure.

Interoperability Patch:
Allows Oracle Applications to function properly with a newer version of the technology stack. Interoperability patches are typically required with new versions of the database or Applications technology stack.

Translated Patch:
A non-English version of a patch. Release 11i supports 30 non-English languages. Customers who are using languages other than English, need to apply the corresponding translated patch(es) for the languages they are using in addition to any base US patch(es).

Merged Translation Patch:
Provided in real time (without requiring a translator) in the event a translated patch is not available when a customer needs it. A merged translation patch is applied just like a fully translated patch. The fully translated patch is escalated and is usually available within 24 hours. It can be applied safely on top of a merged translation patch.

Translation Fix:
Provided in the event a translation word choice is inappropriate. A translation fix is applied just like a translated patch, except there is no corresponding base US patch.

New Feature Patch:
Introduces new functionality and/or products. It is applied using standard patching utilities.

Consolidated Update (CU):
Improves and streamlines the upgrade and maintenance processes by consolidating certain post-release patches. Most recommended patches and rollups for a particular maintenance release are consolidated into a single patch that is installed immediately following application of a maintenance pack or a new installation of Rapid Install. Updates in the CU are predominantly error corrections.

Family Consolidated Upgrade Patch:
Consolidates all upgrade-related patches from all the products within a product family. Family consolidated upgrade patches are released as needed and are applicable only if you are upgrading to Oracle is now introducing a new method for patching, patch set updates, or PSU. According to Metalink notes 854428.1 and 850471.1, An Oracle PSU contains recommended bug fixes and "proactive" cumulative patches, a nice change that makes it simple for the DBA to chose to apply "priority" patches. Starting each quarter, Oracle Cumulative Patch Updates (CPU) will now contain both the PSU and CPU, so the DBA may choose to apply a whole CPU or only the selected patches in the PSU patch bundle.The naming conventions for CPU and PSU is the last-order digit, so it's easy to see of you are patching with CPU or PSU

The PSU supports Oracle's zero-downtime patching, a method for RAC databases whereby each node is patched independently with no downtime.

R12 Changes:

R12 introduces some new terms, codeline and codelevel and changes the meaning of several established terms.

Codeline:

This refers to a point release. Every codeline delivers a unique set of features. So release 12.0 is a understood as codeline A; release 12.1 is understood as codeline B; release 12.2 will be understood as codeline C, and so on.

Codelevel:

Codelevel can resemble patchset level from 11i. For each codeline, there can be a set of updates, which deliver mostly bugfixes and reflects the particular product codelevel after the codeline letter.

Example R12.AR.A.6 means Account Payables product on codeline A (Release 12.0) on codelevel 6 (Part of release 12.0.6).

The important thing to understand is that if you install a specific R12 release such as 12.0.6, all products will not only be on the same codeline (A), but also on the same codelevel (6). The codelevel is incremented via Release Update Packs

Recommended Patch List(RPL):

The Recommended Patch List (RPL) is a tool available via My Oracle Support (formerly called MetaLink), which provides a list of recommended patches pertaining to a selected Family Pack for all the EBS product families. The RPL is available for both 11i and R12 code lines.

The tool is been updated regularly in MySupport/Metalink by EBS development. The well-maintained data in the RPL helps you to easily identify the required patches for the patch set level. As the tool is being standardized across EBS product family, the HRMS patch information is also updated for 11i (FP.K Rup 1, 2 & 3) and R12 code lines. You can now use all the features of the RPL tool

Advantages of applying CPCs over one-off fixes and RUPs are as follows:

CPCs are fully quality assured against current RUP levels. Individual one-off patches are not.
CPCs are consolidated and only contain critical patches that apply to broad customer usages. They are smaller in footprint and therefore much easier to apply and uptake than RUPs.
CPC Readmes have detailed business and functional information about the fixes included. Customers can leverage the Readmes to determine impact and testing required for specific process flows and software components involved.

Important points:

One-off patches, the 7-digit number is their only identifier.
The Patchset level naming convention has an alternative to the patch number for easier identification. It consists of version number, product abbreviation, and a letter.
11i.AR.N refers to patchset N for product AR for version 11i and it can be found under patch number 9054532 (7 Digit Number)
Family packs add an additional component to the short name which is “_PF” after the product name abbreviation. For example: the Financails family pack is referred to as 11.FIN_PF.G
Consolidated updates were introduced after release 11.5.10. They append another number after the version number. So consolidated update 2 is referred to as 11.5.10.2 or simply CU2 .
Maintenance packs and their alternative names are same as the version number, so it’s 11.5.9, 11.5.10 etc.
R12.AR.A.6 means Account Receivables product on codeline A (Release 12.0) on codelevel 6 (Part of release 12.0.6).
RUP5 is equivalent to R12.0.5, RUP6 is equivalent to R12.0.6 etc.

Short names and their meaning:

CPC: Critical Patch Collection
RUP: Release update Packs
RPL: Recommended Patch List
ARU: Automated Release Update
CP: Concurrent Processing
UPC: Upgrade Patch Collection
PSU:Patch Set Update

Source: Oracle MySupport

Using Personalization how to make Warehouse Field Mandatory on Order Entry Screen

2009-07-25T23:15:00.012-04:00

Personalization steps to make Warehouse field mandatory on Order entry screen with a condition to be mandatory for specific Order line type (eg Backorder):

Navigation: Help>Diagnostics>Custom Code > Personalize.

1. Enter Seq:10
Description : Warehouse Mandatory
Level:Function
Condition:
Trigger Event:WHEN-NEW-FORM-INSTANCE
process:Both

Context:
Responsibilites: please assign the responsibilites (order management) as required.
Actions Tab:
Seq:1
Type: Property
Language: All
Enabled:Checked
Object Type:Item
Target Object:LINE.SHIP_FROM_MIR
Porperty Name:Required
Value:TRUE

2.Enter Seq:20
Description:Show message when trying to save with null value in mandatory warehouse field
level:Function
Condition:
Trigger Event:WHEN-VALIDATE-RECORD
Trigger Object:Line

Condition:
:LINE.SHIP_FROM_MIR IS NULL
and ((:LINE.ORG_ID=X and :LINE_TYPE<>1001)
OR(:LINE.ORG_ID=Y and :LINE_TYPE<>1025
Processing Mode: Both

Note: please check the line_type or order type id which need to be included in the above condition in this for back order line type id.

Context:
Responsibility: assign the list of responsibilities as required.

Action Tab:
Enter Seq:10
Type:Message
Language: All
Enabled:checked
Message Type:error
Message Text:Please Enter a Warehouse

When users enter orders with out a warehouse they cannot book the order and they get a popup message please enter a warehouse.

Responsibility Not Visible to user in the list of responsibilites assigned to User:

2009-07-25T22:39:00.008-04:00

Recently came to know that though the system adminstrator is given the responsibility access to users, users are not able to view the responsibilities in the list of responsibilities assigned.

1. Check if the responsibility is not end dated.
2. Run the request " Syn responsibility role data into the WF table".
3. Run the request " Synchronize WF LOCAL tables" enter the paramters
- Orig System: ALL
- Parallel Process:0
- Logging Mode: LOGGING (Logging Activated)
- Temporary Tablespace : Blank
- Riase Errors: Yes
4. Run the request "Workflow Directory Services User/Role Validation" enter the paramters
- p_BatchSize:10000
- Fix dangling user/roles : Yes
- Add missing user/role assignments : Yes
- Update WHO columns in WF tables: Yes
5. Log off and login back and verify that the responsibility appears.

That should resolve the issue.

If the problem is not resolved still ask the sysadmin to start the following servives
Navigation: System Administrator > Workflow > Oracle application manager > Workflow Manager
- Workflow Deffered Notification Agent Listner
- Workflow Error Agent Listner
- Workflow Java Deffered Agent Listner
- Workflow Java Error Agent Listner.

In case still there is a issue please raise a Service request with Oracle.

R12 Mutli Org and MOAC

2009-06-13T20:03:00.009-04:00

What is Multi-Org:
--------------------
•Multi-Org is a server-side (applications and database) enhancement that enables single installation of Oracle Applications.
•Multi-Org keeps transaction data and some setup data separate and secure by different lines of business.

Business needs:
-----------------
The Multi-Org enhancement provides features that enable you to:
•Support multiple business units even if they use different ledgers
•Secure access to data on a single instance by line of business
•Define different organizational models
•Sell and ship from different legal entities
•Procure and receive from different legal entities
•Produce reports across entities or within a single entity

Types of Organizations supported in Multi-Org Model:
---------------------------------------------------------
Business Group :
- HR

Leger:
- GL, FA

GRE/Legal Entity:

Operating Unit:
- AR, OM, AP, PO etc

Inventory Oranziation:
- INV, MFG Ship

Naming Considerations:
------------------------
Ledger:
Ledger_ ; COB_, ROB_, BG_, HR_, LE_, OU_,

Inventory Organization:
IO_

Organziation:
GM_

Mutlti-Org Access Control (MOAC):
------------------------------------------
User Access to Multiple operating units is called Multi-Org Access Control.

Multi-Org Access Control enables companies that have implemented a shared services operating model to efficiently process business transactions by allowing them to access, process, and report on data for an unlimited number of operating units within a single applications responsibility. This increases the productivity of shared service centers, as users no longer have to switch responsibilities when processing transactions for multiple operating units at a time. Data security and access privileges are still maintained using security profiles that now support a list of operating units.

•Access one or more operating units using single responsibility.
•Enhanced reporting capability using:
–Reporting level parameter
–Reporting context

Benefits:
----------
Using MOAC, a user can perform tasks for multiple operating units (OU) without changing their responsibilities.

Tasks users can perform using MOAC in multiple OUs:
•Enter Payables Invoices
•View Consolidated Requisitions
•Perform Collections
•Process Receiving and Drop Shipments
•Customer Data Management
•Accounting Setup

MOAC Setups and Process:
-----------------------------
Setup:
1. Define Operating Unit
2. Create Security Profile
3. Run Security List Maintenance
4. Setup Profile Options.

Process:
1. Login and select a responsibility
2. Launch a Form
3. Application Checks Users Access Privileges
4. Process data for Operating Unit.

Leveraging Multi-Org Access Control feature:

Accounting Setup Manager :
Create ledgers and operating units through the Accounting Setup Manager.

Payables:
Reduce processing time with the ability to enter invoices for multiple operating units without switching responsibilities. Reduce processing cost with the ability to pay invoices for multiple operating units in a single pay run.

Receivables:
Provide global information for decision making purposes with new cross organization reports

Purchasing:
Ability to negotiate discounts armed with consolidated requisition demands

Collections:
Global collections agency with consolidated view of customer accounts and collection tasks for multiple operating units

R12 Oracle Application Footprint

2009-06-13T15:14:00.013-04:00

Release 12 is defined as “The Global Business Release.” Global is
not just a geographic perspective, but also a comprehensive
perspective; release 12 functionality spans across both industries
and business functions.

R12 Foot Print:
============

Key Business Flows :
---------------------
Oracle business flows are a collection of application components
designed for end-to-end business processes. They identify the
critical business processes an organization utilizes to support a
complete business strategy for managing operations, customers,
suppliers, partners, and employees.

Oracle business flows map business processes across multiple
organizations and many applications to represent a streamlined,
efficiently integrated information flow throughout business
organizations and across geographies.

R12 Architecture:
----------------------
Business Architecture: The R12 EBS has 5 principles that drives its business architecture:
-Modern Foundation
-Complete
-End to end Intergration
-Global
-Rapid Implementation.

1. Oracle has embedded all of its new R12 development into open,
scalable standards. These standards include using Java/J2EE,
HTML, JavaScript (JSP), Internet-accessibility, and centralized
management.

2. R12 E-Business Suite is accessible via global networks. It
accommodates multiple languages and currencies; supports
international features, such as flexible date formats and multiple
radix support; supports data in the Unicode Character Set (UTF-8)
and has accounting and business localizations built into it.

Technical Architecture:
PHP (Personal Home Page) or Portal becomes the gateway through
which the user has rights to access all the information to which they
have been granted access. Thus, R12 administrative tasks are
simplified while operations costs are reduced.

- Form based: Forms-based users are typically people involved
in the transactional operations of an organization.
- HTML/JSP's (Self Service): Self-service users are infrequent
users who want their interface with R12 to be as simple and as quick
as possible.
- Business Intelligence: Business intelligence users are senior
executives and managers who want an easy-to-use interface that
can be used to reveal critical business information and reports.
- Mobile: users whose jobs are likely to keep them away from a
readily available, network-connected computer. example : sales
representatives, field representative. By utilizing the mobile
interface, they are able to send and receive information at points
where it is important and convenient for them.

AutoLockbox:

2009-05-30T15:09:00.018-04:00

Overview of AutoLockbox:

•Process where customers mail payments to a post office box near

your remittance bank and the bank deposits the payments in your

account at regular intervals.

•Bank provides you with computer files detailing about the receipts

and their application. •Receivables uses Auto Lockbox to import

details about receipts directly into the system.

What is AutoLockbox:

Auto Lockbox is a service that commercial banks offer corporate

customers to enable them to outsource their accounts receivable

payment processing. Auto Lockbox eliminates manual data entry

by automatically processing receipts that are sent directly to

your bank.

Benefits of AutoLockbox:

•Eliminates manual data entry.
•Streamlines the application of receipts to outstanding transactions.
•Effectively manages cash flow by reducing turnover for converting

checks into cash.
•Apply receipts to outstanding invoices
•Import historical receipt data
•Autolockbox reports, such as the Post Quikcash Execution Report,

are a good tool to reconcile autolockbox receipts with the bank

transmission reports.

AutoLockbox is 3 Step Process:

1. Import :During this step, Lockbox reads and formats the data from

your bank file into interface table AR_PAYMENTS_INTERFACE_ALL

using a SQL *Loader.

•Data is imported into interface tables •Imported data does not affect accounts receivables balances
•Import automatically generates the Lockbox Execution Import report
•Use report to check the imported data

2.Validation: The validation program checks data in this

interface table for compatibility with Receivables. Once validated,

the data is transferred into QuickCash tables

(AR_INTERIM_CASH_RECEIPTS_ALL and
AR_INTERIM_CASH_RCPT_LINES_ALL) .

At this point, you can optionally query your receipts in the QuickCash

window and change how they will be applied before submitting the

final step, Post QuickCash script.

•Ensures that each receipt complies with application and customer

requirements
•Customer must have a primary billing location
•Bank can provide a MICR or a customer number to identify customer
•Validated data is transferred to QuickCash tables
•Transfer does not affect accounts receivables amounts
•Receivables can use AutoAssociate or a billing address to identify customer
•Use the Lockbox Execution Import report to review the validation

3.Post QuickCash: This step applies the receipts and updates your

customer’s balances.

•Data is transferred from QuickCash tables to Receivables tables
•Posting updates the account balances to reflect the imported receipts
•View and update receipts in the Receipts window

These steps can be submitted individually or at the same time from the submit Lockbox Processing window. After you run Post QuickCash, Receivables treats the receipts like any other receipts, you can reverse and reapply them and apply any unapplied, unidentified, or on-account

amounts.

MICR Number:

What is a MICR Number:
–Magnetic Ink Character Recognition (MICR)

MICR # Consists of two segments
1st segment - Transit Routing Number (Customer’s Bank) this

identifies the bank from which your customer draws their check.
2nd Segment - Bank Account of the customer (Customer’s Account)
MICR Number Can Only Be Used For One Customer Only!
MICR Number is used to identify the Customer.

The bank account number and the transit routing number makeup

your customer’s MICR number. If a MICR number is shared with

more than one customer, the receipt is rejected.Customers that are

associated must have unique MICR numbers.

By default the lockbox validation program uses an invoice or debit

memo number to determine the customer.

How AutoLockbox Identifies Customers for Receipts:

AutoLockbox can validate your customer data based on the

following attributes . If no match is found, the receipt is imported

as Unidentified receipt. This unidentified receipts can be identified

and then applied from the Quick cash window or the receipt window.

1. Customer Number: If you provide a customer number for

receipts that you import through AutoLockbox, Receivables can

identify the customer to which the receipt belongs .

2. MICR Number: The MICR number that appears on each

receipt relates the customer to a bank. Lockbox only uses MICR

numbers to associate a customer with a receipt if both of the

following are true:
a). The customer number is not included in the transmission

format
b). The MICR number is passed

3. AutoAssociate: If the customer cannot be identified from either

the MICR number or the customer number (for example, if the

transmission does not include this information), you can use

AutoAssociate to determine the customer using matching numbers.

A matching number can be a transaction number, consolidated

billing invoice number, sales order number, purchase order number

or another custom defined number.

4. Associate Receipts with Billing Locations: Receivables also lets

you track receipts for each of your customer’s billing locations.

To use this feature, you must include a billing location in your

transmission format, data file and the flag Require Billing Location

should be set to Yes. This option should be set to yes both at system

options and at the setup of Lockbox. If the box is checked at the

Lockbox, the receipt will be validated only if the billing location is

provided. The setting at the system options level determines

whether Post QuickCash can process receipts with /without billing

locations.

How AutoLockbox Applies Receipts:

If Lockbox is able to identify the customer for a receipt and the

transaction number is provided , Lockbox applies the receipt to this

transaction.

If the transaction number is not provided and Auto associate is

set to Yes, Post QuickCash uses the matching rules defined for the

customer site, customer or Lockbox to apply the receipt.

The setting of Match Receipts By Option tells what type of matching

number is passed in the transmission. If Matching Rules fail, Post

QuickCash applies the receipt using the AutoCash rules set .

If AutoCash rules also fail, Lockbox assigns the receipt a status

of Unapplied. If the transaction number is not provided and Auto

associate is set to No, Post QuickCash assigns the receipt a status

of Unapplied.

AutoLockbox Receipts Matching:

Receivables applies the receipt using:
•Transaction number
•Sales order number
•Purchase order number
•Consolidated bill number
•User-defined number

Maintain Transmission Data:

Use the Lockbox Transmission Data window to delete and edit

transmission data imported into Receivables from your bank

using Lockbox.

You can correct your lockbox data in this window for receipts that fail

validation, then resubmit the validation step again .

Running AutoLockbox:

To Import and apply receipts using AutoLockbox, run each step individually or run them as a group.

Import:
a) If you are importing a new bank file, check the New Transmission check box, then enter a new Transmission Name.

b) If you are resubmitting an existing lockbox transmission, you can select a name from the list of values.
c) Enter the name of the datafile along with path and extension.
d) Enter the name of the control file with out extension. Make sure that

the control file in $AR_TOP/bin directory.
e) Select the transmission Format from list of values.

Validation:

a) Check the Submit Validation Check box.
b) You must enter a lockbox number if Submit Validation is Yes and

the lockbox number is not specified in your bank file.
c) To apply receipts to transactions belonging to unrelated customers,

check the Allow Payment of Unrelated Invoices check box.

d) If you defined your GL Date as ’Constant Date’ in the Lockboxes

window, you must enter a GL Date; if you specified a GL Date of

’Deposit Date’ or ’Import Date’, Receivables uses this as the GL date.
e) Enter a Report Format. Enter ’All’ to include all records processed

in this transmission. Enter ’Rejects Only’ to include only records

that failed validation.
f) To transfer only the lockbox batches in which all records pass the

validation step to the QuickCash tables, check the Complete Batches

Only check box. If you do not check this check box, Receivables will

transfer any receipts within a batch that pass validation, even if

others are rejected.

Post Quick Cash:

a) To apply the receipts and update your Customer’s balances, check

Submit post QuickCash check box.
b)Choose how lockbox should handle invalid transaction numbers.
c) Post Partial Amounts as Unapplied or Reject Entire Receipt

Save your work. Receivables displays the Request ID of your

concurrent process and generates the Lockbox Execution report.

VSOE and Revenue Recognition

2009-05-23T16:21:00.018-04:00

What is Vendor specific objective evidence(VSOE)==========================================
Vendor Specific Objective Evidence, is Fair Value for Software.
SOP 97-2 was designed for Software companies, and works fairly
well for certain traditional business models.

The concept was introduced in 1997 by the AICPA in their Statement
of Position (SOP) 97-2: It governs how any company that licenses,
sells, leases or otherwise markets software (unless it’s incidental to
the product or service as a whole) must recognize the revenue.

In particular, it governs how companies must recognize revenue from
so-called “multiple-element arrangements” – bundles of software and
related products or services sold as a unit at a single price.

Today, more and more companies find themselves dealing with
VSOE as embedded software becomes an increasingly essential
element in traditionally non-software sectors - consider cell
phones, medical devices, computer networks, even cars with GPS
services, etc.

According to SOP 97-2: you allocate relatively, splitting the fee
amongst the products and related elements based upon VSOE –
which is the price established by the vendor for the separate sale
of each element. Each VSOE price is usually established through
accumulation of a quantity of discrete sales “sufficient” to prove
that the market, in it’s willingness to pay that price, thinks the
price is fair. And here’s the big catch:

You can not recognize revenue for any element either until VSOE
exists for each and every element, or until all of the elements
have been delivered.

Sec's Statement of Postion (SOP) 97-2, Software Revenue
Recognition and SOP 98-9, Software Revenue Recognition with
respect to certain transactions, applied to all entities that license,
sell, lease or market computer software. It specifies that revenue
from an arrangement involving multiple elements should be
allocated to the various elements based on VSOE fair values to
the customer.

Sections of SOP 97-2 were amended with SOP 98-9, Software
Revenue Recognition with respect to certain transactions,
SOP 98-9 states that the residual method of revenue recognition is
required when:
1. There is vendor specfic objective evidence of the fair values of all
undelivered elements in a multiple-element arrangment that is not
accounted for using long-term contract accounting.
2. VSOE of fair value does not exist for one or more of the delivered
elements in the arrangement and 3. All Revenue recognition criteria
in SOP 97-2 other than the requirment for VSOE of the fair value of
each delivered element of the arrangement are satisfied.

Elements of VSOE:
==================
-Software Licenses
- Warranty
- Installation
- Support and professional Services
- Training

Fair Market Value (FMV):
========================
The FASB defined 'fair value' in FAS 159 as "The price that
would be received to sell an asset orpaid to transfer a liability
in an orderly transaction between market participants at the
measurement date. " The key points in this definition are
'orderly transaction' and 'market participants.' Thus fair value
can't be established by looking at an exchange of assets in a
bankruptcy or between 'related parties' as defined by the SEC.

Fair value is established by multiple, non- related market
participants in 'normal, orderly transactions. ' VSOE, on the other
hand, is fair value as established by looking at the historical
transactions of a specific vendor and does not consider what other
vendors are charging for similar products.

Revenue Recognition:
====================
Revenue recognition in today's regulatory and business
environment involves sophisticated revenue scheduling and
allocation, Vendor- specific Objective Evidence (VSOE) carve-outs
and Sarbanes-Oxley compliance. Thus having a common system
for global compliance is key to reducing complexity.
Revenue recognition is a principle prescribing that revenue is
recognized when earned.

It has two considerations - when to recognize revenue, and how
much to recognize. Revenue recognition is relevant for companies
to be able to adhere to legal compliance as per the US GAAP
requirements.

Improper revenue recognition increases the risk of financial
restatement, and financial restatements. Revenue for ISV's is
typically divided into three categories: Software, Maintenance, and
Services. Assuming that software customization is not required,
revenue can be recognized when all of the following criteria are met:

There are four basic criteria that must be met to recognize
revenue
- Evidence
- Delivery
- Fixed or determinable fee
- Collectibility.

Revenue Accounting:
===================
Use the Revenue Accounting feature to quickly and easily adjust
revenue and sales credits at the transaction or line level. You can
make manual adjustments using the Revenue Accounting and
Sales Credits window. Alternatively, use the Revenue Adjustment
API to automatically perform these adjustments. Revenue
Accounting uses the Actions Wizard to guide you through the process
of makingand modifying revenue adjustments.
You can also use the wizard to record early acceptance for an
invoice line, if the line is associated with a contract that offers an
acceptance clause.

Invoicing Rules:
===============
Use Invoicing Rules to specify whetherto record receivables
amounts in the first (Bill in Advance) or Last (Bill in Arrear)
Period.
Invoicing rules determine when to bill the customer inrelation to
the accounting rule Periods. Accounting rules determine the
accounting periods for revenue recognition and Billing.
Two invoicing rules are available:

Bill in Advance: Use this rule to recognize receivables immediately.

Bill in Arrears: Use this rule to recognize the receivable at the end of

the revenue recognition schedule.

•Invoicing rules determine whether to recognize receivables in the first or in the last accounting period.
•Once the invoice is saved, you cannot update an invoicing rule.
•If Bill in Arrears is the invoicing rule, Oracle Receivables updates the GL Date and invoice date of the invoice to the last accounting period for the accounting rule.

Accounting Rules:
=================
Use Accounting Rules to determine when to record revenues.
Accounting Rule determine the number of periods and percentage
of total revenue to record in each accounting period.

Each invoice can have different accounting rule.

Use the Accounting, Fixed Duration type to recognize revenue evenly
over a specific number of periods. Revenue can be spread evenly or a
percentage can be specified for each period.

Variable Duration type to recognize revenue by a percentage for
the first period. The remaining revenue is spread evenly across
the number of periods you specify during transaction entry.

Accounting rules determine when to recognize revenue
amounts. Each invoice line can have different accounting rule.

Oracle Receivables uses the First GL Date field in the Transactions
window to determine when to start recognizing revenue. The number
of periods in which revenue is recognized is determined by the
value in the Number of Accounting Periods field in the Transactions
window.Value defaults from fixed ruleValue must be entered for
variable rule. Accounting distributions are created only after you run
the Revenue Recognition program.

•Accounting distributions are created only after the Revenue
Recognition program is run.
•For Bill in Advance, the offset account to accounts receivable
is Unearned Revenue.
•For Bill in Arrears, the offset account to accounts receivable i
s Unbilled Receivables.
•Accounting distributions are created for all periods when
Revenue Recognition is run.

Revenue Recognition Program Execution Report :
=======================================
Use the Revenue Recognition Execution report to review all
revenuedistributions created for invoices that use invoice and
accounting rules.

This report displays the account class, GL Date, Accounting
Flex field, the currency, amount, and accounted amount for
the revenue distributions Revenue Recognition creates for
each transaction.

Receivables automatically creates the Revenue Recognition
Execution report whenever you run the Revenue Recognition
program, the Revenue Recognition Master program, or the
General Ledger Interfaceprogram.

When the Revenue Recognition program encounters transactions
with problems that prevent the creation of distributions, the
program completes with a status of Warning, and Receivables
includes these transactions at the bottom of this report.

•The Revenue Recognition program gives control over the creation
of accounting entries.
•Submit the Revenue Recognition program manually through the
Run Revenue Recognition window.
•The Revenue Recognition program will also be submitted when
posting to Oracle General Ledger.
•The program processes revenue by transaction, rather than by
accounting period.
•Only new transactions are selected each time the process is run.

Oracle iReceivables

2009-04-21T00:35:00.009-04:00

Overview of i Receivables:

Oracle iReceivables is an online invoice presentment, dispute, and payment solution that enables external and internal users to inquire about their accounts and transactions, pay invoices, and dispute invoices via a streamlined credit memo workflow and it helps you reduce the cost of billing and collections while improving overall customer service.
Oracle iReceivables gives the customers self-service access to their accounts with real-time balance and transaction information. T
he Home page gives customers quick access to their account information with drill down capability to specific details. It shows transaction balance and aging information, supports print requests, gives discount alerts, and shows credit memo status

iReceivables Features:
-Customer Search
-Accont Details
-Interactive Invoice
-Payment and Credit memo display
-Dispute a bill
-Credit Memo Workflow
-Automatic Credit memo creation.
-Credit memo Request Confirmation Page

Oracle iReceivables gives your Customers Self-Service Account Management

Export transaction data to spreadsheet
Attach documents to transactions
Manage Payments and Ensure Data Security
Duplicate dispute warning
One-time credit card payment
Configurable service charges
Customizable transaction search.

Simplify the Payment Processes:

Anonymous user login:
The Anonymous User Login feature allows external customers to log in by only entering an account number. Therefore, customers can access their customer account data without having to register for a username and password. Companies can customize this feature to take the users directly to the page they need to access the most, for example, the Account Details page or the Home page.
The benefits of Anonymous User Login are: 1) it removes the registration overhead for users accessing Oracle iReceivables on the one-time basis. 2)It also speeds up the log-in and navigation process for them. As a result, customers are encouraged to make online payments in a more timely manner.
Multi-pay and multi-print:
-The Multi-Pay feature allows the customers to select multiple invoices and pay all of them at once using credit card or bank account transfer. With this feature, customers no longer have to navigate into each invoice and pay them one by one. Instead, they can just select all the invoices they want to pay in the Account Details page and pay them all at once.
-The Multi-Print feature allows customers to select multiple invoices and print all of them at once. The print format is defined in Oracle Receivables, including PDF, HTML, text, XML, PostScript, etc. Once the print job is completed, the customers will receive an e-mail notification containing a link for accessing the printed documents. The link allows for one-time access only.

Why do companies want to use Oracle iReceivables?

1. To remove their paper invoices and reduce the mailing and faxing overhead for their invoices. 2. To reduce the manual payment applications and receive payments from their customers more quickly. 3. To reduce phone calls and automate their collections and customer services. 4. To be able to resolve bill disputes quickly and improve their customer satisfaction.

Oracle iReceivables supports :

A paperless enterprises It streamlines the dispute processes to help reduce the DSO (Days Sales Outstanding)
It provides customers with self-service payment options such as credit card or bank account, and payment scheduling.
It enables companies to collaborate with their customers through the self-service account management.
It automates user administration and registration and expedites online access for one-time users.

Oracle iReceivables Modules Intergration:

1. It integrates with Oracle Receivables to provide real-time transaction status and details.

2. It with Oracle Trading Community Architecture to provide real-time account access and customer information.

3. It integrates with Oracle iPayment to enable online payment application and processing.

4. It integrates with Oracle Workflow to provide automated credit memo and multi-print processing.

5. integrates with Bill Presentment Architecture, which provides customizable bill presentment templates.

6. It integrates with Oracle Application Framework to enable personalized display of account information.

Set the Profile option, Currency:Negative Format correctly so that negative numbers have the negative sign not brackets to facilitate exporting to Microsoft Excel.
Set the profile option FND:View Object Max Fetch Size, so that all transactions can be viewed on a single page rather than scrolling pages.
setup of External users is done by the party number assigned to a contact.

Mobile Accounts:

Provides anytime, anywhere access to the application via a web enabled mobile device
Designed specifically for mobile devices
For internal (Management , Collection Agents and sales reps) and external users (customers)
Access for internal and external users can be restricted based on configurable function security Integrated with Mobile Customer Directory

Mobile Accounts provides the following information about a customer :
–Account Overview
–Credit Information
–Recent Activity
–Aging

Features:
–Robust Customer Search using Mobile Customer Directory
–Powerful Transaction Search
–Ability to drill down to the Transaction Detail
–Pay an invoice
–Configurable access control
–Efficient non-hierarchical navigational menus

setups:

1. Defind iReceivables Internal Users2

. Defind iReceivables External users and customer Access

3. Define Function Security

4. Index the Customer Database

5. Set up for Self Registraion

6. Setup for Anonymous user login

7. Define Service Charges

8. Review and update Receivables lookups

9. Set the proifle option fo agining buckets

10.Define currencies for customers and customer bill to sites.

11. Define Receipt Class and Payment methodl

12. Set receivables system option for ireceivables payments.

13. setup document sequencing for ireceivables receipts.

14. Set Profile option for ACH Bank accoun transfer payments

15. Modify the dispaly of account information

16. Set profile option for bill presentment architecuture.

17. intergra ireceivables into your business processes.

for more information pls go through the implementation guide and user guide.

Ramification of Invoice Match to PO and Invoice Match to Receipt

2009-04-16T21:59:00.009-04:00

Oracle Payables shares purchase order information from your purchasing system to enable online matching with invoices. Invoiced or billed items are matched to the original purchase orders to ensure that you pay only for the goods or services you ordered and/or received. If you are billed for an item over the amount and quantity tolerances you define in the Invoice Tolerance window, during Approval, Oracle Payables applies a hold to the invoice, which prevents payment.
Oracle Payables supports three levels of matching which verify that purchase order and
invoice information match within defined tolerances.

Match Approval Level: 2-Way , 3-Way, 4-Way.

In 2-way: what ever you have ordered for the PO you will make the payment for the suppliers in 2- way i.e we will compare two documents PO and Invoice.
2-way matching verifies that Purchase order and invoice information match within your tolerances:
Quantity billed <= Quantity Ordered
Invoice price <= Purchase order price
Eg:Suppose we Had given PO for 100 items ,for that we will receive invoice for 100 items. so that we will make payment for that 100 items.

In 3-Way you will compare 3 documents i.e PO+reciept+Invoice.
3-way matching verifies that the receipt and invoice information match with the quantity tolerances defined:
Quantity billed <= Quantity received.
Eg:Suppose we have ordered 100 items in PO. But we had received only 75 items ,But we had received invoice for 100 items. so, we will make payment for only 75 items.

In 4-Way you will compare 4 documents i.e PO+Receipt+Invoice+Inspection.
4-way matching verifies that acceptance documents and invoice information match within the quantity tolerances defined:
Quantity billed <= Quantity accepted.
Eg:Suppose we have 100 items in PO. Suppers send us 75 items We will do inspection on those items what ever we have received, If 15items got damaged. finally, we are going to make payment to the 60 items only.

When you match to a purchase order, Payables automatically checks that the total of PO_DISTRIBUTIONS.QUANTITY_ORDERED = AP_INVOICE_DISTRIBUTIONS.QUANTITY_INVOICED (2-way matching). Payables only checks QUANTITY_RECEIVED (3-way matching) if the RECEIPT_REQUIRED_FLAG is set to Y and only checks QUANTITY_ACCEPTED (4-way matching) if the INSPECTION_REQUIRED_FLAG is set to Y.

Invoice Match Option:

The Invoice Match Option determines whether or not you intend to match invoices for this supplier against purchase orders or receipts.

Invoice Match option to PO Match:
--------------------------------------------
•Payables must match the invoice to the purchase order.

•If the Invoice is matched to a PO rather than to the Receipt when the AP team do a match they have the full PO available to match rather than just the specific lines on the PO that were received.

•There is a possibility someone in payables matching to the wrong distribution if they use Match to PO.

•The accrual is valued at the PO exchange rate date.

Invoice Match option to PO Match:
----------------------------------------------
•Payables must match the invoice to the receipt.
•Receipt Match Option is recommended if you want accounting to use exchange rate information based on the receipt date or if you want to update exchange rate information on the receipt.
•If you use the match to receipt option AP team can't match until the goods are received. If the receiving doesn't happen there is no way to associate the invoice with the PO.
•Invoice processing will be on hold till a receipt is entered into the system.
•Receipt Match option determines the cost with more accuracy i.e. Match to Material item receipt and link other invoice charges to receipt and You can now also associate freight, tax, and miscellaneous charges from invoices to the related receipt.
•Run the Matching Detail Report from Other -> Request -> Run. This report will show you detail of how an invoice, purchase order, or receipt was matched. This report is especially helpful when an invoice is on hold and you are trying determine why the hold was placed.

The Invoice Match Option defaults from the Supplier Sites window. You can change the Invoice Match Option on the shipment until you receive against the shipment.

Financial Options - Invoice Match Option:
For purchase order shipments, indicate whether you want to match invoices to purchase orders or to purchase order receipts. If the supplier was created automatically during Expense Report Import, the default value is Purchase Order, and you can change it to Receipts as appropriate.

The decision to set the Invoice match option to Receipt or Purchase Order depends on Business Needs.
•If you are using Multi Currency Functionality for Purchase Order and if like to have the rate based on Receipt date you need to go with Receipt Match at the invoice match option.
•The main advantage is the Exchange Rate factor i.e. Receipt/Current Date instead of Purchaser Order date.
•Receipt Match gives much closer control of the matching process,Particularly where you have multiple receipts of large purchase order.

If a Business is using Invoice Match option Purhcase Order and like to change from Purchase Order to Receipt Match, then what would be the impact?

•All Supplier sites need to be updated with Invoice Match option to Receipt.
•Purchase orders which are already approved with Invoice Match Option of Purchase order should continue with the same existing process.
•All existing Open PO, which need a change from Purchase Order to Receipt, should be corrected by changing the invoice match option in the purchase order shipment to Receipt. Payables team should match invoices to Receipt for all Purchase Orders created after the cut-off date.
•Training to AP/PO users.

In order for the receipt to use the current exchange rate and not the PO exchange rate, the Invoice Match Option at the system level and on the suppliers should be Receipt, not Purchase Order.

Overview on Financial Accounting Hub

2009-04-10T17:46:00.008-04:00

What is Financial Services Accounting Hub (FSAH pronounced as F-SAA):

Oracle Financials Accounting Hub (FAH) allows you to efficiently create detailed, auditable, reconcilable accounting from a variety of source systems and it address the complex demands of centralizing financial operational data, standardizing accounting and reporting policies, and accelerating regulatory information and management reporting cycles.

It is basically standalone Subledger Accounting (SLA), it allows you to use Oracle SLA and GL to perform the accounting for third party applications.

Financial Services Accounting Hub is a separately licensable product.

What is in the hub?
-Transformation of information from disparate systems into centrally and consistently maintained accounting repository.
-Create and store rules for the transformation of data.
-Secure both information and setup definitions.
-Load journal entry information into the accounting repository.

In 11.5.10, the Oracle AP, AR, FA modules have their own respective accounting engines to derive the accounting to Oracle GL. However, in R12, AP, AR, FA and many of the eBusiness Suite modules will use Subledger Accounting (the FSAH engine) to derive the accounting to Oracle GL. The version of FSAH that you have is not setup to derive the accounting from the subledger products (AP, AR, FA) at this time, so FSAH plays no role in interacting with the Oracle Subledgers in 11.5.10.

FSAH is only available in Release 12. FSAH requires the R12 General Ledger.
The E-Business Suite for Release 12 will use subledger accounting (SLA), which is the engine for FSAH and it will allow integration from AP, AR, and FA to GL.

FSAH is designed to work with Oracle and non-Oracle Applications; therefore, with some customization, FSAH can also work with EBS 11i--i.e., you can integrate the two ledgers from 11i and R12.

Note: FSAH is renamed and it is now called as FAH, FAH is only available in Release 12. FAH requires the R12 General Ledger.FAH is only available in Release 12. FAH requires the R12 General Ledger.

Financials Accounting Hub (FAH) is an offering that enables financial institutions to address the complex demands of centralizing financial operational data, standardizing accounting and reporting policies, and accelerating regulatory information and management reporting cycles. Financials Accounting Hub is a separately licensable product. It is basically standalone Subledger Accounting (SLA). This solution is being offered to Oracle and non-Oracle customers. It was originally intended to fill a market need in the financial services industry -- i.e., banks and financial institutions; however, it is now being offered to customers in other industries such as paint manufacturers, insurance companies, and the healthcare industry.

Overview on iSetup, CCG, CMP and ICM

2009-03-28T23:35:00.024-04:00

What is iSetup:

iSetup is a tool that supports initial implementations of the Oracle E-Business Suite.
iSetup mainly supports the ongoing maintenance of setup data. This includes simplifying the migration of setup data – from one instance to another; aiding in cloning setup data; and keeping track of setup data among the different environments.
The main focus of iSetup is to help migrate functional setups from one E-Business Suite instance to another. During migration, setups can be extracted selectively using filters on setup attributes. Extracted setup data can be optionally transformed before loading into target instance.
Another capability of iSetup is setup comparison, whereby a report can be generated on the exact differences of setup information between two instances or from the same instance across different timelines.

The iSetup solution addresses all the CRP business needs. You can create first time setups based on requirements gathered. You can use the same configuration to populate multiple instances or make refinements before loading into subsequent instances.

Uses of iSetup:

Initially EBS implementation involves a manual setup using either a ManuralEntry or Business Accelerators . iSetup can help start such implementation scenarios by loading a CRP instance from an industry best practice configuration.
iSetup provides an enterprise wide repository to store business specific configuration snapshots. These Gold copies can be used to configure a new instance, thus avoiding re-configurations.
iSetup expedites implementations by providing out-of-the-box migration templates tailored to suit various implemenation phases.
iSetup can also help promote setups from CRP to multiple test, development and production environments.
iSetup enforces business validations inherent in interfaces owned by Oracle product modules.
iSetup can be used to copy all setups striped by an Operating Unit and move it to another EBS instance using Hierarchical selection set feature which cascades filter criteria to all related setups in the selection set template.
In a roll-out scenario, iSetup can be used to replicate the setups tied to an existing Operating Unit to a new Operating Unit.
iSetup can be used to migrate incremental setups selectively across instances using filters on setup attributes. Instead of cloning the entire EBS instance, iSetup can be used to move required setup data from a production instance to a testing instance. New setups can be added to the test instance and those specific setups can be selectively migrated to production instance while the instance is up and running. This minimizes the need to redo setups, and execute expensive clone activities.
iSetup provides standard and comparison reporting features. Standard reports help in documenting the setups in regular PDF/RTF/Excel that serve as a standard reference for implementation teams.
iSetup comparison reports can help in troubleshooting functional setups by enabling users to compare setups across instances or timelines.

Configuration Contorls Governor(CCG) (formerly Integra Apps):

CCG helps you reduce financial loss, compliance cost, and audit effort related to your business application setups. It does this by identifying setup changes, storing them in a central repository, and reporting them. CCG can operate both automatically and on demand. It provides role-based security to ensure the privacy of sensitive business data.

Why CCG need to be used:

CCG's Change Tracker is useful for customers who want their business users to be able to:

Activate/deactivate Change Tracking for all business application setups without a technician's assistance Interpret setup change information without a technician's assistance.
Receive alerts when setup changes occur .
Use a single repository of all Change Tracking information for all business application setups.
Implement controls without employing Table Audit

CCG to Create BR100

Create a BR100-like framework in Oracle GRC Manager.
Enter your business requirements into the framework, and import the setup data that's captured by CCG. Then, add your comments in the framework as desired, and take any needed compensating, remediating, or mitigating steps. If you're wondering why CCG doesn't let you annotate the setup data it captures, it's because that would be at odds with a key GRC best practice: providing a single point of interaction between GRC users and all the data they need to make good decisions. Only solutions like GRCM and GRCI permit that holistic view, and only solutions like GRCM permit the automation of policies and workflows that rely on data from multiple sources, CCG being just one.

iSetup Vs CCG (Configuration Controls Governor):

CCG and CMP:

Configuration Management Pack (CMP )is designed for IT adminstrators who need to troubleshoot failed applications. It detects changes to files and databases, much like CCG Change Tracking detects setup changes. But CMP requires a developer to specify what should be tracked, and reports only raw data that requires a developer's interpretation; therefore it's not useful to the GRC business audience.

CCG and Preventative Controls Governer (PCG):

CCG and PCG complement each other. Use CCG to detect configuration change

Track changes to setups and compare snapshots
Rapid start with shrink-wrap support for 1000's of setups

Use PCG to restrict user activity:

Hide or mask EBS fields
Require third-party approval of EBS data changes
Require reason codes for EBS data changes
They do not compete with each other - PCG tracks changes to EBS data, but must be configured manually.

Internal Control Manager(ICM):

Oracle Internal Controls Manager is a comprehensive tool for executives, controllers, internal audit departments, and public accounting firms to use to document and test internal controls and monitor ongoing compliance. It is based on Committee of Sponsoring Organizations (COSO) standards.

In many countries, governmental regulations apply to the testing and reporting of corporate internal controls. For example, in the United States, the Sarbanes-Oxley Act of 2002 makes reporting on a company's internal control mandatory for both management and external auditors.

ICM Features :
Oracle Internal Controls Manager will:
•Expose internal audits to Sarbanes Oxley certifiers
•Make internal policies an integral part of your system
•Highlight application control points
•Compare internal policies to external guidelines
•Compare actual practices to internal policies
•Provide risk and issues library
•Validate financial values from the consolidated level to the transactional level at every subsidiary

ICM Setups:

Setup Auditbale Units
Define Business Proceses
Define Risks and Associate with Processes
Setup Contorls that mitigate process Risk
Create Surveys and links to Assessments
Define Audit Procedures to verify controls.

Auto Invoice in Accounts Receivables:

2009-03-16T22:12:00.016-04:00

What is Autoinvoice?
Autoinvoice is a powerful and flexible tool, used to import and validate transaction data from external financial systems or other modules of Oracle Applications. Users can create Invoices, debit memos, credit memos, and on-account credits in Oracle Receivables using Autoinvoice.

Auto invoice Process:
Data for creating invoices comes in from various sources such as external systems, Order Management, Oracle Projects, Oracle Services and so on. The interface loading program is run to populate the interface tables. When the Autoinvoice Master Program and Import Program are run, the data passes through certain validation processes and finally populates the tables of the Oracle Receivables module.

The feeder program populates data into the Autoinvoice interface tables, namely

RA_INTERFACE_LINES_ALL,
RA_INTERFACE_DISTRIBUTIONS_ALL and
RA_INTERFACE_SALESCREDITS_ALL

Every line must use the RA_INTERFACE_LINES_ALL table. The other two tables are optional.
RA_INTERFACE_LINES_ALL Table:
This table contains information related to all transactions to be processed by AutoInvoice. Transactions include invoices, debit memos, credit memos, and on-account credits. This table holds the key data such as bill-to customer, ship-to customer, and transaction date.
• Each record contains line, tax, freight, or finance charges information.
• The Line Type field identifies the type of information contained in the record.
• A record can be a parent record: Line, Header Freight, or Charges; or a child record: Tax or line-level Freight.
• A child record is linked to the parent record using the Link-To Transaction flex field.

RA_INTERFACE_DISTRIBUTIONS_ALL Table:
Oracle Order Management does not use this table because Auto Accounting creates the distributions in Oracle Receivables.

This table contains accounting distributions to be used by the transactions defined in RA_INTERFACE_LINES_ALL.
• Accounts defined in this table override any accounts created using Auto Accounting.
• You can choose to pass some or all account information to AutoInvoice. Any accounts that are not passed will be derived using Auto Accounting.
• Records in this table are linked to records in the RA_INTERFACE_LINES_ALL table using the Transaction flex field.

RA_INTERFACE_SALESCREDITS_ALL Table:
This table contains all sales credit information for the transactions in the
RA_INTERFACE_LINES_ALL table.
• The two tables are linked using the Transaction flex field.
• This table is required to track sales credits.

When the Autoinvoice program is run, data is populated into the tables listed below
-RA_BATCHES_ALL
-RA_CUSTOMER_TRX_ALL
-RA_CUSTOMER_TRX_LINES_ALL
-RA_CUST_TRX_LINE-GL_DIST_ALL
-RA_CUST_TRX_LINE_SALESREPS_ALL
-AR_RECEIVABLE_APPLICATIONS_ALL
-AR_PAYMENT_SCHEDULES_ALL
-AR_PAYMENT_SCHEDULES_ALL
-RA_INTERFACE_ERRORS_ALL

Grouping Rules:
Autoinvoice uses grouping rules to group lines to create one transaction. Mandatory grouping attributes cannot be dropped. However, users can add optional grouping attributes.

The grouping rule ‘DEFAULT’ is a seeded value, which contains all the mandatory grouping attributes.

Grouping rules are mandatory and determine how transaction lines are grouped into transactions Optionally, you can use line ordering rules to determine the order in which lines are displayed on a transaction.

To uniquely identify imported transactions and link the tax, freight, commitments, and credit memos, define the Transaction flex fields.

AutoInvoice validates your data by ensuring that the columns in Receivables Interface Tables reference the appropriate values and columns in Receivables.

Autoinvoice uses the following hierarchy to determine the grouping rule that is to be used:
· Transaction batch source
· Customer site level
· Customer profile level
· System Options Window

If a grouping rule is not specified, either, at the Transaction Source or at the Customer Site level or in the Customer Profile Classes window, Autoinvoice uses the default grouping rule specified in the System Options.

Transaction Flex fields:

Transaction flex fields are descriptive flex fields that AutoInvoice uses to uniquely identify transaction lines.

Because they are unique for each transaction line, they can also be used to reference and link to other lines.

Receivables lets you determine how you want to build your transaction flex field structure and what information you want to capture.

Define a flex field for each import source. Specify which one to use during import.

Use the Reference Flex field to link a credit memo line to a transaction. This passes information like order number, project number, and shipping information.

There are four types of transaction flex fields are
· Line Transaction Flex field
· Reference Transaction Flex field
· Link-to Transaction Flex field
· Invoice Transaction Flex field

Line Transaction Flex Field: Use columns INTERFACE_LINE_ATTRIBUTE1-15 and INTERFACE_LINE_CONTEXT to define the Line Transaction Flex field. They are unique for each record in the interface tables and therefore can be used as record identifiers.

The INTERFACE_LINE_CONTEXT field in RA_INTERFACE_LINES_ALL indicates to Autoinvoice, the Line Transaction Flex field code that is to be used. The Context value corresponds to the code field. For example Order Entry, Intercompany etc.

The Line Transaction Flexfield must be defined mandatorily. Autoinvoice always uses the Line Transaction Flexfield structure for both, the Link-to and Reference information when importing invoices. You need to explicitly define the Link-to, Reference and Invoice Transaction Flexfield structures, only if this information is to be displayed on a custom window.

Source: ORDER MANAGEMENT the line transaction flex filed code is ORDER ENTRY.

Reference Transaction Flexfield:
Reference Transaction Flexfields have the same structure as the Line Transaction Flexfields. Reference Transaction Flexfields are used to refer to previously processed transactions.
For example, to import a credit memo and apply it to an invoice or associate an invoice to a specific commitment, use the Reference Transaction Flexfield.
To refer a credit memo to a specific invoice use the REFERENCE_LINE_ATTRIBUTE1-15 and REFERENCE_LINE_CONTEXT columns of the credit memo to enter the value of the Line Transaction Flexfield of the invoice. If the invoice being credited, is already in AR, populate the REFERENCE_LINE_ID column of the table RA_INTERFACE_LINES_ALL.

Link-to Transaction Flexfield:
Link-to transaction flexfields also have the same structure as the Line Transaction flexfield. Use Link-to transaction flexfields to link transaction lines, to each other. For example, to import a freight charge that is associated with a particular transaction line, use the LINK_TO_LINE_ATTRIBUTE1-15 and LINK_TO_LINE_CONTEXT columns of the freight line and populate the value of the Line Transaction Flexfield of the particular transaction line.

Invoice Transaction Flexfield:
Invoice Transaction Flexfield has a structure similar to that of the Line Transaction Flexfield, but includes only the header level segments. Segments included in the Invoice Transaction Flexfield should be included in the Autoinvoice grouping rules. To define the header level transaction flexfield, query Invoice Transaction Flexfield in the title field of the descriptive flexfield segments window and enter the context and segments associated with this transaction flexfield.
All segments in the Line Level transaction Flexfield that refer to the header information must also exist in the header level transaction flexfield.

Auto invoice Validation:
AutoInvoice Validation Validates lines for:
-Accounting Rules
-Accounting Periods.

AutoInvoice validates the data for compatibility with Receivables. It ensures that the columns in Receivables’ interface tables reference the appropriate values and columns in Recievables. It checks for:
Existence: Ensures that the values for some columns are already defined.
Batch Sources: Ensures consistent values for fields in the Transaction Sources window.
Uniqueness: Ensures that the invoice number you supply is unique within a given batch source.
Precision: Ensures that the amount and accounted amount have the correct precision.
Cross Validation: Ensures that column values agree with each other.

Autoinvoice Master Program:
Autoinvoice Master Program selects and marks records in the interface tables, for processing based on the parameters entered. Once the records are selected, the Autoinvoice Import Program is spawned. Autoinvoice Master Program does not provide any report or output. The Master program allows running of several instances of Autoinvoice to improve system performance and to facilitate importing of transactions quickly.

The AutoInvoice Master Program can be submitted from the Standard Report Submission (SRS) window. This process can be schedule to run on specific intervals using the SRS scheduling features. Process specific transactions or a range of transactions by entering report parameters as listed on the slide above.
Use different selection criteria to submit individual transactions or groups of transactions.
Submit a maximum of fifteen instances.

Autoinvoice Import Program:
Autoinvoice Import Program validates the selected records and creates transactions. Any record that fails validation is left in the interface table with an error code. Depending on the overall setup, related records may be rejected as well. An output files called Autoinvoice Execution Report and Validation Report, can be viewed by clicking the View Report button in the Requests Window.

Autoinvoice Purge Program:
Autoinvoice Purge Program deletes records from the interface tables. Only records that have been successfully processed by Autoinvoice are purged. If the Purge Interface Table option in the System Options window is set to No, Autoinvoice does not delete processed records from the interface tables after each run and the Autoinvoice Purge Program will have to be submitted independently.

Reports:
The Autoinvoice Master Program log file, gives details of the concurrent request initiated by the Autoinvoice Master Program and any errors encountered therein.

The Autoinvoice Import Program log file, gives details of the concurrent request carried out for the import of transaction and any errors encountered therein.

The Autoinvoice Execution Report lists the total number of transaction, sales credit and distribution, lines that was successfully imported as well as those that failed.

The Autoinvoice Validation Report is created if any records have failed different phases of validation. It displays all error messages associated with each transaction, sales credit or distribution line that failed validation.

Correcting Auto invoice Errors Overview:

The AutoInvoice Exception Handling Windows can be used to correct errors that are in the AutoInvoice Interface Table. Records that pass validation are transferred into Receivables transaction tables. Records that fail validation are called exceptions; these records remain in the AutoInvoice interface tables.
Once you have corrected the errors, you must resubmit AutoInvoice. Valid lines cannot be changed in the AutoInvoice Exception Handling windows. Only those lines with errors can be changed

Interface Exceptions Window:

Displays the interface ID, exception type, error message, and the invalid value associated with each error. Cannot edit data in this window, but you can view the error message and easily correct the error by clicking the Details button.

Note: The error message and column name with erroneous data is displayed in the Message column, and the value that needs to be corrected is displayed in the Invalid Value column.

Interface Lines Window:
Displays all records in the interface tables that failed validation, provides an error message, and can be used to correct invalid records.
Click the Details button, the window opens where the errors can be corrected. Buttons are provided to correct specific types of errors.
Correct errors in these windows.

Line Errors Window:
Displays all errors associated with a specific line and can only be opened from the Interface Lines window. View all errors associated with a single line by clicking the Errors button in the Interface Lines window. Cannot edit data in this window. Displays the interface ID, the error type, error message, and the invalid value.

Note: You might use this window when you access the Interface Lines window directly, which does not display the error messages. The type indicates which button to click in the Interface Lines window.

How is the Tax code derived in AutoInvoice:

AutoInvoice first looks at the transaction type setup (Menu: Setup>Transactions>Transaction Types) and the TAX_EXEMPT_FLAG column in RA_INTERFACE_LINES_ALL. If the 'Calculate Tax' box is checked on the transaction type OR the TAX_EXEMPT_FLAG column is 'R'(for Required), it tries to derive the Tax code.

To get the tax code, AutoInvoice looks at the following places in the following order, stopping at the first place where it finds a tax code.

-Ship to site; -Bill-to-site; -Customer; -item

Useful Queries:

==============================
select
*
from
AR_VAT_TAX_ALL_B (VAT Code id);
===============================

Select
*
from
AR_VAT_TAX_ALL_B
Where
set_of_books_id=1002;
==============================

select
set_of_books_id,
tax_code,
tax_rate,
tax_type,
start_date,
org_id
from
ar_vat_tax_all
where
vat_tax_id = 10007;
=================================

Correcting AR Interface Errors:

The errors in the interface tables can be corrected with the help of the AutoInvoice Validation Report and the AutoInvoice Errors window which displays records that failed AutoInvoice validation. Depending on the error you may need to make changes either in Receivables, or to your feeder program or to the imported records in the interface tables.

Menu: Interfaces>Control>AutoInvoice>Interface Lines
Interface Lines Window - This window lets you see all of the interface lines that have been processed but rejected by AutoInvoice. You can view and edit data in this window.
Menu: Interfaces>Control>AutoInvoice>Interface Exceptions
Interface Errors Window - This window lets you see all of the errors generated by AutoInvoice. This window is read-only, but you can drill down to view errors in more detail, and modify data in these windows

Within the table RA_INTERFACE_LINES_ALL, there is a column called INTERFACE_LINE_ID. When the Autoinvoice process runs, this column is populated with a unique sequence value. If the process errors, the INTERFACE_LINE_ID can be referenced in the RA_INTERFACE_ERRORS_ALL table. This table will also include the error message for the particular order line in the main interface table.

Error: The total amount of your credit memo cannot exceed the balance of the debit item it is crediting.

Option1:

In the interface table , keep the curose after sale order field and click show field to check for the reference_line_id and make that field as null and resubmit the autoinvoice.

Option2:

update ra_interface_lines_all
set reference_line_id = null
where sales_order = :errored_sales_order
and reference_line_id is not null;

Error: You cannot apply a transaction with a negative amount to another transaction with a negative balance and vice versa.

Option1:
In the interface table , keep the curose after sale order field and click show field to check for the reference_line_id and make that field as null and resubmit the autoinvoice.

Option2:
update ra_interface_lines_allset reference_line_id = nullwhere sales_order = :errored_sales_orderand reference_line_id is not null;

Error: You can supply at most one Receivables account for a transaction (an invoice, a debit memo or a credit memo)

This error is caused by violating the mandatory grouping rules as defined by seeded Oracle functionality. This can occur on any number of fields so the key would be to review the following fields to ensure they are match per sales order:

AGREEMENT_ID
COMMENTS
CONS_BILLING_NUMBER
CONVERSION_DATE
CONVERSION_RATE
CONVERSION_TYPE
CREDIT_METHOD_FOR_ACCT_RULE
CREDIT_METHOD_FOR_INSTALLMENTS
CURRENCY_CODE
CUSTOMER_BANK_ACCOUNT_ID
CUST_TRX_TYPE_ID
DOCUMENT_NUMBER
DOCUMENT_NUMBER_SEQUENCE_ID
GL_DATE
HEADER_ATTRIBUTE1-15
HEADER_ATTRIBUTE_CATEGORY
HEADER_GDF_ATTRIBUTE1-15
INITIAL_CUSTOMER_TRX_ID
INTERNAL_NOTES
INVOICING_RULE_ID
ORIG_SYSTEM_BILL_ADDRESS_ID
ORIG_SYSTEM_BILL_CONTACT_ID
ORIG_SYSTEM_BILL_CUSTOMER_ID
ORIG_SYSTEM_SHIP_ADDRESS_ID
ORIG_SYSTEM_SHIP_CONTACT_ID
ORIG_SYSTEM_SHIP_CUSTOMER_ID
ORIG_SYSTEM_SOLD_CUSTOMER_ID
ORIG_SYSTEM_BATCH_NAME
PAYMENT_SERVER_ORDER_ID
PAYMENT_SET_ID
PREVIOUS_CUSTOMER_TRX_ID
PRIMARY_SALESREP_ID
PRINTING_OPTION
PURCHASE_ORDER
PURCHASE_ORDER_DATE
PURCHASE_ORDER_REVISION
REASON_CODE
RECEIPT_METHOD_ID
RELATED_CUSTOMER_TRX_ID
SET_OF_BOOKS_ID
TERM_ID
TERRITORY_ID
TRX_DATE
TRX_NUMBER
This is a difficult error to resolve, but involves reveiwing the interface line attributes.

Error: You can not apply more than the original line amount
Option1: Control > Autoinvoice > Interface Lines
Query for the Order which has the above error message, go to folder and query for Reference Line ID, Delete this reference id.

Option2: update ra_interface_lines_all
set reference_line_id = null
where sales_order = :errored_sales_order
and reference_line_id is not null

Error: Unable to locate a valid sales tax rate for transaction

This error occurs when the Oracle Tax engine or Tax Extension (for third party tax programs) fails to fetch a sales tax code or rate for the destination location, or fails to derive a tax code from the defaults defined through the system options.

The common causes of this error are listed below.

Missing or incorrect tax rate for the sales tax location combination.
Obsolete or unmaintained applications, tax engine or tax vendor code.
The invoice or order transaction date is not within the tax code effective dates.
When using third party tax vendors, may have overlapping zip code ranges when sales tax data was uploaded.
A tax code is assigned (customer, site or item) but system option tax defaults are not enabled.
Location based tax could not be found because transaction country <> home country.
Addresses are incorrect or not created properly due to invalid database triggers.
Sales tax location flexfield may be invalid

Error:Please correct revenue account or Receivables account or freight or tax account assignment

Change the revenue account assignment to a valid revenue account assignment.

Autoaccounting is used to determine the accounts when the distribution table is not populated. When AutoInvoice gives this error, it generally gives the account with the missing segment(s).

Review the setups:

Menu: Setup>Transactions>Autoaccounting Query the account mentioned in the above error and note the setup for that missing segment. If it is based on:

- Transaction Type : - Menu: Setup>Transaction>Transaction Types, and verify that all accounts are populated.

- Salesperson - Menu: Setup>Transactions>Salespersons, and verify that all accounts are populated.

- Standard Lines For an Inventory Item navigate to Menu: Setup>Transactions>Items>Inventory items, and verify that the 'Sales Account' is populated in the 'Invoicing' alternate region. For a Memo Line, navigate to Setup =>Transactions =>Memo Lines, and make sure that 'Revenue Account' is populated.

-Taxes Menu: Setup>Tax>Codes and verify that account is populated in 'Tax' column under the 'Accounting' alternate region.

Additionally the following can be checked: Setup of Cross Validation Rules. Run Cross validation Listing Report in GL to identify the cross validation rule stopping the import of this line.

Unable to Derive A GL Date for One Transaction.

Populate GL_DATE with a date or populate the date with the created date in the interface table that falls in an open period.

Useful Queries :

=========================
Select
distinct
interface_line_attribute1,
purchase_order
from ra_interface_lines_all
order by Purchase_order;
=========================
select count(1),
message_text
from ra_interface_errors_all
group by message_text;
========================

SELECT
*
FROM
RA_INTERFACE_ERRORS_ALL
WHERE
interface_line_id
IN
(
SELECT
interface_line_id
FROM
RA_INTERFACE_LINES
WHERE
interface_line_attribute1 = <> );
===================================

Select
interface_line_id,
message_text
from
ra_interface_errors_all
where
message_text
like '%Invalid Warehouse ID%';
===========================

Oracle iStores

2009-03-12T02:09:00.003-04:00

Oracle iStore Overeview:

Oracle iStore is a Web-based application that lets businesses establish flexible, robust Internet storefronts. In the Site Administration Application, merchants create and maintain sites which, in the Customer Application, appear as stores, allowing customer users to make online purchases. Strong integration with a variety of other Oracle applications – including Oracle Inventory and Oracle Order Management -- provides an extensive range of e-merchandising capabilities.

Implementing Oracle iStore enables businesses to:

•Build, test, and launch sophisticated online stores in multiple languages and currencies
•Deploy sites in business partner, business-to-business (B2B) and business-to-consumer (B2C) scenarios
•Target different customer segments and/or organizations
•Capture and track customer information and activities
•View reports about the activities in the online stores
•Provide a full range of online purchasing capabilities, including:
-Customer home page that can portal into other applications
-Flexible pricing, including qualifiers, modifiers, and customer-specific prices
-Credit card security features, including risk management and credit card number verification
-Sales assistance, including terms and conditions and published quotes
-Collaborative purchasing (shared carts and shared quotes)
-Regular or Express checkout
-Secure storage of customer addresses and credit card data
-Shopping lists and Direct Item Entry
-Address defaulting into carts
-Services (e.g., extended warranties)
-Promotional goods
-Telecommunications service ordering (TSO) item support
-User maintenance by administrative customer users (primary users)
-Order tracking, cancellation, returns, and access to customer installed base
In addition, organizations can build integrated sites which support users of Oracle iSupport and Oracle Partner Management applications.

Oracle iStore consists of two distinct, but integrated user interfaces:
The Site Administration Application and the Customer Application.

Introduction to the Site Administration Application
The Site Administration Application allows administrators to create and maintain multiple sites, catalogs, and related business rules.

Highlights include:
•Create and maintain unlimited number of sites, including those that support users of Oracle iSupport and Oracle Partner Management
•Set up site business rules, such as price lists, and payment and shipping methods
•Build product catalogs, leveraging the powerful Oracle Inventory application
•Change site look and feel, including adding content and picking section and product display templates
•View and configure Oracle Workflow e-mail notification messages

Introduction to the Customer Application

The Customer Application is a full, Web-based shopping application.

Highlights include:
•Online shopping with orders processed in the Oracle Order Management system
•Configure complex products, including telecommunications items
•Save carts, quotes, and lists
•Share and retrieve carts and quotes
•Track orders
•Cancel orders
•View installed base items
•Submit return orders
•Store and access user address and credit card data
Oracle iStore is an integrated part of the Oracle E-Business Suite.

Key Features Summary

Catalog Management
Oracle iStore provides a full catalog management application in the Site Administration Application, giving merchants a highly configurable, Internet catalog presentation tool. Leveraging the powerful Oracle Inventory on the back-end and Oracle iStore’s catalog building tool in the Site Administration Application, the Catalog is a flexible tool which supports multiple languages and currencies.

Highlights include:
•A section (catalog) hierarchy that can be as simple or complex as your business requirements necessitate. Sections are created in parent-child relationships. Products “hang” on nodes of the section hierarchy.
•Ability to control the browsing experience of the customer through section and subsection presentation.
•Cross-sell capabilities using the seeded Related items relationship, as well as support for a variety of other relationships between products, sections, and Inventory categories.
•A built-in search utility which allows you to locate a product by entering several criteria, including product name, number, category, description, as well as searching by sites that contain the product.
•Product search can support both Section Search and Category Search.
•Optional integration with Oracle interMedia allows you to set up a powerful product search in the specialty sites.
•A Display Template gallery which lets you quickly pick, in WYSIWYG fashion, the layout of individual or groups of sections and products.
•Configurable bins to which you can map your own JSPs and position along the sides, tops, and bottoms of catalog, shopping cart, and user registration pages. Several of the bins are pre-seeded with content.
•Ability to construct targeted catalogs accessible to segments of customers.
•Ability to exclude catalog portions from specific sites.
•Product autoplacement feature which allows the populating of sections with products through a single concurrent program.
•Support for several product types, including serviceable items, configured items, and model bundles.
•Flexible pricing support, including promotional goods modifiers and sites as pricing qualifiers.

Content Management
Oracle iStore’s Content Repository and reusable content components allow you to store, easily retrieve, and configure content to display in your sites.
Highlights include:
•Hundreds of configurable Display Templates present the Customer Application. This rich catalog display environment presents a multitude of possibilities for mapping content files to alter the look and feel of the specialty sites.
•Re-usable content components and media objects.
•Easy-to-use interface for mapping source files to the media objects.
•Components and objects that are organized by type of display they effect.
•Framework for reusing a single source file in any number of site catalog pages.
•Ability to map content to specific sites and languages combinations.
•Easily update files which display in the specialty sites.
•Optional integration with Oracle Content Manager to provide content item creation, versioning, and approvals.

Site Reporting
Oracle iStore supplies a variety of data that feeds the metrics in several e-commerce business intelligence and operational reports. The operational reports are presented in Oracle Discoverer Viewer and the e-commerce intelligence reports in Oracle Web Analytics Reporting module. Together, these reports provide a rich collection of valuable data about your sites, your customers, and their ordering activity.

Automated User Communications
Leveraging Oracle Workflow, Oracle iStore automatically delivers e-mail notification messages to the appropriate users for such events as:
•Orders placed or cancelled
•Contract negotiations
•Shared carts
•Forgotten passwords and login assistance
•Registration confirmation
•Pending user registrations
•Sales assistance requests

In addition, e-mail messages can be configured by organization, site, and user type, giving you immense flexibility in communicating with your customers.

Background Data Management
Several supplied concurrent programs in Oracle iStore automatically refresh data between business objects. For example:
•Lead import concurrent program pulls customer data from orders and expired carts into database tables for use in other Oracle applications
•Product search concurrent program automatically populates necessary tables with product updates for use in the Customer Application product search
•Reports refresh concurrent program supplies automatic updates of transactional and operational data about the sites.

User Management, Self-Service Registration, and Customer Information
Oracle iStore offers a full user registration and management framework in the Customer Application. For organizational users, seeded roles let you offer personalized features for different customer segments and business partners. Automatic user registration enables self-service access to the sites.
Highlights include:
•Supplied registration forms and processes for standard user registration, as well as for customers who have placed orders through other channels and customers who have only partial data registered.
•Business-to-Business (B2B) functionality allows management of complex relationships with corporate customers in a self-service environment, including the ability to restrict access by organization. The seeded Primary User role allows organizational users to set up and manage a community of business users.
•Support for customers integrated with Oracle iSupport and Oracle Partner Management.
•Business-to-Consumer (B2C) functionality allows you to quickly launch an online presence to the buying public.
•Supplied integration with Oracle’s customer data storage model, the Trading Community Architecture (TCA), provides the ability to maintain customer information and complex party relationships.
•Address Book and Payment Book functionality in the Customer Application allows users to maintain their own data.
•Ability to mandate the entry of B2B user contact information.
•Optional integration with Oracle Quoting allows interactive selling and online user assistance.

Globalization and Localization Support
Oracle iStore supports a global product catalog and infrastructure, allowing you to launch and maintain an international online presence.
Highlights include:
•Global accounting through Oracle General Ledger allows you to set up multiple sets of books and business calendars.
•Oracle Multiple Organization Architecture gives you the ability to create and manage multiple organizations, inventory units, and warehouses internationally.
•Multiple currency support allows you to deploy sites — with targeted products and prices — in any country.
•The globally-oriented Site Selection Page is the default landing page for the Customer Application. It displays all sites in your implementation, with separate links for each supported language.
•Seeded media objects for specific languages, allowing you to display country-specific images for each language.
•Templates which can show taxes, payment and shipping methods, and address formats which are particular to a country for which the site has been set up.
•E-mail notification messages leveraging Oracle Workflow can be provided in all languages, and configured by organization, user type, and site.

Interactive Selling and Ordering Options
Oracle iStore provides numerous options for interactive selling, user assistance, and ordering options for customers in the Customer Application application.

Highlights include:
•Sales assistance
•Online contract negotiation
•Support for unstructured contract terms
•Collaborative quoting
•Call-me-back functionality
•Sophisticated pricing
•Shared shopping carts
•Guided selling and product configuration online
•Product model bundles
•Opt in/opt out capabilities
•Real-time inventory checks and reservations
•Shopping lists
•Order cancellation
•Automatic e-mail notifications
•Express checkout
Note that some of these features require integration with other Oracle applications.

Order Management and Fulfillment
Supplied integration with the Oracle Order Management Suite’s powerful combination of order processing tools provide a complete range of order management and fulfillment functions.
Highlights include:
•Instant order transmission and fulfillment through Oracle Order Management
•Shipping and shipment tracking capabilities through Oracle Shipping
•Online automated payment processing through integration with Oracle Order Capture
•Order cancellation abilities
•Order returns
•Optional integration with Oracle Financial applications can provide accounting support
•Order tracking, including the ability to view invoice, shipping, and payment details
•Access to customer installed base
•Published quotes, sales assistance and Terms and Conditions fully integrated with Oracle Quoting

Marketing and Customer Tracking
Oracle iStore features a number of marketing and customer tracking options through its integration with other Oracle applications. These options include:
•Lead import functionality which allows the capture of valuable customer information from Oracle iStore shopping carts. Oracle Sales applications then can use the data in marketing efforts.
•Ability to post advertisements into Oracle iStore Customer Application bins, an option which leverages integration with Oracle Marketing.
•Ability to create deep link advertisements to the Customer Application in other Web pages.
Business Objects, Components, and Processes
Oracle iStore includes the following business objects, components and processes, which allow it to store data, process information, and communicate with the Oracle database and other Oracle applications:
•Business Objects — The schema for representing and storing customers, orders, product catalog and presentation elements. These entities are persistent, shared across all Oracle applications, and manipulated by Java Application Programming Interfaces (API) provided within Oracle iStore’s runtime services.
•Runtime Services and APIs — The coupling of certain common services available within all e-commerce applications (Oracle Foundation) and Java-based APIs (includes some PL/SQL APIs). This combination queries Oracle iStore’s persistent storage of objects and relationships and enables update operations.
•Configurable Customer Application templates — All Customer Application menus and pages are customizable using logical template names.
•Processing and routing templates — Working in combination with the Display Templates, the processing and routing templates contain the logic and appropriate business flows through the sites.
•Oracle BLAF — Both the Site Administration and Customer user interfaces offer the Oracle BLAF (browser look and feel) compliant user interfaces (UI). The Oracle BLAF UI provides consistent look and feel and similar task flows across the Oracle E-Business Suite applications. All section and item runtime templates are BLAF compliant.

Enterprise Asset Managment

2009-03-12T01:47:00.005-04:00

eAM Overview:

Oracle Enterprise Asset Management is part of Oracle’s 11i E-Business Suite and addresses the comprehensive and routine asset maintenance requirements of asset intensive organizations.

Using eAM, organizations can efficiently maintain both assets, such as vehicles, cranes and HVAC systems, as well as rotable inventory items, such as motors and engines. To measure performance and optimize maintenance operations, all maintenance costs and work history are tracked at the asset level.

eAM helps companies track, depreciate, and maintain their fixed assets. eAM enables asset-intensive companies to adopt maintenance strategies that optimize capacity and increase utilization, while lowering unit production costs. It improves operation performance and enhances safety through preventive, scheduled maintenance.

Oracle eAM provides organizations with the tools to create and implement maintenance procedures for both assets and rebuildable inventory items. Maintenance procedures are an integral part of an organization’s complete asset lifecycle management strategy, enabling an organization to optimize asset utilization. eAM enables users to optimally plan and schedule maintenance activities with minimal disruption to an organization’s operations or production. Importantly, it improves resource efficiency, enhances maintenance quality, tracks work history, and records all maintenance costs.

Oracle eAM tracks the performance of assets (including rebuildable, inventory items) using meters, quality plans, and condition monitoring systems. By effectively monitoring an asset’s operating condition, effective preventive maintenance strategies can be implemented. In addition to creating preventive maintenance schedules, users can create alternative maintenance strategies for seasonal or production capacity changes.

eAM’s comprehensive maintenance functionality supports asset lifecycle strategies for asset intensive industries, including Metals/Mining, Manufacturing, Pulp/Paper, Petrochemicals, Facilities, and Education. eAM eliminates the need for spreadsheets and disparate data repositories, by enabling companies to manage reactive, planned, preventive maintenance, and adopt a centralized, proactive strategy for managing asset maintenance across an enterprise.

eAM enables an organization to do the following:
•Create a preventive maintenance strategy
•Maximize resource availability, including both equipment and labor
•Optimize scheduling and resource efficiency
•Integrate with Oracle’s E-Business Suite for enterprise-wide solutions.

Asset Maintenance Goals:

1. Increase Productivity : Create a Preventive Maintenance Strategy and Maximize Resource Availability.
2. Decrease Maintenance Costs :Optimize Scheduling and Resource Efficiency , Minimize Rework 3. Reduce Accidents and Penalties :Ensure Regulatory Compliance ,Increase Workplace Safety

Types of Maintenance:

Reactive :
Small organizations that do not have have Maintenance Planners practice reactive maintenance. As equipment fails, Work Orders are generated and crews are assigned. Materials when in short supply and ordered as needed cause delays in response time. There is little or no preventive maintenance.

Preventive :
Organizations that practice preventive maintenance place a high value on asset performance and availability. These organizations have Maintenance Planners that plan both long and short-term requirements for resources and materials. These organizations have robust preventive maintenance plans that ensure that the assets are maintained on a regular basis to decrease the risk of failure.

Predictive
Organizations that are driven by heavy production demands or regulatory compliance invest heavily in predictive maintenance practices. The behavior and performance of assets is observed based on capacity requirements, engineered capabilities, maintenance strategies, and failure rates. These organizations employ a group of people to create a Reliability Centered Maintenance practice. These groups monitor an asset’s performance and capture data such as Mean Time between Asset Failures and Mean Time to Repair. This data then helps the maintenance organization better strategize their PM programs.

eAM Functionality:
1. Asset Managment.
2. Work Managment.
3. Inventory Managment.
4. Asset Performance and Forecasting.
5. Maintenance Budgeting.
6. Predictive Maintenance.
7. Maintenance Intelligence.

Integration with Other Modules:

Oracle Enterprise Asset Management is part of the Oracle E-Business suite, and directly integrates with Oracle Manufacturing, Oracle Purchasing, Oracle Property Management, Oracle Quality, Oracle Inventory, Oracle Human Resources, Oracle Financials, Oracle Fixed Assets, and Oracle Projects.

This enables you to strategically monitor resource and cost planning throughout the enterprise. Improvement programs can be enforced and reviewed to ensure compliance with industry standards by tracking problems through to resolution.

A well-planned maintenance environment depends on the ability of key personnel to view available inventory items, equipment, and skilled personnel. Because eAM is an enterprise solution, you can view the resource availability for assets that are used by operations and coordinate maintenance work to minimize operation disruption. Most importantly, Oracle eAM is designed for the maintenance user who performs the work. Using Oracle’s Maintenance User, trades people and supervisors with minimum training can easily perform their work.

Required Products
To implement Enterprise Asset Management, you must have the following required products installed:
•Oracle Inventory
•Oracle Bills of Material
•Oracle Human Resources
•Oracle Cost Management
•Oracle Manufacturing Scheduling
•Oracle Quality
•Oracle Work In Process
Optional Products

To implement Enterprise Asset Management, the following products are not required; however, they are useful in the overall robust eAM solution:
•Oracle Master Scheduling/MRP
•Oracle Property Management
•Oracle Financials
•Oracle Fixed Assets
•Oracle iProcurement
•Oracle Projects
•Oracle Project Manufacturing
•Oracle Purchasing
•Oracle Order Management
•Oracle Time and Labor .

eAM Business Flow :

Work Requests Entry
•Location, Asset ID, Owner Action/Activity, Current Work Alert, Condition Based Alert

Work Order Generation
•Work Order Types, Owners, Locations, BOMs, Standards, Copies, Assets, Components, PMs, Preplans

Task Planning
•Task level planning, Dependent Steps

Material Request
•BOM by Location, Asset Category, Component, Procurement, Catalogs, PO Detail, Item Statuses/Location Directs, Services, Rentals, Receipts

Resource Planning
•Assigned Owner, Crew, Craft, Skill Search/Selection, Duration, Contractors

Forecasting
•Asset Schedule/Availability, Capacity Performance, Work Impact on Production, Future Work, Budget Impact

Work Scheduling
•Workbenches with User Defined Filters for Folders and Sorts, Forecasted PMs, Available Resources, WO Generation, Project Scheduling

Work Order Update and Close Out
•Time Entry, Meter Readings, Inspection Data, Notes, Component Meter Reading.

Asset Performance
•Cost History, Work History, RCM Analysis, Design Capacity/Actual Performance, Predictive Maintenance, KPIs, Trending Analysis, Inspection History, Event Tracking, Capacity Impact.

Non-maintenance personnel within an organization report problems as Work Requests. The Work Request is then routed for approval and a Maintenance Planner is alerted to the need for repair or services.

The planner conducts a walk through to estimate the materials and trades people needed to conduct the repair. Some repairs may require that an asset be shutdown or brought into the shop. In such cases, the planner meets with Operations to determine the most appropriate time to remove the asset from service with minimal impact on production.

When the planner has determined the resources, materials, equipment, and time needed to perform maintenance, the Work Order is assigned to the crew that executes the work. Crew Supervisors pull the schedules defined by planners and assign the Work Order to the tradesperson.

Materials are issued, requisitions are generated, and time is entered against the Work Order operation as tasks are progressing. When the task is completed the tradesperson may enter additional information about the work as well as meter and inspection reading conducted during the course of the work. The Work Order is then closed.

Roles:

Enterprise Asset Management Administration :
The Enterprise Asset Management Administration role contains people who are generally responsible for entering information, often for other maintenance employees.
Information entered may include Work Order resource transactions, Work Order completion details, and Time and Labor hours. This person might have limited maintenance knowledge and is generally responsible for supporting the maintenance department by handling information entry.

Enterprise Asset Management User:
The Enterprise Asset Management User is anyone in an organization who may access eAM. This might include an employee who uses Work Requests to report problems, a Plant Manager who accesses eAM to review high cost assets and their work history, as well as a Maintenance User, such as a technician who accesses the Maintenance User Workbench to review his/her daily work assignments.

Self-Service Work Requests User :
The Self-Service Work Requests User is a person in an organization, often an employee (not involved in the maintenance department), who uses Work Requests to report maintenance problems. This person also uses Work Requests to check the statuses of problems that he/she has reported.

Maintenance User :
The Maintenance User is a maintenance person who is generally responsible for completing tasks that are assigned on a Work Order. This person reports maintenance problems using Work Requests, troubleshoots on jobs, and works on a team with other maintenance workers.

Maintenance Super User
The Maintenance Super User is generally a Maintenance Planner or Supervisor and is often defined as a "super user". A Maintenance Planner plans and schedules maintenance jobs, manages and balances work loads over time, manages preventive maintenance strategy and scheduling, manages material requirements, monitors availability, and coordinates strategies with other departments, such as Operations, Purchasing, and Inventory. A Supervisor manages a crew of maintenance workers, assigns jobs based on workers’ abilities and availability, inspects and verifies work, communicates with other departments, knows the current status of all jobs and assets, and is responsible for environmental health and safety.

This person has extensive knowledge of the Enterprise Asset Management system and is responsible for creating and scheduling Work Orders, including Preventive Maintenance Work Orders. This person updates Work Orders, orders parts, and completes operations and Work Orders.

for more information go through the eAM Userguide.

Oracle Transportation Management:

2009-03-12T00:51:00.005-04:00

What is OTM:

Oracle Transportation Management (OTM), enables organizations to meet their customer service and logistics objectives by managing all orders and shipments, both domestic and international, as a single, integrated global logistics business process across the multi-enterprise supply chain.

OTM is structured in such a way that three servers support the formatting, processing, and storing of data.

Webserver : Format - Formats the data from OTM.
Application ServerLogic:Logic - Process data in OTM.
Database :Data - Stores data in OTM.

OTM’s global, multi-domain data model enables multiple customers secure access to their individual information.
User access is granted through the use of a User Role. A User Role controls the data each user can access as well as functional security for that user within OTM. With the appropriate setup, a user can toggle between multiple roles without logging in and out of OTM.

Buy Vs Sell Shipment:

–Buy shipments : A shipper purchases the transportation from a carrier.
–Sell shipments : Used by third party logistics (3PL) providers, for example.
The 3PL plans their customer’s transportation, and then bills their customers for that service.

•Buy shipment: Client ' X ' Wholesalers tenders freight to Carrier 'A'. Carrier 'A' then bills 'X' Wholesalers for the service of moving the freight.
•Sell shipment: Client 'X' 3PL plans the transportation for Shipper 123 and then bills Shipper 123 for planning the movement of their freight.
Because of these two types of shipments, often you need to define whether a rate, for example, is a buy perspective or a sell perspective. Rates that are buy perspective are used for creating buy shipments, whereas rates that are a sell perspective are used for billing purposes.
It is only who is buying or selling transportation services that matter. E.g., As a shipper, you can sell goods on a buy shipment.

OTM Domains :
Within the database, OTM consists of one or more client defined domains. The domains share the database tables, but the domains own the rows. This defines each domain’s access.
Different users can see and use different data. For example,
•Service provider A can only see their rates and shipments.
•The supplier domain can only see their purchase orders.

Public Domain:
The public domain contains general information, such as currencies and country codes.
When installing OTM, certain information is always installed into the public domain, other information can optionally be installed, but you can also add your own specific information. This means that the public data you see in this class might not be available as public data in your installation of OTM.

What Domains to Create :
You set up domains to meet your business needs. For example, you may define domains by types of users.
•Service provider domain
•Sales domain
•Supplier domain

Child Domains :
You can define what access a subdomain has to the parent domain. By default, a parent domain can see all child data but not vice versa.
When domains are created, you can specify the amount of default data to be copied to the new domain. In a standalone domain, OTM copies all of the default data to that domain. In a reference domain, the default data is not copied; OTM points to an existing standalone domain to access the default data

What is OTM Status?

Throughout OTM, certain business objects have statuses associated with them.
Statuses consist of:
•Status type : -Represents a class of actions that can occur during the OTM process.
•Status value: -Associated with a status type and represents specific actions for the record.

Examples of business objects with statuses include location, order base, order release, shipment, and invoice.

•When an order release is created, OTM assigns certain status types and status values to it.
•As the order release is used for creating shipments and other OTM processes, OTM changes the status values accordingly.

Business Scenario
•You create multi-stop shipments for multiple orders of sporting goods, all originating in Chicago, and with a destination of either Atlanta or Boston.
•Shipments can be transported by the truckload carriers, ABC Trucking or XYZ Truck Lines.
•You tender the shipments to the selected carriers.
•Acting for the service provider, you will enter events against the shipments.
•You will match and approve the invoice and allocate the shipment costs back to the orders.

What is Shipment:
•Represents the movement of freight from one location to another.
•OTM creates shipments from order releases.

•An order release states the problem: what is the cheapest way to transport goods given these constraints?
•OTM presents the answer in the form of a shipment.

Once a shipment is created from an order release(s), you can monitor shipment activity, modify shipments, create shipments and shipment templates, and perform various shipment related tasks including:
•Tender shipments
•Change service provider
•Change equipment group
•Change arrival and departure times
•Add pickup and delivery appointment times

A planning parameter set contains planning parameters. Each planning parameter controls how OTM builds shipments and related actions.
Creating a new planning parameter set and assigning it to your domain ensures OTM uses the proper parameters to meet your business processes during planning and optimization.

What is Manual Modification?
To minimize manual changes to the shipment plan, it is important to keep your business rules and parameters up-to-date in OTM so that OTM makes the optimal decision for your business process.
•For example, if your distribution center changes its hours from a 24/7 operation to hours of Monday – Friday 7:00AM – 4:00PM, you need to update the calendar so OTM plans feasible shipments.
An alternative to modifying shipments is to modify you order constraints and re-plan your orders.

Shipment Actions :

Shipment actions allow you to add or change data on shipments,Some actions can be performed on several shipments at once, and other actions can be performed on only one shipment at a time.
Certain actions can only be performed at certain times based on the status; for example, you cannot choose the action Tender Shipment when the shipment is already tendered. But you can choose the action Re-Transmit Tender.

What is a Shipment Event?:
Service providers and other third parties can send information about shipments to OTM with a shipment event.

What is Tendering:
•When a shipment is tendered, OTM sends a notice to the service provider with an offer to move the cargo.
•There are different types of tendering in OTM:
–Tender to a specific service provider
–Spot bid tender
–Broadcast tender

Freight Payment
•The shipper buys the transportation services from the service provider.
•The service provider sends the shipper an invoice for the amount owed.

Customer Billing
Customer billing is used with sell shipments where the service provider sells shipments to customers.

Freight Payment Process :
As a shipper, you get many invoices from your service providers.
Before you pay them, you will want to:
•Bring the invoice information into OTM.
•Match the invoice to the shipment listing all the specifics for this invoice.
•Compare the requested amount on the invoice to the planned amount on the shipment and decide if you approve the invoice for payment.
•Send a voucher for the approved amount to the service provider via your accounts payable system.

What is Rate Manager?
Rates are comprised of four key components:
•Rate distance: Determines the distance from one location to another.
•Rate service: Determines the time required to transport goods from one location to another.
•Rate offering: Contains contract level data specific to a service provider.
•Rate record: Contains specific costing data from one location to another

Note: for more information go through the OTM userguide.

Advanced Collections

2009-03-11T00:05:00.017-04:00

Oracle Advanced Collections is designed to streamline the collections
activities.
Advanced Collection Overview:
• Improved view to Oracle Receivables.
• Real time Collections, no need to use reports.
• All Receivables information available.
• Data can be viewed at different levels.
• Drill down to transaction data.
• Allows you to search on multiple criteria.
• Automatically identifies deliquent customers.
• Create customer scoring.
• Review customer's Aging data.
• View Customer Collections Metrics. etc.

The module Oracle Advanced Collections uses is called Universal Work
Queue, the actual product name. However, the developers renamed it
on the Navigator where it appears as Collectors Work Queue, which
makes more sense to a collections agent. Within this curriculum, for
implementation/setup purposes it is called Universal Work Queue.
But for end-user/navigation purposes it is called Collectors Work Queue.

Key Features:

Collector work Queue

Collections Header

Customer Data Views

Profile and Metrics

History Tab

Aging Tab

Strategies

Notes

Scoring and Segmenting

The following responsibilities control access to functionality based on the role a user has in your company’s collections process:
Collections Agent:
•Allows collectors access the Collections application to perform tasks related to managing delinquencies and interacting with customers.
Collections Forms Administrator:
•Allows managers to run concurrent programs, set profile options, and set up Oracle Foundation and Oracle Sales functionality.
Collections HTML Manager:
•Allows managers access to strategies and dunning, plus later stage collections activities such as write-offs and bankruptcies. Managers also create dunning plans, scoring engines, and strategy and work item templates.
Collections HTML Administrator:
•Sets up Web Assistance and uses SQL queries to create new scoring components, fulfillment queries, and scoring or strategy filters.

Oracle Advanced Collections uses three types of collections management strategies:
1. Collections dunning plans defined in the Collections Dunning Plan module and executed through Oracle XML Publisher and Oracle Collectors Work Queue.
2. Collections strategies driven through the Collections Strategies module and related collections work items that appear in the Collectors Work Queue.
3. Collections campaigns driven through Oracle Marketing Online and optionally Advanced Inbound, and Advanced Outbound.

Migration of AR collections Functinality into Advanced Collections:

1. Collections Workbench in AR will be obsolete and replaced with like functionality in Oracle Advanced Collections.
2. Visibility to workbench data is migrated to advanced collections. Basic Collections functionality will be available to customers already licensing Oracle Receivables.
3. Oracle will provide migration scripts to Oracle receivables customer moving to Oracle Advanced Collections.

Benefits:

Improve navigation and visibility to delinquent customer.
Automated collections management processes.
Improved SOX Compliance.

Dependencies and interactions:

XML:
-Configure corresponding used for dunning and other letters.
Conurrent Processes:
-Scoring Program.
-Dunning Program.
-Correspondence and call back.
-Workflow Backgrond Process.
-Reconciliation.

Oracle Advanced Collections Module Integrations:
Oracle Receivables:
•To identify delinquent customers,
•Adjust transactions,
•Support posting payments, and resolve disputes
Oracle HRMS:
•Creating employees,
•Locations, and
•Organizations (required).
Oracle XML Publisher:
•To send dunning notices, invoice copies and other correspondence,
via e-mail, fax or print (optional).
•Existing Collections customers who are using Oracle 1-to-1 Fulfillment may migrate to XML Publisher.
Oracle iReceivables:
•Self-service access to invoices, payments and disputes.
Oracle iPayment:
•Credit card and bank EFT authorization and validation to take payments over the phone (optional) and for Leasing Management real-time payment processing (required).
Oracle Trade Management:
•Access to invoices and payments relating to trade marketing promotions (optional).
Oracle Lease Management:
•Collecting from delinquent lease contracts (optional).
Oracle Bill Presentment Architecture :
•To view invoices as they were presented online to the customer (optional).
Oracle Loans :
•Collecting from delinquent loans (optional).

Oracle Applications Foundation Modules:
•Notes for creating, saving and viewing customer notes (required).
•Interaction History for tracking of all customer contacts (required).
•Tasks for to-do’s, call backs, and so on (required).
•Collectors Work Queue (JTF component) for non-media work assignments (required).
•Territory Manager for work assignments based on sales territory qualifiers (optional).
•Resource Manager for defining resources and groups (required).
•Oracle TeleSales eBusiness Center for Customer Management (required).

Oracle Interaction Center Modules (when using Advanced Collections in a call-center):
•Collectors Work Queue (server component) for media-related work assignments (optional).
•Advanced Inbound for automating inbound call handling (optional).
•Advanced Outbound for automating outbound and preview predictive dialing call handling (optional) .
•Oracle Scripting for presenting collections call guides and scripts to support collections activities (optional).

Note:
The AR Collections Workbench was obsoleted in Release 12 and now you will need to use the OracleAdvanced Collections product instead. The basic Collections functionality is available in OracleAdvanced Collections without having to purchase a license for the product. However, if you wishto use the more complex functionality in the Oracle Advanced Collections, you will need thelicense. Oracle Advanced Collections now also handles the Dunning process instead of AR.

How to Restrict Finally Close control Action in Purchase Summary Form using Form Personalization.

2009-02-28T00:11:00.020-05:00

AP users are not able to match to PO to a finally closed PO’s as
PO User are Closing the PO with Finally Closed options without the

PO being invoiced.

When AP users try to match the invoice to the PO they get the

following error message.
Error: APP-SQLAP-97198: You cannot match to this Purchase order

shipment because it is finally closed.
To avoid such issues going forward PO and AP supers user have advised

IT team to Inactive the finally close option to users.

This can be achieved through Form Personalization as given below:

1. Go to Purchase Orders Summary form > query for a PO >

after the header of the PO is shown go to

Help >Diagnostics > Custom Code > Personalize.

the Form Personalization open.

Function Name = PO_POXPOVPO

Form Name = POXPOVPO

Debug Mode = Off
Steps:
- Seq = 1

- Description = Stop Final Close from Control Menu

- Level = Function

- Enable is checked.

Condition tab:

- Trigger Event = WHEN-VALIDATE-RECORD

- Trigger Object = PO_DOCON_CONTROL

- Condition =:po_docon_control.action= 'FINALLY CLOSE'

- Processing Mode = Both

Actions tab:

- Seq = 1

- Type = Message

- Description= Blank

- Lanuage=All

- Enabled is checked

- Message Type = Show

- Message Text = :You do not have the permission to Finally Close

Purchase Order.
Finally Closed is a restricted function that should

only be performed once A/P has been consulted

- Please use another function.

- Seq = 2

- Type = Property

- Language = All

- Enabled is checked

- Object Type = Item

- Target Object = PO_DOCON_CONTROL.ACTION

- Property Name = VALUE

- Value = Leave it blank.

- Save

In tab Condition in zone

Context can chose level= User and select users for which this

restriction to be done

Context:

Level Value

------ -------

Responsibility US Purchase Requestor

Responsibility US Purchase Manager

2. Logout/login with the user set on the personalize window and try

to finallyclose a PO. After press on Finally Close action a message

appear as given below:
:You do not have the permission to Finally Close Purchase Order.
Finally Closed is a restricted function that should only be performed

once A/P has been consulted - Please use another function.

click OK and perform other action and exist.

Datafix To open the PO from Finally close to Close:

===========================================

(Please test in your test instance before you migrate to Prod)

Data Fix:
=======

--1) Find po_header_id:

select po_header_id
from po_headers_all
where segment1 in ('1920','3116');

--2) Verify status on PO Header

select closed_code
from po_headers_all
where po_header_id in (971,3622);

--2a) Update closed_code from FINALLY CLOSED to CLOSED:

update po_headers_all
set closed_code = 'CLOSED'
where po_header_id in (971,3622)
and closed_code = 'FINALLY CLOSED';

commit;

--3) Verify status on PO Line

select closed_code
from po_lines_all
where po_header_id in (971,3622);

--3a) Update closed_code from FINALLY CLOSED to CLOSED:

update po_lines_all
set closed_code = 'CLOSED'
where po_header_id in (971,3622)
and closed_code = 'FINALLY CLOSED';

commit;

--4) Verify status on PO Shipment

select closed_code
from po_line_locations_all
where po_header_id in (971,3622);

--4a) Update closed_code from FINALLY CLOSED to CLOSED:

update po_line_locations_all
set closed_code = 'CLOSED'
where po_header_id in (971,3622)
and closed_code = 'FINALLY CLOSED';

commit;

--5) Verify Action History on Finally Closed record

select count(*) from po_action_history
where object_id in (971,3622)
and action_code = 'FINALLY CLOSE';

--5a) Remove Action History on Finally Closed record

delete from po_action_history
where object_id in (971,3622)
and action_code = 'FINALLY CLOSE';

commit;

6) Go to Purchasing Order Entry form. Query the PO. Navigate to
Special -> Control. Open the PO.

Note:Oracle does't recommend to re-open Finally Closed PO's as

this leaves a very poor audit trail and there is a potential for data

corruption in related tables.

Purchase Order Statuses

2009-02-04T20:44:00.010-05:00

Open: You can open at the header, line, and shipment levels.
Open for Receiving: You can reopen for receiving at the header,
line, and shipment level.
Open for Invoicing: You can reopen for invoicing at the header,
line,and shipment level.
Close: Purchasing automatically closes shipments for receiving
and invoicing based on controls that you specify in the Purchasing
Options window. Once all shipments for a given line are closed,
Purchasing automatically closes the line. When all lines for a given
header are closed, Purchasing automatically closes the document.
Close for Receiving: The Receipt Close Tolerance lets you specify
a quantity percentage within which Purchasing closes a partially
received shipment. For example, if your Receipt Close Tolerance
is 5% and you receive 96% of an expected shipment, Purchasing
automatically closes this shipment for receiving.The Receipt Close
Point lets you choose which receiving action (Received, Accepted,
or Delivered) you want to use as the point when Purchasing closes
a shipment for receiving based on the Receipt Close Tolerance.
For example, if you set a Receipt Close Tolerance of 5% and
choose Delivered as your Receipt Close Point, Purchasing closes
shipments for receiving when you have delivered 95% or more
of the ordered quantity.
Close for Invoicing: The Invoice Close Tolerance lets you specify
a similar quantity percentage within which Purchasing automatically
closes partially invoiced shipments for invoicing.
Unfreeze: You can unfreeze only at the header and release levels.
Delete: Before documents are approved, you can delete them or
their components from the document entry window. If you use
online requisitions, Purchasing returns all requisitions associated
with your delete action to the requisition pool. You can reassign
these unfilled requisitions to other purchase orders or releases
using the AutoCreate Documents window.
Cancel: Purchasing lets you terminate an existing commitment
to buy from a supplier by canceling document headers, lines,
shipments, or releases. When you cancel a purchase order entity,
you are unable to receive or pay for cancelled items and services,
however, you can pay for all previously received orders.
You also cannot modify a cancelled entity or its components.
Final Close: Prevent modifications to or actions against
completed documents, lines, and shipments by final closing them.
Final-closed documents are not accessible in the corresponding
entry forms, and you cannot perform the following actions against
final-closed entities: Receive Transfer, Inspect, Deliver, Correct
receipt quantities, Invoice, Return to supplier, or Return to
receiving.You can approve documents that include final-closed
entities, but you cannot approve documents that are final closed
at the header level. You can print final-closed documents.
Finally, you can Purge documents that were final closed at the
header level before the Last Activity Date that you specify when
you submit Purge.
Freeze: Freeze your purchase orders and releases to prevent
changes or additions while maintaining the ability to receive and
match invoices against received shipments. You cannot access
frozen documents in the entry forms.
Hold: Place documents on hold to un-approve them while
preventing printing, receiving, invoicing, and future approval
until you remove the hold.
Firm: When you firm an order, Master Scheduling/MRP uses
the firm date to create a time fence within which it will not
suggest new planned purchase orders, cancellations, or
reschedule–in actions. It continues to suggest reschedule–out
actions for orders within the time fence. If several shipments
with different promised or need–by dates reference the same
item, Master Scheduling/MRP sets the time fence at the latest
of all scheduled dates.You can firm orders at the document
header or shipment level. If you firm at the header level,
Purchasing applies this control to every shipment on the document.

R12 : SLA, SLAM, ASM, Ledger Sets, Data Access Sets

2009-01-17T01:17:00.025-05:00

What is Subledger Accounting(SLA):
================================
Oracle Subledger Accounting is a rule based engine for Generating accountingentries based on subledger transactions from all oracle applications.

Subledger acounting is a set of services for R12 that significantly enhance accounting support across the E-Business suite.

R12 introduces some of the changes that will be fully developed in Fusion, so close attention
to the impact of these changes is worthwhile. Sub-ledger accounting may be one of these key
changes.
When Release 12 was first released, there was a lot of publicity about the move from the Set
of Books concept to Ledgers being so fundamental, however experience suggests that the
introduction of sub-ledger accounting (SLA) probably has even more impact.
For those not familiar with SLA, it is a new product in Release 12 and a major change, (although it may be almost transparent to many end-users). It is both the rules and the engine that generates the accounting representation of your transactions, and it offers some
wonderful opportunities to meet very specific accounting requirements in supportable ways. Participating subledgers include Payables, Receivables, Projects, Assets, Cash Management ,
Purchasing, Cost Management and Process Manufacturing.
In terms of its mechanics, SLA is a new schema into which all accounting entries are processed before being interfaced to the General Ledger - and so it alters the way reconciliation and month-end processes run. This simple statement is both fundamental and important - because many of the skills we have learnt over years to address accounting issues at period end may have to be modified.
Do not underestimate this change and do invest the time to simulate month-end processes
during Testing (CRP and UAT) . Companies should move from utilising Account Generators in Release 12 to representing their accounting rules in the Sub-ledger Accounting Engine. SLA rules that are in place in Release 12 will be protected in an upgrade to Fusion.

Subledger Accounting Methods (SLAM):
===================================
The Subledger accounting method is required if using Oracle Subledger accounting.
A subledger level secondary ledger requires a subledger accounting method for both the primary ledger and the secondary ledgers.

The accounting method can be changed at any time, it will only affect new journals,additional accounting methods may be defined. This is done in subledger Accounting.

There are 5 Subledger Accounting Methods:
1. Accrual with Encumbrance Accounting
2. Cash with Encumburance Accounting
3. Standard Accrual (Default)
4. Standard Cash
5. US Federal Accounting.

All upgraded ledgers in Release 12 will have a subledger accounting method assigned during the upgrade. Any reporting currencies assigned to the ledger inherit the subledger accounting method from the source ledger. The subledger accounting method enables Oracle General Ledger to integrate with Oracle subledgers using Subledger Accounting.

All upgraded, non-publicsector ledgers will have a subledger accounting method assigned called Standard Accrual or Standard Cash.
All upgraded public sector ledgers will have a subledger accounting method assigned called Encumbrance Accrual or Encumbrance Cash.
For US Federal customers, all upgraded ledgers will have the US Federal Accounting subledger accounting method assigned to them.

What is a subledger:

Subledger are applications to manager operational transactions with financials impact.Subledger stores accounting at transaction level of details. Subledger post summarized activity information to a GL Periodically to maintain centralized account balance for the
company.

What is Accounting Setup Manager (ASM):
===================================
It is one of the main feature of the Ledger Architecutre introduced
in R12, which replaces teh Set of books from using a web based
interface.

Accounting Setup Steps:
==================

Accounting Setup Manager(ASM) is the central place where all the
accounting setup is defined and maintained for:
- Legal Enties.
- Operating Units
- Ledgers.
- Reporting Currencies
- Subledger Accouting.
-Inter and Intra Balancing Segments.
- Sequencing (Accounting and Reporting)
- Other Accounting options like retained earning account, suspense
account, currency conversion types etc.

Accounting Setup Manager Benefits:

Centralized Accounting Setup for Financials
–Define all of your accounting-related setup in a central location
–Reduce setup errors
–Have clear view of implementation
Increased Efficiency
–Access accounting setup information more quickly now that it appears centrally in one location.
Simplified Processes
Improved Efficiency
Strengthens business’s corporate legal structure
Streamlined on-going maintenance
User friendly interface
Facilitates internal control management.

What is a ledger:
The Ledger represents an accounting representation for an organizationthat is accountable in a self- contained way. The ledger represent the core of a company's Financial records where every transaction flow thrugh. " A Legal Entity accounts for itself in a ledger"

Primary Ledger :
===========
-Main , Record keeping ledger
- Defined by 4C's.
- Chart of Accounts
- Accounting Calendar
- Primary Currency
- Subledger Accounting Method - New 4th C (Also Called Convension)

There are 3 types of ledgers: Primary , secondary and reporting currency ledgers.

1. Primary Ledger (PL): it is the main ledger and has the most details of information. It can have more than one secondary ledger assigned.

2. Secondary Ledger(SL): it is optional and differs in one or more of the 4C's from the PL.It provides an additional accounting representation of the PL to comply with legal requirements.
The SL can only be assigned to one PL.

3. Reporting Currency(RC): Used when the only element that differ from the PL is the Currency. it is stored in the tables as a ledger but does not need to be setup as a ledger via ASM.

Primary and secondary ledgers can have RC's assigned. if a RC has not been assigned to a PL or SL, when a transaltion is run in a ledger the reporting currency is automatically added
to the ledger setup.

The Secondary and reporting currency ledgers stores additional accounting representations of the information present in the primary ledger. There are different level of detail in which this information is stored, which are called Conversion levels.

Ledger Sets:
Ledger Sets enables you to group multiple ledgers that share the same COA and Calendar Combination. Essentially, Ledger Sets allow you to treat multiple ledger as one. for example you can open and close periods for multiple ledgers in a ledger set in a single submission by submitting the new Open and Close Perdios Program from the Submit Request Form.

Data Access Sets:

Data Access Sets enable you to specify read only or read and write access for a legal entity, ledger, Balancing Segment Value or Management segment Value.

Oracle R12

2009-01-16T23:07:00.013-05:00

R12 is the latest and most advanced version of the E-Business Suite.

R12 is Defined as Global Business Release Focusing on working , Thinking and Managing Global Organization.

Requirements:

============

•Improve support for shared service operations.
•Ease access to aggregated data for management reporting.
•Ensure accurate accounting, tax and currency treatment of transactions.

Results:

=======
•A single responsibility to access and transact on multiple organizations .
•A single ledger to manage multiple currencies.
•Ledger sets to manage accounting processes across ledgers.
•Centralized rules engines for tax, accounting and inter company.
•A separate and simple payment creation and delivery solution.
•Centralized trading partners (suppliers, banks, first party legal entities).
•Simplified reporting via XML Publisher.
•Netting across trading partners.

Centralized Financials Architecture:

==========================

TOP Changes in Oracle Release 12:
===========================
1.Multiple Ledgers- From Set of Books to Ledgers and Ledger Sets.
2.Legal Entities and Accounting Setup.
3.From Product Accounting to Subledger Accounting. (SLA)
4. Shared Service Access Controls - From Multi-Org to Multi-Access- MOAC (Multi Org Access Control) - Role based access to Operating Unit.
5.Oracle Payments and Banking - Centralized Bank Model- Centralized Payment Processing (Shared Services Disbursements and Receipts)
6.From Multi-Tax Codes to E-Business Tax(EB Tax).
7. Intercompany using Advanced Global Intercompany (AGIS).

Changes between 11i and R12 high level details:

Order To Cash

2008-10-13T17:44:00.038-04:00

Order to Cash Process flow:

The Customer Order is received to the time the product or services

is paid for:

Customer:
As a party to a contract, the customer is responsible for oversight

of the contract, payments and any agreed-to obligations with the

contractor. The organization which is in the process of placing an

order with the company.

Creating Order:
The following information is to be provided while entering an order:
- Order details
- Customer information
- Item information at line level.

Booking an Order:
In Order Management, booking is workflow enabled. The application

comes seeded with two types of Booking processes:
- Manual Booking Process
- Deferred Booking Process.

Pick Release:

An order cycle action to notify warehouse personnel that orders are

ready for picking.

Pick Confirm:
Executes the sub-inventory transfer that moves the material from its

source location in the warehouse to the staging location.

Ship Confirm:
To enter shipped quantity and inventory controls for specific

shippable lines. You can ship confirm the same delivery/departure

repeatedly until you close the delivery/departure. Once it is closed,

no more changes can be made into a delivery/departure.

Interface Trip Stop:
Updates the quantity in inventory.It runs two interface programs

- Inventory interface

- Order management interface program.

Auto Invoicing :
=============

The Invoicing workflow activity transfers shipped item information

including quantities, selling prices, payment terms, and transaction

dates to Oracle Receivables, which processes invoices and accounts

for revenue.

Submit the Autoinvoice Master or Import program to transfer

transactions from the interface tables to Oracle Receivables.

- Autoinvoice Master Program
Autoinvoice Master Program selects and marks records in the

interface tables, for processing based on the parameters entered.

Once the records are selected, the Autoinvoice Import Program is

spawned. Autoinvoice Master Program does not provide any report

or output. The Master program allows running of several instances

of Autoinvoice to improve system performance and to facilitate

importing of transactions quickly.

- Autoinvoice Import Program

Autoinvoice Import Program validates the selected records and

creates transactions. Any record that fails validation is left in the

interface table with an error code. Depending on the overall setup,

related records may be rejected as well. An output file called

Autoinvoice Execution Report and Validation Report, can be viewed

by clicking the View Report button in the Requests Window.

Order Management Interfaces:

- Order Import.

- eComerce Gateway.

- Purchase Release.

- Invoice Interface.

- Inventory Interface.

- Shipping Interface.

Order Management Key API's

- Shipping Execution (SE)

- Configurator (CZ)

- Customer Relationship Management (CRM)

- Pricing (QP)

- Release Management (RLM)

- Configure to Order (CTO, formely ATO)

- eCommerce Gatway

- Process Order.

Other API's Interface:

1. Purchasing (PO)

2. Advanced Planning and Scheduling (APS)

3. Accounts Receivables (AR)

4. Inventory Managment (IM)

5. Shipping Execution (SE)

6. Configurator (CZ)
7. Customer Relationship Management (CRM)
8. Pricing (QP)
9. Release Management (RLM)
10 Configure to Order (CTO)

Back Ordered:

If the items are coming back from the staging area to the

source sub-inventory.

RMA:

If the material is coming back from customers after reaching

them. Then we do RMA to accept that back.

Drop Ship:

Supplying material to your customer by getting it from a

external source(supplier).

Internal Sales Order:

Getting material from any of the other organization by means

of a internal requistion.

Basic Order Process Flow:

Line Status Flow:

================

A Standard flow Status are:

Entered (OM): Order is saved but not booked.
Booked (OM): Order is booked.
Scheduled (OM): A user can customize the Workflow to show

the Scheduled status which indicates that the order line has been

successfully scheduled. When the ship line logic starts, the order line

status changes to Awaiting Shipping.

Awaiting Shipping (OM): Order is booked but lines are not yet

picked.

Open (OM): This status of a delivery on the Additional Line

Information form indicates that none of the delivery lines associated

with that delivery have been ship confirmed.

Shipping Execution - the delivery line status flow:

Ready to Release (SE): Order line is booked and passed to

Shipping Execution. It is now a delivery line that is eligible for Pick

Release.

Released to Warehouse (SE): Pick Release has started but not

completed. Either no allocations were created or allocations have

not been Pick Confirmed.
Not Ready to Release (SE): A delivery line may be in this status

when it is interfaced manually into Shipping, is not scheduled and has

no reservations. When lines are imported automatically from Order

Management this status is not used.

Backordered (SE): The delivery line is pick released but no

allocations were created or partial allocations occurred.

As an example, if a delivery line has a quantity of 100, and at pick

release only 25 are available for allocation, the original delivery line

splits to create a new line (quantity of 75) for the unallocated portion

with a status of Backordered. The quantity on the original delivery

line changes to 25 to reflect the allocated portion with a status of

Staged/Pick Confirmed.

Staged/Pick Confirmed (SE): The delivery line is successfully

pick released. It occurs after pick confirm to indicate subinventory

transfer from source location to staging location is complete. Lines

staged until they are ship confirmed. Both Backordered and

Staged/Pick Confirmed status provide the ability to perform

opportunistic cross-docking for warehouse organizations with Oracle

Warehouse Management System (WMS) installed.

Shipped (SE): This line status indicates that the delivery

associated with the delivery line(s) is ship confirmed.

In Transit (SE): This delivery status indicates that the delivery

associated with the line is ship confirmed and the pick up stop is

closed.
Confirmed (SE): This delivery status indicates that the delivery

line is either shipped or backordered and the trip stops are open.

Picked (OM): Pick release has completed normally (both allocation

and pick confirm). The delivery associated with the delivery line(s)

may have also been Ship Confirmed but the Delivery may not be set

in transit and the Trip may not be closed.

Picked Partial (OM): This status occurs when a delivery line is

not allocated the full quantity during Pick Release and Ship Confirm

has not occurred.

Shipping Execution pushes status information to Order Management

once Ship Confirm is completed:

Shipped (OM): The delivery associated with the line is Ship

Confirmed. The Delivery status is set to in transit. This status

appears in the Additional Line Information at the Pick Status field.

Interfaced (SE): If delivery was sourced from Oracle OM: The

delivery line is shipped and the OM Interface and Inventory Interface

concurrent processes have completed.

Interfaced to Receivables (OM): Invoice Interface has been

launched. Order Management writes information to Receivables

tables.

Partially Interfaced to Receivables (OM): This status is used

in a PTO flow and indicates that the particular PTO item is required

for revenue.

Closed (OM): Closed indicates that the line is closed. It does not

necessarily indicate that the line is interfaced to Accounts Receivable

(AR) since you must “close line” activity in a no-bill flow.

Canceled (OM): Indicates that the line has been completely

canceled. No further processing will occur for this line.

OM to AR:

==========

1. Create Item.

2. Create Price List.

3. Inventory increased/Increase on-hand Qty.

4. Create Sales Order.

5. Release Sales Order.

6. Pick Release.

7. Inventory Reduced.

8. Ship Confirm/Shipping notice Generated (ASN).

9. Run Auto Invoice/Invoice Generated.

10. Review Invoice.

11. Invoice sent to customer.

12. Payment Received from Customer.

13. Create Receipts

14. Apply Receipts.

15. Run reports and Reconcile accounts.

Inventory in Stock - Ship from Stock

Inventory Provided by Outside Suppliers:

- Ship to customer directly from the supplier - Drop ship.

Inventory Provided by Outside Supplier:

- Supplier ships the product which is received in inventory,

the shipment is done to Customer - Back to Back.

Internally:

IRISO - Internal Requistion Internal Sales Order

CRM- OM:

========
OM Process Orders entered through the CRM Suite:

- Oracle Marketing

- Mobile Field Sales

- iStores

- Telesales

- Mobile Field Services

- Oracle Services.

Oracle Apllications provides the capability to intergrateback office

modules (ERP) with front office modules (CRM).

OrderManagement is specifically tied to Quote Management, Service

Orders, and Mobile Service charges via Order Capture.

Information from sales order Sales credit are integrated to Sales and

Marketing modules.

Information from sales orders also integrate to the Service product

suite for instillation details and service program information into the

Service InstallBase.

Multi- Org

2008-10-11T22:23:00.014-04:00

What is Multi-Org:

Multi-Org is a way to consolidate your operations under one

installation of Oracle Apps and yet keep transaction data securely

confined within individual operating units.

Multi-Org is an application server side enhancement that enables

multiple business units in an enterprise to use a single installation of

Oracle applications products while keeping transaction data separately

and secure.

Multi-Org Features:

1. Architectural model that supports multiple financial sets of books

in a single installation.
2. Data security by Operating unit.
3. Global Customer and supplier registries.
4. Automatic intercompany accounting entries for sales transactions

booked in one organization and shipped out of another related

organization.

When would you use Multi-Org:

1. Multiple Set of Books.
- Global company with different set of books.
2. Multiple Legal Entities within a Set of Books.
3. Multiple independent Operating Units.
a. Additional requirement to secure data by operating unit
i) Regulatory Requirements
ii) Business Requirements
- Data security issues, etc.
iii) Other Drivers
- Bank code security, purchase aggreements, etc.
b. Inter-company accounting is supported.

Multi-Org Basic Elements:

1.Business Group:
This is an organization that represents the consolidated enterprise, a major division, or an operating company and has no accounting impact. The Business Group partitions Human Resources (HR) information and the Purchasing approval hierarchy. Multiple legal entities can relate to a single Business Group.

2. Set of Books:
This is the highest level which impacts the accounting side of the Business. Multiple Sets of Books may be associated with a Single Business Group. Oracle Applications secure accounting information, such as journal entries and account balances, by Set of Books.

3. Legal Entity:
A legal entity represents a legal company for which you prepare fiscal or tax reports. You assign tax identifiers and other legal entity information to these types of organizations. Each legal entity may be linked to one and only one Set of Books. However, more than one legal entity may be linked to the same Set of Books.

4. Operating Unit:
An operating unit represents a Business Unit or a group of Business Units that share an Oracle sub-ledger application or suite of applications (AP,AR PO, OM). Oracle Applications secure transactional data, such as Customer and Vendor site information, Payables and Receivables invoices, and Payments and Receipts, by operating unit.

5. Inventory Organization:
An organization for which you track inventory transactions, balances, manufacture or distribute products. Examples include manufacturing plants, warehouses, distribution centers, and sales offices.

Multi-Org Impacts:

General Ledger:
- Not impacted by Multi-Org. However, because the G/L sits above the Operating Unit level, its has a direct impact on the Multi-Org design (ie: you can point multiple A/P Operating Units to a single Set of Books, but you Cannot point a single A/P Operating Unit to multiple Sets Of Books).

-The more Sets of Books that are created will mean the more A/P Operating Units that need to be configured to support the General Ledger design. You can see a graphical example on the following slide.

Accounts Receivable:

-A Single Installation to Support AR Functions in multiple Countries.
-Allow for Sharing Business Information Such as Customer Master Header Information at Global Level.
-Secures Transaction Data (e.g.: Invoices and Receipts) at Operating Unit Level.
-Facilitate Inter-Company Transactions.
-Multiple Setups for Multiple AR Operating Units (e.g. Auto-Accounting and Transactions Types).
-Allow for Configuration of Diverse Processes for Different AR OU.
-Cash Receipts are applied by Operating Unit

Accounts Payable:

-A Single Installation to Support AP Functions in Multiple Countries.
-Allow for Sharing Business Information Such as Supplier Master Header Information at Global Level.
-Secures Transaction Data (e.g.: Invoices and Payments) at OU Level.
-Facilitate Inter-Company Transactions.
-Multiple Setups for Multiple AP Operating Units.
-Allow for Configuration of Diverse Processes for Different AP OU's.
-Payment Runs are by Operating Unit.

Project Accounting:

-Secures data at the project level.
-Allows for the configuration of accounting rules to support site specific accounting conventions.
-Limits list of values for ease and accuracy of data entry.

Fixed Assets:

-No Impact, since Assets is not multi-org enabled
-Data is secured at the asset book level.
-Intend to use Projects and its native integration with Assets to drive assets to the proper asset book.

Purchasing:

-Contracts, Blanket agreements, the purchasing hierarchy and the vendor sites are all maintained at the Operating Unit level.
-All demand coming from Inventory Organizations is sourced thru the Operating Unit that the Inventory Org is assigned to.
-In order to do centralized purchasing, all Inventory Organizations that share the same purchasing organization preferably are grouped into one Operating Unit
-If these Inventory Orgs are not grouped into one OU, maintenance of contract, sites, hierarchies, etc. becomes problematic

Order Entry:

-Order Lines are secured and processed at the OU Level.
-Allows Order Types to be setup and maintained by operating. This reduces the risk of clerical error during the order entry process.
-Price List Information is not secured by Operating Unit, but is available across the entire instance.
-If Price list information needs to be secured at the OU level, a low level customization will be needed in order to accomplish this.

Inventory, Purchasing (Receiving), MRP, BOM, WIP:

-Item information and accounting transactions are secured at the Inventory Org level.
-These applications (With the exception of Purchasing), sit below the Operating Unit level.
-Internal Shipping Networks can be setup to facilitate Inter-Org inventory movement.
-Multiple Inventory Orgs can be setup for a single Operating Unit. However, an Inventory Org cannot point to more than one Operating simultaneously.

Users:

- Users must vacillate between multiple Responsibilities to accomplish their daily tasks in R11i.

Shared Services:

-The Multi-Org architecture is not setup to facilitate a Shared Services environment in R11i releases. - Oracle has addressed this issue in R12 using MOAC - Multi-Org Access Control Concept.

Oracle TCA - R12

2008-10-04T16:45:00.058-04:00

TCA- What's New in R12:
======================
What is Oracle TCA:

Trading Community Architecture (TCA) is a model for maintaining
information about parties and customers who belong to an
enterprise's commercial community. Parties can be people or
organizations that can enter into business relationships accross
the e-Business Suite.

The main purpose of TCA is to provide a single source of information
in the TCA Registry for all Oracle e-Business Suite Applications.

R12 - Intergration Capabilities:

R12- TCA:

Trading Community Manager:

This is predefined for country United States in any new instance as
STATE, COUNTY, CITY and POSTAL CODE. For other countries,
you can simply create the geography structure depending on your
requirement or just use the Copy Structure feature to create the
geography structure based on the geography structure of another
country.

First query the country for which you want setup Address Validation
by Country Code or Name.

Real-time address validation validates addresses during address
entry. For Oracle Trading Community Architecture, and other
Oracle E-Business Suite applications, this validation is based on the
information and setup of Geography Hierarchy.

Real-time address validation is performed only for addresses created
in the HZ_LOCATIONS table and countries that are set up in
Geography Hierarchy.

Geography Hierarchy Overview:
Geography Hierarchy is a data model that lets you establish conceptual parent-child relationships between geographies. Oracle Trading Community Architecture (TCA) and other Oracle E-Business Suite applications can leverage Geography Hierarchy for various uses related to locations, such as real-time address validation and tax calculation.

The geography information is centrally located in TCA and share among all the applications.

An ability to create and maintain hierarchies between multiple address elements or tax authorities for the purpose of real time address validation and/or tax calculation.

- Does not include street level Data. - Hierarchies can be created from Tax Vendor provided Data using utility provided by eBusiness Suite Tax Application. - Users can further extend the hierarchies that were created based on data provided by Tax Vendors.

Configuration: - Define Country specific structures for geographic hierarchies. - Manage Geography Details. - Manage Data Validation Levels during Data Entry.

Geography Validation: For example, for the United States, you specified the North America address style for HZ_LOCATIONS addresses. Then for that combination, you map the US country structure to HZ_LOCATIONS attributes, and specify that Country, State, and Postal Code values are used for geography validation.

When the user enters a US address using this address style, the address must have the correct country , state, and postal code combination, based on Geography Hierarchy data, to be considered geographically valid. Use the Geography Validation check box to specify which address elements are mandatory during address entry, based on the geography validation level for country selected.

The Geography Validation Level for Country can be:
1. Error: Only completely valid addresses can be saved, with all mandatory address elements entered.
2. Mandatory Fields Only: Invalid addresses can be saved without warning users, but only if users enter a value for all mandatory addresses elements, as defined by the geography types selected for Geography Validation usage.
3. No Validation: All addresses can be saved including incomplete and invalid addresses.
4. Warning: Invalid addresses are saved after warning users.

The Geography Validation usage determines which address elements re mandatory during ddress entry, based on the geography validation level selected. For example, if the validation level is Mandatory Fields Only, then users must enter address elements that have Geography Validation usage, but the address can still be saved if values are invalid.

Tax Validation: For example, for the United States, you had specified the North America address style for HR_LOCATIONS_ALL. Then for that combination, you map the US country structure to HR_LOCATIONS_ALL attributes, and specify that County, State, and City are used for tax validation. When a sales transaction involves an address with the North America address style, the address must have the correct county, state, and city combination, based on Geography Hierarchy data, to be considered valid for tax calculation.

Important: For either usage, do not skip more than one consecutive level unless you are certain that the selected geography types can uniquely identify geographies. For example, the country structure is: State, County, City, and Postal Code, and you want to select just State and Postal Code for geography or tax validation. However, for the combination of California and 94065, the city can be either Redwood Shores or Redwood City. In this case, you should also select at least City for geography or tax validation.

AR - New Customer User Interface:
- Customer Standard form that has been existing till R11i is finally gone.
- Oracle Introduced a brank new HTML UI built using OA Frame works leveraging TCA that can be used to manage Customers, Accounts, etc.
- New UI Displays both Party Level as well as Account Level information
which is sepearted into Customer Overview and Account Overview.

Find Customer screen now uses DQM (Simple and Advanced Search
Match Rules) similar to what you see in Customers Online or Customer Data Librarian.
- After search, you can create new customer or see customer
overview. From here you can add accounts or modify accounts
and so on.
- You can update customer information from customer overview
page.

R12- Customer Tab Structure:

R12 Supplier is part of TCA:

Supplier can be setup from many different application, but the
datails stored in a single repository called the Trading Community
Architecture.

TCA Provides a single, common definition that can be used to
identify customer,suppliers and organziations that provide you with
goods or services.

Supplier information is shared by the following applications.

1. TCA:
All Supplier information is defined in TCA.

2. Purchasing:
Purchasing uses supplier defaults, such as freight terms, shipping
details,on requisitions, purchase orders, request for Quotations, etc.

3. Payables:
Payables uses supplier defaults, such as method of payment and bank
account information during invoice entry and payment processing.

4. Fixed Asssets:
Assets maintains the supplier name and number for each asset record.

5. Property Manager:
Property Manager exports lease invoces for suppliers to payables so
they may be paid.

6. iSupplier Portal:
iSupplier Portal allows you to grant acces to supplier to review order,
receipt and payment details for the supplier. Supplier can enter
planned (with PO) or unplanned (without PO) invoices and update
supplier information.

MOAC: if you are using Multi organization support feature, you
cannot enter the following information at the supplier level, only at
the supplier site level they can be entered.

- Liability Account
- Prepayment Account
- Distribution set
- Invoice Tax Code
- Future Dated Payment Account.

As we know in R12 Supplier is part of TCA , thus the link between
PO_VENDORS and HZ_PARTIES is PO_VENDORS.party_id.
The link betweenPO_VENDOR_SITES_ALL and
HZ_PARTY_SITES is PO_VENDOR_SITES_ALL.party_site_id.
When a Supplier is createdRecord will be Inserted in HZ_PARTIES.
When the Supplier Site is created Record will be Inserted in
HZ_PARTY_SITES. When Address is created it will be stored
in HZ_LOCATIONS.

Bank Model is part of TCA in R12.

If we compare the bank setup in R11i and R12, we can notice
that banks was utilized into three different places Finance ,
Payroll and Treasury, which requires altogether a different
setup.

We have notice in 11i there was functionality in which Payables in
which we will create an employee type supplier from HR data and
it will contain name and address info but not bank information.

The reason for this is that HR/Payroll does not store the bank
information in a standard way that makes the integration possible.

Bank Account Data Model in R12 is consolidated in TCA Model.

Overview of Bank Model:

The Bank Model feature allows you to define and keep track of all
banks accounts in the e-Business suite in one place and explicity
grant account access to multiple operating Units and users.

The bank model is based on the following concept:

- Centrally located in Cash Managment.
- TCA Parties associated with bank branches.
- Owned by LE's.
- Applications that use Bank Accounts are AR, AP, Treasury
and Payroll.
- Grouped by Country.

In Prior release AP owned banks, bank branches and bank accounts,
such bank accounts could be used by AR, Payroll and Treasury.
In R12, Banks and Bank Branches are created as TCA parties,
The bank Accounts are associated with Bank Branches but reside
with in the Cash Management Application.
During the Bank Account creation, you are able to define in which
application this bank account can be used.

TCA Tables:

Bank Accounts will be stored in a new table called
CE_BANK_ACCOUNTS and will be located at a Bank Branch.
The new table which hold the bank information are as:
CE_BANK_ACCOUNT:stores bank account attributes
CE_BANK_ACCT_USES_ALL : This stores the bank account
use attributes specific to Operating Unit (AR, AP) and Legal
Entity (Treasury).
CE_GL_ACCOUNTS_CCID :The accounting data pertaining to
the bank account use will be stored in the table.

Oracle Trading Community Architecture (TCA)

2008-10-02T15:45:00.042-04:00

Trading Community Model:
Trading Community is defined as a group of entities taking part
in commerce.
Trading Community includes both persons and Organization.

What is Oracle TCA?
TCA: Trading Community Architecture.
Oracle’s Central Customer Data Repository underlying all
Oracle Applications. TCA is a Model, an Architecture and
NOT a Module.

Evolution of TCA Release:

Oracle Trading Community Architecture (TCA) is a data model
that allows you to manage complex information about the
parties, or customers, who belong to your commercial community,
including organizations, locations, and the network of hierarchical
relationships among them.

The below diagram depicts the relationship among the entities
of Trading Community.

Entity Relationship:

TCA Key Entities:

1. Parties:
“Party” is an entity in the Trading Community Model that can
enter into business relationships.
A party is a person, organization (branch, subsidiary, legalentity,
holding company, etc) or relationship (this is a relationship
between two parties).

2. Party Relationships:
A relationship is a state of connectedness between two parties ,
Each relationship consists of two entities; a subject and an object.
Relationship - Associates any two parties

Binary relationship between two parties Inter-Company and
Intra-company relationships Non-business relationships too Are
reciprocalUnlimited in number Dynamic in natureBoth seeded or
user-defined Relationship Types Relationship itself is stored as a
partyAny number of relationships between two organizations
(org-to-org) or two persons (person-to-person) or anorganization
and a person (org-to-person).

The relationship model enables you to :
- Understand the complex relationships among members of your
trading community.
- Use this information to make better business decisions.

3. Customer Accounts:
“Customer Accounts ” is used to represent a party with whom
the deploying company has a selling relationship, regardless of
whether anything has actually been purchased or serviced.
An Account cannot be created without party.

4. Locations:
A geographic location, physical place, usually with an address.
Any number of location types. (e.g., bill-to, ship-to, mail-to).
Allows for restricted use of a location (begin / end date).

Is a Party Site with one or more site uses Only one of the
Party Sites can become an “Identifying Address” for the Party
An Account Site in the context of an Account .

Geographic location including Spatial content Many to Many
relationship between party and location.

Party Site: Links a Party with a Location and describes the usage
of that Location (e.g., mailing address, billing address, home address, etc.).
Parties may be associated to one or more Locations and any one
location may have one or more uses.

5. Contracts.
A Person related to an Organization, this can be a relationship
between an organization and a person as well as between two people.

Party Vs Account:
====================

The Concept of Customer is sepearted in two layers ,
- Party Layer.
- Account Layer.

CRM applications are referring to the Party layer when they
refer to “Customer”.
ERP Applications, on the other hand, are referring to the
Account layer, when they refer to “Customer”.

The word “Customer” is the combination of both the “Party layer”
and the “Account layer”.
- Party layer exists independent of any selling or buying relationship.
- Customer Account layer exists in the context of a Party and only
when a selling relationship exists.

The Party Layer captures intrinsic truths about a person or
organization. The Account Layer captures the details describing
the Party’s financial relationship with the implementing
organization. The Account Layer cannot exist without the Party Layer.

Party:
The unique set of truths about a person, organization, group or
relationship. An entity that can enter into a business relationship.

Person - A unique individual (dead or alive) of interest to the owner
of the software.
Organization - A legal entity recognized by some government authority.
Group - a combination of two or more people, organizations or
groups of created for the use of the owner of the software.
Relationship - links two Parties, regardless of type.

Once a Party Relationship is formed, it may become a Party
in its own right. A Party can belong to any number of relationships.

The combination of a party and its account(s) is considered a customer

Customer Module Overview:
• TCA is designed to encapsulate all members of a ‘trading community.’
• A trading community may include customers, prospects, suppliers,
distributors, resellers, consortiums, etc.
• TCA not only allows for the tracking of relationships between the
implementing organization and its trading partners, but also tracks
relationships between the trading partners themselves.

Customer Standard Strucutre in 11i.:

Account Layer - Components:
===========================
Account:
The attributes of the implementing organization’s financial
relationship with a party, Cannot exist without a Party.
Account Site:
A Party Site that is used within the context of an Account.
Account Site Use:
Use of an Account Site (e.g.billing, shipping).
Account Relationships:
Established between accounts to allow sharing of billing, shipping,
and pricing information.
- One way or bi-directional,
- 1:1 Relationships – not used for multiple levels of a hierarchy .

Party Layer components:
================================
Party: An entity that can enter into a business relationship
- Person (Mr SMITH).
- Organization (ABC) .
Party Relationship: A relationship between two parties .
- Mr. Smith “Contact Of” ABC
- ABC Handhelds “Division Of” ABC - HQ
Location: Essentially an address.
Party Site: The connection between a location and a party that
indicates that a particular location is valid for that party.
Party Site Use: Use of a Party Site (e.g. billing, shipping, purchasing).

Entering orImporting Customer Data into TCA: