Frequently Asked Questions

What We Do

How It Works

Upgrades and Support

Tech Specs and Requirements

eprentise is a set of software products used to transform the data in Oracle E- Business Suite (EBS) while maintaining the relational integrity.  The software can copy, filter, change, move, or merge any EBS source data or structure into an EBS target. The products work from their own schema on the database tier of EBS, and doesn’t change any Oracle source code or any entered accounting information. For many solutions, it runs one time, propagating all changes throughout your existing EBS data and the the schema may be removed from the EBS instance. The software runs on any Oracle-supported version of EBS and covers all EBS modules.  It gives you the ability to make changes to your EBS that used to be available only through a reimplementation or an extensive consulting project.  There are four major product lines to eprentise software:  Consolidation, Divestiture, Reorganization, and FlexField.

After utilizing eprentise software, your E-Business Suite instance looks and functions according to how you have defined the new target. The process is that you will define what result you want to achieve, and eprentise generates the code to achieve the result. All history from the source has also been transformed in line with the target that you have defined. The changed E-Business Suite looks like it was set up according to your target definition since the original implementation. In the case of a consolidation, it looks as though you had always operated within a single environment. You may optionally decide to retain a copy of the source environment until your reconciliation and audits are completed. The database is functionally and technically complete, consistent and correct.

Consider eprentise in situations like these:

  • A merger or acquisition where both parties run E-Business Suite.
  • To reorganize your data for a smooth transition to Fusion®, a Cloud infrastructure, or another ERP
  • To change the Chart of Accounts, the Calendar, the Currency, or the Costing Method
  • To restructure ledgers, Legal Entities, Operating Units or Inventory Orgs
  • The set-up of E-Business Suite is more than 3-5 years old and no longer supports the business.
  • There are inconsistencies in different parts of the organization and there is too much obsolete, redundant, or unused data.
  • The business is supporting several different instances of E-Business Suite.
  • Business reorganization, shared service center, and IT consolidation scenarios.
  • The company has been acquired, and there is a need to align the business to that of the acquiring company
  • Need historical transactions for costing, supplier history, data retention policies, competitive information
  • Divestiture or spin off of part of the business.

Example Business Scenario:  Add Value to Your Post-Merger Integration by Aligning Two Businesses with eprentise Solutions

  • Company A sells its Division M to a competitor, Company B. Both companies, A and B, run E-Business Suite. Company A runs eprentise Divestiture to split off a copy that contains all of Division M’s business (but none of A’s confidential information). Company A continues to run its main instance, which retains Division M history. It gives the new Division M instance to Company B.
  • Company B may choose to run Division M in a stand alone manner until the end of their fiscal year. The instance is functionally complete, consistent, and correct. One optional change would be to run eprentise’ FlexField software to transform the Division M instance to use the Company B Chart Of Accounts (COA). That would make it easier to consolidate the financial reports between Company B’s main instance and Division M. Another possible project consideration would be aligning accounting calendars with eprentise’ Calendar Change software so that both companies are on the same period or yearly calendar.
  • Next, Company B would run eprentise Consolidate to combine the Division M instance into its main instance. They would add all of Division M’s history and open business transactions, setups that define how Division M transactions work, plus other data like Division M’s customers, suppliers, and employees into Company B’s E-Business Suite instance.

With eprentise software you can reorganize, split, merge, change or consolidate OEBS instances or structures within an instance, to streamline operations across the enterprise There are hundreds of possibilities with our copy, change, filter, merge, and move functionalities.

  • Reorganize the business structures within an instance. You can:
    • Move transactions from one ledger, legal entity, operating unit, or inventory org to another.
    • Redefine your organization hierarchy by moving legal entities and operating units to a new ledger.
    • Reduce your inventory footprint by merging inventory orgs or moving inventory orgs Streamline your supply chain by merging item masters
    • Leverage purchasing, discounts, and gain visibility into supplier and customer data by merging operating units.
    • Simplify taxes, compliance, and audits by merging ledgers and legal entities
    • Change accounting calendars, accounting base currency, or inventory valuations or costing methods
  • Separate an Oracle EBS instance into two or more complete, consistent and correct instances for a carve-out.
  • Consolidate two or more EBS instances of the same release  to take advantage of a single shared source of business data.
  • Propagate data quality standards throughout one or more instances, including elimination of duplicate master data records.
  • Change key flexfield (KFF) segments and values, such as Asset Categories or System Items, and reflect the change in all the existing transactions.

FlexField runs one time, changes your Chart of Accounts (COA), and then is removed from the E-Business Suite instance. FlexField transforms an existing accounting flexfield’s segment structure, values, and CCIDs (Code Combination IDs) according to your mappings giving you a new Chart of Accounts. It propagates the new CCIDs throughout your existing E-Business Suite data, everywhere that COA is used. It removes the old code combinations for every configuration and every transaction where the whole CCID is used, and recalculates the balances for Many-to-One mappings  so that all balances belonging to a single CCID are summarized into a single line.

After you change your COA your E-Business Suite looks like the new COA has been in use since you first implemented Oracle. The database is functionally and technically consistent and correct.

Consider the following observations about what is not complete, consistent, or correct.

  • If there are multiple E-Business Suite database instances, no single instance provides the complete business data. There are often inconsistencies among instances and Oracle provides no cross-instance functionality. The inconsistencies lead business users to conclude the data is incorrect and can’t be trusted. They often have external spreadsheets to fix the data and reconcile the differences among the instances.
  • When there are multiple EBS instances, you usually find data is passed between them via interfaces, to synchronize data and couple business processes together.  These interfaces are not consistent because the definitions, processes and standards are not enforced through the custom interface scripts.
  • When data is in separate operating units or inventory orgs, there is often duplicate data or processes, and there is no visibility to align discounts or credit limits or customer sites or item costing.  The lack of transparency leads to treating customers and suppliers differently, inconsistent orders, and inconsistent pricing.
  • Standard “Lift and Shift” or greenfield approaches to migrating multiple instances leave out the transaction history, so the business users are left with “sunset” instances that contain all the history up to the point of the data migration. Customers will need to access these sunset instances to look up prior events and transactions, for audit and tax reasons. Thus the single merged instance is not complete.
  • Even when there is only a single instance, there may be different charts of accounts, or different business rules employed by different parts of the organization. If the business users employ external reconciling spreadsheets because of these differences, the instance is not complete, consistent, or correct.

This is what complete, consistent, and correct means.

eprentise does not have a consulting team and does not provide consulting services, but may be able to connect you with partners who can assist in the design process if your internal team needs assistance.  Designing the “To-Be” state is an individual consulting engagement.  Each customer has different priorities and no two customers want the same results.  eprentise software is “Out-of-the-Box” and generic for all customers so eprentise does not assist with the design of your future state or make any recommendations that apply to a specific customer.  We may, as part of the discussion of your target, provide some insight based on our extensive EBS experience, but our primary role is to  guide the customer on how to use eprentise software operations (which operations, which sequence, etc.) to complete the transformation.   You should rely on your accountants auditors, and trusted advisors for input.

The eprentise technical team is located in Bangalore, India.  Most of the rest of the team is US-based.  All work is done remotely using a VPN connection for the eprentise product lines, and generally web sessions for the FlexField product.  For the eprentise products, the eprentise team does the actual running of our software on India time.  For FlexField, the US team will assist remotely.  A Customer Delivery Engineer (CDE) assists with product guidance and support. 

The project duration depends on the project, the eprentise software used, the source and the target, the customer environment, and the customer resources available for mapping, testing, and reconciliation.  We have had some customers complete 3 test cycles of the FlexField software or our Calendar Change software in as little as 10 days, but generally we tell customers to average 3-4 months for a chart of accounts or calendar change.  Other more complex projects such as instance consolidation or changing functional currency could take as long as a year.    The cutover to production usually is done over a weekend and is dependent on the system resources such as CPU and space.  Most of the eprentise time on complex reorganization projects is spent on specifications and building of the rules for the project.  Most of the customer time is spent on testing and reconciliation.

The key to eprentise is the Metadata Analysis process. Metadata Analysis discovers and documents the internals and architecture of your E-Business Suite environment. eprentise Software is a rules-based software.  The rules understand all the relationships in EBS, the sequence in which rules must be applied to maintain the relational and data integrity, rules to resolve data conflicts, and the impact of changing any one data item across all the EBS data. eprentise packages and manages the rules in a knowledge repository.  That knowledge repository is used by all of the eprentise products, for all customers.  eprentise has a method for adding new rules and validating existing rules.  More than 70% of the rules in the eprentise repository are not in any Oracle documentation, including the My-Support notes, the eTRM, the implementation or user guides.  Metadata Analysis is a required product for all eprentise projects. After Metadata Analysis “learns” about your environment, it creates rules that direct eprentise software in the methods and sequences for making changes to the database. eprentise then verifies that the rules it created are valid. It does that by checking each rule against every row of data. Once a rule is verified as not compromising the data integrity, it is added to eprentise’s rule repository. Business users identify the changes they would like to make to the E-Business Suite by defining a “target”. The structure of the target determines the code that eprentise generates to execute the rule.  Rules are executed by different templates specific to a product (i.e. divestiture, calendar change, change key flexfields, merge inventory orgs, etc.).

Here are the main functional components of the eprentise software. Each plays its part in transforming the data in an E-Business Suite instance according to the customer’s specifications.

  • Metadata Analysis: The metadata engine discovers, stores, and analyzes the current metadata and configuration within your E-Business Suite instances in relation to a source and a target. The engine compares the rules in your environment with rules in other Oracle EBS environments to determine whether the actual content follows the rules and constraints and to determine the level of confidence that a rule in the repository is applicable to the data in your environment. Metadata Analysis also houses the eprentise proprietary rules repository and the rules tester. eprentise Software validates everything it learns about your environment by validating each rule or constraint against all of the data in your E-Business Suite database instance in order to identify valid rules for your project. 
  • Templates:   Templates provide the identification of the high-level sources and targets in your environment and then execute the rules required from Metadata Analysis in the right sequence  to achieve the results that you want.  Templates define the rules used for each transformation, the sequence of operations in eprentise software, and the resolution of conflicts.
  • Mapping:  Customers create a mapping of the source to the target.  That mapping is often loaded into the software and executed by a template.  For example, a customer may map an old chart of accounts to a new one, or may prepare a spreadsheet showing the current Ledger/LE/ OU/ Inv org structures and then the future structure (what would be merged or moved or copied to a given target).
  • Five Data Operations: There are five basic types of eprentise rules: copy, filter, change, move, and merge. When the templates are executed,  the eprentise Software copies, filters, changes, moves or merges data from one or more sources into a target. Rules may be combined to perform more complex functions. For example, an instance consolidation project will use many rules of each operational type to resolve differences and anomalies between two database instances so that the end result (a) meets the business requirements, and (b) provides a complete, consistent, and correct single instance of E-Business Suite.     

Example Business Scenario:  Move an Inventory Org to a New Operating Unit

A client wanted to move 3 inventory orgs (out of 167 inventory orgs) to a new OU which was in a different LE and Ledger than the source OU.  The target ledger had a different chart of accounts and a different calendar than the source.  The target calendar had to be changed and the target COA had to be changed so that the new OU/LE/Ledger could hold all the history from the source.  That was the Change function.  Then the 3 inventory orgs to be moved had to be filtered out from the source OU utilizing Filter functionality.  The inventory orgs had to be Moved or repointed to the new OU/ LE/Ledger, duplicate item attributes needed to be Merged with the item attributes in the target, and then finally profile options responsibilities, and other configurations needed to be Copied to the moved inventory orgs.

Customers need to define the source and the target (the results they want).  The definition of a source and a target is done by creating a mapping (usually a spreadsheet) from the source to the target.  eprentise software works at the database level within the E-Business Suite and makes changes to a customer’s data. eprentise does not change any source code, packages, or SQL code in an E-Business Suite environment. Since the software is out-of-the-box and works on anything that is standard across all EBS customers, there are business rules, customizations, enhancements, modifications, upstream and downstream interfaces, and workflows that will need to be modified after the software is finished to align with the changes that have been made by the software.  A business rule is data or functions that cannot be taken as is and used in another customer’s environment and includes functionality including cross-validation or security rules or revenue recognition rules, a data warehouse or business intelligence system or custom depreciation or tax rules, etc.   That means that any interfaces to third party systems, enhancements, non-standard reports, and bolt-on software are outside the scope of what eprentise will address in your transformation project. You will need to determine if these are impacted by the eprentise transformation of the EBS and adjust or fit them to the changed EBS data.

Once the eprentise software knows what the target is, then it generates the code to change the source to the target. It does not know the business or best practices for an industry.

  • A Customer Delivery Engineer (CDE) will assist with using the software in test cycles and the cutover to production in accordance with the Software License Agreement terms for the product(s) purchased.
  • FlexField projects involve the following steps (first in a test environment):
    • Create the new Chart of Accounts in your E-Business Suite Environment
    • Request a license key from eprentise and install the FlexField software
    • Create a mapping from the source COA to the target COA
    • Load the mapping into the FlexField software
    • Resolve mapping exceptions
    • Execute the FlexField Software
    • Confirm the results
    • Perform the post-steps as defined by the user manual
    • Reconcile the results and test with all EBS modules
    • Make adjustments to your mapping and run the software as many times as needed until the results are exactly what is expected
    • Prepare for the cutover to production
      Change the Chart of Accounts in your production environment.
  • A FlexField project may be completed in weeks, but most clients average 3-4 months for the project.
  • eprentise projects involve the following steps:
    • Provide VPN access to the test database
    • Some projects will require a Software Requirements and Analysis phase to confirm the mapping and rules to transform the source into the target.  This phase can take from 2 to 10 weeks depending on the complexity of the project.
    • Customer will provide mapping from source to target and may have additional pre-steps to complete.  These will be defined by the CDE.
    • The eprentise team will create a build of the rules required for the first test cycle.  Again, depending on the complexity, the duration will be anywhere from a week to 6 weeks.
    • The eprentise team executes the software and validates the rules from the back end.
    • When the execution is complete, the EBS environment is turned over to the user for testing and reconciliation and track issues resulting from the transformation that are caused by the software.  The customer will complete post-steps and perform a thorough testing of the transformation. eprentise will provide support and fix issues on an ongoing basis according to the terms in the Software License Agreement and prepare for the next build of the software.
    • When testing is complete for the first cycle, additional test runs are scheduled.  A new software build is created and validated from the back end by the eprentise team.  When the client has thoroughly tested, the transformation and completed their cutover preparation, the software will be executed in the production environment by the eprentise team.
  • Depending on the complexity, a simple eprentise project such as a calendar change may be completed in weeks, but very complex projects such as an instance consolidation or a complex reorganization project can take 8-16 months. 

There are three primary elements to a good testing process:

  • The first of these is that you should run Oracle standard reports before the transformation as a benchmark, and then again when it is completed, then do a full reconciliation.   These reports will also serve as an audit trail for your audit team and as documentation of the changes made.
  • The second part of the testing process is to complete a full business process cycle such as procure-to-pay, or record-to-report, etc.  Do your full business process including running all the reports, updating items that were created before using eprentise software (i.e. paying an invoice or fulfilling an order).  Check the before and after as you perform the entire process cycle. 
  • The third part of the testing is to make sure that the changes in EBS are reflected in all your CEMLI (Customizations, Enhancements, Modifications, Localizations, and Interfaces) objects and that all your data is aligned properly.    The testing is applicable to only individual customers who all have different business processes, so eprentise does not assist with test scripts.  Also, there is no need to validate with counts or do any SQL validation from the back end. 

eprentise rules may merge data that is the same, or move transactions from one place to another (i.e. to a new OU, or a new accounting period) or split co-mingled data, so counts do not match.

For a successful project, it is critical that your functional testing be as complete as possible during the first test cycle so that rules may be adjusted for the next run without impacting the project schedule.

Visit our Getting Started page for information on how projects are initiated.

FlexField and eprentise software only work on EBS, and there is no similar software for any other ERP.  We cannot change a SAAS ERP because Oracle Fusion and other Cloud ERPs do not allow direct access to the database which is required to do our transformations. We strongly suggest making the necessary changes your database prior to any migration away from EBS. This allows you to work in an environment that your team is familiar with, and also to ensure you are bringing clean data with you when you go.

eprentise and FlexField have no impact on normal E-Business Suite operations, patches, or upgrades.  You may perform the normal upgrades and maintenance to your EBS environment regardless of the type of data transformations you have done with eprentise software.

The eprentise development team thoroughly understands the relationships in E-Business Suite and has designed and implemented a variety of checks to make sure that the eprentise software does not compromise the integrity of the database as it transforms the data. The rules in our Metadata Analysis repository are our proprietary knowledge, and have been vetted on many commercial databases prior to being incorporated into our rules base.  We designed eprentise and FlexField software specifically so companies could make changes to their E-Business Suite that were previously not possible without a reimplementation.  The reason that there is no other software on the market that does the types of transformations provided by eprentise, even for other ERPs, is that no one else (including Oracle) knows the relationships and rules enforced by EBS that we have embedded in our software.   All of our customers have valid Oracle Support agreements and we have never had an SR logged with Oracle in relation to any of the transformations made by eprentise Software.

If you think that the problem is related to a change made by eprentise or FlexField software, please contact us. We will help you isolate and define the problem, and work with you on your Oracle service request.

Oracle doesn’t “certify” any third-party software.  They do have a process to “validate integrations”, but since eprentise Software is a one-time usage product and does not reside permanently in your environment, there is no on-going integration, so the process to validate integrations does not apply.  Also, the types of transformations that eprentise makes are done directly on the database level, there are no APIs used for any integrations.   All of our customers have valid Oracle Support agreements and we have never had an SR logged with Oracle in relation to any of the transformations made by eprentise Software.  The eprentise Support Agreement warrants that eprentise software will work as advertised without violating the data integrity of your database.

The eprentise solution is out-of-the-box software.  It is a rules-based system that adapts to any customer’s EBS environment.  There is no custom code, no scripting, or migration scripts.  The eprentise team will modify rules and for the eprentise products, the eprentise team will actually run the software. 

For all products, the eprentise team will assist with up to 3 test runs and one cutover to production.   The eprentise team’s role is product usage guidance and product technical support, based on over 30 years’ experience with the E-Business Suite.  This knowledge is built into rules in the software.  The rules are generic and are used in every eprentise product.  The eprentise team analyzes the rules and runs the software to mine and execute the rules.   eprentise software includes the fundamental functions of metadata discovery, comparison, and analysis, plus data copy, filter, change, move, and merge. The eprentise team understands how to interpret the metadata analysis and instance comparison reports, and then, based on the analysis results, plans which of the software operations the customer needs to execute.

Business and technical people who have used eprentise and FlexField software have told us the user interface is clear, uncluttered, and easily understood. You will not need specialist IT resources or consultants to run the software or to write extensions.

The eprentise team works with your team to determine the best approach to get the desired results.

As with many E-Business Suite projects, you will set up clone instances of your production environment and these will be the dev/test environments. 

For eprentise projects, the eprentise team will need VPN access to these test environments.  eprentise will set up its own schema during the installation process.  All eprentise software and staging areas will be within the eprentise schema.  eprentise will work in these cloned dev environments for up to 3 test cycles, and then will cutover in your production environment.

For some projects, you will need a reference instance that is a read-only instance from the same generation as the clone that eprentise will be working in.  The reference instance is necessary if we need to restore from a table either because the data was purged or there is a conflict with rules (particularly ID rules). 

The environments will need to be refreshed for each test cycle run and should be ready a couple days before testing on the previous run will end.  Because most OLTP (on-line transaction processing) systems are not designed for large data volumes, you will probably need to modify the SGA, the tablespaces, and other database parameters to achieve optimum performance. 

The closer your test environments are to your production environment, the better we are able to plan the cutover timing and performance. We will work with you during project planning on the specifics.

A DBA installs eprentise software and manages the performance of the database and maintenance of the environments.   A system or network administrator will provide VPN access.  The eprentise team will run the software for eprentise projects.  For FlexField projects, the primary user is a senior business systems analyst or member of the finance team who understands the mapping.

A DBA with system privileges makes a clone of the database and installs eprentise software. No special skills or new techniques are needed. The install can be completed in about a half day. The DBA may also create eprentise users and projects so that the correct privileges are assigned. A DBA may also be required to monitor performance, and adjust tablespaces or rollback segments as the data is manipulated.

The client or system integrator technical team is involved with modifying and testing custom objects, interfaces, or enhancements (CEMLI objects) and completing the post steps.  The business user may also be involved in completing the post-steps.  A partial list of post-steps may be found.

Testing will be done by the business user and is usually a combination of running standard Oracle reports and completing the normal close process for the changed data.

The testing required for a successful eprentise project is performed by the business user. 

Generally, we recommend that the business users run a standard set of Oracle baseline reports for each module for each ledger or operating unit before the eprentise process starts.  When eprentise is finished, run that same set of reports again and reconcile the post-transformation reports with the ones that were run before. 

We recommend that you do a full close cycle with the normal business processes in each module that you would normally do to close a period or close a year.  We also recommend that you update an item that was open before the process (i.e. pay an invoice, receive a shipment, receive a partial payment, etc.) and make sure that the process can be successfully completed in the transformed target environment.

It is critical that the business users do a thorough testing during the first eprentise cycle so that any rule modifications can be made prior to the second run.  That will minimize the number of issues encountered during the second test run and improve the quality of subsequent runs and the cutover to the production environment.  The early testing by the users is different than testing typically required for most non-eprentise projects where the user does not get involved until the final conference room pilot.  We consider the first test run as the UAT so that the eprentise rules can be adjusted early with minimal impact.

Since eprentise software takes care of all the technical requirements, it is not necessary to do counts or a full regression test.  Counts won’t be accurate anyway since much of the data will be merged or split during the process.  Since the technical team is not as familiar with the close process, and the business cycle, most clients do not have the technical team testing the eprentise results.

However, the technical team should thoroughly test the CEMLI objects since eprentise does not touch them during the process.

eprentise runs on the same platforms as the Oracle E-Business Suite. eprentise is browser-based. You will run the install script on the same server as the E-Business Suite, and then use any browser to access the software.

The eprentise architecture is built on a multi-tiered, distributed computing model. The architecture comprises:

  • A client tier that supplies the user interface
  • An application tier responsible for servicing requests and providing responses to the client tier
  • A database tier, which hosts and manages the eprentise schema

Client tier

The client interface is provided as HTML pages which can be accessed via a URL on a standard web browser. Users log into the application through a Login link provided on the eprentise Index page. You can use a standard web browser (e.g., Internet Explorer 6.0+ or Mozilla Firefox 2.0+) on any type of networked work station.

Application tier

The application tier provides for client side validation and manages the communication between the client tier and the database tier. The Application tier also hosts the eprentise reports engine. The current version of the eprentise software is supported on any Linux or UNIX platform that is also capable of supporting Oracle database versions 9i and above. Apache Tomcat server provides the technology component services and acts as the web server, processing the client requests by way of Web Listener and Java Servlet Engine (JSP).

Database tier

The eprentise database schema houses the eprentise knowledge repository and the core rules engine. The eprentise schema is created with its own dedicated data, index, temporary table space, and all the database objects required to operate when you install the software.

Both application and database tiers may reside on the same physical server that hosts your Oracle E-Business Suite test or production instances. It must at least reside on a server that has a DBlink connection to these instances.

To ensure the fastest and most efficient results, we recommend taking a backup prior to the project run in lieu of performing the run with ‘archive log’ on.

Traditionally, ‘archive log’ functionality is meant to capture smaller-scale changes such as an on-line transaction processing (OLTP) system and is not robust enough to keep up with backing up or recording changes to the millions of records in-place, as our transformation software does. In our experience, using the archive log take 3-5 times longer and require both our team and a DBA to be engaged the entire time to monitor space use. The log can fill rapidly and if there is not adequate space readily available, there will be additional maintenance time required to free up space to move forward. This changes the project time-line drastically as, a run and back-up that normally would take 10-20 hours total would require 30-50 hours of constant surveillance in order to engage the archive log.

Additionally, if there was an issue with the environment that disrupted the results, restoring from the archive log wouldn’t alleviate it as the archive log would likely replicate the same disruption while it restored the instance. A fresh start, including checking the build and processes before re-engaging the software, would be necessary, making the archive log redundant. The archive does not have any built-in intelligence of what is/is not right or what could cause an issue; it is designed to simply log and repeat steps.

Our recommended strategy is to take and retain a backup prior to the software run in the unlikely event a roll back is needed. Archive logging can then be re-engaged after the run to cover ‘disaster recovery’ processes when beginning the process of re-entering transactions. We have never had a customer need to use this restore point but it is a method that would be much less expensive and time consuming if a disruption necessitated another production run.