コミュニティ

U.S. Bank Checks and MICR

Hi,
Using FlexiLayout 11 and FlexiCapture 11, I need to capture the MICR line from U.S. bank checks.

1.  Can FLS specify that a text field uses the MICR fonts?
2.  Can FLS recognize the non-numeric MICR symbols as static text?
3.  When FC uses a MICR font, what characters does it use for the non-numeric symbols?  For example, is the transit symbol always represented as an "A"?
4.  Has anyone published a "best practices" guide/whitepaper/Powerpoint for finding and extracting MICR lines?

Thank you,
Marc

この記事は役に立ちましたか?

0人中0人がこの記事が役に立ったと言っています

コメント

6件のコメント

  • Avatar
    Permanently deleted user

    Hello,

    The words written in MICR (E-13B) and MICR (CMC-7) languages will not be recognized by FLS, so their regions should better be captured by Object Collections.

    On the level of FlexiCapture 11 Document Definition the fields containing the MICR symbols can be extracted if the data type in the Data tab (Text - Special - MICR (E-13B)) and OCR option in the Recognition tab (OCR(printed) - MICR (E-13B)) for these fields would be set correctly . 

    The non-numeric symbols will be recognized as letters ABCD.

    0
  • Avatar
    Permanently deleted user

     

    Hi,
    Thank you for your very rapid response; it is helping a lot.
    I know that your job is NOT to do my job and I appreciate the insights into FLS and FC that you are able to provide.

    There is a Word at doc at https://drive.google.com/file/d/0B7zsSrLCxFRuYU01dFBwNjZiSlU/view?usp=sharing with screen snippets showing that the Object Collection does include the MICR text.

    Of course, coming from FLS, the text is, at best, a set of Raw Text objects.

    As you suggested, in FC, the Data tab (Text – Special and Recognition tab are set to MICR E-13B. (see snippets, below).

    But (and there is always a ‘but’ in these kind of posts) FC only recognizes 2 or 3 “top hats” (please see the last two snippets, below).

    My experience with ABBYY so far has been working with US Tax Returns, where all of the relative positioning of text and separators gives me precise control over the element, and ultimately block, location.

    These very large Object Collections regions are making it difficult for me to help FC pick the right object(s).

    Suggestions?

    Thank you,
    M.

     

    0
  • Avatar
    Permanently deleted user

    Hello,

    In your case, you may capture the desired region as CharacterString elements that is located "nearest: pagebottom", or you may somehow extract the desired area as Region element with coordinates given relatively to well-quality static text, for example, haw it can be put in this region's advanced pre-search relations:

    Let ReferenceElement = kwPayToTheOrderOf;

    Rect R = Rect(ReferenceElement.Left, ReferenceElement.Bottom + ReferenceElement.Height * 10, ReferenceElement.Right + ReferenceElement.Width * 10, ReferenceElement.Bottom + ReferenceElement.Height * 15); //coordinates are in Left, Top, Right, Bottom order

    RSA: R; //short notation of RestrictSearchArea

    0
  • Avatar
    Permanently deleted user

    Hello,

    If only the real world would be so simple.  :-)
    In the US there are two main sizes for checks:  business (3.5 inches x 8.5) and personal (2.75 x 6).
    Also, many checks have optional security features such as micro printing in the borders or security "messages" below the MICR area.
    The file on GoogleDrive (URL:  https://drive.google.com/file/d/0B7zsSrLCxFRuYU01dFBwNjZiSlU/view?usp=sharing)
    shows both such cases.
    I come from a procedural language background (C++/Java) and I understand that the FlexiLayout Language is more event driven and hypothesis oriented.

    My approach has been to attempt to recognize text that is the correct height for MICR characters (E13B is fixed at 0.117 inches tall).

    Problem:
    In FLS the MICR characters do NOT even register as raw text elements unless I manually adjust the region to exclude the fine print at the bottom of the check.

    Question:
    If we can get the MICR reliably recognized as raw page elements, is there a way that post-recognition (when the height is known) code can influence the rejection of other hypothesis that are too small to be MICR?

    Thank you,

    M.

     

    0
  • Avatar
    Permanently deleted user

    Hello,

    FLS language also may adjust the quality of already formed hypotheses, it's made in "Advanced post-search relations". Have you already tried to use them? Here is the FLS Help topic: Elements > Additional search constraints > Advanced post-search relations in the FLS Help.

     

    0
  • Avatar
    Permanently deleted user

    Hi,

    Thank you.
    I think we are "good to go".
    I just need to switch my thinking around:  I was trying to find the good hypothesis, and downgrade the others.
    For FLS, a single line seems to do the trick:

    FuzzyQuality: height.Start, {25*dt,30*dt,40*dt,45*dt};

    Thx,

    M.

    0

サインインしてコメントを残してください。