Professional Documents
Culture Documents
You can enter intermediary bank accounts on Suppliers->Entry->Banking Details->Bank Account Details
This is important when paying a foreign supplier from a domestic disbursement account, there may be an intermediary bank used, and it would be set up on
the supplier bank account. Although the intermediary bank UI is owned by Payments, the implementation is as embeddable UI components in pages owned
by i-supplier Portal (suppliers) and AR/Collections (customers).
Some information
1. The supplier bank account information is in the table: IBY_EXT_BANK_ACCOUNTS, the bank and bank branches information is in the table
HZ_PARTIES.
2. Creating a supplier in AP now creates a record in HZ_PARTIES. In the create Supplier screen, you will notice that that Registry_id is the
party_number in HZ_Parties.
3. The table hz_party_usg_assignments table stores the party_usage_code SUPPLIER, and also contains the given party_id for that supplier. Running
this query will return if customer was a SUPPLIER or CUSTOMER
4. Payment related details of supplier are also inserted in iby_external_payees_all as well as iby_ext_party_pmt_mthds
5. IBY_EXT_BANK_ACCOUNTS, the bank and bank branches information is in the table: HZ_PARTIES.
6. The master record that replaces PO_VENDORS is now AP_SUPPLIERS. PO_VENDORS is a view that joins AP_SUPPLIERS and
HZ_PARTIES.
7. The table that hold mappings between AP_SUPPLIERS.VENDOR_ID and HZ_PARTIES.PARTY_ID is PO_SUPPLIER_MAPPINGS. Query by
party_id.
8. The bank branch number can be found in the table: HZ_ORGANIZATION_PROFILES .The HZ_ORGANIZATION_PROFILES table stores a
variety of information about a party. This table gets populated when a party of the Organization type is created.
ER Diagram(Bank Model)
Oracle Table Involved
IBY_PMT_INSTR_USES_ALL : This stores data from AP_BANK_ACCOUNT_USES_ALL for payment instruments assignments .This information is
stored in the following iPayment (IBY) tables:
The link between PO_VENDORS and HZ_PARTIES is PO_VENDORS.party_id. The link between PO_VENDOR_SITES_ALL and
HZ_PARTY_SITES is PO_VENDOR_SITES_ALL.party_site_id.
When a Supplier is created Record will be Inserted in HZ_PARTIES. When the Supplier Site is created Record will be Inserted in
HZ_PARTY_SITES. When Address is created it will be stored in HZ_LOCATIONS
When a bank Is Created, the banking information will be stored in IBY_EXT_BANK_ACCOUNTS IBY_EXT_BANK_ACCOUNTS.BANK_id =
hz_paties.party_id
When the Bank is assigned to Vendors then it will be updated in HZ_CODE_ASSIGNMENTS.
HZ_CODE_ASSIGNMENTS.owner_table_id = IBY_EXT_BANK_ACCOUNTS.branch_id.
The PARTY_SITE_ID column is the link between the tables IBY_EXTERNAL_PAYEES_ALL & PO_VENDOR_SITES_ALL
In R12 a Supplier Site is stored, in TCA, as a Party_Site. The Party Site has the Party ID of the Party that represents the Supplier record.
QUERY1..try this
QUERY2..try this
QUERY3..try this
accounting data
Final accounting data not generated prior to transfer
to GL
Distribution level information GL
Three distinct distributions tables
Customer transactions
Invoices / Credit Memos / Debit Memos /
Accounting class & amounts, but not debits & credits
Receipts & Adjustments
Unapplied, applied
Both debits & credits
Misc. Cash Receipts
Both debits & credits
View Accounting is a report against
Distributions
Accounting data generated and stored in
Accounting Events tables prior to transfer
to GL
Run Create Accounting to populate
accounting events tables
Supplier
Where as in R12
Supplier becomes as TCA Party.
Suppliers Sites as TCA Party Site for each distinct address.
Contacts for each supplier/address , it means Single supplier address and contact can be leveraged by multiple sites, for each OU
o A single change to an address can be seen instantly by all OUs
o No longer need to manually 'push' updates across OUs.This can be best understood by the figure below.
Then the question is what will happen if any one can come from existing financial products. The Impact from upgrade can summarize as:
Country and address line1 are required, this is because creation of suppliers in Party in TCA data model would requires Country and address information, but
it also understood if there is no country or address line 1 specified for a supplier site in cases when upgrades takes place, Payables derives the country based
on the most frequently used operating unit of the Supplier's historical transactions.
3. Employee as suppliers: address NOT migrated to party site in TCA remains in Oracle HR for data security reasons.
As we know in 11i employees are part of internal supplier's record in order for Oracle Payables to create payments for their expense reports. Employees
defined in Oracle Human Resources and associated with an Oracle Payables supplier record have existing party information. During the upgrade, Oracle
Payables updates the existing party information to have a party usage of supplier but it does not migrate the employee address to the party site in TCA, they
remain in Oracle Human Resources for data security reasons.
4. Utilize TCA Party relationships for franchise or subsidiary and its parent company.
Invoice
But in R12,
Because of introduction of invoice line there is significant improvement of data flow with n other oracle modules like
2. Allocate freight and special charges are captured to the lines on the invoice
3. Invoice distributions created at the maximum level of detail similar to 11i.
4. Core functionality
That's means functional testing is more required while upgrade takes place.
Now a days corporate treasury role has been greatly enhanced thus picking up a global bank as partner for all banking need is demand of time in global
working model. The recent couple of years have seen drastic increase in acquisition and merger of company thus global working as well as global instance
get popularity in ERP areana, and this is one of reason of the reason bank data model has been significant changes from 11 to 11i and 11i to R12.
Internal Bank Accounts
In 11i we have seen internal Banks defined in AP and that is shared by AP/AR/CE, Payroll and Treasury and they are bank accounts often replicated in
multiple OUs
Where as in R12,
Banks/Branches defined in AP
Bank accounts often replicated in multiple OUs Before
R12
Impact of Upgrade
3. Bank accounts, bank account uses are migrated into cash management.
4. Transactions are stamped with the bank account uses identifiers as part of the upgrade
In 11i
Oracle standard functionality was based out of User which determines tax by assigning Tax Codes at line level of invoice and Tax rules was
controlled at underline code.
There was global descriptive flex fields were captured for country-specific tax attributes.
More importanta most of the setup performed at OU level.
In R12
A new module eBusinessTax determines tax based on facts about each transaction, this is reason why Oracle has introduced additional line
information at invoice level.
The module "ebusiness Tax" set and configure Tax rules which can be viewed
Tax attributes collected in fields on key entities
Configure tax rules once per regime and share with your legal entities
Impact of Upgrade
1. Payables Tax setup, Tax Code defaulting rules defined per OU are migrated to eBusiness Tax.
2. OUs migrated to tax content owner in R12
3. Tax information in tax codes are transformed to Regime-Rate flow.
4. E-Business Tax takes information from the AP invoice lines and creates summary and detail tax lines in the E-Business Tax repository.
This feature enables user to access data from one or many Operating Units while within a set given responsibility. Due to this change, all processing and
some Reporting in Oracle Payables is available across Operating Units from a single Applications responsibility. Hence you can isolate your transaction data
by Operating unit for security and local level compliance while still enabling shared Service centre processing.Data security is maintained using the Multiple
Organizations Security Profile, defined in Oracle HRMS, which specifies a list of operating units and determines the data access privileges for a user.
Impact of Upgrade
R12 Upgrade does not automatically create security profiles, thus is important if any one want to use Multiple Organizations Access Control, the first things
is to define security profiles, then link them to respective responsibilities or users.
1. HZ_PARTIES
2. HZ_RELATIONSHIPS
3. HZ_RELATIONSHIP_TYPES
4. HZ_ORG_CONTACTS
5. HZ_ORG_CONTACT_ROLES
6. HZ_CONTACT_POINTS
7. HZ_PARTY_SITES
8. HZ_LOCATIONS
9. HZ_ORGANIZATION_PROFILES
The HZ_ORGANIZATION_PROFILES table stores additional attributes of banks and bank branches along with the history of changes made to Banks and
Bank Branches. The contact person at the bank, bank branch and bank account is defined as a party in HZ_PARTIES, while the contact details will be stored
in HZ_CONTACT_POINTS (stores contact methods), HZ_ORG_CONTACTS (stores the contacts title) and HZ_ORG_CONTACT_ROLES (stores the
contacts purpose or role). The address details of Banks and Bank Branches will be in HZ_LOCATIONS (stores addresses) and HZ_PARTY_SITES (stores
party sites).
The new table CE_BANK_ACCOUNT stores bank account attributes while the CE_BANK_ACCT_USES_ALL table stores the bank account use attributes
specific to Operating Unit (AR, AP) and Legal Entity (Treasury).
The accounting data pertaining to the bank account use will be stored in the CE_GL_ACCOUNTS_CCID table.
All of the bank, branch and bank account related attributes in AP_BANK_BRANCHES and AP_BANK_ACCOUNTS_ALL tables will be upgraded to
HZ_PARTIES and the new tables in Cash Management.
Within TCA model, here is various attributes how they fits inside the model.
Hey did you notice there is one thing that keep changing since last 2 releases ...the bank. We have seen there was once from pre 10.x to 11i when supplier
bank separated from suppliers data and now its again in R12 when it become part of TCA.This time , because of changing business need and high demand of
global partners working model. Not only your company is operating globally,your partner too operating global,then why not use them. In typical business
cost model, if corporate office is using Citibank for payroll for USA operation then why not Citibank Singapore branch is used for payroll for Singapore if
they are operating there. Sound bit low...why ..
Bank Name
po_vendor_sites.bank_number => ap_bank_branches.bank_name
po_vendor_sites.bank_number => ap_bank_branches.bank_number
Bank Number
po_vendor_sites.bank_num => ap_bank_branches.bank_num
po_vendor_sites.bank_num => ap_bank_branches.bank_branch_name
Bank Account Name
po_vendor_sites_all.bank_account_name => ap_bank_accounts_all.bank_account_name
Bank Account Number
po_vendor_sites_all.bank_account_num => ap_bank_accounts_all.bank_account_num
Release 11i
These are tables which hold the bank details irrespective of supplier or internal banks.
ap_bank_branches
ap_bank_accounts_all
If we compare the bank with 11i vs R12, we can notice the bank was utilized into three different places , finance ,payroll and treasury, which requires
altogether a different setup. It was one of the big issues with integration aspect, as significant problem was recognized once the Expense management and
payroll uses same bank for the respective person.
There was a common question/confusion between the Integration Existence between Bank Data in Accounts Payable and Bank Data In Payroll ?
As discussed above , you know most of release of 11i family of oracle Application does not have integration between HR and AP for bank account data.
We have notice in 11i there was functionality in which Payables in which we will create an employee type supplier from HR data and it will contain name
and address info but not bank information. The reason for this is that HR/Payroll does not store the bank information in a standard way that makes the
integration possible.
So now r12 this was well taken care and integration is built. There are plans under way for all bank account data models in the various products to be
consolidated in the new TCA architecture. The Cash Management team is working on this project. Payables and HR/Payroll are working so that the eventual
idea will be that you can set up bank accounts in one place and then indicate the usage (pay, expense reimbursement, etc).
For understanding it is comparison between 11i and release 12 , where TCA community take cares of every things.
Bank Accounts will be stored in a new table called CE_BANK_ACCOUNTS and will be located at a Bank Branch.
The new table which hold the bank information are as:
This new data model allows the bank and bank branch entities to be defined separately allowing users to establish a hierarchical relationship between them.
HZ_CODE_ASSIGNMENTS.owner_table_id = IBY_EXT_BANK_ACCOUNTS.branch_id.
Internal Bank Accounts & Supplier and Customer Bank Accounts in R12
AP Suppliers in R12
In R12 Accounts Payables, that there is no more supplier form. The Suppliers have gone to self-service now. This is not the only change in the supplier. The
suppliers objects have moved from AP product to TCA (Trading Community Architecture) DataModel. Due to this, even the underlying tables have changed.
Supplier information is no more stored in PO_VENDORS Table now.
AP_SUPPLIERS
AP_SUPPLIER_SITES_ALL
AP_SUPPLIER_CONTACTS
But don't panic as your customizations can still work as there are views created with names of PO_VENDORS, PO_VENDOR_SITES_ALL and
PO_VENDOR_CONTACTS for backward compatibility.
Being a part of the TCA, these tables are closely linked to the hz tables. Here is the list of few imp HZ Tables that are
affected when a new supplier is added.
HZ_PARTY_SITES Master table for supplier sites along with AP_SUPPLIER_SITES_ALL instead of PO_VENDORS_SITES_ALL
Captures additional Supplier information, e.g. credit scoring details of Supplier or the Number of Employees working
HZ_ORGANIZATION_PROFILES
in Supplier Organization
This is useful in cases whereby two vendors effectively belong the same HZ_Party Record.
So whenever a supplier is added in R12, an entry is made in all these tables. Functionally also, creating the supplier is different from 11i. Here are the steps
to create a new supplier.
2. Enter a unique supplier name (Organization Name) along with other optional other information like Alias, Tax Registration Number, D-U-N-S number.
3. If the Supplier Number Entry option in the Payables System Setup window is set to Automatic, Payables automatically enters a Supplier Number for you.
If this option is set to Manual, you must enter a unique Supplier Number.
4. Click Apply. The system creates the supplier record and accesses the Suppliers: Quick Update page.
5. To create Supplier Sites, you will have to create the locations for that supplier. For that, click on the "Address Book" Button.
7. Fill all the address details and address purpose. i.e. Purchasing, Payment or RFQ Only.
9. When created, you can manage the addresses for other information.
10. The system only displays sites that are in your MOAC profile
11. The address status indicates whether the supplier has provided any updates for the address. Using iSupplier Portal's Supplier Profile Management tools,
suppliers can enter address book information online, creating any number of new addresses, modifying the details for existing addresses, and indicating how
each address is used.
12. Suppliers can also inactivate addresses that are obsolete. Buyer administrators need to approve any changes in order to update the master supplier details.
Change Pending. A supplier has changed the address details. Click the Update icon to review the changes that have been made. The page displays
the original address details and the changes, indicated by a blue dot. Buyer administrators can approve or make additional modifications to the
changes before approving or rejecting the change. If the supplier has indicated that the address should be removed, there is a status change from
Active to Inactive.
14. Since suppliers are stored in TCA, the address details for the supplier may be used by other Oracle products so be careful if removing supplier addresses.
If the address is inactivated, the system no longer associates it to any contacts, and any bank account assignments to the address are inactivated. Methods to
inactivate addresses include:
You can click the Remove button on the Address Book page. This sets the address status to inactive and sets the Inactive Date for every site that
is associated with the address in all operating units to today's date.
You can update the address and set its status to Inactive. This changes the address status and does not inactivate any of the sites that are using the
address.
You can use the Manage Sites page to manually update the Inactive Date for each site.
Prior to R12, creation of a vendor/supplier record in eBusiness 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.
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
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".
Symptoms
In r11i , creation of supplier record in Accounts Payable records were inserted into PO_VENDORS. As of R12 Suppliers have moved to the TCA Data
Model. Now in R12 these tables are now updated when creating a Supplier Record.
Solution
1. Creating a supplier in AP now creates a record in HZ_PARTIES. In the create Supplier screen, you will notice that that Registry_id is the party_number in
HZ_Parties.
2. The table hz_party_usg_assignments table stores the party_usage_code SUPPLIER, and also contains the given party_id for that supplier. Running this
query will return if customer was a SUPPLIER or CUSTOMER
3.Payment related details of supplier are also inserted in iby_external_payees_all as well as iby_ext_party_pmt_mthds
4. The master record that replaces PO_VENDORS is now AP_SUPPLIERS. PO_VENDORS is a view that joins AP_SUPPLIERS and HZ_PARTIES.
5. The table that hold mappings between AP_SUPPLIERS.VENDOR_ID and HZ_PARTIES.PARTY_ID is PO_SUPPLIER_MAPPINGS. Query by
party_id.
Symptoms
A Supplier and a Customer who reference the same entity will have two rows in HZ_PARTIES. Is this expected?
Solution
If the TCA party is first a supplier, you can query the party and create a customer account for it.
If the TCA party is first a customer, then yes - two parties will be created if a supplier is then created.
Symptoms
Is is possible to use the TCA Party information for an existing Customer as the TCA Party information of a Supplier?
The ability to query an existing TCA party and create them as a supplier is not yet available.
Solution
If the TCA party is first a supplier, you can query the party and create a customer account for it.
If the TCA party is first a customer, then yes - two parties will be created if a supplier is then created.
The reason is that unlike Customers, most of the options and details that define a supplier are not in TCA tables, but in separate tables AP_SUPPLIERS and
AP_SUPPLIER_SITES. In order to enter these details the Supplier form or Supplier Open Interface must be used.
Oracle Subledger Accounting (SLA) is a new module in R12. This document is intended as a summary of some of the new features included in this module
and an overview at how to access this information through the E-business UI and through the database. SLA is an enhancement to the Global Accounting
Engine seen in previously released versions of the Oracle E-business Suite. All Global Accounting Engine Features are supported by Oracle Subledger
Accounting (SLA). SLA stores complete and balanced journal entries for each Subledger Transaction and GL Date. This means that SLA captures detailed
drilldown for each captured journal entry line and becomes a single source of truth for all accounting, reconciliation and analytical reporting.SLA offers the
ability to create multiple accounting representations for the same Subledger
Transactions each to be stored in a separate ledger. SLA also offers the ability to substitute new accounts for old ones using mapping functionality. This is
useful when Accounts become redundant. The redundant account can simply have a mapping to a new account. Subledger Accounting will then generate any
accounting with the new account code saving time having to manually updating entries with redundant codes. Accounting entries are generated in SLA by
running Create Accounting. This can be done at different levels in each Subledger. For Receivables, Create Accounting can either be run at Transaction Level
through a Tools menu option in AR or at Ledger Level through the Concurrent Requests Screen. For Payables, it can be run through the Actions Button or at
Ledger Level through the Concurrent Requests Screen.
When we Create Accounting for Transactions, we can run them in 3 ways:
1 Draft This allows users of the Subledger to review and amend the accounting created
2 Final This is the final version of the accounting for the Subledger
3 Final and Post to GL
Create a final version of the accounting, transfer to GL and Post in GL Users have the ability to view accounting creating for each transaction. This is
available from the Tools menu option within the Transactions screen in Receivables and the Invoices screen in Payables.
Viewing SLA Data through the User Interface (UI) An example of the Accounting for a Receivables Transaction is below. We first look at the transaction
through the Forms UI.
Go to Tool => View Accounting
We can see the Ledger and also the Accounts that the accounting applies to.
Viewing data through the Tables
For this we use the Oracle Diagnostics Tool for Receivables (see the R12 diagnostics Tool.zip document set).
We run the diagnostics for the invoice we looked at above. The accounting for this invoice can be seen
below:
This also allows us to get at the individual queries used to generate this data, by using the See SQL
hyperlinks. For this example these are:
XLA_EVENTS:
SELECT*
FROMxla_eventsxe
WHERExe.application_id=222
ANDxe.entity_idIN(
SELECTxte.entity_id
FROMxla.xla_transaction_entitiesxte
WHERExte.application_id=222
ANDxte.entity_code='TRANSACTIONS'
ANDxte.source_id_int_1=10066)
XLA_AE_HEADERS:
SELECT*
FROMxla_ae_headersxah
WHERExah.application_id=222
ANDxah.entity_idIN(
SELECTxte.entity_id
FROMxla.xla_transaction_entitiesxte
WHERExte.application_id=222
ANDxte.entity_code='TRANSACTIONS'
ANDxte.source_id_int_1=10066)
XLA_AE_LINES:
SELECTxal.*
FROMxla_ae_linesxal,xla_ae_headersxah
WHERExal.application_id=xah.application_id
ANDxal.ae_header_id=xah.ae_header_id
ANDxah.application_id=222
ANDxah.entity_idIN(
SELECTxte.entity_id
FROMxla.xla_transaction_entitiesxte
WHERExte.application_id=222
ANDxte.entity_code='TRANSACTIONS'
ANDxte.source_id_int_1=10066)
XLA_DISTRIBUTION_LINES:
Lee Taylor www.LTSolutions.eu Copyright 2008 LT Solutions Limited
20/08/2008 Page 4 of 4
SELECTxdl.*
FROMxla_distribution_linksxdl,xla_ae_headersxah
WHERExdl.application_id=xah.application_id
ANDxdl.ae_header_id=xah.ae_header_id
ANDxah.application_id=222
ANDxah.entity_idIN(
SELECTxte.entity_id
FROMxla.xla_transaction_entitiesxte
WHERExte.application_id=222
ANDxte.entity_code='TRANSACTIONS'
ANDxte.source_id_int_1=10066)
It is obvious that the driving table and link for all SLA transaction queries is the
XLA_TRANSACTION_ENTITIES table. A possible but not complete list of Entity Codes are: TRANSACTIONS, RECEIPTS, ADJUSTMENTS,
PURCHASE_ORDER, AP_INVOICES, AP_PAYMENTS. This demonstrates that this is a common table for linking Subledger Transaction
such as AR Transactions through to their accounting entries.
Subledger Accounting Setup
This is performed for each Subledger such as Receivables or Payables by navigating to Setup =>
Accounting.
Each Subledger has its own Journal Sources, Entities (remember we saw these above in the table XLA_TRANSACTION_ENTITIES), Mapping Sets (for
mapping redundant accounts), .
There are many changes in how organization units are defined and used in R12. An Organization can represent a Ledger, a Business Group, a Legal Entity,
an HR Organization, an Operating Unit, and an Inventory Organization. You may define the relationships among organizations.
A Business Group is the highest level in the organization hierarchy structure, usually representing the consolidated enterprise, an operating company, or a
major division. The business group secures the employee information in all applications except for HR. For example, when you request a list of employees
for approvals or expense reports, you will see all employees assigned to a business group. This is a little bit confusing, because within the HR applications,
you can assign a security profile at the HR organization level providing a much more granular view of confidential information such as salaries or social
security numbers.
The concept of a Legal Entity is much more developed in R12 than it was in 11i. A legal entity is the organization unit level at which you report taxes and
maintain the corporate banking relationships. The LEGAL_ENTITY_ID column is added to the transaction tables in 12, allowing the ability to track
transactions at a Legal Entity level. In R12, you assign a Legal Entity to a Ledger instead of to a Set of Books. It is recommended that you assign one (or
more) balancing segment values in your chart of accounts to a legal entity.
An HR Organization typically represents the functional management or reporting groups within a business group. You may also define HR organizations for
tax and government reporting or for third-party payments.
The Operating Unit is tied to a ledger (instead of a Set of Books) and, as it was in R11, continues to partition transactions. A ledger can have many operating
units assigned to it. Responsibilities determine the security for operating units. A responsibility can access only the transactions for the operating unit(s) to
which it has been assigned. An operating unit also controls access to reports and concurrent requests. If you set up a profile option MO: Operating Unit, then
the responsibility can only access a single operating unit. If you want a responsibility to access multiple operating units, then you must define a security
profile with multiple operating units assigned and assign it to the MO: Security Profile option. The MO: Default Operating Unit option also allows you to
specify the default operating unit for the transactions entered by that responsibility. Operating units are not directly associated with legal entities, though they
are assigned to a ledger and to a default legal context (Legal Entity). A user can assign any operating unit to a transaction or copy transactions to a different
operating unit if access to the operating unit is authorized by the security profile for the responsibility.
With the new Multiple Organization Access Control (MOAC) feature in R12, transactions may be posted to different operating units and legal entities from a
single responsibility. In order to do this, you set up a security control (MO: Security Profile) to assign multiple operating units and legal entities to a single
responsibility.
An Inventory Organization is the organization that manufactures or distributes products or for which you track inventory transactions and balances. An
inventory organization is associated with a parent operating unit, but can serve other operating units under a different ledger. As such, each inventory
organization is attached to a legal entity and a ledger. You can specify the inventory organizations that are available for each responsibility. You can enter
purchase orders and assign for receipt any inventory organization. Your purchase order operating unit and receiving inventory organization can be in
different ledgers to receive against a purchase order. The following applications secure information by inventory organization: Oracle Inventory, Bills of
Material, Engineering, Work in Process, Master Scheduling/MRP, Capacity, and Purchasing receiving functions. To run any of these applications, you must
choose an organization that has been classified as an inventory organization.
Other organization structures may be set up to reflect hierarchies in different subledgers. For example, you can define organizations for project expenditures
to manage project control requirements in Oracle Projects. Oracle Assets uses asset organizations to perform activities for a specific Oracle Assets corporate
book.
Some information is set up at the organization unit level, while other data is set up once for the entire E-Business Suite. All flexfield definitions, customer
and supplier headers, Oracle Assets, General Ledger, Oracle Inventory, and Oracle Manufacturing products are set up only once in the instance. Oracle Cash
Management, Accounts Payable, Purchasing, Accounts Receivable, Order Management, Project Accounting, and Sales & Services are set up at the operating
unit level. Site information for suppliers and customers is also at the operating unit level.
SLA gives the flexibility to manage the entire accounting rule at one place, which acts as a single source of truth for GL.
Note: There is no separate responsibility to access SLA setup or the view the transactions generated by SLA. Rather we can access SLA setup and review
accounted transactions with extended menus attached to each sub ledger module.
While calling xla_events_pub_pkg.create_events, oracle passes a unique id and event class (Will discuss in next step). Unique ID can be an invoice id or a
po_distribution id or an expenditure_item_id etc. As soon as the sub ledger generates event in SLA, SLA returns unique event_id. This event_id will then act
as a reference to all the accounting entries generated by the SLA. Once event is successfully created in SLA, means that the transaction is registered in SLA
for accounting.
Taking the example of Oracle Projects in 11i where after costing the transaction user need to run the PRC: Interface Cost to General Ledger followed by
Journal Import followed by PRC: Tieback process. But in R12 user only need to run PRC: Generate Cost Accounting Events which will register events
in SLA and thereafter SLA will take care of accounting the transaction and interfacing it to GL. There is no tieback process in R12, as there is one to one
reference of event id between SLA and sub ledger tables.
2. How does SLA understand whether unique id is invoice id or a po_distribution id or an expenditure_item_id as SLA uses same table to store all
the identifier?
In step 1 we discussed that while creating the event we also need to pass event class. This event class is used to distinguish between the types of transaction
passed for processing. To understand this better we will go thru the seeded oracle information.
Navigation:
This screen shows the hierarchical structure of different transactions that can be interfaced to SLA. Because the above screen shot is from Oracle Projects
responsibility thus it shows only the projects related transactions. In the entity screen we see only those transactions that can be interfaced to the GL, thats
why we do not see Invoice as one of the entity as Invoices are not directly interfaced to GL from PA but they are routed thru AR.
Identifiers are the unique ID that is passed to SLA from sub ledgers. Per the screenshot Oracle is passing expenditure_Item_id for entity EXPENDITURE.
Identifier Column field under Identifier window tells what column in SLA table should store expenditure_item_id. The identifier columns that can be used
are SOURCE_ID_INT_1 to 4, SOURCE_ID_DATE_1 to 4, SOURCE_ID_CHAR_1 to 4 these values and columns are present in table
XLA_TRANSACTION_ENTITIES.
Event Class window displays the different kind of expenditure transactions that can be interfaced to GL. This level of hierarchy is known as Event class,
which is further classified into Event Types. In PA we have different event types like Labor Cost, Misc Cost, Usage Cost, Supplier Cost etc. Further we could
classify Supplier Cost as Expense Report and Invoices as Oracle Projects can interfaces only these 2 transactions from AP.
3. Based on the identifiers and event class, how SLA creates accounting lines?
After registering the event in SLA, we can create accounting entries by running executable XDODTEXE. This executable is provided by SLA and is used by
all the sub ledgers with different concurrent program names. Around 160 concurrent programs are uses the same executable for example in Projects it is used
with name PRC: Create Accounting. This executable does the following:
a. Gather information from base tables in sub ledgers.
b. Derive the accounting attributes based on the data fetched from sub ledgers.
c. Derive code combination id based on the business rules.
d. Create journal lines based on the seeded Journal definition.
e. Create lines in XLA_AE_HEADERS and XLA_AE_LINES.
MultiOrg R12
Does this mean the payables clerk responsibility will have access to all the operating units?
This is possible now in R12 if that's what your business needs. You can assign a node of organization hierarchy or a list of operating units to your
responsibility. Effectively, you are now able to assign multiple operating units to a single responsibility. This is made possible either through Organization
Hierarchy or by an Organization List.
This sounds very much like HR Security Profiles as we saw in link Oracle HRMS Security Profiles ?
True, in fact Oracle Release12 multi-org model uses Security profiles (so I am told). Read this linked article above to get your concepts on HRMS security
profile clear.
Does this mean, a security profile will be attached to responsibility as profile option?
Correct.
What if I don't wish to implement this enhanced feature? Will this break my existing multi org setup?
Oracle is great when it comes to upgrades. Unless you implement security profile feature, your multi-org will keep working as pre R12.
Coming back to payables clerk, while keying in the invoice, how will they attach specific invoice they key that invoice against a specific
operating unit?
By entering value in the operating unit field in the screen. Prior to Release12, this was a hidden column. But now all screens that use security profile multi-
org will have an enter-able field.
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
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')
I created an customer-account-site, using the api and all went well in creating the underlying objects. But getting the site using the
hz_cust_acct_site_bo_pub.get_cust_acct_site_bo api gave me an error to give the proper identifiers. Strangely enough you have not only to pass the
p_cust_acct_site_id but also a p_cust_acct_site_os and p_cust_acct_site_osr. You have to now that the os and osr suffixes stand for "origininal system" and
"original system reference", that relate to the entry in hz_orig_sys_references table for the site (owner_table_name='HZ_CUST_ACCT_SITES_ALL'). I
expected that passing only the account-site-id would be enough, but the api checks it against the original system reference.
I found that there is also a validation-query done on the hz_cust_acct_sites table, with a cursor where originally the org_id was a parameter, but it is not used
in the where clause anymore. The object hz_cust_acct_sites turns out to be a synonym on hz_cust_acct_sites_all, but allthough the latter gives me rows, the
first one doesn't. Strange, since hz_cust_acct_sites is certainly not a view.
It turns out that IN EBS R12 a row level security policy is applied on the table, leveraging the VPD possibilities of Oracle DB 10g. And under water for the
synonyms on the '%_all' tables an extra where clause condtion is applied using the org-id. This can be seen for example with:
This shows that the mo_global.org_security function is used to return an extra where-clause-condition on org-id for the table.
For now I only have to have the orig-id set. I found with some tips that it is enough to do:
begin
mo_global.set_policy_context_server(p_access_mode => 'S'
,p_org_id => 204);
end;
As access-mode you can give up 'S' for single, 'M' for multiple and 'A' for all. So you can set multiple org-id's. Well and the org-id of course applies to the
value in hz_cust_acct_sites_all.org_id.
Executing the block above before doing your query would give results from hz_cust_acct_sites. And thus the get-api would have to give the appropriate
result.
There are many other '%_ALL' tables with corresponding synonyms that work the same way.