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 o Financial Management o Human Capital Management o Project Management * Procurement * Product Lifecycle Management * Supply Chain Management o Supply Chain Planning o Logistics & Transportation Management o Order Management o Price Management * Manufacturing While learning oracle application one should follow a proper strategy and try to study one module at a time. A good learning path could be 1.Inventory 2.Order Management a.Advanced Price List b.RLM c.iStore 3.Purchasing a.iSupplier 4.Cost Method 5.BOM 6.WIP 7.MRP 8. General Ledger 9. Account Receivables 10. Account Payables

11. Oracle Service 12. Oracle Engineering Before going into details of all these modules one should have a through understanding of some basic oracle concepts like

Masters in Oracle
Posted Tue, 08/18/2009 - 15:39 by Anonymous

Multiple Organizations Overview - R12
The Oracle Applications organization model defines organizations and the relationships among them in arbitrarily complex enterprises. This organization model serves as the cornerstone for all of the Oracle Applications products. It dictates how transactions flow through different organizations and how those organizations interact with each other. Multi-Org is an application and database enhancement that enables multiple business units(operating units) in an enterprise to use a single installation of oracle applications products while keeping transaction data separate and secure.

Major Features of Multi-org Multiple Organizations in a Single Installation You can define multiple organizations and the relationships among them in a single installation of Oracle Applications. These organizations can be ledgers, business groups, legal entities, operating units, or inventory organizations. Secure Access You can assign operating units to a security profile and then assign the security profile to responsibilities or users. If multiple operating units are assigned to the security profile, then a user can access data for multiple operating units from a single responsibility. This ensures that users can only access, process, and report on data for the operating units they have access to. Data Security You can limit users to information relevant to their organization. For example, you can limit access for order administration clerks to sales orders associated exclusively with their sales office. Inventory Organization Security by Responsibility You can specify the inventory organizations that are available to users in each responsibility. The Choose Inventory Organization window automatically limits available inventory organizations to those authorized for the current responsibility. Responsibility Determines Operating Unit Your responsibility determines which operating units you can access when you use Oracle Applications. If you only want a responsibility to access only one operating unit, then set the profile option called MO: Operating Unit. If you want a responsibility 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. Additionally, if using the MO: Security Profile profile option, you can also set the MO: Default Operating Unit profile option to specify a default operating unit that will default in transaction entry pages.

Types of Organizations You can define organizations and the relationships among them. You can define security for either an organization hierarchy or list of organizations.

Business Group The business group represents the highest level in the organization structure, such as the consolidated enterprise, a major division, or an operation company. The business group secures human resources information. For example, when you request a list of employees, you see all employees assigned to the business group of which your organization is a part.

The business group drives the legislation used for human resources and payroll purposes. If the implementation involves employees in multiple countries, then it will likely require several different business groups, one for each country where employees are located. This assumes that the company does not seek to customize multiple legislative requirements into one business group.

The HRMS best practice recommends that a new business group should represent a country or regional level partition of data. All companies that operate in the country or regions should be represented as legal employers in the business group.

SOB/PL Set of books in 11i consists of 3Cs - Chart of Account, calendar, currency Primary ledger in R12 consists of 4Cs See the child chapter to this http://www.oracleug.com/user-guide/basics-oracle/define-sob Legal Entity

A legal company for which you prepare fiscal or tax reports. You assign tax identifiers and other legal entity information to this type of organization. You can define legal entities using Legal Entity Configurator or Accounting Setup Manager in General Ledger.

Operating Unit

An organization that uses Oracle sub ledgers, such as Oracle Cash Management, Order Management and Shipping Execution, Oracle Payables, Oracle Purchasing, Oracle Receivables, and related products. It may be a sales office, a division, or a department.

• •

In R 12 Operating units are not associated with legal entities. Operating units are assigned to ledgers and a default legal context. Information is secured by operating unit for these applications using responsibilities. Each user can access, process, and report on data only for the operating units assigned to the MO: Operating Unit or MO: Security Profile profile option. The MO: Operating Unit profile option only provides access to one operating unit. The MO: Security Profile provides access to multiple operating units from a single responsibility

You can define operating units from the Define Organization window in Oracle HRMS or from Accounting Setup Manager in General Ledger.

Inventory Organization

An organization for which you track inventory transactions and balances, and/or an organization that manufactures or distributes products. Examples include (but are not limited to) manufacturing plants, warehouses, distribution centers, and sales offices.

The following applications secure information by inventory organization: Oracle Inventory, Bills of Material, Engineering, Work in Process, Master Scheduling/MRP, Capacity, and Purchasing receiving functions. To run any of these applications, you must choose an organization that has been classified as an inventory organization.

You can create ledgers using the Accounting Setup Manager in Oracle General Ledger and define organizations using the Define Organization window.

HR Organization HR organizations represent the basic work structure of any enterprise. They usually represent the functional management, or reporting groups that exist within a business group. In addition to these internal organizations, you can define other organizations for tax and government reporting purposes, or for third party payments. Information Shared Across Organizations The following information is global. It must be set up once for the enterprise: • Flexfield definitions • Customer Header (customer site is at the operating unit level) • Supplier Header (supplier site is at the operating unit 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.

In oracle applications, all intercompany entries are automatically created within the SOB to ensure that companies are never out of balance. A legal entity can have one or more than one balancing segments. For example, you may have multiple companies defined in your COA reporting to a single legal entity. How to decide Legal Entities and OUs There two things one should consider while creating legal entities 1. The number of fiscal and tax report the organization has to produces - for each distinct values we should create one legal entity. 2. The number of entities for which the company produce balance sheet - for each distinct values we should create one legal entity. An operating unit a is a fincial entity in a business group that engages in transactions with outsiders and for which you want to track the finalcial transactions. OU deals with 5 subledgers - OM, AR, PO, AP and GL Security and Subledgers decides how many operating units one should create in a business group.

Each company defined in your COA may have multiple divisions which you product balance sheets. In that case, it is likely that each company in the COA is setup as a legal entity and each division is setup as an OU.

Securing values Oracle Applications does not automatically secure balancing segment values within your COA with specific legal entities or OU. You can create security rules to ensure this security requirement. For example, you can ensure that the payables team may access invoices of a specific division. If security rules are not defiend, access to all divisions will be available.

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.

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.

When you use GL, you need to choose a responsibility that specifies a particular SOB(with the profile - GL SET OF BOOKS NAME). This allows you to get information fo that SOB only. In Oracle applications, you can create an SOB using the set of books window in GL. In the set of books window, you can define all other types of organization using the organization window.

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.

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)

Multi-org Security model
Posted Wed, 04/01/2009 - 17:33 by Anonymous

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.

In the multi-org security model, each user within the organization is assigned responsibilities. These responsibilities are in turn attached to operating units (OUs) or inventory organizations. In this security model, the responsibility is the key because different responsibilities have distinct ways of securing the data contained in them.

For example, within general ledger (GL), data security is provided by the GL set of books (SOB). Additionally, each asset can be secured by setting up a hierarchy of asset books within an asset. Similarly, within manufacturing applications and INV, security is provided by inventory organizations (IOs) and for Fixed Assets (FA), security is provided by Corp Book. The security for data Human Resource (HR) is implemented by the Business Group (BG). Similarly, data security for order management (OM), Accounts Receivable (AR), Account Payable (AP), Purchase Order (PO), Cash Management (CE), Project Accounting (PA), and Sales Compensation (SC) is provided by OU.

Oracle APIs and Open Interfaces
Posted Wed, 05/20/2009 - 02:22 by Anonymous

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. 2. 3. Order Import Process Order API 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 stocktake 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

Oracle Financials
Posted Thu, 05/14/2009 - 00:50 by Anonymous

The Oracle E-Business Suite is a complete set of business applications that enables corporations to efficiently track detailed business transaction data and turn it into decision making information using a system built on a unified information architecture. Oracle Financials applications are a subset of this suite and are a family of products designed to capture and analyze your financial data on a worldwide basis. Use Oracle Financials applications to better manage business to the targets that are announced to investors. Management can better report to investors and colleagues. Oracle Financials applications also help you to meet your obligations in key areas surrounding the numbers, such as:

• • • • •

Compliance Financial Control Regulatory Reporting Cost Containment Risk Management

Organizational Models in Oracle Financials 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.

The Legal Organization 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. In the real world, legal entities have the right to own property, the right to trade, and the responsibility to comply with appropriate laws. They also often have the responsibility to account for themselves (balance sheet, income statement, specified reports) to company regulators, taxation authorities, and owners according to rules specified in the relevant legislation.

The Oracle E-Business Suite reflects the real world for legal entities. 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.

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.

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). Compliance and Disclosure Requirements Legal entities are formally the entities that actually enter into transactions. 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. 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. Many company statutes require that legal entities created in compliance with them publish specific and periodic disclosures. Annual or more frequent accounting reports, often referred to as "statutory accounts" and "external reporting," are required. These must be reported to specified national and regulatory authorities, for example the Securities and Exchange Commission (SEC) in the United States. Disclosure requirements are diverse. Local entities file

locally using local regulations and currency, and through their holding company using parent Generally Accepted Accounting Principles (GAAP) and currency. 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 Flexfield
Posted Mon, 01/05/2009 - 16:25 by Anonymous

A flexfield is a field made up of sub–fields, or segments. There are two types of flexfields: key flexfields and descriptive flexfield. A key flexfield appears on your form as a normal text field with an appropriate prompt. A descriptive flexfield appears on your form as a two–character– wide text field with square brackets [ ] as its prompt. When opened, both types of flexfield appear as a pop–up window that contains a separate field and prompt for each segment. Each segment has a name and a set of valid values. The values may also have value descriptions. KFF, DFF, Structure, Segemnt, Value, Value Set, Value Description, Aliases, Rules, Groups, Security.

Key Flexfields
Most organizations use ”codes” made up of meaningful segments (intelligent keys) to identify general ledger accounts, part numbers, and other business entities. Each segment of the code can represent a characteristic of the entity. For example, your organization might use the part number PAD–NR–YEL–8 1/2x14” to represent a notepad that is narrow–ruled, yellow, and 8 1/2” by 14”. Another organization may identify the same notepad with the part number ”PD–8x14– Y–NR”. Both of these part numbers are codes whose segments describe a characteristic of the part. Although these codes represent the same part, they each have a different segment structure that is meaningful only to the organization using those codes. The Oracle Applications store these ”codes” in key flexfields. Key flexfields are flexible enough to let any organization use the code scheme they want, without programming. When your organization initially installs Oracle Applications, you and

your organization’s implementation team customize the key flexfields to incorporate code segments that are meaningful to your business. You decide what each segment means, what values each segment can have, and what the segment values mean. Your organization can define rules to specify which segment values can be combined to make a valid complete code (also called a combination). You can also define relationships among the segments. The result is that you and your organization can use the codes you want rather than changing your codes to meet Oracle Applications’ requirements. For example, consider the codes your organization uses to identify general ledger accounts. Oracle Applications represent these codes using a particular key flexfield called the Accounting Flexfield. One organization might choose to customize the Accounting Flexfield to include five segments: company, division, department, account, and project. Another organization, however, might structure their general ledger account segments differently, perhaps using twelve segments instead of five. The Accounting Flexfield lets your Oracle General Ledger application accommodate the needs of different organizations by allowing them to customize that key flexfield to their particular business usage.

Descriptive Flexfields
Descriptive flexfields provide customizable ”expansion space” on your forms. You can use descriptive flexfields to track additional information, important and unique to your business, that would not otherwise be captured by the form. Descriptive flexfields can be context sensitive, where the information your application stores depends on other values your users enter in other parts of the form. A descriptive flexfield appears on a form as a single–character, unnamed field enclosed in brackets. Just like in a key flexfield, a pop–up window appears when you move your cursor into a customized descriptive flexfield. And like a key flexfield, the pop–up window has as many fields as your organization needs. Each field or segment in a descriptive flexfield has a prompt, just like ordinary fields, and can have a set of valid values. Your organization can define dependencies among the segments or customize a descriptive flexfield to display context–sensitive segments, so that different segments or additional pop–up windows appear depending on the values you enter in other fields or segments.

Basic Flexfields Concepts
Posted Mon, 01/05/2009 - 17:31 by oracleug

We use the following terms for both key and descriptive flexfields: • Structure • Segment

• Value, Value Set, Value Description, Validation (Validate)

Structure
A flexfield structure is a specific configuration of segments. If you add or remove segments, or rearrange the order of segments in a flexfield, you get a different structure. You can define multiple segment structures for the same flexfield (if that flexfield has been built to support more than one structure). Your flexfield can display different prompts and fields for different end users based on a data condition in your form or application data. Both key and descriptive flexfields may allow more than one structure. In some applications, different users may need a different arrangement of the segments in a flexfield (key or descriptive). Or, you might want different segments in a flexfield depending on, for example, the value of another form or database field. Your Oracle General Ledger application, for example, provides different Accounting Flexfield (Chart of Accounts) structures for users of different sets of books. The Oracle General Ledger application determines which flexfield structure to use based on the value of the GL Set of Books Name user profile option.

Segment
A segment is a single sub–field within a flexfield. You define the appearance and meaning of individual segments when customizing a flexfield. A segment is represented in your database as a single table column. You must choose two lengths for each segment, the displayed length and the maximum length. The maximum length is the length of the longest value a user can enter into a segment. The largest maximum length you can choose must be less than or equal to the length of the underlying column that corresponds to the segment. Because these column sizes vary among flexfields, you need to know what column lengths are available for your flexfield. The displayed length is the segment length a user sees in the pop–up window. If the displayed length is less than the maximum length, the user must scroll through the segment to see its entire contents. For a key flexfield, a segment usually describes a particular characteristic of the entity identified by the flexfield. For example, you can have a key flexfield that stores part numbers. The key flexfield can contain the part number PAD–YEL–NR–8 1/2x14, which represents a yellow, narrow ruled, 8 1/2” x 14” note pad. Each section in the part number, separated by a hyphen, describes a characteristic of the part. The first segment describes the object, a note pad, the second segment describes the color of

the object, yellow, and so on. Note that we also refer to the fields in a descriptive flexfield pop– up window as segments even though they do not necessarily make up meaningful codes like the segments in key flexfields. However, they do often describe a particular characteristic of the entity identified elsewhere on the form you are using.

Values, Validation and Value Sets
Your end user enters a segment value into a segment while using an application. Generally, the flexfield validates each segment against a set of valid values (a ”value set”) that are usually predefined. To ”validate a segment” means that the flexfield compares the value a user enters in the segment against the values in the value set for that segment. You can set up your flexfield so that it automatically validates segment values your end user enters against a table of valid values (which may also have value descriptions). If your end user enters an invalid segment value, a list of valid values appears automatically so that the user can choose a valid value. You can think of a value set as a ”container” for your values. You choose what types of values can fit into your value set: their length, format, and so on. A segment is usually validated, and usually each segment in a given flexfield uses a different value set. You can assign a single value set to more than one segment, and you can even share value sets among different flexfields. For most value sets, when you enter values into a flexfield segment, you can enter only values that already exist in the value set assigned to the segment.

Accounting Flexfield : The code you use to identify a general ledger (GL) account in Oracle. Flexfield Qualifiers : Balancing segment, cost center segment, natural account, intercompany segment.

Balancing Segment - Balancing segment is the level for balancing the accounting entries. A balancing entity is one for which you prepare a balance sheets 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. If you define the balancing segment as company, then both debit and credit should be balanced at the company level when the transactions are posted to GL. A Legal entity may consist of one or more balancing segments. If you define multiple divisions of a company in your chart of accounts for which you produce a balance sheet then each compnay is setup as a legal entity and each division as an OU. (Notes: There is no hard and fast rule what should be the values of your balancing segment. While doing the implementation the client should specify at what level they want to see the net balance, profit/loss etc. The values can be some customers for which they want to track the profit-loss, some joint venters..etc. It should aslo contain one value for the whole business for which you want to track the net retained earnings) Cost Center Segment - This attribute is used to identify the cost center segment. Cost centres are divisions that add to the cost of the organization, but only indirectly add to the profit of the company. Typical examples include Research and Development, Marketing and Customer service. Companies may choose to classify business units as cost centres, profit centres, or investment centres. (Examples: Corporate transaction, Engineering Dept,Material Dept, XYZ Exepense, Sales, Discount, ABC A/P ) Natural Account Segment - The natural account number is that portion of the account number that identifies what the financial activity is in pure accounting terms. Some people

(and some general ledger systems) confuse this definition by referring to the natural account number as the account number, implying that it is the entire basis for the chart of accounts. Natural segment is nothing but the account heads type. In other words, natural segment determines the account type. There are five types of account types assets, liabilities, expenses, revenue and owner's equity. Typically ACCOUNT segment would be your natural segment. ex: Current Assets, Fixed Assets, Other Assets, Current liabilities Code Combination : One full accounting flexfield with all segment values. Dynamic Insertion / Cross-Validation : Automatic creation of account code combination based on rules defined with code combinations.

Accounting Flexfield (Chart of Account)
Posted Thu, 01/15/2009 - 00:23 by Anonymous

The code you use to identify a general ledger (GL) account in Oracle. * Accounting (Key) Flexfield segment one of up to 30 different sections of the accounting flexfield, which together make up a GL account code. * Accounting Flexfield structure - the combination of key flexfield segments defined to make up the account code combinations. If a segment(s) is added or removed or re-arranged, the result is a different structure. The basic steps in defining a key Flexfields are as given below. You may or may not use all the steps. The detailed explanation is being followed after the steps. 1. Define & fix the structure of your COA/AFF or any other flex field. we 'll design a flex field of the form .new_COA_seg2.new_COA_seg3 2. Define the value sets for all the three segments Navigation : GL > Set up > Financials > Flex field > Validation > Sets

Similarly definie value set for other two segments 3. Define the flex field Navigation : GL > Set up > Financials > Flex field > key > Segment

Select the application as GL and title as account flexifield. click on OK

Enter the name of new flex field and save it. Click on segments to enter the segments of the FF

Enter the name of the new three segments with the coumn name segmen1, 2 & 3. Assign the corresponding value set. Save it and click on Open to open one segment.

Verify the segment1 contents and modify if necessary. Click on qualifiers

Enter the qualifier as Cost center, Natural account or as required. Repeat this step for all the segments and close the key flexfield segment window.

enable the fields allow dynamic inserts & cross-validate segments. Also enable the freeze flexfield definition and click on complie.

4. Filling value sets Navigation : GL > Set up > Financials > Flex field > key > Values

Cross-Validation Rules
Posted Thu, 07/16/2009 - 09:42 by Anonymous

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

As another example, if you use the Accounting Flexfield, you may decide that all revenue accounts must have a department. Therefore, all your "revenue" account values (such as all values between 4000 and 5999) must have a corresponding department value other than 000 (which means "non-specific"). For example, suppose you have an Accounting Flexfield where you have a Company or Organization segment with two possible values, 01 and 02. You also have a Natural Account segment, with many possible values, but your company policy requires that Company or Organization 01 uses the natural account values 001 to 499 and Company or Organization 02 uses the natural account values 500 to 999. You can create cross-validation rules to ensure that users cannot create a GL account with combinations of values such as 02-342 or 01-750, for example.

Defining Cross-validation Rules

Posted Thu, 07/16/2009 - 11:11 by Anonymous

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 crossvalidation 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-validationrule. 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 Crossvalidation Rule Elements. 7. Save your changes.

Defining Cross-validation Rule Elements Use this block to define the cross-validation rule elements that make up your cross-validation rule. You define a cross-validation rule element by specifying a value range that includes both a low and high value for each key segment. A cross-validation rule element applies to all segment values included in the value ranges you specify. You identify each cross-validation rule element as either Include or Exclude, where Include includes all values in the specified ranges, and Exclude excludes all values in the specified ranges. Every rule must have at least one Include rule element, since a rule automatically excludes all values unless you specifically include them. Exclude rule elements override Include rule elements. Suggestion: We recommend that you define one all-encompassing Include rule element and several restricting Exclude rule elements. Select the type of cross-validation rule element. Valid types are: Include range. Exclude range. When you enter the From (low) field, this window automatically displays a window that Your user cannot enter any segment value combinations that fall in the following Your user can enter any segment value combinations that fall in the following

contains a prompt for each segment in your flexfield structure. You enter both the low and high ends of your value range in this window. After you finish entering your ranges, this zone displays your low segment values in concatenated window in the Low field and displays your high segment values similarly in the High field. Enter the low end and the high end of your segment combination range. Neither the low nor the high combination has to be a valid key flexfield combination, nor do they need to be made up of valid segment values. Note that a blank segment value (null value) is considered to fall within a range that has one or both ends specified as a blank. However, if all of your segments require a value, you would not be able to create a combination with a blank segment anyhow. You may use blank minimum or maximum segment values to create cross-validation rules that can test for blank segments (that are not already required to have a value). For example, if you allow a null value for your last optional segment but not the second-to-last optional segment, you would use a blank minimum or maximum value for the last segment but fill in a value (such as 000 or 999) for both the minimum and maximums for the second-to-last optional segment. If you want to specify a single combination to include or exclude, enter the same combination in both the Low and High fields. Disabled rules are ignored when your key flexfield validates a combination of segment values. Deleting the rule has the same effect, but you can re-enable a disabled rule.

How Cross-Validation Works
Posted Thu, 07/16/2009 - 10:00 by Anonymous

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

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. These settings apply to all users of any responsibility associated with the

Application level application. Responsibility level responsibility. User level username. Important Profiles

These settings apply to all users currently signed on under the

These settings apply to an individual user, identified by their application

1.1. HR:Business Group 1.2 HR: Security Option 1.3: HR: User Type (FOR accessing HRMS functions) 2.1. GL: Set of Books(11i) 2.1 GL:%Ledger% (R12) 3.1. MO: Operating Unit 3.2. MO: Security Profile (R12) 3.3. MO: Default Operating Unit 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.

2. OE: Set of Books and GL: Set of Books Each Responsibility is identified with a set of books using the profile option GL : Set of Books Name, a responsibility can only see the accounting information for that set of books in orcale GL.

3. HR: Business Group Business Group that is linked to the security profile for a responsibility. This option is used online to control access to records that are not related to organization, position, or payroll. This option is seeded at Site level with the start-up Business Group. It is view only. Values are derived from the HR:Security Profile user profile option. HR:Security Profile Restricts access to the organizations, positions, and payrolls defined in

the security profile. This option is seeded at Site level with the view-all security profile created for the Startup Business Group. ‹ Descriptive Flex field up

Add new comment

COMMENTS
Q. What are the main profile
by Anonymous - 02/06/2009 - 18:04

Q. What are the main profile options relating to Organization setup and what are they used for? A. · HR:User Type = HR User This is necessary to allow the Inventory esponsibility to complete the organization setup. Setting the profile to a value of 'User' as opposed to 'Payroll & User' will restrict the Inventory user from accessing any Payroll information if Oracle Payroll is installed. · HR: Business Group = {the users Business Group name} This points the responsibility to the appropriate Business Group. when multiple Business Groups are defined, you must associate each responsibility with one and only one Business Group. A responsibility can not see organization data from more than one Business Group. · MO: Operating Unit = {the users Operating Unit name} Used primarily in a multiorg environment. This points the responsibility to the appropriate Operating Unit. 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.

reply

Q. What are the main profile
by Anonymous - 02/06/2009 - 18:05

Sign up to vote on this title
UsefulNot useful