Working for a world leading medical center meant taking on complex challenges with Accounts Payables. In addition to complexities with patient refunds, legal settlements, and escheatment a full year of historical invoices was required. This ambitious scope would minimize the risk of errant payments post-cutover, satisfy 1099 reporting requirements, and streamline operations. Continue reading for 7 lessons that you can apply to your project today.
1. Take Only What You Need
Requirements gathering lead us to 1 full year of historical invoices, this met important tax reporting needs by the business and protected the hospital from issuing duplicate payments. Because this data was converted for tax reporting purposes and to create warnings about possible duplicate invoices post cutover, we were also able to determine what pieces of information were not needed on the invoice and could remove those complexities from the conversion. For example, we did not need the Invoice to match against a Purchase Order in Oracle, likewise we did not need requester information, excluding these nonessential fields meant the invoice could more easily pass Oracle's validations and we could avoid unnecessary configuration.
2. Optimize the Load Process
Loading millions of records into Oracle Cloud is impossible without optimization. Consider what size batch to group invoices into for loading. For our pod sizing and scope, groups of 100K invoices worked nicely and each step of the load process - loading to interface, loading to base tables, validating invoices, and paying invoices - could be executed in a few hours or less. For the Import Payables Invoices step, it was important to increase the number of Parallel Processes that Oracle would issue. Increasing this parameter above 1 meant that backend Oracle would multithread the load process, using 2, 3, or even 10 engines to load data instead of only 1. It was also critical that the interface table was kept tidy, if a few hundred thousand invoices were left in the interface table and not purged it led to a performance drop or outright failure for the next load.
3. Build Exception Handling into the Conversion Program
With a large enough population of data, anything is possible. Converting a full year of Accounts Payable (AP) history meant we encountered exceptional data issues: conflicting information around check versus electronic payment method, invoices incorrectly left in open status for 10 years, check dates 1000 years in the future, disagreements in header versus line amounts, invoices associated with uncleared checks issued 10 years ago. Error handling and reports must be robust enough identify invalid data scenarios. These scenarios must be redirected to the business experts to plan next steps, agree on overrides, or apply manual workarounds.
4. Convert Master Data Ahead of Time
Converting millions of AP transactions during a narrow cutover window is needlessly risky. Even for an on-premise solution, converting historical data during cutover is difficult, for a cloud solution it is a non-starter. Loading a large volume of historical data requires converting the data early, outside of the cutover window. The benefit to converting high volume data early is that the cutover window does not need to be extended to fit in the hours (or days) of processing time for millions of records. However, this also requires converting supplier data earlier since AP Invoices would be meaningless and fail to load without supporting Supplier data.
5. Your Relationship with Oracle Support is an Asset
Oracle wants your implementation to be successful. In fact, Oracle leads the Cloud SaaS (Software as a Service) industry in having technical information around their solution. Oracle's level of transparency and the available of tools and technical resources makes it possible to solve most problems. As with any complex system, however, there will be issues. Learning how to place Services Requests with Oracle, and what content and screenshots to include in them will save dozens of hours over the course of the project.
6. Review Data Before Attempting to Load
Reviewing data prior to load will ensure your organization can test and eventually go-live with the cleanest possible data. This first level of review ought to confirm expected record counts, corrections from prior loads, basic configuration, and required fields. For large scale projects, automated pre-validation can mimic thousands of checks that normally would not occur until the data is loaded into Oracle staging tables or attempted to pass to base table. By carrying out these checks beforehand, it is possible to keep the Oracle environment pristine until the data and configuration is ready for a clean load with minimal errors.
7. Take Advantages of Descriptive Flex Fields
Descriptive Flex Fields (DFF) can accomplish countless things that Oracle Cloud ERP (Enterprise Requirements Planning) might not handle out of the box. DFF's extend the functionality of the Oracle solution by providing generic fields for your organization to customize. Additionally, they can be used to retain legacy information for converted records. For example, DFF's can be defined to stored legacy key information, which will be useful for the users who may have this information committed to memory. For historical AP data, DFF's were repurposed to store the associated legacy Purchase Order number. This made it possible to retain relevant Purchase Order information without the need to recreate the Purchase Order in Oracle.
Reflecting on our Success
The standard approach for most Cloud ERP (Enterprise Resource Planning) implementations is to carry forward as little historical data as possible. The decision to bring vast quantities of historical data into Oracle Fusion Cloud ERP came after months of discussions and cost-benefit analysis. Our effort to load 1.6 million invoices to Oracle Cloud was successful because of the dedication and commitment of subject matter experts from our client, Applaud data migration software, and the unwavering support of Oracle Corporation and their technical support engineers.
