Thursday, 7 April 2011

MOAC in R12


MOAC in R12 ....R12 Upgrade Series Part -2


This Post is my continuation of my Posts on R12 Upgrades.Today is Sort post about MOAC Multi-Org-Access Feature





Below are high level details of MOAC feature and it's impact on various Modules.

Accounting Setup Manager
Define and manage your Operating Units and their relationships to Legal Entities and Ledgers in a central location

Collections
View and manage customers across Operating Units and within the context of a global collections currency. Apart from that collections tasks can be done across Operating Units

Global Purchase Agreements
Negotiate with your suppliers for your enterprise, not just particular Operating Units.

Payables
Enter and pay invoices across Operating Units

Customer Data Management
View customer accounts, merge and import data for multiple Operating Units.

Supply Chain
Receiving transactions across any OU (Project, PO, Requisition and Above all user can select an inventory item from any Operating Units.


Changes in OE_ORDER_PUB in R12i

From OM Prospect
OE_ORDER_PUB API has been modified to include the parameters
1. p_org_id - p_org_id is operating_unit_id
2. p_operating_unit - p_operating_unit is Operating Unit Name

User can enter any of these values. Please note that when user pass any of these values system will check if the responsibility from where user are executing these APIs has access Operating Unit or not, if not then API will return Error.
If User don’t pass this values then system will try to derive the values from the Default Operating Unit (Profile option) and if that too not specified then API will return Error.



How to Set MOAC Context in R12i (MOAC - Enabled)


In this post I will explain how to set the context to use secured synonym in oracle R12i. Please make a note that in R12i Oracle has removed all the context-based views with Secured Synonym.
All the context-based views like
1. OE_ORDER_HEAREDS
2. OE_ORDER_LINES
3. PO_HEADERS
4. PO_LINES etc has been replaced with Synonym.
Now on if user want to set the context to get the data for particular operating unit they need to use the new apis to set the context
The new API to set the context in R12 is
MO_GLOBAL.Set_Policy_Context.


This API has 2 parameters
1. Operating unit
2. Context
Context has 2 values
1. M
2. S
When policy context is set to ‘M’, data from all accessible Operating Units will be returned.
When policy context is set to ‘S’, then only data from the specified Org_Id will be returned.
Example for R12 –

· Try to run
select * from oe_order_headers

· Set the Context
begin
MO_GLOBAL.Set_Policy_Context('S',204);
end;

· Run Again
· select * from oe_order_headers

But for R11i it is still the same
· Set Context
begin
dbms_application_info.set_client_info('204');
end;

· Run Query
· select * from oe_order_headers


MOAC in R12 Order Management


In this post I will explain the MOAC feature offered in Oracle Apps R12

MOAC – Multi Operating Unit Access control is a major Feature that Oracle has introduced in R12.
In this post I will explain in brief, impact of MOAC in Order Management.

With the MOAC in place, now user can access to multiple operating units without changing the responsibility. This will be of great help to organizations where user need to change responsibilities to access different operating units
Like Shared Services.

To Implement MOAC, Oracle has introduced new field “Operating unit” in almost all UO like Sales Order, Quick Sales Order, Find Windows (Please refer the user guides for complete list).

Now whenever user Navigate to Transaction related forms like Sales Orders, it is mandatory to enter an OU first to create an order. The moment user select the Operating unit, all the fields that are depend on Operating Units like Ship To, Order Type etc will display data that is relevant for the OU.

Apart from the UI’s like Orders Summary, Book Order, Hold will display Orders across all accessible Operating Units. As explained above whenever user change the Operating Unit, system will clear all the operating units sensitive fields.

In Order management LOV’s for all OU dependent fields have been enhanced to display the Operating unit name along with values.


Let’s take the example of item LOV. As we know in OM item LOV will display all the items based on the Item Validation Organization. Item validation org is depending on the Operating Unit. When Operating Unit field has a value (derived or default) the item LOV will display data based on the Item Validation Org for that Operating Unit. If the Operating Unit is cleared or changed the Item field will be cleared. When the Operating Unit field is null, the item LOV will display data for the Item Validation Org setup for the default OU.

Reports
In almost all the reports a new parameter Operating Unit has been added. If user provides the value for this parameter then Report will be executed for that parameter only, but in case user left that blank report will execute for all the operating units (Accessible to user). Not only that once we select the Operating Units all the OU depend parameter reset, so that they will reflect the value for the selected Operating Unit.
Few of OM reports have made Global, i.e. they will execute and display the data for all the operating units (Accessible to user).

Before we start wring sql/plsql etc we have to keep in mind that in R12 all the operating Unit sensitive view has been replaced with the secured synonyms.
So to set the context they need to execute
MO_GLOBAL.Set_Policy_Context

This API has 2 parameters
Context
Org_id

When policy context is set to ‘M’, data from all accessible Operating Units will be returned.
When policy context is set to ‘S’, then only data from the specified Org_Id will be returned.


NOTE – if user don’t set this context all the secured synonym will not return any data.


SETUP – For complete info, please refer my earlier post.
Set the Global Profile
Set MO: Security Profile
Set MO: Default Operating Unit

API to Check Status of Purchase Order in Oracle Applications.


API to Check Status of Purchase Order in Oracle Applications:


Below is API that return you the status of Purchase Order -


DECLARE
l_po_header_id          NUMBER;
l_po_status_rec         PO_STATUS_REC_TYPE;
l_return_status         VARCHAR2(1);
l_autorization_status   VARCHAR2(30);
l_po_release_id         NUMBER;
BEGIN
 PO_DOCUMENT_CHECKS_GRP.po_status_check
                                (p_api_version => 1.0
                                , p_header_id => l_po_header_id
                                , p_release_id => l_po_release_id
                                , p_mode => 'GET_STATUS'
                                , x_po_status_rec => l_po_status_rec
                                , x_return_status => l_return_status);
                               
l_autorization_status := l_po_status_rec.authorization_status(1);
dbms_output.put_line('Status = '||l_autorization_status);
END; 

Query : Sales Order Details After Pick Release


Query : Sales Order Details After Pick Release:

SELECT ooh.order_number,
ool.line_number,
wnd.delivery_id,
mtrh.request_number
FROM oe_order_headers ooh,
oe_order_lines_all ool,
wsh_delivery_details wdd,
wsh_new_deliveries wnd,
wsh_delivery_assignments wda,
mtl_txn_request_lines mtrl,
mtl_txn_reuest_headers mtrh
WHERE ooh.order_number = --Order Number Input Parameter
AND ool.header_id = ooh.header_id
AND ool.line_id = wdd.source_line_id
AND wdd.delivery_detail_id = wda.delivery_detail_id
AND wnd.delivery_id = wda.delivery_id
AND wdd.move_order_line_id = mtrl.line_id
AND mtrl.header_id = mtrh.header_id

Query : Sales Order Hold & Release


Query : Sales Order Hold & Release:

SELECT OHA.ORDER_NUMBER,
HS.HOLD_ENTITY_CODE CREDIT_CHECK_CRITERIA_CODE,
FLV.MEANING CREDIT_CHECK_CRITERIA,
HD.NAME HOLD_NAME,
HD.TYPE_CODE HOLD_TYPE,
HR.RELEASE_REASON_CODE,
FLV1.MEANING RELEASE_REASON,
HS.RELEASED_FLAG,
HS.HOLD_ENTITY_ID,
OH.HOLD_RELEASE_ID,
OH.HEADER_ID,
HS.HOLD_SOURCE_ID
FROM ONT.OE_HOLD_SOURCES_ALL HS,
ONT.OE_HOLD_DEFINITIONS HD,
ONT.OE_ORDER_HOLDS_ALL OH,
ONT.OE_ORDER_HEADERS_ALL OHA,
APPS.FND_LOOKUP_VALUES FLV,
ONT.OE_HOLD_RELEASES HR,
APPS.FND_LOOKUP_VALUES FLV1
WHERE HS.ORG_ID = '&ORG_ID' --- xxx
AND HS.HOLD_ID = HD.HOLD_ID
AND OH.HOLD_SOURCE_ID = HS.HOLD_SOURCE_ID
AND OH.HEADER_ID = OHA.HEADER_ID
AND FLV.LOOKUP_TYPE = 'HOLD_ENTITY_DESC'
AND FLV.VIEW_APPLICATION_ID = 660
AND FLV.LOOKUP_CODE = HS.HOLD_ENTITY_CODE
AND OH.HOLD_RELEASE_ID = HR.HOLD_RELEASE_ID
AND FLV1.LOOKUP_TYPE = 'RELEASE_REASON'
AND FLV1.VIEW_APPLICATION_ID = 660
AND FLV1.LOOKUP_CODE = HR.RELEASE_REASON_CODE

Query : Get the Account Description


Query : Get the Account Description

SELECT apps.gl_flexfields_pkg.get_description_sql(&char_of_account_id,
1,
gcc.segment1) seg1,
gl_flexfields_pkg.get_description_sql(&char_of_account_id,
2,
gcc.segment2) seg2,
gl_flexfields_pkg.get_description_sql(&char_of_account_id,
3,
gcc.segment3) seg3,
gl_flexfields_pkg.get_description_sql(&char_of_account_id,
4,
gcc.segment4) seg4,
gl_flexfields_pkg.get_description_sql(&char_of_account_id,
5,
gcc.segment5) seg5
FROM gl_code_combinations gcc
WHERE gcc.segment4 = '25130' --gcc.code_combination_id = &code_combination_id;

Query : Query to find receipts against a PO shipment line


Query : Query to find receipts against a PO shipment line

 
execute fnd_client_info.set_org_context('org_id');

SELECT
pol.po_header_id,
pol.po_line_id,
pll.line_location_id,
pll.quantity,
rsh. shipment_header_id,
rsh. receipt_source_code,
rsh. vendor_id,
rsh. vendor_site_id,
rsh. organization_id,
rsh. shipment_num,
rsh. receipt_num,
rsh. ship_to_location_id,
rsh. bill_of_lading,
rsl.shipment_line_id,
rsl.QUANTITY_SHIPPED,
rsl.QUANTITY_RECEIVED ,
rct.transaction_type,
rct.transaction_id,
decode(pol.order_type_lookup_code,'RATE',nvl(rct.amount,0),'FIXED PRICE',nvl(rct.amount,0),
nvl(rct.source_doc_quantity,0) ) transaction_qty
from rcv_transactions rct
, rcv_shipment_headers rsh
, rcv_shipment_lines rsl
, po_lines pol
, po_line_locations pll
where rct.po_line_location_id = 28302 --- check it out
and rct.po_line_location_id = pll.line_location_id
and rct.po_line_id = pol.po_line_id
and nvl(pol.order_type_lookup_code,'QUANTITY') NOT IN ('RATE','FIXED PRICE')
and rct.shipment_line_id=rsl.shipment_line_id
and rsl.shipment_header_id=rsh.shipment_header_id
order by rct.transaction_id

Query : To find PO corrections


Query : To find PO corrections:


execute fnd_client_info.set_org_context('ORG_ID');

SELECT pol.po_header_id,pol.po_line_id, rct.po_line_location_id Line_location_id
, sum (nvl(rct1.source_doc_quantity,0) ) Qty_corrected
from rcv_transactions rct
, rcv_transactions rct1
, po_lines pol
, po_line_locations pll
where rct.transaction_type in ( 'RECEIVE' ,'MATCH')
and rct.po_line_location_id = pll.line_location_id
and rct1.transaction_type = 'CORRECT'
and rct1.parent_transaction_id = rct.transaction_id
and rct1.po_line_location_id = pll.line_location_id
and rct.po_line_id = pol.po_line_id
and nvl(pol.order_type_lookup_code,'QUANTITY') NOT IN ('RATE','FIXED PRICE')
group by pol.po_header_id,pol.po_line_id,rct.po_line_location_id
union all
SELECT pol.po_header_id,pol.po_line_id,rct.po_line_location_id Line_location_id
, sum (nvl(rct1.amount,0) ) Qty_corrected
from rcv_transactions rct
, rcv_transactions rct1
, po_lines pol
, po_line_locations pll
where rct.transaction_type in ( 'RECEIVE' ,'MATCH')
and rct.po_line_location_id = pll.line_location_id
and rct1.transaction_type = 'CORRECT'
and rct1.parent_transaction_id = rct.transaction_id
and rct1.po_line_location_id = pll.line_location_id
and rct.po_line_id = pol.po_line_id
and nvl(pol.order_type_lookup_code,'QUANTITY') IN ('RATE','FIXED PRICE')
group by pol.po_header_id,pol.po_line_id,rct.po_line_location_id