My client company is of the leading companies that engage in the development, production, sale, and provision of services for imaging, network system solutions, and industrial products. Being a multi-billion dollar company with a great visionary approach, they have already started investing in Robotic Process Automation making use of the UiPath’s RPA environment.
The organization majorly deploys Oracle E-Business Suite as its primary ERP product. Oracle EBS, which basically is a highly customized environment of Java-based forms, or, commonly known as Oracle Forms. Dealing with Oracle forms in RPA is quite complex compared to other domains of RPA automation, like Web automation. This is because each Oracle form inside the main Forms window is built as a separate window in itself. But when we try to automate Oracle forms with RPA, only the parent Oracle Forms screen is identified as a Window and all other Oracle forms are detected to be elements inside the parent window, by the RPA tool.
Client’s organization receives hundreds of orders into their ERP system for delivery on products on a daily basis. The client company is a manufacturer but still, it imports many parts/components for many assemblies from different manufacturers across the globe. The heart of the problem was discontinuity/replacement of a part/model by the 3rd party importers which ultimately affected client systems as there are multiple orders already created with the discontinued model(s).
The AS IS Process
Whenever the client organization received notification of discontinuity of a model from the 3rd party importer, they used to deploy multiple people to manually open each order in Oracle EBS, containing the discontinued model and create a new order line(or configuration) – replacing the discontinued model with its new alternate. This was followed by copying the attributes of old order line to its new one and many custom processes, and finally, the cancellation of the old order line, once the new order line with a replacement is ready.
We divided the problem statement into 4 parts and built a solution which was a mixture of RPA automation and Oracle’s R12 concurrent programs. The RPA automation was built as an On-demand execution product which replaced this manual activity with almost 100% accuracy and made this a completely unattended RPA solution.
- The solution prompted the business to place a file in a shared path which was picked up by the RPA bot for processing. This file contained the details on the discontinued model and the new replacement for this model.
- The automation would start by reading this file, FTPing them to a remote Unix server and triggering an R12 concurrent program in Oracle EBS environment. The R12 program, in turn, analyzed these input files and would fetch data for automation processing from Oracle database and would generate a file for the RPA bot to process.
- The bot waits for the program to complete and FTPs back the generated file from the Unix server to the RPA server and reads it for processing.
- With the data in hand, RPA would loop the Oracle EBS processes that involved new configuration creation, unit price update, line bundling, etc, for each of the Orders and lines available in the file. Once the RPA updates all processes with the data for the new model, another R12 concurrent program is triggered, that takes care of pulling custom data related to the old order line from database and updates it on the new order line created by RPA bot.
- As soon as the R12 update for the new order and line are completed, the RPA would move forward to cancel the old model and logging relevant comments to notify the user of the reason for cancellation.
- Finally, when all the order lines available in the file are processed by RPA, the final R12 concurrent program is triggered. This program is basically a reporting program which pulls data from the database and generates a complete report of the process and emails it to the business users.
|Stat Element||Before RPA||With RPA|
|Effort Savings||NA||~250 hrs/month|