Oracle Functional Basics

A. Roles, Responsibilities, Menus

Role
Role is a set or group of privileges that can be granted to users. A way for database
administrators to save time and effort.

Role Based Access Control (RBAC)

Role Based Access Control Layer

It can be said that a role is "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 policies that users require to perform a specific function. This is
accomplished with a one-time setup, in which permissions, responsibilities and etc. 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.
Organizations can define roles that closely mirror their business situation. For example, an
organization can create an "Employee" role and then assign that role to all of its employees. It
can also create an "External" role and assign that role to customers and suppliers. Further
examples may include specific roles such as "Support Agent", "Sales Rep", "Sales Managers". In
these examples, each role contains a specific level of access privileges that restricts its assignees
to the scope of their job functions. Some members of the organization will probably be
assigned more than one role. A sales representative would be assigned the Employee and Sales
Representative roles, and a Sales Manager would be assigned the Employee, Sales
Representative, and Sales Manager roles. Roles and role assignments are stored in the
workflow directory, which is interpreted by the security system at runtime.
Role Categories

As part of the Oracle E-Business Suite RBAC model, Oracle User Management introduces Role
Categories. Administrators can create role categories to bundle roles and responsibilities to
make the process of searching for roles and responsibilities easier. For example, all sales and
marketing related roles could be included in the Sales & Marketing category.
Responsibilities
Responsibility is a level of authority that lets users access only those applications functions and
data appropriate to their roles in an organization. A responsibility determines if the user
accesses Oracle Applications or Oracle Self-Service Web Applications, which applications
functions a user can use, which reports and concurrent programs the user can run, and which
data those reports and concurrent programs can access.
How to define a responsibility in Oracle Apps R12
A responsibility is an important configuration which allows the user to navigate to the various
menus and form functions within that responsibility. For example, to create  a new journal, the
user should be provided access to the responsibility titled ‘GL User’ or ‘GL Super User’.
To define a new responsibility, launch the form by navigating as follows:
System Administrator >> Security >> Responsibility >> Define

Menus

A menu is a hierarchical arrangement of functions and menus of functions. Each responsibility

has a menu assigned to it.

A "full access" responsibility with a menu that includes all the functions in an application is
predefined for each Oracle Applications product. As a System Administrator, you can restrict
the functionality a responsibility provides by defining rules to exclude specific functions or
menus of functions. In fact, we recommend that you use exclusion rules to customize a
responsibility in preference to constructing a new menu hierarchy for that responsibility.

B. Multiple Organization Access Control (MOAC)

Multi-Org Access Control (MOAC) enables companies that have implemented a Shared
Services operating model to efficiently process business transactions by allowing them to
access, process and report on data for an unlimited number of operating units within a single
applications responsibility. It allows multiple organizations to be defined in a single instance
and allows users to transact across multiple operating units without changing
responsibilities.
Features of MOAC Access multiple operating units within a single application responsibility
Perform tasks for and across multiple operating units:
1. Set-up controls, Negotiate sales agreements
2. Enter quotes, orders and returns
3. Schedule orders, Apply and Release holds
4. Run reports and concurrent programs
5. Setup Transaction Type, apply and release holds

This increases the productivity of Shared Service Centers as users no longer have to switch
application responsibilities when processing transactions for multiple operating units at a time.
C 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.
We have two types of Profile options – System and Personal profile options depending on to

whom they are visible and who can update their values.

System Profile options are visible and can be updated only in System Administrator

responsibility. In short they will be maintained by a System Administrator only.

User Profile Options are visible and can be updated by any end user of Oracle Apps.

Profile Options can be set at different levels. Site level being the highest and User being the

lowest in the heirarchy. If a profile option is assigned at two levels, then value assigned at

lowest level takes the precedence.

 Site (restricted to the whole of Apps)

 Application ( restricted only to a particular application like Payables, Receivables)

 Responsibility (restricted only to a particular responsibility)

 Organization (restricted to a particular organization)

 User (restricted to a user)

Profile options more: http://www.oracleerpappsguide.com/2011/03/what-is-profile-

options.html
Profile options more: http://www.erpschools.com/articles/profile-option-in-oracle-apps
D Flexfields, Segments, Value Sets, Security Rules, Cross-Validation Rules
A flexfield is a field made up of sub–fields, or segments. A flexible data field that an organization
can customize to business needs without programming. 2 Types of flexfields:
1. Key Flexfield
2. 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 it’s 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.

For more refer to: http://www.oracleerpappsguide.com/2011/02/what-is-oracle-flexfield.html,

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.  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.
For more visit: http://www.oracleerpappsguide.com/2012/01/key-flexfields-in-oracle-e-
business.html
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.
For more visit: http://www.oracleerpappsguide.com/2011/02/descriptive-flex-field.html
We use the following terms for both key and descriptive flexfield

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

Value Set,
Value Set is a container of different values attached to flexfield segments to ensure that only
valid values are entered in the segments.
Y our 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 i.e. 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.
Security Rules allow restricting user access to various key flexfield segment list of values
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.
Cross Validation Rules
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.
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.
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".
For more read: http://www.oracleerpappsguide.com/2011/02/basic-flexfields-concepts-
structure.html#at_pco=smlre-1.0&at_si=56a5f9980bedb108&at_ab=per-
12&at_pos=3&at_tot=4

Lookup(s)
Lookups in Oracle are a collection of values. Lookups are a static collection of codes which are
used by oracle for working.

For Example in a form/table if there is a field for Gender rather than storing the values,
Male/Female/Unknown the system may prefer to store codes M/F/U . Thus when storing the
values rather than storing the description oracle will store the codes M/F/U and display the
complete menaning to the user.

Each lookup when defined will have a lookup code and a corresponding meaning for that code.
Oracle will internally use codes for working and use meaning when communicating to the user.

Lookup codes are mainly used when working with forms and handling data in the tables.

When ever a lookup is created and entry will be created in the table FND_LOOKUP_TYPES ,

For each lookup type when the value is entered for the lookup entries will be created in the
table FND_LOOKUP_VALUES

For the lookups already defined in Oracle each is associated with an application , thus when
searching for application specific lookups user should search with the specific application.

Lookups in Oracle are of 3 types:

1. System: These are lookups which are used internally by the system. Users can see and
use the lookup but they cannot disable the existing values or add new values.
2. Extensible : These are system provided lookups. Users can add their values if they want ,
but Seeded values by Oracle cannot be changed. 
3. User Defined : User Defined lookups are client specific which are created to meet the
business specific customization's. These are created by the users and the users can add new
values and disable the older ones.
More can be understood about lookups by understanding the following Q&A:
An article on Lookups, for beginners that follow http://getappstraining.blogspot.com 
Question : What is a lookup in Oracle Apps
Answer: It is a set of codes and their meanings.

Question: Any examples?
Answer: The simplest example is say a lookup type of Gender.
This will have definitions as below
Code    Meaning
------        -------------
M            Male
F             Female
U            Unknown

Question: But where is it used, any examples of its usages?

Answer: Let us say that there is a table for employees, and this table named PER_PEOPLE_F &
has following columns
----
FIRST_NAME
LAST_NAME
DATE_OF_BIRTH
GENDER

Question: Will the gender column in above table hold the value of M or F or U?
Answer: Correct, and the screen that displays people details will in reality display the meaning
of those respective codes (i.e. Male, Female, Unknown etc) instead of displaying the code of M
or F or U

Question: hmmm...so are lookups used to save the bytes space on database machine?
Answer: Noooo. Imagine a situation as below
a. There are 30,000 records in people table of which 2000 records have gender value = U. In the
screen, their Gender is being displayed as "Unknown". Now let’s say you want this to be
changed to "Undisclosed". To implement this change, all you have to do is to change the
meaning of the lookup codes for lookup type GENDER. Hence it will look like
Code    Meaning
------    -------------
M         Male
F          Female
U         Undisclosed 

Here lies the beauty of lookups, you do not need to modify 2000 odd records in this case.
Question : Any other usage of lookups?
Answer : Sure, lets take another example. In HRMS, there is a field named Ethnicity. By default
Oracle ERO delivers the below values

Lookup code        lookup meaning

----------------        ---------------------
AS            Asian
EU            European

Now, if your client wants to track Ethnicity at a granular level, they can amend the Oracle
delivered lookup definition as below

Lookup code        lookup meaning

----------------        ---------------------
ASI            Asian-Indian
ASP            Asian-Pakistani
EU            European

Hence these values will then be available in the list of values for Ethnicity field.

Question: Are we saying that all the lookups delivered by oracle can be modified?
Answer: Depends. If oracle has a lookup called termination status, and if based on the
termination status code Oracle has some rules defined within Payroll Engine....!! Surely Oracle 
Payroll Engine will not like it if you end date an existing status code or add a new status code to
termination. For this very reason, Oracle flags some lookups as System lookups, and the lookup
entry screen will not let you modify those lookup codes.

Question: OK, what if I do not wish to modify existing Lookup codes, but only wish to add new
Lookup codes to an existing Oracle delivered Lookup Type?
Answer: You can do so, provided the Oracle delivered Lookup Type is flagged as Extensible.
Please see the screenshot

Question: Can we add our own new lookup types?

Answer: Yes you can, for this you will first define a lookup type and will then define a set of
lookup codes against the Lookup Type. In our example above, GENDER is the LOOKUP_TYPE

Question: Does a LOOKUP_TYPE get attached to a Descriptive Flexfield…just like Value Sets?
Answer: Not really. There is no direct relation between lookup and Descriptive Flexfield. 

For more refer to: http://oracle.anilpassi.com/lookup-types-and-lookup-codes-in-oracle-

apps.html