JP2023140703A - 情報処理装置、情報処理端末、情報処理システム、情報処理方法及びプログラム - Google Patents

Abstract

【課題】利用者及び取引先双方の条件を考慮した請求書を提案する。【解決手段】利用者が利用する情報処理端末とネットワークを介して通信可能な情報処理装置が、利用者の取引条件及び取引先の支払条件を記憶部に記憶する記憶制御部と、取引条件に従った請求書情報又は支払条件に従った請求書情報の生成を提案する画面を表示させるための画面データを情報処理端末に送信する送信部と、を備える。【選択図】図４

Description

この発明は、情報処理装置、情報処理端末、情報処理システム、情報処理方法及びプログラムに関する。

従来、商取引での消込処理において、販売者は、購入者から送金された入金情報に含まれる入金額や入金日等の情報と、請求書に記載された請求金額や支払い期限日等の情報とを照合しながら、当該請求書に係る売掛金の消込を行っている。この場合、販売者は、売掛金が請求書通りに回収されているか、回収の遅れが出ていないか等を確認している（特許文献１参照）。

しかしながら、取引条件の確認に手間がかかる場合がある、という課題がある。例えば、販売者と購入者との間で取引条件や支払条件の認識に齟齬があると、請求内容又は入金内容について都度確認を行う必要が生じ、両者にとって負担である。

この発明の一実施形態は、上記のような技術的課題に鑑みて、利用者及び取引先双方の条件を考慮した請求書情報の生成を提案することである。

上記の課題を解決するために、この発明の一実施形態である情報処理装置は、利用者が利用する情報処理端末とネットワークを介して通信可能な情報処理装置であって、利用者の取引条件及び取引先の支払条件を記憶部に記憶する記憶制御部と、取引条件に従った請求書情報又は支払条件に従った請求書情報の生成を提案する画面を表示させるための画面データを情報処理端末に送信する送信部と、を備える。

この発明の一実施形態によれば、利用者及び取引先双方の条件を考慮した請求書情報の生成を提案することができる。

一実施形態における各企業の関係を示す概念図である。 一実施形態における情報処理システムの全体構成の一例を示す図である。 一実施形態における情報処理装置のハードウェア構成の一例を示す図である。 一実施形態における情報処理システムの機能構成の一例を示す図である。 第１実施形態における条件情報登録処理の一例を示す図である。 第１実施形態における取引条件設定画面の一例を示す図である。 第１実施形態における取引条件管理テーブルの一例を示す図である。 第１実施形態における支払条件設定画面の一例を示す図である。 第１実施形態における支払条件管理テーブルの一例を示す図である。 第１実施形態における請求書作成及び送付処理の一例を示す図である。 第１実施形態におけるテナント情報管理テーブルの一例を示す図である。 第１実施形態における売掛帳情報管理テーブルの一例を示す図である。 第１実施形態における請求書作成画面データ作成処理の一例を示す図である。 第１実施形態における請求書作成画面の一例を示す図である。 第１実施形態における請求書作成画面の一例を示す図である。 第１実施形態における請求書画像の一例を示す図である。 第１実施形態における発行請求書情報管理テーブルの一例を示す図である。 第１実施形態における発行請求書情報管理テーブルの一例を示す図である。 第１実施形態における売掛帳情報管理テーブルの一例を示す図である。 第１実施形態における売掛帳情報管理テーブルの一例を示す図である。 第１実施形態における請求書送付画面の一例を示す図である。 第１実施形態における受領情報管理テーブルの一例を示す図である。 第１実施形態における請求書受領処理の一例を示す図である。 第１実施形態における請求書受領画面の一例を示す図である。 第１実施形態における受領請求書情報管理テーブルの一例を示す図である。 第１実施形態における送金データ作成処理の一例を示す図である。 第１実施形態における受領請求書一覧画面の一例を示す図である。 第１実施形態における買掛帳情報管理テーブルの一例を示す図である。 第１実施形態における支払処理画面データ作成処理の一例を示す図である。 第１実施形態における支払処理画面の一例を示す図である。 第１実施形態における支払処理画面の一例を示す図である。 第１実施形態における支払情報管理テーブルの一例を示す図である。 第１実施形態における買掛帳情報管理テーブルの一例を示す図である。 第１実施形態における入金情報取得及び自動消込処理の一例を示す図である。 第１実施形態における入金情報管理テーブルの一例を示す図である。 第１実施形態における自動消込処理の一例を示す図である。 第１実施形態における売掛帳情報管理テーブルの一例を示す図である。 第１実施形態における買掛帳情報管理テーブルの一例を示す図である。 第１実施形態における入金管理画面作成処理の一例を示す図である。 第１実施形態における入金管理画面の一例を示す図である。 第１実施形態における入金管理画面の一例を示す図である。 第２実施形態における取引条件設定画面の一例を示す図である。 第２実施形態における取引条件管理テーブルの一例を示す図である。 第２実施形態における支払条件管理テーブルの一例を示す図である。 第２実施形態における買掛帳情報管理テーブルの一例を示す図である。 第２実施形態における支払処理画面の一例を示す図である。

以下、図面を参照しながら、この発明の実施の形態について、詳細に説明する。なお、図面中において同じ機能を有する構成部には同じ番号を付し、重複説明を省略する。

［第１実施形態］
〔企業間の関係〕
本実施形態における各企業間の関係を、図１を参照しながら説明する。図１は、本実施形態における各企業の関係を示す概念図である。

図１に示されているように、サービス利用企業Ａは、取引先であるサービス利用企業Ｂに対して、商品又はサービスを提供することで、サービス利用企業Ｂから対価を受ける企業である。この場合、販売者であるサービス利用企業Ａが債権者となり、購入者であるサービス利用企業Ｂが債務者となる。

サービス提供企業Ｃは、サービス利用企業Ａからの依頼を受けて、サービス利用企業Ａがサービス利用企業Ｂに送る請求書の作成（請求書情報の生成）を代行するサービスを提供する企業である。本実施形態において、サービス提供企業が提供するサービスを利用する主体を、テナントと表現する場合がある。つまり、本実施形態においてテナントとは、事業者、団体又は個人等である。

金融機関Ｄ１は、サービス利用企業Ｂの銀行口座を管理する金融機関である。金融機関Ｄ２は、サービス利用企業Ａの銀行口座を管理する金融機関である。なお、金融機関に限らず、口座振替サービスにより口座管理する収納代行業者等でもよい。

ここで、本実施形態における処理の概略を説明する。なお、後述の各ＩＤは、識別情報の一例である。

まず、サービス利用企業Ａは、サービス提供企業Ｃに対して、取引条件の登録を要求する（ステップＳ０－１）。取引条件は、例えば、請求締日及び支払サイトである。これにより、サービス提供企業Ｃは、サービス利用企業Ａの取引条件を登録する。次に、サービス利用企業Ｂは、サービス提供企業Ｃに対して、支払条件の登録を要求する（ステップＳ０－２）。支払条件は、例えば、支払締日及び支払予定日である。これにより、サービス提供企業Ｃは、サービス利用企業Ｂの支払条件を登録する。

次に、サービス利用企業Ａは、サービス提供企業Ｃに対して、サービス利用企業Ｂへ発行する請求書の作成（請求書情報の生成）及び送付を要求する（ステップＳ１）。このとき、サービス提供企業Ｃは、サービス利用企業Ａの取引条件とサービス利用企業Ｂの支払条件を考慮した請求内容をサービス利用企業Ａに提案する。これにより、サービス利用企業Ｂは、サービス提供企業Ｃを介して、サービス利用企業Ａから請求書を受領する（ステップＳ２）。

サービス利用企業Ｂは、サービス提供企業Ｃに対して、支払対象とする明細を特定した支払要求を送信する（ステップ３－１）。これにより、サービス提供企業Ｃは、支払要求を識別する支払ＩＤを含む送金データを作成し、サービス利用企業Ｂに送付する（ステップＳ３－２）。この送金データは、購入者（サービス利用企業Ｂ）の銀行口座から販売者（サービス利用企業Ａ）の銀行口座への請求書に基づく送金に用いられるデータである。すなわち、サービス提供企業Ｃは、サービス利用企業Ｂが送金時に使用する送金データを作成し、更に、作成する際に送金データに支払ＩＤを含める処理を行う。

次に、サービス利用企業Ｂは、金融機関Ｄ１に、支払ＩＤが含められている送金データを送る（ステップＳ４－１）。これにより、金融機関Ｄ１は、サービス利用企業Ａの銀行口座が管理されている金融機関Ｄ２に対して、送金データに従った金額を送金する（ステップＳ４－２）。この際、送金データと共に支払ＩＤも、金融機関Ｄ１から金融機関Ｄ２に送られる。

次に、金融機関Ｄ２は、サービス利用企業Ａの銀行口座への入金を確認した後、サービス提供企業Ｃに対して、入金内容及び支払ＩＤを含めた入金情報（入金元、入金額、入金日等の情報）を送付する。これにより、サービス提供企業Ｃは、入金情報を取得する（ステップＳ５）。

次に、サービス提供企業Ｃは、入金情報に含まれる支払ＩＤに基づいて支払対象とされた請求書の明細を特定し、当該明細に関する消込処理を行う（ステップＳ６）。請求書に含まれる明細の一部に基づく送金が行われても、支払ＩＤにより支払対象とされた明細を特定することができ、当該明細に関する請求金額と入金額が一致しているか否かを確認することができる。したがって、請求書に含まれる明細単位での支払いが行われた場合であっても、自動的に消込を行うことができる。

〔情報処理システムの全体構成〕
本実施形態における情報処理システムの全体構成を、図２を参照しながら説明する。図２は、本実施形態における情報処理システムの全体構成の一例を示すブロック図である。

図２に示されているように、本実施形態における情報処理システム１は、取引管理サーバ１０、販売者端末２０、購入者端末３０及び２台の口座管理サーバ４０を含む。取引管理サーバ１０、販売者端末２０、購入者端末３０及び口座管理サーバ４０は、それぞれ通信ネットワークＮ１に接続している。

通信ネットワークＮ１は、接続されている各装置が相互に通信可能となるように構成されている。通信ネットワークＮ１は、例えば、インターネット、ＬＡＮ（Local Area Network）、又はＷＡＮ（Wide Area Network）などの有線通信によるネットワークによって構築されている。

通信ネットワークＮ１は、有線通信だけでなく、例えば、無線ＬＡＮ、又は近距離無線通信等の無線通信、もしくはＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）、ＬＴＥ（Long Term Evolution）、又は５Ｇ（5th Generation）等の移動体通信によるネットワークが含まれていてもよい。

販売者端末２０は、サービス利用企業Ａ（販売者）に設置されている。購入者端末３０は、サービス利用企業Ｂ（購入者）に設置されている。取引管理サーバ１０は、サービス提供企業Ｃに設置されている。購入者側の口座管理サーバ４０－１は、金融機関Ｄ１に設置されている。販売者側の口座管理サーバ４０－２は、金融機関Ｄ２に設置されている。

販売者端末２０及び購入者端末３０は、例えば、ＰＪ（Projector：プロジェクタ）、ＩＷＢ（Interactive White Board：相互通信が可能な電子式の黒板機能を有する白板）、デジタルサイネージ等の出力装置、ＨＵＤ（Head Up Display）装置、産業機械、撮像装置、集音装置、医療機器、ネットワーク家電、自動車（Connected Car）、ノートＰＣ（Personal Computer）、携帯電話、スマートフォン、タブレット端末、ゲーム機、ＰＤＡ（Personal Digital Assistant）、デジタルカメラ、ウェアラブルＰＣまたはデスクトップＰＣ等であってもよい。

〔情報処理システムのハードウェア構成〕
本実施形態における情報処理システムのハードウェア構成を、図３を参照しながら説明する。図３は、取引管理サーバ１０、販売者端末２０、購入者端末３０及び口座管理サーバ４０がコンピュータで実現される場合のハードウェア構成の一例を示す図である。

図３に示されているように、本実施形態におけるコンピュータは、ＣＰＵ（Central Processing Unit）５０１、ＲＯＭ（Read Only Memory）５０２、ＲＡＭ（Random Access Memory）５０３、ＨＤ（Hard Disk）５０４、ＨＤＤ(Hard Disk Drive)コントローラ５０５、ディスプレイ５０６、外部機器接続Ｉ／Ｆ(Interface)５０８、ネットワークＩ／Ｆ５０９、バスライン５１０、キーボード５１１、ポインティングデバイス５１２、ＤＶＤ－ＲＷ(Digital Versatile Disk Rewritable)ドライブ５１４、メディアＩ／Ｆ５１６を備えている。

これらのうち、ＣＰＵ５０１は、コンピュータ全体の動作を制御する。ＲＯＭ５０２は、ＩＰＬ等のＣＰＵ５０１の駆動に用いられるプログラムを記憶する。ＲＡＭ５０３は、ＣＰＵ５０１のワークエリアとして使用される。ＨＤ５０４は、プログラム等の各種データを記憶する。ＨＤＤコントローラ５０５は、ＣＰＵ５０１の制御にしたがってＨＤ５０４に対する各種データの読み出し又は書き込みを制御する。

ディスプレイ５０６は、カーソル、メニュー、ウィンドウ、文字、又は画像などの各種情報を表示する。外部機器接続Ｉ／Ｆ５０８は、各種の外部機器を接続するためのインターフェースである。この場合の外部機器は、例えば、ＵＳＢ(Universal Serial Bus)メモリやプリンタ等である。ネットワークＩ／Ｆ５０９は、通信ネットワークＮ１を利用してデータ通信をするためのインターフェースである。バスライン５１０は、図３に示されているＣＰＵ５０１等の各構成要素を電気的に接続するためのアドレスバスやデータバス等である。

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

〔情報処理システムの機能構成〕
本実施形態における情報処理システムの機能構成を、図４を参照しながら説明する。図４は、本実施形態における情報処理システムの機能構成の一例を示すブロック図である。

＜取引管理サーバの機能構成＞
図４に示されているように、本実施形態における取引管理サーバ１０は、送受信部１１、生成部１４、判断部１５、作成部１６、記憶制御部１９及び記憶部１００を備える。これら各部は、図３に示されている各構成要素のいずれかが、ＨＤ５０４からＲＡＭ５０３上に展開されたプログラムに従ったＣＰＵ５０１からの命令によって動作することで実現される機能又は機能する手段である。また、記憶部１００は、図３に示されているＲＡＭ５０３及びＨＤ５０４によって構築される。

送受信部１１は、図３に示されているＣＰＵ５０１からの命令及びネットワークＩ／Ｆ５０９によって実現され、通信ネットワークＮ１を介して他の端末、装置、又はシステムと各種データ（または情報）の送受信を行う。

生成部１４は、図３に示されているＣＰＵ５０１からの命令によって実現され、所定のデータ（情報）の生成を行う。生成内容は後述する。

判断部１５は、図３に示されているＣＰＵ５０１からの命令によって実現され、所定の判断を行う。判断内容は後述する。

作成部１６は、図３に示されているＣＰＵ５０１からの命令によって実現され、後述の各画面の作成や各画面のＵＲＬの作成等を行う。

記憶制御部１９は、図３に示されているＣＰＵ５０１からの命令及びＨＤＤコントローラ５０５によって実現され、記憶部１００に各種データを記憶したり、記憶部１００に記憶された各種データを読み出したりする処理を行う。

記憶部１００には、テナント情報管理ＤＢ、売掛帳情報管理ＤＢ、買掛帳情報管理ＤＢ、発行請求書情報管理ＤＢ、受領情報管理ＤＢ、受領請求書情報管理ＤＢ、支払情報管理ＤＢ、入金情報管理ＤＢ、取引条件管理ＤＢ及び支払条件管理ＤＢが構築されている。

テナント情報管理ＤＢは、テナント情報管理テーブルによって構成される。テナント情報管理テーブルには、取引管理サーバ１０のテナントであるサービス利用企業Ａ及びサービス利用企業Ｂに関する情報が格納されている。テナント情報管理テーブルの詳細は、後述する。

売掛帳情報管理ＤＢは、テナント毎の売掛帳情報管理テーブルによって構成される。売掛帳情報管理テーブルには、販売者（サービス利用企業Ａ）から購入者（サービス利用企業Ｂ）への販売情報に基づく売掛帳情報が格納されている。売掛帳情報は、例えば会計システム等の売掛帳を有する外部のシステムからインポートすればよい。取引管理サーバ１０が会計機能も備える場合、当該取引管理サーバ１０が有する売掛帳を利用してもよい。売掛帳情報管理テーブルの詳細は、後述する。

買掛帳情報管理ＤＢは、テナント毎の買掛帳情報管理テーブルによって構成される。買掛帳情報管理テーブルには、販売者（サービス利用企業Ａ）から購入者（サービス利用企業Ｂ）への納品情報に基づく買掛帳情報が格納されている。買掛帳情報は、例えば会計システム等の買掛帳を有する外部のシステムからインポートすればよい。取引管理サーバ１０が会計機能も備える場合、当該取引管理サーバ１０が有する買掛帳を利用してもよい。買掛帳情報管理テーブルの詳細は、後述する。

発行請求書情報管理ＤＢは、テナント毎の発行請求書情報管理テーブルによって構成される。発行請求書情報管理テーブルには、販売者（サービス利用企業Ａ）が購入者（サービス利用企業Ｂ）に発行した請求書に関する請求書情報が格納されている。発行請求書情報管理テーブルの詳細は、後述する。

受領情報管理ＤＢは、テナント毎の受領情報管理テーブルによって構成される。受領情報管理テーブルには、購入者（サービス利用企業Ｂ）が請求書を受領するための受領情報が格納されている。受領情報管理テーブルの詳細は、後述する。

受領請求書情報管理ＤＢは、テナント毎の受領請求書情報管理テーブルによって構成される。発行請求書情報管理テーブルには、購入者（サービス利用企業Ｂ）が販売者（サービス利用企業Ａ）から受領した請求書に関する請求書情報が格納されている。受領請求書情報管理テーブルの詳細は、後述する。

支払情報管理ＤＢは、テナント毎の支払情報管理テーブルによって構成される。支払情報管理テーブルには、購入者（サービス利用企業Ｂ）が販売者（サービス利用企業Ａ）に送金した支払情報が格納されている。支払情報管理テーブルの詳細は、後述する。

入金情報管理ＤＢは、テナント毎の入金情報管理テーブルによって構成される。入金情報管理テーブルには、販売者（サービス利用企業Ａ）の口座に送金された入金情報が格納されている。入金情報管理テーブルの詳細は、後述する。

取引条件管理ＤＢは、テナント毎の取引条件管理テーブルによって構成される。取引条件管理テーブルには、販売者（サービス利用企業Ａ）が設定した取引条件が格納されている。取引条件管理テーブルの詳細は、後述する。

支払条件管理ＤＢは、テナント毎の支払条件管理テーブルによって構成される。支払条件管理テーブルには、購入者（サービス利用企業Ｂ）が設定した支払条件が格納されている。支払条件管理テーブルの詳細は、後述する。

＜販売者端末の機能構成＞
図４に示されているように、本実施形態における販売者端末２０は、送受信部２１、受付部２２、表示制御部２４、判断部２５、記憶制御部２９及び記憶部２００を備える。これら各部は、図３に示されている各構成要素のいずれかが、ＨＤ５０４からＲＡＭ５０３上に展開されたプログラムに従ったＣＰＵ５０１からの命令によって動作することで実現される機能、又は機能する手段である。また、記憶部２００は、図３に示されているＲＡＭ５０３及びＨＤ５０４によって構築される。

送受信部２１は、図３に示されているＣＰＵ５０１からの命令、並びに外部機器接続Ｉ／Ｆ５０８及びネットワークＩ／Ｆ５０９によって実現され、通信ネットワークＮ１を介して他の端末、装置又はシステムと各種データ（または情報）の送受信を行う。

受付部２２は、主に、図３に示されているＣＰＵ５０１からの命令、並びにキーボード５１１及びポインティングデバイス５１２によって実現され、利用者による各種入力を受け付ける。

表示制御部２４は、主に、図３に示されているＣＰＵ５０１からの命令によって実現され、ディスプレイ５０６又は外部機器接続Ｉ／Ｆ５０８に接続された外付けのディスプレイに対して画像データを出力することで、画像を表示させる。表示制御部２４は、Ｗｅｂブラウザ機能を有している。

判断部２５は、主に、図３に示されているＣＰＵ５０１からの命令によって実現され、各種判断を行う。

記憶制御部２９は、主に、図３に示されているＣＰＵ５０１からの命令及びＨＤＤコントローラ５０５によって実現され、記憶部２００に各種データを記憶したり、記憶部２００に記憶された各種データを読み出したりする処理を行う。

＜購入者端末の機能構成＞
図４に示されているように、本実施形態における購入者端末３０は、送受信部３１、受付部３２、表示制御部３４、判断部３５、記憶制御部３９及び記憶部３００を備える。

購入者端末３０が備える送受信部３１、受付部３２、表示制御部３４、判断部３５、記憶制御部３９及び記憶部３００は、それぞれ、販売者端末２０が備える送受信部２１、受付部２２、表示制御部２４、判断部２５、記憶制御部２９及び記憶部２００と同様の機能を有しているため説明を省略する。

＜口座管理サーバの機能構成＞
図４に示されているように、本実施形態における口座管理サーバ４０は、送受信部４１、判断部４５、作成部４６、記憶制御部４９及び記憶部４００を有している。これら各部は、図３に示されている各構成要素のいずれかが、ＨＤ５０４からＲＡＭ５０３上に展開されたプログラムに従ったＣＰＵ５０１からの命令によって動作することで実現される機能又は機能する手段である。また、記憶部４００は、図３に示されているＲＡＭ５０３及びＨＤ５０４によって構築される。

送受信部４１は、図３に示されているＣＰＵ５０１からの命令及びネットワークＩ／Ｆ５０９によって実現され、通信ネットワークＮ１を介して他の端末、装置、又はシステムと各種データ（または情報）の送受信を行う。

判断部４５は、図３に示されているＣＰＵ５０１からの命令によって実現され、所定の判断を行う。判断内容は後述する。

作成部４６は、図３に示されているＣＰＵ５０１からの命令によって実現され、画面の作成等を行う。

記憶制御部４９は、図３に示されているＣＰＵ５０１からの命令及びＨＤＤコントローラ５０５によって実現され、記憶部４００に各種データを記憶したり、記憶部４００に記憶された各種データを読み出したりする処理を行う。

なお、口座管理サーバ４０は、金融機関により提供されるサーバ装置であってもよいし、金融機関システムと連携する所定のサービスにより提供されるサーバ装置であってもよい。

〔情報処理システムの処理手順〕
本実施形態における情報処理システムが実行する情報処理方法の処理手順を、図５乃至図４１を参照しながら説明する。

なお、本実施形態では、予め販売者と購入者との間で、請求締日及び支払サイトについて、契約等で合意しているものとする。本実施形態における支払サイトは、請求締日から支払日までの期間の上限である。

＜条件情報の登録＞
まず、本実施形態における条件情報登録処理（図１のステップＳ０）について、図５を参照しながら説明する。図５は、本実施形態における条件情報登録処理の一例を示すシーケンス図である。

ステップＳ１において、販売者端末２０が備える受付部２２が、販売者による取引条件の登録操作を受け付ける。販売者は、例えば、サービス利用企業Ａの業務を遂行する担当者である。

取引条件の登録操作は、取引条件設定画面において行われる。取引条件設定画面は、例えば、取引管理サーバ１０が提供するメインメニュー画面において、取引条件設定メニューを選択することで表示される。

（取引条件設定画面）
ここで、本実施形態における取引条件設定画面について、図６を参照しながら説明する。図６は、本実施形態における取引条件設定画面の一例を示す概念図である。

図６に示されているように、本実施形態における取引条件設定画面３０００は、取引先入力欄３００１、支払サイト入力欄３００２、請求締日入力欄３００３、登録ボタン３００８及びキャンセルボタン３００９を有する。

販売者が登録ボタン３００８を押下すると、受付部２２が、取引条件の登録操作を受け付ける。販売者がキャンセルボタン３００９を押下すると、表示制御部２４が、取引条件設定画面３０００を閉じる。

取引条件設定画面には、販売者と購入者との間で事前に合意した取引条件を設定する。事前の合意は、例えば、契約書で行われる。図６の例では、月末までの１か月間に納品された商品について一括して購入者に請求することを表している。購入者は、請求書を受領した後、請求締日の翌月末までに請求金額を支払う必要がある。例えば、９月１日から９月３０日までに納品され、請求された明細について、１０月３１日までに支払う必要がある。

図５に戻って説明する。ステップＳ２において、販売者端末２０が備える送受信部２１は、取引条件の登録要求を取引管理サーバ１０に送信する。当該登録要求には、取引条件設定画面３０００で入力された取引条件が含まれる。取引管理サーバ１０では、送受信部１１が、取引条件の登録要求を販売者端末２０から受信する。

ステップＳ３において、取引管理サーバ１０が備える記憶制御部１９は、取引条件の登録要求に含まれる取引条件を取引条件管理ＤＢに登録する。

（取引条件管理テーブル）
ここで、取引条件管理テーブルの詳細について、図７を参照しながら説明する。図７は、本実施形態における取引条件管理テーブルの一例を示す概念図である。

図７に示されているように、本実施形態における取引条件管理テーブル１８００では、取引先を表す情報（取引先の会社名等）、支払サイト及び請求締日等が関連付けて管理されている。

図５に戻って説明する。ステップＳ４において、購入者端末３０が備える受付部３２が、購入者による支払条件の登録操作を受け付ける。購入者は、例えば、サービス利用企業Ｂの業務を遂行する担当者である。

支払条件の登録操作は、支払条件設定画面において行われる。支払条件設定画面は、例えば、取引管理サーバ１０が提供するメインメニュー画面において、支払条件設定メニューを選択することで表示される。

（支払条件設定画面）
ここで、本実施形態における支払条件設定画面について、図８を参照しながら説明する。図８は、本実施形態における支払条件設定画面の一例を示す概念図である。

図８に示されているように、本実施形態における支払条件設定画面３１００は、支払締日入力欄３１０１、支払予定日入力欄３１０２、登録ボタン３１０８及びキャンセルボタン３１０９を有する。

購入者が登録ボタン３１０８を押下すると、受付部３２が、支払条件の登録操作を受け付ける。購入者がキャンセルボタン３１０９を押下すると、表示制御部３４が、支払条件設定画面３１００を閉じる。

支払条件設定画面には、購入者の支払に関する支払条件を設定する。支払条件は、事前に合意していなくともよい。ただし、購入者が実際に行う支払は、事前に合意した取引条件を満たさなければならない。図８の例では、前月２６日から当月２５日までに納品が確認された商品に関する代金を一括して翌月の２０日までに支払いを行うことを表している。

図５に戻って説明する。ステップＳ５において、購入者端末３０が備える送受信部３１は、支払条件の登録要求を取引管理サーバ１０に送信する。当該登録要求には、支払条件設定画面３１００で入力された支払条件が含まれる。取引管理サーバ１０では、送受信部１１が、支払条件の登録要求を購入者端末３０から受信する。

ステップＳ６において、取引管理サーバ１０が備える記憶制御部１９は、支払条件の登録要求に含まれる支払条件を支払条件管理ＤＢに登録する。

（支払条件管理テーブル）
ここで、支払条件管理テーブルの詳細について、図９を参照しながら説明する。図９は、本実施形態における支払条件管理テーブルの一例を示す概念図である。

図９に示されているように、本実施形態における支払条件管理テーブル１９００では、支払締日及び支払予定日等が関連付けて管理されている。

＜請求書作成及び送付＞
次に、本実施形態における請求書作成及び送付処理（図１のステップＳ１）について、図１０を参照しながら説明する。図１０は、本実施形態における請求書作成及び送付処理の一例を示すシーケンス図である。

ステップＳ１１において、販売者端末２０が備える受付部２２は、販売者による請求書作成画面の表示操作を受け付ける。販売者は、例えば、サービス利用企業Ａの業務を遂行する担当者である。

受付部２２は、請求書作成画面の表示操作を受け付ける前に、販売者によって入力されたテナントの識別情報であるテナントＩＤ等の認証情報を受け付ける。そして、送受信部２１は、認証情報を取引管理サーバ１０に送信し、取引管理サーバ１０において所定の認証処理を行う。取引管理サーバ１０は、テナント情報管理ＤＢを用いて、販売者の認証を行う。したがって、販売者が取引管理サーバ１０において認証された場合のみ、受付部２２は、販売者による請求書作成画面の表示操作を受け付けることができる。

（テナント情報管理テーブル）
ここで、テナント情報管理テーブルの詳細について、図１１を参照しながら説明する。図１１は、本実施形態におけるテナント情報管理テーブルの一例を示す概念図である。

図１１に示されているように、本実施形態におけるテナント情報管理テーブル１０００では、テナントを表す情報（会社名等）、認証情報（ユーザＩＤ及びパスワード等）、連絡先（メールアドレス及び住所等）及び振込先の口座情報等が関連付けて管理されている。

本実施形態においては、テナントは販売者としても購入者としてもサービスを利用することができるものとする。ただし、テナント情報として販売者又は購入者等を表すユーザロールを登録することで、特定のテナントを販売者のみ又は購入者のみとしてサービスを利用するように制限してもよい。

図１０に戻って説明する。ステップＳ１２において、販売者端末２０が備える送受信部２１は、請求書作成画面の取得要求を取引管理サーバ１０に送信する。取引管理サーバ１０では、送受信部１１が、請求書作成画面の取得要求を販売者端末２０から受信する。

ステップＳ１３において、取引管理サーバ１０が備える記憶制御部１９は、売掛帳情報管理ＤＢから売掛帳情報を読み出す。次に、作成部１６が、記憶制御部１９が読み出した売掛帳情報に基づいて、請求書作成画面の画面データを作成する。

共通請求書ＩＤは、各テナントで共通して管理するために取引管理サーバ１０が各請求書情報に設定する識別情報である。請求書ＩＤは、テナントが任意に請求書情報に設定する識別情報である。したがって、以降の処理において、取引管理サーバ１０が請求書情報を特定するために用いる識別情報は、共通請求書ＩＤである。ただし、請求書ＩＤが各テナント間で重複しないように制御可能であれば、共通請求書ＩＤに代えて請求書ＩＤを用いてもよい。

（売掛帳情報管理テーブル）
ここで、売掛帳情報管理テーブルの詳細について、図１２を参照しながら説明する。図１２は、本実施形態における売掛帳情報管理テーブルの一例を示す概念図である。

図１２に示されているように、本実施形態における売掛帳情報管理テーブル１１００では、売掛が発生した日付（以下、「売掛日付」とも呼ぶ）、請求書を識別する識別情報（共通請求書ＩＤ及び請求書ＩＤ等）、請求書中の明細に関する情報（明細ＩＤ、商品コード、単価、数量、金額等）及び入金に関する情報（入金数量及び入金額）等が関連付けて管理されている。

図１２に示した売掛帳情報の例は、売掛帳からインポートされた初期状態である。初期状態では、各識別情報（共通請求書ＩＤ、請求書ＩＤ及び明細ＩＤ）及び入金に関する情報（入金数量及び入金額）は空欄となる。

≪請求書作成画面データの作成≫
ここで、本実施形態における請求書作成画面データの作成処理（図１０のステップＳ１３）について、図１３を参照しながら説明する。図１３は、本実施形態における請求書作成画面データの作成処理の一例を示す概念図である。

ステップＳ１３－１において、記憶制御部１９は、売掛帳情報管理ＤＢから、売掛日付が請求期間内で、かつ、入金数量及び入金額が空欄の売掛帳情報を取得する。

ステップＳ１３－２において、判断部１５は、取引先の支払条件を優先するか否かを判定する。取引先の支払条件を優先するか否かは、予め登録されているものとする。取引先の支払条件を優先する場合（ＹＥＳ）、判断部１５は、ステップＳ１３－３に処理を進める。取引先の支払条件を優先しない場合（ＮＯ）、判断部１５は、ステップＳ１３－５に処理を進める。

ステップＳ１３－３において、記憶制御部１９は、取引条件管理ＤＢから、販売者の請求締日を取得する。次に、記憶制御部１９は、支払条件管理ＤＢから、購入者の支払締日を取得する。

ステップＳ１３－４において、判断部１５は、ステップＳ１３－３で取得した請求締日と支払締日との前後関係を判定する。支払締日が請求締日より前である場合、判断部１５は、ステップＳ１３－６に処理を進める。請求締日が支払締日より前である場合、判断部１５は、ステップＳ１３－７に処理を進める。

ステップＳ１３－５において、作成部１６は、ステップＳ１３－１で取得した売掛帳情報を請求対象として表示することを決定する。

ステップＳ１３－６において、作成部１６は、ステップＳ１３－１で取得した売掛帳情報のうち、売掛日付が支払締日以前の売掛帳情報を請求対象として表示することを決定する。

ステップＳ１３－７において、記憶制御部１９は、売掛日付が請求締日の翌日から次の請求期間の支払締日までの期間に含まれる売掛帳情報を取得する。次に、記憶制御部１９は、ステップＳ１３－１で取得した売掛帳情報とステップＳ１３－７で取得した売掛帳情報とを請求対象として表示することを決定する。

ステップＳ１３－８において、作成部１６は、請求対象として表示することを決定した売掛帳情報の金額の合計を計算する。なお、計算した金額は、請求書の請求金額として請求書作成画面に表示される。

ステップＳ１３－９において、作成部１６は、請求締日に支払サイトの日数を加算した日付を計算する。なお、計算した日付は、請求書の支払期限日として請求書作成画面に表示される。

ステップＳ１３－１０において、作成部１６は、ステップＳ１３－１からＳ１３－９で取得した情報に基づいて、請求書作成画面の画面データを作成する。

図１０に戻って説明する。ステップＳ１４において、取引管理サーバ１０が備える送受信部１１は、作成部１６が作成した請求書作成画面の画面データを販売者端末２０に送信する。販売者端末２０では、送受信部２１が、請求書作成画面の画面データを取引管理サーバ１０から受信する。

ステップＳ１５において、販売者端末２０が備える表示制御部２４は、請求書作成画面の画面データに基づいて、請求書作成画面をディスプレイ５０６に表示する。

（請求書作成画面）
ここで、本実施形態における請求書作成画面について、図１４を参照しながら説明する。図１４は、本実施形態における請求書作成画面の一例を示す概念図である。

図１４に示されているように、本実施形態における請求書作成画面２０００は、条件設定領域２０１０、売掛帳表示領域２０２０、支払期限表示欄２０３０、作成ボタン２００８及びキャンセルボタン２００９を有する。条件設定領域２０１０には、取引先の支払条件を優先するか否かを選択するための取引先優先選択欄２０１１が表示される。

条件設定領域２０１０において、請求先及び請求期間等の条件を入力すると、当該条件に合致する売掛帳情報が売掛帳表示領域２０２０に表示される。条件設定領域２０１０に表示される各条件値は、予め設定しておいてもよい。例えば、請求期間は、前月の請求締日の翌日から当月の請求締日に設定すればよい。

売掛帳表示領域２０２０には、売掛帳情報の内容が各明細を選択可能な形態で表示される。例えば、各明細に対して１つのチェックボックスを表示することで、当該明細を選択可能に表示することができる。初期状態では、すべての明細が選択されているものとする。

販売者が取引先優先選択欄２０１１を選択すると、売掛帳表示領域２０２０に表示された売掛帳情報のうち、取引先の支払条件に合致する売掛帳情報が選択される。また、その他の売掛帳情報は選択が解除される。初期状態では、取引先優先選択欄２０１１は非選択（すなわち、自社の取引条件を優先する）とする。

販売者が作成ボタン２００８を押下すると、受付部２２が、請求書の作成（請求書情報の生成）操作を受け付ける。販売者がキャンセルボタン２００９を押下すると、表示制御部２４が、請求書作成画面２０００を閉じる。

図１５は、取引先優先を選択した請求書作成画面の一例を示す概念図である。図１５に示されているように、取引先優先を選択した場合、取引先の支払条件に合致しない売掛帳情報の選択が解除される。ここでは、取引先の支払締日が２５日に設定されているため、売掛日付が２０２０年９月２９日である売掛帳情報の選択が解除されていることがわかる。また、請求金額は、選択が解除された売掛帳情報の請求金額を減算した金額となっていることがわかる。

取引先優先を選択した状態で、選択が解除された売掛帳情報を選択しようとした場合、取引先の支払条件に合致しない旨を示す警告を表示してもよい。例えば、売掛日付が２０２０年９月２９日である売掛帳情報は、取引先の支払締日である９月２５日を過ぎているため、例えば「取引先の支払締日を超過しています」といったメッセージをディスプレイ５０６に表示すればよい。

図１０に戻って説明する。ステップＳ１６において、販売者端末２０が備える受付部２２は、販売者による請求書の作成（請求書情報の生成）操作を受け付ける。具体的には、販売者は、請求書作成画面２０００において、請求書に含める明細を選択し、作成ボタン２００８を押下する。

ステップＳ１７において、販売者端末２０が備える送受信部２１は、請求書情報の登録要求を取引管理サーバ１０に送信する。当該登録要求には、売掛帳表示領域２０２０において選択された売掛帳情報が含まれる。取引管理サーバ１０では、送受信部１１が、請求書情報の登録要求を販売者端末２０から受信する。

ステップＳ１８において、取引管理サーバ１０が備える作成部１６は、請求書情報の登録要求に基づいて、図１６に示すような請求書画像を生成し、所定の保存先に記憶する。このとき、作成部１６は、当該請求書を受領するための受領画面にアクセスするためのＵＲＬ（Uniform Resource Locator）である受領画面ＵＲＬを作成する。

次に、記憶制御部１９は、請求書の内容を表す請求書情報を生成し、発行請求書情報管理ＤＢに登録する。また、記憶制御部１９は、生成した請求書情報に基づいて、売掛帳情報管理ＤＢを更新する。このとき、記憶制御部１９は、請求書を識別する共通請求書ＩＤ及び請求書ＩＤ、並びに各明細を識別する明細ＩＤを発行する。

（発行請求書情報管理テーブル）
ここで、発行請求書情報管理テーブルの詳細について、図１７を参照しながら説明する。図１７は、本実施形態における発行請求書情報管理テーブルの一例を示す概念図である。

図１７に示されているように、本実施形態における発行請求書情報管理テーブル１３００では、請求書を識別する識別情報（共通請求書ＩＤ及び請求書ＩＤ等）、請求書の請求先を表す情報（請求先の会社名等）、請求金額、請求日、支払期限日、請求書状態、請求書画像保存先、取引先優先、明細に関する情報（明細ＩＤ、商品コード、商品名、単価、数量及び金額等）及び振込先情報等が関連付けて管理されている。

これらのうち、請求金額は、選択された売掛帳情報の金額の総額が設定される。支払期限日は、購入者に対応する支払サイトに基づいて自動的に設定される。例えば、購入者が支払サイト３０（日）である場合、支払期限日は翌月末となる。また、例えば、購入者が支払サイト６０（日）である場合、支払期限日は翌々月末となる。請求書状態は、「作成済み」に設定される。振込先情報は、テナント情報管理テーブルから取得する。

図１８は、取引先優先を選択した請求書作成画面の一例を示す概念図である。図１８に示されているように、取引先優先を選択した場合、取引先の支払条件に合致しない売掛帳情報に基づく明細が請求書情報に含まれなくなる。ここでは、共通請求書ＩＤがabcd1235である請求書情報から、売掛日付が２０２０年９月２９日である売掛帳情報に基づく５個のホワイトボードと３５個の椅子に関する明細が削除されていることがわかる。また、請求金額は、削除された明細に関する請求金額を減算した金額となっていることがわかる。

図１９に、請求書作成後の売掛帳情報管理テーブルの一例を示す。図１９に示されているように、請求書作成後の売掛帳情報管理テーブルでは、請求書を発行した売掛帳情報に、共通請求書ＩＤ、請求書ＩＤ及び明細ＩＤが登録されている。

図２０は、取引先優先を選択した場合における、請求書作成後の売掛帳情報管理テーブルの一例を示す概念図である。図２０に示されているように、取引先優先を選択した場合の売掛帳情報管理テーブルでは、請求書に含まれない売掛帳情報には、共通請求書ＩＤ、請求書ＩＤ及び明細ＩＤが登録されていない。ここでは、売掛日付が２０２０年９月２９日である売掛帳情報は、共通請求書ＩＤ、請求書ＩＤ及び明細ＩＤが空欄となっていることがわかる。

図１０に戻って説明する。ステップＳ１９において、販売者端末２０が備える受付部２２は、販売者による請求書の送付操作を受け付ける。請求書の送付操作は、請求書送付画面において行われる。請求書送付画面は、例えば、作成済みの請求書の一覧を表示する画面において、送付したい請求書を選択することで表示される。

（請求書送付画面）
ここで、本実施形態における請求書送付画面について、図２１を参照しながら説明する。図２１は、本実施形態における請求書送付画面の一例を示す概念図である。

図２１に示されているように、本実施形態における請求書送付画面２１００は、送付先選択欄２１０１、請求書画像表示欄２１０２、送付状入力欄２１０３、送付ボタン２１０８及びキャンセルボタン２１０９を有する。

これらのうち、送付先選択欄２１０１には、テナント情報管理テーブルにおいて購入者に関連付けられたメールアドレスが選択可能に表示される。請求書画像表示欄２１０２には、発行請求書情報管理テーブルの請求書画像保存先が示す請求書画像が表示される。

送付状入力欄２１０３には、請求書送付時に記載する件名及び本文を入力する。件名及び本文は予め定めたテンプレートが初期表示されるとよい。送付状入力欄２１０３には、受領画面ＵＲＬのリンクが埋め込まれる。

販売者が送付ボタン２１０８を押下すると、受付部２２が、請求書の送付操作を受け付ける。販売者がキャンセルボタン２１０９を押下すると、表示制御部２４が、請求書送付画面２１００を閉じる。

図１０に戻って説明する。ステップＳ２０において、販売者端末２０が備える送受信部２１は、請求書の送付要求を取引管理サーバ１０に送信する。当該送付要求には、共通請求書ＩＤが含まれる。取引管理サーバ１０では、送受信部１１が、請求書の送付要求を販売者端末２０から受信する。

ステップＳ２１において、取引管理サーバ１０が備える記憶制御部１９は、請求書の送付要求に含まれる共通請求書ＩＤに基づいて、発行請求書情報管理テーブルにおいて請求書情報を特定する。次に、記憶制御部１９は、特定された請求書情報の請求書状態を「送付済み」に更新する。

ステップＳ２２において、取引管理サーバ１０が備える記憶制御部１９は、請求書の送付要求に基づいて受領情報を生成し、受領情報管理ＤＢに登録する。

（受領情報管理テーブル）
ここで、受領情報管理テーブルの詳細について、図２２を参照しながら説明する。図２２は、本実施形態における受領情報管理テーブルの一例を示す概念図である。

図２２に示されているように、本実施形態における受領情報管理テーブル１４００では、請求書を識別する識別情報（共通請求書ＩＤ及び請求書ＩＤ等）、請求書の発行元を表す情報（発行元の会社名等）、発行日及び受領画面ＵＲＬ等が関連付けて管理されている。

図１０に戻って説明する。ステップＳ２３において、取引管理サーバ１０が備える送受信部１１は、受領画面ＵＲＬを含む電子メールを購入者端末３０に送信する。なお、送受信部１１は、受領画面ＵＲＬを含む電子メールを購入者端末３０に直接送信しなくてもよい。例えば、送受信部１１が、購入者側の所定のメールアドレス宛に電子メールを送信し、購入者端末３０が、メールサーバから電子メールを受信するようにしてもよい。

受領画面ＵＲＬの送信方法は電子メールに限定されない。例えば、メッセンジャーアプリを介して、受領画面ＵＲＬを含むメッセージを購入者端末３０に送信してもよい。さらに、作成部１６が、受領画面ＵＲＬを示す二次元コードを作成し、当該二次元コードを請求書画像に埋め込み、送受信部１１が、二次元コードが埋め込まれた請求書画像を印刷装置に送信し、請求書画像を記録紙に印刷出力し、印刷した紙の請求書を購入者側に郵送で送付することもできる。

＜請求書受領処理＞
次に、本実施形態における請求書受領処理（図１のステップＳ２）について、図２３を参照しながら説明する。図２３は、本実施形態における請求書受領処理の一例を示すシーケンス図である。

ステップＳ３１において、購入者端末３０が備える送受信部３１は、受領画面ＵＲＬを含む電子メール等を受信する。次に、受付部３２が、購入者による請求書受領画面の表示操作を受け付ける。購入者は、例えば、サービス利用企業Ｂの業務を遂行する担当者である。請求書受領画面の表示操作は、例えば、電子メールに含まれる受領画面ＵＲＬを開く操作（すなわち、電子メール中の受領画面ＵＲＬのリンクをクリックする操作）である。

ステップＳ３２において、購入者端末３０が備える送受信部３１は、請求書受領画面の取得要求を取引管理サーバ１０に送信する。当該取得要求には、受領画面ＵＲＬが含まれる。取引管理サーバ１０では、送受信部１１が、請求書受領画面の取得要求を購入者端末３０から受信する。

ステップＳ３３において、取引管理サーバ１０が備える記憶制御部１９は、請求書受領画面の取得要求に含まれる受領画面ＵＲＬに基づいて、受領情報管理ＤＢから受領情報管理テーブル１４００を用いて受領情報を読み出す。次に、記憶制御部１９は、読み出した受領情報に含まれる共通請求書ＩＤに基づいて、発行請求書情報管理ＤＢから発行請求書情報管理テーブル１３００を用いて請求書情報を読み出す。続いて、作成部１６が、記憶制御部１９が読み出した受領情報及び請求書情報に基づいて、請求書受領画面の画面データを作成する。

ステップＳ３４において、取引管理サーバ１０が備える送受信部１１は、作成部１６が作成した請求書受領画面の画面データを購入者端末３０に送信する。購入者端末３０では、送受信部３１が、請求書受領画面の画面データを取引管理サーバ１０から受信する。

ステップＳ３５において、購入者端末３０が備える表示制御部３４は、請求書受領画面の画面データに基づいて、請求書受領画面をディスプレイ５０６に表示する。

（請求書受領画面）
ここで、本実施形態における請求書受領画面について、図２４を参照しながら説明する。図２４は、本実施形態における請求書受領画面の一例を示す概念図である。

図２４に示されているように、本実施形態における請求書受領画面２２００は、請求書画像表示欄２２０１、ダウンロードボタン２２０２及び受領ボタン２２０３を有する。

これらのうち、請求書画像表示欄２２０１には、発行請求書情報管理テーブルの請求書画像保存先が示す請求書画像が表示される。

購入者がダウンロードボタン２２０２を押下すると、送受信部３１が、請求書画像のダウンロードを行い、記憶制御部３９が、ダウンロードした請求書画像を記憶部３００の所定の保存先に記憶する。購入者が受領ボタン２２０３を押下すると、受付部３２が、請求書の受領操作を受け付ける。

図２３に戻って説明する。ステップＳ３６において、購入者端末３０が備える受付部３２は、購入者による請求書の受領操作を受け付ける。具体的には、購入者は、請求書受領画面２２００において、受領ボタン２２０３を押下する。

ステップＳ３７において、購入者端末３０が備える送受信部３１は、請求書の受領要求を取引管理サーバ１０に送信する。当該受領要求には、共通請求書ＩＤが含まれる。取引管理サーバ１０では、送受信部１１が、請求書の受領要求を購入者端末３０から受信する。

ステップＳ３８において、取引管理サーバ１０が備える記憶制御部１９は、請求書の受領要求に含まれる共通請求書ＩＤに基づいて、発行請求書情報管理テーブルにおいて請求書情報を特定する。次に、記憶制御部１９は、特定された請求書情報の請求書状態を「受領済み」に更新する。

ステップＳ３９において、取引管理サーバ１０が備える記憶制御部１９は、発行請求書情報管理テーブルで特定された請求書情報を受領請求書情報管理ＤＢに登録する。

（受領請求書情報管理テーブル）
ここで、受領請求書情報管理テーブルの詳細について、図２５を参照しながら説明する。図２５は、本実施形態における受領請求書情報管理テーブルの一例を示す概念図である。

図２５に示されているように、本実施形態における受領請求書情報管理テーブル１５００では、請求書を識別する識別情報（共通請求書ＩＤ及び請求書ＩＤ等）、請求書の請求先を表す情報（請求先の会社名等）、請求金額、請求日、支払期限日、請求書画像保存先、明細に関する情報（明細ＩＤ、商品コード、商品名、単価、数量、金額等）及び振込先情報等が関連付けて管理されている。すなわち、受領請求書情報管理テーブルは、発行請求書情報管理テーブルと比較して、請求書状態を有さない点のみが異なる。

＜送金データ作成処理＞
次に、本実施形態における送金データ作成処理（図１のステップＳ３）について、図２６を参照しながら説明する。図２６は、本実施形態における送金データ作成処理の一例を示すシーケンス図である。

ステップＳ４１において、購入者端末３０が備える受付部３２は、購入者による支払処理画面の表示操作を受け付ける。支払処理画面の表示操作は、受領請求書一覧画面において行われる。

（受領請求書一覧画面）
ここで、本実施形態における受領請求書一覧画面について、図２７を参照しながら説明する。図２７は、本実施形態における受領請求書一覧画面の一例を示す概念図である。

図２７に示されているように、本実施形態における受領請求書一覧画面２３００は、請求書一覧表示欄２３０１を有する。請求書一覧表示欄２３０１には、受領済みの請求書に関する情報（請求元、請求書番号、合計金額及び発行日等）が一覧で表示される。請求書一覧表示欄２３０１に表示される各請求書には、表示ボタン２３０２、ダウンロードボタン２３０３及び支払処理ボタン２３０４が表示される。

購入者が表示ボタン２３０２を押下すると、当該請求書に対応する請求書画像がディスプレイ５０６に表示される。購入者がダウンロードボタン２３０３を押下すると、送受信部３１が、請求書画像のダウンロードを行い、記憶制御部３９が、ダウンロードした請求書画像を記憶部３００の所定の保存先に記憶する。購入者が支払処理ボタン２３０４を押下すると、受付部３２が、支払処理画面の表示操作を受け付ける。

図２６に戻って説明する。ステップＳ４２において、購入者端末３０が備える送受信部３１は、支払処理画面の取得要求を取引管理サーバ１０に送信する。当該取得要求には、共通請求書ＩＤが含まれる。取引管理サーバ１０では、送受信部１１が、支払処理画面の取得要求を購入者端末３０から受信する。

ステップＳ４３において、取引管理サーバ１０が備える記憶制御部１９は、支払処理画面の取得要求に含まれる共通請求書ＩＤに基づいて、受領請求書情報管理ＤＢから請求書情報を読み出す。次に、記憶制御部１９は、読み出した請求書情報に含まれる共通請求書ＩＤに基づいて、買掛帳情報管理ＤＢから買掛帳情報を読み出す。続いて、作成部１６が、記憶制御部１９が読み出した請求書情報及び買掛帳情報に基づいて、支払処理画面の画面データを作成する。

（買掛帳情報管理テーブル）
ここで、買掛帳情報管理テーブルの詳細について、図２８を参照しながら説明する。図２８は、本実施形態における買掛帳情報管理テーブルの一例を示す概念図である。

図２８に示されているように、本実施形態における買掛帳情報管理テーブルでは、買掛が発生した日付（以下、「買掛日付」とも呼ぶ）、請求書を識別する識別情報（共通請求書ＩＤ及び請求書ＩＤ等）、請求書中の明細に関する情報（明細ＩＤ、商品コード、単価、数量、金額等）及び支払に関する情報（支払数量及び支払金額）等が関連付けて管理されている。

図２８に示した買掛帳情報の例は、買掛帳からインポートされた初期状態である。初期状態では、各識別情報（共通請求書ＩＤ、請求書ＩＤ及び明細ＩＤ）及び支払に関する情報（支払数量及び支払金額）は空欄となる。

≪支払処理画面データの作成≫
ここで、本実施形態における支払処理画面データの作成処理（図２６のステップＳ４３）について、図２９を参照しながら説明する。図２９は、本実施形態における支払処理画面データの作成処理の一例を示す概念図である。

ステップＳ４３－１において、記憶制御部１９は、受領請求書情報管理ＤＢから、共通請求書ＩＤで特定される請求書情報を取得する。

ステップＳ４３－２において、記憶制御部１９は、買掛帳情報管理ＤＢから、買掛日付が支払期間内で、かつ、支払数量及び支払金額が空欄の買掛帳情報を取得する。

ステップＳ４３－３において、判断部１５は、請求書情報の取引先優先に基づいて、取引先の支払条件を優先するか否かを判定する。取引先の支払条件を優先する場合（ＹＥＳ）、判断部１５は、ステップＳ４３－８に処理を進める。取引先の支払条件を優先しない場合（ＮＯ）、判断部１５は、ステップＳ４３－４に処理を進める。

ステップＳ４３－４において、記憶制御部１９は、支払条件管理ＤＢから、購入者の支払締日を取得する。

ステップＳ４３－５において、作成部１６は、ステップＳ４３－２で取得した買掛帳情報の明細のうち、ステップＳ４３－１で取得した請求書情報に含まれない明細を取得する。

ステップＳ４３－６において、判断部１５は、ステップＳ４３－５で明細を取得したか否かを判定する。取得した明細がある場合（ＹＥＳ）、判断部１５は、ステップＳ４３－７に処理を進める。取得した明細がない場合（ＮＯ）、判断部１５は、ステップＳ４３－８に処理を進める。

ステップＳ４３－７において、判断部１５は、ステップＳ４３－５で取得した各明細について、支払サイトを満たすか否かを判定する。具体的には、まず、判断部１５は、買掛日付から支払予定日を計算する。次に、判断部１５は、請求締日と支払サイトに基づいて支払期限日を計算する。そして、支払予定日が支払期限日以前であるか否かを判定する。判断部１５は、支払サイトを満たす各明細を、支払対象として表示することを決定する。

ステップＳ４３－８において、作成部１６は、ステップＳ４３－１で取得した請求書情報とステップＳ４３－２で取得した買掛帳情報とで一致する各明細を、支払対象として表示することを決定する。

ステップＳ４３－９において、作成部１６は、現在日時と支払条件の支払予定日に基づいて、次の支払日を計算する。なお、計算した支払日は、支払日として支払処理画面に表示される。

ステップＳ４３－１０において、作成部１６は、ステップＳ４３－１からＳ４３－９で取得した情報に基づいて、支払処理画面の画面データを作成する。

図２６に戻って説明する。ステップＳ４４において、取引管理サーバ１０が備える送受信部１１は、作成部１６が作成した支払処理画面の画面データを購入者端末３０に送信する。購入者端末３０では、送受信部３１が、支払処理画面の画面データを取引管理サーバ１０から受信する。

ステップＳ４５において、購入者端末３０が備える表示制御部３４は、支払処理画面の画面データに基づいて、支払処理画面をディスプレイ５０６に表示する。

（支払処理画面）
ここで、本実施形態における支払処理画面について、図３０を参照しながら説明する。図３０は、本実施形態における支払処理画面の一例を示す概念図である。

図３０に示されているように、本実施形態における支払処理画面２４００は、条件設定領域２４１０、買掛帳情報表示欄２４２０、請求書情報表示欄２４３０、明細情報表示欄２４４０、数量入力ボタン２４４１、支払情報表示欄２４５０、買掛帳情報表示欄２４６０、作成ボタン２４０８及びキャンセルボタン２４０９を有する。

条件設定領域２４１０において、支払締日及び支払期間等の条件を入力すると、当該条件に合致する買掛帳情報が買掛帳情報表示欄２４２０に表示される。条件設定領域２４１０に表示される各条件値は、予め設定しておいてもよい。例えば、支払期間は、前月の支払締日の翌日から当月の支払締日に設定すればよい。

請求書情報表示欄２４３０には、請求書情報の内容（請求書ＩＤ、請求金額、請求日、支払期限日及び取引先優先等）が表示される。明細情報表示欄２４４０には、請求書情報に含まれる明細に関する情報（商品名、数量、単価及び金額等）が各明細を選択可能な形態で表示される。

買掛帳情報表示欄２４６０には、買掛日付が次の支払期間に含まれる買掛帳情報が表示される。購入者の支払条件（支払締日が２５日）に従えば、２０２０年９月２９日の売掛帳情報は支払対象外となる。しかしながら、次の支払期間に支払うと、支払日が１１月２０日となるため、支払サイト３０の条件（支払期限日は１０月３１日）を満足できなくなる。そのため、２０２０年９月２９日の売掛帳情報も今回の支払対象に含める必要がある。

仮に、販売者との合意により、支払締日が月末かつ支払サイト６０であった場合、２０２０年９月２９日の売掛帳情報は支払サイト６０の条件（支払期限日は１１月３０日）を満足できる。そのため、２０２０年９月２９日の売掛帳情報は今回の支払対象に含める必要がなくなる。

明細情報表示欄２４４０では、買掛帳情報及び請求書情報に含まれる各明細の照合が行われる。買掛帳情報及び請求書情報両方に含まれる明細は、自動的に選択される。このとき、買掛帳情報の数量と請求書情報の数量が一致しない場合、両方の数量が把握できるように表示する。例えば、「買掛帳情報の数量／請求書情報の数量」といった書式で表示すればよい。

数量入力ボタン２４４１は、明細情報表示欄２４４０に表示された各明細に対して１つの数量入力ボタン２４４１が表示される。数量入力ボタン２４４１を押下すると、数量を入力するためのダイアログ画面が表示され、当該明細に対して支払いを行う数量を入力することができる。

なお、明細情報表示欄２４４０で選択されていない明細に対応する数量入力ボタン２４４１は、押下不可に制御してもよい。

支払情報表示欄２４５０には、請求書情報に含まれる振込先情報が表示される。支払情報表示欄２４５０の支払日は、購入者の支払条件に設定した支払予定日（ここでは、翌月２０日）が自動的に入力される。ただし、購入者が手動で修正することも可能である。

購入者が作成ボタン２４０８を押下すると、受付部３２が、送金データの作成操作を受け付ける。購入者がキャンセルボタン２４０９を押下すると、表示制御部３４が、支払処理画面２４００を閉じる。

図３１は、取引先優先を選択した場合の支払処理画面の一例を示す概念図である。図３１に示されているように、取引先優先を選択した場合、買掛帳情報表示欄２４６０は表示されない。取引先優先を選択した場合、購入者の支払条件に合致するように請求書が作成されているため、請求書に記載された通りに支払いをすればよいためである。

図２６に戻って説明する。ステップＳ４６において、購入者端末３０が備える受付部３２は、購入者による送金データの作成操作を受け付ける。具体的には、購入者は、支払処理画面２４００において、送金データに含める明細を選択し、作成ボタン２４０８を押下する。

ステップＳ４７において、購入者端末３０が備える送受信部３１は、送金データの作成要求（以下、「支払要求」とも呼ぶ）を取引管理サーバ１０に送信する。当該作成要求には、請求書ＩＤ、明細ＩＤ及び各明細に対して入力された数量が含まれる。当該作成要求に含まれる明細ＩＤは、明細情報表示欄２４４０において選択された明細の明細ＩＤである。取引管理サーバ１０では、送受信部１１が、送金データの作成要求を購入者端末３０から受信する。

ステップＳ４８において、作成部１６は、送金データの作成要求に基づいて、当該支払を識別する支払ＩＤを発行する。次に、作成部１６は、支払ＩＤが埋め込まれた送金データを作成する。支払ＩＤは、ＥＤＩ（Electronic Data Interchange）情報として送金データに埋め込むことができる。また、全銀ＥＤＩシステムにおける取引明細の特定の項目（例えば、備考等）に埋め込んでもよい。

支払ＩＤは、取引管理サーバ１０が発行しなくともよい。例えば、送金データを作成した際に金融機関Ｄ１から発行される支払情報ＩＤを支払ＩＤとして利用してもよい。

ステップＳ４９において、取引管理サーバ１０が備える記憶制御部１９は、送金データの内容を表す支払情報を生成し、支払情報管理ＤＢに登録する。また、記憶制御部１９は、送金データの作成要求に基づいて、買掛帳情報管理ＤＢを更新する。

（支払情報管理テーブル）
ここで、支払情報管理テーブルの詳細について、図３２を参照しながら説明する。図３２は、本実施形態における支払情報管理テーブルの一例を示す概念図である。

図３２に示されているように、本実施形態における支払情報管理テーブル１６００では、送金データの内容を表す情報（支払ＩＤ、支払金額及び支払予定日等）、請求書を識別する識別情報（共通請求書ＩＤ及び請求書ＩＤ等）及び明細に関する情報（明細ＩＤ、数量及び金額等）等が関連付けて管理されている。

図３３に、送金データ作成後の買掛帳情報管理テーブルの一例を示す。図３３に示されているように、送金データ作成後の買掛帳情報管理テーブルでは、送金データを作成した買掛帳情報に、共通請求書ＩＤ、請求書ＩＤ及び明細ＩＤが登録されている。

図２６に戻って説明する。ステップＳ５０において、取引管理サーバ１０が備える送受信部１１は、支払ＩＤが埋め込まれた送金データを購入者端末３０に送信する。

その後、購入者は、ダウンロードした送金データを用いる送金の実行を、所定の手順に従って指示する。例えば、購入者は、サービス利用企業Ｂの口座を管理するファームバンキングやインターネットバンキング等の金融機関Ｄ１が提供した所定の画面を介して、送金データをアップロードすることで、送金の実行を指示する。そして、サービス利用企業Ｂの口座を管理する金融機関Ｄ１からサービス利用企業Ａの口座を管理する金融機関Ｄ２に対して、送金データに従った金額を送金するとともに、送金データに含まれる支払ＩＤ等の情報も金融機関Ｄ２に送信される。これにより、販売者は、支払ＩＤ等の情報を含めた入金情報を金融機関Ｄ２から取得することができる。

なお、送金データに基づく送金は、金融機関を介して行うことに限定されない。例えば、オンライン決済サービス等のサービスを介して送金を行ってもよい。この場合、例えば、サービス提供企業Ｃは、送金データを示す二次元コードを購入者に送付し、購入者は、購入者端末３０にインストールされたオンライン決済サービス等のサービスのアプリケーションを介して、当該二次元コードを読み取らせることで、送金を行うことができる。

＜入金情報取得及び自動消込処理＞
次に、本実施形態における入金情報取得処理（図１のステップＳ５）及び自動消込処理（図１のステップＳ６）について、図３４を参照しながら説明する。図３４は、本実施形態における入金情報取得処理及び自動消込処理の一例を示すシーケンス図である。

ステップＳ６１において、取引管理サーバ１０が備える送受信部１１は、入金情報の取得要求を口座管理サーバ４０－２に送信する。口座管理サーバ４０－２は、サービス利用企業Ａの口座を管理する口座管理サーバ４０である。

取引管理サーバ１０が入金情報の取得要求を送信する契機は、販売者の操作に応じた販売者端末２０からの要求であってもよいし、所定の時間間隔（例えば、３０分）の経過毎であってもよい。

ステップＳ６２において、口座管理サーバ４０－２が備える送受信部４１は、サービス利用企業Ａの口座に関する入金情報を取引管理サーバ１０に送信する。当該入金情報には支払ＩＤが含まれている。取引管理サーバ１０では、送受信部１１が、入金情報を口座管理サーバ４０－２から受信する。

口座管理サーバ４０－２は、サービス利用企業Ａの口座に関する入金情報を取引管理サーバ１０に送信する際に、所定の認証処理を行う。例えば、テナント情報管理ＤＢにサービス利用企業Ａの口座の認証情報を登録しておき、取引管理サーバ１０の送受信部１１は、テナントＩＤに基づいて特定された認証情報を入金情報の取得要求と共に、口座管理サーバ４０－２に送信する。

口座管理サーバ４０－２では、記憶制御部４９が、送信された認証情報に基づく認証処理を実行する。記憶制御部４９は、認証に成功した場合、記憶部４００に蓄積されている入金情報のうち、認証情報に対応する入金情報を読み出す。最後に、送受信部４１は、読み出された入金情報を取引管理サーバ１０に送信する。

ステップＳ６２において、取引管理サーバ１０が備える記憶制御部１９は、口座管理サーバ４０－２から受信した入金情報を、入金情報管理ＤＢに登録する。

（入金情報管理テーブル）
ここで、入金情報管理テーブルの詳細について、図３５を参照しながら説明する。図３５は、本実施形態における入金情報管理テーブルの一例を示す概念図である。

図３５に示されているように、本実施形態における入金情報管理テーブル１７００では、取引日、出金額（お支払金額）、支払先を表す情報、入金額（お預り金額）、送金元を表す情報、差引残高、支払ＩＤ及び消込状態等が関連付けて管理されている。初期状態では、消込状態は空欄となる。

図３４に戻って説明する。ステップＳ６４において、取引管理サーバ１０は、入金情報及び支払情報に基づいて自動消込処理を実行する。

≪自動消込処理≫
ここで、本実施形態における自動消込処理（図３４のステップＳ６４）の詳細について、図３６を参照しながら説明する。図３６は、本実施形態における自動消込処理の一例を示すフローチャートである。

ステップＳ６４－１において、記憶制御部１９は、入金情報管理ＤＢから未処理の入金情報を取得する。未処理の入金情報とは、入金情報管理テーブルの消込状態が空欄である入金情報である。

ステップＳ６４－２からＳ６４－８は、ステップＳ６４－１で取得された未処理の入金情報それぞれについて実行される。

ステップＳ６４－２において、判断部１５は、取得した入金情報に支払ＩＤが設定されているか否かを判定する。支払ＩＤが設定されている場合（ＹＥＳ）、判断部１５は、当該支払ＩＤを取得し、ステップＳ６４－３に処理を進める。支払ＩＤが設定されていない場合（ＮＯ）、判断部１５は、ステップＳ６４－８に処理を進める。

ステップＳ６４－３において、記憶制御部１９は、ステップＳ６４－２で取得した支払ＩＤに基づいて、支払情報管理ＤＢから支払情報を取得する。

ステップＳ６４－４において、判断部１５は、支払情報の支払金額と入金情報のお預かり金額とが一致するか否かを判定する。支払金額とお預かり金額とが一致する場合（ＹＥＳ）、判断部１５は、ステップＳ６４－５に処理を進める。支払金額とお預かり金額とが一致しない場合（ＮＯ）、判断部１５は、ステップＳ６４－７に処理を進める。

ステップＳ６４－５において、記憶制御部１９は、入金情報及び支払情報に基づいて、売掛帳情報を生成し、売掛帳情報管理テーブルに登録する。生成する売掛帳情報は、売掛日付が入金情報の取引日に設定され、共通請求書ＩＤ、請求書ＩＤ、明細ＩＤ、入金数量及び入金額が支払情報の共通請求書ＩＤ、請求書ＩＤ、明細ＩＤ、数量及び金額に設定される。

ステップＳ６４－６において、記憶制御部１９は、入金情報管理テーブルの消込状態を消込済みに更新する。その後、記憶制御部１９は、当該入金情報に対する処理を終了し、ステップＳ６４－２に処理を戻す。

ステップＳ６４－７において、記憶制御部１９は、入金情報管理テーブルの消込状態を金額不一致に更新する。その後、記憶制御部１９は、当該入金情報に対する処理を終了し、ステップＳ６４－２に処理を戻す。

ステップＳ６４－８において、記憶制御部１９は、入金情報管理テーブルの消込状態を手動消込に更新する。その後、記憶制御部１９は、当該入金情報に対する処理を終了し、ステップＳ６４－２に処理を戻す。

図３７に、自動消込後の売掛帳情報管理テーブルの一例を示す。図３７に示されているように、自動消込後の売掛帳情報管理テーブルでは、共通請求書ＩＤ、請求書ＩＤ及び明細ＩＤが一致し、入金数量及び入金額が設定されたレコードが追加されている。

図３８に、自動消込後の買掛帳情報管理テーブルの一例を示す。図３８に示されているように、自動消込後の買掛帳情報管理テーブルでは、共通請求書ＩＤ、請求書ＩＤ及び明細ＩＤが一致し、入金数量及び入金額が設定されたレコードが追加されている。

なお、買掛帳情報管理テーブルに対する入金数量及び入金額の登録は、自動消込処理では行われない。購入者は、購入者端末３０に対する操作等により、入金数量及び入金額が設定された買掛帳情報を手動で登録する。

ただし、取引管理サーバ１０が、支払予定日に支払情報管理テーブルを参照し、入金が確認できたら自動的に買掛帳情報管理テーブルに登録するように構成してもよい。具体的には、支払情報管理テーブルにおいて、支払予定日が当日の支払情報を取得し、共通請求書ＩＤ、明細ＩＤ、数量及び金額を設定した買掛帳情報を買掛帳情報管理テーブルに登録すればよい。

図３４に戻って説明する。ステップＳ６５において、販売者端末２０が備える受付部２２は、販売者による入金管理画面の表示操作を受け付ける。入金管理画面の表示操作は、例えば、取引管理サーバ１０が提供するメインメニュー画面において行われる。

ステップＳ６６において、販売者端末２０が備える送受信部２１は、入金管理画面の取得要求を取引管理サーバ１０に送信する。当該取得要求には、請求期間が含まれる。請求期間は、前月の請求締日の翌日から当月の請求締日までとしてもよいし、入金管理画面の表示操作において指定してもよい。取引管理サーバ１０では、送受信部１１が、入金管理画面の取得要求を販売者端末２０から受信する。

ステップＳ６７において、取引管理サーバ１０が備える記憶制御部１９は、入金管理画面の取得要求に含まれる請求期間に基づいて、売掛帳情報管理ＤＢから売掛帳情報を読み出す。次に、記憶制御部１９は、読み出した売掛帳情報に含まれる共通請求書ＩＤに基づいて、発行請求書情報管理ＤＢから請求書情報を読み出す。

続いて、記憶制御部１９は、読み出した売掛帳情報に含まれる共通請求書ＩＤに基づいて、支払情報管理ＤＢから支払情報を読み出す。次に、作成部１６が、記憶制御部１９が読み出した売掛帳情報、請求書情報及び支払情報に基づいて、入金管理画面の画面データを作成する。

≪入金管理画面の作成処理≫
ここで、本実施形態における入金管理画面の作成処理（図３４のステップＳ６７）の詳細について、図３９を参照しながら説明する。図３９は、本実施形態における入金管理画面の作成処理の一例を示すフローチャートである。

ステップＳ６７－１において、記憶制御部１９は、売掛帳情報管理ＤＢから第１の売掛帳情報を取得する。第１の売掛帳情報は、売掛日付が請求期間内で、かつ、入金数量及び入金額が空欄の売掛帳情報である。

ステップＳ６７－２からＳ６７－１５は、ステップＳ６７－１で取得された第１の売掛帳情報それぞれについて実行される。

ステップＳ６７－２において、判断部１５は、取得した第１の売掛帳情報に共通請求書ＩＤ及び明細ＩＤが設定されているか否かを判定する。共通請求書ＩＤ及び明細ＩＤが設定されている場合（ＹＥＳ）、判断部１５は、当該共通請求書ＩＤ及び当該明細ＩＤを取得し、ステップＳ６７－３に処理を進める。共通請求書ＩＤ及び明細ＩＤが設定されていない場合（ＮＯ）、判断部１５は、ステップＳ６７－８に処理を進める。

ステップＳ６７－３において、記憶制御部１９は、ステップＳ６７－２で取得した共通請求書ＩＤ及び明細ＩＤに基づいて、売掛帳情報管理ＤＢから第２の売掛帳情報を取得する。第２の売掛帳情報は、第１の売掛帳情報と共通請求書ＩＤ及び明細ＩＤが同一、かつ、入金数量及び入金額が設定されている売掛帳情報である。

ステップＳ６７－４において、判断部１５は、ステップＳ６７－３で第２の売掛帳情報を取得できたか否かを判定する。第２の売掛帳情報を取得できた場合（ＹＥＳ）、判断部１５は、ステップＳ６７－５に処理を進める。第２の売掛帳情報を取得できなかった場合（ＮＯ）、判断部１５は、ステップＳ６７－１０に処理を進める。

ステップＳ６７－５において、作成部１６は、ステップＳ６７－３で取得した第２の売掛帳情報の売掛日付、入金数量及び入金額を取得する。なお、取得した売掛日付は入金日として入金管理画面に表示される。

ステップＳ６７－６において、判断部１５は、第１の売掛帳情報の数量及び金額と、第２の売掛帳情報の入金数量及び入金額とが一致するか否かを判定する。数量及び金額と入金数量及び入金額とが一致する場合（ＹＥＳ）、判断部１５は、当該第１の売掛帳情報に対する処理を終了し、ステップＳ６７－２に処理を戻す。数量及び金額と入金数量及び入金額とが一致しない場合（ＮＯ）、判断部１５は、ステップＳ６７－７に処理を進める。

ステップＳ６７－７において、作成部１６は、当該第１の売掛帳情報を要注意として協調して表示することを決定する。強調表示はどのような方法でもよいが、例えば、背景色を変える、文字色を変える、太字で表示する等を用いればよい。その後、作成部１６は、当該第１の売掛帳情報に対する処理を終了し、ステップＳ６７－２に処理を戻す。

ステップＳ６７－８において、作成部１６は、入金管理画面に表示する請求書状態を未発行に設定する。

ステップＳ６７－９において、作成部１６は、入金管理画面に表示する入金予定数量及び入金予定金額を空欄に設定する。その後、作成部１６は、当該第１の売掛帳情報に対する処理を終了し、ステップＳ６７－２に処理を戻す。

ステップＳ６７－１０において、記憶制御部１９は、ステップＳ６７－２で取得した共通請求書ＩＤに基づいて、発行請求書情報管理ＤＢから請求書情報を取得する。次に、記憶制御部１９は、当該共通請求書ＩＤに基づいて、支払情報管理ＤＢから支払情報を取得する。

ステップＳ６７－１１において、作成部１６は、ステップＳ６７－１０で取得した請求書情報の請求書状態を取得する。なお、取得した請求書状態は入金管理画面に表示される請求書状態として用いられる。

ステップＳ６７－１２において、判断部１５は、ステップＳ６７－１０で支払情報を取得できたか否かを判定する。支払情報を取得できた場合（ＹＥＳ）、判断部１５は、ステップＳ６７－１３に処理を進める。支払情報を取得できなかった場合（ＮＯ）、判断部１５は、ステップＳ６７－９に処理を進める。

ステップＳ６７－１３において、作成部１６は、ステップＳ６７－１０で取得した支払情報の支払予定日を取得する。なお、取得した支払予定日は入金予定日として入金管理画面に表示される。

ステップＳ６７－１４において、作成部１６は、ステップＳ６７－１で取得した第１の売掛帳情報の明細ＩＤに基づいて、ステップＳ６７－１０で取得した支払情報の数量及び金額を取得する。なお、取得した数量及び金額は入金管理画面に表示される入金予定数量及び入金予定金額として用いられる。

ステップＳ６７－１５において、判断部１５は、第１の売掛帳情報の数量及び金額と、支払情報の数量及び金額とが一致するか否かを判定する。数量及び金額が一致する場合（ＹＥＳ）、判断部１５は、当該第１の売掛帳情報に対する処理を終了し、ステップＳ６７－２に処理を戻す。数量及び金額が一致しない場合（ＮＯ）、判断部１５は、ステップＳ６７－７に処理を進める。

ステップＳ６７－１６において、作成部１６は、ステップＳ６７－１からＳ６７－１５で取得した情報に基づいて、入金管理画面の画面データを作成する。

図３４に戻って説明する。ステップＳ６８において、取引管理サーバ１０が備える送受信部１１は、作成部１６が作成した入金管理画面の画面データを販売者端末２０に送信する。販売者端末２０では、送受信部２１が、入金管理画面の画面データを取引管理サーバ１０から受信する。

ステップＳ６９において、販売者端末２０が備える表示制御部２４は、入金管理画面の画面データに基づいて、入金管理画面をディスプレイ５０６に表示する。

（入金管理画面）
ここで、本実施形態における入金管理画面について、図４０を参照しながら説明する。図４０は、本実施形態における入金管理画面の一例を示す概念図である。

図４０に示されているように、本実施形態における入金管理画面２５００は、条件設定領域２５１０、入金情報表示欄２５２０及び詳細確認ボタン２５２１を有する。

条件設定領域２５１０において、請求期間等の条件を入力すると、当該条件に合致する入金情報が入金情報表示欄２５２０に表示される。条件設定領域２５１０に表示される各条件値は、予め設定しておいてもよい。例えば、請求期間は、前月の請求締日の翌日から当月の請求締日に設定すればよい。

詳細確認ボタン２５２１は、入金情報表示欄２５２０に表示された各入金情報に対して１つの詳細確認ボタン２５２１が表示される。詳細確認ボタン２５２１を押下すると、入金情報の詳細を表示する画面表示される。詳細確認ボタン２５２１は、明細の金額と入金予定金額又は入金額とが一致しない等の場合に、詳細を確認するために用いることができる。

なお、入金予定に関する情報（入金予定日、入金予定数量及び入金予定金額）又は入金に関する情報（入金日及び入金額）が表示されていない入金情報に対応する詳細確認ボタン２５２１は、非表示に制御してもよい。

図４１に、入金済みの場合の入金管理画面２５００の一例を示す。図４１に示されているように、入金済みの場合の入金管理画面２５００では、入金情報表示欄２５２０に入金日及び入金額が表示されている。

〔第１実施形態の主な効果〕
本実施形態における取引管理サーバ１０は、販売者の取引条件と購入者の支払条件が予め登録されており、請求書作成画面において、いずれの条件を優先するかを選択することで、選択された条件に従った請求書の内容を提案する。したがって、本実施形態における取引管理サーバ１０によれば、販売者及び購入者双方の条件を考慮した請求書を提案することができる。

［第２実施形態］
第１実施形態では、請求締日及び支払サイトが、販売者と購入者との間で予め合意がある例を説明した。第２実施形態では、支払サイトについては予め合意があるが、請求締日については合意がない例を説明する。

第１実施形態では、請求締日及び支払サイトの合意があるため、請求締日を起算日として支払サイトの日数が経過した日付を支払期限日として決定した。第２実施形態では、請求締日について合意がなく、販売者が購入者の同意なく独自に設定することができる。そのため、支払期限日は、売掛が発生した日を起算日として支払サイトの日数が経過した日付を支払期限日として決定する。ただし、請求対象とする明細は、販売者が請求締日に基づいて決定する。

第１実施形態では、請求締日が起算日であるため、請求書に含まれるすべての明細が同じ支払期限日となる。一方、第２実施形態は、各明細の売掛が発生した日が起算日であるため、明細毎に支払期限日が異なる。そのため、請求締日と支払締日との関係によっては、前の支払期間に支払わないと支払サイトの条件を満たせない場合が生じる。したがって、第２実施形態の例では、購入者は、請求書に記載された明細のうち、支払サイトの条件を満たすように支払対象を決定する必要がある。

以下、第２実施形態における情報処理システムについて、第１実施形態との相違点を中心に、図４２乃至図４６を参照しながら説明する。

（取引条件設定画面）
図４２は、本実施形態における取引条件設定画面の一例を示す概念図である。図４２に示されているように、本実施形態における取引条件設定画面３０００は、複数の取引先入力欄３００１、複数の支払サイト入力欄３００２、及び１つの請求締日入力欄３００３を有する。

複数の取引先入力欄３００１と複数の支払サイト入力欄３００２とは、１対１で対応付けられている。本実施形態における取引条件設定画面３０００では、複数の取引先それぞれに対して支払サイトを設定し、すべての取引先に対して同一の請求締日を設定する。

なお、図４２に示されているように、本実施形態では、購入者であるＢ株式会社に対して支払サイト４５を設定したものとする。

（取引条件管理テーブル）
図４３は、本実施形態における取引条件管理テーブルの一例を示す概念図である。図４３に示されているように、本実施形態における取引条件管理テーブルには、図４２に示した取引条件設定画面３０００で設定された取引条件が格納されている。

（支払条件管理テーブル）
図４４は、本実施形態における支払条件管理テーブルの一例を示す概念図である。図４４に示されているように、本実施形態では、購入者である株式会社Ｂが支払予定日として翌月１２日を設定したものとする。

（買掛帳情報管理テーブル）
図４５は、本実施形態における買掛帳情報管理テーブルの一例を示す概念図である。図４５に示されているように、本実施形態では、買掛日付が２０２０年９月２６日で５個のホワイトボードに関する買掛帳情報と、買掛日付が２０２０年９月２９日で３５個の椅子に関する買掛帳情報とが格納されているものとする。

（支払処理画面）
図４６は、本実施形態における支払処理画面の一例を示す概念図である。図４６に示されているように、本実施形態における支払処理画面２４００では、買掛帳情報表示欄２４６０に表示された買掛帳情報のうち、支払対象とされない買掛帳情報が存在する。具体的には、買掛帳情報表示欄２４６０に表示された買掛帳情報のうち、買掛日付が９月２６日の買掛帳情報は支払対象に含めるが、買掛日付が９月２９日の買掛帳情報は支払対象に含めない。

本実施形態では、買掛日付を起算日として支払サイトに基づいて支払期限日を計算する。そのため、買掛日付が９月２６日の買掛帳情報は、次の支払日である１１月１２日に支払いを行うと、支払サイト４５の条件を満たすことができない。したがって、買掛日付が９月２６日の買掛帳情報は、支払対象に含める必要がある。一方、買掛日付が９月２９日の買掛帳情報は、次の支払日である１１月１２日に支払いを行っても、支払サイト４５の条件を満たす。したがって、支払対象に含める必要はない。

〔第２実施形態の主な効果〕
本実施形態における取引管理サーバ１０は、買掛が発生した日を起算日として支払サイトの条件が適用される場合に、次の支払期間に含まれる買掛帳情報であっても、次の支払日に支払うと支払サイトの条件を満たせない買掛帳情報については、支払対象とする制御を行う。したがって、本実施形態における取引管理サーバ１０によれば、請求締日と支払締日との関係によって支払サイトの条件を満たせなくなる事態を回避することができる。

［補足］
上記実施形態では、販売者側の請求書情報を発行請求書情報管理テーブルに格納し、購入者側の請求書情報を受領請求書情報管理テーブルに格納した。ここで、取引管理サーバ１０が各テナントに共通の請求書情報管理テーブルを備え、請求書情報を共有するように構成してもよい。このように構成することで、購入者側で請求書の受領等の操作を行わなくとも、当該請求書情報を参照可能とすることができる。

上記実施形態において、取引管理サーバ１０は情報処理装置の一例である。販売者端末２０は情報処理端末の一例である。送受信部１１は送信部又は受信部の一例である。

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

実施例に記載された装置群は、本明細書に開示された実施形態を実施するための複数のコンピューティング環境のうちの１つを示すものにすぎない。ある実施形態では、取引管理サーバ１０及び口座管理サーバ４０は、サーバクラスタといった複数のコンピューティングデバイスを含む。複数のコンピューティングデバイスは、ネットワークや共有メモリなどを含む任意のタイプの通信リンクを介して互いに通信するように構成されており、本明細書に開示された処理を実施する。

以上、本発明の実施の形態について詳述したが、本発明はこれらの実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形又は変更が可能である。

１ 情報処理システム
１０ 取引管理サーバ
２０ 販売者端末
３０ 購入者端末
４０ 口座管理サーバ
１１，２１，３１，４１ 送受信部
２２，３２ 受付部
２４，３４ 表示制御部
１５，２５，３５，４５ 判断部
１６，４６ 作成部
１９，２９，３９，４９ 記憶制御部
１００，２００，３００，４００ 記憶部

特開２００８－９８７３号公報

Claims (12)

1. 利用者が利用する情報処理端末とネットワークを介して通信可能な情報処理装置であって、
   前記利用者の取引条件及び取引先の支払条件を記憶部に記憶する記憶制御部と、
   前記取引条件に従った請求書情報又は前記支払条件に従った請求書情報の生成を提案する画面を表示させるための画面データを前記情報処理端末に送信する送信部と、
   を備える情報処理装置。
2. 請求項１に記載の情報処理装置であって、
   前記取引条件は、請求締日及び支払サイトに関する条件を含み、
   前記支払条件は、支払締日及び支払予定日に関する条件を含む、
   情報処理装置。
3. 請求項２に記載の情報処理装置であって、
   前記画面は、前記請求締日と前記支払締日との前後関係に基づいて、前記請求書情報に含める明細を選択する、
   情報処理装置。
4. 請求項３に記載の情報処理装置であって、
   前記請求締日及び支払サイトは、前記利用者と前記取引先とで予め合意した条件であり、
   前記画面は、前記請求締日と前記支払サイトに基づいて、前記請求書情報に含める支払期限日を計算する、
   情報処理装置。
5. 請求項３に記載の情報処理装置であって、
   前記支払サイトは、前記利用者と前記取引先とで予め合意した条件であり、
   前記画面は、前記明細の売掛日付と前記支払サイトに基づいて計算した支払期限日と、前記支払予定日との前後関係に基づいて、前記請求書情報に含める明細を選択する、
   情報処理装置。
6. 情報処理装置とネットワークを介して通信可能な情報処理端末であって、
   利用者の取引条件に従った請求書情報又は取引先の支払条件に従った請求書情報の生成を提案するための画面を表示する表示制御部と、
   前記請求書情報から支払対象とする明細を特定した支払要求を前記情報処理装置に送信する送信部と、
   を備える情報処理端末。
7. 情報処理装置とネットワークを介して通信可能な情報処理端末であって、
   取引先の取引条件に従った請求書情報に対する送金データを作成するための画面を表示する表示制御部と、
   前記請求書情報から支払対象とする明細を特定した支払要求を前記情報処理装置に送信する送信部と、
   を備える情報処理端末。
8. 利用者が利用する情報処理端末と情報処理装置とがネットワークを介して通信可能な情報処理システムであって、
   前記情報処理装置は、
   前記利用者の取引条件及び取引先の支払条件を記憶部に記憶する記憶制御部と、
   前記取引条件に従った請求書情報又は前記支払条件に従った請求書情報の生成を提案する画面を表示させるための画面データを前記情報処理端末に送信する送信部と、
   を備え、
   前記情報処理端末は、
   前記画面データに基づいて前記画面を表示する表示制御部と、
   前記請求書情報から支払対象とする明細を特定した支払要求を前記情報処理装置に送信する送信部と、
   を備える情報処理システム。
9. 利用者が利用する情報処理端末とネットワークを介して通信可能なコンピュータが、
   前記利用者の取引条件及び取引先の支払条件を記憶部に記憶する記憶制御手順と、
   前記取引条件に従った請求書情報又は前記支払条件に従った請求書情報の生成を提案する画面を表示させるための画面データを前記情報処理端末に送信する送信手順と、
   を実行する情報処理方法。
10. 利用者が利用する情報処理端末とネットワークを介して通信可能なコンピュータに、
    前記利用者の取引条件及び取引先の支払条件を記憶部に記憶する記憶制御手順と、
    前記取引条件に従った請求書情報又は前記支払条件に従った請求書情報の生成を提案する画面を表示させるための画面データを前記情報処理端末に送信する送信手順と、
    を実行させるためのプログラム。
11. 情報処理装置とネットワークを介して通信可能なコンピュータに、
    利用者の取引条件に従った請求書情報又は取引先の支払条件に従った請求書情報の生成を提案するための画面を表示する表示制御手順と、
    前記請求書情報から支払対象とする明細を特定した支払要求を前記情報処理装置に送信する送信手順と、
    を実行させるためのプログラム。
12. 情報処理装置とネットワークを介して通信可能なコンピュータに、
    取引先の取引条件に従った請求書情報に対する送金データを作成するための画面を表示する表示制御手順と、
    前記請求書情報から支払対象とする明細を特定した支払要求を前記情報処理装置に送信する送信手順と、
    を実行させるためのプログラム。

Images