- About Us
- Events and Webinars
- Contact Us
Prior to 12.0.x users had to have a single responsibility for every operating unit in EBS. This increased cost and administrative burden when performing functions in more than one operating unit, and shared service users had to switch responsibilities to service the enterprise.
With R12 Multi-Org Access Control that changes – using the same responsibility and form to enter data for multiple operating units.
Think about it like the inventory organizations / warehouses in the inventory module that allow you to change inventory organizations without switching responsibilities – that is now possible across operating units. The Multi-Org Access Control initiative allows application users to access to multiple operating units via a single responsibility. An additional field has been enabled on the forms to allow tracking of the Operating Unit being transacted. This is a huge boon for shared service organizations where a centralized workforce supports global operations.
Payment Card Industry (PCI) Security Standards Council encourages and in some cases mandates that merchants use only PA-DSS (Payment Application Data Security Standards) certified payment application software.
Certification applies to software applications that store, process, or transmit payment cardholder data as part of an authorization or settlement process. This certification reassures users that Oracle Payments is properly handling and securing sensitive payment card information. R12 comes pre-certified, reducing the time to enable payment services, and proving the enterprise and customer an immediate security benefit. In organizations where PA-DSS certification was previously a barrier to consolidating their card processing into E-Business Suite, this can now be combined into the ERP, reducing IT footprint.
In R12 Oracle has made a concerted effort to migrate a majority of the standard reports to Bi Publisher reports. This allows for users to manipulate the report layouts, and minor logic without the need to involve a technical person for coding changes. For example the standard Receivables Invoice print output can be changed, one can move the data elements around, build basic logic (if country is ‘Germany’ change it to ‘Deutschland’. These basic changes can be handled by the business, resulting in an ability to quickly customize documents for client/vendors without needing a development team involvement.
R12 completed the TCA design by combining all entities into a single data structure, and a common user interface for maintenance. Customer, Vendors, Sales Rep, all share the same structure. This is a positive impact since it provides a single source of data, allowing vendors to be flagged as customers and vice versa. However the negative is the change in process, and mindset as to how external entities are treated. Additionally the change in the user interface will require re-training of the users. Thoughtful business process review is required to mitigate user uncertainty.
The single most powerful feature in R12 is Sub-Ledger Accounting. This is a fundamental change in the way transactions are accounted in the enterprise. SLA introduces a fully configurable layer to handle financial account derivation. SLA provides a solution for handling both GAAP, and IFRS compliance recording, and reporting. The good news is, by default R12 comes with SLA enables for each Sub-Ledger or module. So one does not need to configure anything in order to process transactions through SLA. However, due it’s flexibility, SLA can become a very complex area of configuration,depending on your business needs.
R12 introduces the functionality of Deferred COGS accounting. This books COGS to a deferred account, and upon revenue recognition books COGS to actual COGS account. This functionality whilst of value to many organizations, may result in process changes for companies that do not require such a practice. As of now there is no way to avoid going through the deferred COGS process.
Bank and Payment management is now centralized in R12. In earlier releases Payables and Receivables both has separate banking/payment processes. In R12 Payment Manager allows centralized reconciliation and finance management.
As the Oracle marketing material states there are thousands of improvements in R12. These are just some of the new features, we’ve found in the past have impacted our customers as they move to the R12 platform. Centroid’s approach to upgrade THEN uptake the new features and functions has been a winning strategy in R12 upgrades across industries. This minimizes risk, allows the R12 techstack to stabilize, then, through a phased approach, roll out enhanced business processes and functionality as your organization requires.
Centroid is a cloud services and technology company that provides Oracle enterprise workload consulting and managed services across Oracle, Azure, Amazon, Google, and private cloud. From applications to technology to infrastructure, Centroid’s depth of Oracle expertise and breadth of cloud capabilities helps clients modernize, transform, and grow their business to the next level.