どの企業の典型的な調達プロセスにも、次のような複数のドキュメントが関連付けられています。 請求書、発注書、納品書など。このプロセスは、オーバーヘッドを削減するためのテクノロジーベースの改善の一貫した焦点となっています。 これらのドキュメントのデジタル化による大幅な最適化により、コストが削減され、ターンアラウンド タイムが短縮され、エラー率が減少しました。 この投稿では、特に発注書に焦点を当てて、これらの文書から OCR ベースのデータを取得する最新技術について概説します。
あまり詳しく説明しなくても、典型的な調達ワークフローは次のようになります。
- 購入者は注文書を生成します
- 仕入先が請求書を作成します
- 買い手が GRN / 注文を生成する 領収書 Note
これらのドキュメントに含まれる情報と構造が異なるため、これらの各ドキュメントのデータ取得プロセスと要件には微妙な違いがあります。 大きな違いは、誰がドキュメントを準備しているのか、そして結果として誰がドキュメントをデジタル化する必要があるのかということでもあります.
3ウェイマッチング
デジタル化の主な理由は、これらの文書がすべてを裏付け、取引の一貫したストーリーを伝える必要があるためです。 これらの 3 つのドキュメントの確証のプロセスは、3 ウェイ マッチングと呼ばれます。 スリーウェイ マッチングの必要性とプロセスは、マッチングを行うのが買い手か売り手かによって大きく異なります。
バイヤーの視点：
購入者は PO を生成し、 領収書 そして、ソフトウェアで簡単に調整できるこの情報を持っています。 一致する必要があります 送り状 注文書に 領収書. バイヤーはデジタル化する必要があります 送り状 他のドキュメントはすでに ERP システム内にあります。
バイヤーがスリーウェイ マッチングを実行する必要がある理由はさまざまです。
- 照合することにより、購入が承認されていることを確認する 請求書 および発注書付きの GRN
- ドキュメント間で照合することにより、正しい製品を確実に購入する
- 承認された正しい数量が調達され、配送されたことを確認します。
- 各製品に支払われた価格が承認されていることを確認する
- 同じ製品が異なるベンダーから調達される可能性があるため、正しいベンダーが選択され、正しいベンダーが最終的に支払われることを確認する
- ダウンストリームのデータ品質のために、在庫をGRNの数量と一致させる
売り手の視点：
売主は、 送り状 POと 領収書 請求書の情報と一致します。 売り手は、発注書をデジタル化し、ERP から生成された請求書を受け取る必要があります。
3ウェイマッチングの売り手のニーズ
- システムの在庫を指定して、購入注文を履行できるかどうかを確認する
- 要求された製品と一致するように出荷された商品を確保する
- 正しい顧客に要求された製品が送られたことを確認する
- 要求された製品が顧客に提供されるものであることを確認する
- 正しい数量が顧客に提供されるようにする
- POの価格の保証には、履行可能な粗利益があります。
注文書を自動化する AI ベースの OCR ソリューションをお探しですか? ナノネットを与える™ インテリジェントオートメーションプラットフォーム スピンして、発注書を自動操縦にしましょう!
手動3ウェイマッチングの問題
3ウェイマッチングの問題は、双方が契約の終わりに到達するためにかなり重要であるため、効率と精度が最も重要です。 ただし、これはさまざまな観点から見るとかなり高いプロセスコストです。
ドキュメントの追跡とエラーの人的コスト
- POが複数回改訂される場合は特に、面倒なプロセスです。 POの正しいバージョンを維持することは困難な場合があります。 正しく行わないと、複数回の支払いや余分なアイテムの配達などにつながる可能性があります。
- 頻繁なサプライヤ、バイヤーの間には、複数の同様のドキュメントとトランザクションがあります。 これらのトランザクションは消費される可能性があります。
- プロセスはスケーリングできません。 処理量が急激に変化する場合、最適な人材を維持することは困難です。 ほとんどの企業では、これらの部門の人員を増やして、量の急増を補っています
支払いまたは調達の遅延
- 文書のデータは手動で入力されます。 処理されるドキュメントの量が増えると、このプロセスはボトルネックになります
- 遅延は、配達/支払い/調達の遅延につながる可能性があります。 運転資金の高コストや原材料調達の遅れ等による収益の損失につながる
在庫エラー
- 在庫システムがこのプロセスと正しく統合されていない場合、在庫を誤って計算する高いコストが発生する可能性があります。 在庫過剰、注文の重複、在庫不足、収益の損失につながります。
3ウェイマッチングのエラー
このプロセスで発生するさまざまな異なるエラーがあります。 以下はいくつかの例です
ベンダーマッチングエラー
ベンダーの照合は、通常、ベンダー名と住所の XNUMX つに基づいて行われます。 同じ会社がさまざまな子会社やさまざまな事業部門を持ち、同様の発行を行う可能性があるため 請求書.
注文書の住所と 送り状 正しい住所とベンダー名が特定されていないと、マッチングに問題が生じる可能性があります。 また、明確にわかるように、請求書と PO の照合では、テキストの直接照合だけでは機能しません。
| 購入注文 | 送り状 | Status: |
|---|---|---|
| アクメ株式会社 | アクメ株式会社 | ワークス |
| アクメ株式会社 | Acme Inc.アフリカ | 失敗する |
| アクメ | Acme LLC。 | 失敗する |
| Acme LLC。 | Acme LLC。 砲兵師団 | 失敗する |
商品照合エラー
製品は、注文書と請求書で同じ名前を使用することはめったにないため、一致させるのが最も難しい項目です。 領収書. これがエラーの最大の原因である可能性が最も高いです。
エラーの原因は、同じ製品の異なるバージョン、サイズ、仕様、価格が異なることが原因である可能性があります。 製品に最近のアップデートがあった可能性があります。入手できないアイテムの代わりが提供されました。
| 購入注文 | 送り状 | Status: |
|---|---|---|
| タイレノール副鼻腔圧と痛み | タイレノール副鼻腔圧と痛み | ワークス |
| タイレノール | タイレノール副鼻腔圧と痛み | 失敗する |
| タイレノール副鼻腔圧と痛み | タイレノール®副鼻腔圧と痛み | 失敗する |
| タイレノールエクストラストレングス | タイレノールエクストラストレングス鎮痛剤＆解熱剤500mgカプレット | 失敗する |
| タイレノールエクストラストレングス鎮痛剤＆解熱剤500mgカプレット | タイレノールエクストラストレングス鎮痛剤＆解熱剤250mgカプレット | 失敗する |
数量一致エラー
製品が正しく一致していても、指定された数量の製品が入手できない場合などは、数量の一致にエラーが発生する可能性があります。通常、これらのXNUMXつのドキュメントの間にはタイムラグがあるため、これは通常、注文書とGRNの間にも当てはまります。
価格照合エラー
製品の購入ライフサイクル全体で価格が変更された場合、または製品が更新または置換された場合、このエラーが発生する可能性があります。
複製ドキュメント
同じベンダーから同様の製品を頻繁に購入する場合、非常によく似た複数のドキュメントが存在する可能性があります。 POへの参照番号が請求書および請求書またはPOのGRNに記載されていない場合は、ドキュメントの不一致の重大な範囲があります。
注文書のデジタル化
注文書からすべての関連データを収集するには、次のフィールドを抽出する必要があります。
抽出されるフィールドの共通リスト（注文書全体で、名前が異なる場合があります）：
| 請求先住所 | 支払条件 | 小計 |
| バイヤー名 | PO番号 | 件名 |
| ご担当者名 | プロダクト | トータル |
| 通貨 | 発注日 | 単価 |
| に配信 | 数量 | 業者名 |
| 期日 | 要求No |
現在の解決策とその問題
テンプレート+テキストマッチング
これには、特定の情報を探すために正確な領域を定義することが含まれます。 したがって、日付を抽出しようとしていて、形式がドキュメント全体でまったく同じで、日付がドキュメント内のまったく同じ場所にある場合を考えてみましょう。 日付のドキュメントで検索する領域を定義します。
ここにプロセスがあります：
- ドキュメントを画像に変換します
- サンプル文書を差し上げます
- 日付が見つかった領域をマークします（ドキュメントは左上隅が（0,0）である座標系として表示されます）。日付の対象領域である（200,300）から（350,450）をマークします。
- 新しいドキュメントがある場合は、（200,300）から（350,450）に移動し、そこにテキストを抽出します。
これまで、これはこの問題を解決するための最も一般的なアプローチのXNUMXつでした。 これにはさまざまな理由があります。
- ソフトウェアのシンプルさと実装。 有能なプログラマーはXNUMX日足らずでこのソリューションを作成できます
- ソリューションがどのように機能するかは不確かではありません。ドキュメントが完全に同じ形式であれば、完全に機能します。
- データを抽出するために非常に限られた計算リソースが必要です
ただし、この方法がいかに初歩的であるかを考えると、いくつかの非常に明白な課題があります。
- ドキュメントに少しでも違いがあると機能しません
- バイヤーがフォーマットを更新しても機能しません
- 購入者ごとに、セットアップが必要な新しいフォーマットがあります
- スキャンしたドキュメントでは機能しません
OCR + NLP +テキストマッチング
OCR + NLPは、ドキュメントからデータを抽出する新しい手法です。 OCRはかなりよく研究された問題であり、ドキュメントからテキストを抽出することはほとんどの場合機能します。 次のステップは、ドキュメントから抽出されたすべての未加工テキストを取得し、ドキュメント内の個々のテキストのそれぞれを解析することです
NLP内には、この問題を解決するために使用できるさまざまな手法があります。
- 正規表現（正規表現）
日付を抽出するには、正規表現は次のようになります。
^(?:(?:31(/|-|.)(?:0?[13578]|1[02]|(?:Jan|Mar|May|Jul|Aug|Oct|Dec)))1|(?:(?:29|30)(/|-|.)(?:0?[1,3-9]|1[0-2]|(?:Jan|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec))2))(?:(?:1[6-9]|[2-9]d)?d{2})$|^(?:29(/|-|.)(?:0?2|(?:Feb))3(?:(?:(?:1[6-9]|[2-9]d)?(?:0[48]|[2468][048]|[13579][26])|(?:(?:16|[2468][048]|[3579][26])00))))$|^(?:0?[1-9]|1d|2[0-8])(/|-|.)(?:(?:0?[1-9]|(?:Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep))|(?:1[0-2]|(?:Oct|Nov|Dec)))4(?:(?:1[6-9]|[2-9]d)?d{2})$
抜粋01/02/2020
情報源： https://stackoverflow.com/questions/15491894/regex-to-validate-date-format-dd-mm-yyyy
正規表現ベースのソリューションの欠点は、新しい各フォーマットを個別にプログラムする必要があることです。 新しいフォーマットがある場合は、正規表現に追加する必要があります。 特定の日付が、注文の日付または日付による納期であるかどうかは識別しません。
2. NER（名前付きエンティティの認識）
NERを使用してフィールドタイプを抽出するには
results = stanford_ner_tagger.tag(article.split()) print('Original Sentence: %s' % (article)) for result in results: tag_value = result[0] tag_type = result[1] if tag_type != 'O': print('Type: %s, Value: %s' % (tag_type, tag_value))
版画Type: DATE, Value: 01/02/2020
情報源： https://towardsdatascience.com/named-entity-recognition-3fad3f53c91e
NERベースの抽出の欠点は、明確に定義されたタイプではうまく機能しますが、住所や非標準形式であるものなどのさまざまなタイプでは失敗することです。 それは日付、通貨、電話番号などでうまく機能します。名前とエンティティで時々機能します。 これは、注文日または日付によって、配達日がわからないという同様の問題に悩まされています。
3.ベンダー/バイヤーにソフトウェアを使用してドキュメントを送信するように強制する
ベンダーまたはバイヤーが取引に大きな影響力を持っている場合、相手がソフトウェアを使用してドキュメントを提出するように強制することができます。 これにより、ほとんどの問題が取り除かれ、ベンダー全体の責任が軽減されます。ドキュメントのデジタル化は必要ありません。 ただし、これにはユビキタスではないという明らかな問題があり、相手がソフトウェアと対話する必要があります。 少数の3者がこのプロトコルに従わない場合でも、それを既存のシステムに追加するにはかなりの労力が必要です。
深層学習
ディープラーニングテクノロジーは、最近、データの抽出と、より重要なことに、より良い予測につながる可能性のある機能の抽出において、かなり進歩しました。
グラフ畳み込みニューラルネットワーク（GCN）を使用して、これらのドキュメントからデータを抽出できます。 GCNにはさまざまな機能を提供しています。それぞれの機能を使用して、正しい情報を抽出できます。
それは2つのステップに分けることができます：
1.特徴抽出
各テキストブロックからさまざまな機能を抽出します。
a）テキスト機能
b）視覚的特徴
c）ロケーション機能
d）サイズの特徴
e）フォント機能
2.グラフの作成
これらの機能は、テキストのブロックごとに作成され、グラフが作成されます。 各テキストブロックには、隣接する機能が渡されます。 各テキストブロックに対して作成されたグラフ機能およびその他の機能を使用して、対象のフィールドのXNUMXつまたはなしとして分類されます。
文書照合
ドキュメントを一致させるには、ディープラーニングも優れたソリューションであり、各ドキュメントタイプから抽出されたフィールドを解析して、ドキュメントが一致した場合に最終的な予測を行うことができます。
ディープラーニングの問題
抽出される情報にはXNUMXつのクラスがあります
1.キー値（PO番号、日付など）の問題
- キーと値のペアを識別します。 それらはフォーマット間で均一に配置されておらず、何人の隣人を見通すのか不明確です。
- 複数の言語を考慮に入れる。
- 特定のキーをトレーニングするのに十分なデータがない（クラスの不均衡）
2.テーブル値の問題
- ボックスをテーブルとして分類する
- 複数のテーブルがあるページでテーブルが見つからない
- XNUMXつの閉じる列をマージする
- ページの境界線をテーブルの境界線として誤って解釈する
3.その他の問題
- 回転とトリミング
- 画質が悪い
- データドリフト
ナノネットの使用
発注書でOCRにディープラーニングを使用する際の問題の解決
Nanonets APIの使用一致するドキュメントに必要なすべての必要なキーを自動的に抽出できます。 ドキュメントをアップロードして、抽出したすべてのフィールドを選択した形式で返すだけです。
私たちは上記の問題のほとんどに取り組みますので、ホイールの再発明に時間を費やす必要はありません。
キーと値のペア：
1.キーと値のペアを特定します。 それらはフォーマット間で均一に配置されていません。
GCN実装を使用すると、ドキュメント全体のキーを解析できます。 GCNの実装には、適切な近傍検索を見つけるための最適化が含まれており、モデルがそれぞれに属するキーを正しく解釈するために、機能の爆発とコンテキストの欠如との間の最良のトレッドオフを取得します
2.複数の言語を考慮に入れる。
私たちのモデルは、言語にとらわれないテキスト埋め込みでトレーニングされています。 これは、「請求書」と「Faktura」（ドイツ語の請求書）およびचलाना（ヒンディー語の請求書）の単語の埋め込みがすべて同じ特徴スペースにマッピングされるように、特徴スペースを作成することによって実現されます。 したがって、テキスト機能は言語に依存せず、モデルを言語ごとにトレーニングする必要はありません。
3.特定のキー（クラスの不均衡）をトレーニングするのに十分なデータがない
この問題を軽減するためにモデルがトレーニングされている財務ドキュメントの大規模なコーパスがあります。
テーブル類
1.ボックスをテーブルとして分類する
さまざまな形式と設定でさまざまなテーブルを識別できる堅牢な分類子を作成しました。 これは、視覚的機能とレイアウト機能を組み合わせて使用し、テキストベースの機能を使用してテーブルの構造を識別します。
2.複数のテーブルがあるページでテーブルが見つからない
ページ全体で異なるテーブル構造のそれぞれを識別したら、構造がマージするのに十分類似しているかどうか、および前のページのテーブルが不完全でXNUMXつのテーブルをマージするかどうかを決定するかどうかを決定するマージロジックがあります。
3. XNUMXつの閉じる列をマージする
視覚的特徴のみに依存している場合、空間ベースの分離を識別することが難しいため、これは問題になります。 ただし、視覚的なテキストと位置に基づく機能を含めることで、列に含まれるデータの種類が新しい列と呼ばれるほど異なる場所を特定することが可能になります。
4.ページの境界線をテーブルの境界線として誤って解釈する
上記と同様に、この問題は、さまざまな機能を使用して、特定の構造がテーブルであるかページ境界であるかを判別することで解決されます。
その他の問題
1.回転とトリミング
ドキュメントのエッジを特定し、ドキュメントの向きを正しく設定するための前処理ステップの一部として、回転およびトリミングモデルを実装しました。 これは、オブジェクト検出モデルに類似したモデルを使用して、目的関数が修正され、オブジェクト検出問題の標準である4点ではなく、2コーナーが識別されます。 これは、回転とトリミングの両方を解決します
2.にじみと質の悪いドキュメントの品質
特定の品質しきい値を超えるドキュメントのみを受け入れる前処理パイプラインの一部として配置された品質モデルがあります。 これは、良い品質と悪い品質の両方を持つ多数のドキュメントでトレーニングされた単純な画像分類モデルであるバイナリ分類子です。 ドキュメントキャプチャパイプラインでは、ドキュメントが必要な品質基準を満たしていない場合は早期に拒否され、再キャプチャまたは手動処理のために送信できます。
2.データドリフト
モデルが単一のベンダーまたは単一のリージョンからのデータのみに公開されている場合、データのドリフトは問題です。 モデルが歴史的にさまざまな異なるベンダー、地域産業などでトレーニングされている場合、すでにこれらの差異にさらされているため、データのドリフトの可能性は大幅に減少します。
POのデジタル化を開始し、 請求書 ナノネットで今 – 1クリックPOデジタル化:
参考文献
アップデート1：
注文書からの情報の抽出および自動化のための OCR の使用に関する資料をさらに追加
更新2: PO からデータを抽出するモデルの精度が大幅に向上しました。
デモをセットアップする
デモをセットアップして、Nanonetsがこの問題の解決にどのように役立つかを学ぶ
