Create is an advanced tool that can be used to easily create new x9 output files using a combination of X9Utilities and our E13B-OCR recognition products. Create is designed to be used when you have captured the front and back images for each item (eg, through a scanner), but you do not have associated E13B MICR lines from the front images. In this situation, E13B MICR lines must be obtained through OCR recognition from the MICR band area at the bottom of the front side check image. This OCR process is required since the MICR data fields must be populated into each item within the X9.37 file that is being constructed.
E13B-OCR recognition is often provided by the firmware embedded within your document scanner. When this feature is available, the scanner can read the E13B scan line from at the bottom of each check and provide the MICR line to you via their API. In this way, you do not need a separate E13B recognition tool, since it is integral to your scanner process. Our recommendation is to always use the E13B scan line that can be obtained from scanner, whenever that is option is available to you. There are several reasons why this is considered to be the best overall approach, since it:
- Allows you to leverage the scanner vendor for this process, instead of complicating your environment and potentially adding another vendor to your workflow.
- Provides a proven and reliable approach, since this facility will most probably be used by a majority of their customers.
- Obtains the MICR line from the scanning device using the same API that will already be implemented to obtain the document images.
- Provides a no-cost solution, since vendors most typically always provide this functionality as a part of their bundled solution.
- Represents the most efficient way to obtain the E13B MICR line. OCR recognition is a CPU expensive function, so doing this in your scanner is always the best solution.
If you do not have a scanning solution that provides an OCR MICR line scanner, or if you do not want to use that facility, there are other vendor solutions you might consider. For example, Parascript or Mitek A2iA. Given this background and these alternatives, X9Ware offers our own E13B-OCR recognition solution, which is the X9Ware E13B-OCR product. This product can be licensed on a standalone basis, but is also offered as an extension to X9Utilities. In this scenario, X9Utilities and X9Ware E13B-OCR are fully integrated to provide an optimized flow that can build ICL files using minimal check formation. Specifically, for each item, you will only need the following fields: amount, item sequence number, and the front-back check images.
Image conversion
The check images will ideally already be in TIFF format and x9.100-181 complaint, which means that the are suitable for x9.37 image exchange. If that is not the case, then our create function has the ability to resize and/or repair the images to ensure x9.100-181 compliance. These functions are turned off on a default basis. You must enable “-imageResizeEnabled” and “-imageRepairEnabled” if you want to use these image capabilities.
Although the images that are input to create are ideally in TIFF format, create will also automatically convert images to TIFF as needed from other formats such as PNG, JPG, GIF, or BMP. We nonetheless highly suggest that you avoid using our conversion facilities, since it adds substantially to runtime. It is important your image archive contains the check images as you are sending them to your processor or financial institution. For this reason, the best solution is to convert images elsewhere within your workflow, add them to your internal image archive, and then send the resulting TIFF images into the create process.
Create is built on top of our -write function and thus implements all of the same command line switches that are provided by the writer. Essentially, create is a pre-processor for write, where the csv output file that is manufactured by create will be provided as input to write. All of this is automatically provided by X9Utilities; you can view -create as a “super” version of -write, with the additional capability of obtaining the MICR line through E13B-OCR recognition.
E13B-Threading
As with all OCR processing, our E13B-OCR recognition process is extremely CPU intensive. As part of optimization, recognition will be performed from a series of background threads that are run in parallel, with the intention to maximum performance and minimize overall run time. The “-threads” parameter can be optionally provided to influence the number of background threads that will be used. For example, you can provide a switch value of “-threads:4” to indicate that four (4) threads should be used for recognition processing. When this parameter is not provided, it will default to a reasonable setting based on the number of processors that are available on your system.
CSV conversion of i25 to t25
Create reads an input csv file and applies E13B-OCR recognition against the front-side images to create an output csv file that is formatted specifically for -write processing. The input csv identifies items as “i25” lines, while the output csv identifies items at “t25” lines. You can essentially view the create function as a translator that uses E13B-OCR to obtain the MICR line for each item and then convert apply the MICR line to each “i25” lines to manufacture “t25” lines. Here are the important things to know about the process:
- All “i25” rows within the input csv will be converted to “t25” rows.
- An optional “imageFolder” line can be provided as often as needed, to identify a path for those images that immediately follow the “imageFolder” row. The “imageFolder” can provide the full path to the images within the file system, or can instead provide only a high level path where the image names then provide the lower level path to the image.
- Using “imageFolder” can sometimes be helpful, since it eliminates the need to put a fully qualified file name on each “i25” row. Create uses the “imageFolder” rows to formulated the image file names. These “imageFolder” rows are critical to Create but will not be needed by the writer, since Create passes on fully qualified file names. Because of that, Create drops the “imageFolder” rows and does not pass them on to the writer.
- Other than these translations, Create copies all csv rows from input-to-output.
- Create ensures that the output csv is written in the same sequence as they were encountered on input, despite the background thread processing that is being used internally to optimize the process.
All Writer functionality can be leveraged
Because create ensures that the output csv file is written in the same order as the input csv, you can leverage all functionality that provided by x9utilities -write. This includes:
- Use of the headerXml file to define all x9.37 attributes. The headerXml file name is provided either via the command line or provided on the first row of the input csv.
- Automated insertion of an offsetting ICL credit, based on headerXml parameters.
- Addenda attachment either via headerXml parameters or embedded type 26 and 28 records within the input csv.
- Paid stamps that can be applied to the back-side check images.
- Batch profiles to automatically group items and generate customer level credits.
- Output x9.37 file rename from temp to final on successful completion.
- Summary file(s) of the output x9.37 file that are automatically created on completion, subject to your command line switches (-j, -x, -t).
- Final exit status per -write documentation.
ImageFolder and Base64 image strings
An image folder can be optionally provided on the -create command line. When the image folder is provided, all images will be written to this folder and the output “t52” lines will be redirected to this target folder. Create has this facility to save all processed images, since input images can be repaired, resized, or even converted from other image formats as part of file generation. In these situations, you we recommend that you store these images in your archive, along with your originally captured images, as part of your audit trail. When the image folder is omitted from the command line, images within the intermediate csv file that is constructed and passed to the ICL writer will be populated as base64 strings and not as fully qualified file names. By passing them as base64 strings, they are internally defined within the output csv file and are not dependent on the file system. Using the embedded base64 images can provide a performance improvement when a significant number of items are being processed.
Action CSV
Create will always write the output “ACTIONS” csv file within the same folder at the output T25 csv file. This csv is used to inform you of various actions that have been taken against the input csv and images. The actions csv file can be empty (length zero) when there were no unusual situations or errors during processing, and the write recognition lines (-wrl) switch has not be enabled.
The first field within the ACTIONS csv file is a line type which defines the action that is being reported. ype of data that is mage repair actions were needed. This csv fill have three columns: front-or-back (“front”, “back”), action-taken, fully qualified input image file name, and fully qualified output image file name that will be located within the output image folder. The various line types written to the ACTIONS file are as follows:
ACTIONS File Line Type | Columns |
“imageRepaired” – item has been recognized and written. | [ line type ] Input csv line number Front image file name Back image file name Image side that was repaired: front or back Input image dpi that was detected Image action that was taken Output repaired image file name that was written |
“micrFailed” – failure to find and recognize the micr line. | [ line type ] Input csv line number Front image file name Back image file name |
“accepted” – item has been recognized and written. “micrError” – one or more micr line fields did not pass command line validations. “loadFailed” – unable to load the image. “repairFailed” – image repair was attempted but unsuccessful. “convertFailed” – image conversion from one format to another was unsuccessful. “bitonalFailed” – image conversion to a bitonal (black-white) image was unsuccessful. “converted” – image format conversion was successful. “notFound” – image was not found. “exception” – image processing exception. | [ line type ] Input csv line number Front image file name Back image file name Failed micr line fields MICR recognition confidence level MICR line asterisk count reserved-1 reserved-2 eserved-3 reserved-4 eserved-5 reserved-6 reserved-7 reserved-8 reserved-9 reserved-10 MICR routing MICR OnUs MICR AuxOnUs MICR EPC Unparsed MICR line in its entirety |
FAILURES CSV
Create will optionally write the “FAILURES” csv when the “-wcf” switch is enabled on the command line. The FAILURES file is written within the same folder at the output T25 csv file. This csv contains MICR failure items, written in the x9utilities-write T25 format.
All items where the MICR line cannot be successfully read, or that do not pass the various MICR field validations that are enabled on the command line, will be written to the FAILURES files. Use of this file will ensure that all input items to create are written, either to the standard output file or to the failures file. Hence there are no escapes and all input items are account for.
Create will use the FAILURES file to manufacture a second output x9.37 file using these items. This x9.37 file is similarly written within the same folder at the output T25 csv file. This will use a similarly constructed FAILURES file name with an “x9” extension. These items are considered failed in some manner. Although the FAILURES file will have images, the MICR fields within the type 25 record may not be populated.