Read this:

• KNOW WHAT IS SUPPLY CHAIN MANAGEMENT (SCM)? : An Overview
• SCM Subsystem

This article is an easy guide for Techno-functional consultant to understand SCM from Implementation as well as Oracle Application product Prospective.Lets start the topic with some of high points of earlier post .

• As mention in earlier post a Supply Chain is a network of retailers, distributors, transporters, storage facilities and suppliers that participate in the sale, delivery and production of a particular product.
  • Make a note a supply chain is product specific, not company specific
• Supply chain management (SCM) is a systematic approach to manage the entire flow of information, materials, and services from raw material suppliers through factories and warehouses to the end customer.
• Moreover , SCM involves the flows of material, information and finance in a network consisting of customers,suppliers, manufacturers, and distributors.
• You should be clear with Flow that SCM can manage :
  • The flow of actual materials, the top middle bars
    • From suppliers : flows of raw materials, intermediate products, finished goods
    • Reverse material flows : returns, repairs, servicing, recycling, disposal
  • and the information flows
    • From suppliers : manufacturing capacity, delivery schedules, promotions they have going
    • Reverse flows : sales, orders, inventory, quality, promotions
  • And finally, there are financial flows:
    • From suppliers: Credits, consignment, payment terms, invoice
    • Reverse Flows : payments, consignment
• Supply Chain Management is the management of the entire value-added chain, from the supplier to manufacturer right through to the retailer and the final customer.
• SCM has three primary goals: Reduce inventory, increase the transaction speed by exchanging data in real-time, and increase sales by implementing customer requirements more efficiently
• The need for SCM is because effective Supply Chain Mgt. is the next logical step towards increased profits and market share.
• Supply Chain Management (SCM) in line manager prospective is “let’s-keep-things-moving-efficiently”.

Read the rest of this entry »

It was request from one of reader to provide some information for new organization Hierarchy model between two release of 11i and R12.Therefore invite you to run through the following diagram as below with some basics.

Read the rest of this entry »

Read this

• Managing Cash , EBS and SWIFT

Whenever the Bank Intergation is required , the very first term would come in mind is SWIFT , a very similar way as EDI sort of messaging servics that Financial sectors are using .So let explore what is SWIFT and how many of these can be potenially targetted for Integration .

What is a S.W.I.F.T?

S.W.I.F.T. (or SWIFT) stands for Society for Worldwide Interbank Financial Telecommunication. It is a non-profit organization comprised of member financial institutions. It was established in 1973 by European bankers who needed a more efficient and secure system for inter bank communications and transfer of funds and securities. Until then, all inter bank communications were by telephone, telex, courier, or mail.

Swift Messages

SWIFT messages are preset and referred to by category numbers called MT numbers. Through this network (a.k.a. SWIFTnet) information can be exchanged using special crafted messages known as Message-Types (MT).

Read the rest of this entry »

There was a requirement to provide a particular BU user to access to other BU PO’s for approval. Normally such kinds of requirement always happen in today’s complex business model . To implement this requirement a best we can do it is to use of new profile option which was introduced in Oracle 11i called HR: Cross Business Group , which need to switched on (i.e. set to “Yes”) can be used .This new profile option makes it possible for Oracle Application users to view and modify certain specific areas of data across all business groups.

From 11.5.9 onward in HRMS there are two Security Models as:

• Standard HRMS Security
• Security Groups

The first one is Standard HRMS security which normally requires defining a security profile, and defining a responsibility for use by application users, whereas security groups means whereby you can reuse a responsibility and assign it to different security profiles in different business groups if required.

Typically Multi-national Companies would be benefited from security as they normally have concept of service centres using multiple business groups and security profiles.

The good and bad in new Security Group Model

The Standard Security Model on Oracle HRMS forces a responsibility to be tied to only one business group/security profile. This means that when new business groups are added a brand new set of responsibilities must be set up for the business group, even if the new set of responsibilities is identical in every respect to existing responsibilities assigned to another business group.

The new security group model can cut down dramatically on the number of responsibilities required as it allows responsibilities to be reused by many different business groups.

Here are the key points of how the new security group functionality works.

• Every time a business group is created a new security group of the same name is also created.
• Security profiles are defined the same way they are now. There is no change in this functionality.
• Form Assign Security Profile is activated under the new security model. This form allows a user to be linked to a security profile, responsibility, security group (business group) combination.
• Profile option HR: Business Group is no longer set manually for HRMS responsibilities. This profile option will be set dynamically when a user selects a responsibility/security group combination at logon.
• Profile option HR: Security Profile is no longer set manually for HRMS responsibilities. This profile option will be set dynamically when a user selects a responsibility/security group combination at logon.
• The \Security\User Define Screen in the System Administrator responsibility is no longer user to assign HRMS responsibilities to users as this is now done in the new Assign Security Profile screen.

Please note, that although it is possible in the new security group model to access many business groups through the same responsibility, because of the way users are now assigned to responsibility/security group combinations, an HRMS user can only access the data in one business group at any one time.This can be best understood in next section.

Overview of Standard Security Model versus new Security Group Model

Lets try to understand by a simple diagram below, what is here is 3 BU defined in global instance representing three BU X-Singapore, X- Australia and third one X-UK. The simple diagram below shows the difference in responsibility set-ups associated with each model.

In the standard security model when a user logs on or decides to change responsibility the list of responsibility names they have access to are presented to them to select from. In the security group model when a user logs on or decides to change responsibility the list of responsibility names and the associated security group (i.e. business group) assigned to the user are presented to the user to select from. This difference can be best described as:

3 steps away to switching to the new security model

The steps required to switch to the new security model are as follows;

• Profile option HR: Cross Business Group should be set to “Yes”.
• Profile option Enable Security Groups must be set to “Service Bureau”
• Concurrent request Enable Multiple Security Groups must be run.

Not to Forget

Once the new security model is switched on, it cannot be switched off.

Suggested Reading

• Enhancements in Oracle HRMS Security in R11.5: Note:202478.1
• How Does the Cross Business Group Profile Option Impact the Application :Note:224822.1
• Understanding and Using HRMS Security in Oracle HRMS :Note:394083.1

Other related post in Security

• Know the “Security by Book” in Fixed Asset
• Understanding Security in : Oracle Financials and Manufacturing
• MOAC : From Multi-Org….To Multi-Access

This 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.

Conversion uses a daily rate that is either supplied by the user or pulled from the Daily Rates Table at the time the transaction is entered.

The Rate Type is simply a label to identify the kind of rate used in a transaction.

In EBS suite, “User” rate Type is reserved, whereas other rate type like “Corporate” and “Spot” used for the seeded data in GL currency table.

When such a transaction is posted, a separate balance is kept in the GL_BALANCES table of all accounts entered in a foreign currency and their equivalent balance in the functional currency.

When you see the information in GL_BALANCES table, which keeps a cumulative balance for the foreign and the functional balance in an account; the rate information is missing. The rate information and the transaction-by-transaction detail is kept in the GL_JE_LINES table. GL_BALANCES only keeps the total amount entered for a particular account in a particular currency and the total functional amount for those foreign transactions. This allows for the segregation of portions of an account balance by the different currencies used in each transaction.

Finally lets compare all three

This table has compares the three Foreign Currency concepts:

Related Posts in series for “Dealing with Foreign Currency”

• Dealing with Foreign Currency : “Revaluation”
• Dealing with Foreign Currency :”Translation”
• Dealing with Foreign Currency : “Conversion”

Similar to Revaluation, there is another term called ‘Translation’ , a feature that linked with Foreign Currency transactions in General Ledger.

Translation

Translation is used to translate an entire set of books or balances for a company from the functional currency to a foreign currency.

This feature can translate both actual and budget balances. If the system have enabled average balance processing then the system can translate average balances as well.

Translation is frequently used to prepare financial reports for consolidation into global financial statements.

Translation uses periodic rates and, optionally, historical rates in compliance with FASB52.

FASB stands for Financial Accounting Standards Board which is a group within the Accounting field that issues bulletins on how to account for various financial events.

How does the system translate balances?

As per Metalink Note 1061166.6, FASB52 states that when translating a Trial Balance from one currency to another, the following conventions should be used:

How does the system translate balances?

Assets and liabilities are translated by multiplying the YTD balance by the Period End Rate.

YTD (translated currency) = Rate X YTD (functional currency)

Whereas,revenue and Expense balances are translated using the PTD balance for each period and the corresponding Period Average rate for each period; therefore, translation must be performed for the first period of the fiscal year forward to the period for which translation is required. Rates must also exist in the Period Rates table back to the first period of the fiscal year in which the translation is being performed.

PTD (translated currency) = Rate X PTD (functional currency)

In the Stock and Ownership Equity accounts, historical rates are generally used. but there are certain other special cases requiring the use of Historical rates.

Point that should be noted is EBS GL allows the use of an amount to be used as the translated balance for the account specified rather than calculating the amount using the Historical Rates. This feature allows the translated balance to be calculated outside of the application in lieu of setting up and maintaining the Historical Rates. Historical Rate usage is set up by specifying a range of accounts to use Historical Rate translation. This set-up overrides the above rules for using the Period End and Period Average rates.

Cumulative Translation Adjustment Account

Since the Balance Sheet and the Profit and Loss accounts are being translated using different rates, the translated Trial Balance is no longer in balance. The amount required to bring the foreign Trial Balance back in balance is called the Cumulative Translation Adjustment or CTA. This account is specified in the Set of Books set-up screen. The accounts and the amounts in them are created and populated dynamically when the Translation process get completed successfully.

You should note that CTA is typically a Balance Sheet account, the account type is determined when the account value is defined for the account

Some of the underline report for Translation :

• Historical Rates Execution Report : This is used to review the historical rates, mounts or weighted-average rates you assigned to individual accounts or ranges of accounts.
• Translated Trial Balance Report :This is for reviewing account balances and period activity after running translation.
  

..What happen in Oracle when Translation Run?

Translation is very table-space intensive. When this run its roughly doubling one period of data held in the GL_BALANCES table.

Suggested Reading at Metalink

• How Does the Translation Process Calculate the Translated Amounts? Note 188530.1
• DOES ORACLE APPS COMPLY WITH FASB 52? Note:1061166.6

Related Posts in series for “Dealing with Foreign Currency”

1. Dealing with Foreign Currency : “Revaluation”
2. Dealing with Foreign Currency :”Translation”

Lets take some thoughts on Oracle GL Foreign Currency exposure.As we know three key terminology most wildly used in GL that pertain to foreign currency. They are Conversion, Revaluation, and Translation.Lets start with Revaluation:

Revaluation - when ,what & why?

Revaluation is used if, and only if, you have foreign currency transactions (i.e.Conversion of foreign currency transactions). Revaluation uses the Period Rates Table. The Revaluation Rate is simply 1/Period End Rate.

The Revaluation Process:

1.)Finds accounts within the range of accounts specified that have all or a portion of their balance derived from foreign currency transactions;

2.)takes the foreign currency portion of the account balance and revalues it using the Revaluation Rate from the Period Rates Table;

3.)figures the difference between the current cumulative functional balance of these foreign transactions and the revalued functional currency balance calculated using the Revaluation Rate;

4.) creates an unposted journal batch to adjust the account balance to the new revalued balance calculated using the Revaluation Rate. The offsetting account is an Unrealized Gain/Loss account specified when running the Revaluation process.

Don’t be confused by the fact that the Revaluation process revalues transactions entered using Daily Rates with rates from the Period Rate table; the rate it is using is simply the “Daily Rate” on the last day of the month stored in the Period Rate Table.

The purposes of Revaluation is to “true-up” liability or asset accounts that may be materially understated or overstated at month-end using an exchange rate at month- end. This understatement or overstatement is caused by an unacceptable fluctuation in the exchange rate between the time the transaction was entered into and the period of interest for reporting, usually at a month-end. Revaluation is only necessary while the obligation remains unsettled (example ..the invoice is still unpaid or the receivable uncollected). The Realized Gain/Loss will be recorded at the time the obligation is settled.

Take a note revaluation can be done on any account, but typically,this is done for balance sheet accounts, whose balance is made up of open
transactions (ie. Accounts Payable, Accounts Receivable).

Revaluation is typically done for reporting purposes only; therefore, the journal entries produced as a result should be reversed in the following period.

Although Revaluation is intended to be used when transacting in currencies because of fluctuating Forex rate in the unstable economies, more and more company who is operating in Multi national environment , normally using this functionality by creating Journal Entries to reconcile their foreign subsidiary intercompany account.

The idea being that they are getting translated balances from their subsidiaries that do not balance to their inter company due to using different rates throughout the month to record inter company transactions.

Revaluation is used to revalue all these transaction at the same rate the foreign subsidiary used to translate their intercompany balance.

How to specifying PTD or YTD Revaluation

We can use the setting in the profile option ‘GL: Income Statement Accounts Revaluation Rule’.

The following values are available:

PTD: Only PTD balances will be revalued for income statement accounts.

When you select PTD, the Revaluation program only revalues the PTD balances of your income statement accounts but continues to revalue YTD balances for balance sheet accounts.

YTD: Only YTD balances will be revalued for income statement accounts.
When you select YTD, then the revaluation program behaves as it did before, revaluing YTD balances for both your income statement and
balance sheet accounts.

Formula Used By Revaluation Calculation

YTD:

REVALUATION ACCOUNT AMOUNT= ((begin_balance_dr + period_net_dr - begin_balance_cr -period_net_cr) * revaluation_rate)
LESS
(begin_balance_dr_beq + period_net_dr_beq - begin_balance_cr_beq - period_net_cr_beq)

PTD

REVALUATION ACCOUNT AMOUNT = ((period_net_dr - period_net_cr) * revaluation_rate))
LESS
(period_net_dr_beq - period_net_cr_beq)

Will explore some more in foreign currency functionality area , keep watching…Happy weekend :)

Read this:

• Understanding Global Accounting Engine ( Product AX)
• Understanding Global Accounting Engine - Dual posting, Tables, Reports
• R12 SLA: From Product Accounting to Subledger Accounting
• R12 SLA: Analyzing Sub ledger Accounting

We have already seen oracle new Oracle Sub ledger Accounting replaces the Global Accounting Engine, which normally used for European & Regional Localizations need in earlier versions. SLA itself extends the AX engine functionality by providing customizable accounting rules via a flexible

Is SLA a clone of AX?
Yes, almost the functionality was derived from there itself, lets see vis-à-vis to uptake some of the functionality in these two products.

Not only functionality, some of the reports replaces the corresponding reports of the Global Accounting Engine.

The good is that both the Global Accounting Engine(AX) and Oracle Subledger Accounting(SLA) generate accounting from a compiled definition of accounting rules defined by users. Oracle Subledger Accounting further maintains version control on the rules enabling users to modify the rules while maintaining auditability.

What you say..sounds good :)

We are well aware of some of Oracle E-Business Suite R12 Architectural changes in the Financials section like:

• Legal Entity
• Ledger Sets
• Accounting Engine (SLA)
• Transaction Based Taxes(E-Tax)
• Inter-company Accounting (AGIS)
• Multi-Organization Access Control (MOAC)

Let’s uptake to Legal Entity:

Financial books defined as “A Legal Entity is an entity identified through the registration with the legal authority.”

That’s means ,In this compliance world and in Oracle system it corresponds closely and defined as the system “Legal Entity” corresponds with an independently identifiable “legal person” a public company, a private business or limited partnership, a trust, a not-for-profit, a government or a non-government organization (NGO) - that can operate as if it were a real person in conducting business transactions.

What is meant for with LE?

• Can get the the right to:
  • Own property weather its is assets or inventory or receivable
  • Trade (borrow, sell, buy, incur expenses, employ)
• And the responsibility to:
  • Repay debt (liabilities, equity)
  • Pay Taxes
  • Account for themselves (legal reports, audits)

Note for R11i with respect to R12

Release 11i GRE/LEs will be upgraded as Release 12 Legal Entities.

Release 11i Operating Units and Inventory orgs will be upgraded as Establishments.

One Legal Entity can have several establishments.

• In Release 12 there is no specific link between Operating Units and Legal Entities where as in R11 it was.
• The Legal Entity is linked to a Ledger and the Operating unit is also linked to a Ledger.
• Every Release 12 transaction must be associated with both an Operating Unit and a Legal Entity.
• The Legal Entity is also required for e-Business Tax to establish which taxes will be applicable to the transaction.

The New Model called ” LEA(Legal Entity Architecture)”

Legal Entity architecture, which is new in this release, provides users with the ability to model an enterprise’s legal organizational structure and define rules and attributes specific to legal entities.

Bank Account whether its is remittance bank or internal bank is now owned by the Legal Entity instead of Operating Unit, and can be used by any of the Operating Units sharing the same Ledger as that Legal Entity.

As marked (dotted red line) in above figure the relationship between legal Entity and Operating Unit is no more active. This concept allows Operating Units to be governed by more than one jurisdiction, but the accounting is still performed in a single ledger.

Multiple Legal Entities can be associated with a single Ledger, allowing the LEs to share the same ledger and chart of accounts, calendar and currency. Each LE points to one Ledger.

Multiple Operating Units can also be associated with a single Ledger. Each OU points to only on Ledger.

Thanks to David, who pointed out last week regarding Bank Uptake in LE side in reference to my old post. Check his post for further information.

Take a note; in R12 EBS multiple legal entities can be associated with a single Ledger, allowing the LEs to share the same ledger and chart of accounts, calendar and currency. Each LE points to one Ledger. Multiple Operating Units can also be associated with a single Ledger. Each OU points to only on Ledger.

Where it affects:

“Most of the Financial Application Products”

Cash Management (Bank)

As discussed in earlier, in Release 12 Bank Accounts are owned by Legal Entities and can be accessed by multiple Operating Units.

As we know in 11i the Bank Accounts were Operating Unit Specific.

For all Internal Banks should be assigned to a Legal Entity.

Receivables:

Now all REC activity must have a legal owner, so Legal Entity is stamped on every transaction. Receivables activity such as transaction whether credit memo or debit memo or invoice must have stamps on it and receipt header with the Legal Entity information.

Because there can be multiple legal entities using the same ledger, it may be necessary for the user to assign the LE. Each transaction can only belong to one Legal Entity, so when multiple legal entities exist, either the system or the user will assign the LE.

• Transaction

The defaulting hierarchy for a transaction comes from the setup of the Transaction Type and Transaction Batch Source. Receivables will look first to the Transaction type. If a LE has not been assigned, then Receivables will look to the Batch Source. The assignment of the LE to the Transaction Type and Transaction Batch Source is option, so if Receivables cannot find a default LE, then it is up to the user to provide the LE value.

• Receipts

The LE defaulting for receipts works differently than transactions.

Let’s look at how defaulting occurs for the Receipt Header.
As we know , internal Bank Accounts is not owned by legal entities instead of operating units, so LE defaults from internal (remittance) bank account.

The Receipt Method in Receivables has the bank account assignment, which determines what bank account gets assigned to the receipt.

Take a note in version 11 the receipt Method was called the Payment Method. Now in Release 12 this featured with same name “Payment Method” now used by new application called Oracle Payments. Therefore in AR, you will now see a Receipt Method, which is part of receipt setup; and Payment Method, which is part of Payments setup.Once the bank account is assigned to a receipt header, this information can be used to find the appropriate LE.Because the LE comes from only one source, the bank account, there is no special setup to be performed in Receivables.Defaulting of the single LE always occurs, so the user does not need to assign or update LE on receipts.

How LE affects receipts and there applications and refunds

We seen the receipts inherit the LE from the bank account weather its is manual, Automatic, Lockbox and Post Quick Cash Programs.There is no way that user can change the value.

Receipt application across Legal Entities is allowed if the receipt and transactions are in same OU and Sub Ledgers Accounting will performed by inter-company accounting for cross-LE receipt applications or cross-LE receipt clearing.

SLA will create inter-company accounting as long as LE is setup as one of the CCID (Account Code Combination) segment derivation sources in SLA.

Payable

Invoices and Payments indicate the operating unit and the legal entity owner of the transaction. The legal entity can be used as selection criteria when preparing pay runs.

Projects

As we know in 11i in EBS maintains the default legal context on the Operating Unit. There is not much impact in Projects model. Earlier in 11i we used to consider the Legal Entity of the Operating Unit as the Legal Entity of the Projects Transactions. Now the Legal Entity attached at the Default Legal Context of the Operating Unit is the Legal Entity of the Projects Transactions.

So the Legal Entity of the Projects expenditure transactions will be the Legal Entity attached at the Default Legal Context of the Expenditure Operating Unit and the Legal Entity of the Project will be the Legal Entity attached at the Default Legal Context of the Project owning operating unit.

LE and TCA

Legal Entity is still dependent on TCA. A party (supplier, customer, bank, student etc) is an entity that can enter into business relationships. As we know the Oracle TCA’s model supports four types of parties: organization, person, group, and party relationship. Under the TCA model, Parties (including Legal Entities) exist just once in our E-business Suite system for single maintenance and consistency. Legal Entities will be stored in TCA as Parties of party type ‘ORGANIZATION’. A Legal Profile, containing specific Legal Entity attributes, will be associated to the TCA Party. In addition, other TCA components will be used for Addresses, Contacts, Party Information, etc.

Where to do the setup

There should be no confusion.

May be , some may think if this is just extension of GRE/LE from old version , then Why this required to do set up from both ASM and HR in R12?

In R12 ,it is separate the legal entity from the GRE which is a HR organization. We did not link the 2 entities together as they serve 2 different purposes altogether.

The HR model does not look at the new Legal Entity model. It continues to use the GRE/LE as a legal entity. So the HR requirement can be achieved using the HR organization of type GRE/LE.

Therefore, Legal Entities do have to be set up in both ASM and HR in R12.

Hope this sound interesting for new change in Financial Architecture.

Suggested Reading

1. Oracle Financials Concepts Guide,Release 12(Part No. B28873-01)
2. David Haimes Blog : How do I define my Legal Entities?
3. Release 12 Financial Applications RCD

Oracle’s Release 12 of the E-Business Suite is also called the “ Global Business Release ”, as it has numerous enhancements designed to make it easier to do business on a global basis. A more flexible, centralized global accounting structure has been introduced which makes it easier to operate between and across operating units and legal entities. Overall, R12 contains 18 new modules and 2443 enhancements to existing functionality.

Oracle’s Release 12 (R12) of their E-Business Suite continues to extend the functionality of the Receivables arena , in addition to incorporated new financial architecture and new products , Oracle Receivables is now very natured product.As part of this post, we will look at Oracle’s newest/enhanced offerings in Oracle Receivables.

Revenue Recognition

In R12 revenue recognition is based on Rules and Events, and they are:

• Time-Based Revenue Recognition
  • Ratably Over Time
  • Upon Expiration of Contingencies
• Event-Based Revenue Recognition
  • Payment
  • Customer Acceptance
• Rule-Based Revenue Recognition
  • Payment Term Thresholds
  • Refund Policy Thresholds
  • Customer Credit worthiness

Lets take a quick look on some of the new changes:

• Daily Revenue Recognition
  • Revenue distribution over full as well as partial accounting periods.
  • Fulfills stringent accounting standards
  • Accuracy to the number of days in the accounting period.
• Enhanced Revenue Contingencies :
  • Fully Supports US GAAP and IAS
  • User definable contingencies
  • User definable defaulting rules for contingencies assignment
  • Supports parent-child (e.g. Product and Service) relationship
  • Integration with Order Management and Service Contracts
  • User Interface as well as Programming Interface (API) support
  • Access control through seeded Revenue Managers Responsibility
• Deferred Revenue Management

Event-Based Revenue Management in Oracle Receivables allows users to define revenue deferral reasons or contingencies and corresponding revenue recognition events. In Release 12, revenue contingencies for customer acceptance that are applied to goods sold in Order Management are now applied to services sold to cover those goods. Revenue is deferred for service ordered in both Order Management and Service Contracts. Acceptance contingencies associated with an item instance are automatically applied to service revenue associated with the item instance when it is covered in a Service Contract as a Covered Product. Revenue for services on other covered levels, subscriptions and usage is not impacted by contingencies applied to goods associated with those services.

Global Architecture

As we know, with in global architecture , these new things has been introduced.

• Sub ledger Accounting - Journal Creation takes place prior to GL.
• Bank Model - This unified model enables to park customer Bank as well as Internal bank information into there new model, so that working capital cash flow should be enhanced.
• EBusiness Tax - Oracle E-Business Tax is a new product that uniformly delivers tax services to all Oracle EBusiness Suite business flows. In Release 12, Receivables is enhanced to support
  integration with the E-Business Tax product.
• Intercompany - This is enhanced by automatic balancing,

MOAC Control

This enhance you by enabling and performing tasks across operating Units (OUs), where you have access to without changing responsibilities.As we know , MOAC 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.

In nutshell, once MOAC is enabled, then you can:

• Perform Setups for any OU
• Enter invoices across OUs
• Receive Cash for any OU
• Manage Customer Credit across all OU
• Run reports across OUs

Because of this greatly enhanced Role based security options, the ability to access multiple operating units with a single responsibility can simplify SOX compliance monitoring from finance controller side.

Line Level Cash Applications

The Line Level Cash Applications solution allows the application of receipts to specific transaction items such as individual lines, groups of lines, or tax or freight buckets. From the receipt workbench,you are able choose whether to allocate cash to the entire transaction or to apply amounts against specific items according to the customer remittance.

• Apply to specific lines or groups of lines
• Indicate when tax, freight or finance charges only are paid
• Make changes as needed
• Easily view activity against receipts
• Know what historical activity affects your receipt
• See what prior activity affects a new application

Enhanced Customer Screen

We have seen 11i Customer standard forms makes easier by simple navigation. This times there is clearer separation of the party and account layers, which makes a consist ant look and feel.More over full backward compatibility with 11i UI Bill Presentment Architecture has been provided.

The AR Create Customer page in R12 has eliminated the navigation to separate windows. Now, users can specify the following on a single page:

• Customer Information
• Account Details
• Address
• Account Site Details
• Business Purpose
  

Refunds

Oracle Receivables is fully integrated with Oracle Payables to deliver a seamless, automated process to generate check and bank account transfer refunds for eligible receipts and credit memos.

Late Charges

As we know oracle receivables delivers enhanced Late Charges functionality enabling the creation of standard late charge policies that can be assigned to customer accounts or account sites.Flexible policy configurations include multiple interest calculation formulas, transaction and account balance thresholds, and currency-level rate setups. With new changes these are the enhanced functionality:

• Expanded assessment and calculation capabilities
• Tiered charge schedules
• Penalty charge calculation
• Integration with Balance Forward Billing
• Centralized setup and maintenance of late charge policies
• Calculation performed independent of Dunning and Statement processing

AR-AP Netting

The matching of open receivables and open payables is automated.

Balance Forward Billing

This makes easy transaction processing.

Balance Forward Billing is an enhanced version of the existing consolidated billing functionality for industries where customers are billed for all their account activity on a regular, cyclical basis.

Balance Forward Billing provides the ability to setup cycle-based billing at the account or account site levels, enable event based billing, and leverage user configurable billing formats provided by Oracle Bill Presentment Architecture.

A typical case can be best understood as

• Payment Term defaults
• from Site profile if Bill Level = Site
• from Account profile if Bill Level = Account
• Billing Date derived from transaction date and billing cycle
• Due Date derived from billing date and payment term
• Optionally select non-Balance Forward term if Override Terms = Yes