JP2023081199A - 情報処理装置、情報処理方法、プログラム、情報処理システム - Google Patents

Abstract

【課題】帳票同士をより容易に対応付けることを目的とする。【解決手段】記憶部に格納された第一の帳票情報の中から、第二の帳票情報と対応付ける第一の帳票情報を特定する情報の入力を受け付ける受付画面を端末装置に表示させる表示制御部と、前記特定する情報に基づき特定された第一の帳票情報を、前記第二の帳票情報と対応付ける対応付け部と、を有する情報処理装置である。【選択図】図１４

Description

本発明は、情報処理装置、情報処理方法、プログラム、情報処理システムに関する。

従来では、２つのドキュメントを突き合わせる際（突合）に、視覚的レイアウトが類似したドキュメント同士を突き合わせる技術が知られている。

例えば、請求書と注文書等のように、２つの帳票を突合する場合、２つの帳票を特定する情報に基づき両者を対応付ける必要がある。従来では、この対応付けを、突合作業の担当者による目視や、既存のソフトウェアの機能等によって行っており、突合作業が繁雑になる。

開示の技術は、帳票同士をより容易に対応付けることを目的とする。

開示の技術は、記憶部に格納された第一の帳票情報の中から、第二の帳票情報と対応付ける第一の帳票情報を特定する情報の入力を受け付ける受付画面を端末装置に表示させる表示制御部と、前記特定する情報に基づき特定された第一の帳票情報を、前記第二の帳票情報と対応付ける対応付け部と、を有する情報処理装置である。

帳票同士をより容易に対応付けることができる。

第一の実施形態の取引管理システムのシステム構成の一例を示す図である。 取引管理装置のハードウェア構成の一例を示す図である。 端末装置のハードウェア構成の一例を示す図である。 注文先管理データベースの一例を示す図である。 注文書管理データベースの一例を示す図である。 請求書管理データベースの一例を示す図である。 突合管理データベースの一例を示す図である。 取引管理システムに含まれる各装置の機能を説明する図である。 取引管理システムの動作を説明する第一のシーケンス図である。 取引管理装置の処理を説明する第一のフローチャートである。 注文書情報の確認画面の一例を示す図である。 取引管理装置の処理を説明する第二のフローチャートである。 請求書情報の確認画面の一例を示す図である。 取引管理システムの動作を説明する第二のシーケンス図である。 買い手端末の表示例を示す第一の図である。 買い手端末の表示例を示す第二の図である。 買い手端末の表示例を示す第三の図である。 買い手端末の表示例を示す第四の図である。 買い手端末の表示例を示す第五の図である。 買い手端末の表示例を示す第六の図である。 取引管理システムのシステム構成の別の例を示す図である。

以下に、図面を参照して、実施形態について説明する。図１は、取引管理システムのシステム構成の一例を示す図である。

本実施形態の取引管理システム１００は、取引管理装置２００と、端末装置３００とを含む。取引管理装置２００と端末装置３００とは、ネットワークを介して通信が可能である。また、本実施形態の取引管理装置２００は、端末装置４００と、ネットワークを介して通信を行う。

本実施形態の取引管理装置２００は、端末装置３００において作成された帳票に含まれる帳票情報を格納する。また、取引管理装置２００は、この帳票に対して発行された帳票の帳票情報の入力を受け付けると、格納されている帳票情報と、入力された帳票情報とを対応付けて管理する。

以下の説明では、端末装置３００から入力された帳票情報を第一の帳票情報と呼び、第一の帳票情報を含む帳票を第一の帳票と呼び、第一の帳票情報を含む帳票画像データを第一の帳票画像データと呼ぶ。

また、以下の説明では、第一の帳票と対応して発行された帳票を第二の帳票と呼び、第二の帳票を示す帳票画像データを第二の帳票画像データと呼び、第二の帳票に含まれる帳票情報を第二の帳票情報と呼ぶ。

本実施形態の取引管理装置２００は、端末装置３００から、第二の帳票情報の入力が行われると、既に格納されている第一の帳票情報のうち、第二の帳票情報と対応する第一の帳票情報を選択させるための画面を、端末装置３００に表示させる。そして、取引管理装置２００は、端末装置３００において、第一の帳票情報が選択されると、選択された第一の帳票情報と、第二の帳票情報とを対応付けて、両者の突合処理を行う。

このように、本実施形態では、第二の帳票情報の入力を受け付けて、第二の帳票情報と対応する第一の帳票情報の選択させるための画面を表示させることで、第一の帳票と第二の帳票との対応付けを行わせる。このため、本実施形態では、２つの帳票の帳票情報を目視で確認する等の作業が不要であり、帳票同士の対応付けを容易に行わせることができる。また、本実施形態では、帳票同士の対応付けが容易になるため、突合作業の作業負荷も軽減することができる。

本実施形態の端末装置３００は、主に、取引管理装置２００を介して注文を行う注文元によって利用される端末装置である。言い換えれば、端末装置３００は、商品等を購入する買い手側によって利用される端末装置である。以下の説明では、端末装置３００を買い手端末３００と表現する場合がある。

なお、本実施形態の注文元とは、例えば、各種の注文先に対して注文を行う事業者である。なお、本実施形態の事業者とは、個人であってもよいし、企業や法人等の組織であってもよい。以下の実施形態の説明では、事業者を、テナントと表現する場合がある。

本実施形態の端末装置４００は、取引管理システム１００の外部の装置であり、主に、商品等の販売者等によって利用される端末装置である。言い換えれば、端末装置４００は、商品等を販売する売り手側によって利用される端末装置である。以下の説明では、端末装置４００を売り手端末４００と表現する場合がある。

本実施形態の第一の帳票とは、例えば、商品の注文書などである。この場合、第一の帳票情報は、注文の内容を示す注文書情報となる。また、第一の帳票が注文書である場合、第一の帳票に対応する第二の帳票とは、この注文書に対応した請求書である。この場合、第二の帳票情報は、請求の内容を示す請求書情報となり、第二の帳票画像データは、請求書画像データとなる。また、例えば、第一の帳票は注文書であり、第二の帳票は納品書であってもよいし、第一の帳票は見積書であり、第二の帳票は注文書であってもよい。

以下の説明では、注文書を第一の帳票の一例とし、請求書を第二の帳票の一例として説明する。

また、本実施形態の端末装置３００は、主に、取引管理装置２００を介して注文を行う注文元によって利用される端末装置である。言い換えれば、端末装置３００は、商品等を購入する買い手側によって利用される端末装置である。以下の説明では、端末装置３００を買い手端末３００と表現する場合がある。

なお、本実施形態の注文元とは、例えば、各種の注文先に対して注文を行う事業者である。なお、本実施形態の事業者とは、個人であってもよいし、企業や法人、団体等の組織であってもよい。以下の実施形態の説明では、事業者を、テナントと表現する場合がある。

本実施形態の端末装置４００は、取引管理システム１００の外部の装置であり、主に、商品等の販売者等によって利用される端末装置である。言い換えれば、端末装置４００は、商品等を販売する売り手側によって利用される端末装置である。以下の説明では、端末装置４００を売り手端末４００と表現する場合がある。

本実施形態の取引管理装置２００は、注文先管理データベース２１０、注文書管理データベース２２０、請求書管理データベース２３０、突合管理データベース２４０、取引管理部２６０を有する。

注文先管理データベース２１０は、注文先に関する注文先情報が格納される。言い換えれば、注文先管理データベース２１０は、売り手側に関する情報が格納される。注文書管理データベース２２０は、注文書管理情報が格納される。

本実施形態の注文書管理情報は、注文書情報を管理するための情報であり、注文書情報を含む。本実施形態の注文書情報は、買い手端末３００において作成された注文書画像データに対する帳票認識処理によって抽出されてもよい。

帳票認識処理は、取引管理装置２００において実行されてもよい。また、注文書情報は、例えば、取引管理装置２００と通信が可能な画像形成装置等において、注文書に対するＯＣＲ（Optical character recognition）を行った結果として取得されてもよい。

請求書管理データベース２３０は、請求書管理情報が格納される。

本実施形態の請求書管理情報は、請求書情報を管理するための情報であり、請求書情報を含む。本実施形態の請求書情報は、買い手が売り手から受領した請求書から抽出された情報であり、本実施形態の請求書は、買い手が発行した注文書に対して、売り手が発行して買い手に渡すものである。

請求書情報は、取引管理装置２００において、請求書画像データに対して帳票認識処理を実行することで取得されてもよい。また、請求書情報は、画像形成装置等によるＯＣＲ処理を行った結果として取得されてもよい。

突合管理データベース２４０は、注文書情報と請求書情報とを突合した結果を示す情報等が格納される。

取引管理部２６０は、買い手が受領した請求書の請求書情報と、買い手が発行した注文書の注文書情報との突合を行う際に、請求書情報と注文書情報とを対応付けるための画面を、買い手端末３００に表示させる。言い換えれば、取引管理部２６０は、請求書管理情報と注文書管理情報とを対応づける。

具体的には、取引管理部２６０は、買い手端末３００から請求書情報と注文書情報との突合指示を受け付けると、買い手端末３００に対し、突合の対象となる請求書情報と対応する注文書情報を選択するための画面を表示させる。

本実施形態では、このような画面を表示させることで、例えば、請求書と注文書の両方又は何れか一方が紙媒体である場合等でも、請求書情報と注文書情報とを取引管理システム１００内で対応付けることができる。つまり、本実施形態によれば、帳票同士を容易に対応付けることができる。さらに、本実施形態では、関連する帳票同士の対応付けを容易にできるため、突合作業における負荷も軽減される。

なお、突合作業とは、発注の内容と、発注と対応した受注の内容とを照らし合わせ、発注の内容と受注の内容とが一致しているか否かを確認する作業である。

また、図１の例では、注文先管理データベース２１０、注文書管理データベース２２０、請求書管理データベース２３０、突合管理データベース２４０は、取引管理装置２００に設けられるものとしたが、これに限定されない。これらの各データベースは、一部又は全部が、他の装置に設けられていてもよい。また、取引管理装置２００は、複数台の情報処理装置によって実現されてもよい。

次に、本実施形態の取引管理装置２００のハードウェア構成について説明する。

図２は、取引管理装置のハードウェア構成の一例を示す図である。取引管理装置２００は、コンピュータによって構築されており、図２に示されているように、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、ＨＤ２０４、ＨＤＤ(Hard Disk Drive)コントローラ２０５、ディスプレイ２０６、外部機器接続Ｉ／Ｆ(Interface)２０８、ネットワークＩ／Ｆ２０９、バスラインＢ１、キーボード２１１、ポインティングデバイス２１２、ＤＶＤ－ＲＷ(Digital Versatile Disk Rewritable)ドライブ２１４、メディアＩ／Ｆ２１６を備えている。

これらのうち、ＣＰＵ２０１は、取引管理装置２００全体の動作を制御する。ＲＯＭ２０２は、ＩＰＬ等のＣＰＵ２０１の駆動に用いられるプログラムを記憶する。ＲＡＭ２０３は、ＣＰＵ２０１のワークエリアとして使用される。ＨＤ２０４は、プログラム等の各種データを記憶する。ＨＤＤコントローラ２０５は、ＣＰＵ２０１の制御にしたがってＨＤ２０４に対する各種データの読み出し又は書き込みを制御する。ディスプレイ２０６は、カーソル、メニュー、ウィンドウ、文字、又は画像などの各種情報を表示する。外部機器接続Ｉ／Ｆ２０８は、各種の外部機器を接続するためのインターフェースである。この場合の外部機器は、例えば、ＵＳＢ(Universal Serial Bus)メモリやプリンタ等である。ネットワークＩ／Ｆ２０９は、通信ネットワークを利用してデータ通信をするためのインターフェースである。バスラインＢ１は、図２に示されているＣＰＵ２０１等の各構成要素を電気的に接続するためのアドレスバスやデータバス等である。

また、キーボード２１１は、文字、数値、各種指示などの入力のための複数のキーを備えた入力手段の一種である。ポインティングデバイス２１２は、各種指示の選択や実行、処理対象の選択、カーソルの移動などを行う入力手段の一種である。ＤＶＤ－ＲＷドライブ２１４は、着脱可能な記録媒体の一例としてのＤＶＤ－ＲＷ２１３に対する各種データの読み出し又は書き込みを制御する。なお、ＤＶＤ－ＲＷに限らず、ＤＶＤ－Ｒ等であってもよい。メディアＩ／Ｆ２１６は、フラッシュメモリ等の記録メディア２１５に対するデータの読み出し又は書き込み（記憶）を制御する。

次に、図３を参照して、本実施形態の買い手端末３００のハードウェア構成について説明する。図３は、端末装置のハードウェア構成の一例を示す図である。本実施形態の端末装置３００は、ＣＰＵ３０１、ＲＯＭ３０２、ＲＡＭ３０３、ＥＥＰＲＯＭ３０４、ＣＭＯＳセンサ３０５、撮像素子Ｉ／Ｆ３０６、加速度・方位センサ３０７、メディアＩ／Ｆ３０９、ＧＰＳ受信部３１１を備えている。

これらのうち、ＣＰＵ３０１は、端末装置３００全体の動作を制御する演算処理装置である。ＲＯＭ３０２は、ＣＰＵ３０１やＩＰＬ等のＣＰＵ３０１の駆動に用いられるプログラムを記憶する。ＲＡＭ３０３は、ＣＰＵ３０１のワークエリアとして使用される。ＥＥＰＲＯＭ３０４は、ＣＰＵ３０１の制御にしたがって、スマートフォン用プログラム等の各種データの読み出し又は書き込みを行う。ＲＯＭ３０２、ＲＡＭ３０３、ＥＥＰＲＯＭ３０４は、端末装置３００の記憶装置の一例である。

ＣＭＯＳ(Complementary Metal Oxide Semiconductor)センサ３０５は、ＣＰＵ３０１の制御に従って被写体（主に自画像）を撮像して画像データを得る内蔵型の撮像手段の一種である。なお、ＣＭＯＳセンサではなく、ＣＣＤ(Charge Coupled Device)センサ等の撮像手段であってもよい。

撮像素子Ｉ／Ｆ３０６は、ＣＭＯＳセンサ３０５の駆動を制御する回路である。加速度・方位センサ３０７は、地磁気を検知する電子磁気コンパスやジャイロコンパス、加速度センサ等の各種センサである。メディアＩ／Ｆ３０９は、フラッシュメモリ等の記録メディア３０８に対するデータの読み出し又は書き込み（記憶）を制御する。ＧＰＳ受信部３１１は、ＧＰＳ衛星からＧＰＳ信号を受信する。

また、端末装置３００は、遠距離通信回路３１２、遠距離通信回路３１２のアンテナ３１２ａ、ＣＭＯＳセンサ３１３、撮像素子Ｉ／Ｆ３１４、マイク３１５、スピーカ３１６、音入出力Ｉ／Ｆ３１７、ディスプレイ（表示装置）３１８、外部機器接続Ｉ／Ｆ(Interface)３１９、近距離通信回路３２０、近距離通信回路３２０のアンテナ３２０ａ、及びタッチパネル３２１を備えている。

これらのうち、遠距離通信回路３１２は、通信ネットワークを介して、他の機器と通信する回路である。ＣＭＯＳセンサ３１３は、ＣＰＵ３０１の制御に従って被写体を撮像して画像データを得る内蔵型の撮像手段の一種である。撮像素子Ｉ／Ｆ３１４は、ＣＭＯＳセンサ３１３の駆動を制御する回路である。マイク３１５は、音を電気信号に変える内蔵型の回路である。スピーカ３１６は、電気信号を物理振動に変えて音楽や音声などの音を生み出す内蔵型の回路である。音入出力Ｉ／Ｆ３１７は、ＣＰＵ３０１の制御に従ってマイク３１５及びスピーカ３１６との間で音信号の入出力を処理する回路である。

ディスプレイ３１８は、被写体の画像や各種アイコン等を表示する液晶や有機ＥＬ(Electro Luminescence)などの表示手段の一種である。外部機器接続Ｉ／Ｆ３１９は、各種の外部機器を接続するためのインターフェースである。近距離通信回路３２０は、ＮＦＣ(Near Field Communication)やＢｌｕｅｔｏｏｔｈ（登録商標）等の通信回路である。タッチパネル３２１は、利用者がディスプレイ３１８を押下することで、端末装置３００を操作する入力手段の一種である。ディスプレイ３１８は、端末装置３００の有する表示部の一例である。利用者は、例えば個人またはテナントの場合は当該事業者における従業員等である。

なお、本実施形態の端末装置３００は、例えば、取引管理装置２００と同様の機能構成を有する情報処理装置であってもよい。

次に、図４乃至図８を参照して、取引管理装置２００の有する各データベースについて説明する。図４は、注文先管理データベースの一例を示す図である。

本実施形態の注文先管理データベース２１０は、例えば、テナント毎に設けられている。また、本実施形態の注文先管理データベース２１０は、情報の項目として、名称、住所、電話番号、メールアドレス、担当者名等を含み、これらの項目は、テナントＩＤ（テナントの識別情報）及びテナント名と対応付けられている。

本実施形態では、注文先管理データベース２１０において、名称、住所、電話番号、メールアドレス、担当者名等の項目の値を含む情報を、注文先情報と表現する場合がある。テナントＩＤ及びテナント名は、テナントを特定するための情報である。項目「名称」の値は、取引先（請求先）の名称を示し、項目「住所」、「電話番号」、「メールアドレス」、「担当者名」のそれぞれの値は、請求先の住所、電話番号、メールアドレス、取引を担当する担当者の名称を示す。

なお、注文先情報に含まれる情報の項目は、図４に示す例に限定されない。注文先情報に含まれる情報の項目は、図４に示す項目が全て含まれなくても良いし、図４に示す項目以外の項目が含まれてもよい。

本実施形態の注文先情報は、取引管理装置２００が、買い手端末３００からの入力を受け付けると、注文先管理データベース２１０に格納される。

図５は、注文書管理データベースの一例を示す図である。本実施形態の注文書管理データベース２２０は、注文先管理データベース２１０と同様に、テナント毎に設けられてよい。

注文書管理データベース２２０は、情報の項目として、注文書番号、対応請求書番号、確認状態、帳票ステータス、注文先、合計金額、注文日、情報ステータス、帳票画像パス、明細情報等を含み、各項目は、テナント名と対応付けられている。なお、本実施形態では、テナント名の代わりに、テナントを識別するためのテナントＩＤを用いてもよい。

また、注文書管理データベース２２０では、項目「注文書番号」とその他の項目とが対応付けられている。本実施形態では、注文書管理データベース２２０において、項目「注文書番号」の値と、その他の項目の値とを含む情報を、注文書管理情報と呼ぶ。

また、注文書管理情報において、項目「対応請求書番号」、「確認状態」、「帳票ステータス」、「情報ステータス」等は、注文書情報を管理するための情報の項目であって、注文書情報に含まれなくてもよい。

項目「注文書番号」の値は、注文書、注文書情報及び注文書管理情報を特定するための帳票識別情報である。言い換えれば、項目「注文書番号」の値は、第一の帳票情報を特定するための識別情報である。

項目「対応請求書番号」の値は、注文書番号によって特定される注文書情報と対応する請求書情報を含む請求書を特定するための識別情報である。言い換えれば、項目「対応請求書番号」の値は、帳票（請求書）を特定するための帳票識別情報である。言い換えれば、項目「対応請求書番号」の値は、第二の帳票情報を特定するための識別情報である。

本実施形態では、注文書管理データベース２２０において、項目「対応請求書情報」の値が格納されている場合、注文書情報と請求書情報との対応付けが完了していることを示す。

項目「確認状態」の値は、対応する注文書情報の突合作業の進捗を示す。具体的には、例えば、項目「確認状態」の値が、「確認済み」である場合には、買い手の目視による突合作業が完了していることを示す。また、例えば、項目「確認状態」の値が「要確認」である場合には、買い手の目視による突合作業が行われていないことを示し、項目「確認状態」の値が「未請求」である場合、注文書情報と請求書情報との対応付けが行われていないことを示しており、このときの項目「対応請求書情報」の値は空となる。また、項目「確認状態」の値が、「成功」である場合には、取引管理装置２００による突合処理が成功したことを示す。

項目「注文先」の値は、注文書番号で特定される注文書の注文先の名称を示す。図５の例では、注文先は「株式会社○○」である。したがって、注文書番号「１９０１８６」で特定される注文書は、テナント名「株式会社△△」が、株式会社○○に対して発行した注文書であることがわかる。

項目「合計金額」、「注文日」のそれぞれの値は、注文書に記載された合計金額、注文日を示す。

項目「帳票ステータス」の値は、帳票の認識の進捗を示す。本実施形態では、項目「帳票ステータス」の値として、未処理状態、下書き保存状態、確定済み状態、外部出力済み状態の４つを含む。各状態は、以下の通りである。

・未処理状態（状態１） 帳票情報（注文書情報、請求書情報）が取得された直後であり、帳票情報の内容の確認等が行われていない状態。

・下書き保存状態（状態２） 帳票情報の確認等の作業の途中等であり、帳票管理情報（注文書管理情報、請求書管理情報）が確定される前の状態。

・確定済み状態（状態３） 帳票情報の確認等の作業が完了し、帳票管理情報（注文書管理情報、請求書管理情報）が確定された情報として帳票管理データベース（注文書管理データベース２２０、請求書管理データベース２３０）へ格納された状態。
・外部出力済み状態（状態４） 取引管理システム１００と連携する会計システム等への帳票情報の出力が完了した状態。

項目「情報ステータス」の値は、取引管理システム１００における帳票情報（注文書情報、請求書情報）の状態を示す。具体的には、帳票情報の状態は、以下の４つの状態を含む。

・未処理状態（状態１） 帳票情報（注文書情報、請求書情報）が取得された直後であり、帳票情報の内容の確認等が行われていない状態。

・下書き保存状態（状態２） 帳票情報の確認等の作業の途中等であり、帳票情報（注文書情報、請求書情報）の内容が確定される前の状態。

・確定済み状態（状態３） 帳票情報の確認等の作業が完了し、帳票情報（注文書情報、請求書情報）が確定された情報となった状態。

本実施形態では、このように、帳票（注文書、請求書）の認識の進捗を示す状態と、帳票情報（注文書情報、請求書情報）の確認の状態と、を別々に管理する。このため、本実施形態では、例えば、買い手が注文書に対応した請求書を受領した後に、請求書の仕訳等の処理を行う前に、請求書情報のみを先に確定させて、確定された請求書情報と注文書情報とを突合させることができる。

項目「帳票画像パス」の値は、注文書画像データの格納先を示す。

項目「明細情報」は、項目「商品コード」、「商品名」、「数量」等のように、注文金額の内訳を示す項目と対応付けられていてよい。

なお、注文書管理情報に含まれる情報の項目は、図５に示す例に限定されない。注文書管理情報に含まれる情報の項目は、図５に示す項目が全て含まれなくてもよいし、図５に示す項目以外の項目が含まれてもよい。

図６は、請求書管理データベースの一例を示す図である。本実施形態の請求書管理データベース２３０は、注文先管理データベース２１０と同様に、テナント毎に設けられてよい。本実施形態の、請求書管理データベース２３０は、情報の項目として、請求元、請求書番号、対応注文書番号、合計金額、発行日、帳票ステータス、情報ステータス、帳票画像パス、振込先、明細情報等を含む。これらの各項目は、テナント名と対応付けられている。また、項目「請求先」及び「請求書番号」と、その他の項目とが対応付けられている。

以下の説明では、請求書管理データベース２３０における項目「請求元」及び「請求書番号」と、その他の項目の値を含む情報を請求書管理情報と呼ぶ。

また、請求書管理情報において、項目「対応注文書番号」、「確認状態」、「帳票ステータス」、「情報ステータス」等は、請求書情報を管理するための情報の項目であって、請求書情報に含まれなくてもよい。

項目「請求元」の値は、請求元のテナントの名称を示す。言い換えれば、項目「請求元」の値は、請求書情報を作成したテナントの名称を示す。

項目「請求書番号」の値は、請求書、請求書情報及び請求書管理情報を特定するための識別情報である。言い換えれば、項目「請求書番号」の値は、第二の帳票情報を特定するための識別情報である。

項目「対応注文書番号」の値は、請求書番号によって特定される請求書情報と対応する注文書情報を含む注文書を特定するための識別情報である。言い換えれば、項目「対応注文書番号」の値は、第一の帳票情報を特定するための識別情報である。

本実施形態では、請求書管理データベース２３０において、項目「対応注文書情報」の値が格納されている場合、請求書情報と注文書情報との対応付けが完了していることを示す。

項目「確認状態」の値は、請求書情報が受領された後の突合処理による突合結果の、買い手による確認が行われていない場合は「要確認」となる。また、項目「状態」の値は、買い手により突合結果の確認が行われた場合は「確認済み」となる。

項目「合計金額」の値は、請求金額の合計額を示す。項目「発行日」の値は、請求書番号で特定される請求書が発行された日付けを示す。

項目「帳票画像パス」の値は、注文書画像データの格納先を示す。項目「明細情報」は、項目「商品コード」、「商品名」、「数量」等のように、合計金額の内訳を示す項目と対応付けられている。

なお、請求書情報に含まれる情報の項目は、図６に示す例に限定されない。請求書情報に含まれる情報の項目は、図６に示す項目が全て含まれなくてもよいし、図６に示す項目以外の項目が含まれてもよい。

次に、図７を参照して、本実施形態の突合管理データベース２４０について説明する。図７は、突合管理データベースの一例を示す図である。本実施形態の突合管理データベース２４０は、テナント毎に設けられてよい。

突合管理データベース２４０は、情報の項目として、注文書番号、処理日時、合計金額、明細情報等を含み、項目「注文書番号」と、その他の項目とが対応付けられている。

項目「処理日時」の値は、突合処理が行われた日時を示す。項目「合計金額」の値は、注文書番号で特定される注文書情報に含まれる合計金額と、この注文書情報と対応する請求書情報に含まれる合計金額とを突合した結果を示す。

項目「明細情報」は、項目「商品コード」、「商品名」、「数量」等のように、合計金額の内訳を示す項目と対応付けられている。突合管理データベース２４０において、これらの項目の値は、請求書情報に含まれる明細情報と、注文書情報に含まれる明細情報とにおいて、商品名が一致する明細情報同士を突合した結果を示す。

図７の例では、合計金額を突合した結果が「要確認」であり、請求書情報と注文書情報に含まれる明細情報１を突合した結果、単価が「要確認」であることがわかる。

また、本実施形態では、突合結果が一致した場合を「成功」と表現し、突合結果が不一致である場合を「要確認」と表現する場合がある。

なお、突合管理データベース２４０に含まれる情報の項目は、図７に示す例に限定されない。突合管理データベース２４０に含まれる情報の項目は、図７に示す項目が全て含まれなくても良いし、図７に示す項目以外の項目が含まれてもよい。

次に、図８を参照して、本実施形態の取引管理システム１００に含まれる各装置の機能について説明する。図８は、取引管理システムに含まれる各装置の機能を説明する図である。

はじめに、取引管理装置２００の機能について説明する。本実施形態の取引管理装置２００の取引管理部２６０は、送信部２６１、受信部２６２、入力受付部２６３、帳票認識部２６４、表示制御部２６５、格納制御部２６６、対応付け部２６７、突合部２６８、出力部２６９を有する。

送信部２６１、受信部２６２は、取引管理装置２００と他の装置との情報の送受信を行う。入力受付部２６３は、取引管理装置２００に対する各種の入力を受け付ける。具体的には、入力受付部２６３は、買い手端末３００からの各種の情報の入力や要求を受け付ける。各種の情報とは、例えば、帳票画像データ（請求書画像データ、注文書画像データ）、帳票情報（請求書情報、注文書情報）等を含む。

帳票認識部２６４は、帳票画像データから帳票情報を抽出する。具体的には、帳票認識部２６４は、帳票画像データに対して文字認識処理を行ってテキストデータを取得し、取得したテキストデータから、帳票画像に含まれる項目と項目の値とを抽出し、項目と項目の値とを対応付けた情報を帳票情報とする。以下の説明では、帳票画像に含まれる項目と、この項目の値とを抽出し、項目と項目の値とをテキストデータに変換して対応付けることを、帳票認識と呼ぶ。

本実施形態では、入力受付部２６３により、請求書画像データの入力を受け付けた場合には、帳票認識部２６４により、請求書画像データから請求書情報を取得する。また、本実施形態では、入力受付部２６３により、注文書画像データの入力を受け付けた場合には、帳票認識部２６４により、注文書画像データから注文書情報を取得する。

表示制御部２６５は、買い手端末３００における表示を制御する。また、表示制御部２６５は、売り手端末４００における表示を制御してもよい。格納制御部２６６は、取引管理部２６０の処理に応じて、各データベースを更新する。

対応付け部２６７は、注文書情報と請求書情報との対応付けを行う。具体的には、対応付け部２６７は、請求書情報と注文書情報との突合を指示する操作を受け付けると、請求書情報と注文書情報とが対応付けられているか否かを判定する。そして、対応付け部２６７は、請求書情報が注文書情報と対応付けられていない場合に、表示制御部２６５により、請求書情報と対応付ける注文書情報を選択するための画面を買い手端末３００に表示させる。

対応付け部２６７は、この画面において、注文書情報が選択されると、選択された注文書情報と請求書情報とを対応付ける。具体的には、対応付け部２６７は、格納制御部２６６に、注文書管理データベース２２０の対応請求書番号の値を更新させ、請求書管理データベース２３０の対応注文書番号の値を更新させる。

突合部２６８は、互いに対応付けられた請求書情報と注文書情報との突合処理を行い、格納制御部２６６により、突合管理データベース２４０を更新させる。出力部２６９は、取引管理装置２００からの各種の情報の出力を行う。

次に、買い手端末３００の機能について説明する。本実施形態の買い手端末３００は、表示部３３０、通信部３４０を有する。表示部３３０は、買い手端末３００のディスプレイへの情報の表示を行う。通信部３４０は、買い手端末３００と他の装置との間の情報の送受信を行う。

次に、図９を参照して、本実施形態の取引管理システム１００の動作について説明する。

図９は、取引管理システムの動作を説明する第一のシーケンス図である。図９では、取引管理システム１００において、買い手が発行した注文書の注文書情報が注文書管理データベース２２０に格納されるまでの動作をステップＳ９０１からステップＳ９０８に示す。
また、図９では、取引管理システム１００において、買い手が売り手から受領した請求書の請求書情報が請求書管理データベース２３０に格納されるまでの動作をステップＳ９０９からステップＳ９１７に示す。

なお、注文書情報を注文書管理データベース２２０に格納する動作と、請求書情報を請求書管理データベース２３０に格納する動作とは、それぞれが独立したタイミングで実行されてよい。

本実施形態の取引管理システム１００において、買い手端末３００は、テナントからの注文書情報の登録を指示する操作を受け付けると（ステップＳ９０１）、注文書情報の登録要求を取引管理装置２００に送信する（ステップＳ９０２）。

注文書情報の登録要求は、例えば、買い手端末３００に入力された注文書画像データと共に取引管理装置２００に送信されてもよいし、紙媒体の注文書に記載された項目名と項目値とを対応付けたＣＳＶファイル等であってもよい。

取引管理装置２００は、入力受付部２６３により、注文書情報の登録要求を受け付けると、注文書情報を取得して、格納制御部２６６により、注文書管理データベース２２０に取得した注文書情報を格納する（ステップＳ９０３）。ステップＳ９０３の詳細は後述する。

続いて、取引管理装置２００は、表示制御部２６５により、買い手端末３００に対し、注文書情報を確認するための確認画面の表示指示を送信する（ステップＳ９０４）。

買い手端末３００は、確認画面の表示指示を受け付けて、表示部３３０により、注文書情報の確認画面を表示させる（ステップＳ９０５）。

続いて、買い手端末３００は、テナントから、注文書情報の確定を指示する操作を受け付けると（ステップＳ９０６）、取引管理装置２００に対し、注文書情報の確定要求を送信する（ステップＳ９０７）。

取引管理装置２００は、この要求を受けて、格納制御部２６６により、ステップＳ９０３で注文書管理データベース２２０に格納された注文書情報の状態を確定させる（ステップＳ９０８）。具体的には、格納制御部２６６は、注文書管理データベース２２０に格納された注文書情報を含む注文書管理情報において、項目「帳票ステータス」、「情報ステータス」の値を「確定」とする。

以上が、注文書情報を注文書管理データベース２２０に格納する動作である。次に、請求書情報を請求書管理データベース２３０に格納する動作を説明する。

買い手側のテナントが、売り手側から請求書を受領し（ステップＳ９０９）、買い手端末３００が、買い手側のテナントにより、請求書情報の登録を指示する操作を受け付けると（ステップＳ９１０）、買い手端末３００は、請求書情報の登録要求を取引管理装置２００へ送信する（ステップＳ９１１）。

取引管理装置２００は、入力受付部２６３により、請求書情報の登録要求を受け付けると、請求書情報を取得して、格納制御部２６６により、請求書管理データベース２３０に取得した請求書情報を格納する（ステップＳ９１２）。ステップＳ９１２の詳細は後述する。

続いて、取引管理装置２００は、表示制御部２６５により、買い手端末３００に対し、請求書情報を確認するための確認画面の表示指示を送信する（ステップＳ９１３）。

買い手端末３００は、確認画面の表示指示を受け付けて、表示部３３０により、請求書情報の確認画面を表示させる（ステップＳ９１４）。

続いて、買い手端末３００は、テナントから、請求書情報の確定を指示する操作を受け付けると（ステップＳ９１５）、取引管理装置２００に対し、請求書情報の確定要求を送信する（ステップＳ９１６）。

取引管理装置２００は、この要求を受けて、格納制御部２６６により、ステップＳ９１２で請求書管理データベース２３０に格納された請求書情報の状態を確定させる（ステップＳ９１７）。具体的には、格納制御部２６６は、請求書管理データベース２３０に格納された請求書情報を含む請求書管理情報において、項目「情報ステータス」の値を「確定」とする。
本実施形態では、請求書の仕訳等の処理を行う前に、請求書情報のみを先に確定させ、確定された請求書情報と注文書情報とを突合させることができる。また、本実施形態では、請求書情報に対する仕訳等が完了した後に、請求書管理情報の項目「帳票ステータス」が確定されてもよい。

以上が、請求書情報を請求書管理データベース２３０に格納する動作である。次に、格納制御部２６６の処理について説明する。

図１０は、取引管理装置の処理を説明する第一のフローチャートである。図１０では、図９のステップＳ９０３において、注文書情報を注文書管理データベース２２０に格納する格納制御部２６６の処理の詳細を示している。

本実施形態の取引管理装置２００の取引管理部２６０は、入力受付部２６３により、注文書情報の登録要求を受け付けると（ステップＳ１００１）、格納制御部２６６は、注文書が紙媒体であるか否かを判定する（ステップＳ１００２）。

具体的には、格納制御部２６６は、注文書情報の登録要求と共に買い手端末３００から送信された情報が、注文書画像データであるか否かを判定する。買い手端末３００から注文書画像データが送信された場合とは、スキャナ等の読み取り装置によって紙媒体の注文書が読み取られたことを示しており、注文書が紙媒体であると言える。

ステップＳ１００２において、注文書が紙媒体でない場合、取引管理部２６０は、後述するステップＳ１００４へ進む。注文書が紙媒体でない場合とは、注文書情報の登録要求と共に買い手端末３００から送信された情報が、例えば、ＣＳＶ形式のデータである場合等である。

このとき、買い手端末３００から送信される注文書情報は、取引管理装置２００が買い手端末３００に対して提供するアプリケーションを用いて作成された注文書情報であってもよいし、他のアプリケーションを用いて作成された注文書情報であってもよい。

ステップＳ１００２において、注文書が紙媒体である場合、取引管理装置２００は、帳票認識部２６４により、注文書画像データに対して帳票認識を行い、注文書画像データから注文書情報を抽出する（ステップＳ１００３）。

続いて、取引管理装置２００は、格納制御部２６６により、注文書情報を注文書管理データベース２２０へ格納し（ステップＳ１００４）、表示制御部２６５により、注文書情報の確認画面を表示させるための画面データを生成し（ステップＳ１００５）、処理を終了する。

以下に、図１１を参照して、注文書情報の確認画面について説明する。図１１は、注文書情報の確認画面の一例を示す図である。なお、図１１の例は、注文書が紙媒体であった場合の注文書情報の確認画面の例であってもよい。

図１１に示す画面１１１は、表示領域１１２、１１３、１１４と、操作ボタン２６、２７とを含む。

表示領域１１２には、注文書画像データが表示される。表示領域１１３には、注文書画像データに対する帳票認識により抽出された注文書情報が表示される。図１１の例では、注文書番号、注文先、合計金額、明細情報等が表示される。また、表示領域１１３には、操作ボタン１１６が表示されている。操作ボタン１１６は、表示領域１１３に表示された注文書情報の情報ステータスを、確定済み状態とするための操作ボタンである。

表示領域１１４には、帳票ステータスの値が表示される。操作ボタン２６は、画面１１１に注文書画像データと注文書情報とが表示された注文書の状態を、下書き保存状態に変更するための操作ボタンである。操作ボタン２７は、画面１１１に注文書画像データと注文書情報とが表示された注文書の状態を、確定済み状態に変更するための操作ボタンである。

なお、本実施形態では、例えば、帳票認識により抽出された注文書情報に対して修正を行う場合は、買い手端末３００において、修正対象となる項目の値を変更する操作を行えばよい。

本実施形態では、以上のようにして、買い手に対して注文書情報の確認を行わせる。

図１２は、取引管理装置の処理を説明する第二のフローチャートである。図１２では、図９のステップＳ９１２において、請求書情報を請求書管理データベース２３０に格納する格納制御部２６６の処理の詳細を示している。

本実施形態の取引管理装置２００の取引管理部２６０は、入力受付部２６３により、請求書情報の登録要求を受け付けると（ステップＳ１２０１）、格納制御部２６６は、請求書が紙媒体であるか否かを判定する（ステップＳ１２０２）。

具体的には、格納制御部２６６は、請求書情報の登録要求と共に買い手端末３００から送信された情報が、請求書画像データであるか否かを判定する。買い手端末３００から請求書画像データが送信された場合とは、スキャナ等の読み取り装置によって紙媒体の請求書が読み取られたことを示しており、請求書が紙媒体であると言える。

ステップＳ１２０２において、請求書が紙媒体でない場合、取引管理部２６０は、後述するステップＳ１２０４へ進む。請求書が紙媒体でない場合とは、請求書情報の登録要求と共に買い手端末３００から送信された情報が、例えば、ＣＳＶ形式のデータである場合等である。

このとき、買い手端末３００から送信される請求書情報は、取引管理装置２００が売り手端末４００に対して提供するアプリケーションを用いて作成され、取引管理装置２００を介して売り手端末４００から買い手端末３００へ送信された請求書情報であってもよい。

また、本実施形態では、請求書情報と、この請求書情報と対応する注文書情報との両方が、取引管理装置２００から提供されたアプリケーションを用いて作成された場合、請求書情報が作成された際に、自動的に注文書情報が請求書情報と対応付けられてよい。

また、請求書情報は、他のアプリケーションを用いて作成された請求書情報であってもよい。

ステップＳ１２０２において、請求書が紙媒体である場合、取引管理装置２００は、帳票認識部２６４により、請求書画像データに対して帳票認識を行い、請求書画像データから注文書情報を抽出する（ステップＳ１２０３）。

続いて、取引管理装置２００は、対応付け部２６７により、請求書情報と対応付けられた注文書情報が存在するか否かを判定する（ステップＳ１２０４）。具体的には、対応付け部２６７は、請求書情報が取引管理装置２００により提供されたアプリケーションを用いて作成されたものであり、且つ、請求書情報に対応注文書番号が付与されているか否かを判定している。

ステップＳ１２０４において、該当する注文書情報が存在しない場合、取引管理装置２００は、後述するステップＳ１２０６へ進む。

ステップＳ１２０４において、該当する注文書情報が存在する場合、取引管理装置２００は、対応付け部２６７により、請求書情報と注文書情報との対応付けを行う（ステップＳ１２０５）。

具体的には、取引管理装置２００は、対応付け部２６７により、注文書管理データベース２２０に格納された注文書情報のうち、注文書番号の値が、請求書情報に付与された対応注文書番号と一致する注文書情報を特定する。そして、取引管理装置２００は、格納制御部２６６により、特定された注文書情報を含む注文書管理情報において、項目「対応請求書番号」の値を、請求書情報に含まれる請求書番号とする。

続いて、取引管理装置２００は、格納制御部２６６により、請求書情報を請求書管理データベース２３０へ格納する（ステップＳ１２０６）。このとき、請求書情報と対応する注文書情報が存在する場合には、請求書情報を含む請求書管理情報における項目「対応注文書番号」の値を、対応する注文書情報の注文書番号とする。

続いて、取引管理装置２００は、表示制御部２６５により、請求書情報の確認画面を表示させるための画面データを生成し（ステップＳ１２０７）、処理を終了する。

次に、図１３を参照して、本実施形態の請求書情報の確認画面について説明する。図１３は、請求書情報の確認画面の一例を示す図である。なお、図１３の例は、請求書が紙媒体であった場合の請求書情報の確認画面の例であってもよい。

図１３に示す画面１３１は、表示領域１３２、１３３と、操作ボタン２８、２９とを含む。

表示領域１３２には、請求書画像データが表示される。

表示領域１３３は、表示領域１３４、１３５、１３６、１３７を有し、表示領域１３４には、請求書画像データに対する帳票認識により抽出された請求書情報が表示される。図１３の例では、請求書番号、請求元、請求額、明細情報等が表示される。また、表示領域１３４には、操作ボタン１４０が表示されている。操作ボタン１４０は、表示領域１３４に表示された請求書情報の情報ステータスを、確定済み状態とするための操作ボタンである。

なお、本実施形態では、例えば、帳票認識により抽出された請求書情報に対して修正を行う場合は、買い手端末３００において、操作ボタン１４０を操作する前に、修正対象となる項目の値を変更する操作を行えばよい。

表示領域１３５には、請求書に対する仕訳情報の入力欄等が表示される。本実施形態では、操作ボタン１４０が操作されて、請求書情報を確定させた後に、仕訳情報の入力等を行うことができる。

表示領域１３６は、請求書の帳票ステータスが表示される。図１３の例では、表示領域１３６には「未処理」と表示されており、請求書の状態が確定していないことがわかる。

表示領域１３７は、突合の進捗状態が表示される。図１３の例では、表示領域１３７には「要確認」と表示されており、突合結果の確認が行われていないことがわかる。

また、本実施形態の表示領域１３４には、タブ１３８、１３９が表示されている。タブ１３８は、請求書情報を表示領域１３４に表示させるためのタブである。タブ１３９は、表示領域１３４に表示された請求書情報と対応する注文書情報と、注文書情報との突合結果とを表示させるためのタブである。

本実施形態は、請求書情報の確認画面を表示させる場合には、タブ１３８が選択された状態で表示させる。

また、本実施形態では、請求書情報の画面１３１において、タブ１３９が選択された場合に、表示領域１３２に請求書画像データが表示された請求書情報と注文書情報との突合指示を受け付けたものとする。ここで、表示領域１３２に請求書画像データが表示された請求書情報は、突合対象として選択された請求書情報である。

次に、図１４を参照して、本実施形態の注文書情報と請求書情報との突合について説明する。

図１４は、取引管理システムの動作を説明する第二のシーケンス図である。本実施形態の取引管理システム１００において、買い手端末３００は、テナント等により、突合を指示する操作を受け付ける（ステップＳ１４０１）。具体的には、買い手端末３００は、請求書情報の確認画面において、注文書情報との突合結果を表示させるためのタブの選択を受け付けると、突合を指示する操作を受け付けたものとする。

買い手端末３００は、この指示を受け付けると、取引管理装置２００に対して、突合結果の表示要求を送信する（ステップＳ１４０２）。

取引管理装置２００は、入力受付部２６３により、この表示要求を受け付けると、対応付け部２６７により、確認画面に表示されている請求書情報との突合の対象となる注文書情報が存在するか否かを判定する（ステップＳ１４０３）。

具体的には、対応付け部２６７は、請求書管理データベース２３０において、確認画面に表示された請求書情報と対応する対応注文書番号の値が存在するか否かを判定する。

以下のステップＳ１４０４からステップＳ１４０６までの処理は、ステップＳ１４０３において、突合の対象となる注文書情報が存在すると判定された場合の処理である。

ステップＳ１４０３において、突合の対象となる注文書情報が存在すると判定された場合、取引管理装置２００は、突合部２６８により、請求書情報と注文書情報との突合を行い（ステップＳ１４０４）、出力部２６９により、突合結果を示す情報と、この情報の表示指示とを買い手端末３００を出力する（ステップＳ１４０５）。

なお、突合とは、注文書情報における発注の内訳と、請求書情報における請求の内訳とを照らし合わせ、発注の内訳と受注の内訳とが一致しているか否かを確認することを示す。

買い手端末３００は、突合結果を示す情報と、表示指示とを受信すると、表示部３３０に突合結果を表示させる（ステップＳ１４０６）。

以下のステップＳ１４０７からステップＳ１４２３までの処理は、ステップＳ１４０３において、突合の対象となる注文書情報が存在しない、と判定された場合の処理である。

ステップＳ１４０３において、突合の対象となる注文書情報が存在しない、と判定された場合、取引管理装置２００は、表示制御部２６５により、買い手端末３００に対して、突合の対象となる注文書情報の検索画面の表示指示を送信する（ステップＳ１４０７）。

買い手端末３００は、この表示指示を受けて、表示部３３０に注文書情報の検索画面を表示させる（ステップＳ１４０８）。続いて、買い手端末３００は、テナント等により、注文書情報の検索条件が入力されると（ステップＳ１４０９）、取引管理装置２００に対して検索要求を送信する（ステップＳ１４１０）。

取引管理装置２００は、検索要求を受け付けると、対応付け部２６７により、検索条件で、注文書管理データベース２２０を検索する（ステップＳ１４１１）。

このとき、対応付け部２６７は、注文書管理データベース２２０において、項目「情報ステータス」の値が「確定済み」とされた注文書情報から、検索条件に合致する注文書情報を検索する。

以下のステップＳ１４１２からステップＳ１４１５は、ステップＳ１４１１における検索で、検索結果として１の注文書情報が抽出された場合の処理を示す。本実施形態では、検索によって、１つの注文書情報が特定された場合には、取引管理装置２００は、対応付け部２６７により、特定された注文書情報と請求書情報とを対応付ける（ステップＳ１４１２）。

具体的には、対応付け部２６７は、格納制御部２６６により、特定された注文書情報の注文書番号を、請求書情報の対応注文書番号として、請求書管理データベース２３０に格納させる。また、対応付け部２６７は、格納制御部２６６により、特定された注文書情報の対応請求書番号として、請求書情報の請求書番号を注文書管理データベース２２０に格納させる。

このように、ステップＳ１４０８で表示される検索画面は、請求書情報と対応する注文書情報の選択を受け付ける受付画面の一例となる。

続いて、取引管理装置２００は、突合部２６８により、請求書情報と、特定された注文書情報との突合を行い（ステップＳ１４１３）、突合結果を示す情報を買い手端末３００へ送信する（ステップＳ１４１４）。

また、このとき、取引管理装置２００は、格納制御部２６６により、突合結果を注文書管理データベース２２０、請求書管理データベース２３０、突合管理データベース２４０のそれぞれに格納する。

具体的には、格納制御部２６６は、注文書管理データベース２２０と、請求書管理データベース２３０とに、項目「確認状態」の値として、請求書と注文書という帳票単位の突合結果を示す情報を格納する。例えば、格納制御部２６６は、帳票同士の突合が成功した場合には、項目「確認状態」の値を「成功」とし、帳票同士の突合が失敗した場合には、項目「確認状態」の値を「要確認」とする。帳票単位の突合の成功と失敗についての詳細は後述する。

また、格納制御部２６６は、突合管理データベース２４０において、請求書情報と注文書情報とに含まれる明細情報単位の突合結果を格納する。明細情報単位の突合の成功と失敗についての詳細は後述する。

買い手端末３００は、突合結果を示す情報を受信すると、この情報を表示させる（ステップＳ１４１５）。

以下のステップＳ１４１６からステップＳ１４２３までの処理は、ステップＳ１４１１の検索において、複数の注文書情報が抽出された場合の処理を示す。

ステップＳ１４１１において、複数の注文書情報が抽出されると、取引管理装置２００は、表示制御部２６５により、検索結果の表示指示を買い手端末３００に送信する（ステップＳ１４１６）。

買い手端末３００は、検索結果の表示指示を受信すると、検索結果として抽出された複数の注文書情報から、注文書情報を選択させるための選択画面を表示部３３０に表示させる（ステップＳ１４１７）。言い換えれば、取引管理装置２００は、請求書情報と対応づける注文書情報の選択を受け付けるための受付画面を買い手端末３００に表示させる。

続いて、買い手端末３００は、テナント等により、注文書情報を選択する操作を受け付けると（ステップＳ１４１８）、買い手端末３００は、取引管理装置２００に対して選択された注文書情報を通知する（ステップＳ１４１９）。

取引管理装置２００は、入力受付部２６３により、注文書情報を特定する通知を受け付けると、対応付け部２６７により、特定された注文書情報と請求書情報とを対応付ける（ステップＳ１４２０）。

続いて、取引管理装置２００は、突合部２６８により、請求書情報と、選択された注文書情報とを突合する（ステップＳ１４２１）。

続いて、取引管理装置２００は、出力部２６９により、突合結果を示す情報と、この情報の表示指示を買い手端末３００へ送信する（ステップＳ１４２２）。

買い手端末３００は、突合結果を示す情報と、表示指示とを受信すると、突合結果を示す情報を表示部３３０に表示させる（ステップＳ１４２３）。

このように、本実施形態では、突合指示を受ける前に、請求書情報と注文書情報とが対応付けられていない場合に、請求書情報と注文書情報を対応付けるための対応付け画面を買い手端末３００に表示させる。

また、対応付け画面に表示される注文書情報は、情報ステータスが確定済みとされたもののみである。したがって、本実施形態では、今後変更される可能性がある注文書情報が、突合の対象として選択されることを防止できる。言い換えれば、本実施形態では、確定されていない帳票情報が突合の対象とされることを防止できる。

なお、図１４の例では、請求書情報を請求書管理データベース２３０に格納する際に表示される請求書情報の確認画面から、突合を指示する操作が行われるものとしたが、突合を指示する操作が行われるタイミングは、これに限定されない。

本実施形態では、例えば、買い手端末３００に、受領した請求書の一覧を表示させ、表示された一覧から請求書が選択されると、選択された請求書情報の確認画面を表示するようにしてもよい。このようにすれば、買い手は、請求書を受領した後の任意のタイミングで、請求書情報と注文書情報との突合を行うことができる。

以下に、買い手端末３００の表示例について説明する。図１５は、買い手端末の表示例を示す第一の図である。図１５に示す画面１３１Ａは、図１４のステップＳ１４０８で買い手端末３００に表示される検索画面の一例を示す。

図１５に示す画面１３１Ａは、表示領域１３２、１３３Ａと、操作ボタン２８、２９とを含む。表示領域１３２には、請求書画像データが表示される。

表示領域１３３Ａは、表示領域１３４Ａ、１３５、１３６、１３７を有し、表示領域１３４Ａには、入力欄１４１、１４２、操作ボタン１４３、表示領域を含む。

入力欄１４１、１４２は、注文書情報の検索条件の入力欄である。具体的には、入力欄１４１には、注文書番号が入力され、入力欄１４２は、注文書情報が取引管理システム１００に取り込まれた日時が入力される。取り込まれた日時とは、注文書情報の情報ステータスが確定済みとされた日時である。

このことから、本実施形態の画面１３１Ａでは、請求書情報と対応付けられる注文書情報を特定するための情報の入力を受け付ける受付画面の一例とも言える。

なお、図１５の例では、検索条件を注文書番号と取込日時としたが、これに限定されない。本実施形態では、検索条件とした入力させる項目を、テナントの操作によって任意に変更することができる。

操作ボタン１４３は、入力欄１４１、１４２に入力された検索条件での検索を指示するための操作ボタンである。本実施形態の買い手端末３００は、入力欄１４１、１４２に検索条件が入力されて、操作ボタン１４３が操作されると、取引管理装置２００に検索要求を送信し、検索結果を表示させる。

表示領域１４４は、突合結果を表示させるための表示領域である。図１５の例では、突合の対象となる注文書情報が特定されていないため、表示領域１４４は空欄となっている。

図１６は、買い手端末の表示例を示す第二の図である。図１６に示す画面１３１Ｂは、画面１３１Ａの入力欄１４１、１４２に入力された検索条件を行った結果、表示領域１３２に表示された請求書画像データから抽出された請求書情報と対応する１つの注文書情報が特定された場合に、買い手端末３００に表示される画面の一例である。

具体的には、図１６に示す画面１３１Ｂは、図１４のステップＳ１４１５で買い手端末３００に表示される画面の一例である。

図１６に示す画面１３１Ｂは、表示領域１３２、１３３Ｂと、操作ボタン２８、２９とを含む。画面１３１Ｂでは、タブ１３９が選択された状態となっている。

表示領域１３３Ｂは、表示領域１３４Ｂ、１３５、１３６、１３７Ａを有し、表示領域１３４Ｂには、突合結果を示す情報が表示される。

具体的には、表示領域１３４Ｂには、入力欄１４１、１４２に検索条件として入力された注文書番号と取込日時が表示されている。

また、表示領域１３４Ｂは、表示領域１４４Ａを有する。表示領域１４４Ａには、入力欄１４１に入力された注文書番号で特定された注文書情報の明細情報と、各明細情報を請求書情報に含まれる明細情報と突合した結果とが表示されている。

表示領域１４４Ａでは、注文書情報に含まれる全ての明細情報について、「突合成功」という通知が表示されており、請求書情報に含まれる明細情報とが一致していることがわかる。

ここで、明細情報単位の突合の成功と失敗について説明する。

本実施形態では、請求書情報と注文書情報のそれぞれにおいて、商品名が一致する明細情報が一つだけ存在し、且つ、数量、単価、総額が全て一致する場合に、この商品名の明細情報の突合結果を「成功」とする。

また、本実施形態では、請求書情報と注文書情報のそれぞれにおいて、商品名が一致する明細情報が一つだけ存在し、且つ、数量、単価、総額の何れかが一致しない場合に、この商品名の明細情報の突合結果を「要確認」とする。

また、本実施形態では、請求書情報と注文書情報のそれぞれにおいて、商品名が一致する明細情報が複数存在する場合、又は、商品名が一致する明細情報が存在しない場合に、
数量、単価、総額に関わらず、この商品名の明細情報の突合結果を「要確認」とする。

次に、帳票単位の突合の成功と失敗について説明する。

本実施形態では、全ての明細情報の突合結果が「成功」であった場合に、表示領域１３７Ａに表示される帳票同士の突合の進捗状態が「成功」となる。また、本実施形態では、明細情報の突合結果に１つでも「要確認」が含まれる場合に、帳票同士の突合の進捗状態も「要確認」となる。

図１６の例では、表示領域１３７Ａに表示される帳票同士の突合の進捗状態が「成功」であるため、表示領域１３２に請求書画像データが表示されている請求書情報と、注文書情報とが一致したことがわかる。

図１７は、買い手端末の表示例を示す第三の図である。図１７に示す画面１３１Ｃは、画面１３１Ａの入力欄１４１、１４２に入力された検索条件を行った結果、複数の注文書情報が抽出された場合に、買い手端末３００に表示される画面の一例である。具体的には、図１７に示す画面１３１Ｃは、図１４のステップＳ１４１７において買い手端末３００に表示される注文書情報の選択画面の一例である。

画面１３１Ｃは、表示領域１７０を含む。表示領域１７０は、検索結果として抽出された注文書情報の一覧と、操作ボタン１７１とが表示される。

本実施形態の買い手端末３００は、表示領域１７０において、注文書情報が選択されて、操作ボタン１７１が操作されると、選択された注文書情報を、突合の対象となる注文書情報として、取引管理装置２００に通知する。

取引管理装置２００は、通知を受けると、選択された注文書情報を請求書情報と対応付けて突合処理を行う。

ここで、突合が成功した場合には、図１６に示す画面と同様のレイアウトの画面が表示される。

図１８は、買い手端末の表示例を示す第四の図である。図１８に示す画面１３１Ｄは、請求書情報と注文書情報とが対応付けられた後に行われた突合において、注文書情報に含まれる明細情報と、請求書情報に含まれる明細情報とが一致しない場合に、買い手端末３００に表示される画面の一例である。したがって、画面１３１Ｄは、図１４のステップＳ１４２３で買い手端末３００に表示される画面の一例と言える。

図１８に示す画面１３１Ｄは、表示領域１３２、１３３Ｃと、操作ボタン２８、２９とを含む。また、画面１３１Ｄでは、タブ１３９が選択された状態となっている。

表示領域１３３Ｃは、表示領域１３４Ｃ、１３５、１３６、１３７を有する。また、表示領域１３４Ｃは、表示領域１４４Ｂ、１４５を含む。

表示領域１４５には、検索条件である注文書番号と取込日時が表示される。また、表示領域１４５には、注文書情報の明細情報が商品名毎に表示される。

表示領域１４４Ｂには、請求書情報の明細情報と、注文書情報の明細情報とをそれぞれ突合した結果が、明細情報毎に表示される。

本実施形態では、例えば、表示領域１４４Ｂには、注文書情報の明細情報のうち、請求書情報の明細と一致しなかった商品名と対応する明細情報が表示されてもよい。

また、表示領域１４４Ｂには、明細情報毎に、テナントによる内容の確認が必要であることを示す通知「要確認」が表示される。また、表示領域１４４Ｂでは、各明細情報にチェックボックスが対応付けられて表示されている。このチェックボックスは、対応する明細情報の突合結果について、テナント等が確認作業を行った際に、チェックが入力される。

本実施形態では、表示領域１４４Ｂに表示された全ての明細情報について、テナントによる確認作業が行われると、突合が完了したことになる。

図１９は、買い手端末の表示例を示す第五の図である。図１９に示す画面１３１Ｅは、図１８に示す画面１３１Ｄにおいて、表示領域１４４Ｂに表示された突合結果に対し、テナントが確認を行った後に表示される画面の一例である。

図１９に示す画面１３１Ｅは、表示領域１３２、１３３Ｄと、操作ボタン２８、２９とを含む。また、画面１３１Ｅでは、タブ１３９が選択された状態となっている。

表示領域１３３Ｄは、表示領域１３４Ｄ、１３５、１３６、１３７Ｂを有する。また、表示領域１３４Ｄは、表示領域１４４Ｃ、１４５を含む。

図１９の例では、表示領域１４４Ｃでは、各明細情報に対応付けられたチェックボックスに、テナントによる確認が行われたことを示すチェックが入力されている。

また、図１９の例では、表示領域１３７Ｂに、「確認済み」と表示されており、明細情報の突合結果の確認作業が完了した状態であることがわかる。

図２０は、買い手端末の表示例を示す第六の図である。図２０に示す画面１３１Ｆは、帳票ステータスが「確定済み」とされ、且つ、注文書情報との突合も完了した請求書の請求書情報の確認画面の一例を示す。

図２０に示す画面１３１Ｆは、表示領域１３２、１３３Ｅと、操作ボタン２８、２９とを含む。また、画面１３１Ｆでは、タブ１３８が選択された状態となっている。表示領域１３３Ｅは、表示領域１３４、１３５、１３６Ａ、１３７Ａを有する。

図２０の例では、表示領域１３６Ａに「確定済み」と表示されており、表示領域１３７Ａに「成功」と表示されている。

したがって、表示領域１３２に請求書画像データが表示された請求書は、確定済みの状態であり、且つ、対応する注文書との突合も成功した状態であることがわかる。

このように、本実施形態では、帳票ステータスと、突合の進捗状態とを表示させるため、請求書情報と注文書情報との状態をテナントに対して容易に把握させることができる。

また、本実施形態では、請求書情報と注文書情報とが対応付けられていない場合に、請求書情報に対応付ける注文書情報を特定する情報の入力を受け付ける受付画面を買い手端末３００に表示させる。

また、本実施形態では、注文書や請求書が紙媒体である場合には、注文書画像データや請求書画像データに対して帳票認識を行い、注文書情報と請求書情報とを取得する。

したがって、本実施形態では、注文書や請求書が紙媒体であっても、突合作業の担当者が目視で対応付けを確認する、といった作業を行う必要がなく、請求書情報と注文書情報との対応付けを容易に行わせることができる。

なお、本実施形態では、取引管理装置２００が帳票認識機能を実現する帳票認識部２６４を有するものとしたが、これに限定されない。帳票認識部２６４は、取引管理装置２００の外部に設けられていてもよい。以下に、図２１を参照して、取引管理システムの別の構成について説明する。

図２１は、取引管理システムのシステム構成の別の例を示す図である。図２１に示す取引管理システム１００Ａは、取引管理装置２００Ａ、買い手端末３００、帳票認識装置５００を有する。

取引管理装置２００Ａは、注文先管理データベース２１０、注文書管理データベース２２０、請求書管理データベース２３０、突合管理データベース２４０、取引管理部２６０Ａを有する。

取引管理部２６０Ａは、帳票認識部２６４を有していないこと以外は、取引管理部２６０と同様である。帳票認識装置５００は、帳票認識部２６４を有する。

取引管理システム１００Ａでは、取引管理装置２００Ａは、例えば、買い手端末３００から帳票画像データを受信した場合、この帳票画像データを帳票認識装置５００へ送信し、帳票認識を行わせてもよい。そして、取引管理装置２００Ａは、帳票認識装置５００から、帳票認識により取得された帳票情報を受信してもよい。

本実施形態では、このように、帳票認識を取引管理装置２００Ａ以外の装置で行うことで、取引管理装置２００Ａの処理負荷を軽減させることができる。

また、上記で説明した実施形態の各機能は、一又は複数の処理回路によって実現することが可能である。ここで、本明細書における「処理回路」とは、電子回路により実装されるプロセッサのようにソフトウェアによって各機能を実行するようプログラミングされたプロセッサや、上記で説明した各機能を実行するよう設計されたASIC（Application Specific Integrated Circuit）、DSP（digital signal processor）、FPGA（field programmable gate array）や従来の回路モジュール等のデバイスを含むものとする。

また、実施形態に記載された装置群は、本明細書に開示された実施形態を実施するための複数のコンピューティング環境のうちの１つを示すものにすぎない。

ある実施形態では、取引管理装置２００は、サーバクラスタといった複数のコンピューティングデバイスを含む。複数のコンピューティングデバイスは、ネットワークや共有メモリなどを含む任意のタイプの通信リンクを介して互いに通信するように構成されており、本明細書に開示された処理を実施する。同様に、取引管理装置２００は、互いに通信するように構成された複数のコンピューティングデバイスを含むことができる。

さらに、取引管理装置２００は、開示された処理ステップを様々な組み合わせで共有するように構成できる。例えば、取引管理装置２００によって実行されるプロセスは、他のサーバ装置によって実行され得る。同様に、取引管理装置２００の機能は、他のサーバ装置によって実行することができる。また、サーバ装置と他のサーバ装置の各要素は、１つのサーバ装置にまとめられていても良いし、複数の装置に分けられていても良い。

また、明細書中のテーブルは、機械学習の学習効果によって生成されたものでもよい。また、取引内容の記載に含まれうるキーワードと項目とを機械学習にて分類付けすることで、対応テーブルを使用しなくてもよい。

ここで、機械学習とは、コンピュータに人のような学習能力を獲得させるための技術であり、コンピュータが、データ識別等の判断に必要なアルゴリズムを、事前に取り込まれる学習データから自律的に生成し，新たなデータについてこれを適用して予測を行う技術のことをいう。機械学習のための学習方法は、教師あり学習、教師なし学習、半教師学習、強化学習、深層学習のいずれかの方法でもよく、さらに、これらの学習方法を組み合わせた学習方法でもよく、機械学習のための学習方法は問わない。

以上、各実施形態に基づき本発明の説明を行ってきたが、上記実施形態に示した要件に本発明が限定されるものではない。これらの点に関しては、本発明の主旨をそこなわない範囲で変更することができ、その応用形態に応じて適切に定めることができる。

１００、１００Ａ 取引管理システム
２００、２００Ａ 取引管理装置
２１０ 注文先管理データベース
２２０ 注文書管理データベース
２３０ 請求書管理データベース
２４０ 突合管理データベース
２６０ 取引管理部
２６３ 入力受付部
２６４ 帳票認識部
２６５ 表示制御部
２６６ 格納制御部
２６７ 対応付け部
２６８ 突合部
２６９ 出力部
３００ 買い手端末（端末装置）
４００ 売り手端末（端末装置）

特開平１１－２３２３０６号公報

Claims (14)

1. 記憶部に格納された第一の帳票情報の中から、第二の帳票情報と対応付ける第一の帳票情報を特定する情報の入力を受け付ける受付画面を端末装置に表示させる表示制御部と、
   前記特定する情報に基づき特定された第一の帳票情報を、前記第二の帳票情報と対応付ける対応付け部と、を有する情報処理装置。
2. 前記表示制御部は、
   前記特定された第一の帳票情報が複数存在する場合に、複数の前記特定された第一の帳票情報を含む選択画面を前記端末装置に表示させ、
   前記対応付け部は、
   前記選択画面において選択された第一の帳票情報を、前記第二の帳票情報と対応付ける、請求項１記載の情報処理装置。
3. 前記第二の帳票情報と対応付けられた第一の帳票情報と、前記第二の帳票情報とを突合する突合部を有し、
   前記表示制御部は、前記突合部による突合の結果を示す情報を前記端末装置に表示させる、請求項１又２記載の情報処理装置。
4. 前記表示制御部は、
   前記突合の結果を示す情報を、前記第一の帳票情報と、前記第二の帳票情報を含む第二の帳票画像データと共に、前記端末装置に表示させる、請求項３記載の情報処理装置。
5. 前記特定する情報は、前記記憶部に格納された第一の帳票情報の検索条件であり、
   前記対応付け部は、
   前記検索条件で前記記憶部を検索した結果を前記特定された第一の帳票情報とする、請求項１乃至４の何れか一項に記載の情報処理装置。
6. 前記検索条件による検索は、前記記憶部において状態が確定された第一の帳票情報に対してのみ、行われる、請求項５記載の情報処理装置。
7. 情報処理装置による情報処理方法であって、前記情報処理装置が、
   記憶部に格納された第一の帳票情報の中から、第二の帳票情報と対応付ける第一の帳票情報を特定する情報の入力を受け付ける受付画面を端末装置に表示させ、
   前記特定する情報に基づき特定された第一の帳票情報を、前記第二の帳票情報と対応付ける、情報処理方法。
8. 前記情報処理装置が、
   前記特定された第一の帳票情報が複数存在する場合に、複数の前記特定された第一の帳票情報を含む選択画面を前記端末装置に表示させ、
   前記選択画面において選択された第一の帳票情報を、前記第二の帳票情報と対応付ける、請求項７記載の情報処理方法。
9. 前記情報処理装置が、
   前記第二の帳票情報と対応付けられた第一の帳票情報と、前記第二の帳票情報とを突合し、
   前記突合の結果を示す情報を前記端末装置に表示させる、請求項７又８記載の情報処理方法。
10. 前記情報処理装置が、
    前記突合の結果を示す情報を、前記第一の帳票情報と、前記第二の帳票情報を含む第二の帳票画像データと共に、前記端末装置に表示させる、請求項９記載の情報処理方法。
11. 前記特定する情報は、前記記憶部に格納された第一の帳票情報の検索条件であり、
    前記検索条件で前記記憶部を検索した結果を前記特定された第一の帳票情報とする、請求項７乃至１０の何れか一項に記載の情報処理方法。
12. 前記検索条件による検索は、前記記憶部において状態が確定された第一の帳票情報に対してのみ、行われる、請求項１１記載の情報処理方法。
13. 記憶部に格納された第一の帳票情報の中から、第二の帳票情報と対応付ける第一の帳票情報を特定する情報の入力を受け付ける受付画面を端末装置に表示させ、
    前記特定する情報に基づき特定された第一の帳票情報を、前記第二の帳票情報と対応付ける、処理を情報処理装置に実行させる、プログラム。
14. 情報処理装置と、端末装置とを含む情報処理システムであって、
    前記情報処理装置は、
    記憶部に格納された第一の帳票情報の中から、第二の帳票情報と対応付ける第一の帳票情報を特定する情報の入力を受け付ける受付画面を前記端末装置に表示させる表示制御部と、
    前記特定する情報に基づき特定された第一の帳票情報を、前記第二の帳票情報と対応付ける対応付け部と、を有し、
    前記端末装置は、
    前記受付画面を表示させる表示部を有する、情報処理システム。

Images