One of the major downsides with using IR/ISO in 11i and the initial R12 releases was the change management process. Once an IR is approved it is essentially locked down and cannot be updated thereafter. Only cancelations were only allowed if the corresponding ISO was canceled. So if required dates needed to be changed on the IR, the corresponding ISO and the IR itself would have to be canceled and recreated with the proper dates. Terrible!

Additionally, changes to the ISO, which were restricted to cancelations and scheduled ship date changes, would not propagate automatically to the IR and would have to be done manually. In my opinion this was a huge gap in functionality. If cancelations or scheduled ship date changes were made to the ISO, and if the IR was not manually updated to reflect these changes, it would result in a conflicting supply/demand picture between the requesting and source organizations. In other words, the requesting organization would still see the supply quantity or required date of the IR it originally requested, while the source organization would be planning to the revised demand quantity or scheduled ship date on the ISO.

However, in 12.1 Oracle has finally provided some improvements. The “Improved Internal Requisition/Internal Order Change Management” functionality provides automated change control between the two transactions. In this release, changes made to the ISO can now be automatically applied to the IR. Better yet, the IR itself can also be modified after it has been approved, where changes are also propagated to the ISO. Workflow notifications can also be setup to notify the requesting or supplying organizations of such changes. No longer will there be a discrepancy between the IR and ISO!

Another nuisance of the IR/ISO process was that the changes to the IR or ISO could not be initiated from planning. So if planning had recommendations to change or cancel an IR, this would have to be done manually. Likewise, the ISO would also have to be manually updated to ensure both were in sync.

But in 12.1.2, Oracle has added integration between Advanced Supply Chain Planning (ASCP) and Purchasing to provide internal requisition management from the planner’s workbench. The “Release Recommendations for Internal Requisitions” functionality now allows the planner to release scheduled date and cancelations changes to the IR. This perfectly complements the change management functionality introduced in 12.1.

As a consultant who has seen the pain in implementing the IR/ISO process in the past, these are welcomed changes. I would highly recommend any customers who are in need of an integrated supply chain solution to consider these releases.

The previous way of setting organization context in 11i was to execute the following statement:

dbms_application_info.set_client_info(ORG_ID);

However, in R12, the new way of setting the organization context is as follows:

mo_global.init(’AR’);
mo_global.set_policy_context(’S',ORG_ID);

The ‘S’ parameter indicates a single organization context. Replace ORG_ID with the ID of the operating unit you wish to use. You can also set a context for multiple operating units by setting the security profile. This is done by executing the following statement:

mo_global.set_org_access(NULL,SECURITY_PROFILE_ID,’ASO’);

Replace SECURITY_PROFILE_ID with the ID of the appropriate security profile.  ‘ASO’ represents the application short name associated with the responsibility you’ll be using.

Multiple Operating Unit Access – In 11i, a responsibility could only be tied to a single operating unit. However, in R12, responsibilities can be assigned to one or more operating units by assigning the responsibility to a security profile. This is a great enhancement for businesses where users require multi-organization access.

Credit Card Entry Enhancements - An additional field has been added to the order entry screen to capture the security code typically located on the back of a credit card. Additionally, the credit card number is encrypted at the database level and stored within the Payments (formally iPayments) module. I’ll put out a more detailed article that talks about the drastic changes to the iPayments module.

Reoccurring Charges - Functionality has been added to the TSO (Telecommunications Service Ordering) module which allows reoccurring billings. This is perfect for subscriptions and other like services.

Partial Period Revenue Recognition – A joint OM and AR enhancement, partial period revenue recognition is a set of new revenue recognition rules in AR which allow for revenue recognition on a daily basis. Previously in 11i revenue recognition could only be done on a monthly basis.

Pay Now or Pay Later – Upfront billing in Order Management can now be done and can be configured based on pricing charges, taxes, deposits, installment billing, and prepayments.

Mass Scheduling Changes – The scheduling concurrent request can now pick up lines that have errored in the scheduling workflow activity. It also can now pick up lines that are in Entered status – both converted and manually entered orders.

Customer Acceptance Process - Oracle R12 now provides the ability to introduce a customer acceptance step prior to invoicing. By setting up a deferral reason in AR, invoicing can be deferred until acceptance has been captured.

Tax Updates – Additional tax fields have been added to the order entry screens that provide more flexibility with Vertex.

Architectural Changes to Inventory - in 11i, Discrete and Process Inventory modules were entirely separate entities. Oracle has converged these modules into one data structure, where functionalities from both modules have combined to be available to both. This doesn’t mean much from an OM perspective, but technical changes have been performed to the Pick Release and Ship Confirmation processes to work with the new combined inventory model.

Architectural Changes to OM, Install Base, and Service Contracts Integration – My understanding is that there is no functionality changes, but from a technical standpoint Oracle has implemented a best practice approach  to OM to Install Base and OM to Service Contracts touchpoints to ensure API calls are used rather than direct queries.