0

由于 OpenText Capture Center 内几乎没有关于编程的文档或代码片段。我需要有经验的人提供一些意见。

这里是我需要的关键... 在脚本管理器中，我需要能够访问 OCR 在文档中识别的所有 Phrase 对象，无论在提取过程中匹配或识别的字段如何。

只要我可以访问 OCR 短语，我就可以做两件事，这将大大提高我们在任何领域的匹配率。

  1. 在匹配发生之前执行发票短语的清理和转换作为一种预处理（IE将公司变成CORP，删除撇号等）
  2. 编写一个比原生 Generic SnapMatch 更了解我们数据的自定义匹配函数。

谢谢！

4

1 回答 1

0

好的，最终没有办法通过脚本管理器入口点来做到这一点。这样做的原因是所有图像数据在进入脚本管理器之前都被解析和提取。当您进入管理器的提取阶段时，您有一个 XML 运行时文档，该文档表示输出文档的元结构，其中包含在输入之前提取“认为可能有用”的数据。提取的所有其他可能的“短语”和其他不适合字段或替代的数据类型都被“丢弃”。这意味着供应商名称或 DoKuStar 不感兴趣的类似名称，仍然无法使用任何代码机制进行搜索。

我需要解决的问题非常具体到我的特定域，并且是由 Oracle 组的策略间接引起的。供应商的名称被去除特殊字符并连接起来。基本上，它们只是与发票上的内容不符，因此 snapmatch 几乎毫无用处。

我创建了一个中间解决方案，用户可以直接更新本地 SnapMatch 数据库，可以说是“重命名供应商”。因此，我们的本地 SnapMatch 数据库将在我们进行更正时匹配发票上的内容，即使 Oracle 数据库不匹配。总而言之，不是针对编码方面的特定解决方案，但事实证明它是解决域问题的有效解决方案。

于 2013-02-05T21:33:29.967 回答