JP4309852B2 - 請求書を自動的に生成するための方法およびソフトウェアアプリケーション - Google Patents

Description

本発明の背景
本発明の技術分野
本発明の技術分野は、電子データ処理の分野である。より詳細には本発明は、自動的な請求システムのための方法、コンピュータプログラム、コンピュータプログラム製品およびシステムに関する。さらに詳細には、遠隔の確認および支払いのためにカスタマへ送付される電子的な明細請求書の処理、生成および呈示のための方法、コンピュータプログラム、コンピュータプログラム製品およびシステムに関する。

関連分野の説明
ここで使用されているような用語「提示（presentment）」は、通常はコマーシャルペーパーに関連する特別な定義を含んでいないことを理解されたい。すなわち、名宛人に対する譲渡可能な文書に基づく提示という定義を含んでいないことを理解されたい。むしろこの用語は、電子的手段を介して情報を提供すること、とりわけ、少なくとも同一のカスタマ請求データを含む「明細請求書」を提供することを指している。この少なくとも同一のカスタマ請求データは、典型的には紙の明細請求書に記載されているカスタマ請求データである。電子的な提示は、インターネットウェブサイトまたはイントラネットウェブサイトを使用することによって行うか、またはｅメールまたはＳＭＳを使用することによって行うのが有利であり、たとえば１つまたは複数の人に対してアクセス可能であるウェブサイトを形成することによって行うが、これらに限定されない。電子的提示はさらに、コンピュータ読み出し可能な記憶媒体を、たとえば標準的な郵便を介して送付することによって行うこともできる。このコンピュータ読み出し可能な記憶媒体は、ディスク、ＺＩＰディスク、磁気光学ディスク、ＣＤ‐ＲＯＭ、ＣＤＲＷ‐ＲＯＭ、ＤＶＤ‐ＲＯＭ等である。

エンタープライズリソースプランニングソフトウェア（ＥＲＰ）の環境における電子請求書提示支払いサービス（ＥＢＰＰ）のための方法およびシステムが、従来技術から公知である。ＵＳ６０４４３６２において、自動的な電子的明細請求書生成および支払いのためのシステムが開示されている。このシステムによって遠隔のカスタマが、明細請求書の請求者からの自動請求を確認することができる。このシステムは明細請求書提示電子装置を有しており、この明細請求書提示電子装置には制御システムおよび第１の電子通信装置が設けられている。このシステムは、カスタマインタフェースを備えている少なくとも１つの遠隔認証端末も有しており、この遠隔端末システムには第２の電子通信装置が設けられている。この第２の電子通信装置は、第１の電子通信装置と機能的に有効に通信するように適合されている。明細請求書提示電子装置の制御システムは、自動請求のために予備認証されたカスタマ明細請求書を考慮して、第２の電子通信装置へ伝送するための第１の電子通信装置へ請求データを供給するように適合されている。遠隔の認証端末のカスタマインタフェースは、請求データをカスタマに対して提示し、請求データに関連する応答をカスタマから受信するように適合されている。この応答は、自動請求のための請求データの承諾を示すか、または自動請求を変更するための請求データの変更のうち１つを示す。承諾は、カスタマからの能動的な応答であるか、または受動的な応答である。受動的な応答はたとえば、事前設定された限度までの自動的な承諾である。

ＵＳ５４６５２０６において、事前設定された規則にしたがって動作する支払いネットワークを介して、参加カスタマが請求額を参加請求者に対して支払う請求書支払いシステムが開示されている。参加カスタマは参加請求者から、金額および一意の請求者識別番号を示す請求書（紙／郵便の請求書、ｅメール通知の請求書、自動的借入のための暗黙的な請求書）を受け取る。送金額を認証するためには、カスタマは銀行（参加銀行）へ請求額支払いオーダを送信する。この請求額支払いオーダは、支払い日、支払い額、請求者によるカスタマの口座番号、資金源および請求者の請求者識別番号を、直接または静的データに対する参照によって示しており、データ要素を含んでいる。銀行Ｃは支払いメッセージを支払いネットワークへ送信し、請求者参照番号を割り当てる該支払いネットワークは、支払いメッセージを請求者の銀行へ転送する。その結果として、カスタマの銀行はカスタマの口座に借方記入し、支払いネットワークとともに正味持ち高に対して支払い義務を負う。また、請求者の銀行はネットワーク位置を支払いネットワークから受信し、請求者の銀行口座に貸方記入する。カスタマの銀行が、撤回不可の支払いメッセージを送信することに同意した場合、資金不足の場合に該カスタマの銀行が損失のリスクを負うことを承諾しなくても資金が十分になるまで、保証された支払いネットワークの場合、該カスタマの銀行はトランザクションを送信しない。請求者の銀行は、支払いメッセージの受信に応じて資金を請求者に解放し、請求者Ｂが指示した形態でＡ／Ｒデータを請求者へ供給する。この形態は、請求者に対して例外項目として処理する必要がない形態である。トランザクションが支払いネットワークの事前設定された規則に準ずる可逆的なトランザクションでない場合、請求者の銀行は該支払いネットワークによって支払いを確認する。特別な構成では、カスタマは請求額支払いオーダを手動で、ＡＴＭで紙を介して開始するか、ＰＣを介して開始するか、または電話機のダイヤルを介して開始する。

別のシステムが、ウェブサイトwww://ofx.net.から公知である。オープンフィナンシャルエクスチェンジ（ｏｆｘ）は、金融上のデータおよび命令をカスタマと金融機関との間で交換するための、広い支持基盤を有するフレームワークである。これによって、機関は媒介者を必要とせずに、カスタマと直接接続することができる。オープンフィナンシャルエクスチェンジは、誰もが具現化できるオープンな仕様である。すなわち、すべての金融機関、トランザクションプロセッサ、ソフトウェア開発者または他のパーティが具現化できるオープンな仕様である。ここでは、データフォーマット（ＸＭＬ等）、接続（ＴＣＰ／ＩＰおよびＨＴＴＰ）およびセキュリティ（ＳＳＬ）の、広く受け入れられているオープンな標準方式が使用される。オープンフィナンシャルエクスチェンジは、各金融サービスかつ共通のフレームワークおよびインフラストラクチャによって使用される要求メッセージおよび応答メッセージを定義することにより、これらのメッセージの通信を支援する。請求者およびカスタマのデータは、同一のシステムにて保持される。

しかし、請求者とカスタマとの間で直接的なコンタクトを使用するシステムは、異なる請求者の請求書を１つのカスタマに提示するというビジネスシナリオを技術的に具現化するのが困難であるという欠点を有する。さらに、このようなシステムを請求者およびカスタマのＩＴ（情報技術）システムに統合および維持するのは、とりわけ大きな請求所要量を処理しなければならない場合に困難である。

したがって、上記の問題の少なくとも一部を、より効率的に解決するための方法および／またはソフトウェアアプリケーションおよび／またはデータ処理システムが必要とされる。とりわけ、請求書処理をより効率的にするためのメカニズムを有するソフトウェアアプリケーションを提供するのが望ましい。

本発明の要約
本発明によれば、カスタマに対する請求書を電子的な処理するコンピュータシステムが提供される。ここでこのコンピュータシステムは、第１処理モジュールと、第２処理モジュールとを有しており、
上記の第１処理モジュールは、
− 請求者によって入力されたデータを受信する手段と、
− この受信データを記憶する請求者マスタデータ記憶手段と、
− この請求者マスタデータ記憶手段に記憶されているデータから請求書を作成する手段と、
− この作成した請求書をカスタマによって指定された請求書フォーマットに変換する手段とを有しており、
上記の第２処理モジュールは、
− カスタマによって入力されたデータを記憶するカスタママスタデータ記憶手段と、
− ビジネストランザクションに関するすべてのデータを記憶するビジネスオブジェクトデータベースと、
− 上記の第１処理モジュールによって作成され変換された複数の請求書をカスタマ毎にまとめて前記のビジネスオブジェクトデータに記憶するコンソリデーション手段とを有しており、上記のカスタママスタデータには請求書フォーマットが含まれており、
上記の第１処理モジュールおよび第２処理モジュールはそれぞれ、データを互いに交換するための手段を有しており、
上記の１つまたは複数の第１処理モジュールと第２処理モジュールとがこのデータ交換手段を介して接続されており、ここで
ａ） 第１処理モジュールは、請求者によって入力された請求情報を受信し、
ｂ） 第１処理モジュールは、上記の請求情報および上記の請求者マスタデータ記憶手段に記憶されているデータを使用して請求書を作成し、
ｃ） 第１処理モジュールは、上記のデータ交換手段を介し、上記の請求書に対応しかつ上記のカスタママスタデータに記憶されている請求書フォーマットを第２処理モジュールに要求し、
ｄ） 第１処理モジュールは、当該の請求書フォーマットを受信し、
ｅ） 請求者によって使用される請求書フォーマットが、上記の第２処理モジュールにて指定されかつこの第２処理モジュールから受信した請求書フォーマットでない場合、第１処理モジュールは、上記の作成した請求書を上記の第２処理モジュールから受信した請求書フォーマットに変換し、
ｆ） 第１処理モジュールは、この変換した請求書を第２処理モジュールに送信し、
ｇ） 第２処理モジュールは、この第２処理モジュールに送信された複数の請求書をカスタマ毎にまとめて前記のビジネスオブジェクトデータに記憶することを特徴とする。

方法およびシステムは、大量の請求書を効率的に、指定されたカスタマへ提供するという前記課題の解決に技術的に寄与する。複数の請求者が、請求情報を第１のモジュールへ供給することができる。請求情報は最後に、各カスタマによって指定されたフォーマットの請求書に変換される。

本発明はさらにコンピュータプログラムと、コンピュータ読み出し可能な媒体とを対象としている。これらはそれぞれ、本発明の方法にしたがい本発明の実施形態において請求書を処理するためのプログラムコードまたは命令を有する。

第１の処理モジュールおよび第２の処理モジュールはコンピュータプログラムとして、異なるハードウェアシステム（コンピュータまたはコンピュータシステム）にインストールすることができ、相互に別個に独立して動作させることができる。この異なるシステムは、相互に通信できるようにネットワークの形態で接続することができる。

本発明および本発明の実施形態の付加的な対象および利点が部分的に、詳細な説明に記載されているか、または実際に実施することによって習得することができる。本発明の対象および利点は、とりわけ従属請求項に記載された個々の要素および組み合わせによって実現および達成される。本発明の実施形態は、詳細な説明の部分および従属請求項において開示されている。

以下の全般的な説明および以下の詳細な説明は、双方とも単なる挙例および詳解のために記載されたものであり、請求項に記載されているように、本発明を限定するものではない。

図面の簡単な説明
本明細書に組み込まれており本明細書の一部を構成する添付図面によって、本発明の実施形態を図解し、詳細な説明とともに本発明の基本的思想を詳述する。

図面
図１ コンピュータシステムで本発明の方法の実施を概略的に示すブロック図である。
図２ 本発明の方法の一例のブロック図である。
図３ 本発明の電子的な請求書提示支払いシステムの一例の概観図である。
図４ 第１の処理モジュールおよび第２の処理モジュールの接続の一例のブロック図である。
図５ 本発明の請求プロセスの一例のフローチャートである。
図６ 本発明の請求書提示プロセスの一例のフローチャートである。
図７ 本発明の電子的請求プロセスにおいてカスタマを登録するためのプロセスの一例のフローチャートである。
図８ カスタマの登録を請求者によってアクティベートするためのプロセスの一例を示すフローチャートである。
図９ カスタマに対する請求者のＩＤを、請求者に対するカスタマのＩＤにマッピングするためのテーブルの一例を示すブロック図である。
図１０ 本発明の電子的な請求書提示支払いシステムにｅバンキングを組み込む一例のブロック図である。
図１１ カスタマによる請求書の確認を開始および実行するためのプロセスの一例を示すフローチャートである。
図１２ 図１１に示されたフローチャートの続きを示している。
図１３ 請求者またはカスタマのデータのためのアーカイブプロセスの一例を示すブロック図である。

詳細な説明
コンピュータシステムとプログラムとは密接に関連している。以下で使用されているように、「コンピュータは供給する」および「プログラムは特定の動作を供給または実行する」、「ユーザは特定の動作を実行する」等のフレーズは、プログラムによって制御されるコンピュータシステムによる動作を表現するための便宜上の短縮表現であるか、または、コンピュータシステムが特定の動作を実行できるようにプログラムまたはプログラムモジュールが設計されていること、または、ユーザが特定の動作をコンピュータシステムによって実行できるようにプログラムまたはプログラムモジュールが設計されていることを表現するための便宜上の短縮表現である。

本発明の構想においてこれらの用語は、異なって定義されない限り、データ処理の分野のコンテクストにおいて通常の意味を有するものとする。コンピュータシステムは、ＰＣまたはラップトップ等の独立したコンピュータであるか、または会社内のネットワーク等のネットワークとして接続された複数のコンピュータであるか、またはインターネットを介して接続された複数のコンピュータである。

要約の部分に記載された本発明の方法の第１の実施形態は、ｆ）変換された請求書を第２の処理モジュールによって、第３の処理モジュールに対してアクセス可能であるように形成するステップを有することを特徴とする。

本発明の方法の第２の実施形態は、ｇ）変換された請求書を、カスタマに対してアクセス可能であるように形成するステップを有することを特徴とする。

第３の実施形態は、ｈ）変換された請求書をカスタマに対して提示または供給するステップを有することを特徴とする。

第４の実施形態は、請求書を第１の処理モジュールによってデジタル署名することを含んでいる。

第５の実施形態は、カスタマのアクセスのために、変換された請求書に、該変換された請求書の記憶位置に対するリンクまたは該請求書の詳細の記憶位置に対するリンクを設けることを特徴とする。

第６の実施形態は、請求書または変換された請求書を、印刷サービスへ送信することを特徴とする。

本発明の第７の実施形態では、請求書および／または変換された請求書を、第１の処理モジュールおよび／または第２の処理モジュールによって暗号化することが含まれている。

第８の実施形態は、請求書および／または変換された請求書を、第１の処理モジュールおよび／または第２の処理モジュールによってアーカイブすることを含んでいる。

別の実施形態は、カスタマの請求書の概略を提示するための手段を提供する第３の処理モジュールを特徴とする。有利には該第３の処理モジュールは、請求書を検証するための手段を提供する。本発明による方法の別の実施形態では、該第３の処理モジュールはワークフロー支援または請求書の異議申し立てのための手段を提供する。

別の実施形態は、第２の処理モジュールは国固有の請求書の提示および／または支払いのための手段を提供することを特徴とする。別の実施形態の特徴は、該第２の処理モジュールは、データを１つまたは複数の別の第２の処理モジュールと交換するための手段を提供することである。別の実施形態の特徴は、第２の処理モジュールが支払いオーダをカスタマから受信することである。別の実施形態は、第２の処理モジュールが支払いオーダまたは変換された支払いオーダを、支払いサービス提供者へ転送することを特徴とする。

本発明による方法の別の実施形態の特徴は、請求情報が、請求者および／またはカスタマおよび／または支払いサービス提供者のアドレス情報、支払い情報、ＶＡＴ情報と、購入オーダに関連する項目化された請求位置、および／または会計情報を有することである。別の実施形態では請求者のマスタデータは、アドレス情報、および／またはデータフォーマット情報、および／または通信アドレスに関する情報、および／または銀行情報および銀行口座情報、および／またはユーザ認証情報、および／またはユーザ許可情報、および／またはアーカイブサービスのための任意選択および／または印刷サービスのための任意選択および／または通知のための任意選択に関する情報を有する。別の実施形態ではカスタマのマスタデータは、アドレス情報、および／またはデータフォーマット情報、および／または通信アドレス、および／または銀行情報および銀行口座情報、および／またはユーザ認証情報、および／またはユーザ許可、および／またはアーカイブサービスのための任意選択に関する情報および／または通知のための任意選択に関する情報を含んでいる。

別の実施形態は、第２の処理モジュールが、１つまたは複数の別の第１の処理モジュールとデータを交換するための手段を有することを特徴とする。別の実施形態の特徴は、第２の処理モジュールが、１つまたは複数の別の第３の処理モジュールとデータを交換する手段を有することである。

別の実施形態では第２の処理モジュールまたは第１の処理モジュールは、特定のカスタマに対する請求者のＩＤを、特定の請求者に対するカスタマのＩＤにマッピングする手段を有する。

別の実施形態は、請求書を、請求者によって使用されたフォーマットからカスタマのマスタデータで指定されたのと同じフォーマットに、中間のフォーマットを使用せずに直接変換することを含んでいる。

第３の処理モジュールをコンピュータプログラムとして、第１の処理モジュールおよび第２の処理モジュールと同一のハードウェアシステムにインストールするか、または異なるハードウェアシステムにインストールして、他の２つのモジュールから別個に独立して実行することができる。第３の処理モジュールを、第２の処理モジュールの一部とすることもできる（第２の処理モジュールに組み込むことができる）。

コンピュータプログラムを実行するのに適したプロセッサはたとえば、汎用マイクロプロセッサおよび専用プロセッサ双方と、すべての種類のデジタルコンピュータのうち１つまたは複数のプロセッサとを有する。一般的には、プロセッサは命令およびデータを読み出し専用メモリまたはランダムアクセスメモリから受け取るか、または双方から受け取る。コンピュータの重要な要素は、命令を実行するためのプロセッサと、命令およびデータを記憶するための１つまたは複数の記憶装置である。一般的にはコンピュータは、データを記憶するための１つまたは複数の大容量記憶装置（記憶手段）も有しているか、または該大容量記憶装置からデータを受け取るかまたは該大容量記憶装置へデータを伝送するかまたは双方を行うために該大容量記憶装置と動作上有効に結合されている。前記大容量記憶装置はたとえば、磁気ディスク、磁気光学ディスク、または光学ディスクである。コンピュータプログラム命令およびデータを具現化するのに適した情報担体には、すべての形式の不揮発性メモリが含まれている。ここに含まれるのはたとえば、ＥＰＲＯＭ、ＥＥＰＲＯＭおよびフラッシュメモリデバイス等の半導体記憶装置、内部ハードディスクおよびリムーバブルディスク等の磁気ディスク、磁気光学ディスク、ＣＤ‐ＲＯＭディスクおよびＤＶＤ‐ＲＯＭディスクである。プロセッサおよびメモリは、ＡＳＩＣ（特定用途集積回路）によって補足するか、またはＡＳＩＣに包括することができる。

ユーザとのインタラクションを可能にするため、本発明を、ＣＲＴ（陰極線管）モニタまたはＬＣＤ（液晶ディスプレイ）モニタ等の表示装置と、キーボードと、マウスまたはトラックボール等のポインティング装置を備えたコンピュータ上で実施することができる。これによって、情報がユーザに対して表示され、ユーザがコンピュータに入力を行うことができる。別の種類の装置を使用して、ユーザとのインタラクションを可能にすることもできる。たとえば、ユーザに供給されるフィードバックは、視覚フィードバックまたは聴覚フィードバックまたは触覚フィードバック等のどの形式の感覚フィードバックでもよい。さらにユーザからの入力を、どの形式で受け取ってもよい。この形式には、音響入力、音声入力または触覚入力が含まれる。

ここで、データ処理プロセスに基づいて本発明を説明することにより、本発明の原理を詳述する。これらデータ処理プロセスの実施例は添付の図面に示されている。ここに挙げられた実施例は、本発明を説明するためのものであり、本発明をどのような意味でも制限しようとするものでない。

以下、第１処理モジュールを「請求者サービス提供者」（"biller service provider" ＢＳＰ）と称し、第２処理モジュールをコンソリデータ（"consolidator" 整理統合ユニット）と称し、また第３処理モジュールをカスタマーサービス提供者（"customer service provider" ＣＳＰ）と称する。ＣＳＰがコンソリデータに統合される場合、得られる組合せを「統合化されたＣＳＰ」（ｉＣＳＰ）と称する。

図１は、本発明の１実施形態の実施例を示している。ここでは本発明の方法を実施するプログラムモジュールを有するコンピュータシステムが示されている。図１にはＣＰＵ１０５を有するコンピュータ１０３と、ＣＰＵ１０５によって処理されるソフトウェアアプリケーションが記憶されている作業記憶装置１１２（メモリ）とからなるコンピュータシステム１０１が示されている。このソフトウェアアプリケーションには、本発明の方法にしたがい、第１処理モジュール、第２処理モジュールおよび第３処理モジュールをそれぞれ実行するプログラムモジュール１０６，１０９，１１０が含まれている。さらにコンピュータシステム１０１は、例えばプログラムモジュールをスタートさせるためおよび／またはデータ入力のためにユーザとのインタラクションするための入力手段１１７、出力手段１１２、ならびにデータを送受信するためのネットワーク接続部１１４を含む一般的な入／出力手段１０４を有している。ここでこのデータは、例えば、請求情報、請求書、支払いオーダ、カスタマおよび請求者のマスタデータなどである。複数のコンピュータシステム１０１を、ネットワーク１１３の形態でネットワーク接続部１１４を介して接続することができる。このような場合、各モジュール１０６，１０９，１１０は、別個および互いに無関係に各コンピュータ１１３において実装および実行することができる。この場合、ネットワークコンピュータ１１３は、さらなる記憶場所としての使用を含めて、さらなる入／出力手段として使用することができる。コンピュータシステム１０３はさらに、カスタマのマスタデータが記憶されている第１記憶手段１０７と、請求者のマスタデータが記憶されている第２記憶手段１０８とを含む。本発明の方法によれば、第１処理モジュール１１０（ＢＳＰ）は、記憶手段１０８に記憶されている請求者のマスタデータにアクセスでき、また第２処理モジュール１０６（コンソリデータ）は、記憶手段１０７に記憶されているカスタマのマスタデータにアクセスできる。請求者１１１およびカスタマ１１５は、入／出力手段１０４を介してコンピュータシステム１０３に常時接続されているか、またはオンデマンドベースで接続される。支払いサービス１１６に対して別のコネクションを確立することができる。請求者１１１およびカスタマ１１５と、付随するプログラムモジュール１１０，１０９とのインタラクションは、それぞれ破線の矢印で示されている。ＢＳＰおよびコンソリデータと、記憶手段１０８，１０７とのそれぞれの関係も同様である。

図２はいくつかのプログラムモジュール、すなわち、ＢＳＰ２０１ａ，２０１ｂ，コンソリデータ２０２ａ，２０２ｂ，２０２ｃ、およびＣＳＰ２０３のネットワークコネクションの例を示している。これらのモジュールはそれぞれ、別個のコンピュータシステム２０４ａ，ｂ，２０５ａ，ｂ，ｃおよび２０８に実装されている。それぞれのコンピュータシステムは適用事例の要求に依存して、同一でも互いに異なっていてもよい。コンピュータシステムは、世界中の別個の国々に設置することができる。一つまたはそれ以上の請求者がウェブブラウザ２０７ａ，ｂを使用し、コンピュータシステム２０６ａ，ｂを介してこのネットワークにアクセスすることができる。これらのコンピュータシステム２０６ａ，ｂは、各ＢＳＰ２０４ａ，ｂに接続可能である。カスタマは、ウェブブラウザ２１１を有するコンピュータシステム２１０を介してこのネットワークにアクセスすることができる。請求書に関連する支払いを実行するために、ｅバンキングアプリケーションを有する支払いサービス提供者のコンピュータシステム２０９を、１つまたはそれ以上のコンソリデータシステム２０５ａ，ｂ，ｃに接続することができる。

請求者マスタデータと、カスタママスタデータとを分ける本発明のコンセプトによれば、ＢＳＰを必要なだけ１つのコンソリデータに接続することができる。これによって、不必要なデータの移動が回避される。それは、請求書を処理するモジュールにカスタママスタデータを移動またはコピーする必要がないからである。これは従来技術の方法によれば必要である。このコンセプトによれば、例えば、１ヶ月当たりに数百万を上回る請求書量を、１つのコンソリデータに接続されているいくつかのＢＳＰで処理することができる。カスタママスタデータを更新しなければならない場合、本発明のシステムではこれは極めて簡単である。それは、コンソリデータのデータベースだけを変更すればよいからである。このような更新によってＢＳＰデータベースが影響を受けることはない。さらなる効果は、マスタデータに対するメンテナンスコストが低減されることである。

図３には、請求者とＢＳＰとの間、ＢＳＰとコンソリデータとの間、コンソリデータとＣＳＰとの間、およびＣＳＰとカスタマ（支払い者）との間でデータ交換することができるフォーマットおよびインタフェースの概要が示されている。請求者側は、３つのケースに分かれている。すなわち、ＳＡＰ ＥＲＰシステム（ＳＡＰ ＡＧ，D-69190 Walldorf, Germany）を使用する大規模の請求者と、ＳＡＰ ＥＲＰシステムでないシステムを使用する大規模の請求者と、小規模の請求者とに分かれている。ここで「大規模」および「小規模」とは、それぞれの会社または各人員の取引高のことであり、説明のためだけの任意の尺度である。カスタマ側にも同じことが相応に当てはまる。この例においてＣＳＰは、大規模支払い者の場合にはｉＣＳＰとしてコンソリデータに組み込まれており、また小規模支払い者の場合には、択一的な２つの実装、すなわちＳＡＰポータルＣＳＰおよびオンラインバンキングＣＳＰを有する別個のプログラムモジュールである。この例においてＢＳＰは、請求情報に対して４つのフォーマットをサポートしている。すなわちＩＤＯＣ，FLATFILEおよびEDIFACTフォーマットおよびあらかじめ定義可能なＢＳＰであり、請求者およびＢＳＰのシステムをそれぞれのソフトウェアの実装中にこれらに適合化しなければならない。請求者側のシステムは、ＨＴＭＬ，ＨＴＴＰＳ，ＸＭＬ‐ＩＤＯＣ（ＳＳＬ），ＦＬＡＴ（ＳＳＬ），ＥＤＩ（ＳＳＬ）に基づいてＢＳＰと通信することができる。ＢＳＰおよびコンソリデータ、またコンソリデータおよびＣＳＰも、ＸＭＬを介して通信することができる。ＣＳＰおよび／またはｉＣＳＰは、ＨＴＭＬ（ＨＴＴＰＳ），ＸＭＬ‐ＩＤＯＣ（ＳＳＬ），ＥＤＩ（ＳＳＬ）およびＸＭＬに基づいてカスタマのシステムと通信することができる。

図４は、ＢＳＰおよび／またはＣＳＰおよび／またはｉＣＳＰが有し得るインタフェース（ＩＦ）の例を示している。すなわち請求者またはカスタマのＥＤＩ／ファイルＩＦ，ウェブＧＵＩ（graphical user interface），ＢＣＸ，フラットファイル（Flat File）変換，プリントＩＦ，アーカイブＩＦ，請求エンジンとのコネクションに対するコストイベントＩＦ，支払いサービス（金融機関）とのコネクションに対するＩＦ，またはインターネットサービスプロバイダ（ＩＳＰ）とのコネクションに対するＣＣＸ ＩＦが示されている。これらの請求者は、その請求書要約のリストを見るため、請求者はＢＳＰに接続することができ、カスタマは好みに応じて、ＣＳＰ／ｉＣＳＰに直接接続するか、または金融機関またはＩＳＰへのコネクションを介して間接的に接続することができる。項目化された請求書および登録に対して、カスタマはＢＳＰに接続することができる。ＢＳＰは、請求者に関連するすべてのデータをパートナデータベースに記憶する。請求者のマスタデータは、アドレス、識別キー、権限付与、請求者統合化レベル（インタフェース能力および実装された処理）、ロゴ、請求書におけるロゴの位置、個人別の販売促進に対する宣伝フォーム、クレジットに対するフォーマット、ディジタル署名などを含む。請求情報、生成および／または変換された請求書、ウェブ提示に対する請求書の詳細は、ＢＳＰによってビジネスオブジェクトデータベースに記憶することができる。この意味でのビジネスオブジェクトは、特定の請求書の発生原因としてのビジネストランザクションに属するデータ全体のことである。典型的な請求情報は、品物、品物のタイプ、番号、ポジション、ＩＤ、品物の説明、価格、税情報、住所（例えば配送用）、参照（詳細に対するＵＲＬ）、日付（例えば、請求日）などである。コンソリデータ／ｉＣＳＰは、カスタマおよび金融機関に関連するすべてのデータをパートナデータベースに記憶する。すなわち、カスタマのアドレス、カスタマの組織内およびカスタマと請求者との間の通信用のアドレス、請求書を提示すべきフォーマット、ステータス情報または異議申し立てまたは調査管理を供給するためのアドレス、識別キー、権限付与、ディジタル署名などを含むカスタマのマスタデータを記憶する。カスタマに提示すべき請求書サマリまたは整理統合または総計された請求書は、コンソリデータ／ｉＣＳＰによってコンソリデータのビジネスオブジェクトデータベースに記憶される。このようにして、請求書量を処理するために必要な数のＢＳＰを１コンソリデータ／ｉＣＳＰに接続することができる。

プログラムモジュール１０６，１０９，１１０が図１のＣＰＵ１０５によって処理されて本発明の方法が実施される場合、以下に説明するステップが上記のようにコンピュータシステム１０１またはネットワークのシステムによって実行される。

図５は、本発明の方法の例示的な実施の流れ図を示している。このタイプの流れ図の時間軸は、上から下に経過する。請求者は（そのＥＲＰコンピュータシステムによって）、この請求者がＢＳＰ登録時に合意したフォーマットで請求情報をＢＳＰに送信する。ＢＳＰは、この請求情報および請求者マスタデータに基づいて請求書を作成し、ステータス「新しい」をこのオブジェクトに割り当てる。次にこのＢＳＰは、カスタマについての情報の要求（CustomerInfoRequest）をコンソリデータ／ｉＣＳに送信する。コンソリデータ／ｉＣＳＰはこの要求に応答して、問い合わされたカスタマに対するカスタママスタデータベースから、使用可能なデータをこのＢＳＰに返す（CustomerInfoResponse）。上で示した情報に加えて、上記の応答は、カスタマが、ウェブ提示のための請求書データを要求したか（疎な整理統合化、「疎である」のは主要な情報だけがカスタマに提示されるからである）、またはＥＲＰシステムにおける処理のための請求書データを要求したか（密な整理統合化、「密である」のはこの請求書が、請求書の詳細を含めてカスタマに電子的に送信されるからである）、または適用可能な税または別の法的な規定にしたがってディジタル署名フォーマットで行うか、または提示する請求書を暗号化するか否かについての情報を含むことができる。さらに付加的に上記の応答は、各ＥＲＰシステムにおける各ＩＤに関する、請求者とカスタマとの関係についての情報（ＢＣＲ biller to customer relation）を含むことができる。さらに付加的に上記の応答は、項目化された請求書にアクセスするためまたは暗号化（ディジタルＩＤのリスト、識別名（distinguished name）、証明シリアル番号など、Ｘ．５０９証明書を参照する）に対する認証情報を含むことができる。次にＢＳＰは、CustomerInfoResponse（カスタマ情報応答）で受信したフォーマットに請求書を変換する。

データは、ソースフォーマットからターゲットフォーマットにできるだけ直接的に、ソースのできる限り近くで変換すべきであり、また可能であれば、変換は回避すべきである。それはデータ損失のリスクを孕んでいるからである。ターゲットフォーマットを内部で形成できない場合には、ＢＳＰは外部の変換サービスを使用することができる。理由は、ＢＳＰにおいて請求書を直接的にカスタマのフォーマットに変換することにより、ＶＡＴ控除に対する政府の規定に適合する請求書をディジタル署名することができるからである。カスタマは直接、処理して、明細請求書をアーカイブすることができ、これによって簡単な統合化プロセスが得られ、アプリケーションコンテンツを比較的簡単に保存することができるようになる。サポートされるフォーマットの総数を少なくすること（標準化）によって変換作業およびコストが低減され、ＰＳＰ（支払いフォーマット）固有の適合化は、コンソリデータ／ｉＣＳＰにおいて処理することができる。

従来技術によるＥＢＰＰシステムのコンテキストでは変換は、中間（社内"in-house"）フォーマットを使用することによって間接的に行われ、ソースデータはまずこの社内フォーマットに変換され、つぎにターゲットフォーマットに変換される。この技術の利点は、変換の回数が、フォーマットの数（ｎ）に対して、直接変換の場合のｎ(ｎ−１)と比較して線形（２ｎ）になることである。しかしながら中間フォーマットというものがＢＳＰの提示時における変換にも使用できる事実とは関係なく、カスタマフォーマットへの変換は提示プロセスにおいてできる限り早く行うべきである。ＢＳＰにおいてエンドユーザフォーマットに明細請求書を変換することの利点は、ＢＳＰにおいてこの請求書に署名できることである。請求者は、その請求書作成プロセスをＢＳＰに外注するので、ＢＳＰに署名を委任することが可能である。コンソリデータにおいてＰＳＰフォーマットを請求者およびカスタマのフォーマットに変換することの利点は、コンソリデータだけがＰＳＰ（例えば国）固有拡張を含むことである。ＢＳＰおよびＣＳＰはＰＳＰフォーマットには無関係のままである。

ＢＳＰは第３者のハードウェアシステムに実装されている場合、法的には請求者の外注パートナとして扱われる。同じことがＣＳＰおよびコンソリデータ／ｉＣＳＰにも相応に適用される。この点においてＢＳＰは、電子的な請求書を請求者に代わって作成し、またオプションとして紙の請求書も作成するのである。法人としての請求者は、ＢＳＰを運営する法人に請求書にディジタル署名する権利を委任するのである。ＢＳＰは、カスタマによって承諾され、可読であり、処理可能であり、かつＶＡＴ控除において有効なフォーマットで、ディジタル署名された明細請求書メッセージを作成しなければならない。これは上述の変換プロセスを使用することによって達成される。カスタマは、上記の委任をオンラインでチェックすることができる。請求者のリスト（電子請求書に対するカスタマ登録を参照されたい）は、ＢＳＰにありかつ請求者によってディジタル署名された委任文書へのハイパーリンクを含んでいる。

多くの欧州の国々では、最近まで、購入した品物に対するＶＡＴ（Value Added Tax）の払い戻しのために、明確に規定された最小セットの情報を有する紙の明細請求書を管轄官庁に提示しなければならなかった。また請求明細の文書は、請求者が印刷しなければならなかった。電子的に伝送され、カスタマによって印刷された請求書は認められなかったのである。欧州連合および他の国々（例えばスイス）では新たな法律および規則により、請求者によってディジタル署名された請求書であれば、電子的に伝送された請求書に基づくＶＡＴ控除が認められる。署名に使用される証明および手続きは規制されている。

要求されるフォーマットを生成するためにＢＳＰは、外部の変換サービス、例えばウェブサービスにアクセスすることができる。考えられ得るカスタマのアクセスに対する請求書の提示には準備がなされる。選別：カスタマと電子的に連絡を取れない場合、例えばCustomerInfoResponse（カスタマ情報応答）が「不明」を返す場合、ＢＳＰは紙の請求書を生成し、および／または請求者に相応に通知することができる。

請求情報に含まれている明細請求書送付日付に達したら、ＢＳＰは、変換した請求書をコンソリデータ／ｉＣＳＰに送付する（InvoiceDeliveryRequest 明細請求書送付要求）。付加的にＢＳＰは、コンソリデータ／ｉＣＳＰに、請求者の統合化状況についての情報を提示する（BillerPreference 請求者好み設定）。これらの情報は、コンソリデータ／ｉＣＳＰが、受信した変換済み請求書を操作するのに有益である。これらの操作は、利用可能なクレジットの通知またはクレジット通知フォーマット、請求者に対するその時点のビジネストランザクションのステータス（例えば、請求書送付済、または請求額支払い済、等）、サポートされている処理（例えば、異議申し立て、送金通知拒絶など）に対する要求である。コンソリデータ／ｉＣＳＰは、変換した請求書が、カスタマがアクセスするために使用できることを、ＢＳＰへのｏｋ応答によって確認する（InvoiceDeliveryResponse 明細請求書送付応答）。ＢＳＰは、請求書のステータスを「送付済み」に設定し、コンソリデータ／ｉＣＳＰは、受信した変換済み請求書のステータスを「オープン」に設定する。

次の処理ステップは、カスタマがウェブカスタマであるか、またはＥＲＰカスタマであるかに依存するか、または支払いの好みが、特定のカスタマに対して適用可能であるか否かに依存するか、または請求者およびカスタマの支払いサービス提供者（ＰＳＰ）の接続状況に依存する。いくつかのオプションを挙げると、バンキングポータルを使用したウェブ提示および支払い（ＣＣＸ ＩＦ）、ＩＳＰ（例えばyahoo）およびＰＳＰを使用するウェブ提示および支払い、支払いチャンネル（payment channel）を使用するＥＲＰ接続および支払い、ＳＡＰ ＥＢＰＰシステムを使用したＥＲＰ接続および支払いがある。カスタマは、変換された自分の請求書をコンソリデータ／ｉＣＳＰから受け取るか、またはウェブポータルを介して、コンソリデータおよび／またはｉＣＳＰデータベースにある、変換された請求書にアクセスする（請求書送付）。オプションのステップを、明細請求書検査、資料管理とのクロスチェック、支払い処理のための作業フローに基づいて行うことができる。次に（オプションでディジタル署名された）支払いオーダがコンソリデータ／ｉＣＳＰに送信される。次にコンソリデータ／ｉＣＳＰは、支払いオーダによって構成された支払いスケジュール情報をＢＳＰに伝える（SetEBPPStatusRequest）。次にＢＳＰは、（オプションではスケジュールされた）支払いを請求者に通知する。直ちにまたは要求された支払い日に、コンソリデータ／ｉＣＳＰは、ＰＳＰによって要求されたフォーマットで支払いオーダを生成し、この支払いオーダをＰＳＰに送信する。この支払いオーダは、暗号化法で認証され、ＰＳＰは支払いを処理する。その際に要求があれば、銀行間支払い処理が使用される。カスタマのＰＳＰは、コンソリデータ／ｉＣＳＰに要求して、口座引き落とし通知（debit advice）をカスタマに送信させる。コンソリデータ／ｉＣＳＰは、カスタマが要求したフォーマットで口座引き落とし通知を生成し、メッセージをカスタマに送信させる（口座引き落とし通知）。変換された請求書のコンソリデータ／ｉＣＳＰにおけるステータスは、「支払い済」に設定される。請求者のＰＳＰは、コンソリデータ／ｉＣＳＰに要求して、この請求者にクレジット通知を送信させる。コンソリデータ／ｉＣＳＰは、請求者によって要求されたフォーマットでクレジット通知を生成して、ステータス変更要求と一緒にそのメッセージをＢＳＰに送信する（SetEBPPStatusRequest）。ＢＳＰは、このクレジット通知メッセージを請求者に送信して、請求書のステータスを「支払い済」に変更する。

図６には請求書提示プロセスの例示的なフローチャートが示されている。

カスタマまたはユーザは、ＣＳＰ／ｉＣＳＰにログインする（標準的なプロシージャ：ディジタルＩＤ（X.509），ＳＳＬクライアント認証）。このＤＮ（distinguished name 識別名）がｉＣＳＰ／コンソリデータへウェブアクセスするのを許可しなければならない。このユーザは次にクライアント（カスタマ）を選択するか、またはこのユーザがクライアントを有しない場合、該ユーザがすでにログインしているカスタマの整理統合された請求書のリストを直接選択することができる（GetListOfBills）。このリストの各請求書毎に、典型的には以下のデータを提示する。すなわち、明細請求書参照、請求者名、請求者銀行預金口座、支払期日、通貨による金額、ビジネストランザクション（請求書）ステータス（オープン、（または催促）、満期、予定、支払済み、異なる金額による支払い）、請求書に対する付加的な情報用のハイパーリンク（ルーペシンボルまたは下線付きの明細請求書参照）を提示することができる。カスタマは、ハイパーリンクを選択して、請求書に対する付加的な情報を得ることができる。この（ＳＳＬ）ハイパーリンクは、請求者の情報ページをポイントしており、これは、通常、ＢＳＰがホストをしている（択一的な例としてはこのページは請求者のウェブサーバに存在することも可能である）。ＢＳＰは、トークン（請求書の詳細が準備される時点で生成され、請求書サマリの一部として渡される）に基づいてカスタマを認証する。このトークンは、ハイパーリンクと一緒にＢＳＰに戻される。カスタマが強力な認証を要求する場合、認証がCustomerInfoReference（カスタマ情報参照。前の図を参照されたい）で指定された証明書のうちの１つと一致する場合にだけ請求書が提示される。ＢＳＰは複数のＨＴＭＬテンプレートを保持しており、参照されたビジネストランザクション（請求書）に基づいて適切なテンプレートを選択する。このテンプレートは、書き込むべきビジネストランザクションデータを参照することができる（例えば、個人別の広告に有効である）。カスタマアドレスに基づき、また請求者との合意により、ローカルな第３者の広告を付加することができる。生成したＨＴＭＬページは、項目化された請求書へのハイパーリンクを含む。カスタマは、この項目化された請求書へのハイパーリンクを選択して、（認証の後）ＰＤＦフォーマットで請求書を受信する。

図７には、電子請求書に対するカスタマの登録プロセスの例示的なフローチャートが示されている。

カスタマまたはユーザは、ＣＳＰ／ｉＣＳＰにログインする（標準的なプロシージャ：ディジタルＩＤ（X.509），ＳＳＬクライアント認証）。このＤＮ（distinguished name 識別名）がｉＣＳＰ／コンソリデータのマスタデータへのウェブアクセスするのを許可しなければならない。ユーザは次にクライアント（カスタマ）を選択するか、またはこのユーザがクライアントを有しない場合、請求者のリストを直接、選択することができる。コンソリデータは、電子的な請求者への情報を含む（通常は管理保持された）ＨＴＭＬテンプレートを保有している。このリストには、ロゴおよびＢＳＰからの請求者データを補足することができる。ここでこれはハイパーリンクを使用して行われる（択一的にはこのデータをコンソリデータにおいてローカルに保持することも可能である）。また提示されるリストは、各請求者ごとにカスタマ登録ステータス（イナクティブ、アクティブ、登録要求、登録拒絶）も含んでいる。この登録ステータスは、コンソリデータのＢＣＲ（Biller Customer Relation 請求者カスタマ関係）テーブルに記憶される。カスタマは、請求者を選択する。登録フォームに対するＵＲＬは、ＢＳＰ（または請求者のウェブサーバ）をポイントする。ＢＳＰは、カスタマＰＩＤ（Partner Identification Number パートナ識別番号）をこのＵＲＬから受信する。またこのカスタマを認証できない場合、ＢＳＰは、コンソリデータから受信したＰＩＤに一致するカスタママスタデータを受け取る。請求者固有のＨＴＭＬテンプレートに基づいて登録フォームが提示される。これはカスタマのマスタデータ（編集不可）と、少なくとも登録または登録を取り消すためのボタンを含む。付加的に請求者は、ＢＣＮ（Biller's Customer Number請求者側のカスタマ番号または債権者番号）を要求することができる。カスタマがこの請求書をＥＲＰシステムで処理する場合、この登録フォームは、ＣＢＮ（Customer's Biller Number カスタマ側の請求者番号 ＝ 債務者番号）を記入するために１フィールド分拡張される。カスタマは、この登録フォームを記入完了し、これをＢＳＰに返送する。ＢＳＰは、コンソリデータにおいて「登録要求（registration＿requested）」のステータスを有するＢＣＲエントリを作成する。ＢＳＰは、新たな登録について請求者に（例えばＥメールで）通知することできる（オプション）。

図８は、カスタマの登録に対する請求者の動作の例示的なフローチャートを示している。

請求者または（請求者の）ユーザは、ＢＳＰにログインする（標準的なプロシージャ：ディジタルＩＤ（X.509），ＳＳＬクライアント認証）。ＢＳＰのマスタデータへのウェブアクセスに対してＤＮ（distinguished name 識別名）を許可しなければならない。ユーザは次にクライアント（請求者）を選択するか、またはこのユーザがクライアントを有しない場合、フィルタリング検索条件（例えば、すべてのregistration＿requested 登録要求）を直接定めて、カスタマのリストにアクセスすることができる。ＢＳＰは、この要求をコンソリデータ／ｉＣＳＰに送信して、コンソリデータ／ｉＣＳＰの応答を処理し、請求者にカスタマのリストを提示する。請求者は、提供された登録情報を詳細に調べて（ＢＣＮおよびカスタマ名における不整合は回避すべきである）、登録データが正しい場合にはＢＣＲステータスを「アクティブ」にする。ＢＳＰは、SetBCRState（ＢＣＲ状態設定）要求を使用して、コンソリデータ／ｉＣＳＰにＢＣＲ状態を設定する。ＢＣＲテーブルにおいて適切な状態を設定した後、コンソリデータ／ｉＣＳＰは、（例えばＥメールによって）カスタマに通知することができる。

図９には請求者カスタマ関係テーブルのコンセプトが示されている。

請求者カスタマ関係コンセプトは、請求者またはカスタマＥＳＰシステムの統合化を最適にサポートするために設計されている。

ＢＣＮ（Billers Customer Number 請求者側カスタマ番号）：ＢＣＮまたは債務者番号は、コンソリデータ／ｉＣＳＰシステムに記憶することができる。これによって請求者は、ＢＳＰに送信される請求データに存在するカスタマ識別子を使用することができる。コストのかかるマッピングを回避することができる。カスタマ登録プロセスにおいて取得された情報に基づいて、コンソリデータ／ｉＣＳＰは、ＢＣＮを一意的なカスタマ識別子（例えば、ＣＰＩＤ，Customer Partner Identification カスタマのパートナ識別子）にマッピングすることができる。

ＣＢＮ（Customers Biller Number カスタマの請求者番号）：カスタマＥＲＰシステムにおいて請求者を識別するために使用される債権者番号も、カスタマ登録プロセス中にコンソリデータ／ｉＣＳＰに記憶される。これによってＢＳＰは、ＢＳＰにおける変換中にＢＰＩＤ（Biller Partner Identification 請求者のパートナ識別子）を、カスタマＥＲＰシステムに既知である請求者ＩＤに直接マッピングすることができる。したがってカスタマは、面倒でコストのかかるＩＤのマッピングを実装する必要はないのである。

図１０にはＣＣＸ ＩＦを使用したｅバンキング統合化が示されている。ＣＣＸ（Consolidator CSP Exchange コンソリデータＣＳＰ交換）インタフェースを使用すれば、ｅバンキングソリューションにより、請求書提示を統合化することができる。カスタマは、複数のＣＳＰ（マルチバンキング）を使用することができる。すなわち、ＣＳＰは、提示のために、コンソリデータ／ｉＣＳＰにおける請求書のその時点のリストを取り出すことができる。請求書はＣＳＰによって単純にルーティングされるのではない。これによりカスタマは、相異なる複数のＣＳＰ（例えば銀行）からの自分の請求書を見て、支払うことができるという独特の手段が得られる。

図１１および１２には、請求書を確認するための作業フローの例示的なフローチャートが示されている。

ここではディスパッチャと称することにするカスタマの１従業員は、コンソリデータ／ｉＣＳＰにログインして請求書のリストを選択する（ウェブ請求書提示を参照されたい）。確認作業フローのための準備がまだ整っていない請求書の場合、ディスパッチャは、SetUpReviewWorkflow（確認作業フローのセットアップ）を選択することができる。フォームが提示されると、ディスパッチャは、確認者のリストを決めることができる。これは確認者のＥメールアドレス（またエイリアス）を入力することによって行われる。ディスパッチャは、またテキスト（質問、請求書項目の割り当てその他）を入力することもできる。これと並行してディスパッチャは、項目化された請求書を提示させることができる（ウェブ請求書提示を参照されたい）。ディスパッチャは、このフォームをコンソリデータ／ｉＣＳＰに返送する（PostReviewForm）。ｉＣＳＰ／コンソリデータは、Ｅメールを確認者に送信する（可能であれば、暗号化またはプライベート（社内）ネットワークを使用する）。このＥメールは作業項目、確認請求書および（カスタマイズ可能な）短い説明へのハイパーリンク（ＵＲＬ）を含むことができる。オプションで、このＥメールは認証トークンを含むことが可能である。ビジネストランザクションのステータスは、「請求書確認」に変更される。このＥメールの受信者は、このＥメールにリストアップされていたｉＣＳＰ／コンソリデータのＵＲＬに接続する。ｉＣＳＰは有利にはＳＳＬクライアント認証を使用し、受信した証明書と、マスタデータ内の認可された証明書とを比較するか、またはＵＲＬのトークンに基づいてユーザを許可するか、ユーザｉｄ／パスワードメカニズムに基づいてユーザを認証する（認証／許可方式はシステムにおいてカスタマイズ可能である）。ｉＣＳＰ／コンソリデータは、これまで付加したすべてのデータと一緒に現在の確認フォームを返送する。この確認フォームも付加的な請求情報へのハイパーリンクを含むことができる（ウェブ請求書提示を参照されたい）。ユーザは、請求書の内容についてコメントおよび会計情報を付加することができる（例えば、ポジション３は受信していない、ポジション１および４はｏｋ、内部明細番号XYZに変更その他）。記入済みのフォームはｉＣＳＰ／コンソリデータに返送される（PostReviewForm）。別の確認者も、自分の作業フローの項目を同様に処理することができる。ディスパッチャまたは権限を有する別の任意のユーザは、任意の時点に請求書のリストを介して確認フォームにアクセスすることができる。すべての確認者が確認フォームを送り、ビジネストランザクションの状態が期限日に依存して「オープン」または「期限日」に設定されると、システムはあらかじめ定めたアドレスにメッセージを送信する。確認者は、別の請求書または請求書のリストにアクセスする必要はない。認証／許可だけをｉＣＳＰ／コンソリデータに記憶するだけでよい（例えば、ディジタルｉｄを有する確認者に対し、そのＤＮだけを請求書確認のための権限と結び付けて記憶するだけでよい）。

図１３には例示的なアーカイブ作成プロシージャが説明されている。アーカイブ作成は、適用可能な規則（ＶＡＴ）の要求を満たさなければならない。請求者は、ＢＳＰとのすべてのビジネストランザクション（請求書）を含むＣＤまたはＤＶＤ ＲＯＭまたは別の読み取り専用の装置の形態でアーカイブを受け取る。カスタマも請求者と同じ形態で、ｉＣＳＰ／コンソリデータとのすべてのビジネストランザクションを含むアーカイブを受け取ることができる。ＰＳＰおよびサポート組織もそれ自体のデータを含むアーカイブを受け取ることができる。アーカイブは以下のものを含むことができる：
ＢＳＰ、ｉＣＳＰ／コンソリデータによってそれぞれディジタル署名されたインデックス。ここでこのインデックスは、アーカイブにあるすべてのビジネストランザクションの請求書サマリを含む。このインデックスにはディジタル署名することができ、これによって各ビジネストランザクション（提示された請求書）毎にアーカイブ内容の証明ができるようにする（ビジネストランザクションは除去できない）。

請求書サマリと、すべてのビジネストランザクションイベントの履歴と、オリジナルメッセージへのハイパーリンクとを含むビジネストランザクションリポート。

交換されたすべてのメッセージ。例えば、構造化されたメッセージ（ＸＭＬ ＩＤＯＣまたはEDIFACTなど）としてのディジタル署名された明細請求書、同様にディジタル署名されたＰＤＦファイルとしての明細請求書、など。

オプションでは暗号化メカニズムが適用されて、アーカイブのいかなる内容変更も回避される。このアーカイブは、請求者またはカスタマの要求にしたがって定期的に作成することができる。アーカイブを請求者またはカスタマに送付することができる。受け取り側は、受け取ったアーカイブが読み取れることを確認することができ、これは「アーカイブ受け入れ」メッセージを送信することによって、またはこの受け入れをインタラクション的に確認することによって行われる。 所要の受入メッセージをすべて受信した後、また設定可能な営業日数（典型的には９０日）の後、ビジネストランザクションは、ＢＳＰおよびｉＣＳＰ／コンソリデータからそれぞれ除去することできる。

上に示した本発明の方法およびシステムにより、ＥＢＰＰシステムにおける次のような要求が満たされる。すなわち、請求者ＩＴシステムとカスタマＩＴシステムとを簡単に統合化すること、１つのカスタマに対して、異なる請求者の請求書を整理統合すること、支払いに対して複数の金融機関を許容すること、請求書の詳細のプライバシーおよびアクセスセキュリティ、政府のＶＡＴ規定の遵守、請求書量についての高いスケーラビリティ、クロスボーダーのＥＢＰＰを許容すること、および請求書確認作業フローなどの要求が解決される。

ここに示した実施例および本明細書の考察から当業者には本発明の変更および適合化が明らかであろう。本発明の実施について上で述べたことは、例解および説明を目的として示しただけである。ここに記載されたものだけがすべてではなく、また開示した内容と正確に同じ形態に本発明を制限するものではない。上で教示した内容を考え合わせれば変更および変形が可能であり、また本発明の実施例から変更および変形を得ることもできる。例えば、上で説明した実現はソフトウェアを含むが、本発明に見合ったシステムおよび方法をハードウェアおよびソフトウェアの組合せとして、またはハードウェア単独で実現することができる。さらに、メモリに記憶することに関して本発明の種々の側面を説明したが、当業者には、これらの側面は、別のタイプのコンピュータ読み取り可能な媒体、例えばハードディスク、フロッピィディスク、またはＣＤ−ＲＯＭ等の２次記憶装置、インターネットまたは別の伝搬媒体、またはＲＡＭまたはＲＯＭの別の形態にも記憶することができることがわかるであろう。明細書および実施例は例示だけのものとみなされることを意図しており、本発明の真の範囲および思想は添付の特許請求の範囲に示されている。

言葉による説明およびフローチャートに基づくコンピュータプログラムは、経験を積んだ開発者の技量の範囲内にあるものである。当業者に公知の任意のテクニックを駆使して種々のプログラムまたはプログラムモジュールを作成することができ、または既存のソフトウェアと結びつけて設計することができる。例えば、プログラムまたはプログラムモジュールは、Ｊａｖａ(Ｒ)，Ｃ＋＋，ＨＴＭＬ，ＸＭＬまたはＪａｖａアプレットが組み込まれたＨＴＭＬで、またはこれらを用いて設計することができ、またはＳＡＰ Ｒ／３またはＡＢＡＰで設計することできる。１つまたはそれ以上のこのようなモジュールを既存のＥメールまたはブラウザソフトウェアに組み込むことができる。

コンピュータシステムで本発明の方法の実施を概略的に示すブロック図である。 本発明の方法の一例のブロック図である。 本発明の電子的な請求書提示支払いシステムの一例の概観図である。 第１の処理モジュールおよび第２の処理モジュールの接続の一例のブロック図である。 本発明の請求プロセスの一例のフローチャートである。 本発明の請求書提示プロセスの一例のフローチャートである。 本発明の電子的請求システムにおいてカスタマを登録するためのプロセスの一例のフローチャートである。 カスタマの登録を請求者によってアクティベートするためのプロセスの一例を示すフローチャートである。 カスタマに対する請求者のＩＤを、請求者に対するカスタマのＩＤにマッピングするためのテーブルの一例を示すブロック図である。 本発明の電子的な請求書提示支払いシステムにｅバンキングを組み込む一例のブロック図である。 カスタマによる請求書の確認を開始および実行するためのプロセスの一例を示すフローチャートである。 図１１に示されたフローチャートの続きを示している。 請求者またはカスタマのデータのためのアーカイブ作成プロセスの一例を示すブロック図である。

Claims (37)

1. カスタマに対する請求書を電子的に処理するコンピュータシステムにおいて、
   該コンピュータシステムは、第１処理モジュール（ＢＳＰ）と、第２処理モジュール（コンソリデータ）とを有しており、
   前記の第１処理モジュール（ＢＳＰ）は、
   − 請求者によって入力されたデータを受信する手段と、
   − 当該の受信データを記憶する請求者マスタデータ記憶手段と、
   − 当該の請求者マスタデータ記憶手段に記憶されているデータから請求書を作成する手段と、
   − 当該の作成した請求書をカスタマによって指定された請求書フォーマットに変換する手段とを有しており、
   前記の第２処理モジュール（コンソリデータ）は、
   − カスタマによって入力されたデータを記憶するカスタママスタデータ記憶手段と、
   − ビジネストランザクションに関するすべてのデータを記憶するビジネスオブジェクトデータベースと、
   − 前記の第１処理モジュールによって作成され変換された複数の請求書をカスタマ毎にまとめて前記のビジネスオブジェクトデータに記憶するコンソリデーション手段とを有しており、前記のカスタママスタデータには請求書フォーマットが含まれており、
   前記の第１処理モジュールおよび第２処理モジュールはそれぞれ、データを互いに交換するための手段を有しており、
   前記の１つまたは複数の第１処理モジュールと第２処理モジュールとが当該のデータ交換手段を介して接続されており、ここで
   ａ） 第１処理モジュールは、請求者によって入力された請求情報を受信し、
   ｂ） 第１処理モジュールは、前記の請求情報および前記の請求者マスタデータ記憶手段に記憶されているデータを使用して請求書を作成し、
   ｃ） 第１処理モジュールは、前記のデータ交換手段を介し、前記の請求書に対応しかつ前記のカスタママスタデータに記憶されている請求書フォーマットを第２処理モジュールに要求し、
   ｄ） 第１処理モジュールは、当該の請求書フォーマットを受信し、
   ｅ） 請求者によって使用される請求書フォーマットが、前記の第２処理モジュールにて指定されかつ当該第２処理モジュールから受信した請求書フォーマットでない場合、第１処理モジュールは、前記の作成した請求書を前記の第２処理モジュールから受信した請求書フォーマットに変換し、
   ｆ） 第１処理モジュールは、当該の変換した請求書を第２処理モジュールに送信し、
   ｇ） 第２処理モジュールは、当該の第２処理モジュールに送信された複数の請求書をカスタマ毎にまとめて前記のビジネスオブジェクトデータに記憶することを特徴とする、
   カスタマに対する請求書を電子的に処理するコンピュータシステム。
2. さらに前記の第２モジュール（コンソリデータ）に接続された第３処理モジュール（ＣＳＰ）を有しており、
   該第３処理モジュールは、
   − カスタマによって入力されるデータを受信する手段と、
   − 当該のカスタマに請求書を提示する出力手段とを有しており、
   ここで前記の第２処理モジュールは、前記のまとめた請求書を第３処理モジュールがアクセスできるようにする、
   請求項１に記載のコンピュータシステム。
3. さらに前記のまとめた請求者をカスタマがアクセスできるようにした、
   請求項１または２に記載のコンピュータシステム。
4. さらに前記のまとめた請求書をカスタマに提示または配送する、
   請求項１から３までのいずれか１項に記載のコンピュータシステム。
5. さらに前記の第１処理モジュールによって請求書にデジタル署名する、
   請求項１から４までのいずれか１項に記載のコンピュータシステム。
6. さらにカスタマがアクセスできるようにするため、前記のまとめた請求書または当該の請求書の詳細の記憶位置へのリンクが当該のまとめた請求書に設けられている、
   請求項１から５までのいずれか１項に記載のコンピュータシステム。
7. さらに前記の作成した請求書および／または変換した請求書が第１処理モジュールによって暗号化され、および／または前記のまとめた請求書が第２処理モジュールによって暗号化される、
   請求項１から６までのいずれか１項に記載のコンピュータシステム。
8. 前記の作成した請求書および／または変換した請求書が第１処理モジュールによってアーカイブされ、および／または前記のまとめた請求書が第２処理モジュールによってアーカイブされる、
   請求項１から７までのいずれか１項に記載のコンピュータシステム。
9. さらに前記の第２処理モジュールには１つまたは複数の別の第２処理モジュールとデータを交換する手段が設けられている、
   請求項１から８までのいずれか１項に記載のコンピュータシステム。
10. さらに前記の第２処理モジュールにより、支払いオーダをカスタマから受信する、
    請求項１から９までのいずれか１項記載のコンピュータシステム。
11. さらに前記の第２処理モジュールにより、支払いオーダまたはまとめられた支払いオーダが支払いサービス提供者に転送される、
    請求項１から１０までのいずれか１項に記載のコンピュータシステム。
12. さらに前記の請求情報には、請求者および／またはカスタマおよび／または支払いサービス提供者のアドレス情報、および／または支払い情報、および／またはＶＡＴ情報、および／または購入オーダに関連する項目化された請求位置、および／または会計情報が含まれる、
    請求項１から１１までのいずれか１項に記載のコンピュータシステム。
13. さらに前記の請求者マスタデータには、アドレス情報、および／またはデータフォーマット情報、および／または通信アドレスに関する情報、および／または銀行情報および銀行口座情報、および／またはユーザ認証情報、および／またはユーザ許可情報、および／またはアーカイブサービスのための任意選択に関する情報、および／または印刷サービスのための任意選択に関する情報、および／または通知のための任意選択に関する情報が含まれる、
    請求項１から１２までのいずれか１項に記載のコンピュータシステム。
14. さらに前記のカスタママスタデータには、アドレス情報、および／またはデータフォーマット情報、および／または通信アドレス、および／または銀行情報および銀行口座情報、および／またはユーザ認証情報、および／またはユーザ許可、および／またはアーカイブサービスのための任意選択に関する情報、および／または通知のための任意選択に関する情報が含まれる、
    請求項１から１３までのいずれか１項に記載のコンピュータシステム。
15. さらに前記の第２処理モジュールは、１つまたは複数の別の第３処理モジュールとデータを交換するための手段を有する、
    請求項１から１４までのいずれか１項に記載のコンピュータシステム。
16. 前記の第２処理モジュールまたは第１処理モジュールは、特定のカスタマに対する請求者のＩＤを、特定の請求者に対するカスタマのＩＤにマッピングするための手段を有する、
    請求項１から１５までのいずれか１項に記載のコンピュータシステム。
17. 前記の請求者によって使用されたフォーマットがカスタママスタデータで指定されたフォーマットでない場合、中間フォーマットを使用せずに、請求者によって使用されたフォーマットからカスタママスタデータで指定されたフォーマットに請求書が直接変換される、
    請求項１から１６までのいずれか１項に記載のコンピュータシステム。
18. エンタープライズリソースプランニングソフトウェアに使用される、
    請求項１から１７までのいずれか１項記載のコンピュータシステム。
19. カスタマに対する請求書を電子的に処理するシステムとしてコンピュータを機能させるプログラムにおいて、
    該プログラムは、請求書を作成する第１処理モジュール（ＢＳＰ）および請求書をまとめる第２処理モジュール（コンソリデータ）として前記コンピュータを機能させ、
    前記の第１処理モジュール（ＢＳＰ）は、
    − 請求者によって入力されたデータを受信する手段と、
    − 当該の受信データを記憶する請求者マスタデータ記憶手段と、
    − 当該の請求者マスタデータ記憶手段に記憶されているデータから請求書を作成する手段と、
    − 当該の作成した請求書をカスタマによって指定された請求書フォーマットに変換する手段とを有しており、
    前記の第２処理モジュール（コンソリデータ）は、
    − カスタマによって入力されたデータを記憶するカスタママスタデータ記憶手段と、
    − ビジネストランザクションに関するすべてのデータを記憶するビジネスオブジェクトデータベースと、
    − 前記の第１処理モジュールによって作成された複数の請求書をカスタマ毎にまとめて前記のビジネスオブジェクトデータに記憶するコンソリデーション手段とを有しており、前記のカスタママスタデータには請求書フォーマットが含まれており、
    前記の第１処理モジュールおよび第２処理モジュールはそれぞれ、データを互いに交換するための手段を有しており、
    前記の１つまたは複数の第１処理モジュールと第２処理モジュールとが当該のデータ交換手段を介して接続されており、ここで
    前記のプログラムは、前記の第１処理モジュールに
    ａ） 請求者によって入力された請求情報を受信するステップと、
    ｂ） 前記の請求情報および前記の請求者マスタデータ記憶手段に記憶されている情報を使用して請求書を作成するステップと、
    ｃ） 前記のデータ交換手段を介し、前記の請求書に対応しかつ前記のカスタママスタデータに記憶されている請求書フォーマットを第２処理モジュールに要求するステップと、
    ｄ） 当該の請求書フォーマットを受信するステップと、
    ｅ） 請求者によって使用される請求書フォーマットが、前記の第２処理モジュールにて指定されかつ当該第２処理モジュールから受信した請求書フォーマットでない場合、前記の作成した請求書を前記の第２処理モジュールから受信した請求書フォーマットに変換するステップと、
    ｆ） 当該の変換した請求書を第２処理モジュールに送信するステップとを実行させ、
    さらに前記のプログラムは、第２処理モジュールに
    ｇ） 当該第２処理モジュールに送信された複数の請求書をカスタマ毎にまとめて前記のビジネスオブジェクトデータに記憶するステップを実行させることを特徴とする、
    カスタマに対する請求書を電子的に処理するシステムとしてコンピュータを機能させるプログラム。
20. 前記のコンピュータシステムはさらに、第２モジュール（コンソリデータ）に接続された第３処理モジュール（ＣＳＰ）を有しており、
    該第３処理モジュールは、
    − カスタマによって入力されるデータを受信する手段と、
    − 当該のカスタマに請求書を提示する出力手段とを有しており、
    前記のプログラムは、前記のまとめた請求書を第３処理モジュールがアクセスできるようにするステップを前記の第２処理モジュールに実行させる、
    請求項１９に記載のプログラム。
21. さらに前記のまとめた請求者をカスタマがアクセスできるようにするステップを前記の第２処理モジュールに実行させる、
    請求項１９または２０に記載のプログラム。
22. さらに前記のまとめた求書をカスタマに提示または配送できるようにするステップを前記の第２処理モジュールに実行させる、
    請求項１９から２１までのいずれか１項に記載のプログラム。
23. さらに請求書にデジタル署名するステップを前記の第１処理モジュールに実行させる、
    請求項１９から２２までのいずれか１項に記載のプログラム。
24. さらにカスタマがアクセスできるようにするため、前記のまとめた請求書または当該の請求書の詳細の記憶位置へのリンクを当該のまとめた請求書に設けるステップを第２処理モジュールに実行させる、
    請求項１９から２３までのいずれか１項に記載のプログラム。
25. 前記の作成した請求書および／または変換した請求書を第１処理モジュールによって暗号化し、および／または前記のまとめた請求書を第２処理モジュールによって暗号化するステップを前記の第１処理モジュールまたは第２処理モジュールに実行させる、
    請求項１９から２４までのいずれか１項に記載のプログラム。
26. 前記の作成した請求書および／または変換した請求書を第１処理モジュールによってアーカイブし、および／または前記のまとめた請求書を第２処理モジュールによってアーカイブするステップを前記の第１処理モジュールまたは第２処理モジュールに実行させる、
    請求項１９から２５までのいずれか１項に記載のプログラム。
27. さらに１つまたは複数の別の第２処理モジュールとデータを交換するステップを前記の第２処理モジュールに実行させる、
    請求項１９から２６までのいずれか１項に記載のプログラム。
28. さらに支払いオーダをカスタマから受信するステップを前記の第２処理モジュールに実行させる、
    請求項１９から２７までのいずれか１項記載のプログラム。
29. さらに支払いオーダまたはまとめられた支払いオーダを支払いサービス提供者に転送させるステップを前記の第２処理モジュールに実行させる、
    請求項１９から２８までのいずれか１項に記載のプログラム。
30. さらに前記の請求情報には、請求者および／またはカスタマおよび／または支払いサービス提供者のアドレス情報、および／または支払い情報、および／またはＶＡＴ情報、および／または購入オーダに関連する項目化された請求位置、および／または会計情報が含まれる、
    請求項１９から２９までのいずれか１項に記載のプログラム。
31. さらに前記の請求者マスタデータには、アドレス情報、および／またはデータフォーマット情報、および／または通信アドレスに関する情報、および／または銀行情報および銀行口座情報、および／またはユーザ認証情報、および／またはユーザ許可情報、および／またはアーカイブサービスのための任意選択に関する情報、および／または印刷サービスのための任意選択に関する情報、および／または通知のための任意選択に関する情報が含まれる、
    請求項１９から３０までのいずれか１項に記載のプログラム。
32. さらに前記のカスタママスタデータには、アドレス情報、および／またはデータフォーマット情報、および／または通信アドレス、および／または銀行情報および銀行口座情報、および／またはユーザ認証情報、および／またはユーザ許可、および／またはアーカイブサービスのための任意選択に関する情報、および／または通知のための任意選択に関する情報が含まれる、
    請求項１９から３１までのいずれか１項に記載のプログラム。
33. さらに１つまたは複数の別の第３処理モジュールとデータを交換するためのステップを前記の第２処理モジュールに実行させる、
    請求項１９から３２までのいずれか１項に記載のプログラム。
34. さらに特定のカスタマに対する請求者のＩＤを特定の請求者に対するカスタマのＩＤにマッピングするステップを前記の第１処理モジュールまたは第２処理モジュールに実行させる、
    請求項１９から３３までのいずれか１項に記載のプログラム。
35. 前記の請求者によって使用されたフォーマットがカスタママスタデータで指定されたフォーマットでない場合、中間フォーマットを使用せずに、請求者によって使用されたフォーマットからカスタママスタデータで指定されたフォーマットに請求書を直接変換するステップを第２処理モジュールに実行させる、
    請求項１９から３４までのいずれか１項に記載のプログラム。
36. エンタープライズリソースプランニングソフトウェアに使用される、
    請求項１９から３５までのいずれか１項記載のプログラム。
37. 請求項１９から３６までのいずれか１項に記載のプログラムを記憶するコンピュータ読み出し可能媒体。

Images