Reasons for a Sales Order to get Backordered

A Sales Order can get into backorder state after performing Pick Release on a Sales Order but there are many reasons for a Sales Order to get backorder.

1.         Order on Hold

2.         Inventory Period NOT open

3.         No enough on-hand quantity

4.         No enough quantity to reserve/transact

5.         No on-hand quantity in required sub-inventory

6.         The Lot from which items are selected is inactive/expired

7.         Lot control Item Lot Divisible Option not enabled

8.         Specified Lot is Disallowed Transaction (Applied on Material Status)

9.         Item On-Hand to Disallowed Transaction (Applied on Material Status)

10.      Wrong Item reservation (even inventory have enough quantity)

11.      Inventory reserved for other sales orders

12.      Inventory picked-up by other sales orders

13.      Previously done return to stock not properly performed

14.      Cycle Count Adjustments

15.      Serial Control Item Serial number not allocated or not assigned 

16.      Manually Backordered 

17.      Move order is in pending state 

NOTE: There will be many reasons for a sales order to get backorder as of now found these many reasons.

Please provide your valuable feedback ............

Script for finding oracle Forms and Self-Service page file versions

Finding file version from Oracle Forms and Self-Service page

select distinct app_short_name

,b.bug_number

,version,f.filename 

,to_char(prb.creation_date

,'dd-mon-yyyy

,hh24:mi:ss') Patch_date

from

apps.ad_file_versions v

,apps.ad_files f

,apps.ad_patch_run_bug_actions prba

,apps.ad_patch_run_bugs prb

,apps.ad_bugs b

where v.file_id=f.file_id

and f.file_id=prba.file_id

and prba.patch_run_bug_id = prb.patch_run_bug_id

and prb.bug_id=b.bug_id

and prba.patch_file_version_id=v.file_version_id

and lower(f.filename) like lower('<file name>')

order by filename;

Please provide your valuable feedback ............

Oracle Fusion Roles Concepts in Fusion Applications

Introduction to Fusion Applications Roles Concepts

Fusion Applications Security is designed based on Role-Based Access Control (RBAC). It is an approach to restricting access to authorized users. In general, RBAC is defined based on the primary rules as per this wiki page.

RBAC normalizes access to functions and data through user roles rather than only users. User access is based on the definition of the roles provisioned to the user. RBAC secures access in a “Who can do what on which functions or sets of data under what conditions” approach. The “who” is the user.

The roles are defined at functional and technical levels. The functional level is the business definition that is used by business users and the technical level is the implementation of roles using Oracle Technology. This post will quickly review the definition of “Functional Roles” and provide introductory internals on the technical implementation of these “Roles” within Fusion Applications.

Architecture of Functional Roles

At a high level, RBAC is based on the following concepts:

·         Role assignment: A subject can exercise permission only if the subject has selected or been assigned a role.

·         Role authorization: A subject’s active role must be authorized for the subject. With rule 1 above, this rule ensures that users can take on only roles for which they are authorized.

·         Permission authorization: A subject can exercise a permission only if the permission is authorized for the subject’s active role. With rules 1 and 2, this rule ensures that users can exercise only permissions for which they are authorized.

In Fusion Applications, the RBAC implementation is based on abstract, job, duty, and data roles that work together to control access to functions and data. The definitions of these functional roles are as follows:

Abstract Role:

This role categorizes the roles for reference implementation. It inherits duty role but does not contain security policies. For example: Employee, Manager, etc.

Job Role:

This role defines a specific job an employee is responsible for. An employee may have many job roles. It may require the data role to control the actions of the respective objects. For example: Benefits Manager, Accounts Receivable Specialist, etc.

Data Role:

This role defines access to the data within a specific duty. Who can do what on which set of data? The possible actions are read, update, delete, and manage. Only duty roles hold explicit entitlement to the data. These entitlements control the privileges such as in a user interface that can see specific screens, buttons, data columns, and other artifacts.

Duty Role:

This role defines a set of tasks. It is the most granular form of a role. The job and abstract roles inherit duty roles. The data security policies are specified to duty roles to control actions on all respective objects.

This is a diagram from the “Oracle Fusion Applications Security Guide” that shows the relationships between these roles:

Note: The duty role in above diagram is the granular form of a role where security policies are attached. They are implemented as application roles in APM and scoped to individual Oracle Fusion Applications.

Please provide your valuable feedback ............