Item Unassignment and Delete Items

There can be scenarios where an Item is mistakenly assigned to a warehouse but we need to un-assign the item from the warehouse , We have 2 options available for this operation depending on the number of items and the number of warehouses from when there items have to be unassigned.


However note that item un-assignment can only be performed provided no material transactions have been booked for the item.


If the data volume is less users can query the items from Item master and uncheck the check boxes of item assignment to the specific warehouses and then save the changes.


For large data volumes we can have follow the step by step approach as below :

1. Delete Item Costs --> Any cost for the item needs to be deleted. This can be achieved by running DELETE scripts on the tables :
1. cst_item_costs
2. cst_item_cost_details
3. CST_COST_UPDATES
4. CST_STANDARD_COSTS

Once the item costs have been cleared we need to group the items into Deletion Groups.
For this an entry needs to be made in the Table :

1. BOM_DELETE_GROUPS --> 1 Entry is made for each Organization (warehouse) from which the item has to be un-assigned
2. BOM_DELETE_ENTITIES --> Entry for individual item is made

Once the data insert is complete the user needs to navigate the screen for Delete Items , Search the BOM Deletion group , review and delete it to complete item un-assignment

Purchase Order (PO) approval Hierarchy

PO Approval in Oracle is based on the Approval hierarchy setup for this process. The basic setup can be explained via a flow diagram as below

The basic setups need for the setup are:

1. Postion creation and assignment to a Position Hierarchy
2. PO approval Group Creation and Assignment
3. User Creation , Assigning it to an employee and setting it up as a buyer

The approval workflow consists of the disparate setups which are interlinked together to complete the PO Approval workflow in Oracle

1. Postion creation and assignment to a Position Hierarchy

First Step in setting up the Approval hierarchy to Define a position which basically signifies the position of the employee in the organization. This position will be assigned in a position hierarchy to identify the level of this approval / the complete hierarchy of the employee . This will determine that if an employee submits a PO for approval if it will directly approved or if it will be passed on to someone else for review and approval . The position hierarchy will be assigned to the PO document type which will be mapped to the PO workflow

2. PO approval Group Creation and Assignment :

The first step is PO Approval Group creation ,  we need to create an approval group which has information of the amount of PO that can be approvaed and also the list/range of distribution accounts that can be approved . Once the Approval Group has been created , it needs to be assigned to a position

3. User Creation , Assigning it to an employee and setting it up as a buyer

The PO’s will in the end be created and approved by business users. This will need creation of employees in the system these employees need to be assigned one of the positions created above. This will determine where the employee lies in the hierarchy and if their PO will be directly approved or passed to someone else for approval. The Employee has to be setup as a buyer and needs to be mapped to an end user in Oracle .

Run the Standard Program : Fill Employee hierarchy details to make these changes come into effect

Once this is done create a PO and try for approval. Based on the position hierarchy setup either the PO will be directly approved or passed on to the superior

Sales Order --> Rules --> Processing Constraints

Depending on the business requirements we can be required to check for some conditions and based on their applicability restrict some operations to be performed on the Sales Order.
These restrictions can be applied via the Processing Constraints. There are number of Seeded Oracle Constraints which prevent certain operations in orders to maintain Data Integrity .
E.g. We cannot split an Order line After it is shipped , thus Seeded Oracle Processing Constraint will ensure that this action cannot be performed by the user.


Apart from these we can have custom constraints defined too. Once the constraints have been defined we need to apply it i.e. map it to the responsibilities to specify which responsibilities will be bound by the constraint or can override the constraint.


This can be done by the Applicable to Option :


Oracle provides 3 options which work as below :


All Responsibilities : This means this constraint will be applicable to all responsibilities.
Authorized Responsibility : When any responsibility is mentioned here, then the processing constraint will NOT BE applicable to that responsibility
Constrained Responsibility : When any responsibility is mentioned here, then the processing constraint will BE applicable ONLY to that responsibility


For Seeded constraints the Applicability is All Responsibilities and cannot be updated