Skip to main content

MarkView Connector - Description of process for OCRInvoice

Article # 304126 - Page views: 236



Applies To

  • ERP System: Oracle
  • MarkView Version: 5.5 - 6.4


What is the process - start to finish - when an OCR document is scanned?

Known Causes

In troubleshooting problems with MarkView OCR Invoice, it is important to understand the mechanisms that are used to process OCR invoices. Using this information, the point of failure can be determined, and the root cause can then be identified.

The first section of this Answer describes the process flow in general terms, from the time an OCR document is scanned until the invoice is imported into Oracle, and the Connector workitems are finished processing.

The second section describes in detail what the mechanisms are and provides links to troubleshooting Answers that relate to problems which can occur at each step.

Overview of OCR Processing

  1. Image is scanned into MarkView Scan and is accepted
  2. TIFF is created on Document Server and workitem is created in the Connector Export workflow
  3. Export Request is created
  4. Document Export OC4J on the OCR machine places xml and tif files on OCR machine, ready for Kofax to process
  5. Kofax Ascent processes the images and places xml, tif, and trg files on OCR machine, ready for Import Server to process
  6. Import Server creates workitem in the Connector Import workflow
  7. Workitem is created in Connector Validation workflow
  8. Row is written into the ap_invoices_interface table so Oracle Open Interface Import can import the invoice
  9. Oracle Open Interface Import creates an invoice in ap_invoices_all
  10. Validation workitem moves to terminal queue

Detailed Description of Processing


  1. Images are scanned in using an OCR barcode
  2. Images are uploaded by the Scan Station to the document server via the DTM
  3. Code in MVT_Document_Capture_Custom.PostCreateDocument creates a workitem in the Connector Export workflow

Export Workflow

  1. In the "Export To Partner System" queue, the name of the (TIFF) file that will be exported to the OCR application is set by the MVCN Set Export File Name rule
  2. In the "Export To Partner System" queue, the MVCN Submit Export Request rule is triggered and creates an Export Request for the connector export queue.
    1. The connector export queue is defined in the mvcn_export_config table, in the export_queue_name column.
    2. The request itself is created via a call to mvcn_workflow.submitExportRequest, which in turn makes a call to mv_export.SubmitTIFFMetadataRequest to create the request.
    3. Mvcn_workflow is a database type, but the actual code called here is determined by the result of the following query:
      1. SELECT workflow_custom_object_type FROM mvcn_connector_application;
      2. Note that there is typically just one row in the mvcn_connector_application table, and for an OCRInvoice implementation the code is typically in the mvcn_ocrInv_workflow_custom type body.
  3. Once the Export Request is created, the Export Workflow workitem transitions to the Partner System Processing queue, where it waits for notification that the invoice has completed OCR and has been imported back into the Connector workflows.
  4. The Connector Export Server DBMS job polls the database for requests. Once it finds a request for the connector export queue, it passes the request to the Document Export OC4J that is running on the OCR machine The URL it uses to pass this to Document Export is the one that is set in the Servlet Address for the Queue Assignment on the Connector Export Server.
  5. The Document Export OC4J gets a copy of the TIFF from the DTM and places the TIFF as well as an XML file on the OCR machine, in the input directory for the Kofax XML Auto Import service. This directory is defined in mvcn_export_config.export_location_url.

OCR Processing

  1. XML Auto Import runs and the image enters Kofax Ascent
  2. During processing by Ascent, the batch goes through the Validation, Verification, and Release queues, in that order. If there is a problem in processing at any point in the process, the batch will be routed to the Quality Control queue, which is roughly the Ascent equivalent of MarkView's Workflow Administration queue. Ascent Batch Manager can be used to check the status of batches, manually process batches, and to investigate problems with batches that get routed to Quality Control.
  3. Kofax Ascent performs OCR on the invoice image. If any of the extracted OCR data does not meet the confidence requirements for Kofax, an end user will have to use the Ascent Validation tool to confirm and/or correct the data.
  4. An xml, tif, and trg file are output by Ascent, in the Import Server's import directory

Import Workflow

  1. Import Server is set up to process files once it sees the .trg file in its import directory. It creates a Connector Import workflow workitem
  2. In the "Notify Export Work Item" queue, the MVCN Set Export Work Item rule identifies the Export workitem that is related to the invoice and uses this to set the ExportWIInstanceId property on the Import workitem.
  3. In the "Notify Export Work Item" queue, the MVCN Notify Export Start Proc rule calls the mvcn_workflow.notifyStartProc procedure, which alerts the MVCNNotifyStartProc event. This event calls the MVCN Transition Start Proc rule, which moves the Export workitem into the Connector Processing queue.
  4. In the "Transform XML" queue, the MVCN Transform XML rule reads the xml that was output by Kofax and transforms it to the format which is used by Connector. This xml is stored in the transformed_xml column of the mvcn_file table.
  5. In the "Import XML" queue, the MVCN Import XML rule imports the transformed XML to create one or more Cnnectcor Entities (Invoice Headers or Invoice Lines)

Validation Workflow

  1. In the "Validate Entity" queue, the MVCN Validate Entity rule calls mvcn_workflow.validateEntity, which runs the validation rules for each of the entities.
    • A list of the validation rules in place can be obtained by running the attached validation_rules.sql.
  2. In the "Validate Entity" queue, the MVCN Set External Vald Status rule sets the ExternalValidationStatus, ExternalValidationReason, and ExternalValidationComments workitem properties for the Validation workitem.
  3. In the "Validate Entity" queue, the MVCN Check Ext Valid Status rule sends the item to the Waiting for External Processing queue if it needs to be rescanned or recycled.
  4. In the "Validate Entity" queue, the MVCN Check Review Status rule moves the workitem to the Review Entity queue if the status indicates review is required. The Connector Review tool in MarkView Home must then be used to correct or verify the OCR data that has been imported. Connector Review can then be used to resubmit the workitem for validation.
  5. In the "Validate Entity" queue, the item transitions to the Populate Interface queue if external processing and review were both not required, or if the review has been completed and the item successfully passed revalidation.
  6. In the "Populate Entity" queue, the MVCN Populate Interface rule populates the Oracle Open Interface table: ap_invoices_interface
  7. After populating ap_invoices_interface, the item moves to the Waiting for Interface Processing and remains there until it is notified that the invoice has been imported into Oracle.

Invoice Interface Import Process

  1. The Oracle Open Interface Import concurrent job imports the invoice, creating a row in ap_invoices_all, which causes the mvcn_oa_ap_import_processed_tr trigger to fire.
  2. The mvcn_oa_ap_import_processed_tr trigger calls the mvcn_workflow.NotifyEndProcSync procedure, which alerts the MVCNNotifyEndProcSync event.
  3. The MVCNNotifyEndProcSync event fires the MVCN Process Unique ID rule, which calls mvcn_workflow.processUniqueId. This procedure calls the workflow custom object (typically mvcn_ocrInv_workflow_custom) and this updates the PayablesInvoiceID property on the Validation workitem. If there is an error at this stage, the item will go to the Interface Processing Error queue. Otherwise it will go to the Successful Interface Completion queue.
  4. In the "Successful Interface Completion" queue, the MVCN Notify IntProc Complete rule calls the mvcn_workflow.notifyInterfaceProcComplete procedure, which calls the interfaceProcessingComplete procedure in the custom workflow object (mvcn_ocrInv_workflow_custom). This procedure copies the original document, creating a new document in the appropriate AP workflow (PO OCR-INVOICE, NON-PO OCR-INVOICE, or PRE-APPROVED OCR-INVOICE).

Keywords: ocr, ocrinvoice