Oracle IPM Invoice Processing Accelerators

Oracle is rolling out best-practice ERP AP invoice processing solution accelerators as part of their 11g Fusion Middleware offering. Called “adapters”, these ERP software components are available for Oracle E-Business Suite, PeopleSoft, and Siebel.

The accelerators are a mechanism to ensure scanned invoices reach a backend ERP system for final handling even when there are issues in the invoice data gathered using OCR forms recognition during scanning. This allows for minimal user exception handling or intervention prior to each invoice arriving in the ERP system. The idea is to simply load the scanner with invoices, press a button, and then handle the invoices once they arrive in the backend.

In order for this approach to work, Oracle’s solution accelerators use XML documents to contain header and line invoice data. The XML documents are combined with business rules in an Oracle BPEL Process Manager workflow that automatically massages the data into a format that will be accepted by the ERP import functionality such as the Oracle EBS open interface table import. The invoice image resides in the Oracle IPM system.

In the case where data can’t be massaged sufficiently for insert, the invoice is keyed from image from within the BPEL workflow. Invoices that directly insert into the ERP system arrive either ready for validation, matching, payment, coding, etc., or are placed on hold with a hold code and a hold reason code. Some sample hold and reason codes are:

FIELD VALIDATION HOLD HOLD REASON
Purchase Order PO must be valid and open.
PO vendor must match invoice vendor.
IPM_INVALID_PO_HOLD INVALID PO NUM
INACTIVE PO
INCONSISTENT PO SUPPLIER
Supplier Supplier is required.
Supplier must exist in vendor master.
Supplier ID and supplier site ID must match.
IPM_INVALID_
SUPPLIER_HOLD
NO SUPPLIER
INVALID SUPPLIER
INCONSISTENT SUPPLIER

There are many more business rules that operate on each invoice inside of workflow that meet the requirements of the ERP system.

Oracle has created a flash demo of a scan to EBS process at:

http://bit.ly/aHaNwl

Oracle has also created a PDF document that highlights the E-Business Suite Adapter:

http://bit.ly/b4pGFa

As an Oracle partner, ImageSource has begun to implement these solutions in the field.

Clint Lewis
Senior Systems Engineer
ImageSource, Inc.

Match Fields Early when Designing an Imaging Solution

When building an enterprise level imaging system, one of the most important early tasks is matching up the fields in the solution. A typical ERP imaging solution has fields in the following functional areas:

Scan and validation
Image repository
Workflow template
Temporary tables for line items and custom forms
EBS tables

Looking at the big picture, the entire imaging solution is simply a transportation system for meta data stored in table columns (fields) at various stages from paper scan to workflow, to voucher creation. Fields carry information that tie to a specific image document.

Many fields map across each step of the process and must have the same data types. Some fields are used uniquely during scanning, image retrieval, workflow, or in the ERP backend. It is very difficult to begin a project until all these fields are well-known and understood.

One of the challenges of matching up fields is that each area may refer to a field data type (string, integer, etc.) in a slightly different way. An experienced architect and solutions implementor will resolve the type quirks during implementation.

I’ve found the best way to understand how the fields map across the solution is to create a single table with a common set of fields names and data types with columns indicating areas of use, rather than creating separate tables spread throughout the project plan for each area.

Since project plans are lengthy, having a single field mapping table makes it much easier to create the necessary fields, templates, and tables during project implementation since you don’t have to jump around in the project document to find the needed information. Also, having a single table prevents incorrectly mapped fields between functional areas because the big picture view is simple to understand.

I like to use color to highlight specific logical field groupings and keep notes for each field. I tend to continuously revise the master table as the project unfolds and additional information is discovered and then email each revision to the key project players so that everyone is working from the same assumptions.

Here is a link to a sample field mapping table. The table can be improved by adding a column that contains realistic sample data for each field. I use basic field type nomenclature and convert the types as needed in each functional environment.

If you are responsible for putting together a project plan for an imaging system deployment, or work in a company with an imaging system, I encourage you to have a table like this that matches your system. It’s very useful.

Clint Lewis
Senior Systems Engineer
ImageSource, Inc.

 

 

Oracle IPM 11g Released!

For those of you who have not heard Oracle has released the next generation of their Enterprise Content Management Software, Imaging and Process Management (IPM) 11g.  This version is the first major step that Oracle has taken to tightly integrate the product into Oracle’s overall software architecture…IPM 11g has been completely overhauled to be part of the Fusion Middleware (FMW) tech stack.  From the ECM perspective, Oracle now has a complete seamlessly integrated end to end offering that includes the storage repository, document management, business process management, library services, web publishing, records management, reporting/monitoring and application integration.  This creates many advantages for customers that use or plan to use other Oracle products in their workplace, as well as, integrating and leveraging existing investments in non-Oracle software.

I have been working as a Systems Engineer and Project Manager with the IPM software base for over 8 years, through the Stellent IBPM acquisition, all the way back to the Optika Acorde and eMedia days.  A couple major differences in implementing the latest Oracle 11g version are the requirements for Oracle Universal Content Management (UCM) for the storage repository and Oracle WebLogic Server for the application/web server.  I look at both of these requirements in a positive light.  UCM and WebLogic Server are powerful robust products that provide standard approaches to managing content storage and applications, respectively, from the FMW perspective.  With that said, if you do not have experience with either UCM or WebLogic, you will need to get up to speed with them to succeed in an IPM implementation.  Neither of these products can be installed through the “Next, Next, Next, Finished!” approach, so careful upfront planning and architecting is required to ensure a successful implementation.

Let’s talk about the new user interface a little bit.  Oracle has followed suit with the rest of the major players in the ECM world by creating a complete web based interface for performing all administrative and end user functions.  This makes administration duties of the system much easier than in past versions that require administration to be done through the “thick” client.  Also, by moving to the WebLogic Server the full featured web interface is now much more browser agnostic than in the past.  The image viewer comes in two flavors that support over 400 file formats; a zero footprint view only version and the a re-written java applet that allows for full annotations, annotation security, and server based conversion/rendering for access speed.  The following are a couple of screen captures of the user interface from IPM 11g:

The Client Interface

The Zero Footprint Viewer


Continue reading

Student Enrollment Transcript Processing

Many Colleges and Universities must handle transcripts received from other Colleges and Universities for Student Enrollment processing. The receiving College goes through several steps to process a Student Application for Enrollment and the associated transcript(s) that Application may have and those steps may require the application to pass to several different people.  Usually a folder is created to hold all the documents being received to support the Application and once all required documents are received this folder is passed on to Evaluators to evaluate the application and make an Admit or Deny decision.

The processing of a transcript may follow different processing depending on the College.  In one case the information on the transcript is manually entered into an ERP system for Student Processing on a line by line basis.  This is very labor intensive and slows the processing of a Student’s Application.  In addition, the Evaluator must review the transcript and mark those lines that cannot be transferred, and manually add up the Units Attempted, Units Earned/Completed and calculate a GPA to see if the Student qualifies for admission.  A lot of manual processing is done on a single transcript and a single Student may have one or more transcripts from previous institutions and all have to be evaluated in the same way to determine admission to the school.

There are a couple of products available that can help to automate this Student Enrollment Processing, Oracle I/PM and ABBYY FlexiCapture.  Oracle I/PM can provide both the image storage of all the documents received and also a workflow to route the document sets through the various stages of processing electronically.  This relives the use of paper in the processing and the associated issues of losing track of documents or folders and time consuming searches to find a document.

Since a paper transcript is different for different institutions a product that allows flexibility in processing different formats is required to read the data from the transcript and place it into similar fields that can be uploaded into an ERP system.  The ABBYY FlexiCapture product allows for the capture of information from a free format form like a transcript.  It has a module called FlexiLayout that allows the developer to specify where on a page a specific data set may reside.  It can handle table data like Session/Course data which can be repeated multiple times on a single transcript.  It can handle multiple page transcripts and multiple columns of data on a single page that continues on the next page.  This product is very flexible in the design stages to allow the developer to handle almost all the common issues when attempting to extract data from a transcript.

By using the ABBYY FlexiCapture product and releasing the extracted transcript data and the image into I/PM there are several time and labor gains to Enrollment Processing.

  • Almost all manual routing of paper is eliminated.  This saves time in both the movement of folders from one desk to another and also saves time in searching for the correct folder to place newly acquired documents.
  • Manual Line by Line data entry of transcripts is reduced.  Even with the ABBYY product some labor is still required to review the extraction results and ensure the data is correct.  However, this Validation step takes a lot less time and effort then manual line by line data entry.  The data can then be uploaded electronically into an ERP/Student Processing system.
  • Since the extracted data is now in the I/PM repository it is easy to develop a form that can allow the evaluator to select the Session/Course lines to include in a Total Summary and then press a button so the totals are calculated automatically.  This sure beats the manual method of using a hand calculator.

Using both of these products help in lowering the costs of processing Student Applications for Enrollment and the time consuming effort of transcript processing.

Accounts Payable Processing with Kofax KTM and Oracle I/PM

Every company no matter how big or small has an Accounts Payable department.  It may be as small as one person or it may have ten, fifteen or more people.  For medium and large companies there are problems that arise with the data entry of all that invoice data and the tracking of all those invoices through the approval cycle.  There have been many different methods that companies have created to try and handle both which still lead to missing/late invoices and mistakes during data entry.  Methods such as logging the invoices either in a spreadsheet or manually on paper are just some of the types of methods that companies have tried to keep track of where invoices are and how long they have been waiting to be paid.  Maybe there is a better way.

Kofax KTM in conjunction with Oracle I/PM provides a solution to these two issues.  Kofax provides two software packages to scan and then process documents like invoices.  KTM is the processing part and is able to OCR and identify the key fields on an invoice no matter where on the page the data is located.  KTM can also validate some of the data against the ERP system the company is running. Fields like PO Number, PO Release, Vendor Name, Vendor Address, Vendor Pay Site, Vendor Payment Terms and other fields can be read from the ERP system and added to the set of data held by KTM.  KTM can then pass this data on to Oracle I/PM.

Oracle I/PM is an imaging and workflow software package.  Not only does it store the invoice document with the index data entered through KTM, but it also has a workflow module that can track the invoice through the business process so the users can know where in the process the document is sitting.  With I/PM workflow the invoice can be routed electronically to the assigned approver for invoice approval that is done on a Form built for workflow.  If there are multiple levels that can be handled within the workflow in one of several ways depending on the information available from other systems such as the company ERP system.  In addition, I/PM workflow scripts allow a programmer to write code to transfer the data directly into the ERP system through its data import tables.  I/PM has been successfully integrated to pass data to JDE F0411Z1/F0911Z1 tables and Oracle EBS Open Interface tables to name just a few.  These code scripts are re-usable so we can quickly get them working in your environment.  Have we have found, not every company process their AP Invoices in the same manner, so each implementation we do is slightly different than any other, so we need to discover the differences and then modify the form and script code to match.

We at ImageSource can provide the expertise and experience to quickly get an imaging and workflow process into place in your company.  Just contact us at http://www.imagesourceinc.com to find out how.