Tech Diff between 11i and R12

MO_GLOBAL-Dive into R12 Multi Org Design I hope you have already read article Basics of Multi Org in R12 . A few questions come to mind when we think about Multi Org in R12. The best way to analyse those questions is by opening package MO_GLOBAL. Don't worry if you are not yet on R12, package MO_GLOBAL is installed 11.5.10 too. Lets get digging. How is CLIENT_INFO being replaced in R12? Lets take an example. In pre Release 12, you would have had following methodology for PO_HEADERS_ALL a. A table is created in PO Schema, named PO_HEADERS_ALL b. A synonym named PO_HEADERS_ALL is created in APPS schema, referring to PO.PO_HEADERS_ALL c. Create a view PO_HEADERS in APPS schema, as "select * from po_headers_all where org_id=client_info" But now in R12, following will happen a. A table is created in PO Schema, named PO_HEADERS_ALL b. A synonym named PO_HEADERS_ALL is created in APPS schema, referring to PO.PO_HEADERS_ALL c. Another synonym named PO_HEADERS is created in APPS, referring to PO_HEADERS_ALL d. A Row Level security is applied to PO_HEADERS, using package function MO_GLOBAL.ORG_SECURITY. This can be double-checked by running SQL select * from all_policies where object_name='PO_HEADERS' e. The effect of this policy is that, whenever you access PO_HEADERS, Oracle RLS will dynamically append WHERE CLAUSE similar to below SELECT * FROM PO_HEADERS WHERE EXISTS (SELECT 1 FROM mo_glob_org_access_tmp oa WHERE oa.organization_id = org_id) Also see **** below, latter Does this mean, if I create a new custom table, I will have to apply RLS [Row Level Security] against Custom table too? Yes indeed, if it contains data partitioned by ORG_ID. All you need to do in such case is to assign package function MO_GLOBAL.ORG_SECURITY to that table/synonym/view. Will the Multi Org Row Level security be applied against the table or the synonym or the view? In theory, RLS can be applied against any of the above objects. However in practice, you will apply RLS against Objects in APPS Schema. This means, you will most probably apply RLS on Synonyms. Basically, the Multi Org Views are now replaced by RLS Secured Synonyms. Hence no code change is required where the pre-R12 Multi-

Org secured view was being accessed. The responsibility of securing data as per ORG_ID now lies with RLS [also known as VPD - Virtual Private Database]. I have made changes to my Multi Org Security Profile, by attaching a new Org Hierarchy. Do I need to run any process? Just like we do in HRMS, it is advised that any changes to Security Profiles must be followed by running "Security List Maintenance" What is MO_GLOBAL.INIT Purpose of mo_global.init :It will check if new Multi Org Security Profile is set, to decide if new Security Profile method will be used. If the new MO security profile is set, then mo_global.init inserts one record, for each Organization in Org Hierarchy, in table mo_glob_org_access_tmp When & from where is mo_global.init called ? This package procedure will be called as soon as you login or as soon as you switch responsibility. Just like FND_GLOBAL.INITIALIZE is called. It is safe to assume that Oracle will invoke MO_GLOBAL.INIT after FND_GLOBAL.INITIALIZE Is mo_glob_org_access_tmp table a global temporary table? Yes, it is. Hence after Multi Org is initialised for your session, your session will have X number of records in table mo_glob_org_access_tmp. X is the number of organizations assigned to MO Security profile [view org hierarchy or org list in security profile] What is the purpose of MO_GLOBAL.ORG_SECURITY? The purpose of Row-Level-Security is to hide certain data [based on some conditions]. RLS does so by appending a where clause to the secured object. 1. MO_GLOBAL.ORG_SECURITY is a function that returns a predicate for the WHERE CLAUSE 2. The where clause will be appended to Table/Synonym/View for which Multi Org Row Level security is enabled What is the purpose of MO_GLOBAL.SET_POLICY_CONTEXT? This procedure has two parameters p_access_mode Pass a value "S" in case you want your current session to work against Single ORG_ID Pass a value of "M" in case you want your current session to work against multiple ORG_ID's p_org_id Only applicable if p_access_mode is passed value of "S" In SQL*Plus, I wish to set my session to work against a specific Org [one single org]. How do I do that in R12 SQL>> exec MO_GLOBAL.SET_POLICY_CONTEXT ('S', 101);

In the above case, ORG_ID 101 will be assigned as current org for your session. Internally, following code in blue will be executed by Oracle when you set your context to single Org, dbms_session.set_context('multi_org2', 'current_org_id', 101); **** If the current database session is initialised for Single Org[as in above step], then Where clause appended to object by Row-Level-Security will be WHERE org_id = sys_context('multi_org2','current_org_id') Why will I as a Apps Techie ever use MO_GLOBAL.SET_POLICY_CONTEXT ? Lets say you wish to call an API to create invoices in ORG_ID 101. In case the API does not have a parameter for Org_id, you can do the below a. exec MO_GLOBAL.SET_POLICY_CONTEXT ('S', 101) b. Call the Invoice API, which will internally read the ORG_ID from MO Current Context. From SQL*Plus, I wish to simulate login to a specific responsibility. How do I do this? a. Call FND_GLOBAL.INITIALIZE - This will set your responsibility id, user_id etc b. call MO_GLOBAL.INIT - This will read the MO profile option values for your responsibility/user, and will initialize the Multi Org Access. What happens to dbms_client_info.set_client_info(101)? This will become redundant functionally. Use mo_global package instead. This package already exists in 11.5.10 instance. And if you open this, you will find this using Row Level Security. Technically I think dbms_client_info.set_client_info will still work, but will produce unexpected results if you have enabled the MultiOrg Security Profile feature too. How does this effect my customizations? Statement 1:- If you have hard-coded client-info command, then obviously that will no longer work [with disclaimers, but I think so will be the case] Statement 2 :- Also, if you have been using fnd_profile.org_Id, that again will not work. Both statements above are false if you decide not to implement Multi Org Access Control feature in Release 12.

Suppliers in TCA - A dive into Vendor Tables in R12

Prior to R12, creation of a vendor/supplier record in e-Business suite largely meant insertion of records in PO_VENDORS. However, from R12 onwards, records are inserted into at least half a dozen tables when a single Supplier record is created. This is largely due to the fact that Suppliers have been moved into the TCA DataModel. In this article, I would like to show you the set of tables that are affected when a Supplier record gets created in Release12. I will also touch base upon Supplier Sites and changes to taxation related tables.

End User Step 1 To begin with, we need to create a Supplier. Lets name it Go4Gold Simply enter name of the Supplier in organization name field and click on Apply. This will create a Supplier.

End User Step 2: You can double check the created Supplier, which has Supplier Number 20186. This supplier number comes from a table named AP_SUPPLIERS.

The registry id that you see is the Party_number field from hz_parties [TCA Party Table] Now, lets have a look at the list of tables impacted by creating the above Supplier record. I am not saying that inserting into below listed tables is the way to create Suppliers in R12 TCA Model

[Use API's for that]. This article is purely for your understanding of the new data model for Suppliers in R12 TCA. Of course this will also be helpful to you when developing reports in R12. Table HZ_PARTIES SELECT * FROM hz_parties WHERE party_name= 'Go4Gold' ; This happens to be the master table now instead of PO_VENDORS. You will notice that the PARTY_NUMBER below is the Registry id in the R12 supplier screen. Also, this party_id = 301934 will be referenced in the remainder set of tables.

Table HZ_PARTY_USG_ASSIGNMENTS SELECT party_id ,party_usg_assignment_id,party_usage_code FROM hz_party_usg_assignments WHERE party_id = 301934; This table stores the Party Usages, for example, in this case it captures the fact that the given party_id is of type SUPPLIER.

Table HZ_ORGANIZATION_PROFILES SELECT * FROM hz_organization_profiles WHERE party_id = 301934 This table captures additional Supplier information, for example, credit scoring details of Supplier or the Number of Employees working in Supplier Organization.

Table IBY_EXTERNAL_PAYEES_ALL SELECT * FROM iby_external_payees_all WHERE payee_party_id = 301934

This table captures Payment related details of the Supplier. For example: 1. How should the supplier's remittance advice be sent? 2. What is the default Payment method Code for this supplier? 3. Who bears the bank charges when lets say SWIFT payment is made? This information can be setup at either the Supplier level or at Supplier Site level. Table AP_SUPPLIERS SELECT vendor_id, vendor_name, segment1, enabled_flag FROM ap_suppliers WHERE party_id = 301934 Alongside HZ_PARTIES, this is another master table that replaces the PO_VENDORS table of 11i. Instead of expanding the design of HZ_PARTIES, oracle decided to hold the supplier specific attributes in AP_SUPPLIERS [fair enough!].

Table POS_SUPPLIER_MAPPINGS SELECT * FROM pos_supplier_mappings WHERE party_id = 301934 This table holds the mapping between the AP_SUPPLIERS.VENDOR_ID and HZ_PARTIES.PARTY_ID. This is useful in cases whereby two vendors effectively belong the same HZ_Party Record.

Table ZX_PARTY_TAX_PROFILE SELECT party_type_code, party_tax_profile_id FROM zx_party_tax_profile WHERE party_id = 301934 The taxation related details like Tax Codes, and Tax Accounts etc have been moved from AP into ZX. ZX is the name of a new Application "E-Business Tax".

Effectively this application is the Tax repository/Taxation Engine for e-Business Suite starting from R12. Effectively this also means that our good old AP_TAX_CODES_ALL is no longer the master table for Taxes. Now we have a new tax rate table, i.e. ZX_RATES_B. ZX_ACCOUNTS is another table that has been introduced to capture accounting setup related to Tax Codes. Database View PO_VENDORS select vendor_name, segment1, party_number from po_vendors WHERE party_id = 301934 PO_VENDORS is a view in R12, that joins AP_SUPPLIERS & HZ_PARTIES.
Similarly, PO_VENDOR_SITES and PO_VENDOR_SITES_ALL are also views based upon AP_SUPPLIER_SITES_ALL.