What is new in R12

MOAC

Multi-Org in simple term means the implementation of multiple business units (or Organization) under a single installation of Oracle Applications. The concept of Multi-Org will manage the operations of an enterprise which has got subsidiaries across globe under a single oracle apps window, taking appropriate care of data security and data maintenance.
It decides how transactions flow through different organizations and how those organizations interact with each other.

• By MOAC (Multiorg Access Control) , we can be able to access  multiple operating units at a time.
• Mutiorg views were replaced with MOAC Based synonyms.
• MO:Security Profile is a new profile added in R12.
• VPD(Virtual Private Database) System will take care of  Data security in R12
• Org Initialisation process in R12 :

begin

   mo_global.set_policy_context('S','204');

 end;

MOAC Synonym Initialization:

begin

   FND_GLOBAL.APPS_INTILISE('APPLICATION_ID','RESPONSIBILTY_ID,'USER_ID');

   MO_GLOBAL.INIT('SQLAP'); -- Application Short Name

end;

Module wise change 11i to R12

1) General Ledger :

• gl_sets_of_books table was replaced with gl_ledgers and gl_ledger_Sets.
• 4c’s comes in R12  Currency,Calendar,Chart of accounts, Accounting Convention , In 11i,  there are 3c’s ( Currency,Calendar,Chart of accounts)

2) Accounts Payable :

• ap_invoice_lines_all table added in R12.
• ap_invoice_distributions_all table populates the data when ever invoice gets accounted.
• Supplier form was converted from form based solution to webbased solution.
• po_vendors tables replaced with ap_suppliers tables.
• Supplier and customer information was defined together Under TCA(Trading Community Architecture).
• Accounting Tables were modified.
• Both supplier and customer bank information was defined under payments(New application in R12) Application.

11i Tables	R12 Tables
po_vendors	ap_suppliers
po_vendor_sites_all	ap_supplier_sites_all
po_vendor_contacts	ap_supplier_contacts
ap_banks	ce_banks
ap_bank_branches	ce_bank_branches
ap_ae_headers_all	xla_ae_headers
ap_ae_lines_all	xla_ae_lines
ap_ae_accounting_events	xla_events

3) Suppliers

11i Tables	R12 Tables
po_vendors	ap_suppliers
po_vendor_sites_all	ap_supplier_sites_all
po_vendor_contacts	ap_supplier_contacts

Additional supplier related tables in IBY (Payments) and HZ (TCA):
IBY_EXTERNAL_PAYEES_ALL – stores Payee(supplier) information.
HZ_PARTIES – Party data for the suppliers.
HZ_PARTY_SITES – Party site data for the supplier sites.

4) Invoices:

In 11i , Only two table ,AP_INVOICES_ALL, AP_INVOICE_DISTRIBUTIONS_ALL but R12 Additional table  AP_INVOICE_LINES_ALL

Allocations – AP_CHRG_ALLOCATIONS_ALL is obsolete in R12

5) Bank Account Details

11i	R12
AP_BANK_ACCOUNTS_ALL	CE_BANK_ACCOUNTS
AP_BANK_ACCOUNT_USES_ALL	CE_BANK_ACCT_USES_ALL
AP_CHECK_STOCKS_ALL	CE_PAYMENT_DOCUMENTS

 6) Sub-ledger Accounting

SLA is rule based accounting hub in Release 12 (R12) of the Oracle E-Business Suite of applications. SLA is used to derive all attributes required to account a transaction in Oracle General Ledger.
SLA can be configured in many ways to help derive accounting attributes such as the entered amount, accounted amount, date, currency code as well as the more complex attributes like ledger, code combination ID (CCID). SLA accounting attributes are interfaced to GL from SLA, thus in R12 no sub ledger application module (i.e. AP, PO, PA etc) interfaces the transactions directly to GL.
Create Accounting :  Subledger tables and xla_events -> xla_ae_headers, xla_ae_lines and xla_distribution_links
Transfer to GL -: xla_ae_headers and xla_ae_lines -> gl_je_headers and gl_je_lines
Post to GL : gl_je_headers and gl_je_lines -> gl_balances
Subledger Accounting Balances Update  :  xla_ae_headers and xla_ae_lines -> xla_control_balances

11i	R12
AP_ACOCUNTING_EVENTS_ALL	XLA_EVENTS
AP_AE_HEADERS_ALL	XLA_AE_HEADERS
AP_AE_LINES_ALL	XLA_AE_LINES

7) Trial Balance:

New R12 Table
XLA_TRIAL_BALANCES
AP_LIABILITY_BALANCE-> not used in new R12 transactions
AP_TRIAL_BALANCE -> not used in new R12 transactions

8) Taxes:
Functionality provided by E-Business Tax
New tables in R12
ZX_LINES – Detailed Tax lines for the invoice (trx_id = invoice_id)
ZX_LINES_SUMMARY – Summary tax lines for the invoice (trx_id = invoice_id)
ZX_REC_NREC_DIST – Tax distributions for the invoice (trx_id = invoice_id)
ZX_LINES_DET_FACTORS – Tax determination factors for the invoice (trx_id = invoice_id)

9) Order Management

RA_CUSTOMERS ,RA_SITE_USES_ALL ,RA_ADDRESSES_ALL views were removed in R12. in place of ra_customers,ra_site_uses_all,ra_addresses_all views need to use the below mentioned base tables.

• HZ_CUST_ACCOUNTS
• HZ_PARTIES
• HZ_CUST_SITE_USES_ALL
• HZ_CUST_ACCT_SITES_ALL
• HZ_PARTY_SITES
• HZ_LOCATIONS

Source: http://oracleoverview.com/difference-between-r12-and-11i-101

Requisitions Import/Interface

Application.
Purchasing PO.

Validations.
. Requisition Type should not be null.
. Item Type should not be null.
. Item category should not be null.
. Item description should not be null.
. UOM should not be null and should be a valid one.
. Quantity should not be null and should not be negative or 0.
. Item Should exist in the system.
. Supplier should not be null.
. Ship to locaton should not be null.

Interface Tables.
PO_REQUISITIONS_INTERFACE_ALL.
PO_REQ_DIST_INTERFACE_ALL.

Base Tables.
PO_REQUISITION_HEADERS_ALL
PO_REQUISITION_LINES_ALL
PO_REQ_DISTRIBUTIONS_ALL

Import Program Name.
Requisition Import.

Source: http://www.surereddy.com/po-requisitions-interface.php

Handle Error Codes and Exceptions

RowMatch: In-memory filter

RowMatch is used to apply in-memory a qualifying expression to rows in memory. The user specifies a SQL expression.

A RowMatch may be used stand-alone or used a qualifying RowMatch for a ViewObject. To use it stand-alone, one would create a RowMatch. Then, to see if a Row qualifies, one would invoke rowQualifies(Row). Here is an example:

    RowMatch rowMatch = new RowMatch("Deptno = 30");
    if (rowMatch.rowQualifies(row))
    {
       System.out.println("We have a row whose Deptno is 30");
    }

To use a RowMatch for a ViewObject, invoke ViewObject.setRowMatch(RowMatch). Rows will be qualified in-memory.

RowMatch differs from the where-clause of a database query statement mainly in that one should use row's attribute names as opposed to the database column names. Note that database column names are by default case-insensitive, while attribute names are case-sensitive.

Where-clause qualfication only applies to rows already exsiting in the database table. RowMatch will apply to rows as they are read from database query as well. Additionally, RowMatch is applied to rows that are created because of view link consistency.

View link consistency allows a RowSet to see new rows (unposted) created by another RowSet. Internally, when a new row is created by the other RowSet and the row's primary key is set, the original RowSet (if view link cosnsistency is on) receives an event indicating a new row has been created. This RowSet creates a row and inserts it in its collection. Before this copy row is inserted, it is tested against the view object's RowMatch. Only if the row qualifies will it be inserted.

If a qualification can be expressed in a query's where-clause, one should use the where-clause, because database will skip unqualifying rows. If one relies solely on the RowMatch for in-memory qualification, he may incur unnecessary performance overhead, because rows will be read from database query and formed in memory.

Unlike a where-clause, a RowMatch can evaluate expression involving transient attributes and not-yet-posted attribute values.

ViewLinkConsistency/AssociationConsitency

When multiple instances of entity-based view objects in an application module are based on the same underlying entity object, a new row created in one of them can be automatically added (without having to re-query) to the row sets of the others to keep your user interface consistent or simply to consistently reflect new rows in different application pages for a pending transaction.

#The default setting for this parameter is the word "DEFAULT" which has the following meaning. If your view object has:
-A single entity usage, view link consistency is enabled
-Multiple entity usages, and:
--If all secondary entity usages are marked as contributing reference information, then view link consistency is enabled
--If any secondary entity usage marked as not being a reference view link consistency is disabled.
#To set the feature programmatically, use the setAssociationConsistent(true) API on any RowSet. When you call this method on a view object, it affects its default row set
#If you call setWhereClause() on a view object to set a dynamic WHERE clause, the view link consistency feature is disabled on that view object.
#If a row set has view link consistency enabled, then new rows added due to creation by other row sets are added to the bottom of the row set.
#If a row set has view link consistency enabled, then when you call the executeQuery() method, any  qualifying new, unposted rows are added to the top of the row set before the queried rows from the
database are added.
#If viewCriteria is applied on VO2 instance, then framework switch off the association consistency mode at the view object level. This does not allow to reflect changes done in VO1 in VO2. We can programmatically enable it in VO2's executeQueryForCollection method by calling setAssociationConsistent(true).

/*Override below method in VO2Impl.java file to
protected void executeQueryForCollection(Object qc, Object[] params, int noUserParams) {
  super.executeQueryForCollection(qc, params, noUserParams);
  setAssociationConsistent(true);
}

More Details: http://radio-weblogs.com/0123729/

How to find modified rows of EO/VO

Sample Code from AM:

    public void findModifiedRow(){
        Iterator itr = EmpEOImpl.getDefinitionObject().getAllEntityInstancesIterator(getDBTransaction());
        while (itr.hasNext()) {      
            EmpEOImpl eEOImpl = (EmpEOImpl) itr.next();
           
            if (eEOImpl.getEntityState() == Entity.STATUS_NEW){
                System.out.println("Emp "+eEOImpl.getEmpId()+"is a new Row");
            }
            if(eEOImpl.getEntityState() == Entity.STATUS_MODIFIED ){
            System.out.println("Emp "+eEOImpl.getEmpId()+"is a modified Row");
            }          
            if(eEOImpl.getEntityState() == Entity.STATUS_DELETED){
                System.out.println("Emp "+eEOImpl.getEmpId()+"is a deleted Row");
            }              
        }
    }

Query Execution Modes of View Criteria

There are 3 types Execution modes for a view criteria that can be helpful in filtering out the data.

Database: The search results are filtered from the Database table every time the query is hit.
In Memory: The results are filtered from the VO cache memory. It will use the rows which are already in the row set. It will stop the unnecessary hits to the DB.
Both: The results are filtered from the existing row set and also from the filtered results from Database. This is useful when you want to filter from uncommitted records also.

How to trace ADF BC Queries

Set Java option as -Djbo.debugoutput=console in Run/Debug/Profile for the model project. This is just to trace the queries being executed at runtime.

The easiest way to set this system property while running your application inside JDeveloper is to edit your project properties and in the Run/Debug panel, select a run configuration and click Edit to edit it. Then add the string  -Djbo.debugoutput=console to the Java Options field.

What is View Link Consistency

When multiple instances (say VO1, VO2, VO3 etc) of an EO-based VO are based on the same underlying EO, a new row created in one of these VO instances (say VO1)can be automatically added (without re-query) to the row sets of the others (VO2, VO3 etc ). This capability is known as the view link consistency. This feature works for any VO for which it is enabled, regardless of whether they are involved in a view link or not.

Most Commonly Used ADF Business Components Methods

http://docs.oracle.com/cd/E15051_01/web.1111/b31974/appendix_mostcommon.htm#CACHIEBH

JBO-25014: RowInconsistentException

Cause: Comparison of the cached entity failed with the values in the database for that entity. This could happen when another user or operation has committed modifications to the same entity-row in the database. This exception can also be thrown if the equals() method on one of the domain-type attributes in the entity fails.
Action: Choose from the following options:

• Verify that another user or operation has not modified the same row in the database. If this entity has attributes of a domain type verify that the equals() method on these domains do not fail when comparing the existing cached value with the newly fetched value.
• For any attributes/columns that are updated by the database, modify the entity attribute definition by selecting Refresh after update on the Attribute Settings page of the Entity Object Wizard.
• Use view.executeQuery() frequently, especially after any operations that result in data being changed.

Source:http://docs.oracle.com/cd/A97337_01/ias102_otn/buslog.102/bc4j/jboerrormessages.html

AM -executeCommand()

public int executeCommand(java.lang.String command): Executes a SQL command using a JDBC Statement under the current transaction. Applications should use this method to execute application-specific JDBC statements. This method provides a way of bypassing the framework to query the database directly. Internally, the method passes the specified SQL command to a statement on the JDBC connection and executes it.

The following code example uses executeCommand. The SQL string is designed to update the EMP table. This example passes the string to executeCommand, then prints a message to report how many rows were actually updated.

 public static void demoUpdateColumn(ApplicationModule appMod) {
     String sqlStr = "UPDATE EMP " +
                     "SET MGR=7007 " +
                     "WHERE MGR=7698 ";
     int n = appMod.getTransaction().executeCommand(sqlStr);
     System.out.println("Updated " + n + " rows.");
   }

Be careful when using executeCommand, because it will execute any valid SQL statement. For example, you could perform an operation like the following DDL command:

 appMod.getTransaction().executeCommand("DROP TABLE MYTEMPTABLE");

A pending database transaction could be committed inadvertently due to the implicit commit performed by DDL operations, as well as having any row locks released.

Page Flow Scope and Multiple Regions

Every ADF region maintains its own Page Flow scope, this means even if you have two ADF regions on the same page - each ADF region will have its own Page Flow scope and it will not be allowed to enter another region Page Flow scope. If we would be allowed to share Page Flow scope between different regions, it would be easy to pass data from one ADF region to another, however this is not allowed by design.

Solutions:
1. ADF Task Flow parameters - preferable option, is simple to use, however sometimes is not enough for complex scenarios

2. Contextual Events - flexible and powerful approach, but can be too complicated. When application grows, is hard to maintain and understand dependency between different Contextual Events. In certain situations, its mandatory to use Contextual Events, for example dependent region refresh

3. Page Definition Access through Data Control - we can access separate ADF region page definition through Data Control directly. While this works, is not advisable because it creates direct dependencies between regions

4. Session Scope-session scope values are accessible by both regions.  

Source:http://andrejusb.blogspot.in/2011/02/adf-region-communication-data-exchange.htm

Life Cycle Phase details on First page load and on Submit action

ADF Life Cycle:


On First Page Call

1. Restore view.
As the session is fresh, there's no means of any UIViewRoot to restore, so nothing to see here.
2. Apply request values.
This phase is skipped because there is no form submit.
3. Process validations.
This phase is skipped because there is no form submit.
4. Update model values.
This phase is skipped because there is no form submit.
5. Invoke application.
This phase is skipped because there is no form submit.
6. Render response.
The bean is constructed. Behind the scenes a new UIViewRoot is created and stored in the session. If the component binding getters returns precreated components (precreated in e.g. the constructor) and not null, then those will be used, otherwise JSF will create new components. The components will be stored in the UIViewRoot and the bounded components are set in the component bindings. The values to be shown are retrieved from the value binding getters in the backing bean. If the values aren't set yet, they defaults to null. The component bindings are not required by the way. Only use them if you actually need the component in the backing bean for other means than getting/setting the value. In this article they are included just to demonstrate what all happens in the lifecycle.


On Page Submit Action:

1. Restore view.
The bean is constructed. The UIViewRoot is restored from session and the bounded components are set in the component bindings.
2. Apply request values.
Nothing to see here. Behind the scenes the submitted form values are obtained as request parameters and set in the relevant components in the UIViewRoot, for example inputComponent.setSubmittedValue("test").
3. Process validations.
The submitted values are passed through the converter getAsObject() method and validated by the validator. If the conversion and validation succeeds, then the initial input value will be retrieved from the value binding getter and behind the scenes the inputComponent.setValue(submittedValue) and inputComponent.setSubmittedValue(null) will be executed. If the retrieved initial input value differs from the submitted value, then the valueChangeListener method will be invoked.
4. Update model values.
The converted and validated values will now be set in the value binding setters of the backing bean. E.g. myBean.setInputValue(inputComponent.getValue()).
5. Invoke application.
The real processing of the form submission happens here.
6. Render response.
The values to be shown are retrieved from the value binding getters in the backing bean. If a converter is definied, then the value will be passed through the converter getAsString() method and the result will be shown in the form.

Source: http://balusc.blogspot.in/2006/09/debug-jsf-lifecycle.html

Life Cycle phases involved with Validations and ValueChangeEvents

ADF Life Cycle Phases:

Apply Request Values: Each component in the tree extracts new values from the request parameters (using its decode method) and stores the values locally. Most associated events are queued for later processing. If a component has its immediate attribute set to true, then the validation, the conversion, and the events associated with the component are processed during this phase.

Process Validations: Local values of components are converted from the input type to the underlying data type. If the converter fails, this phase continues to completion (all remaining converters, validators, and required checks are run), but at completion, the lifecycle jumps to the Render Response phase.
If there are no failures, the required attribute on the component is checked. If the value is true, and the associated field contains a value, then any associated validators are run. If the value is true and there is no field value, this phase completes (all remaining validators are executed), but the lifecycle jumps to the Render Response phase. If the value is false, the phase completes, unless no value is entered, in which case no validation is run.

What we understand here is that, for input components, by default, the validations are going to be fired in the Process Validations phase. Furthermore, they have a specific order:
1)  converters
2)  required checks (check if it is required)
3)  validators

NOTE: Of course there are some other cases were the required checks are not fired.. but the above is the general idea.

As you may have noticed, in the Apply Request Values phase, it is mentioned that if the component has it's immediate property to true, then the validations will take place in tha phase.

Which means, that they are not skipped.

What we understand here is that validations will fire no matter if the component is immediate =true or not.

But when does the ValueChangeEvent is triggered? Again, according to the documentation:
ValueChangeEvent is an intermediate phase between Process Validations and and updae model Values. This means that ValueChangeListener are invoked right after validations. It does not matter if the component is immediate true or not. The difference lays in the phase those operations will be executed.

The case of the commandButton:
CommandButtons will trigger the validations and valueChangelisteners of inputComponent while pressed. It is the same case weither the the button is partialSubmit and the inputComponent partialTriggered by the button, or the button is not partialSubmit.

If we set the commandButton to immediate true, then some phases are skipped:

According to documentation:  When actionSource components (such as a commandButton) are set to immediate, events are delivered in the Apply Request Values phase instead of in the Invoke Application phase. The actionListener handler then calls the Render Response phase, and the validation and model update phases are skipped.

This means that if the button is set to immediate only the ApplyRequestValues phase will be invoked, the Process Validations phase will be skipped.

So, if we will have a selectOneChoice component with autoSubmit=false and immediate=false and a commandButton with immediate=true. 

According to what we know so far, the commandButton will invoke the ApplyRequestValues phase and then render response phase. Our selectOneChoise, will invoke the validation and ValueChangeListener in the Process Validations phase.. which in our case, will not be invoked.

So we are bypassing everything...

If we want to invoke validators and valueChangeListeners while having the button immediate=true, we will have to have the selectOneChoice to immediate=true as well!

 why? simply because, according to documentation, while having the input component immediate=true, all validators and valuChangeListeners will be shifted to ApplyRequestValues. Which is exactly what we want.

Conclusion: Validators are executed before ValueChangeListeners. They are executed even if the input component is immediate=true. The only change is the which phase they will be executed in.
The combination of commandButton can bypass he validations and valuechangelisteners if it set to immediate=true. We can still have validations and valueChangeListeners triggered if we have the inputComponent to immediate=true. Since the validations and ValueChangelisteners will be triggered in a different phase and more specifically, they will be triggered in the ApplyRequestValues phase.

Source: http://dstas.blogspot.in/2011/12/validator-or-valuechangelistener-adf.html

VO Current Row Refresh

refresh(int refreshMode): Refreshes the row's attributes with values from database. refreshMode should be a combination of REFRESH_.... See REFRESH_... constants for further information.

Sample:
EmpVOImpl eVO = getEmpVO();
EmpVORowImpl eRow = (EmpVORowImpl)eVO.getCurrentRow();
eRow.refresh(Row.REFRESH_UNDO_CHANGES|Row.REFRESH_WITH_DB_FORGET_CHANGES);

REFRESH_WITH_DB_FORGET_CHANGES forgets edits that the current user made to the row. The row data is refreshed from database. The latest data from database replaces data in the row regardless of
whether the row was modified or not.

If the current user had called ApplicationModule#postChanges() REFRESH_WITH_DB_FORGET_CHANGES will pick up the data that he himself wrote through his call to postChanges().

If REFRESH_REMOVE_NEW_ROWS is not specified, REFRESH_WITH_DB_FORGET_CHANGES puts a new row back to blank. If REFRESH_REMOVE_NEW_ROWS is specified, the new row is removed.

REFRESH_WITH_DB_ONLY_IF_UNCHANGED works just like REFRESH_WITH_DB_FORGET_CHANGES for unmodified rows, i.e., the row is refreshed with attribute values from the database. If a row was already modified by this transaction, the row is not refreshed.

If locking mode is pessimistic, the fact that you (this user) were able to change the data means that you were able to lock the row and that you got the latest data.

When using this refresh mode, if the locking mode is optimistic, the framework could bring the latest data for unmodified attributes and merge them into the row, while retaining changed attributes as is. However, this could lead to data integrity problems. Thus, for consistency sake and data integrity, we leave the row alone if it was modified even for optimistic locking mode.

If REFRESH_REMOVE_NEW_ROWS is not specified, calling refresh with this mode will be a no-op (treated just like a modified row). If REFRESH_REMOVE_NEW_ROWS is specified, the new row is removed.

REFRESH_UNDO_CHANGES works just like REFRESH_WITH_DB_FORGET_CHANGES for unmodified rows, i.e., the row is refreshed with attribute values from the database.

For a modified row, this mode refreshes the row with attribute values at the beginning of this transaction. This mode will back out changes that have been posted to database through postChanges(), but not yet committed. Suppose a row's attribute value was modified from 'A' to 'B' and 'B' is posted. Suppose further the user changes 'B' to 'C' (after the post). Calling refresh(int) with this mode will restore the attribute value to 'A'.

Out on database, the attribute value is still 'B'. However, the row is marked as modified, so that when the changes are posted later 'A' will replace 'B' out on database.

If REFRESH_REMOVE_NEW_ROWS is not specified, REFRESH_UNDO_CHANGES puts a new row back to blank. If REFRESH_REMOVE_NEW_ROWS is specified, the new is removed.

Custom Error Message

Sometimes user wants to display custom error message instead of default message. For such cases ADF framework provides a way to create custom error handler class which extends default DCErrorHandlerImpl class. You are not required to write any code to register your custom exception handler class. Instead, you’ve to select the root node of the DataBindings.cpx files in the Structure window, and then use the Property Inspector to set the ErrorHandlerClass property to the fully qualified name of the error handler you want to use.

Example:
Default Message: JBO-25013 Too many object match primary key
CustomMessage: Duplicate Employee Id Found

Source: http://www.adftutorials.com/adf-custom-error-handler-to-display-custom-message-to-user.html