Вопрос
Понравился трюк с представлением верификатору repeatable group в виде таблицы. А как при таком подходе быть с верификацией документа (verification)? Ну т.е. понятно, что на верификацию данных (data verification) неуверенно распознанные символы нормально прилетят, но что будет именно на этапе верификации документа? Если я правильно понимаю, то при присвоение значений полей repeatable group полям таблицы информация о том уверенно или не уверенно распознаны символы потеряется… Представим ситуацию: групповая верификация данных, оператор не смог точно определить какой-нибудь символ из поля repeatable group и решил его отложить до этапа верификации документа (verification), чтобы посмотреть на поле или документ целиком и попытаться понять что это за символ. Но при присвоении значений полей repeatable group полям таблицы информация о том, что символ распознан неуверенно потеряется и как его найдет оператор?
В качестве «Если есть, что добавить»
Бывает так, что компания закупила оборудование (например принтеры), а потом годами ждет, когда оно окупится. В итоге документы, например те же инвойсы или чеки, печатаются на таком старье! На основе своих наблюдений в ЕС я даже готов утверждать, что чем крупнее компания, тем вероятнее, что ее инвойсы или чеки печатаются на старых, шумных матричных принтерах с заезженной лентой. Результат получается плачевный. Документы зачастую ни то что OCR, человек прочитать не может… Но! Товары у крупных компаний как правило стандартизированы и у каждого товара есть уникальный баркод или код, который обычно печатается в инвойсе. FlexiCapture позволяет захватив баркод/код вытащить остальную информацию о товаре (например цену, описание) из базы данных (разумеется что нужно иметь базу данных заказываемых товаров, но это как правило не проблема). Эта волшебная возможность иногда даже позволяет восстанавливать испорченные документы — главное чтобы баркоды/коды и количества словились, остальное из базы подтягивается. Вторая проблема, которая решается с помощью этой фичи — приведение описаний товаров к стандартному виду (описания которые приняты у вас, а не у поставщика, могут вытягиваться из БД). И это собирается без единой строчки кода — стандартные правила. Красота!
Вопрос
Понравился трюк с представлением верификатору repeatable group в виде таблицы. А как при таком подходе быть с верификацией документа (verification)? Ну т.е. понятно, что на верификацию данных (data verification) неуверенно распознанные символы нормально прилетят, но что будет именно на этапе верификации документа? Если я правильно понимаю, то при присвоение значений полей repeatable group полям таблицы информация о том уверенно или не уверенно распознаны символы потеряется… Представим ситуацию: групповая верификация данных, оператор не смог точно определить какой-нибудь символ из поля repeatable group и решил его отложить до этапа верификации документа (verification), чтобы посмотреть на поле или документ целиком и попытаться понять что это за символ. Но при присвоении значений полей repeatable group полям таблицы информация о том, что символ распознан неуверенно потеряется и как его найдет оператор?
В качестве «Если есть, что добавить»
Бывает так, что компания закупила оборудование (например принтеры), а потом годами ждет, когда оно окупится. В итоге документы, например те же инвойсы или чеки, печатаются на таком старье! На основе своих наблюдений в ЕС я даже готов утверждать, что чем крупнее компания, тем вероятнее, что ее инвойсы или чеки печатаются на старых, шумных матричных принтерах с заезженной лентой. Результат получается плачевный. Документы зачастую ни то что OCR, человек прочитать не может… Но! Товары у крупных компаний как правило стандартизированы и у каждого товара есть уникальный баркод или код, который обычно печатается в инвойсе. FlexiCapture позволяет захватив баркод/код вытащить остальную информацию о товаре (например цену, описание) из базы данных (разумеется что нужно иметь базу данных заказываемых товаров, но это как правило не проблема). Эта волшебная возможность иногда даже позволяет восстанавливать испорченные документы — главное чтобы баркоды/коды и количества словились, остальное из базы подтягивается. Вторая проблема, которая решается с помощью этой фичи — приведение описаний товаров к стандартному виду (описания которые приняты у вас, а не у поставщика, могут вытягиваться из БД). И это собирается без единой строчки кода — стандартные правила. Красота!