Oracle Basics

Oracle Corporation markets its home-grown software applications, including Oracle Financials, Oracle HRMS, Oracle CRM etc. as parts of the "Oracle E-Business Suite". The following enterprise applications are available as part of Oracle eBusiness Suite:

• Asset Lifecycle Management
• Customer Relationship Management
• Enterprise Resource Planning

• Procurement
• Product Lifecycle Management
• Supply Chain Management

• Manufacturing

Profile Options

A user profile is a set of changeable options that affect the way your application runs. The system administrator can set user profiles at different levels:

Site level     These settings apply to all users at an installation site.
Application level     These settings apply to all users of any responsibility associated with the application.
Responsibility level     These settings apply to all users currently signed on under the responsibility.
User level     These settings apply to an individual user, identified by their application username.

Important Profiles
1.1. HR: Business Group
1.2  HR: Security Option
1.3: HR: User Type (FOR accessing HRMS functions)
1.4  HR: Cross Business Group

2.1. GL: Set of Books(11i)
2.1  GL:%Ledger%  (R12)
2.3  GL: Data Access Set. This profile option to control the ledgers that can be used by Oracle General Ledger.

3.1. MO: Operating Unit
3.2. MO: Security Profile (R12)
3.3. MO: Default Operating Unit

4.1 Tax: Allow Override of Tax Code
4.2 Tax: Invoice Freight as Revenue
4.3 Tax: Inventory Item for Freight

5.1 Sequential Numbering
5.2 INV: Intercompany Currency Conversion

6.1 RCV: Processing Mode - Batch, Immediate, Online
6.2 QA: PO Inspection - Oracle Purchasing , Oracle Quality

7.1 Hide Diagnostics menu entry

8.1 OE: Item Flexfield
This profile option indicates the structure of the Item Flexfield (System Items) used by Order Entry. This structure should be the same across all applications in the same database.
This profile option is visible and updatable at the site level.

8.2 OE: Item Validation Organization
This profile option indicates the Oracle Manufacturing organization against which items are validated. You must define all items that can be included in your transactions in this organization.
Set the OE: Item Validation Organization profile at the site level for the inventory organization whose master item number you want to use. This profile option indicates the organization that Receivables uses to validate items.
This profile option is visible and updatable at the site level.

Values set at a higher level cascade as defaults to the lower levels. Values set at a lower level override any default from a higher level. For profile options that need to differ at the operating unit level, including OE: Item Validation Organization, OE: Set of Books, and GL: Set of Books, you must set the values at the responsibility level. Oracle General Ledger windows use the GL Set of Books profile option to determine your current set of books. If you have different sets of books for your operating units, you should set the GL Set of Books profile option for each responsibility that includes Oracle General Ledger windows.

For profile options that need to differ at the set of books level, including Sequential Numbering, set the values at the responsibility level.

Profile options specify default values that affect system processes, system controls, and data entry. In a multiple organization
environment you may want to confine the effect to a specific operating unit. Therefore, you may want to change your profile options to be visible and updatable at the responsibility level.

1. MO: Operating Unit = {the users Operating Unit name}
     This points the responsibility to the appropriate Operating Unit.
This the profile which holds the value of operating unit org_id when ever user login into system his org_id is  value is transfered to profile value base on this profile  we get data and put data from databaseUsed primarily in a multiorg environment.
     Set the site level to the desired default operating  unit.
     If there is more than 1 Operating Unit Defined, this profile option must be set at the responsibility level for each responsibility.
Example: Suppose we define a responsibility Purchasing Super User US . Then MO : Operating Unit at this responsibility level determines which Opertaing unit can this responsibility(or the user assigned to this responsibility) acess.
 

HRMS with Oracle Financial

The organization information used in HR is as follows
1. Business Group
2. HR Organization

The HR organization classification used in oracle financials applications are as follows
1. GRE/Legal Entity
2. Operating unit
3. Company Cost Center(Used in financials DBI)
4. Auditable Unit(Used in ICM module)
5. Assets Organization (Used in Financial Payables : Assets)

Define SOB

To define Business group, LE, OU, Organization, HR Organization etc check out below link
http://www.oracleug.com/user-guide/oracle-inventory/organization

SOB is a sepcial organization in multi-org model. Its a financial entity that shares a particular hart of account, finctional currency and finncial accounting calendar. A General Ledger (GL) secures transaction information bu SOB.

An SOB is the highest level that affects the accounting aspects of business. One BG can be associated with multiple SOBs, but one SOB can be associated with only one BG. Each SOB has 3Cs.

 

 

With the multi-Org enhancements, multiple SOBs can use the same global item master organization. This is because the item master organization is used for item definition and not for item accounting information. All accouting-related attributes in the item master are controlled at the item level or organization level.

Balancing Entity

A balancing entity is one for which you prepare a balance sheet as a balancing segment value in the Accounting Flexfield structure. In any OU, you can have multiple balancing entities and each of these must balance within itself.

To explain different balancing entities, assume that there is one GL SOB, balancing segment value is the company segment, and that there are three companies 10, 20 and 30. You should ensure that OUs are associated with responsibilities, and each responsibility is associated with one and only one OU. In the case the company 10 is a legal entity in which two divisions Div1 and Div2 are defined as OUs. You can create a security rule to ensure that when users log in with a particular responsibility, they should only be able to enter transactions with compnay 10, and the users from company 20 and copnmany 30 should not be allowed.
 

Multi-org Security model

The organization models in Oracle Applications define organizations, their relationships, and the transactional flow among organizational structures. With the multi-org security model, you can customize Oracle Applications according to your business needs. In this topic, you learn about features of multi-org security model.

Descriptive Flex field

Create the DFF structure

 

1.2 Descriptive Flex field

Create the DFF structure

 

Descriptive Flex field

Create the DFF structure

 

1.2 Descriptive Flex field

Create the DFF structure

 

Organizational Model in R12

Oracle Financials can be implemented in multiple ways to reflect your real-world organization. Groups generally reflect a tension between their legal organization, management organization, and business divisions.

Standard Business Organization
The following diagram shows an archetypical group of companies operating various business and a standard functional organization.

• A separate card represents each of a series of registered companies, that is, legalentities. The list of cards is the "Legal Axis".
• Each company hosts parts or all of various subdivisions that management has made within its businesses. These are shown as vertical columns on each card. For example, a Group might have a separate company for each business in the United Kingdom, but have their Ireland company host all businesses in that country.
  The subdivisions are linked across the cards so that a business can appear on some or all of the cards. For example, the chemical business might be operated by the Ireland, United Kingdom, and France companies. The list of business subdivisions is the "Business Axis".
• Each company's card is also horizontally striped by functional groups, such as the sales team and the finance team. The functional list is the "Functional Axis". The overall image suggests that information might, at a minimum, be tracked by company, business subdivision, and function in a group environment.

The Legal Organization
Our ability to buy and sell, own, and employ comes from our charter in the legal system. Commercial groups exist through corporate law. Units in the legal structure of a group are individual companies that share common ownership and control. In a public group, a company is owned by the public through shares sold on a stock market. In a private group, they are held by a privately held holding company. In other organizations, the legal entities are partnerships, funds, or government agencies.

A legally recognized entity can own and trade assets and employ people; while an entity without legal recognition cannot. When granted these privileges, legal entities are also assigned responsibilities to account for themselves to the public (statutory reporting and external reporting), comply with legislation and regulations, and pay income or profit and transaction taxes.
Most groups have many legal entities. They are created to facilitate legal compliance, segregate operations, optimize taxes, and for many other reasons. Legal entities establish your identity under the laws of each nation in which you operate, and provide vehicles for contractual relationships, compliance, and taxation.

Business Divisions
Successfully managing multiple businesses requires that you segregate them by the rewards and risks involved in making them profitable. You divide your organization accordingly and assign management personnel to each division.
Although related to your legal structure, the business organizational hierarchies do not need to be reflected directly in the legal structure of the firm. The management entities and structure include divisions and subdivisions, lines of business, and other strategic business units, and include their own revenue and cost centers.

Functional Organizations
Straddling the legal and business organizations is an organization structured around people and their competencies: sales force, operations, plants, researchers, finance people, human resource management, information technologists, and management. The income statement often reflects their efforts and expenses directly. Organizations must manage and report revenues, cost of sales, and functional expenses such as Research and Development (R&D) and Selling, General, and Administrative Expense (SG&A).

The Legal Entiry in Oracle

1. "Legal entity" in the Oracle system corresponds closely to "legal entity" or "company" in the legal world. You can store information about a registered company or other real world legal entity in the "legal entity". For example, you can store the registered address and director or officer names.
2. All legal entities exist in particular legal jurisdictions, both national and regulatory, and must comply with the regulations of those jurisdictions. Legal entities have multiple compliance requirements placed on them, many of which define the form of the transactions into which that legal entity enters.
3. Individual legal entities own the assets of the enterprise, record sales and pay taxes on those sales, make purchases and incur expenses, and make other transactions.
4. Legal entities are formally the entities that actually enter into transactions.  Assigning Legal Entity to all transactions enables tax calculation, supporting the centralized tax solution
5. The Trading Community Architecture (TCA) model supports four types of parties: organization, person, group, and party relationship.  Legal Entities will be stored in TCA as Parties of party type ‘ORGANIZATION’. 
6. The subsidiaries of the Legal Entities are defined as Establishments. The Establishments are also defined as parties with legal information stored in the Legal Entity Data Model.

The system legal entity is the first party on business transactions and is the transaction tax filer and payer. We recognize that for many groups, particularly in environments where the authorities allow you to treat many legal entities as one, you don't need or want to segment data or account separately for each entity that you have incorporated.  Therefore, the system legal entity does not automatically account for itself.

Most groups have many legal entities. They are created to facilitate legal compliance, segregate operations, optimize taxes, and for many other reasons. Legal entities establish your identity under the laws of each nation in which you operate, and provide vehicles for contractual relationships, compliance, and taxation.

A given legal entity may or may not represent all or part of a management framework in its domain. For example, in a large country such as the United Kingdom or Germany, you might deploy individual companies to represent each business division, and you might control many companies in that country. In a smaller country, for example Austria, you might use a single legal entity to host all of your business divisions. Legal entities have very specific relationships with shared service centers and with the ownership of the goods and transactions managed by such centers.

 

Oracle APIs and Open Interfaces

Oracle Puchasing:
1. Requisitions Open Interface
2. Purchasing Documents Open Interface
3. Cancel PO APIs
4. Receiving Open Interface

Oracle Inventory:
1. Open Transaction Interface
2.1 Customer Item Interface
2.2 Open Item Interface
2.3 Cycle Count Open Interface
3.1 Open Replenishment Interface
3.2 Reservations Open Interface
3.3 Move Orders Open Interface

OM:
1.    Order Import
2.    Process Order API
3.    RLM Open Interfaces
Actions, APIs, and Parameters: Descriptions of the APIs used for various functions and the API parameters.
Application Parameter Initialization: Description of the application parameter initialization call.
Trip API: Create and update trip records and perform actions on trips.
Stop API: Create and update stop records and perform actions on stops.
Deliveries API: Create and update trip stop records and perform actions on trip stops.
Delivery Details API: Assign and unassign delivery details to and from deliveries, split a delivery detail, update a delivery detail with new
information, and create trips and deliveries for multiple delivery lines.
Container API: Create container records, update container records, autopack containers, perform actions on containers.
Freight Cost APIs: Create freight cost records, update freight cost records, validate freight cost types, delete freight cost records.

Tables
OE_ORDER_HEADERS_ALL
OE_ORDER_LINES_ALL
WSH_DELIVERY_DETAILS
OE_ORDER_HOLDS_ALL

OE_PRICE_ADJUSTMENTS
OE_TRANSACTION_TYPES_ALL
OE_DROP_SHIP_SOURCES
OE_SETS
OE_SYSTEM_PARAMETSR

MTL_DEMANDS
MTL_RESRVATIONS

Inventory
Open Transaction Interface
Oracle Inventory provides an open interface for you to load transactions from external applications and feeder systems. These transactions could include sales order shipment transactions from an Order Management system other than Oracle Order Management, or they could be simple material issues, receipts, or transfers loaded from data collection devices. The following transaction types are supported by this interface:
• Inventory issues and receipts (including user-defined transaction types)
• Subinventory transfers
• Direct interorganization transfers
• Intransit shipments
• WIP component issues and returns
• WIP assembly completions and returns
• Sales order shipments
• Inventory average cost updates
• LPN Pack
• Unpack
• Split Transactions
• Inventory Lot Split/ Merge/ Translate Transactions
This interface is also used as an integration point with Oracle Order Management for shipment transactions. Oracle Order Management's Inventory Interface program populates the interface tables with transactions submitted through the Confirm
Shipments window.
You must write the load program that inserts a single row for each transaction into the MTL_TRANSACTIONS_INTERFACE table. For material movement of items that are under lot or serial control, you must also insert rows into MTL_TRANSACTION_LOTS_INTERFACE and MTL_SERIAL_NUMBERS_INTERFACE respectively. If you insert WIP
assembly/completion transactions that complete or return job assemblies, you must also insert rows into the CST_COMP_SNAP_ INTERFACE table if the organization referenced uses average costing. The system uses this information to calculate completion cost.

There are two modes you can use to process your transactions through the interface. In the first processing mode, you populate the interface table only. Then the Transaction Manager polls the interface table asynchronously looking for transactions to process, groups the transaction rows, and launches a Transaction Worker to process each group.
In the second processing mode, you insert the rows in the interface table and call a Transaction Worker directly, passing the group identifier of the interfaced transactions as a parameter so that the worker can recognize which subset of transactions to process.

The Transaction Worker calls the Transaction Validator, which validates the row, updates the error code and explanation if a validation or processing error occurs, and derives or defaults any additional columns. Next, the Transaction Processor records the transaction details in the transaction history table along with relevant current cost information. All material movement transactions update inventory perpetual balances for the issue, receipt, or transfer locations. Once the transaction has been successfully processed, the corresponding row is deleted from the interface table. Finally, the transaction is costed by the transaction cost processor, which runs periodically, picking up all transactions from the history table that have not yet been marked as costed.

Open Replenishment Interface
Oracle Inventory provides an open interface for you to easily load replenishment requests from external systems such as a barcode application. Such requests may be in the form of stock-take counts or requisition requests for subinventories in which you do not track quantities.

Cycle Count Entries Interface
You can import cycle count entries from an external system into Oracle Inventory using the Cycle Count Entries Interface. This interface validates all data that you import into Oracle Inventory. It also performs foreign key validation and checks for attribute inter-dependencies, acceptable values, and value ranges. The interface ensures that the imported cycle count entries contain the same detail as items entered manually using the Cycle Count Entries window. Errors detected during validation are written to the Cycle Count Interface Errors table.

Kanban Application Program Interface
The Kanban API is a public API that allows you to update the supply status of kanban cards. To accomplish this task, you use the public procedure update_card_supply_status

Item Open Interface
You can import items from any source into Oracle Inventory and Oracle Engineering using the Item Open Interface. With this interface, you can convert inventory items from another inventory system, migrate assembly and component items from a legacy manufacturing system, convert purchased items from a custom purchasing system, and import new items from a product data management package. The Item Open Interface validates your data, ensuring that your imported items contain the same item detail as items that you enter manually in the Master Item window.

You can also import item category assignments. This can be done simultaneously with a process of importing items, or as a separate task of importing item category assignments only. For this purpose, the Inventory menu contains the Import submenu with the Import Items and Import Item Category Assignments menu entries.

Receiving Open Interface
You use the Receiving Open Interface to process and validate receipt data that comes from sources other than the Receipts window in Oracle Purchasing. These sources include:
• Receipt information from other Oracle applications or legacy systems
• Brocades and other receiving information from scanners and radio frequency devices
• Advance Shipment Notices (ASNs) from suppliers
The Receiving Open Interface maintains the integrity of the new data as well as the receipt data that resides in Oracle Purchasing.
The Receiving Open Interface does not support:
• Movement statistics
• Dynamic locators

BOM
Bills of Materials Open Interfaces

WIP
Open Move Transaction Interface
You can load Move transaction information into the Open Move Transaction Interface from a variety of sources, including external data collection devices such as bar code readers, automated test equipment, cell controllers, and other manufacturing execution systems. You then use the interface to load these transactions into Oracle Work in Process. All transactions are validated and invalid transactions are marked, so that you can correct and resubmit them.

Open Resource Transaction Interface
You can use external data collection devices such as bar code readers, payroll systems, and time card entry forms to collect resource and overhead transaction data, then load the data into the Open Resource Transaction Interface for Oracle Work in Process to process.

Work Order Interface
The Work Order Interface enables you to import Discrete job and Repetitive schedule header information, and Discrete job operations, material, resource, and scheduling information from any source, using a single process.
You can import:
• Planned orders for new Discrete jobs,
• Discrete job operations, components, resources, resource usage, and scheduling details
• Update and reschedule recommendations for existing Discrete jobs
• Suggested Repetitive schedules Work in Process then uses this information to automatically create new Discrete jobs
and pending Repetitive Schedules, or to update existing Discrete jobs.

MRP
Open Forecast Interface
You can import forecasts from any source using the Open Forecast Interface table. Oracle Master Scheduling/MRP automatically validates and implements imported forecasts as new forecasts in Oracle Master Scheduling/MRP.

Cost Management
Periodic Cost Open Interface
The Oracle Periodic Cost Open Interface provides an open interface for you to easily load periodic item costs from external applications or legacy systems and migrate them into the Oracle Cost Management Application. This interface should only be used to bring in periodic costs for the first opened periodic period. It cannot be used for subsequent periods. Costs in subsequent periods are calculated by the system.

Cost Import Interface
The Oracle Cost Import Interface enables you to import costs for items from legacy systems, and import new cost information for existing items. Importing resource costs and resource overhead rates is also supported. You will also be able to replace existing cost information with the new cost information. However, updating of existing costs is not supported. Importing costs into frozen cost type is also not supported. The item costs will have to be imported into another cost type and then the cost update may be run to update the frozen cost type

OM
Order Import
Pricing Open interface
Pick release

Cross-Validation Rules

A key flexfield can perform automatic cross-validation of segment values according to rules your organization defines when you customize the key flexfield. You can use cross-validation to closely control the creation of new key flexfield combinations, and you can maintain a consistent and logical set of key flexfield combinations that you need to run your organization.

What is Cross-Validation?
Cross-validation (also known as cross-segment validation) controls the combinations of values you can create when you enter values for key flexfields. A cross-validation rule defines whether a value of a particular segment can be combined with specific values of other segments. Cross-validation is different from segment validation, which controls the values you can enter for a particular segment.

You use cross-validation rules to prevent the creation of combinations that should never exist (combinations with values that should not coexist in the same combination). For example, if your organization manufactures both computer equipment and vehicles such as trucks, you might want to prevent the creation of "hybrid" part numbers for objects such as "truck keyboards" or "CPU headlights".

4. Cross-Validation Rules

A key flexfield can perform automatic cross-validation of segment values according to rules your organization defines when you customize the key flexfield. You can use cross-validation to closely control the creation of new key flexfield combinations, and you can maintain a consistent and logical set of key flexfield combinations that you need to run your organization.

What is Cross-Validation?
Cross-validation (also known as cross-segment validation) controls the combinations of values you can create when you enter values for key flexfields. A cross-validation rule defines whether a value of a particular segment can be combined with specific values of other segments. Cross-validation is different from segment validation, which controls the values you can enter for a particular segment.

You use cross-validation rules to prevent the creation of combinations that should never exist (combinations with values that should not coexist in the same combination). For example, if your organization manufactures both computer equipment and vehicles such as trucks, you might want to prevent the creation of "hybrid" part numbers for objects such as "truck keyboards" or "CPU headlights".

Cross-Validation Rules

A key flexfield can perform automatic cross-validation of segment values according to rules your organization defines when you customize the key flexfield. You can use cross-validation to closely control the creation of new key flexfield combinations, and you can maintain a consistent and logical set of key flexfield combinations that you need to run your organization.

What is Cross-Validation?
Cross-validation (also known as cross-segment validation) controls the combinations of values you can create when you enter values for key flexfields. A cross-validation rule defines whether a value of a particular segment can be combined with specific values of other segments. Cross-validation is different from segment validation, which controls the values you can enter for a particular segment.

You use cross-validation rules to prevent the creation of combinations that should never exist (combinations with values that should not coexist in the same combination). For example, if your organization manufactures both computer equipment and vehicles such as trucks, you might want to prevent the creation of "hybrid" part numbers for objects such as "truck keyboards" or "CPU headlights".

4. Cross-Validation Rules

A key flexfield can perform automatic cross-validation of segment values according to rules your organization defines when you customize the key flexfield. You can use cross-validation to closely control the creation of new key flexfield combinations, and you can maintain a consistent and logical set of key flexfield combinations that you need to run your organization.

What is Cross-Validation?
Cross-validation (also known as cross-segment validation) controls the combinations of values you can create when you enter values for key flexfields. A cross-validation rule defines whether a value of a particular segment can be combined with specific values of other segments. Cross-validation is different from segment validation, which controls the values you can enter for a particular segment.

You use cross-validation rules to prevent the creation of combinations that should never exist (combinations with values that should not coexist in the same combination). For example, if your organization manufactures both computer equipment and vehicles such as trucks, you might want to prevent the creation of "hybrid" part numbers for objects such as "truck keyboards" or "CPU headlights".

How Cross-Validation Works

When a user finishes entering segment values in a flexfield pop-up window, the flexfield checks whether the values make up a valid combination before updating the database. If the user entered an invalid combination, a diagnostic error message appears, and the cursor returns to the first segment assumed to contain an invalid value.

Cross-validation rules control combinations of values within a particular key flexfield structure. Cross-validation applies to combinations users attempt to create using either the combinations form or foreign key forms (using dynamic inserts).

Cross-Validation Rules and Existing Combinations
Cross-validation rules have no effect on combinations that already exist when you define your cross-validation rules.

Suppose you define a new cross-validation rule, but have existing entries in your combinations table that violate the rule. Since the existing combinations pre-date the rule, your flexfield continues to treat them as valid. However, if your end user tries to create a new combination that violates your new rule, your flexfield returns an error message and rejects the combination.

If you want to prevent users from using previously-existing combinations that are no longer valid according to your cross-validation rules, you can always manually disable those combinations using the combinations form.

Dynamic Insertion and Cross-Validation
Your use of cross-validation is separate from (and in addition to) your use of dynamic inserts.

By allowing dynamic inserts, you can let users create new combinations automatically upon entering the combination in a foreign key form (any form other than the combinations form) and in the combinations form itself.

If you want greater control, you can disallow dynamic inserts. You can thus restrict the creation of new combinations to certain authorized people who have access to the combinations form on their menu. You simply turn dynamic insertion off using the Define Key Flexfield Segments form. Depending on the key flexfield you use, you can still create new combinations using one of your product setup forms (the combinations form). For example, if you use the Accounting Flexfield, you can enter new combinations using the Define Accounting Flexfield Combination form.

In either case, however, there is no inherent protection against a user creating an invalid new combination. Cross-validation rules ensure that nobody can create invalid new combinations from either foreign key forms or the combinations form, regardless of whether you allow dynamic inserts.

As you consider the controls you want over your key flexfield combinations, determine whether you need cross-validation rules at all. To provide an extra level of security, use cross-validation rules even if you turn dynamic insertion off. This allows you to double-check new combinations that even your authorized personnel enter using the combinations form.

Changing your key flexfield structure after defining rules
Changing an existing key flexfield structure may adversely affect the behavior of any cross-validation rules you have for that structure, so you should be sure to manually disable or redefine any cross-validation rules to reflect your changed structure. Flexfield structure changes that make your existing rules invalid include:

          o changing the order of segments

          o adding a new segment

          o disabling a segment

          o changing segment lengths

For example, if you change a six-segment structure to contain only five segments, you would not be able to use any new five-segment code combinations since any rules existing for the old six-segment structure would be violated.

Cross-Validation Rules Window
Your flexfield checks cross-validation rules while attempting to create a new combination of flexfield values (for example, a new Accounting Flexfield combination). Your cross-validation rules have no effect on flexfield combinations that already exist. If you want to disable an existing combination, you must disable that combination specifically using the appropriate window. For example, you can disable an existing Accounting Flexfield combination using the Define Accounting Flexfield Combinations window.

    Suggestion: We recommend that you define many rules that each have few rule elements rather than a few rules that each have many rule elements. The more rules you provide, the more specific you can make your error message text.

Your flexfield checks cross-validation rules only if you set Cross-Validate Multiple Segments to Yes using the Define Key Flexfield Segments window.

If you make changes to your cross-validation rules, you need to either change responsibilities or exit from your application and sign on again in order for the changes to take effect.

Defining Cross-validation Rules

Oracle Applications provides many key flexfields, such as the Accounting Flexfield, Location Flexfield and System Items Flexfield. In this essay, we use the Accounting Flexfield to present suggestions for designing your cross-validation rules, but you can use cross-validation rules for any key flexfield structure that has cross-validation enabled.

Use the Key Flexfield Segments window to define your flexfield structure and segments and specify Yes in the Cross-Validate Multiple Segments field for your flexfield structure.

To define cross-validation rules:

1. Select the name and structure of your key flexfield for which you wish to define cross-validation rules. Your list only contains structures with the field Cross-Validate Multiple Segments set to Yes on the Key Flexfield Segments window.
2. Enter a unique name and a description for your cross-validation rule.
3. Enter your error message text for this cross-validation rule.                                                                                  Your flexfield automatically displays this error message on the message line whenever a new combination of segment values violates your cross-validation rule. You should make your error messages as specific as possible so that your users can correct any errors easily.
4. Enter the name of the segment most likely to have caused this cross-validation rule to fail. Your flexfield leaves the cursor in this segment whenever a new segment combination violates this cross-validation rule to indicate where your user can probably correct the error. If you do not specify an error segment name, your flexfield leaves the cursor in the first segment of the flexfield window following a violation of this rule.
5. If you want to have the rule effective for a limited time, you can enter a start date and/or an end date for the rule. The rule is valid for the time including the From and To dates.
6. Define the cross-validation rule elements that make up your rule. See: Defining Cross-validation Rule Elements.
7. Save your changes.

Masters in Oracle

Combination

Values and Value Sets

Oracle Application Object Library uses values, value sets and validation tables as important components of key flexfields, descriptive flexfields, and Standard Request Submission. This section helps you understand, use and change values, value sets, and validation tables.

When you first define your flexfields, you choose how many segments you want to use and what order you want them to appear. You also choose how you want to validate each of your segments. The decisions you make affect how you define your value sets and your values. You define your value sets first, either before or while you define your flexfield segment structures. You typically define your individual values only after your flexfield has been completely defined (and frozen and compiled). Depending on what type of value set you use, you may not need to predefine individual values at all before you can use your flexfield.

You can share value sets among segments in different flexfields, segments in different structures of the same flexfield, and even segments within the same flexfield structure. You can share value sets across key and descriptive flexfields. You can also use value sets for report parameters for your reports that use the Standard Request Submission feature.

Because the conditions you specify for your value sets determine what values you can use with them, you should plan both your values and your value sets at the same time. For example, if your values are 01, 02 instead of 1, 2, you would define the value set with Right–Justify Zero–fill set to Yes.

Remember that different flexfields may have different requirements and restrictions on the values you can use, so you should read information for your specific flexfield as part of your value planning process. For example, the Accounting Flexfield requires that you use certain types of value sets.

3. Values and Value Sets

Oracle Application Object Library uses values, value sets and validation tables as important components of key flexfields, descriptive flexfields, and Standard Request Submission. This section helps you understand, use and change values, value sets, and validation tables.

When you first define your flexfields, you choose how many segments you want to use and what order you want them to appear. You also choose how you want to validate each of your segments. The decisions you make affect how you define your value sets and your values. You define your value sets first, either before or while you define your flexfield segment structures. You typically define your individual values only after your flexfield has been completely defined (and frozen and compiled). Depending on what type of value set you use, you may not need to predefine individual values at all before you can use your flexfield.

You can share value sets among segments in different flexfields, segments in different structures of the same flexfield, and even segments within the same flexfield structure. You can share value sets across key and descriptive flexfields. You can also use value sets for report parameters for your reports that use the Standard Request Submission feature.

Because the conditions you specify for your value sets determine what values you can use with them, you should plan both your values and your value sets at the same time. For example, if your values are 01, 02 instead of 1, 2, you would define the value set with Right–Justify Zero–fill set to Yes.

Remember that different flexfields may have different requirements and restrictions on the values you can use, so you should read information for your specific flexfield as part of your value planning process. For example, the Accounting Flexfield requires that you use certain types of value sets.

Values and Value Sets

Oracle Application Object Library uses values, value sets and validation tables as important components of key flexfields, descriptive flexfields, and Standard Request Submission. This section helps you understand, use and change values, value sets, and validation tables.

When you first define your flexfields, you choose how many segments you want to use and what order you want them to appear. You also choose how you want to validate each of your segments. The decisions you make affect how you define your value sets and your values. You define your value sets first, either before or while you define your flexfield segment structures. You typically define your individual values only after your flexfield has been completely defined (and frozen and compiled). Depending on what type of value set you use, you may not need to predefine individual values at all before you can use your flexfield.

You can share value sets among segments in different flexfields, segments in different structures of the same flexfield, and even segments within the same flexfield structure. You can share value sets across key and descriptive flexfields. You can also use value sets for report parameters for your reports that use the Standard Request Submission feature.

Because the conditions you specify for your value sets determine what values you can use with them, you should plan both your values and your value sets at the same time. For example, if your values are 01, 02 instead of 1, 2, you would define the value set with Right–Justify Zero–fill set to Yes.

Remember that different flexfields may have different requirements and restrictions on the values you can use, so you should read information for your specific flexfield as part of your value planning process. For example, the Accounting Flexfield requires that you use certain types of value sets.

3. Values and Value Sets

Oracle Application Object Library uses values, value sets and validation tables as important components of key flexfields, descriptive flexfields, and Standard Request Submission. This section helps you understand, use and change values, value sets, and validation tables.

When you first define your flexfields, you choose how many segments you want to use and what order you want them to appear. You also choose how you want to validate each of your segments. The decisions you make affect how you define your value sets and your values. You define your value sets first, either before or while you define your flexfield segment structures. You typically define your individual values only after your flexfield has been completely defined (and frozen and compiled). Depending on what type of value set you use, you may not need to predefine individual values at all before you can use your flexfield.

You can share value sets among segments in different flexfields, segments in different structures of the same flexfield, and even segments within the same flexfield structure. You can share value sets across key and descriptive flexfields. You can also use value sets for report parameters for your reports that use the Standard Request Submission feature.

Because the conditions you specify for your value sets determine what values you can use with them, you should plan both your values and your value sets at the same time. For example, if your values are 01, 02 instead of 1, 2, you would define the value set with Right–Justify Zero–fill set to Yes.

Remember that different flexfields may have different requirements and restrictions on the values you can use, so you should read information for your specific flexfield as part of your value planning process. For example, the Accounting Flexfield requires that you use certain types of value sets.

Account Generator processes

Applications need to construct Accounting Flexfield combinations automatically for various purposes. The Account Generator feature uses Oracle Workflow technology to provide applications with the ability to construct key flexfield combinations automatically using customized construction criteria. Each site can customize how they want to build key flexfield combinations.

Benefits of the Account Generator using Oracle Workflow
Automatic construction of key flexfield combinations speeds users' data entry.

Automatic construction of key flexfield combinations improves accuracy of data entry because users do not need to determine what key flexfield combination to enter.

Each site can customize rules for the construction of key flexfield combinations to match the existing way of doing business.

Fixed Assets

Assets are resources owned by a company as the result of transactions. Examples of assets are cash, accounts receivable, inventory, prepaid insurance, land, buildings, equipment, trademarks and customer lists purchased from another company, and certain deferred charges.

The term fixed assets generally refers to the long-term, tangible assets used in a business that are classified as property, plant and equipment. Examples of fixed assets are land, buildings, manufacturing equipment, office equipment, furniture, fixtures, and vehicles. Except for land, the fixed assets are depreciated over their useful lives

Depreciation
Since most assets depreciate in value overtime, accounting practices mandate that fixed assets are prorated to decrease their value on the books over an estimated period of time. Buildings, machinery, equipment, furniture, fixtures, computers, outdoor lighting, parking lots, cars, and trucks are examples of assets that will last for more than one year, but will not last indefinitely. During each accounting period (year, quarter, month, etc.) a portion of the cost of these assets is being used up. The portion being used up is reported as Depreciation Expense on the income statement. In effect depreciation is the transfer of a portion of the asset's cost from the balance sheet to the income statement during each year of the asset's life.

Depreciation expense
The income statement account which contains a portion of the cost of plant and equipment that is being matched to the time interval shown in the heading of the income statement. (There is no depreciation expense for land.)

Accumulated depreciation
The amount of a long term asset's cost that has been allocated to Depreciation Expense since the time that the asset was acquired. Accumulated Depreciation is a long-term contra asset account (an asset account with a credit balance) that is reported on the balance sheet under the heading Property, Plant, and Equipment.

The calculation and reporting of depreciation is based upon two accounting principles:
   1. Cost principle. This principle requires that the Depreciation Expense reported on the income statement, and the asset amount that is reported on the balance sheet, should be based on the historical (original) cost of the asset. (The amounts should not be based on the cost to replace the asset, or on the current market value of the asset, etc.)
   2. Matching principle. This principle requires that the asset's cost be allocated to Depreciation Expense over the life of the asset. In effect the cost of the asset is divided up with some of the cost being reported on each of the income statements issued during the life of the asset. By assigning a portion of the asset's cost to various income statements, the accountant is matching a portion of the asset's cost with each period in which the asset is used. Hopefully this also means that the asset's cost is being matched with the revenues earned by using the asset.

There are several depreciation methods allowed for achieving the matching principle. The depreciation methods can be grouped into two categories: straight line depreciation and accelerated depreciation.

The assets mentioned above are often referred to as fixed assets, plant assets, depreciable assets, constructed assets, and property, plant and equipment. It is important to note that the asset land is not depreciated, because land is assumed to last indefinitely.

Example
To illustrate depreciation used in the accounting records and on the financial statements, let's assume the following facts:
    * On July 1, 2009 a company purchases equipment having a cost of $10,500.
    * The company estimates that the equipment will have a useful life of 5 years.
    * At the end of its useful life, the company expects to sell the equipment for $500.
    * The company wants the depreciation to be reported evenly over the 5–year life.

Calculation of Straight-line Depreciation
The most common method of depreciating assets for financial statement purposes (as opposed to the method used for income tax purposes) is the straight-line method. Under this depreciation method, the depreciation for each full year is the same amount.

The depreciation expense for a full year when computed under the straight-line method is illustrated here:
Cost of the asset         $10,500
Less: Expected salvage value          –   500
Depreciable Cost (amount to be depreciated over the estimated useful life)         $10,000
Years of estimated useful life                  5
Depreciation Expense per year         $ 2,000

If a company's accounting year ends on December 31, the company will report the depreciation expense on the company's income statement as shown in the following depreciation schedule:

Oracle Release 12

 

1. Change in Organization model (Legal Entity & Ledger Sets)
2. Multi-Organization Access Control (MOAC)
3. Accounting Engine (SLA)
4. Inter-company Accounting (AGIS)
5. eBusiness Tax
6. Bank Model

Ledgers and Subledgers

A fundamental concept in Oracle Applications is the "Ledger." The Ledger represents an accounting representation for an organization that is accountable in a self-contained way. The ledger replaces the 11i concept of a set of books.

1. A ledger provides balanced ledger accounting for the accounting entity and serves as the repository of financial information.
Ledger balances have meaning - they assert that the balance:
  1. on an account
  2. at a given date
  3. has a specific value in a particular currency and
  4. is properly calculated.

2. The four basic elements of ledger are  Chart of Accounts (COA), Calendar, Currency, and accounting Convention and comibned known as 4C. SOB had 3Cs.
The COA provides the account; Calendar the date; Currency the amount; and Convention the calculation.

3. It represents an accounting representation for one or more legal entities or for a business need such as consolidation or management reporting.

Legal Entities can be mapped to entire Ledgers or if more than one Legal Entity is used within a ledger, each Legal Entity is mapped with the balancing segments within a ledger

Secondary Ledger

• If it is required to represent the primary ledger transactions in another accounting method, chart of accounts, calendar, currency, and/or ledger processing options, secondary ledgers will have to be setup.
• At least one C has to be different to create a secondary ledger
• Primary ledger is the main record keeping ledger
• One or more secondary ledgers are created to retain alternate representations for the different reporting requirements.
• Each secondary ledger can differ from the primary ledger by the chart of accounts, calendar, currency, and accounting method.
• When using a second ledger, either the details or only the balances can be transferred 

Notes : Technically the realtionsip between Legal entity and Ledger is many to many as one legal entity can be reoprted in more than one ledger and similarly, one ledger may contains more than one legal entity.

Reporting Currency
If it is required to maintain ledger transactions in multiple currencies, we can use reporting currencies.  It replaces MRC feature in 11i

Reporting currencies are additional currency representations of primary or secondary ledgers

Unlike secondary ledgers, reporting currencies can only differ by currency from their source ledger and must share the same chart of accounts, accounting calendar/period type combination, subledger accounting method, if used, and ledger processing options

Reporting currencies can be used for supplementary reporting purposes, such as consolidation or management reporting

Ledger Sets
Ledgers can be grouped into "Ledger Sets".

1. A Ledger Set is a collection of ledgers that can be managed as though they were one ledger. “Manage" includes reporting, opening and closing, running allocation calculations, and entries.

2. Ledgers sets achieves processing efficiencies.

• open or close periods for multiple ledgers simultaneously
• translate balances for all ledgers in a ledger set
• run recurring journals that update balances for multiple ledgers
• run consolidated financial reports that summarize balances across multiple ledgers in a ledger set

3. All ledgers in a ledger set must share the same chart of accounts and accounting calendar/period type combination. They do not have to share the same currency

Balancing Segment
Ledgers balance, that is, the sum of the debit and credit balances equal each other and you can prepare an income statement and balance sheet from them. Oracle Financials checks that imported data, subledger posting, and journal entries (adjustments) balance, in order to maintain this integrity. Ledgers in a Ledger Set also balance and are also
used for financial reporting.

Within a ledger, you can nominate a segment of your chart of accounts to be a "balancing segment". The values (Balancing Segment Values or BSV) that you assign in that segment will represent entities in your organization for which you want to measure both income and wealth, that is, to prepare income statements and balance sheets, and to measure return on investment.

You might do this for divisions, plants, externally reportable segments, legal entities sharing a jurisdiction, and for other reasons. Customers frequently combine entities into BSVs and report on groups of them. For example, if you want to track return on investment (ROI) on both "plants" and "divisions", you might create balancing segment values as shown in the following table.
 

More on Legal Entity

Legal Entities and Accounting

Operating Units can be associated with multiple Legal Entities in shared accounting environment if they are assigned to the same ledger as the Legal Entity

 

LE1 uses the account balancing segments of 1-5, and LE 2 uses the account balancing segments of 6-7 in the same ledger. Both OU1 and OU2 point to the same ledger.

In this shared environment, either the system or the user must determine which LE gets assigned to a transaction. A default legal context sets the default Legal Entity value for a transaction. The user can change this value.

Entering Legal Entity in Transaction Entry form



Legal Entity Association

Operating Units

In the financial applications of Oracle's E-Business Suite, an Operating Unit (OU) is a system organization that:
1. Stores subledger data separately from the data associated with other OUs that support a particular ledger ("Partitions").
2. Administers subledger rules such as those associated with transaction types, sequencing schemes, and other sales tax or VAT regulations ("Complies").
3. Administers user access to the data for processing and reporting ("Secures").
4. Applies to subledger business transaction and document data and associated data such as customer details. Subledger accounting data is not tagged with OU identification unless you elect to do so. General ledger data is not managed through
OUs.
5. Is not product specific and automatically links all subledger products that post to a specific ledger.

Multiple Organizations is the name we give to the functionality that surrounds OUs and it is exploited by all products as appropriate. System legal entities, Ledgers, and OUs are defined in relationship to one another. A legal entity accounts for itself in the Primary Ledger and optionally in other ledgers, and stores its subledger data in one or more OUs.

OUs are often identified with security. In the Oracle E-Business Suite, users are given access to the data they handle though "responsibilities". A responsibility is associated with a specific OU, or with several OUs - this is a feature called "Multiple Organizations Access Control". By securing subledger data in this way users can access and process transaction information only for the particular operating unit or set of operating units to which they have been granted access. They view only what they need and have authorization to view.

OUs can be used to model autonomous organizational units that create financial transactions. You create, process, and report on subledger financial data within the context of an OU.

• Use an OU when you need to keep the data of one organization distinct - at arms length - from the data of another organization. You might have the right to prevent a state's transaction tax auditor from viewing the transactions of a neighboring state; consider storing each state's transactions in separate OUs. This right often exists when the states are independent nations, but seldom when they are federated.
• Use an OU when you need to comply with transaction tax law that is substantially different (more than just the tax rates) to similar laws in neighboring state. You can use product "transaction types" to create similar transactions that follow different documentation and processing practices.
• Use an OU when you wish to keep data of an operation private from management of another operation. For example, within a financial institution division, you may want to keep the transactions and data of the lending operation separate from that of the brokerage operations.

OUs divide the subledger document data in Oracle Financials applications into distinct segments. Standard reports and processes run within OUs; and 'special' reports and processes run across them. You can deploy OUs to provide barriers that require special access, reporting, and processing to cross.

Difference between 11i & R12
In R12 OU is not directly linked with any ledger as it was in 11i where each OU is assigned to a SOB and Legal entity.
In R12 OU is assigned to a Primary Ledger and a default legal context is given to it.
While entering any transaction system tries to find out the legal entity from different defaulting conditions (for example in R12 while entering AR transaction or AP invoice we need to specify the leagl entity which was not the case in 11i), if it does not find any then the dfault legal context LE is considered as the LE for that transaction.
 

Inventory Organizations

Multi-Org Access Control (MOAC)

1. Multi-Org Access Control, or MOAC, enables users to access multiple operating units from a single application responsibility.
2. Operating unit security will be preserved such that companies can effectively implement security and shared services at the same time.
3. Enhanced Multi-Org Reporting provides the ability to process and report critical financial information at different levels of the enterprise.

Prior to Release 12, each responsibility could access only one operating unit.  Therefore, users who had to manage multiple operating units had to log in and log out of multiple responsibilities to perform their tasks. In Release 12, users can perform tasks for multiple operating units without changing responsibilities and its achieved by setting up MO: Security profile.
Usage Example:
In 11i, If a company had three operating units Belgium, Holland, and Denmark, the company would have to create three responsibilities, one for each operating unit.  And users, who had to enter invoices into all 3 operating units, had to log into each one of the EMEA responsibilities separately. 
With Multi-Org Access Control in R12, each application responsibility can access multiple operating units. The company can create a single EMEA responsibility for all three operating units and users would only have to log in once to perform tasks such as: entering payables invoices, viewing consolidated requisitions, performing collections, and processing receiving and drop shipments.

It is required to set up either the MO: Operating Unit or MO: Security Profile profile option for each application responsibility to use Multiple Organizations context sensitive applications. If the MO: Security Profile is set, then the MO: Operating Unit profile is ignored.

Data security is maintained using security profiles that are defined for a list of operating units and determine the data access privileges for a user When drilling down on balances from Oracle General Ledger, General Ledger ignores the operating unit profile setting to allow you to drill down to your subledger details, regardless of which operating unit originated the transaction.

The OU field visible for all relevant transactions and relevant setups.  On data entry, the system will derive the OU, when possible.  E.g. if user enters a PO default invoice, the supplier site determines OU.

Setups

1. Create Security Profile
2. Run Security List Maintenance program
3. Setup profile option MO: Security Profile
4. Setup profile option MO: Default Operating Unit

Note: If a responsibility has to access only one operating unit, then set the profile option - MO: Operating Unit. If a responsibility has to access multiple operating units, then define a security profile with multiple operating units assigned and assign it to the MO: Security Profile profile option
 

Other secruity features in R12

MOAC is not the only security option available in oracle R12.
The other prominent security features are
1. Data Access Set
2. Data defination security.

Subledger accounting

What is a subledger
The subledger, or subsidiary ledger, is a subset of the general ledger used in accounting. The subledger shows detail for part of the accounting records such as property and equipment, prepaid expenses, etc. The detail would include such items as date the item was purchased or expense incurred, a description of the item, the original balance, and the net book value. The total of the subledger would match the line item amount on the general ledger.

There are instances when items will go directly to the general ledger without any subledger.These items will be linked to your balance sheet but not to your profit and loss statement.

What is SLA in R12

• Generation and storage of detailed accounting entries
• Storage of Subledger balances
• Subledger accounting entries (with Bidirectional drilldown to /from transactions)
• Subledger reporting

Features of SLA

• Replaces various disparate 11i setups, providing single source of truth for financial and management analysis. It introduces a common data model and UI across subledgers
• Allows multiple accounting representations for a single business event Optionally Post subledger accounting entries to Secondary Ledgers Resolves conflicts between Corporate and Local Accounting Requirements
• Highly granular level of detail in the Subledger accounting model retained
• Accounting Model separate from Transactional Model
• Catering to custom requirements of accounting of transactions in Subledgers
• Accounting created in Draft or Final mode : 

Benifits of SLA
1. The flexibility of the accounting rule setup allows meeting different requirements in different legislative, geographic or industry contexts.
Assuming operations in multiple countries, each with its own legal requirements and accounting standards, you are able to define a setup to meet each of the requirements. SLA allows for multiple accounting requirements for a single transaction or business event.

2. Increase transparency and enable full auditability of the transaction and accounting data through the new data model
In 11i, accounting information and the tie back to the underlying transaction is maintained differently for each module; and sometimes not at all!
Different subledgers/modules have their own model as to how and what they capture in terms of accounting data.  Some allow capturing more details and some link between the journals and the underlying transactions.  Some do not have the same flexibility or detail.  This causes difficulty and inconsistency in reporting for auditing, reconciliation or whichever purpose across modules.

Another second benefit that SLA brings in R12 is the ability to retain the full link between trx and accounting data for all modules, and thus allow auditability.  The accounting SLA creates is strongly tied to the underlying transactions.

3. Another benefit is the support for business flows in accounting within and across modules.  Basically, in flows involving multiple transactions whose accounting need to be tied together, SLA provides standard features to recognize multi-transactional flows.  This is very important in especially reconciling accounts inter-transactional accounts.
 

Accounting Conventions

Ledgers reflect accounting conventions. The balance on your "revenue" account has meaning only insofar as it reflects your definition of revenue. In turn, your definition of revenue will reflect your compliance with your GAAP (for example, International Accounting Standards/International Financial Reporting Standards (IAS/IFRS) or United States GAAP), your statutory and regulatory obligations, and perhaps your transaction tax regulation mandates.

We make it easy to construct meaningful balances by posting to the accounts according to easily articulated and controlled rules that are applied to each subledger transaction. The rules are set up in Oracle Subledger Accounting and are assigned to individual ledgers. Groups of rules can be managed in sets that we call "Accounting Methods". For those situations where you must comply with both local regulation and a parent GAAP, the rules engine allows you to account for a business transaction using different conventions. This support can be tailored to the complexity of the situation, from automatic adjusting entries in the same ledger through completely populated secondary ledgers.

For example, by using two ledgers with the appropriate conventions, a French firm with a subsidiary in the United States (US), can automatically create local bookkeeping in accordance with US principles (in the US primary ledger), but also simultaneously
maintain accounting for the same transactions in accordance with French regulations (in a French secondary ledger).

SLA Structure & AMB

Accounting Methods Builder is used to create and modify the setup for application accounting definitions(AAD) and journal line defination (JLD) for Oracle subledger applications.

AMB(Accounting Methods Builder) Enables an organization to meet specific fiscal, regulatory and analytical requirements . It Compromises of two models as shown in above picture.

• Event Model
• Accounting Model

Event Model

Definition of the Subledgertransaction types and lifecycle.
Predefined Components-new components cannot be defined.
There are 3 Levels in event model

1. Event Entity: Highest level, often 1 per Subledger
2. Event Class: classifies transaction types for accounting rule purposes
3. Event Type: for each transaction type, defines possible actions with accounting significance

Ledger

Subledger Accounting Method

Owner
Automatically populated. For components seeded by Oracle, the value is Owner. For components created on site by users, the value is User.  When selecting component names from a list of values in AMB windows, users are presented with the name as well as the Owner of the component. This enables users to distinguish between seeded and user-defined components. 

Enabled  If selected, makes this subledger accounting method available for use 

Chart of Accounts region 
The transaction and accounting chart of accounts are optional. If they are entered, then the following rules apply:
Only an application accounting definition with the same or no charts of accounts is available for assignment.
The accounting chart of accounts must match the chart of accounts of the ledger that this subledger accounting method is assigned to.

 Application  Application that owns the application accounting definition for this subledger accounting method 

Note: Oracle recommends that users do not modify a seeded method or any other seeded component as it could get overwritten in an upgrade. Instead, copy a seeded component and then modify it appropriately. The modified component has an Owner type of User.

Application Accounting Definitions

Use application accounting definitions to assign journal lines definitions, supporting references, and header descriptions to event classes and event types.

Storing the accounting definitions validation status at the event class and event level enables you to generate subledger journal entries for certain event classes or event types even if the accounting definitions for other event classes or event types are invalid.

Each event class and event type assignment consists of a header assignment and one or more journal lines definition assignments. A header assignment includes the following:

• source assignments for the GL date and Accrual Reversal GL date, if enabled for the event class
• a journal entry description (optional)
• one or more supporting references (optional)

You can assign multiple journal lines definitions to an event class or event type. Subledger Accounting generates a single journal entry per accounting event and ledger using the line assignments from all the journal lines definitions assigned to the event class or event type. The following can be assigned to a journal lines definition:

1. Journal entry description
2. Journal line type
3. Account derivation rules
4. Supporting references

Sources are used by all of the above components.

The figure below shows the relationship of the components to an application accounting definition as described in the above text.

Application accounting definitions enable you to meet the subledger accounting requirement of multiple accounting representations. While one application accounting definition can generate subledger journal entries that are compliant with one particular set of accounting requirements, another definition can be defined to meet a completely different set of accounting requirements.

For example, use a complete set of US GAAP accounting definitions for Payables as an application accounting definition for the ledger US applications. Use a complete set of French GAAP accounting definitions for Payables can be used for the ledger French Operations. These two sets of definitions have differences based on the setup of the various components that make up their application accounting definitions.

Seeded application accounting definitions are provided for all Oracle subledgers. If specific requirements are not met by startup accounting definitions, users can copy and modify the seeded definitions and their assignments.

The Applications Accounting Definitions (AAD) Loader enables users to import and export application accounting definitions and journal entry setups between the file system and database instances. The AAD Loader also supports concurrent development and version control of the application accounting definitions.
 

Journal Lines Definitions

Use journal lines definitions to create sets of line assignments for an event class or event type. These sets can be shared across application accounting definitions.

In the Journal Lines Definitions window, you can:

• Assign account derivation rules, supporting references, and descriptions to journal line types

• Define multiperiod accounting rules for a journal line type

Journal Lines Definitions Examples

Example 1

A public sector agency buys computer equipment for $10,000. Besides accounting for the purchase, the agency wants to set aside money to cover for its replacements. The required journal entries are described in the table below.

To achieve the above journal entries, two journal lines definitions are required as described in the following tables.

Standard Invoice Journal Lines

Public Sector Invoice Journal Lines
Example 2

This example describes how to allocate an invoice's liability amount across multiple balancing segments on the invoice distributions.

The Accounting Flexfield structure is Balancing Segment-Cost Center-Account. The default liability account for supplier site ABC is 000-000-2300. If automatic offsets using the balancing method are enabled, an invoice entered for supplier site ABC is distributed as described in the table below.

To achieve the above journal entry, the journal line definition is defined as described in the table below.

Invoice Journal Lines with Automatic Offsets

The Liability journal line type requires the following account derivation rules:

Journal Line Type

Application:  Automatically populated with the application name associated with the user's responsibility. 

Line Type Code: Users cannot modify a seeded journal line type or any other seeded component as it could get overwritten in an upgrade. Instead users can copy the seeded type and then modify it appropriately. The copied journal line type has an Owner type of User.
The list of values displays the component name and the owner to distinguish between seeded and user-defined components.
 
Name:  Appears in the list of values when assigning the journal line type to a journal lines definition. 

Accounting Class:  Shared across applications and enables users to classify journal entry lines.
For example, when a receipt is matched to a purchase order and the accrual method is On Receipt, an accrual journal line is created upon receipt creation. When the Payables invoice is matched to a purchasing document, Payables creates a journal line reversing the original accrual. In this case, Purchasing and Payables define journal line types to generate these accruals and both of them can assign the accounting class Accrual.
Accounting classes are defined using an extensible AOL lookup type. The list of values for this field contains all accounting classes that are seeded but users can add new accounting classes. 

Rounding Class:  Defaults to the accounting class.
The rounding class, along with the transaction rounding reference accounting attribute, groups lines together in order to determine whether rounding is necessary. 

Enabled:  If selected, makes this journal line type available for use. 

Encumbrance:  If this balance type is selected and the business flow method is not Prior Entry, an encumbrance type must be selected from the drop-down list.
This field is disabled if Prior Entry is selected as the business flow method or if Accrual or Recognition is selected as the Multiperiod option. 

Side:  A Gain/Loss journal line type creates a debit line for a loss and a credit line for a gain. The gain/loss side journal line type is used exclusively for the gain or loss amount automatically calculated by Subledger Accounting and can only be defined for the actual balance type.
Note: For journal line types with a side of Gain/Loss, the following accounting attributes are not displayed in the Accounting Attributes Assignments window when accessed from this window:
Applied to Application ID, Applied to Distribution Type, Applied to Entity Code, Applied to First Distribution Identifier,
Applied to First System Transaction Identifier, Multiperiod End Date, Multiperiod Option, Multiperiod Start Date, Conversion Date,
Conversion Rate, Conversion Rate Type, Entered Amount, Entered Currency Code
Note: If the business flow method Prior Entry or Same Entry is selected, the Gain/Loss option cannot be selected.
The Gain/Loss option can only be selected if the business flow method is set to None and the Multiperiod option is also set to None.
 
Switch Debit/Credit: Determines whether negative amounts will result in negative amounts on the same side or positive amounts on the opposite side.
Note: If the Side is Gain/Loss, the Switch Debit/Credit field is disabled.
 
Merge Matching Lines:  Summarizes subledger journal lines within each subledger entry. Journal entry lines with matching criteria are merged.
The possible values are:
All: All matching lines within a subledger journal entry with the same values for the following attributes:
Accounting Class, Rounding Class, Transaction Rounding Reference, Switch Side flag, Gain or Loss flag, Business Flow Class code
Multiperiod Option, Currency, Conversion Rate Type, Conversion Date, Conversion Rate, Third Party, Third Party Site, Third Party Type
Accounting Flexfield, Description, Reconciliation Reference, Gain/Loss Reference, Encumbrance Type
As a result of merging, a journal entry line with a net of zero amount can be created.
Note:  that choosing All only merges all lines within a given subledger journal entry. This does not impact the transfer to General Ledger of summarized data. The latter is decided by making a choice in the Transfer to General Ledger region.

No: Matching lines are not merged.

Dr/Cr: Matching lines with the same debit or credit side are merged to produce a single debit or credit line when the attributes listed above are matching across debit or credit lines.
Note: Normally, users merge matching lines. However there are some exceptions. For example, in Italy, gain or loss amounts must be recorded for each invoice payment rather than at the total payment level. By setting the merge selection to No, users guarantee that journal entry lines are not merged, even though they are for the same transaction and entry.
 
Subledger Gain or Loss:  Yes indicates that gain/loss is calculated in the primary ledger. The gain/loss amount is therefore not converted to the reporting currency and non-valuation method secondary ledgers. Select No for Subledger Accounting to calculate the gain or loss.
Note: When Gain or Loss is set to Yes, multiperiod accounting is disabled.
 
Transaction:  Transaction chart of accounts.

Method:  Business flow method
If Prior Entry or Same Entry is selected, the Gain/Loss option in the Side region cannot be selected.
If Prior Entry is selected, then the following accounting attributes are inherited from an upstream journal entry and cannot be selected or updated in the Accounting Attributes Assignments window:
Currency Code, Conversion Rate Type, Conversion Date, Conversion Rate, Party Type, Party Identifier, Party Site Identifier, Encumbrance Types
 
Class:   Business flow class; required if the business flow method is Prior Entry 

Multiperiod:  
None: Journal line type will not create multiperiod accounting.
Accrual: To create the accrual journal line for the originating entry, such as prepaid expense
Recognition: To create the recognition journal line
Note: When Gain or Loss is set to Yes, multiperiod accounting is disabled and defaults to None.

Transfer to GL:  Select Detail to maintain the same level of detail as the subledger journal entry line. Select Summary to summarize subledger journal entry lines by Accounting Flexfield.
One journal line is created in General Ledger to record the subledger activity.

Conditions:  Opens the Journal Line Type Conditions window.

Accounting Attribute Assignments: This button is enabled when the conditions are entered.
Opens the Journal Line Accounting Attribute Assignments window.
When creating a journal line type, accounting attribute assignments are automatically established based on the default accounting attribute assignments for that journal line type's event class or entity. In the Journal Line Accounting Attribute Assignments window, override this default mapping of standard sources to accounting attributes. The list of values for the Source field contains all header level sources that are assigned by developers to the accounting attribute and event class associated with the journal line type. Users can assign a source to the Reconciliation Reference accounting attribute which is used to meet accounting requirements in continental Europe. 

Journal Entry Description

Application:  Defaults from the application associated with the responsibility 

Owner:  Automatically populated. Value is Oracle for seeded components. Value is User for components created on site by users. 

Transaction Chart of Accounts:  Chart of accounts used to input and create transactions

Enabled: Retain the default to make the description available for assignment to application accounting definitions 

Priority: Users can create more than one priority number for a journal entry description, each one with its own conditions and details. Description details are evaluated in ascending priority order, where the highest priority has the lowest number until a condition is met. For performance reasons, use the most commonly met descriptions first.

Change the order in which description details are evaluated by updating the priority number instead of deleting and rewriting the descriptions. Once the conditions associated with a detail line are satisfied, the value from that line is used and other lines are ignored.

If none of the conditions are met, enter a last line with no conditions associated to it. Because Subledger Accounting uses this line as a default, assign the lowest priority to this line.
The Journal Entry Description field displays a concatenation of the elements of the description created in the Journal Entry Description Details window as described in To Define Journal Entry Description Details. 
 

Account Derivation Rules

INV OU PL LE

Below query finds out all the Inventory Organization and corresponding Operating Unit, Ledger and Legal Entity.

Select a.organization_id, a.organization_code, a.organization_name,
a.operating_unit, b.name OU, a.set_of_books_id,d.name LEDGER,
a.legal_entity,c.name LE_NAME
From  apps. ORG_ORGANIZATION_DEFINITIONS a,
apps. HR_OPERATING_UNITS b,
apps. xle_entity_profiles c,
apps. gl_ledgers d

Where a.operating_unit=b.organization_id
AND c.legal_entity_id=a.legal_entity
AND d.ledger_id=a.set_of_books_id
 

System Administrator - Security

Release 12 of Oracle Applications provides significant enhancements to the Oracle Applications security system. Core Security now includes a Role Based Access Control model that builds on the existing Function Security and Data Security models. A new set of administrative features that build on Core Security are also introduced in this release.

Oracle User Management
Oracle User Management is a secure and scalable system that enables organizations to define administrative functions and manage users based on specific requirements such as job role or geographic location. With Oracle User Management, instead of exclusively relying on a centralized administrator to manage all its users, an  organization can create local administrators and grant them sufficient privileges to manage a specific subset of
the organization's users. This provides the organization with a more granular level of security, and the ability to make the most effective use of its administrative capabilities.

Oracle's function and data security models constitute the base layers of this system, and contain the traditional system administrative capabilities. Organizations can optionally add more layers to the system, depending on the degree of flexibility they require.

Key features of Oracle User Management include:
Role Based Access Control (RBAC) - Enables organizations to create roles based on specific job functions, and to assign these roles the appropriate permissions. With RBAC, administrative privileges and user access are determined by assigning individuals the appropriate roles.

Delegated Administration - Enables system administrators to delegate some of their administrative privileges to individuals that manage a subset of the organization's users. These individuals are assigned administrative privileges for a limited set of roles that they can assign to the users they manage.

Registration Processes - Enable organizations to provide end-users with a method for requesting various levels of access to the system, based on their eligibility. Registration processes also simplify an administrator's job by providing streamlined flows for account maintenance and role assignment.

Self Service Requests and Approvals - Enable end users to request initial access or additional access to the system.

Oracle Application Object Library Security
Oracle Application Object Library security comprises two main components, Function Security and Data Security.

Function Security restricts user access to individual menus of functions, such as forms, HTML pages, or widgets within an application. Function Security by itself restricts access to various functions, but it does not restrict access to the data a user can see or what actions a user can perform on that data.

Data Security restricts the access to the individual data that is shown once a user has selected a menu or menu option. For example, with Data Security you can control the set of users that a particular local security administrator can access within Oracle User Management. In conjunction with Function Security, Data Security provides additional
access control on data that a user can see or actions a user can perform on that data.

User and Data Auditing
Oracle Applications allows you to audit users and changes they make to application data.
The Sign-On Audit feature allows you to track your users' activities. You can choose who to audit and what type of user information to track. Sign-On Audit reports give you historical, detailed information on your users' activities within an application. Also, the Monitor Users form allows you to view online, real-time information on user activity.

AuditTrail lets you keep a history of changes to important data: what changed, who changed it, and when. With AuditTrail, you can easily determine how any data row or element obtained its current value. You can track information on most types of fields, including character, number, and date fields.

Security Administrators manage all user accounts in the system, and can assign / revoke all roles. Security Administrators also manage system accounts (such as GUEST), that are not tied to a person.

Access Control with Oracle User Management

In Release 12 Core Security includes Oracle's Function and Data Security models, as well as Role Based Access Control. Administrative Features build upon Core Security and include Delegated Administration, Registration Processes, and Self Service and Approvals.

Core Security and Administrative Features are implemented in successive layers and each builds upon the one that precedes it. Organizations can optionally uptake the various layers, depending on the degree of automation and scalability that they wish to build upon the existing Function and Data Security models.

In general, Access Control with Oracle User Management begins with basic system administration tasks, progresses to more distributed, local modes of administration, and ultimately enables users to perform some basic, predefined registration tasks on their own. The above diagram illustrates how the layers build upon each other.

Function Security
Function Security is the base layer of access control in Oracle Applications. It restricts user access to individual menus and menu options within the system, but does not restrict access to the data contained within those menus. For example, an organization could use Function Security to provide its sales representatives with the required
menus and menu options for querying customers. It could also control access to specific components of those pages such as a button on a sales forecasting page

Data Security
Data Security is the next layer of access control. Building on Function Security, Data Security provides access control within Oracle Applications on the data a user can access, and the actions a user can perform on that data. Oracle Applications restricts access to individual data that is displayed on the screen once the user has selected a menu or menu option. For example, Data Security restricts the set of users that a local administrator can access within Oracle User Management. Data Security policies can only be defined for applications that have been written to utilize the Data Security Framework.

Role Based Access Control (RBAC)
RBAC is the next layer and builds upon Data Security and Function Security. With RBAC, access control is defined through roles, and user access to Applications is determined by the roles granted to the user. Access control in Oracle Applications closely follows the RBAC ANSI standard (ANSI INCITS 359-2004) originally proposed by the National Institute of Standards & Technology (NIST), which defines a role as "a job function within the context of an organization with some associated semantics regarding the authority and responsibility conferred on the user assigned to the role."

A role can be configured to consolidate the responsibilities, permissions, function security and data security polices that users require to perform a specific function. This is accomplished with a one-time setup, in which permissions, responsibilities, and other roles are assigned to the role. Users are not required to be assigned the lower-level
permissions directly, since permissions are implicitly inherited on the basis of the roles assigned to the user. This simplifies mass updates of user permissions, since an organization need only change the permissions or role inheritance hierarchy defined for a given role, and the users assigned that role will inherit the new set of permissions
automatically.

Role Inheritance Hierarchies
Roles can be included in role inheritance hierarchies that can contain multiple subordinate roles and superior roles. With role inheritance hierarchies, a superior role inherits all of the properties of its subordinate role, as well as any of that role's own subordinate roles. The following example demonstrates how role inheritance hierarchies can greatly simplify user access control and administration.

Delegated Administration
Delegated Administration is a privilege model that builds on the RBAC system to provide organizations with the ability to assign the required access rights for managing roles and user accounts. With delegated administration, instead of relying on a central administrator to manage all its users, an organization can create local administrators and grant them sufficient privileges to manage a specific subset of the organization's users and roles. This provides organizations with a tighter, more granular level of security, and the ability to easily scale their administrative capabilities. For example, organizations could internally designate administrators at division or even department
levels, and then delegate administration of external users to people within those (external) organizations. Delegation policies are defined as data security policies. The set of data policies that are defined as part of delegated administration are known as Administration Privileges.

Delegating to Proxy Users
There are a number of business scenarios in which users of Oracle E-Business Suite need to grant delegates the ability to act on their behalf (act as proxy users for them) when performing specific E-Business Suite functions. Traditionally, delegators have done this by giving passwords for specific applications to other users. A delegate who
was given another user's passwords for certain applications could assume the identity and privileges of the delegator within those applications, and only those applications.

The integration of E-Business Suite with Oracle Application Server 10g Single Sign-On (SSO) makes this traditional strategy insecure. If a delegator grants a delegate access to his SSO password, the delegate will be able to access every SSO-enabled application to which the delegator has access, not just to specific applications. The new mechanism was designed to enable limited, auditable delegation of privilege from delegators to their delegate

Provisioning Services
Provisioning services are modeled as registration processes that enable end users to perform some of their own registration tasks, such as requesting new accounts or additional access to the system. They also provide administrators with a faster and more efficient method of creating new user accounts, as well as assigning roles.
Registration processes accomplish this by encapsulating core components of registration, including:

• The role(s) assigned after the user successfully completes the process.
• An optional registration user interface for collecting account or additional information.
• A workflow for approval, confirmation, rejection, and identity verification notifications.
• The Approval Management Transaction Type. A transaction type represents a set of approval routing rules that are interpreted at runtime.
• The set of users that are eligible to sign up for additional access (only applicable for Request for Additional Access registration processes).
• Whether identity verification is required. Identity verification confirms the identity of a requester before the registration request is processed, by sending an email notification to the requester's email address. If the recipient does not reply within a specified time, the request will be automatically rejected.
• The set of local administrators that should be able to register people and/or create users through the Account Creation by Administrators registration process.

When a user completes registration using a registration process, the system captures the required information from the user, and subsequently assigns that person a new user account, role, or both. Oracle User Management supports three types of registration processes: Self-service Account Requests, Requests for Additional Access, and Account Creation by Administrators.

Web ADI

Web ADI brings Oracle E-Business Suite functionality to the desktop where the familiar  Microsoft Excel, Word, and Project applications can be used to complete your Oracle E-Business Suite tasks. This guide provides instructions on using the Microsoft Excel functionality.

The Web ADI integration with Microsoft Excel enables you to bring your E-Business Suite data to a spreadsheet where familiar data entry and modeling techniques can be used to complete Oracle E-Business Suite tasks. You can create formatted spreadsheets on your desktop that allow you to download, view, edit, and create Oracle E-Business Suite data. Use data entry shortcuts (such as copying and pasting or dragging and dropping ranges of cells) or Excel formulas to calculate amounts to save time. You can combine speed and accuracy by invoking lists of values for fields within the spreadsheet.

After editing the spreadsheet, you can use Web ADI's validation functionality to validate the data before uploading it to the Oracle E-Business Suite. Validation messages are returned to the spreadsheet, allowing you to identify and correct invalid data.

The fields that appear in the spreadsheet, their positions, and their default values can all be customized through Web ADI's Layout functionality. This allows you to create a more productive work environment by removing unnecessary fields from the spreadsheet, and by organizing the spreadsheet in a way that conforms to your
practices.

Key Features
Oracle Web ADI includes the following features:

Works Via Internet
Web ADI uses Internet computing architecture to lower the total cost of ownership by having the product centrally installed and maintained. No installation is required on client machines; you need only a Web browser and Microsoft Excel. This architecture also provides superior performance over a WAN or dialup connection, since the exchange between client and server is simplified through the use of HTML.

Presents E-Business Suite Data in a Spreadsheet Interface
Spreadsheets provide a familiar interface that is common in the business environment. You can use familiar editing capabilities such as copying and pasting data, and moving ranges of cells to create or edit large amounts of data. Recurring data entry is possible by saving a spreadsheet, and then uploading it at needed intervals, such as every month or every quarter. Spreadsheets offer additional flexibility in the way work is done; they can be sent to others for approval or review, and they can be edited when disconnected from a network.

Validates Data
All data in the spreadsheet can be validated against Oracle E-Business Suite business  rules before it is uploaded. This includes validation against key and descriptive flexfields. Data is validated against accounts, segment security rules, and cross validation rules. If any errors are found, messages are returned directly to the spreadsheet, enabling you to correct the errors and successfully upload the data.

Enables Customizations
You can use the layout functionality to determine what fields appear in your spreadsheet, where they appear, and if they contain default values. These definitions can be saved, reused, and modified as needed.

Automatically Imports Data
Wed ADI automatically imports data into your Web ADI spreadsheets whenever you create them. This information can come from the Oracle E-Business Suite or from a text file. Imported information can be quickly modified in Excel, validated, and uploaded to the Oracle E-Business Suite. This feature can be useful when migrating data from a
legacy system to the Oracle E-Business Suite.

Multiple Organizations Reporting

Multiple Organizations Reporting enhances the reporting capabilities of Oracle Applications products by allowing you to report at the:

1. Ledger level
2. Operating unit level

The Multiple Organizations Reporting feature is comprised of below components:

• Reporting Parameters
• Report Types

Reporting Parameters
Two new parameters have been added to the reports that are enabled for Multiple Organizations Reporting: Reporting Level and Reporting Context.

Reporting Level: Allows users to choose the level at which they want to report. The valid options are Ledger, and Operating Unit. If the user chooses Ledger as the reporting level, then the report displays data for the operating units assigned to the ledger that the user can access. If the user chooses Operating Unit, the operating units that can be selected depends on the operating units assigned to the MO: Operating Unit or the MO: Security Profile profile option. If the MO: Security Profile profile option is set, the MO: Operating Unit profile option is ignored.

Reporting Context: Allows users to choose an entity within the reporting level they have selected. Valid options are ledger names, or operating unit names, depending on the reporting level value.

Report Types
Reports can be classified into three broad categories:
Cross Organization Reports &  Multiple Organization Reports

Cross Organization Reports : Cross Organization Reports report data for one or more Operating Units.
MO: Security Profile profile option controls the operating units a user can submit a report for. The Reporting Level and Reporting Context determine the level a user can submit a report for. The possible reporting levels are:

• Operating Unit: Report for a single operating unit.
• Ledger: Operating units in a ledger.

Cross Organization reports have two possible values: Ledger and Operating Unit. The available value for context is validated against user's access privilege. If the user chooses Ledger as the context level, a report is generated based on data from all operating units assigned to that ledger that the user has access to. If the user does not
have access to all operating units that make up a Ledger, then the report output indicates the set of operating unit data that was used for report generation.

Multiple Organization Reports
Multiple Organization Reports report data for one or more multiple operating units from a single responsibility.
With multiple organizations access control, a responsibility could have access to multiple operating units from a single responsibility. Even though the user can access one or more Operating Units, the user can only report data for one operating unit at a time. For example, if the Profile option MO: Security Profile gives access to three Operating Units, the user can choose one of the three operating units when submitting the report.

Running Reports



To run reports at different reporting levels:
1. Navigate to the Submit Request window.
2. At the Submit Request window, choose the report you want to run.
3. At the Parameters window, choose the reporting level (Ledger, or Operating Unit).
4. Choose the reporting entity.
 

Multiple Org Report Example

Assume Acme Inc. has Multiple Organization architecture set up as shown in the figure below. You are an Oracle Applications user connecting to a responsibility that is linked to the Western Division operating unit.

The figure depicts an organization structure that is used as an ongoing example in the Reports chapter of the Multi-Org publication. The top-level box of the organization chart represents the entire organization, and is labeled Acme, Inc. This box splits out into US Operations (ledger) and France (ledger). The France ledger drills down to the
transactions entered by the France (operating unit) in the context of the French legal entity.

The US Operations ledger drills down to the transactions entered for the US (legal entity) and Canada (legal entity). US (legal entity) drills down to Western Division (operating unit) and Eastern Division (operating unit). The Canada legal entity drills down to the Canada Division (operating unit).

Reports

Oracle Payables
All standard Payables and Subledger reports can be run for an operating unit.
The following Payables reports can also be run for a ledger or ledger set to report on balances across all operating units assigned to a given ledger or ledger set:

• Payables Posted Invoice Register
• Payables Posted Payments Register for a Ledger or Ledger Set
• Open Account Balances Listing

• Adjustment Register
• Adjustments Journal Report
• Aging - 4/7 Buckets Report
• Applied Receipts Journal
• Applied Receipts Register
• AR Reconciliation Report
• AR: Journal Entries Report
• Credit Hold Report
• Cumulative Activity Balance Report
• Customer Credit Snapshot
• Invoice Exception Report
• Miscellaneous Receipts Register
• On Account Credit Memo Gain and Loss Journal
• Other Receipt Applications Report
• Receipt Journal Report
• Receipt Register
• Sales Journal By Customer
• Sales Journal by GL Account Report
• Transaction Register
• Unapplied Receipts Journal
• Unapplied and Unresolved Receipts Register

•  Tax Audit Trail
•  Tax Register
•  Use Tax Liability
•  Intra-EU VAT Audit Trail
•  U.S. Sales Tax Report
•  Tax Reconciliation Report
•  Financial Tax Register
•  Canadian GST/PST Tax Report

Concurrent Programs

A new field Operating Unit Mode is included to the Define Concurrent Programs window which allows users to specify the concurrent programs for multiple organizations. The concurrent programs can be categorized into Single, Multiple or Null. The default value is Null. The concurrent program is used to execute the multiple organizations initialization and also determine when to display Operating Unit field in the Submit Requests window and Schedule Requests window.

There are two categories of Concurrent programs:
1. Single Organization Concurrent Programs
2. Multiple Organization Concurrent Programs

Single Organization Concurrent Programs
Single Organization concurrent programs are non-report programs that report or process data for one Operating Unit only. These programs show data for the Operating Unit specified by MO: Operating Unit profile option. These programs are flagged as Single for Operating Unit mode in the Define Concurrent Programs window.

Multiple Organization Concurrent Programs
The Multiple Organization Concurrent Programs process or report date for multiple operating units specified by the profile option MO: Security Profile. These programs display the operating unit as an optional parameter. The user selects an operating unit and submits the program or leaves it blank. If the parameter is left blank, the concurrent
program processes or reports data for the operating units specified in the MO: Security Profile.

The figure below shows an Submit Request window with the operating unit parameter added for the Payables Open Interface Import program. Users may either choose to enter a value for the Operating Unit or leave it blank and submit the request. If you specify the operating units invoices are processed for  the respective operating units else
invoices are processed for all the operating units in the security profile.

Currency Profiles

OM profiles

1. Retain Time for Non-ATPable Items :
In the case of ATP enabled items, the timestamp will always schedule to 23:59:00 as ATP considers all the components and resources available till end of day.

In the case of non-ATPable items, the profile 'MSC: Retain Time stamp for Non ATPABLE items' is used.
If this is set to Yes, the timestamp can be saved to the value entered by the user.

The Profile can be set to either Yes or No.

MSC:Retain time for Non-ATPable items set to Yes
------------------------------------------------

ATP returns same time stamp as passed to ATP from the Request Date and Time, for all single lines
for non-atpable items or for all sets containing only non-atpable items.

If a set contains mix of atpaple and non atpable items, then ATP continues to return 23:59:00 as
the new timestamp.

MSC:Retain time for Non-ATPable items set to No
-----------------------------------------------

If the profile is set to 'No', then ATP will also return 23:59:00 as the time stam

2. OM: Add Customer

This profile enables user to allow customer in the create sales order window.

Value of a profile in a responsibility

Select fpo.profile_option_name,fpo.user_visible_flag, fpo.user_changeable_flag, fr.responsibility_key, pov.profile_option_value from apps. fnd_profile_option_values pov, apps. FND_RESPONSIBILITY fr, APPS.fnd_profile_options fpo where pov.LEVEL_VALUE_APPLICATION_ID = fr.APPLICATION_ID AND pov.LEVEL_VALUE=fr.responsibility_id AND fpo.profile_option_id= pov.profile_option_id AND fpo.profile_option_name LIKE '%AR%CONTEX%' -- profile name AND fr.responsibility_key LIKE 'XX%AR%SET%' -- responsibility name

user name, employee & associated responsibilities

SELECT fu.user_name "User Login", fu.description "Role Description", fu.start_date "Login Start Date", fu.end_date "Login End Date", fu.email_address "E-Mail Associated", fu.employee_id "Employee Id", ppf.employee_number "Employee Number", ppf.full_name "Full Name", hou.NAME "Business Group", fr.responsibility_name "Responsibility Associated", fur.start_date "Association Start Date", fur.end_date "Association End Date" FROM apps.fnd_user fu, apps.per_all_people_f ppf, apps.hr_all_organization_units hou, apps.fnd_user_resp_groups_all fur, apps.fnd_responsibility_tl fr WHERE ppf.person_id = fu.employee_id AND hou.organization_id = ppf.business_group_id AND ppf.effective_end_date = TO_DATE ('31/12/4712', 'DD/MM/RRRR') AND fu.user_id = fur.user_id AND NVL (fur.end_date, SYSDATE + 1) > SYSDATE AND fur.responsibility_id = fr.responsibility_id AND fr.responsibility_name LIKE '%XXXX%' – Replace with appropriate OU Qualifier AND fr.LANGUAGE = 'US' ORDER BY fu.user_name, fr.responsibility_name

Worklist & notification

The Worklist pages let you view and respond to your notifications using a Web browser. The Advanced Worklist provides an overview of your notifications, from which you can drill down to view an individual notification in the Notification Details page. You can also reassign notifications to another user, request more information about a notification from another user, respond to requests for information, and define vacation rules to handle notifications automatically in your absence.
Oracle Workflow also provides the Personal Worklist, which includes additional options to specify what notifications to display in your Worklist and what information to display for those notifications. Before you can use the Personal Worklist, your system administrator must give you access to it.

Worklist Access

The Advanced Worklist also lets you grant access to your worklist to another user. That user can then act as your proxy to handle the notifications in your list on your behalf. You can either grant a user access for a specific period or allow the user's access to continue indefinitely.
The worklist access feature lets you allow another user to handle your notifications without giving that user access to any other privileges or responsibilities that you have in Oracle Applications. However, note that a user who has access to your worklist can view all the details of your notifications and take most actions that you can take on the notifications. Ensure that you take all necessary security considerations into account when you choose to grant worklist access to another user.

Advantages
If another user has granted you access to his or her worklist, you can switch the Advanced Worklist to display that user's notifications instead of your own. When viewing another user's worklist, you can perform the following actions:

View the details of the user's notifications.
Respond to notifications that require a response.
Close notifications that do not require a response.
Reassign notifications to a different user.
Request more information about a notification from a different user.
Respond to a request for more information.

Limitations
If the user whose worklist you are accessing has a notification sent from you, you can only view that notification and cannot take any action on it. For example, you cannot respond to a notification that you reassigned to the other user, nor to a notification marked as being sent from you by special logic in the workflow, such as an expense report that you submitted to the other user for approval.
You cannot define vacation rules for the user whose worklist you are viewing. You also cannot grant access to that user's worklist to anyone else.