The Address table contains street addresses, city and postal codes, the document type in question has each as a separate field, ie street address is one field, city is a separate field as well postal code.
the customer unique identifier is on the form as well, I DON'T want to do a lookup and replace, I just want the database field to help constrain the related field, ie let FC recognition understand that a character is most likely an 8 and not a B or its a 1 and not an L etc.
is there a best practice or pre-verification script to go down to the field and character level to help "bias" the confidence of a character/symbol. ?
the customer unique identifier is on the form as well, I DON'T want to do a lookup and replace, I just want the database field to help constrain the related field, ie let FC recognition understand that a character is most likely an 8 and not a B or its a 1 and not an L etc.
is there a best practice or pre-verification script to go down to the field and character level to help "bias" the confidence of a character/symbol. ?
コメント
2件のコメント
Daniel V,
Not sure if you attended your local FlexiCapture training class. I see you are asking a lot of these simple question. Regarding your question and improving recognition with data type, what you can use is a simple Database lookup. Instead of using exact, you can use "Fuzzy" With this option, if the word is similar, it can match to work and if you enable "copy", it will pull the words in if its close enough.
Otherwise, if you can use Data Type to help with the Recognition. i.e. load a dictionary in.
Its not as simple so my bad if i was not specific enough,
1. I actually don't want to do this in a validation step ie fuzzy/compare/dont replace
2. I actually want to leverage the database to help/constrain the recognition to a value if possible, hence cobman should be coleman
3. just like how a regex constraints a postal code in canada to [A-Z][0-9][A-Z] [0-9][A-Z][0-9] , better would be to load/somehow use 135,000 postal codes from database.
4. its actually the data type recognition - field content constraints but its limited to a dictionary of seemingly single words, what about a phrase "first street kingston" I dont want to keep having to update the doc-def dictionary of a field or do the same thing for the same field in 4 different doc-tyes.
サインインしてコメントを残してください。