(57)【要約】【課題】消し込み処理の効率を高める。【解決手段】所定のネットワークを介して供給され、少なくとも払込みを行った払込元を一意に識別するための営扱コードと、払込まれた金銭の額を示す払込額情報とを含む払込データを受信して処理する払込金処理システムにおいて、コンピュータが、営扱部門対応データベース手段と、請求情報管理データベース手段と、対応部門抽出手段と、会計処理手段と、処理不能表示手段とを備える。これにより、会計処理手段が、前記対応部門抽出手段によって記録された一又は複数の部門識別情報と同じ部門識別情報を有し、かつ請求額の合計額が払込額情報の金額に一致又は近似する１又は複数の請求情報の組の組合せを請求情報管理データベース手段を検索して抽出し、請求情報の組の消し込み処理を実行する。【選択図】  図１
2004302574.tif 000002
【特許請求の範囲】
【請求項１】
所定のネットワークを介して供給され、少なくとも払込みを行った払込元を一意に識別するための営扱コードと、払込まれた金銭の額を示す払込額情報とを含む払込データを受信して処理する払込金処理システムであって、
コンピュータが、
前記営扱コードと、各部門を一意に識別する部門識別情報とを対応付けて登録している営扱部門対応データベース手段と、
前記払込元に対する金銭の請求額を示す請求額情報と、前記部門識別情報とを１つの組として対応付け、１または複数の請求情報の組として登録している請求情報管理データベース手段と、
前記払込データをネットワーク経由で受信したとき、当該払込データに含まれている営扱コードを検索キーとして前記営扱部門対応データベース手段を検索して、対応する一又は複数の前記部門識別情報を抽出し、前記営扱コード及び前記払込額情報に対応付けて記録する対応部門抽出手段と、
前記対応部門抽出手段によって記録された一又は複数の前記部門識別情報と同じ部門識別情報を有し、かつ前記請求額の合計額が前記払込額情報の金額に一致又は近似する１又は複数の前記請求情報の組の組合せを前記請求情報管理データベース手段を検索して抽出し、前記請求情報の組の消し込み処理を実行する会計処理手段と、
前記請求情報の組の組合せのうち、前記会計処理手段による消し込み処理で消し込めなかった処理不能の組について記録し、表示する処理不能表示手段とを備えたことを特徴とする払込金処理システム。
【請求項２】
請求項１の払込金処理システムにおいて、
前記処理不能表示手段は、所定の部門から前記処理不能の組についての表示要求を受付ける手段と、少なくとも表示要求を行った前記所定の部門の前記部門識別情報が含まれる前記処理不能の組を特定し表示する手段を有し、
前記払込金処理システムは、
前記処理不能表示手段によって表示された内容についての修正を許容する修正手段をさらに有し、
前記修正手段は、少なくとも前記所定の部門からの前記部門識別情報及び前記請求額情報の少なくともいずれかについての修正を受け付け、
前記請求情報管理データベース手段は、前記修正手段が受けた修正に基づいて、前記部門識別情報及び前記請求額情報の少なくともいずれかについて更新処理をし、
前記会計処理手段は、更新処理を行った後の前記請求情報管理データベース手段を検索して、前記請求情報の組の消し込み処理を実行する、
ことを特徴とする払込金処理システム。
【請求項３】
請求項１の払込金処理システムにおいて、
前記処理不能表示手段は、前記会計処理手段において１又は複数の前記請求情報の組の組合せを抽出することのできなかった前記営扱コードを含む前記払込データを特定し、
前記払込金処理システムは、
表示された前記払込データに含まれる前記営扱コードの修正を許容する営扱コード修正手段をさらに有し、
前記対応部門抽出手段は、前記営扱コード修正手段によって修正された前記営扱コードを検索キーとして対応する一又は複数の前記部門識別情報を改めて抽出し、
前記会計処理手段は、改めて抽出された前記一又は複数の前記部門識別情報を用いて前記請求情報の組の消し込み処理を実行する、
ことを特徴とする払込金処理システム。
【請求項４】
請求項１の払込金処理システムにおいて、
前記処理不能の組について、前記部門識別情報に応じた部門に宛てて、第１の消し込み不能通知を送信することにより部門ごとの消し込みを促す処理不能通知手段を備え、
前記処理不能通知手段は、前記第１の消し込み不能通知により通知した組について消し込みが行えたか否かを検査し、消し込みが行えなかった組について複数の部門に宛てて、第２の消し込み不能通知を送信することを特徴とする払込金処理システム。
【請求項５】
請求項１乃至４の払込金処理システムにおいて、
前記会計処理手段は、
抽出した前記請求情報の組の組み合わせの中から、すべて又は一部の組を選択し、選択した組について前記請求額情報が示す請求額の値の合計値を算出する合計値算出部と、
この合計値と該当営扱コードに対応する払込データ中の払込額情報が示す値の大小関係を検査する比較判定手段と、
を備えたことを特徴とする払込金処理システム。
【請求項６】
請求項５の払込金処理システムにおいて、
請求状況管理データベース手段は、
あらかじめ設定された前記請求情報の組に優先度を示す情報を予め登録しておく優先度設定部を備え、
前記合計値算出手段は、
前記検査の結果、前記合計値が払込額情報が示す値以上となるように、前記優先度にしたがって組の選択を行うことを特徴とする払込金処理システム。
【請求項７】
請求項５又は６の払込金処理システムにおいて、
前記合計値算出手段は、
前記検査の結果、前記合計値が払込額情報が示す値以上となり、かつ、消し込み処理を施す組の数が最大となるように組の選択を行い、この選択にしたがって前記消し込み処理を実行させる選択組数優先適応制御部を備えたことを特徴とする払込金処理システム。
【請求項８】
請求項５乃至７の払込金処理システムにおいて、
前記合計値算出手段は、
前記検査の結果、前記合計値が払込額情報が示す値以上となり、かつ前記合計値と払込額情報が示す値の差が最小となるように組の選択を行い、この選択にしたがって前記消し込み処理を実行させる差額優先適応制御部を備えたことを特徴とする払込金処理システム。
【請求項９】
請求項１乃至８の払込金処理システムにおいて、
前記ネットワークを介して当該払込金処理システムに対向している金融機関システムが、単一の払込受口座に複数の関連口座を関連づけ、所定の関連口座識別情報を用いて関連口座を一意に識別する関連口座サービスを提供している場合、
前記払込元には、自身に関連づけられた関連口座に、前記金銭の払込みを行わせ、その関連口座の関連口座識別情報に、前記営扱コード又は取引の内容に関する情報を持たせることを特徴とする払込金処理システム。
【請求項１０】
所定のネットワークを介して供給され、少なくとも払込みを行った払込元を一意に識別するための営扱コードと、払込まれた金銭の額を示す払込額情報とを含む払込データを受信して処理する払込金処理方法であって、
コンピュータが、
前記営扱コードと、各部門を一意に識別する部門識別情報とを対応付けて営扱部門対応データベース手段に登録し、
前記払込元に対する金銭の請求額を示す請求額情報と、前記部門識別情報とを１つの組として対応付けた上で、１または複数の請求情報の組を請求情報管理データベース手段に登録し、
前記払込データをネットワーク経由で受信したとき、当該払込データに含まれている営扱コードを検索キーとして前記営扱部門対応データベース手段を検索して、対応する一又は複数の前記部門識別情報を抽出し、前記営扱コード及び前記払込額情報に対応付けて対応部門抽出手段に記録し、
会計処理手段に、前記対応部門抽出手段によって記録された一又は複数の前記部門識別情報と同じ部門識別情報を有し、かつ前記請求額の合計額が前記払込額情報の金額に一致又は近似する１又は複数の前記請求情報の組の組合せを前記請求情報管理データベース手段を検索して抽出させて、前記請求情報の組の消し込み処理を実行させ、
前記請求情報の組の組合せのうち、前記会計処理手段による消し込み処理で消し込めなかった処理不能の組について、処理不能表示手段に記録させ、表示させることを特徴とする払込金処理方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は払込金処理システム及び方法に関し、例えば、顧客が銀行などの所定の口座へ振込みなどにより、払い込んだ金銭を当該顧客に対して金銭の請求を行っていた社内の複数の部門に自動的に振り替える場合などに適用して好適なものである。
【０００２】
【従来の技術】
従来、例えば、企業間で金銭の請求や支払いを行う場合、請求側の企業では、請求書の作成および発送、売掛伝票の作成などの作業が行われていた。
【０００３】
一方、前記請求書を受け取る支払い側の企業では、当該請求書の内容の検査、当該請求書の内容に応じた金銭の銀行への振込みなどの作業が行われていた。そして、請求企業側で振り込みなどによって払い込まれた金額と請求した金額との照合作業を行っていた。
【０００４】
この一連の作業は煩雑で手数を要するものであるため、特に照合作業の効率化をはかることを目指して、下記の特許文献１〜３の技術が考案されている。
【０００５】
特許文献１は、支払人と関連付けられた複数の仮想的な振込専用の口座（振込専用口座）を利用するものである。これら複数の振込専用口座を配下におく本来の口座（特定口座）は１つで、各振込専用口座に振り込まれた金銭は最終的にこの特定口座に集中される。振込専用口座の口座番号が、支払人の特定などに活用できる点で、前記一連の作業のうち振込時の作業負担の軽減をはかること等が可能となる。そのため、請求側では、振込専用口座の口座番号などを活用して支払人を特定することが可能であり、振込みの確認作業の効率化などをはかることができる。
【０００６】
また、特許文献２は、ある請求側企業からある支払側企業への請求が複数種類におよぶ場合、複数種類の請求にかかる合計金額が正確に支払われたか否かを自動的に検査することで、一連の作業の効率を改善するものである。
【０００７】
さらに、特許文献３は、支払側が支払った振込金額と請求側が請求している請求金額が一致しない場合の付き合わせ処理を効率化するものである。
【０００８】
【特許文献１】
特許第３０２９４２１号公報
【０００９】
【特許文献２】
特許第３３３３１２６号公報
【００１０】
【特許文献３】
特開２０００−２６８１１９号公報
【００１１】
【発明が解決しようとする課題】
ところで、実際にある請求側企業から支払側の個人または企業に対して金銭の支払いを請求する場合、経理部などの担当者が一括して管理しているケースが多いが、その請求の実質的な母体（つまり、請求の原因となった取引などを担当する主体）は、請求側企業内の各部門（部、課など）であることが多い。したがって、支払人から払い込まれた金額など請求に関する事情については請求側企業の各部門がもっとも詳しい情報を持っている。そのため、請求を行った金額と払い込まれた金額を照合して請求データの消し込みなどの作業をする際に、照合ができなかった場合の確認作業は各部門が経理部などの担当者と協働して行うのが効率的である。また、請求を行う企業にとっては各部門からの請求額の合計値が、当該請求側企業全体としての、前記支払側個人など（支払側企業も含む）に対する請求額となる。この合計値にそのまま一致する金銭が払い込まれれば問題なく消し込み処理を行うことができるが、実際には、消し込みのできない場合がある。
【００１２】
前記特許文献１乃至３には、取引などを担当した各部門と経理部などの一括管理部門との協働による照合処理に関する記述は存在しない。
【００１３】
また、前記特許文献３には、振込金額と複数の請求書の合計請求額とが一致しない場合に、請求書単位で突き合わせを行い、それでも一致しない場合は請求書が所定枚数以内の時は複数の請求書を組み合わせてその合計請求額と突き合わせる処理が開示されている。また、請求書が所定枚数より多い時は債権データを月単位にまとめて、そのまとまり毎に同じように請求書単位や、複数の請求書を組合せた合計額との突き合わせを行う処理が開示されている。しかし、複数の請求書の組合せを具体的にどのように実施するかが示されておらず、結局、複数存在する請求書をすべての組合せで合計して、それぞれに突き合わせ処理を行わざるを得ず、突き合わせ処理のステップ数が膨大になってしまう。
【００１４】
本発明はこのような事情に鑑みて、各部門で発生した請求事案に対する払い込みについて、請求額と払込金額との照合を効率的に行うための手段を提供する。
【００１５】
【課題を解決するための手段】
かかる課題を解決するために、本発明における払込金処理システムでは、所定のネットワークを介して供給され、少なくとも払込みを行った払込元を一意に識別するための営扱コード（例えば、図４のＦ１）と、払込まれた金銭の額を示す払込額情報とを含む払込データ（例えば、図４のＲＤ３）をコンピュータが受信して処理する払込金処理システムであって、コンピュータが営扱コードと、各部門を一意に識別する部門識別情報とを対応付けて登録している営扱部門対応データベース手段と、各部門からの要求に基づいた前記払込元に対する金銭の請求額を示す請求額情報と、前記部門識別情報とを１つの組（組とは、図６に示す請求コードＬ１で指定される１つの行のこと）として対応付け、１または複数の請求情報の組として登録している請求情報管理データベース手段と、前記払込データをネットワーク経由で受信したとき、当該払込データに含まれている営扱コードを検索キーとして前記営扱部門対応データベース手段を検索して、対応する一又は複数の前記部門識別情報を抽出し、前記営扱コード及び前記払込額情報とに対応付けて記録する対応部門抽出手段と、前記対応部門抽出手段によって記録された一又は複数の前記部門識別情報と同じ部門識別情報を有し、かつ前記請求額の合計額が前記払込額情報の金額に一致又は近似する１又は複数の前記請求情報の組の組合せを前記請求情報管理データベース手段を検索して抽出し、前記請求情報の組の消し込み処理を実行する会計処理手段と、前記請求情報の組の組合せのうち、前記会計処理手段による消し込み処理で消し込めなかった処理不能の組について記録し、表示する処理不能表示手段とを備えたことを特徴とする。
【００１６】
このようなシステムとすることで、払込元から払い込まれた金額について、営扱コードに対応する各部門毎に分けて消し込み作業を行うことができ、消し込み作業の能率を高めることができる。
【００１７】
なお、ここで営扱コードとは請求された金額の払込元を一意に識別する情報である。払込元とは、例えば保険契約の保険料集金を行い保険会社に払い込みをする保険料集金者や、個人や会社が商品やサービスを購入した時にその代金を支払う者をいう。払込元には、それぞれを一意に識別する営扱コードがあらかじめ付与される。
【００１８】
また部門識別情報とは、払込元と対応関係を有する部門を一意に識別する情報であり、部門とは、例えば保険料集金者を所管する保険会社の営業課所や、商品やサービスを提供した企業の中でその商品やサービスの販売先顧客を担当する営業部門などを意味する。こうした部門は、払込元からの払い込みの原因となる事情に関する情報にもっとも精通しており、コンピュータによって払込金の消し込みができない場合でも、容易にその原因を解明することができる場合が多い。
【００１９】
また、本発明における払込金処理システムにおいて、処理不能表示手段が、所定の部門から前記処理不能の組についての表示要求を受付ける手段と、表示要求を行った前記所定の部門の前記部門識別情報が含まれる前記処理不能の組を特定し表示する手段を有し、さらに払込金処理システムは、処理不能表示手段によって表示された内容についての修正を許容する修正手段をさらに有し、修正手段は、少なくとも前記所定の部門からの前記部門識別情報及び前記請求額情報の少なくともいずれかについての修正を受け付け、前記請求情報管理データベース手段は、前記修正手段が受けた修正に基づいて、前記部門識別情報及び前記請求額情報の少なくともいずれかについて更新処理をし、前記会計処理手段は、更新処理を行った後の前記請求情報管理データベース手段を検索して、前記請求情報の組の消し込み処理を実行するようにしてもよい。
【００２０】
このような処理を行うことで、請求情報（請求書を発行するしないは問わず、入金が予定される取引などに関する情報をいう。）のうち、例えば請求金額（あるいは入金予定金額でもよい、以下同じである。）などが間違って記録されていた場合に、各担当部門からの訂正を行い、訂正された内容に基づいて消し込み処理を行うことができる。
【００２１】
さらに、本発明における払込金処理システムにおいて、処理不能表示手段が、前記会計処理手段において１又は複数の前記請求情報の組の組合せを抽出することのできなかった前記営扱コードを含む前記払込データを特定し、前記払込金処理システムは、表示された前記払込データに含まれる前記営扱コードの修正を許容する営扱コード修正手段をさらに有し、前記対応部門抽出手段は、前記営扱コード修正手段によって修正された前記営扱コードを検索キーとして対応する一又は複数の前記部門識別情報を改めて抽出し、会計処理手段は、改めて抽出された前記一又は複数の前記部門識別情報を用いて前記請求情報の組の消し込み処理を実行するようにしてもよい。
【００２２】
そうすることで、振込金データに含まれる営扱コードの入力間違いによって消し込み不能が生じた場合にも、スムーズに対応することができる。
【００２３】
さらに本発明における払込金処理システムにおいて、処理不能の組について、前記部門識別情報に応じた部門に宛てて、第１の消し込み不能通知を送信することにより部門ごとの消し込みを促す処理不能通知手段を備え、前記処理不能通知手段は、前記第１の消し込み不能通知により通知した組について消し込みが行えたか否かを検査し、消し込みが行えなかった組について複数の部門に宛てて、第２の消し込み不能通知を送信することとしてもよい。
【００２４】
このようなシステムとすることで、例えば営扱コードに対応する部門に対して処理不能の通知をしても、消し込みできない原因が把握できない払込み事案があった場合に、その事案だけを複数の部門に送信して消し込みできなかった原因を究明することができる。
【００２５】
さらに本発明における払込金処理システムにおいて、会計処理手段は、抽出した前記請求情報の組のすべて又は一部の組を選択し、選択した組について前記請求額情報が示す請求額の値の合計値を算出する合計値算出部と、この合計値と該当営扱コードに対応する払込データ中の払込額情報が示す値の大小関係を検査する比較判定部とを備えてもよい。
【００２６】
そうすることで、該当特定の複数の組の間で、請求金額を組み合わせて合計して、振込みされた金額との比較をすることができ、どの組み合わせが払込データに合致するかを確認することができる。また、金融機関などへの振り込み手数料を控除した場合、複数の請求事案の合計請求金額が振込金額より大きくなることはあっても、逆に振込金額が請求金額より大きい場合は、一義的には照合できないものと考えられ、このような判定をすることが可能となる。
【００２７】
さらに本発明による払込金処理システムにおいて、請求情報管理データベース手段は、あらかじめ設定された前記請求情報の組に優先度を示す情報を予め登録しておく優先度設定部を備え、前記合計値算出手段は、前記検査の結果、前記合計値が払込額情報が示す値以上となるように、前記優先度にしたがって組の選択を行うことを特徴とすることができる。
【００２８】
それによって、例えば、振込みされることの確かな請求情報ついては優先度を高くしておいて、それら優先度の高い請求情報から順次振込データとの消し込みを実施していくことで、消し込み処理を効率的に行うことができる。
【００２９】
さらに本発明による込金処理システムにおいて、前記合計値算出手段は、記検査の結果、前記合計値が払込額情報が示す値以上となり、かつ、消し込み処理を施す組の数が最大となるように組の選択を行い、この選択にしたがって前記消し込み処理を実行させる選択組数優先適応制御部を備えてもよい。
【００３０】
さらに本発明による込金処理システムにおいて、前記合計値算出手段は、前記検査の結果、前記合計値が払込額情報が示す値以上となり、かつ前記合計値と払込額情報が示す値の差が最小となるように組の選択を行い、この選択にしたがって前記消し込み処理を実行させてもよい。
【００３１】
さらに本発明による込金処理システムにおいて、前記ネットワークを介して当該払込金処理システムに対向している金融機関システムが、単一の払込受口座に複数の関連口座を関連づけ、所定の関連口座識別情報を用いて関連口座を一意に識別する関連口座サービスを提供している場合、前記払込元には、自身に関連づけられた関連口座に、前記金銭の払込みを行わせ、その関連口座の関連口座識別情報に、前記営扱コード又は取引の内容に関する情報を持たせるようにしてもよい。
【００３２】
さらにまた、本発明における払込金処理方法では、所定のネットワークを介して供給され、少なくとも払込みを行った払込元を一意に識別するための営扱コードと、払込まれた金銭の額を示す払込額情報とを含む払込データを受信して処理する払込金処理方法であって、コンピュータが、前記営扱コードと、各部門を一意に識別する部門識別情報とを対応付けて営扱部門対応データベース手段に登録し、前記払込元に対する金銭の請求額を示す請求額情報と、前記部門識別情報とを１つの組として対応付けた上で、１または複数の請求情報の組を請求情報管理データベース手段に登録し、前記払込データをネットワーク経由で受信したとき、当該払込データに含まれている営扱コードを検索キーとして前記営扱部門対応データベース手段を検索して、対応する一又は複数の前記部門識別情報を抽出し、前記営扱コード及び前記払込額情報に対応付けて対応部門抽出手段に記録し、会計処理手段に、前記対応部門抽出手段によって記録された一又は複数の前記部門識別情報と同じ部門識別情報を有し、かつ前記請求額の合計額が前記払込額情報の金額に一致又は近似する１又は複数の前記請求情報の組の組合せを前記請求情報管理データベース手段を検索して抽出させて、前記請求情報の組の消し込み処理を実行させ、前記請求情報の組の組合せのうち、前記会計処理手段による消し込み処理で消し込めなかった処理不能の組について、処理不能表示手段に記録させ、表示させることを特徴とする。
【００３３】
このような方法によっても、払込元から払い込まれた金額について、営扱コードに対応する各部門毎に分けて消し込み作業を行うことができ、消し込み作業の能率を高めることができる。
【００３４】
【発明の実施の形態】
（Ａ）実施形態
以下、本発明にかかる払込金処理システム及び方法の実施形態について説明する。
【００３５】
（Ａ−１）実施形態の構成
本実施形態にかかる通信システム１０の全体構成例を図１に示す。
【００３６】
図１において、当該通信システム１０は、外部ネットワーク１１と、支払側システム１２と、銀行システム１３と、請求側システム１４とを備えている。
【００３７】
このうち外部ネットワーク１１は、インターネットなどであってもかまわないが、専用線伝送網などの閉じたネットワークであってもよい。本実施形態の構成上、当該外部ネットワーク１１を介した通信は、銀行システム１３経由で行われる。
【００３８】
すなわち、支払側システム１２と銀行システム１３が通信し、当該通信に応じて銀行システム１３と請求側システム１４が通信する。したがって本実施形態では、基本的に支払側システム１２と請求側システム１４が直接、通信することはない。
【００３９】
支払側システム１２は、支払側ユーザ（個人ユーザＵ１または企業ユーザＥ１）によって利用され、請求側システム１４は企業Ｅ２によって利用され、銀行システム１３は銀行Ｋ１が運営するものとする。企業Ｅ２は、金銭を請求する側であり、支払側ユーザＵ１など（支払側ユーザには企業ユーザＥ１も含むが、以下では支払側ユーザが個人ユーザの場合を例に説明する。）は、その請求に応じて金銭を支払う側である。
【００４０】
なお、商品やサービスの購入代金に対する払い込みの場合は、企業Ｅ２から支払側ユーザＵ１に請求書などの書類やデータが送られることになるが、保険契約の保険料集金者などが個人ユーザＵ１となる場合は自分が取り扱った保険契約と保険料に関する情報を自分で保険会社に連絡して、その情報に基づいて保険会社で請求データ（つまり、入金予定データ）が作成される。保険料集金者などは、自ら集金した金額を自主的に保険会社の口座に払い込む。
【００４１】
通常、企業Ｅ２から個人ユーザＵ１などへの請求は、企業Ｅ２の名の下に、一括して行われ得るが、実際には、個人ユーザＵ１を担当する企業Ｅ２内の部や課Ｂ１〜Ｂ５などの個々の部門がその請求の実体的な母体となるのが普通である。例えば、企業Ｅ２が保険会社で、各地域のエリア毎に保険料集金者などを担当する部門（課所など）が設けられている場合、一人の支払側ユーザＵ１はある特定の１つの部門によって担当される。この場合、個人の支払側ユーザＵ１と企業Ｅ２は１対１に対応することになる。また、例えば保険会社が自動車保険、船舶保険、貨物保険などの各種保険を取り扱っており、各保険ごとに別な担当課が設けられている場合には、一人の個人ユーザＵ１に対して複数の部門が担当となり、個人ユーザＵ１に対する保険料の請求も、自動車保険の保険料は自動車保険課Ｂ１から、船舶保険の保険料は船舶課Ｂ２から、そして貨物保険の保険料は貨物課Ｂ３から請求するとうように、複数の部門が担当となることがある。
【００４２】
請求情報の内容（請求金額など）を請求側企業Ｅ２やその中の各部門から支払側ユーザＵ１に伝える方法としては様々なものを利用することができる。例えば、郵便などを利用してもよく、電子メール（外部ネットワーク１１以外のネットワークを使用）などを利用してもよい。また、先に説明したように請求書などが送付されることなく、個人ユーザＵ１が自発的に払い込む場合もある。さらに、定期的に支払いが行われる保険料や賃貸マンションの賃貸料などの場合も、必ずしも個々に請求を伝える必要はない。
【００４３】
また、請求側システム１４は、パーソナルコンピュータなどを含むコンピュータネットワーク（図２参照）で、請求や、個々の請求の消し込みなどの処理を効率化する機能を有する。本実施形態の構成上、請求側システム１４は必須である。
【００４４】
これに対し支払側システム１２は、銀行システム１３内に設けられた所定の口座に対して金銭の払込を行う機能を有するだけであるため、省略可能である。支払側システム１２を省略した場合、支払側個人ユーザＵ１などは、銀行Ｋ１の店舗などに設置されたＡＴＭ（現金自動預け払い機）端末などを利用して支払いを行うことができる。
【００４５】
支払側システム１２を用いる場合、支払側システム１２から供給される振込データＲＤ１が銀行システム１３に供給され、銀行システム１３内で当該振込データＲＤ１に対応する処理が行われると共に、その処理の結果として、銀行システム１４から当該振込データＲＤ１に対応する振込データＲＤ２が請求側システム１４に供給される。振込データＲＤ２は、銀行Ｋ１が企業Ｅ２に提供する後述の報告サービスによって供給されるものである。
【００４６】
なお、振込データＲＤ１やＲＤ２には、必要に応じて、暗号化を施しセキュリティ性を高めるようにしてもよい。
【００４７】
振込データＲＤ１とＲＤ２は基本的に同じ内容のデータであってよい。当該振込データＲＤ２（またはＲＤ１）は、例えば、図４に示すように、営扱コードＦ１、振込依頼人名Ｆ２、金額Ｆ３，振込日Ｆ４などの各情報を含んでいる。
【００４８】
営扱コードＦ１とは、払込元（支払側ユーザ）を識別するための識別子である。営扱コードに持たせる機能については様々なものがあり得るが、少なくとも、請求側企業Ｅ２内において個々の支払側のユーザ（例えば、個人ユーザＵ１）を識別する機能（支払側ユーザ識別機能）を有する。必要に応じて、後述する請求側を識別する請求側識別機能（部門識別機能）も、当該営扱コードに持たせることが可能である。
【００４９】
当該営扱コードとしては、例えば、１０桁程度の数字の列（数値のほか、記号、その他の文字列、さらにそれらの組み合わせでも可）を用いることができる。営扱コードの支払側ユーザ識別機能だけに着目する場合、支払側ユーザの住所、氏名、電話番号などの情報を当該営扱コードとして利用することも可能である。また振込依頼人名（支払側ユーザの氏名）の文字列の前（または後）に一連の数値や記号を付加することで、振込依頼人名の一部として取得することができる。
【００５０】
営扱コードＦ１の値は、例えば、請求の内容を、前記郵便や電子メールなどで伝える際、あらかじめ支払側のユーザに知らせておくことができる。
【００５１】
営扱コードＦ１は、支払時に支払側のユーザに入力させるようにしてもよいが、前記特許文献１の技術を利用する場合などには、営扱コードの入力に代えて、払込先口座の識別情報に営扱コードを含ませることができ、支払側ユーザの操作負担を軽減することができる。
【００５２】
すなわち、個々の支払側ユーザごとに異なる前記振込専用口座を対応付け、支払側ユーザと各振込専用口座の対応関係を請求側システム１４で管理しておけば、振り込まれた振込専用口座を特定するだけで支払側ユーザを特定することも可能となる。
【００５３】
この場合、前記特許文献１における振込専用口座に払込（以下、振込ともいう）が行われると、その振込専用口座の口座番号（このケースでは、この口座番号が営扱コードＦ１としての機能も併せ持つ）が銀行システム１３から請求側システム１４に通知されることになる。このとき、振り込まれた金銭は、振込専用口座に関連付けられた、企業Ｅ２が銀行Ｋ１に開設した特定の口座に集中されることになる。
【００５４】
上述したように、営扱コードＦ１は支払側ユーザ識別機能を有する識別子であるが、実際には、支払側ユーザさえ特定できれば、その振込がどの請求に対応する振込であるか（振込の原因となった取引などを特定する内容など（以下、払込原因又は振り込み原因という）をいう）も特定できることが多い。ただしもし必要ならば、支払側ユーザの振込原因を明示させるため、営扱コードのほかに、振込原因を識別するための情報も入力させるようにしてもよい。
【００５５】
前記振込依頼人名Ｆ２は振込依頼人（すなわち、支払側ユーザ）の氏名、名称などであり、支払側ユーザが振込（支払）を行う際に入力する。前記営扱コードＦ１によって支払側ユーザを一意に特定できるため、当該振込依頼人名Ｆ２の入力を省略できるシステム構成とすることも可能であるが、例えば、後述する手動消し込みなどの際、営扱コードＦ１の入力ミスなどを検出できるようにするためには、当該振込依頼人名Ｆ２の入力も行わせることが好ましい。
【００５６】
金額Ｆ３は、支払側ユーザが所定の口座（例えば、前記振込専用口座）に振り込んだ金銭の額を示す情報である。この値は、銀行システム１３内の機能に応じて、例えば振り込み手数料を控除するなどして生成される。
【００５７】
振込日Ｆ４は振込が行われた日付を示す情報である。
【００５８】
このほかにも、必要ならば各種の情報が、当該振込データＲＤ２（またはＲＤ１）のなかに含まれ得る。例えば、代表部店コード、銀行コード、銀行支店コード、口座番号、勘定科目などが含まれていてもよい。
【００５９】
なお、支払側システム１２の替わりに前記ＡＴＭ端末などを用いる場合には、支払側ユーザがＡＴＭ端末に対して行う操作の内容に応じて、当該振込データＲＤ１の内容が当該ＡＴＭ端末などから銀行システム１３に供給されることになる。
【００６０】
振込データＲＤ２に含まれる情報は、銀行側で規定された所定のフォーマットによって決まる。
【００６１】
銀行Ｋ１が請求側企業Ｅ２に対して提供する前記報告サービスは、基本的に前記振込データＲＤ２を企業Ｅ２の請求側システム１４に供給することだけをそのサービス内容とする。
【００６２】
前記請求側システム１４の内部構成例を図２を用いて説明する。
【００６３】
（Ａ−１−１）請求側システムの内部構成例
図２において、当該請求側システム１４は、電子掲示板システム９と、内部ネットワーク２０と、通信処理装置２１と、中継処理サーバ（中間処理サーバ）２２と、データベースサーバ２３と、営扱部門対応データベース２４、請求情報管理データベース２５、表示装置２９、さらに各部門毎に設けられたクライアント端末２７及び２８を有し、これらが内部ネットワーク２０を介して接続されている。
【００６４】
このうち通信処理装置２１は、当該内部ネットワーク２０と前記外部ネットワーク１１とを接続するためのルータなどのネットワーク機器である。内部ネットワーク２０は例えばＴＣＰ／ＩＰネットワークであってよい。
【００６５】
中継処理サーバ２２は、銀行システム１３から通知のあった振込に関する情報などに基づいて、適宜請求情報管理データベース２５に記録された請求情報（入金予定データ）の消し込み処理や、電子掲示板システム９が提供する掲示板の内容に関する指示を出すなどの処理を実行する。必要ならば、図４に示す振込データＲＤ２中の各情報（Ｆ１，Ｆ２など）の並べ換え処理も、この中継処理サーバ２２で行うことができる。銀行ごと（その１つがＫ１）に振込データＲＤ２中の情報の順番が異なることが多いが、請求側システム１４中で有効な順番が１つである場合には、この並べ換え処理により、各銀行から到来する振込データＲＤ２中の情報の順番を請求側システム１４中で有効な順番に統一するように並べ替えることができる。
【００６６】
電子掲示板システム９は、１対多のメッセージ交換システムである。当該メッセージを閲覧したユーザ（Ｍ２，Ｍ１など）も、当該メッセージに対する自身のメッセージを掲示板に記述することで、メッセージ交換を進め、共同作業を行うことができる。このような電子掲示板の機能をコンピュータネットワーク上で実現する方法には様々なものがある。例えば、ＮＮＴＰプロトコルを用いるネットニュースなどを用いて電子掲示板を構成することもできるが、内部ネットワーク２０がＴＣＰ／ＩＰネットワークである場合にはＷｅｂサーバの機構を利用するのが簡便である。
【００６７】
Ｗｅｂサーバの機構を利用した電子掲示板システムでは、基本的に、ユーザがメッセージを記述する場合には、フォームを利用する。フォームはユーザが記述した情報をＷｅｂサーバ側で収集するための部品（フィールド）の集合体であるから、フィールドから収集した情報をもとに、ＣＧＩプログラムなどを利用して新たにＷｅｂページ（掲示板）を生成すれば、当該Ｗｅｂページを閲覧することで、多数のユーザが当該ユーザのメッセージの内容を知ることができる。
【００６８】
また、当該ＣＧＩプログラムにアクセス制御機能（例えば、ユーザ認証機能）を持たせれば、肯定的な認証結果が得られたユーザだけがそのメッセージを読むことができるようになるから、電子掲示板を１対１の通信手段として利用することもでき、１対多（この場合は、１対特定多数）の通信手段として利用することもできる。
【００６９】
本実施形態では、最初に電子掲示板システム９が提供する掲示板にメッセージを記述して請求情報や振込データの確認依頼をし、手動消し込みの依頼を行うのは、中継処理サーバ２２である。
【００７０】
各部門の社員である消し込みの担当者（例えば、Ｍ１）は、自身が所属する部門にだけアクセスを許可するアクセス制御機能が付加された電子掲示板の場合、掲示板にアクセスすることで自身の部門に関連するメッセージＭＳ１のみを確認することができる。
【００７１】
前記データベースサーバ２３は、営扱部門対応データベース２４や請求情報管理データベース２５に記録された各種のデータを検索することで読み出したり、中継処理サーバ２２での処理のためにデータを提供する等、データの管理処理を実施する。
【００７２】
一般的にデータベースには、その論理データモデル（ＤＢＭＳのタイプ）に応じて網型、階層型などのタイプがあり、本発明は網型や階層型のデータベースにも適用可能であるが、本実施形態で使用するのは、関係型データベースであるものとする。したがって、当該営扱部門対応データベース２４は、１または複数の関係テーブルから構成される関係データベースである。
【００７３】
営扱部門対応データベース２４は、例えば、図５（Ａ）または（Ｂ）に示すような対応テーブルＴＢ１を有している。図５（Ａ）において、当該営扱部門対応データベース２４上の対応テーブルＴＢ１は、すくなくとも営扱コードと、支払者名（支払側ユーザ名）と、各営扱コードに対応する部門識別情報を備えている。営扱コードは、部門識別情報と対応づけられ、営扱コードが決まればそれに対応する部門識別情報が特定される。  一つの営扱コードの値に対応する部門識別情報の値は、一つでもよく、複数でもよい。図５（Ａ）の例では、一つの営扱コードの値（例えば、ＣＤ１）に対し一つの部門識別情報の値（例えば、ＤＤ１）が対応し１対１の対応関係にあるが、図５（Ｂ）の例では、一つの営扱コードの値（例えば、ＣＤ１）に対し複数の部門識別情報の値（例えば、ＤＤ１とＤＤ２）が対応し１対多の対応関係にある。もちろん同じテーブルの中に１対１の対応関係と１対多の対応関係が混在していてもよいことは当然である。
【００７４】
対応関係が１対１となるか１対多となるかは、営扱コードの機能と具体的な請求の内容に応じて決まる。営扱コードが上述した支払側ユーザ識別機能のみを有する場合、同一の支払側ユーザに対して複数の部門から請求が行われれば１対多の対応関係になる。営扱コードが支払側ユーザ識別機能とともに部門識別機能を有する場合には、１つの部門から一人の支払側ユーザに対し、同時に複数の請求が行われないのであれば１対１となり、行われるのであれば１対多となる。
【００７５】
部門識別機能を有する場合、営扱コード自体の中に対応する部門識別情報を含ませることもできるので、図５（Ａ）又は図５（Ｂ）に示す営扱部門対応データベース２４を省略することも可能である。例えば、図５（Ｂ）において支払側ユーザ名「日動太郎」に対して、「ＤＤ１ＤＤ２ＣＤ１」といった営扱コードを用いることで、この営扱コードが部門識別情報「ＤＤ１」と「ＤＤ２」に対応付けられていることが、営扱コード自体から確認できる。なお以下では、営扱コードは支払側ユーザ識別機能だけしか持たず、部門識別機能は持たないものと仮定している。
【００７６】
表示装置２９は、中継処理サーバ２２を中心とする本社などにおける振込金の一括管理処理を実施する統括部門での処理を行う際に、統括部門の担当者が内容を確認するために表示を行うための通信装置で、本実施形態において重要な役割を有する。ただし装置自体の機能としては、サーバである電子掲示板システム９に対し、クライアント端末２７などと同様なクライアント端末の１つである。
【００７７】
電子掲示板システム９が各クライアント端末（表示装置２９も含む）に提供する掲示板の内容を、この表示装置２９を操作する統括部門の担当者Ｍ０が変更したり、追加したりすると、その他のクライアント端末（例えば、２８など）が当該電子掲示板システム９にアクセスすることで、変更後、追加後の掲示板を閲覧し、当該担当者Ｍ０とクライアント端末（例えば、２８）を操作する社員（例えば、Ｍ２）がメッセージ交換を行うことができる。
【００７８】
社員Ｍ１，Ｍ２は支払側ユーザを担当する各部門に属するから、このようなメッセージ交換により、支払側ユーザを担当する各部門が統括部門と協働して振込金の照合処理を実施することが可能となる。
【００７９】
なお、通信処理装置２１、中継処理サーバ２２、データベースサーバ２３、営扱部門対応データベース２４、請求情報管理データベース２５、及び表示装置２９は、それぞれ別個に設置される代わりに、一つのサーバまたはホストコンピュータ内に統合されてもよい。
【００８０】
上述した中継処理サーバ２２は、銀行処理システム１３から振込金データＲＤ２（図４参照。営扱コードを含む振込人、振込金額、振込日など振込に関する各種データ）を通信処理装置２１を介して受け取った時点で、図６に示す請求情報管理データベース２５に記録されている請求（入金予定）内容テーブルＴＢ２の各請求情報をデータベースサーバ２３を介して取得し、それらについて振込があったかどうかを確認し、振込のあった請求情報については消し込み処理を実施する。
【００８１】
図６は、企業Ｅ２内の各部門から登録された、各請求データ（請求情報）の内容を示したものである。各請求項目を一意に特定するための請求コード（Ｌ１〜）、当該請求の原因母体となった部門に関する部門識別情報、請求（入金予定）金額、入金予定日、支払側ユーザ名、そして優先度が、それぞれの請求情報について記録される。なお、ここで営扱コードは必須の項目ではないが、営扱コードを請求情報の一部として、例えば請求情報管理データベース２５内の請求（入金予定）内容テーブルＴＢ２に記録するようにすれば営扱部門対応データベース２４は不要となる。以下では、請求（入金予定）内容テーブルＴＢ２に、営扱コードが記録されておらず、営扱部門対応データベース２４を用いて関連する部門識別情報が抽出されるものとして説明する。
【００８２】
部門識別情報とは、企業Ｅ２内の課（部門として、以下では主に課を例として説明する。）などの実体的な請求の母体を一意に指定するためのものである。図５（Ａ）、図５（Ｂ）、及び図６では、自動車課や、船舶課などの課の名称とそれに該当する記号を括弧内に組み合わせて記述しているが、課などの名称や、あるいは数値、記号その他の文字列、さらにそれらの組み合わせなどを用いて記述してもよく、数値だけ、記号だけを用いて記述してもよい。
【００８３】
営扱コードが含まれない以上、図６に示したデータ項目（営扱コードは除く）だけでは請求内容テーブルＴＢ２に請求情報（すなわち、行）を一意に特定する主キーが存在しないことになるため、図６の請求コードのように主キー（Ｌ１〜Ｌ７など）を構成できる新たなデータ項目を設けることが望ましい。
【００８４】
なお、行とは、一般的にテーブル中の横の並びのことであり、例えば、図６のテーブルＴＢ２においては、「Ｌ１，自動車課（ＤＤ１）、４０００，２００３．２．２５、日動太郎、ＣＤ１，１」の横の並びは、１つの行である。本実施形態の構成上、行は請求情報に等しい。
【００８５】
請求（入金予定）金額とは、各課から、該当する支払側ユーザに対し請求する金額（ここでは、保険料）を示すデータ項目である。同じ課からの請求であっても、契約している保険の内容に応じて、支払側ユーザごとに保険料の額は異なる。また、請求金額は、支払側ユーザに対して請求書などで通知されることもあるが、請求側であらかじめ把握される場合には、入金予定金額として表示される。
【００８６】
例えば、（営扱コードがＣＤ１、）支払側ユーザ名「日動太郎」の場合、自動車課からの請求金額として４０００円（Ｌ１）、５０００円（Ｌ２）、及び１００００円（Ｌ３）の３件分が記録されている。そして、船舶課からの請求金額が３０００円（Ｌ５）で、その他の請求データは存在しない。
【００８７】
なお、優先度とは、同じ支払側ユーザに対する請求のなかで振込データとの照合（消し込み）に際して、優先的に消し込み対象として選択するべきものとして、その度合いの高さを示すためのデータである。その値が小さいほど優先度が高いことを示す。図６の場合、例えば、営扱コードＣＤ１の支払側ユーザについては、請求コードＬ１、Ｌ２の順で優先度が高く、Ｌ３とＬ４については優先対象外であることが示されている。
【００８８】
優先度は、支払側ユーザからの振込金額に優先的に消し込みの対象に当てる項目であることを意味する。優先度を高く設定するのは、例えば入金予定日に入金になる確率が高い等、消し込み処理に関連する信憑性の高さに基づいて設定される。あるいは、保険会社など請求側にとって重要性の高い請求情報について高い優先度が設定されることもある。優先度の設定の方法は任意である。図６に示す請求内容テーブルＴＢ２に格納する優先度の値は、実際に振込データＲＤ２が供給される前に、設定しておく必要がある。
【００８９】
なお、消し込みとは、請求情報と振込データを照合して、各請求情報に対する払い込み（振り込み）支払がすでに行われたことを、請求（入金予定）内容テーブルＴＢ２の登録内容に反映させる処理をいう。振込データとしては、図７に示した振込データテーブルＴＢ３を用いて、それと請求情報（つまり、請求（入金予定）内容テーブルＴＢ２）との間で照合を行うことになる。図７に示した振込データテーブルＴＢ３の生成については、後に詳述する。
【００９０】
消し込みの処理方法には様々なものがあり得る。例えば、請求情報の各行（請求コードＬ１〜Ｌ７などで指定される各行）自体を請求（入金予定）内容テーブルＴＢ２から削除（消去）することをもって消し込みとしてもよいし、その行の請求金額の値を０円に変更することをもって消し込みとしてもよい。
【００９１】
本実施形態の構成上、一人の支払側ユーザに対するすべての課からの請求金額を合計した額である合計金額が重要である。例えば、営扱コードがＣＤ１、支払側ユーザ名「日動太郎」の支払側ユーザの場合、優先対象内の行は２つあり、１つの行（請求コードＬ１の行）では、自動車課からの請求金額が４０００円で、もう１つの行（請求コードＬ２の行）では５０００円であるから、合計金額は、９０００円となる。
【００９２】
一人の支払側ユーザに対する複数の請求情報のうち一部の請求情報を消し込むのが一部消し込みである。なお、消し込みが一部消し込みである場合には、行の削除による消し込みでも、請求金額の値を０円にする消し込みでも、未消し込みの請求情報が残存するため、請求（入金予定）金額の合計金額を表示する場合は、その値を変更する必要がある。
【００９３】
合計金額の値は予め算出してテーブル（例えば、ＴＢ２など）に登録しておくようにしてもよいが、ここでは、必要が生じたときに動的に算出するものとする。
【００９４】
また、請求側システム１４の内部で行われる消し込みは、中継処理サーバ２２が振込金データを受け取った時点で最初に行う消し込み処理（自動消し込み処理）と、各部門の担当社員（例えば、Ｍ１）がクライアント端末２７、２８などの操作によって請求情報や振込金データの訂正（修正）を行った後に行われる消し込み処理（修正後消し込み処理）に分けることができる。さらに、各部門の担当社員（例えば、Ｍ１）がクライアント端末２７、２８（以下では、主としてクライアント端末２７を用いる場合を例として説明する。）などの操作によって行う消し込み処理（手動消し込み処理）がある。
【００９５】
本実施形態で行われる消し込みは最初に中継処理サーバ２２による自動消し込みが行われ、自動消し込みによって消し込みのできなかった請求情報について、クライアント端末２７などから請求情報や振込データ（振込データテーブルＴＢ３）の訂正が行われる。さらに、修正された請求情報や振込データに基づいて、中継処理サーバ２２が再度消し込み処理を実施する。それでも消し込みできなかった請求情報について、各部門においてクライアント端末２７などを介して請求情報（請求（入金予定）内容テーブルＴＢ２）や振込データ（振込データテーブルＴＢ３）の内容が修正され、修正された後に再度消し込み処理が行われる。それでも消し込みできないものについては、各部門の担当者によって手動で消し込みが行われる。
【００９６】
一般的に、人間の具体的な判断が介在する手動消し込みのほうが信頼性が高いため、手動消し込みの頻度が高いほど全体として信頼性の高い消し込みを行うことができるが、効率アップの観点では、これと反対に、自動消し込みの頻度を高めることが望ましい。
【００９７】
自動消し込みで消し込めなかった各請求情報（図６のＬ１〜で指定される請求情報）や、該当する請求情報を検索できない振込データ（図４のＲＤ２参照）が発生した場合など、所定の消し込み不能条件が発生したとき、中継処理サーバ２２は、表示装置２９に当該請求情報や振込データを表示する。もしくは、部門識別情報によって請求側の部門が特定できる場合、当該部門に対して通信処理装置２１を介して消し込み不能であった旨の通知を送る。表示装置での表示や中継処理サーバ２２からの通知によって消し込み不能であった旨の情報を得た当該部門の担当者は、クライアント端末２７、２８などから中継処理サーバ２２に対して、請求情報又は振込データの修正受け付け画面の提供を要請する。
【００９８】
修正要請に基づいた修正処理と、その後の消し込み処理については、後に説明する。
【００９９】
自動消し込みに際しては、中継処理サーバ２２が機能する。自動消し込みでは、振込データＲＤ２を受け取った中継処理サーバ２２がデータベースサーバ２３に指示して、前記消し込みが自動的に実行される。
【０１００】
ほとんどの請求情報は、この自動的な消し込みによって消し込むことができるが、実際には、上述したように、自動的消し込みで消し込むことができない請求情報が発生し得る。
【０１０１】
図２に示すクライアント端末２７，２８は、企業Ｅ２内の各部門（ここでは各課）ごとに設置されている。例えば、クライアント端末２７は、自動車課Ｂ１内に設置され、クライアント端末２８は船舶課Ｂ２内に設置されている。クライアント端末は、２つに限定されるものではなく各部門に１つ又は複数設置することもでき、その数は任意である。
【０１０２】
クライアント端末２７は例えばネットワーク機能を備えたパーソナルコンピュータなどであってもよく、その内部構成は、図３に示す通りである。クライアント端末２８や前記表示装置２９もこれと同様な内部構成を備えているものである。
【０１０３】
携帯通信端末がＷｅｂブラウザなどのクライアントソフトを搭載している場合には、当該携帯通信端末をそのまま当該クライアント端末２７として用いることも可能である。
【０１０４】
（Ａ−１−２）クライアント端末の内部構成例
図３において、当該クライアント端末２７は、通信部３０と、制御部３１と、表示部３２と、操作部３３と、記憶部３４とを備えている。
【０１０５】
このうち通信部３０は、内部ネットワーク２０を経由して請求側システム１４内の各構成要素と通信するために機能する部分である。通信部３０による通信の相手には、請求側システム１４内のあらゆる構成要素を選ぶことができるが、通常は、電子掲示板システム９と通信することになる。
【０１０６】
電子掲示板システム９が各クライアント端末（表示装置２９も含む）に提供する掲示板の内容を、この表示装置２９を操作する統括部門の担当者Ｍ０が変更したり、追加したりすると、その他のクライアント端末（例えば、２８など）が当該電子掲示板システム９にアクセスすることで、変更後、追加後の掲示板を閲覧し、当該担当者Ｍ０とクライアント端末（例えば、２８）を操作する社員（例えば、Ｍ２）がメッセージ交換を行うことができる。
【０１０７】
前記操作部３３は、社員Ｍ１が操作してクライアント端末２７に指示を伝える部分で、例えば、マウスなどのポインティングデバイスやキーボードなどを有する。
【０１０８】
制御部３１は、ハードウエア的には当該クライアント端末２７のＣＰＵ（中央処理装置）に相当し、ソフトウエア的にはＯＳ（オペレーティングシステム）やクライアントソフトＣＬ１などの各種プログラムに相当する部分である。
【０１０９】
クライアントソフトＣＬ１は、社員Ｍ１がクライアント端末２７を用いてデータベースサーバ２３などへアクセスするためのプログラムである。汎用的なクライアントソフトウエアであるＷｅｂブラウザなどをクライアントソフトＣＬ１として利用することも可能であるが、専用のプログラムを利用してもかまわない。クライアント端末２７からデータベースサーバ２３へのアクセスは、電子掲示板システム９経由で行うものであってよい。
【０１１０】
サーバとしての電子掲示板システム９が提供する電子掲示板は、基本的に、クライアント端末２７を用いて担当者Ｍ１がアクセスしたときにのみ掲示板の内容（メッセージ）を前記表示部３２に表示させることのできるプル型の通信手段であるが、当該クライアントソフトＣＬ１に自動的かつ定期的にアクセスする機能を搭載すること等により、担当者Ｍ１がアクセスしようとしなくても強制的に掲示板の内容を表示させるプッシュ型の通信手段として利用することもできる。このときＭ１宛て（不特定多数宛てや、特定多数宛てであって、Ｍ１が宛先に含まれるものも含む）のメッセージのみを選択して表示させる機能（メッセージ選択機能）を持たせることは容易である。
【０１１１】
当該クライアントソフトＣＬ１はまた、前記通信部３０が通信する請求側システム１４内の上述した各構成要素のクライアントとして機能することもできる。
【０１１２】
表示部３２は、クライアントソフトＣＬ１などの機能に応じて画面表示を行うディスプレイ装置に対応する部分である。データベースサーバ２３のＤＢＭＳは関係型（関係モデル）に対応するから、例えば、ＳＱＬ文を用いて問い合わせを行うと、その問い合わせ結果が当該表示部３２に画面表示されることになる。クライアント端末２７を操作する社員Ｍ１は自動車課Ｂ１に属するから、例えば、請求側の値が自動車課（ＤＤ１）で、未消し込みの行などを検索するように問い合わせを発する可能性が高い。その場合、図５に示した請求コードＬ１の行がまだ消し込まれていなければ、当該行を含む一覧が、問い合わせ結果として表示部３２に表示され得る。
【０１１３】
このような問い合わせは、前記手動消し込みの過程において実行するものであってもよく、手動消し込みと無関係に実行するものであってもよい。
【０１１４】
記憶部３４は、ＲＡＭ（ランダムアクセスメモリ）や、ハードディスクなどによって構成される記憶資源である。前記クライアントソフトＣＬ１などのプログラムファイルも、この記憶部３４に記憶されている。また、前記表示部３２に当該一覧を含む各種画面が表示されているときには、その一覧に対応するビュー表が、この記憶部３４に格納された状態であり得る。
【０１１５】
クライアント端末２７，２８、２９以外の請求側システム１４の構成要素も基本的に図３に示すものと同じ内部構成を備えるものであってよい。ただしその場合には、表示部３２や操作部３３に相当する部分は主として、保守管理などのために使用することになる。遠隔保守などを実行する場合などには、表示部３２や操作部３３は省略可能である。
【０１１６】
また、これらはサーバであるから記憶部４４にはクライアントソフト（例えば、ＣＬ１）ではなく、各サーバソフト（例えば、ＤＢＭＳを主体とするサーバ用のプログラム）のためのプログラムファイルなどが格納されることになる。
【０１１７】
以下、上記のような構成を有する本実施形態の動作について説明する。
【０１１８】
（Ａ−２）実施形態の動作
前記クライアント端末２７からデータベースサーバ２３に対して、請求（入金予定）内容テーブルＴＢ２の内容を登録する場合の動作は次のようになる。
【０１１９】
（Ａ−２−１）請求情報登録動作
各部門の担当者のうち自動車課Ｂ１に属する担当者Ｍ１は、クライアント端末２７から、電子掲示板システム９に対して請求（入金予定）内容テーブルＴＢ２の情報登録のための入力画面を要求する。図８は請求（入金予定）内容テーブルＴＢ２の内容を入力するための入力用画面の例を示したものである。図８には、入力日を入力する欄、入力する部門の名称、部門識別情報、入金予定日、支払側ユーザ名、そして入金予定金額をそれぞ入力する欄が設けられている。各入力欄への入力の後に、登録ボタンを押下することで、請求情報がクライアント端末２７内の通信部２０を経由して電子掲示板システム９に届き、電子掲示板システム９が備える例えば、前記ＣＧＩプログラムがデータベースサーバ２３にアクセスする。この後、データベースサーバ２３の処理によって請求情報管理データベース２５に当該請求情報が登録される。毎月定期的に発生する請求情報については、例えば、前記中継処理サーバ２２からの要求を受けたデータベースサーバ２３が請求情報管理データベース２５に登録された情報に基づいて、所定の期日になった時点で当該請求情報を生成して、請求情報管理データベース２５に登録する。いずれにしてもこのような請求情報の登録は、支払側ユーザが振込を行い、その振込に応じた振込データＲＤ２が請求側システム１４へ到来する前に実行しておく必要がある。
【０１２０】
このようにして登録された請求情報のうち、例えば２００３年２月２５日が入金予定日となっているものがデータベースサーバ２３によって検索されて一覧（前記ビュー表に対応）とされたものが図６の請求（入金予定）内容テーブルＴＢ２であってよい。
【０１２１】
請求情報管理データベース２５に記録される請求情報は、クライアント端末２７や中継処理サーバ２２からのアクセスで更新されたり読み出されたりするだけでなく、クライアント端末２８や表示装置２９からの電子掲示板システム９経由のアクセスによって、読み出されたり、更新されたりすることもある。
【０１２２】
請求（入金予定）内容テーブルＴＢ２の各請求情報のうち例えば、請求コードＬ１で指定される請求情報は、自動車課Ｂ１に属する担当者Ｍ１によってクライアント端末２７より登録されたものである。また、各部門の社員（例えば、Ｍ１）は、適宜、請求（入金予定）内容テーブルＴＢ２の内容を参照して、消し込みの進捗状況などを確認することもできる。
【０１２３】
次に、中継処理サーバ２２が前記振込データＲＤ２を取得してから、消し込み処理を実施する間の流れについて、図９のフローチャート及び図４乃至図７、さらに図１０乃至図１３を用いて説明する。ここでは、図５（Ａ）または（Ｂ）に示した営扱部門対応テーブルＴＢ１は存在するものとして説明する。
【０１２４】
（Ａ−２−２）消し込み処理時の動作
消し込み処理を実行するには、その前提として前記振込データテーブルＴＢ３が生成されている必要がある。当該振込データテーブルＴＢ３に登録される振込データＲＤ２には、図４に示すように、営扱コードと、振込依頼人名、金額、振込日の情報が含まれる。この営扱コードとして振込依頼人名を含む情報や仮口座番号を利用することができることはすでに述べた通りである。
【０１２５】
中継処理サーバ２２が、このような振込データＲＤ２を取得すると（図９のステップＳ９０１）、データベースサーバ２３に振込データＲＤ２に引き継ぎ、データベースサーバ２３は、振込データＲＤ２を所定の格納部に格納する。この格納部は論理的には、図７に示したような振込データテーブルＴＢ３であってよい。振込データＲＤ２が１つ格納されるごとに、振込データテーブルＴＢ３の行が１行ずつ追加されていく。
【０１２６】
データベースサーバ２３は、振込データテーブルＴＢ３を生成する際に、営扱部門対応データベース２４に格納された営扱部門対応テーブルＴＢ１（図５）を参照して、当該振込データＲＤ２に含まれる営扱コードを検索キーとして、当該営扱コードに対応する部門識別情報を抽出し（図９ステップＳ９０３）、振込データテーブルＴＢ３に営扱コードや振込金額などの情報と対応づけて記録する。図７の例ではＣＤ１、日動太郎、８７００の行（Ｈ１）には部門識別情報として「自動車課（ＤＤ１）」と「船舶課（ＤＤ２）」が対応づけて記録される。同様に、ＣＤ２、浦野孝雄、７０００の行（Ｈ２）には部門識別情報として「自動車課（ＤＤ１）」と「自賠責課（ＤＤ３）」が対応づけて記録される。このようにして生成されたテーブルＴＢ３によれば、営扱コードが上述したように部門識別機能を持たない場合であっても、当該テーブルＴＢ３の内容だけで請求元の部門を識別することが可能となる。
【０１２７】
次に、中継処理サーバ２２は、振込データテーブルＴＢ３の内容と、請求（入金予定）内容テーブルＴＢ２の内容を照合して、消し込み処理（自動消し込み処理）を実施する。この消し込み処理の実施中にも、新たな振込データＲＤ２が到着するたびに随時、前記振込データテーブルＴＢ３に新たな行が追加されいくものであってよい。
【０１２８】
当該自動消し込み処理において、まず中継処理サーバ２２は、図７の行Ｈ１の振込データについて、部門識別情報（部門識別情報に応じた部門の名称も含む。以下同様とする。）と同じ部門識別情報を有し、かつ所定の条件（例えば、入金予定日が一定の範囲内のものなど、抽出条件として設定されたもの）に当てはまる請求情報の組を抽出して、図６に示す請求（入金予定）内容テーブルＴＢ２を生成し、請求情報管理データベース２５内の所定の個所に格納する。そして、この中から振込データの振込金額と一致または近似する額となる請求情報の組の組み合せを抽出する。図７の行Ｈ１の部門識別情報に該当する「自動車課（ＤＤ１）」と「船舶課（ＤＤ２）」を有する請求情報として、請求（入金予定）内容テーブルＴＢ２からＬ１〜Ｌ６の６件の請求情報が抽出される（図９のステップＳ９０５）。中継処理サーバ２２は、このなかで優先度の値が設定されている請求情報が存在するかどうかを確認し（図９ステップＳ９０７）、Ｌ１の行に優先度「１」のフラッグ立てられていることを確認する（図９ステップＳ９０７におけるＹＥＳ）。このあと中継処理サーバ２２は、Ｌ１の行の金額がＨ１の金額と一致するかどうかを確認する（図９ステップＳ９１３）。このケースでは金額が一致しないために、中継処理サーバ２２はＬ１の行の金額がＨ１の金額のどちらが大きいかを確認し、Ｌ１の行の請求金額の方が大きいかどうかを確認する（図９ステップＳ９１５）。請求金額の方が小さい場合、中継処理サーバ２２は図９ステップＳ９１９の「ＮＯ」判定を介して、ステップＳ９２７へと進み、別の特定すべき請求情報を選択する。
【０１２９】
同様に中継処理サーバ２２は、他に優先度の値がフラグとして立てられている請求情報が存在しないかを確認し（図９ステップＳ９０７）、Ｌ２の行に「２」の優先度フラッグが立てられていることを確認する。なお、本実施形態では、営扱コードに対応する支払側ユーザを担当する複数の部門から優先度フラッグが設定されるために、場合によっては同順位の優先度が設定されることがあるが、その場合は、適宜（例えば、部門識別情報の名称や数値や記号等を昇順に並べた場合の順番に従うなどして）、同順位の優先度の請求情報について確認順番を前後を設定して、振込データテーブルＴＢ３の金額と比較する。
【０１３０】
中継処理サーバ２２は、次の優先度「２」が付されたＬ２の行を特定し、その行の請求（入金予定）金額をＬ１の行の請求（入金予定）金額（以下、請求金額とする。）に加算する。その結果、振込データＨ１の振込金額が８７００円であったのに対し、Ｌ１とＬ２の各行の請求金額の合計が９０００円になることを確認する。中継処理サーバ２２は、Ｌ１の行とその他の複数の請求情報とを組み合わせて、８７００円に一致するか、８７００円以上でより近似する合計金額が得られるかどうかを確認する。その際、Ｌ２〜Ｌ６の行の中で優先度フラッグの立てられた請求情報が存在する場合は、その請求情報の金額を優先させてＬ１の行の金額に加算する。こうして、複数の請求情報を組み合わせて確認を行った結果として、Ｌ１とＬ２の各行の合計金額９０００円がＨ１の振込金額８７００円以上の値でもっとも近似することを確認する。さらに、中継処理サーバ２２は、次の優先度「２」のフラッグの立っているＬ２の請求情報を用いて、Ｌ１の請求情報以外の他の請求情報との組み合わせで、合計金額が９０００円と同額又は９０００円以下でより近似するものが存在するかを確認する。さらに、優先度フラッグの付されていない請求情報についても順次、単独又は組み合わせて特定して（図９ステップＳ９１３）、振込データの金額と比較をする（図９ステップＳ９１３）。
【０１３１】
こうして、中継処理サーバ２２は、振込データに記録された８７００円に一致する請求情報の組み合せが発見されないために、Ｌ１からＬ６までのすべての請求情報の組み合せについて合計金額と振込データの振込金額を比較し（図９ステップＳ９２１）、結果としてＬ１とＬ２の請求金額の合計９０００円が、振込データＨ１の８７００円以上で、もっとも８７００円に近似することを確認する（図９ステップＳ９２５）。
【０１３２】
なお、振込データの振込金額と請求情報の組み合せによる請求金額と差が最小となるものについて、組み合わせの持ち方は極力効率的に処理されるように処理手順を予め設定しておくと便利である。たとえば、各請求情報について、それぞれ単独で（１つずつ）振込データと照合して消し込み処理を実施する。この際、優先ブラッグの付された請求情報から順次照合する。そして、単独で消し込み処理できたものについては、以後の消し込み処理の対象から除外する。そのような処理手順をあらかじめ設定して、中継処理サーバ２２が消し込み処理を実施する事で、組み合せの数を大幅に削減する事ができる。
【０１３３】
さらに、中継処理サーバ２２は、請求金額の合計９０００円と、振込データＨ１の８７００円との差額が一定範囲内であるかを確認する（図示せず）。たとえば、ここでは３００円を超えない範囲であるかどうかを確認する。ここでの一定範囲であるかどうかの確認とは、例えば振込手数料として金融機関などに支払う必要のある金額を予め範囲設定のための金額として定めておき、その金額の範囲内であるかどうかを確認することをいう。範囲設定のための金額は、例えばあらかじめ中継処理サーバ２２内の所定の記憶領域内に格納される。８７００円と９０００円の差が３００円を超えないことを、中継処理サーバ２２は確認すると、請求情報の金額と振込データの金額が照合したものと見なしてよい等の判断が可能となる。すなわち、このような範囲を設定しておくことで、請求情報の金額と振込データの金額が照合したものと見なしてよいかどうかのメルクマールを得ることができる。設定された範囲を超える金額の差が生じる組み合わせしか存在しない場合、その振込データは照合できずに消し込み不能であったものとして処理（処理不能）する。
【０１３４】
こうして中継処理サーバ２２は、Ｌ１とＬ２の請求情報と、振込データＨ１を照合して、いずれともを消し込み処理する（図９ステップＳ９２９）。
【０１３５】
なお、以上の消し込み処理において、銀行などに支払う振込手数料等に起因して発生する振込データの振込金額と請求情報の請求金額との差額が、最小でかつ一定範囲内であることを確認する事で消し込み処理を実施したが、それに代えて、振込データに含まれる振込金額に所定の予想される振込金額を加算して、その金額と請求情報の請求金額（請求情報の組の組み合せによる合計額を含む）とを比較して一致するかどうかを確認するようにしてもよい。その場合、図１０に示したように、各振込データに含まれる営扱コードに対して、それぞれあらかじめ想定される振込手数料をテーブルとして記録し、請求情報管理データベース２５内の所定の格納部に格納しておく。そして、振込データが銀行側システム１４から送信された時点で、中継処理サーバ２２がデータベースサーバ２３に指示をして、振込データに含まれる金額に図１０に示したテーブル上の各金額（振込手数料）を加算して、振込データを修正する。この修正振込データを基に請求情報との消し込み処理を実施する。この場合、中継処理サーバ２２は、図９のステップＳ９１５からステップＳ９２５までの処理を省略し、ステップＳ９１３で金額が一致しにない場合には、直接ステップＳ９２７に進むようにしてもよい。
【０１３６】
この場合、図７の振込データテーブルＴＢ３には、各営扱コードに該当する支払側ユーザが振り込んだ振込元の金融機関（銀行）と、図１０に示すテーブルＴＢ４にある取引銀行が同じであったかどうかを確認し、同じであった場合は取引銀行を記録し、また振込みを受けた企業Ｅ２の自社の振込受け金融機関（銀行）名とを併せて記録するように中継処理サーバ２２はデータベースサーバ２３に指示する。この場合、データベースサーバ２３はその指示に基づいて、振込データテーブルＴＢ３を生成する。生成された振込データテーブルＴＢ３に基づいて、中継処理サーバ２２は振込データに含まれる振込金額を用いて振込手数料を特定し、それを振込データの振込金額に加算して振込データを修正し、修正した振込データを用いて、消し込み処理を実施する。以下の実施形態においても、このような修正振込データを用いて、請求情報との消し込み処理を実施する事が可能である。
【０１３７】
次に中継処理サーバ２２は、振込データＨ２についての消し込み処理を実施する。このとき振込データＨ２の部門識別情報に該当する「自動車課（ＤＤ１）」と「自賠責課（ＤＤ３）」を有する請求情報として、請求（入金予定）内容テーブルＴＢ２から、先に消し込み処理されたＬ１とＬ２を除いたＬ３〜Ｌ４とＬ７の３件の請求情報が抽出される。中継処理サーバ２２は、Ｈ１の場合と同様の処理によって、Ｌ４がＨ２と金額が同一であることを確認し、いずれともを消し込み処理する。
【０１３８】
次に、中継処理サーバ２２は振込データＨ３について消し込み処理を実施する。振込データＨ３の部門識別情報に該当する「船舶課（ＤＤ２）」と「火災課（ＤＤ４）」を有する請求情報として、請求（入金予定）内容テーブルＴＢ２から、Ｌ６の行が抽出される。中継処理サーバ２２は、振込データＨ３の振込金額とＬ６の請求情報の請求金額を比較し、請求金額の方が振込金額よりも大きいものの、両者の差額が３００円を超えることを確認し、他に該当する請求情報がないために、いずれともを消し込み不能として処理する。なお後の、修正処理において説明するが、ここでのＬ６の請求情報については、当該部門の担当者が請求情報を入力する際に、金額を誤って入力し、そのために照合ができなかったものである。
【０１３９】
このように中継処理サーバ２２は、順次、各振込データについて、消し込み処理を実施し、振込データＨ５の消し込み処理を実施する。Ｈ６の営扱コードはＣＤ６となっており、この営扱コードに対応する部門識別情報は「自賠責課（ＤＤ３）」のみである。そして、当該部門識別情報に一致し、上記と同様の処理によって金額が妥当する請求情報は存在しないことを中継処理サーバ２２は確認する。そのため、中継処理サーバ２２はＨ５の振込データを消し込み不能として処理する。さらに、振込データＨ６については請求情報Ｈ７と照合ができ、中継処理サーバ２２はそのいずれをも消し込み処理する。こうして、消し込み処理可能であったものと、消し込み処理不能であったものとが例えば図１１（Ａ）、（Ｂ）に示したようなデータとして生成され、請求情報管理データベース２５内の所定の格納部に格納される。
【０１４０】
なお、以上の消し込み処理においては、請求（入金予定）内容テーブルＴＢ２に営扱コードや支払側ユーザ名などが記録されていないことを前提としたが、これら営扱コードや支払側ユーザ名を部門識別情報と併せて請求（入金予定）内容テーブルＴＢ２に記録し、それら情報すべてを請求情報のグループ分けに用い、同じ部門識別情報と同じ営扱コードや支払側ユーザ名を有する請求情報毎に、振込データとの消し込み処理を実施することもできる。そうすることで、各振込データに対して消し込み処理対象とする請求情報の組が少なくなり、そのため請求情報の組の組み合せも少なくなり、消し込み処理の効率をさらに高めることができる。
【０１４１】
また、請求（入金予定）内容テーブルＴＢ２と振込データテーブルＴＢ３には、入金予定日と振込日とが同じものをリストアップして消し込み処理を実施したが、例えば所定の期間（例えば１ヶ月分等）の請求情報をリストアップして請求（入金予定）内容テーブルＴＢ２を生成し、同様に所定期間に振込のあった振込データに基づいて振込データテーブルＴＢ３を生成して、両者の間で消し込み処理を実施するようにしてもよい。それによって、振込予定日と実際の振込日が異なったものについても、消し込み処理を実施することができる。振込日違いによる消し込み不能の発生を防止することができる。この場合、入金予定日や振込日から所定期間（例えば１週間など）を経過しても消し込み処理のできない請求情報または振込データを中継処理サーバ２２がデータベースサーバ２３に抽出させ、中継処理サーバ２２が当該請求情報や振込データを、電子掲示板システム９を介して各部門に送信して、原因確認を促すようにしてもよい。
【０１４２】
また、消し込み処理において優先度フラッグに基づいて、消し込み処理の対象とする請求情報の選択を行ったが、常に優先度フラッグが必要となるわけではなく、優先度フラッグが設定されない場合は、中継処理サーバ２２が任意の請求情報を選択して順次消し込み処理を実施していくようにしてもよい。
【０１４３】
また、上記の請求情報の組み合わせ方法に代えて、単独（１つ）の請求情報で、対応する振込データとの消し込み処理が実施できない場合に、できるだけ多くの請求情報の組あわせによって消し込み処理可能な振込データを見出すように、中継処理サーバ２２は消し込み処理を行ってもよい。企業によっては、個々の請求情報に対して個別の振込データを厳密に対応させなくとも、たとえば、一定の期間における合計として振込データの振込金額と請求金額とが一致していれば足りると見なして処理するところもある。その場合、できるだけ多くの請求情報を、振込データと消し込み処理できるように、組み合せて消し込み処理していくこともできる。
【０１４４】
前記消し込み処理の結果は、例えば、図１１（Ａ）に示す消し込み処理済み分と、図１１（Ｂ）に示す消し込み処理不能分のようにまとめることができる。消し込み処理不能分のうち、左側に表示されたＬ５とＬ６の各行は、請求（入金予定）内容テーブルＴＢ２にリストアップされていたにもかかわらず、振込データを入手（つまり、振込のあったことを確認）できなかったものを意味する。また、右側に表示されたＨ３とＨ５は、振込データＲＤ２が銀行システムから送信されてきたにもかかわらず、当該請求情報を請求（入金予定）内容テーブルＴＢ２にリストアップされたものの中から特定できなかったものを意味する。
【０１４５】
かかる消し込み処理不能の発生する原因としては、支払側ユーザが各請求情報にかかる請求金額をまとめて振り込み、その額に相当する請求情報の組み合わせを中継処理サーバ２２が発見できなかった場合の他、請求情報又は振込データに誤りがあった場合が考えられ、また左側のＬ５とＬ６の行が消し込み不能となった理由には支払側ユーザから振り込みが実施されていない場合が、さらに右側のＨ３とＨ５が消し込み処理できなかった原因としては担当部門において請求情報の登録がなされていなかった場合が考えられる。
【０１４６】
本実施形態においては、振込データに含まれる営扱コードに対応する部門識別情報に基づいて、請求情報ついて一定のグループ単位で消し込み処理を実施するため、例えば振込人名だけで照合するなどの場合に比べて、中継処理サーバ２２が振込データに対応する請求情報の組み合わせを発見できない可能性は低くなる。しかし、振込人名や営扱コードの記載誤り、さらに金額間違いによる振込データの間違いがあった場合、中継処理サーバ２２が消し込み処理を実施することは不可能となる。また、振込データＲＤ２が銀行システム１３から送信されてくる前か、遅くとも消し込み処理を実施するまでに、請求情報が請求情報管理データベース２５に登録されていなければ、同様に中継処理サーバ２２は消し込み処理を実施することができない。
【０１４７】
このような消し込み処理不能のデータについて、本社の経理部門など一括管理処理を実施する統括部門においてその原因を確認することは困難である。最終的には、振込など払込の原因となった取引を取り扱った各担当部門（前記自動車保険課Ｂ１など）において確認することが必要になる。
【０１４８】
以下では、消し込み処理不能のデータについて、各部門がアクセスして電子掲示板システム９を介して閲覧することで、請求情報や振込データに誤りがあった場合、さらに中継処理サーバ２２による消し込み処理に間違いがあった場合の修正処理について説明する。
【０１４９】
まず、各部門の担当者（Ｍ１とする）が例えばクライアント端末２７を立ち上げ、操作部３３での操作を介して所定の部門識別情報を入力し、制御部３１の指示により通信部３０から電子掲示板システム９に、消し込み処理結果データ要請のための画面の提供を要請する。これを受けて当該電子掲示板システム９は、図１２に示した消し込み処理結果要請用の画面を、クライアント端末２７に送信する。部門担当者Ｍ１は、消し込み処理結果要請のための情報を図１２の画面に入力し、通信部３０を介して、電子掲示板システム９に送り、消し込み処理結果の表示依頼をする。この表示依頼は、前記表示装置２９の表示部３２に掲示板の内容を表示させることを依頼するものである。表示装置２９はクライアント端末であるが、表示装置２９上に搭載されている上述したクライアントソフトＣＬ１が自動的かつ定期的にアクセスを行う機能を有するため、表示依頼を受けた電子掲示板システム９が表示装置２９に宛てたメッセージ（このメッセージの内容には様々なものがあり得るが、消し込み不能の詳細を伝える場合などには、一例として、後述する図１４に示した消し込み処理不能分の画面の内容も、このようなメッセージの一部となり得る）を掲示板上に記述しておくことにより、自動的に、そのメッセージの内容が表示装置２９の表示部３２に表示される。
【０１５０】
このメッセージの生成にあたり、電子掲示板システム９は、データベースサーバ２３に消し込み処理結果要請データに含まれた内容にしたがって請求情報管理データベース２５から消し込み処理結果を抽出するよう指示をし、抽出された消し込み処理結果で当該メッセージを生成するものである。このメッセージはまた、表示依頼の送信元であるクライアント端末２７にも電子掲示板システム９から送信され、クライアント端末２７の表示部３２に表示されるものであってよいことは当然である。
【０１５１】
もちろん表示依頼以外の通常のアクセスであれば、電子掲示板システム９はアクセスを行ったクライアント端末２７のみへ、当該メッセージを送信することになる。
【０１５２】
図１２の消し込み処理結果データ取得要請画面では、要請をする部門の名称入力欄、部門識別情報の入力欄、要請する請求情報の対象期間（入金予定日が含まれる期間）  の入力欄、対象情報として自部門の情報のみか、全部門の情報か、あるいは指定した部門の情報のいずれかを選択する欄、そして部門を指定して入手したい請求情報を特定する場合の部門指定のための部門識別情報を入力する欄が存在し、要請する部門の担当者Ｍ１は、要請する内容に基づいて図１２の画面に必要項目を入力する。
【０１５３】
以下図１２では、担当者が上述した自動車（保険）課ＤＤ１ではなく船舶課ＤＤ２に属する場合（担当者Ｍ２の場合）の例を示しており、請求情報として２００３年２月に入金予定となっていたものが指定される。船舶課ＤＤ２に属する担当者Ｍ２がクライアント端末２８を操作して表示させた画面が、この図１２の画面である。ここで、２００３年２月に入金予定であった請求情報が図６にしめしたものですべてであったと仮定する。図１２では、当該船舶課の情報のみが要請されたので、図１３に示したように船舶課に関連する消し込み処理結果（不能）データだけが、表示部３２に表示される。なお、消し込み処理済みデータも併せて表示するようにしてもよいが、船舶課についてはもともと消し込み処理済みデータが存在しない。
【０１５４】
なお、各担当者が自身の属する課以外からの請求にかかる請求情報や、その消し込み処理結果の表示を求めて電子掲示板システム９にアクセスしてもよいことは当然であるが、その詳細については後述する。上述したアクセス制御機能によって拒否されない限り、電子掲示板システム９が提供するすべての掲示板の内容を各担当者Ｍ１〜Ｍ３などが自身のクライアント端末（表示装置２９も含む）で閲覧でき、各クライアント端末の表示部３２にそのアクセスに応じた画面表示が行われる。換言するなら、一部の担当者だけにしか閲覧させたくない掲示板は、前記アクセス制御機能によって、アクセスを制限することになる。
【０１５５】
クライアント端末２８の表示部３２で図１３の画面を目視した船舶課の担当者Ｍ２は、消し込み処理結果データを確認して、Ｌ５とＬ６の請求情報、そして振込データＨ３とＨ５が消し込み不能となっていることを認識する。そして、過去の取引資料などを確認して、Ｌ６の請求情報に入力されていた請求（入金予定）金額が「６５００円」ではなく、振込データＨ３の面木武子（営扱コードＣＤ３）との取引きであり、正しくは５５００円と入力すべきであったものの入力間違いであったことを確認する。また、振込データＨ５の振込人「日動太郎」の営扱コードが正しくはＣＤ１であり、支払側ユーザが振り込み処理を行う際に営扱コードを書き間違ったものと推測する。そして、取引資料を確認したり、日動太郎本人に確認するなどしたうえで、正しくは振込データの営扱コードが「ＣＤ１」と記載されるべきであったことを確認する。
【０１５６】
こうして、消し込み処理不能となった原因が確認される。船舶課の担当者Ｍ２は、クライアント端末２８の操作部３３から、図１３の請求情報修正入力ボタン１１１及び振込データ修正入力ボタン１１２を押下し、電子掲示板システム９に修正入力を受け付け可の状態にするよう要請する。１１１と１１２の各修正ボタンの押下により、図１３の各データが修正可能となり、船舶課担当者Ｍ２は、Ｌ６の請求情報の入金予定金額を５５００円に、また振込データＨ５の営扱コードを「ＣＤ１」に修正入力し、図示しない確定ボタンなどを押下して、修正情報をクライアント端末２８から電子掲示板システム９に送信する。電子掲示板システム９は、受け取った修正情報をデータベースサーバ２３に引き継ぎ、データベースサーバ２３は、請求情報管理データベース２５に格納されていた元のデータを修正内容に基づいて更新する。請求情報管理データベース２５による修正更新を受けて、中継処理サーバ２２は、改めて消し込み処理（修正後消し込み）を実施する。この修正後消し込み処理は、電子掲示板システム９から中継処理サーバ２２へ送信された要求に応じて開始されるものであってよい。修正を行った結果、図９に示した手順に基づいて、Ｌ６の請求情報と振込データＨ３が、またＬ５の請求情報と振込データＨ５が照合のうえ、消し込み処理される。こうして消し込み処理不能の事案について原因が特定され、正しく消し込み処理が行われる。
【０１５７】
次に、自動車課ＤＤ１が消し込み処理結果データを要請した場合について説明する。自動車課ＤＤ１の担当者Ｍ１は、上で述べたと同様に、消し込み処理結果データ要請のための画面の提供を電子掲示板システム９に要請し、電子掲示板システム９から送られてきた図１２で示したものと同じ画面上で、対象請求情報として「下記指定部門の情報」を選択し、指定部門識別情報欄に「自動車課ＤＤ１」と「船舶課ＤＤ２」と「自賠責課ＤＤ３」を入力したとする。その結果、図１１（Ａ）および（Ｂ）に示したように自動車課ＤＤ１を含む３つの課（部門）の消し込み処理結果データが中継処理サーバ２２によって生成され、取得される。なおこの時点では、船舶課による修正処理が未だ実施されていないものと仮定する。そのため、消し込み処理不能分として船舶課に関連するデータが表示されている。ここで、自動車課ＤＤ１の担当者Ｍ１が、中継処理サーバ２２によって消し込み処理されたＬ１及びＬ２の請求情報の組と振込データＨ１とが、ただしくは消し込み処理してはいけないものであることを確認したとする。例えば、振込データＨ１は、登録忘れなどで登録されていなかった別の例えば８７００円という金額の取引に基づいて振り込まれたものであったとする。その場合、Ｍ１は表示部３２に表示された図１１のＨ１の行の「消し込み取り消し」欄にチェックマークなどを入力し、「消込結果修正」ボタン１２３をクライアント端末２７の操作部３３から押下する。図１１のＨ１の行に対する「消込結果修正」ボタン１２３の押下に伴って、その情報が電子掲示板システム９経由で中継処理サーバ２２に送信される。中継処理サーバ２２は、データベースサーバ２３に、消し込み処理済みとして登録していたＬ１とＬ２の請求情報、さらに振込データＨ１とを、消し込み処理不能として更新するよう指示し、データベースサーバ２３は、請求情報管理データベース２５の内容を更新する。更新した結果が中継処理サーバ２２からクライアント端末２７に送信され、表示部３２に表示された内容を示したのが図１４である。図１４では、消し込み処理不能に分類されていたＬ６とＬ５にさらにＬ１とＬ２の請求情報が加えられて消し込み処理不能分として表示される。また消し込み処理不能の振込データとしてＨ３、Ｈ５にＨ１が加わって表示される。この場合、自動車課の担当者Ｍ１は、併せて振込データＨ１に対応する請求情報の登録をクライアント端末２７から行う。登録された請求情報をデータベースサーバ２３は請求情報管理データベース２５内で更新し、その登録結果を受けて中継処理サーバ２２が再度消し込み処理を実施する。
【０１５８】
中継処理サーバ２２による消し込み処理は、修正や登録がなされ、修正等の情報を受け取った時点で中継処理サーバ２２が実施するようにしてもよいし、あるいは所定の間隔で定期的に消し込み処理を実施するようにしてもよい。
【０１５９】
なお、上で説明した消し込み処理結果データの修正受け付けに際して、部門識別情報に基づいて修正権限の有無を電子掲示板システム９の前記アクセス制御機能または中継処理サーバ２２が管理するようにしてもよい。これにより修正しようとする当該部門識別情報と関連付けられた営扱コードにかかる振込データや、当該部門識別情報を有する請求情報についてのみ当該部門からの修正を受け付け、それ以外の部門からの修正は受け付けない処理とする事ができる。
【０１６０】
このようにして、電子掲示板システム９が消し込み処理結果データに関する修正処理のための画面を提供し、各部門から修正内容を受け付け、修正された内容で消し込み処理を再度実施することで、請求情報と振込データとの照合をより正確に行うことができる。各部門では、取引の実態を詳細に把握しているため、消し込み処理ができなかったものについてその原因を確認して、正しく消し込み処理できるように本システムを利用することで効率的に実施する事ができる。また、中継処理サーバ２２が間違って消し込み処理済みとして処理していた事案についても、各部門担当者がその間違いを確認して、正しい処理となるように修正することができる。
【０１６１】
さらに、必要ならば、前記中継処理サーバ２２が受信した振込データＲＤ２の内容を示すログ情報などを蓄積しておくとよい。このログ情報を、各社員（例えば、Ｍ１）が適宜、クライアント端末を用いて検査することで、消し込み処理に誤りがないこと等を確認することができる。
【０１６２】
なお、以上のような自動消し込み処理、修正後消し込み処理によっても消し込みができない場合、中継処理サーバ２２は電子掲示板システム９を介して当該部門に対し、手動消し込み処理を依頼する。
【０１６３】
このような請求側システム１４の内部において、上述した消し込み不能条件が発生し、手動消し込みを行わせたい場合には、該当する部門にその旨を通知し、手動消し込み開始依頼を行う必要がある。
【０１６４】
この通知の方法には様々なものがあり、例えば、電子メールなどを利用することも可能であるが、本実施形態では上述したように、主として電子掲示板を利用する。
【０１６５】
まずクライアント端末２７から前記担当者Ｍ１が電子掲示板システム９から消し込み処理不能であった請求情報を取得する場合について説明する。
【０１６６】
本実施形態では、最初に電子掲示板システム９が提供する掲示板にメッセージＭＳ１を記述して請求情報や振込データの確認依頼をし、手動消し込みの依頼を行うのは、中継処理サーバ２２である。
【０１６７】
担当者Ｍ１など各部門の担当者は、自身が所属する部門にだけアクセスを許可する前記アクセス制御機能により、または自身宛のメッセージだけを選択して表示部３２に表示させる上述したメッセージ選択機能により、自身の部門に関連するメッセージ（例えば、ＭＳ１）のみを確認することができる。
【０１６８】
手動消し込み等の依頼メッセージＭＳ１は、手動消し込みの開始を該当する部門の社員に依頼するメッセージであるが、単に依頼するだけでなく、手動消し込みに必要な最低限の情報は、依頼と同時に伝えるほうが効率的であるから、その内容は、発生した消し込み不能条件に応じて相違し得る。
【０１６９】
例えば、消し込み不能条件が、自動消し込みにおいて上述した一部消し込みを実行したことである場合には、一部消し込みで残った行の内容のほか、その一部消し込みにかかる振込データＲＤ２の内容や、一部消し込みで消し込んだ行の内容なども手動消し込み開始依頼メッセージＭＳ１に含めることが望ましい。
【０１７０】
消し込み処理がされた請求情報の内容を含める場合、その手動消し込み開始依頼メッセージＭＳ１の宛先（例えば、前記アクセス制御機能によりその手動消し込み開始依頼メッセージＭＳ１へのアクセスを許可される課または社員）は、その行の部門識別情報の値に応じて決定されることになる。
【０１７１】
具体的な宛先は、一部消し込みで残った行の請求側（その部門の担当者）だけとしてもよいが、一部消し込みで消し込んだ行の請求側も含めるようにしてもよい。一部消し込みで残った行の請求側だけを宛先とした場合、その宛先の課の社員が必要性を認めれば、いつでも、一部消し込みで消し込んだ行の請求側と、電子掲示板システム９を利用して連絡を取り合うことができる。
【０１７２】
例えば、営扱コードＣＤ１の支払側ユーザからの振込に対応する振込データＲＤ２の供給に応じて、Ｌ１〜Ｌ３の行のうちＬ１の行だけを一部消し込みで消し込んだ場合には、残ったＬ２，Ｌ３の行の請求側である船舶課と貨物課だけを手動消し込み開始依頼メッセージＭＳ１の宛先としてもよいが、消し込んだＬ１の行の請求側である自動車課も、宛先に含めるようにしてもよい。
【０１７３】
金額Ｆ３の値（振込金額）に過不足のない正常な振込データＲＤ２が届いていたら一部消し込みを行う必要はないのであるから、自動消し込みで一部消し込みを行ったということは予期せぬ誤りが潜んでいる可能性も小さくないことを意味する。そしてこのような予期せぬ誤りを効率的に検出するには、これらの課の共同作業が必要となる可能性がある。一部消し込みに起因する手動消し込み開始依頼メッセージＭＳ１を受けた課の担当者の主たる役割は、そのような予期せぬ誤りの有無を検査することにある。
【０１７４】
検査のために必要ならば、各課の担当者は、前記電子掲示板システム９を利用してメッセージ交換を行うことができる。
【０１７５】
この検査の結果、例えば、振込データＲＤ２中に記述された営扱コードが誤っていたこと（誤って記述された営扱コードと同じ値の営扱コードが偶然、テーブルＴＢ１上に存在していたこと）が原因で自動消し込みによる一部消し込みを行っていたことが判明する場合などもあり得る。その場合、当該担当者は、その一部消し込みを取り消す必要がある。この取り消しは、前記手動消し込みの一部として実行され、当該手動消し込みにより請求内容テーブルＴＢ１の内容はさらに変更される可能性がある。
【０１７６】
振込データＲＤ２に振込依頼人名などが記述されていれば、当該担当者はその記述に基づいて、営扱コードの入力ミスなどを検出することが可能である。
【０１７７】
反対に、振込依頼人名の記述に誤りが存在することもあり得るが、本実施形態の構成上、振込依頼人名は自動消し込みに利用していないため、振込依頼人名の記述に誤りがあったとしても、それが原因で手動消し込みが開始されることはない。ただし、振込依頼人名を自動消し込みに利用する構成を取ることも可能であり、そのような構成を取った場合には、振込依頼人名の記述の誤りが原因で前記消し込み不能条件が発生し、手動消し込みが開始されることも起こり得る。
【０１７８】
一般的に、人間にとって意味を理解しにくく可読性の低い営扱コードに比べ、理解しやすい自然言語で記述される振込依頼人名は、誤りが発生する頻度が低いと考えられる。
【０１７９】
自動消し込みや手動消し込みによる一連の処理の履歴は、後で追跡できるように、前記ログ情報として保存しておくことが望ましい。
【０１８０】
また、前記消し込み不能条件が、該当する行を検索できない振込データＲＤ２が供給されたことである場合には、その振込データＲＤ２の内容が、手動消し込み開始依頼メッセージＭＳ１に含められ、一部消し込みさえ実行できなかった場合には、残った行の内容だけが手動消し込み開始依頼メッセージＭＳ１に含められる。
【０１８１】
該当する行を検索できない振込データＲＤ２が供給された場合、営扱コードに部門識別機能を持たせない本実施形態では、その振込データＲＤ２に対応する請求側を絞り込むことができないため、手動消し込み開始依頼メッセージＭＳ１の宛先は、企業Ｅ２内のすべての課（請求側となる可能性のない課は除外できる）となる。
【０１８２】
また、一部消し込みさえ実行できなかった場合には、残った行の請求側を宛先として、電子掲示板システム９に手動消し込み開始依頼メッセージＭＳ１を送信し、掲示板に対しその旨の記述を行うことになる。
【０１８３】
例えば、営扱コードＣＤ１の支払側ユーザに関するＬ１〜Ｌ３、Ｌ５の行が一部消し込みさえ実行されずに全て残った場合、請求側である自動車課と船舶課に宛てて、手動消し込み開始依頼メッセージＭＳ１が送信されるが、Ｌ１〜Ｌ３、Ｌ５の行の請求側となっていない自賠責課や国際課などへ宛てては、手動消し込み開始依頼メッセージＭＳ１は送信されない。
【０１８４】
これにより、各担当者は自身の所属する部門に関連が強い手動消し込み開始依頼メッセージＭＳ１だけを読めばよくなり、手動消し込みの作業を効率的に進めることができる。
【０１８５】
なお、手動消し込みを実行する担当者が必要性を認めた場合には、当該手動消し込み開始依頼メッセージＭＳ１に含まれたもの以外の情報を、請求側システム１４内の各構成要素（例えば、請求内容テーブルＴＢ１など）から収集できることは当然である。
【０１８６】
中継処理サーバ２２から手動消し込み開始依頼メッセージＭＳ１を受けた担当者が消し込みを行うことができた場合、その時点で手動消し込みの手順は終了するが、その担当者が消し込みを行うことができなかった場合には、さらに手動消し込みの手順を継続することが望ましい。
【０１８７】
この継続は、例えば、手動消し込みで消し込めなかった担当者（例えば、Ｍ１）が、２次的な手動消し込み開始依頼メッセージＭＳ２を、電子掲示板に記述することによって行うことができる。
【０１８８】
その担当者Ｍ１が、手動消し込みを行うことのできる１または複数の担当者（あるいは、１または複数の部門）を推測できたときには、２次的な手動消し込み開始依頼メッセージＭＳ２は、その担当者（あるいは、部門）に宛てたものとすることができるが、推測できないときには企業Ｅ２内のすべての課に宛てた（すなわち、不特定多数に宛てた）ものとする。
【０１８９】
なお、基本的にはプル型の通信手段あり、リアルタイム性に欠ける電子掲示板の欠点を補うため、新たな手動消し込み開始依頼メッセージＭＳ１（または、ＭＳ２）が電子掲示板上に記述されたことのみを伝える電子メールを、自動的に、該当する部門の該当する担当者に送信することも望ましい。このような電子メールを自動的に作成し、送信する機能は、例えば、中継処理サーバ２２に搭載することができる。
【０１９０】
またこの電子メールは、その担当者（例えば、Ｍ２）が携帯している携帯通信端末（例えば、メール端末、携帯電話機、ＰＨＳ端末など）に宛てて送信することが望ましい。これにより、その担当者Ｍ２がどこにいても、その担当者Ｍ２宛ての手動消し込み開始依頼メッセージＭＳ２またはＭＳ１が電子掲示板システム９が提供する電子掲示板に記述されたことをリアルタイムで伝えることができる。
【０１９１】
なお、電子メールの代わりに、例えば、ページャなどを活用してもよいことは当然である。
【０１９２】
（Ａ−３）実施形態の効果
本実施形態によれば、請求（入金予定）内容テーブル（ＴＢ２）の行（Ｌ１〜Ｆ７の行）の消し込み処理の効率を高めることができる。
【０１９３】
加えて、本実施形態では、各種の誤りが発生した場合の一部消し込みの処理効率も高めることが可能で、柔軟性が高い。
【０１９４】
また、本実施形態では、自動消し込みを補完する手動消し込みを効率的に実行することが可能であるため、効率的であるだけでなく、消し込み結果の信頼性も高い。
【０１９５】
（Ｂ）他の実施形態
なお、上記実施形態では、図５〜図７などに各種のテーブルの内容を具体的に示したが、各テーブルの値（インスタンス）はもとより、構成（スキーマ）も図示したものと異なるものにすることができる。
【０１９６】
例えば、通常、企業Ｅ２が前記報告サービスの提供を受ける銀行は、前記銀行Ｋ１だけでなく複数であるのが普通であると考えられるので、各テーブルに、各銀行を識別するためのデータ項目として銀行コードを設けるようにしてもよい。
【０１９７】
銀行コードを設けた場合などには、クライアント端末からの問い合わせの内容に応じて、特定の銀行（例えば、Ｋ１）に対応する行だけから構成されるビュー表を生成し、当該ビュー表に対応する一覧をクライアント端末の表示部３２に表示すること等が可能なことは当然である。
【０１９８】
また、各テーブルに対しては、適宜、正規化（第１〜第３正規化）を施して、テーブル管理の効率化をはかることが望ましい。
【０１９９】
さらに、各テーブルの行の数は図示したものより、少なくてもよく、多くてもよいことは当然である。ただし、例えば、テーブルＴＢ２の場合、行の数は、最大で企業Ｅ２に対する支払側ユーザの数の数倍程度になるものと考えられるから、通常は、図示したものよりはるかに膨大な数の行が存在し得る。
【０２００】
なお、前記特許文献１の振込専用口座を利用する場合、一人の支払側ユーザに複数の振込専用口座を割り当て、請求側の課に応じて異なる振込専用口座に振り込ませるようにしてもよい。その場合、いずれの請求側からの請求に対する支払であるのかを、実際に振込が行われた振込専用口座の口座番号から確認することができる。
【０２０１】
ただしこの場合でも、必ずしも、振込専用口座と請求側（の課）を１対１に対応付ける必要はない。したがって、１つの振込専用口座に複数の請求側が対応付けられているところでは、上述した一部消し込みで消し込む行の選択を行うことができる。
【０２０２】
なお、上記実施形態では、Ｂ１とＢ２は、異なる課であるものとしたが、これは課以外の単位で分けてもよいことは当然である。例えば、地理的に離れた場所に点在する事業所（本店、支店など）を単位としてもよい。
【０２０３】
また、上記実施形態では、Ｂ１とＢ２は基本的に対等なものであったが、前記担当者Ｍ０が属する経理部などの統括部門は、例えば、消し込み処理の進行や、各テーブルの格納内容に関し、他の部や課よりも包括的な責任を負うため、より優先的で広範囲なアクセス権限を経理部に与えるようにしてもよい。例えば、他の部などに属する担当者がアクセスできないデータ項目に対し、経理部に属する担当者がアクセスできるようにしてもかまわない。例えば、ある支払側ユーザに関する過去の支払状況の履歴を示すデータ項目を設けた場合に、そのデータ項目へアクセスできるのは、経理部だけ等としてもよい。
【０２０４】
なお、保険会社などのように、企業Ｅ２の内部で各事業所ごとの管轄エリアがある場合などには、管轄エリア内の銀行店舗から入力されているか否かを確認（自動または手作業による確認）すること等も、前記手動消し込みに際して有効な手段となり得る。
【０２０５】
さらに、上記実施形態で手動消し込みによって担当者が行った作業の一部または全部は、自動的に実行することできる可能性がある。
【０２０６】
なお、上記実施形態では主として、営扱コードが支払側ユーザ識別機能だけしか持たない場合を想定したが、営扱コードが支払側ユーザ識別機能に加えて前記請求側識別機能を持つ場合でも、基本的には、上記実施形態の各処理をそのまま適用することができる。
【０２０７】
支払側ユーザ識別機能とともに部門識別機能を持つ営扱コードの入力は、支払側ユーザが自身が振り込んだ金銭の請求側を特定する意思表示とみることができるから、その点を重視して処理に変更を施すことも望ましい。
【０２０８】
ただしその場合でも、営扱コードそのものの入力ミスにも配慮して自動消し込みや手動消し込みを行うには、結局、営扱コードの部門識別機能の正常性を疑った処理を実行する必要があるのであるから、営扱コードが支払側ユーザ識別機能しかもたない場合と同様な処理も実行する必要がある。
【０２０９】
さらに、上記実施形態では各部門から自主的に、消し込み処理不能の案件を確認して、その修正処理を実施し、その修正に基づいてさらに消し込み処理することとしたが、消し込み処理不能であった振込データや請求情報を、中継処理サーバ２２が関連する部門に送信するようにしてもよい。消し込み処理不能の請求情報の組や振込データについて、部門識別情報に応じた部門に宛てて、第１回目の消し込み不能通知を送信し、それによって各部門が請求情報や振込データの修正を行ったり、手動消し込みを行い、それでも消し込み処理ができなかったものについては、例えば、全部門に再送信して確認を促してもよい。
【０２１０】
そうすることで、営扱コードの入力間違いなどでまったくことなった部門が対応付けられてしまった場合でも、その他の部門が確認して、自分の部門の振込データであったことを確認することができる。この際に、再送信する先を全部門とせずに、例えば、対応付けられた部門と同一のエリア（例えば、同一県内の各部門等）や類似した機能を有する組織（例えば本社内の各統括部門）、さらには組織的上下関係において同一のレベルにある部門（支店や本部などの組織レベル）など、特定の関係を有する複数の部門に再送信するようにしてもよい。この場合、図５（Ａ）、図５（Ｂ）などの営扱部門対応テーブルには、各部門の属性情報（例えば、所属エリア、機能属性、組織内上下関係のレベルなど）を合わせて記録し、以後の請求情報などにも当該情報を引き継いでいく。又は、請求側システム１４に、別途部門属性データベースを保持し、このように部門属性を部門識別情報と対応付けて保持させてもよい。
【０２１１】
また、以上の説明では主としてハードウエア的に本発明を実現したが、本発明はソフトウエア的に実現することも可能である。
【０２１２】
【発明の効果】
以上に説明したように、本発明によれば、組の消し込み処理を効率的に実行することができる。
【図面の簡単な説明】
【図１】実施形態に係る通信システムの全体構成例を示す概略図である。
【図２】実施形態で使用する請求側システムの内部構成例を示す概略図である。
【図３】実施形態で使用するクライアント端末の内部構成例を示す概略図である。
【図４】実施形態で使用する振込データのフォーマットの構成例を示す概略図である。
【図５】実施形態で使用する営扱部門対応テーブルの構成例を示す概略図である。
【図６】実施形態で使用する請求（入金予定）内容テーブルの構成例を示す概略図である。
【図７】実施形態で使用する振込データテーブルの構成例を示す概略図である。
【図８】実施形態で使用する請求内容登録画面の構成例を示す概略図である。
【図９】実施形態の動作例を示すフローチャートである。
【図１０】実施形態で使用するテーブルの構成例を示す概略図である。
【図１１】実施形態の動作例を示す動作説明図である。
【図１２】実施形態で使用する消し込み処理結果要請用の画面の構成例を示す概略図である。
【図１３】実施形態の動作例を示す動作説明図である。
【図１４】実施形態の動作例を示す動作説明図である。
【符号の説明】
９…電子掲示板システム、１０…通信システム、１１…外部ネットワーク、１２…支払側システム、１３…銀行システム、１４…請求側システム、２０…内部ネットワーク、２１…通信処理装置、２２…中継処理サーバ、２３…データベースサーバ、２４…営扱部門対応データベース、２５…請求情報管理データベース、２７，２８…クライアント端末、２９…表示装置、３０…通信部、３１…制御部、３２…表示部、３３…操作部、３４…記憶部、ＲＤ１、ＲＤ２…振込データ、ＴＢ１〜ＴＢ４…テーブル、ＭＳ１，ＭＳ２…手動消し込み開始依頼メッセージ。
【図１】
2004302574.tif 000003
【図２】
2004302574.tif 000004
【図３】
2004302574.tif 000005
【図４】
2004302574.tif 000006
【図５】
2004302574.tif 000007
【図６】
2004302574.tif 000008
【図７】
2004302574.tif 000009
【図８】
2004302574.tif 000010
【図９】
2004302574.tif 000011
【図１０】
2004302574.tif 000012
【図１１】
2004302574.tif 000013
【図１２】
2004302574.tif 000014
【図１３】
2004302574.tif 000015
【図１４】
2004302574.tif 000016