Expanded Logging for LiquidOffice eForms

If you have ever been tasked with administrating or monitoring eForms and processes published by Autonomy Process Administration (formerly known as LiquidOffice), the default events leave a bit to be desired.

Continue reading

One Way ILINX® Manages Compound Documents

As part of the ECM industry, it is important to understand what compound documents are and how they affect you.  Compound documents have been an issue in ECM software from the beginning of time. According to wiseGEEK, Compound documents are document files that contain several different types of data as well as text. A compound document may include graphics, spreadsheets, images, or any other non-text data. The additional data may be embedded into the document or be linked data that is resident within the application. You may be asking what that means for you? We all know that basic ECM is scan/store/retrieve, but what happens when you add electronic documents in PDF or MS Word?

Continue reading

KTM TDS Model Building

Are you tired of separator sheets?  Tired of wasted paper and countless hours of flipping through pages and inserting a barcode sheet at the start of a new document just to take it out after the batch is scanned or leave it in the batch and have more paper to store?  Why not have the computer do the work for you?  That’s the idea behind the Project Planner module in KTM.  There is a standard separation functionality built into KTM that works very well on structured and semi-structured documents but when you have more complex separation rules the Project Planner component of KTM is what you need.

Continue reading

eForms 101

I recently gave a presentation at our Nexus convention about eForms — and how they can produce real business value. Although the presentation was meant for those who have not spent much time analyzing the benefits of e-forms, some real industry heavyweights showed up. Unfortunately this was a lost opportunity because if I had more time I would’ve handed over the microphone for additional eForm paradigms and parables. Alas I had more material than time. Here’s a brief discussion of some of the topics I covered.

An eForm is of course an electronic representation of a paper form. In fact, many eForms look exactly like their paper counterpart. When a paper process goes electric, you’re not just leaving the paper behind. You are opening the door to processing times that are dramatically more expedient, and a host of other advantages.

Because of their inherent characteristics, eForms:

  • save money
    • When it can costs $20 to file a document and up to $314 per filing cabinet for the real state it consumes, you know storing paper isn’t cheap. And it can cost up to $220 to reproduce a lost document.
  • are green
    • Since the United States is the world’s largest producer and consumer paper, and for more than half of all organizations paper use is on the rise – the green choice is to reproduce paper processes electronically
  • are malleable
    • What if you just snail mailed one million requests for information and then discovered a fatal error in the text of your paper document. You can do the math here — it would be expensive to fix this, and slow. Online eForms can be changed in flash with very little effort or cost.

Continue reading

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.