ベンダーや部署のデータベースの準備
ODBC 互換データベース
ABBYY FlexiCapture for Invoicesでは、データセットを ODBC 互換データベース(詳細は「ベンダーや部署のデータベースの接続」を参照)に接続して一度にデータをロードしたり、定期間隔で外部データベースのデータでデータセットを更新(詳細はデータセットの更新)。
したがって最初のステップは、Microsoft Access、Microsoft SQL Server、Oracle などの ODBC 互換データベースにある外部データを導入することです。
外部データベースのレコードの重複を排除する
インボイスでベンダー(または部署)を検出した結果として値を取得するフィールドを、外部のベンダー(または部署)データベースで決定することが重要です。このフィールド(またはフィールドのセット)はデータセットの一意キーになります。
部署データセットの固有キーは、IDフィールド(詳細→BusinessUnits データセットの列)。ユーザーの観点からは、このフィールドはABBYY FlexiCapture for Invoicesが、特定インボイスの発行先部署の検出結果となります。
ベンダーデータセットの固有キーは、特定のインボイスを発行したベンダーをABBYY FlexiCapture for Invoicesが検出した結果として外部情報システムに渡される値でなければなりません。ベンダー表が使用される場合、その固有キーはデータセットのIDフィールドに関連付けられている必要があります。インボイスでベンダーが検出されると、この値は外部情報システムに渡されます。
社内のさまざまな部署に発行されたインボイスを 1 つのプロジェクトで処理しようと計画し、部署ごとに独自のベンダーデータベースがある場合は、各部署の固有キーをベンダーデータセットのBusinessUnitId列Vendors各ベンダーのキーをベンダーデータセットのID列Vendorsデータセットに存在するかどうかチェックします。したがって、ベンダーが検出された時に外部情報システムに渡されるベンダーレコードの固有キーは、IDとBusinessUnitIdの値のペアになります(詳細はこちら→Vendors データセットの列)。
以下の説明では部署の場合と状況がまったく同じであるため、ベンダー検出だけを考慮します。
レコードの固有キーによって、ベンダー検出で使用される固有の組み合せが決定します。外部情報システムはほとんどの場合、インボイスで指定され、ベンダー検出で使用されるさらに多くのパラメータに依存しながらベンダーレコードが固有であると見なします。
たとえば、外部の情報システムはIDMCN_USDを受け取ることを期待することがあります。これは、My Company Name Ltd.が請求書を米ドルで発行した場合、または同じ会社がユーロで請求書を発行した場合にMCN_EURIDが受け取れると考える場合です。たとえ通貨がインボイスに記載されていても(MCN_USDを返すタイミングとMCN_EURを返すタイミングは区別できます)通貨はベンダー検出では使用されません。
したがって、ベンダー検出のメカニズムは、MCN_USDとMCN_EUR。
このような場合は、MCN_USDとMCN_EURの両方に対応して、ベンダーが検出されたときに返されるMCN識別子を作成します。次に、対象となるインボイスの通貨に応じて、MCN_USDとMCN_EURのいずれかを選ぶルールを文書定義に作成できます。
一般的に言えば、ベンダーレコードの固有の識別子には、会社名、会社住所、税金 ID (VATID、国の VATID など)、国際銀行口座番号(IBAN)など、ベンダー検出で使用されるパラメータの固有セットが必要です(詳細「Vendors データセットの列」を参照)。ベンダー検出のメカニズムは、その場合のみインボイスの適切なベンダーレコードを選択できるようになります。
注:次に、プログラムは追加フィールドをキャプチャし、文書定義のルールを使って、必要な値を取得できるよう結果を微調整します。
ベンダー検出で使用される同一の(または混同しやすい)パラメータのセットが複数の固有キーに対応している場合、プログラムは唯一のキーを選択できず、ベンダー検出が偶発的になり品質が低下します。
その理由は以下のとおりです。プログラムがインボイスに印刷されているデータを使ってMy Company Name確実に検出できるにもかかわらず、インボイスのデータに対応するレコードが複数(MCN1,MCN2, ...MCNN)データセットにある場合、他のレコードの利益となるよう、プログラムはそのインボイスデータについて好ましくはないもののそれほど多くのレコードとはならないマッチングを判断します。これは最終的に、ベンダーが不正確に検出される原因となります。
したがって、外部データベースで重複を排除し、ベンダー検出で使用されるレコードフィールドの固有の値セットについて、その外部データベースの列に固有の値が与えられるようにすることが重要です。
データセットに接続すると、データセットの固有キーに関連付けられる列と同じ値を持つ行が、データセットの 1 つのレコードへ自動的に格納されます。
データセットの複数の値を持つ列
データセットには、会社レコードの論理列 1 つにつき複数の値を保存させることができます。
会社の名前や住所といった会社パラメータはインボイスによって異なる(「My Company Name」と「MCN Ltd.」など)ため、複数値の保存が必要ですが、会社を確実に検出できるようにするためには、データセットのテキストがインボイス画像からキャプチャされたテキストとなるべくマッチングさせる必要があります。また、会社は複数の銀行口座やその他の属性を持つこともあります。
注:データセット 複数値の列は、異なる方法で記述された同じ情報を格納するために使用するためのものですから、ご注意ください。たとえば、「Karl Marx Street」と「K. Marx str.」といった具合です。同じ住所をふたつの異なる方法で表記しています。ただし、ロンドンとベルリンの弊社支店では、ふたつの別々の記録を保持しています。
複数値の列の値は、外部データベースから取得できます(例:ベンダーの表に各会社の銀行の詳細が1〜5つ含まれる場合)。またデータキャプチャ中にユーザが追加する場合もあります(例:オペレータが外部データベースでは不明なものの、企業名の一般的に使用される略称をデータセットに追加できます)。
データセットは列を非正規化します。つまり、以下のような形式でデータを保存します:
データセットの固有キー* | Name1 | Name2 | ... | NameN | ... |
1 | My Company Name | MCN Ltd. | ... | <empty value> | ... |
2 | The Second Company, Inc. | S-Company | ... | <empty value> | ... |
... | ... | ... | ... | ... | ... |
レコードの論理フィールドの 1 つ、たとえば名前の場合は、複数の列がデータセットに作成されます。論理フィールドに入る可能性がある値はすべてこの列に保存されます。そのため、名前は、「複雑な列」と呼ばれます。
外部データベースからのテーブル(またはビュー)に接続する時は、上述した列の非正規化のほか、さらに一般的な行の非正規化も可能です。後者の場合、データセットで 1 つのレコードのパラメータに結合されなければならない行は、データセットの固有キーに対応する列と同じ値を持っていることが必要です。例:
データセットで固有キーに対応する列 | 名前 | ... |
1 | My Company Name | ... |
1 | MCN Ltd. | ... |
... | ... | ... |
N | <empty value> | ... |
2 | The Second Company, Inc. | ... |
2 | S-Company | ... |
... | ... | ... |
N | <empty value> | ... |
... | ... | ... |
* 部署データセットの固有のキーはIdフィールドです。仕入先データセットの固有のキーは、設定に応じてIDフィールド、またはフィールドIDと部署のペアになります。(詳細はこちら→Vendors データセットの列)
12.04.2024 18:16:25