Good Afternoon,
I am running into an issue trying to read a currency in ABBYY where the invoice has cost as the follow:
22 868,25 $
ABBYY is capturing the whole field but representing it incorrectly. I have tried using a character string and a currency field. The currency field doesn't grab the whole cost, the character string results in the attached.
Anyone run into this before?
Thanks,
Comments
7 comments
Yes, all the time. Try playing around with different "normalization settings" in your corresponding field inside the document definition. Here you can choose how numbers should be grouped within a given string, which separators to allow etc. It won't always work and sometimes you can end up introducing "ambiguity" which would require scripting in order to resolve. It can get rather complicated.
What I mean is, if you allow a comma as a separator at the "thousands" position, if this is misread as a decimal, and the actual decimal value is read correctly, you end up with 2 decimal values, from which the system will not be able to decide which is correct. This is where scripting comes in. For instance, you could do a comparison between the unit value as captured vs the value obtained by dividing the line total by the quantity. At this point you could programmatically select the unit value closest to the result obtained from this operation.
Hi,
Total value is 1, 1249.56. But system captures it as 1249.56 and doesn't grab initial 1 value. But when we mark up the value on the form it captures correctly. That means whole value is readable but still system doesnt capture complete value.
How to make it to capture whole value?
If you are using a CS, I would make sure you either include the "," in the character set, make the boundary a little bigger (instead of above the bottom -5, maybe choose -10 or -15 etc), and if that doesn't work you can try grabbing it using a OC.
Hi Elliot, I am using "Amount" data type for Total field. It has been not imported from flexilayout to describe above bottom or anything that measures the boundary. It is directly in the document definition.
Sounds like that particular invoice format could benefit from additional field training or even a custom layout to define those boundaries. Without specific information on where to look it will continue to miss digits if there is unusual spacing for example.
Hi Mike,
Its hard to set any dimension, where to look from as there are many kind of invoices, different keywords/labels and positions for "Total" value and not pertaining to particular invoice. Facing problems for different kinds of invoices. So what can we do?
This is why custom layouts exist. Sounds like you need one as there is no "one size fits all" solution when dealing with elements that move around and which use different formats etc.
Please sign in to leave a comment.