JP2014194702A - 請求入金マッチング装置、請求入金マッチング方法及び請求入金マッチングプログラム - Google Patents

Abstract

【課題】入金元の支払いの特徴を反映させたうえで、１つの入金に対応する１又は複数の取引の組合せを複数表示する。
【解決手段】
本発明の請求入金マッチング装置は、反復する同種の債権を請求単位に集計し組合せ単位を作成し、それ以外の債権については個々の債権からなる組合せ単位を作成し、支払期日の前後関係と、反復する同種の債権であるか否かに応じて定義される組合せ単位の区分の優先順位が高い順に、作成した組合せ単位の一部を抽出し、抽出した組合せ単位のうちから所定の数を選択した組合せの合計金額を入金金額と突合し、金額が一致した組合せに含まれる債権の金額を表示する処理を繰り返す。
【選択図】図３

Description

本発明は、請求入金マッチング装置、請求入金マッチング方法及び請求入金マッチングプログラムに関する。

企業は、顧客に対して商品及び役務を提供した後、顧客に対して請求書を発行する。顧客は、請求書の内容を確認し、企業が指定した支払期日までに、企業が指定した銀行口座あて入金する。企業は、請求書のリストのなかから、入金された取引を特定する作業を行う。そして、企業は、入金された取引については領収書を発行し、そうでない取引については入金を催促する等の次の工程の作業に進む。当該特定する作業は、一般には突合作業、照合作業等と呼ばれる。当該作業を効率的に行うための既存技術が多く存在する。

特許文献１に記載の入金照合プログラムは、コンピュータに対し、入金予定データと、実入金データとを相互照合する処理を実行させる。そして、入金照合プログラムは、それぞれのデータの複数の項目のうち、照合（突合）する項目と照合しない項目をパターン化し、そのパターンを優先順位に関連付けて記憶させている。さらに、入金照合プログラムは、優先順位に従って、特定の項目についてのみ照合処理を実行させる。

特開２０１１−１１８５４４号公報（請求項１）

実際には、請求書及び入金は、単純な１対１の対応関係を有していない。実際の突合作業等において、銀行振込手数料を節約する、等の理由から、企業は、複数の請求書の取引を１度にまとめて支払う（銀行口座に入金する）ことが多い。そこで、１度の入金に対して、多くの取引候補のうち、どの複数の候補の組合せが、１つの入金に対応するかを、正確かつ迅速に決定することが重要になってくる。
支払いを行なうべき多くの取引候補のうち、どの候補から順番に、どれだけの候補をまとめて支払うかについては、顧客ごとに特徴が存在する。なぜならば、顧客においては、請求書の内容確認及び支払いを複数の部署が分担して行うためである。突合作業を行う企業の担当者は、この特徴を、経験に基づいて判断することにより、入金予定データ及び実入金データの突合を迅速かつ正確に完成させることに努める。

しかしながら、特許文献１の技術は、「取引先」及び「取引金額」を必須項目とし、「入金日」及び「入金方法」のそれぞれをチェックするか否かのパターンを定めているに過ぎない。さらに、特許文献１の技術は、突合条件の数だけ「ＩＦ構文」を設定する構成になっていることに起因して、突合結果を１つしか表示しない。つまり、特許文献１の技術は、顧客ごとの微妙な特徴を反映できるような検索方法を提供せず、特許文献１の技術だけでは、実際に突合する入金予定データを取得するには、熟練者であっても相当量の試行錯誤を必要とする。さらに、複数の突合結果のうちから真に顧客の意図に合致していると思われる請求の組合せをユーザが最終決定することができない。
そこで、本発明は、入金元の支払いの特徴を反映させたうえで、１つの入金に対応する１又は複数の債権を複数表示することを目的とする。

本発明の請求入金マッチング装置は、反復する同種の債権を請求単位に集計し組合せ単位を作成し、それ以外の債権については個々の債権からなる組合せ単位を作成し、支払期日の前後関係と、反復する同種の債権であるか否かに応じて定義される組合せ単位の区分の優先順位が高い順に、作成した組合せ単位の一部を抽出し、抽出した組合せ単位のうちから所定の数を選択した組合せの合計金額を入金金額と突合し、金額が一致した組合せに含まれる債権の金額を表示する処理を繰り返すことを特徴とする。
その他の手段については、発明を実施するための形態のなかで説明する。

本発明によれば、入金元の支払いの特徴を反映させたうえで、１つの入金に対応する１又は複数の債権を複数表示することが可能になる。

本実施形態の請求書の一例を示す図である。 本実施形態の請求入金マッチング装置の構成図である。 本実施形態の処理の流れを概説する図である。 本実施形態の債権請求情報の一例を示す図である。 （ａ）は、本実施形態の入金情報の一例を示す図であり、（ｂ）は、本実施形態の組合せ単位区分情報の一例を示す図である。 本実施形態の組合せ単位作成方法情報の一例を示す図である。 本実施形態の組合せ単位情報の一例を示す図である。 本実施形態の組合せ単位作成方法の一例を示す図である。 本実施形態の組合せ単位作成方法の一例を示す図である。 本実施形態の組合せ単位作成方法の一例を示す図である。 本実施形態の組合せ単位作成方法の一例を示す図である。 本実施形態の組合せ単位作成方法の一例を示す図である。 本実施形態の組合せ単位作成方法の一例を示す図である。 本実施形態の組合せ単位作成方法の一例を示す図である。 本実施形態の処理手順のフローチャートの一例を示す図である。 本実施形態の検索条件入力画面の一例を示す図である。 本実施形態のステップＳ２０６の処理を説明する図面である。 本実施形態のステップＳ２０７の処理を説明する図面である。 本実施形態のステップＳ２０９の処理を説明する図面である。 本実施形態の検索結果出力画面の一例を示す図である。

以降、本発明を実施するための形態（「本実施形態」という）を、図等を参照しながら詳細に説明する。

（債権と請求との関係及び顧客の支払い習慣等）
図１に沿って請求書を説明する。請求書１には、請求日１ａ、請求ＩＤ１ｂ、請求先名１ｃ、請求者名１ｄ、請求明細１ｉ〜１ｌ、請求金額１ｍ、支払期日１ｎ及び支払口座番号１ｏが記載されている。請求日１ａは、請求書１が発行された年月日である。請求ＩＤ１ｂは、請求書１を一意に特定する識別子である。請求先名１ｃは、商品又は役務の提供を受けた者（顧客）の名称である。請求者名１ｄは、商品又は役務の提供を行った者の名称である。請求明細１ｉ〜１ｌは、項番欄１ｅ、摘要欄１ｆ、照会番号欄１ｇ及び金額欄１ｈから構成される。債権明細の個々のレコードは、個々の取引によって発生した売掛金に対応する。この売掛金を本実施形態では「債権」と呼ぶ。つまり、１又は複数の債権が、１つの請求書１に対応している。

項番欄１ｅには、個々の債権の、請求書１上の記載順序が記載される。摘要欄１ｆには、個々の債権の、債権発生原因が記載される。照会番号欄１ｇには、個々の債権を一意に特定する債権ＩＤが記載されている。金額欄１ｈには、個々の債権の金額が記載されている。請求金額１ｍは、個々の債権の金額の合計金額である。支払期日１ｎは、請求金額が銀行口座に振り込まれるべき期日である。支払口座番号１ｏは、請求金額が振り込まれるべき銀行口座に関する情報である。

企業は、通常、ある顧客ごとに、１又は複数の債権をまとめて請求書１としてその顧客に請求する。企業は、ある期間に発生したすべての債権を１つの請求項１にまとめることもある。また、ある期間に発生した複数の債権を、債権の発生原因等に応じて複数の請求書に分けて請求することもある。

顧客は、通常、ある商品又は役務の提供を行った企業ごとに、指定された銀行口座に対して支払う。しかしながら、ある１つの請求書１に記載された請求金額１ｍを、１度の入金として支払う場合もあり、そうでない場合もある。顧客独自の支払いのルールとして、例えば以下が想定される。本発明は、以下のようなルールを利用して、照合処理の効率化を図る。

（ルール１）請求書の単位を無視して、個々の取引ごとに支払う。稀な例であるが、取引の発生が散発的になると一般化する。なお、取引とは、企業から見れば「債権」である（以下同様）。
（ルール２）取引の単位を無視して、請求書ごとに支払う。決裁権者が少ない小規模顧客に多く見られる。
（ルール３）同種同額の支払いが毎月発生することが予定されている取引（「継続」取引と呼ぶ）は、請求書ごとに支払う。
（ルール４）さらに、複数の継続取引についての複数の請求が同じタイミングであった場合は、複数の請求書についてまとめて１度で支払う。
（ルール５）継続取引以外の取引（「スポット」取引と呼ぶ）については、個々に金額の妥当性等を確認した後に、取引ごとに支払う。
（ルール６）特に重要な取引については、支払先の企業に連絡した上で支払う。

（ルール７）支払い予算が制約されている場合、同種の「継続」取引又は「スポット」取引のうち、支払期日が現時点に最も近い取引を後回しにして、過去に未払いがある取引を先に支払う。
（ルール８）支払い予算が制約されている場合、同種の「継続」取引又は「スポット」取引のうち、過去に未払いがある取引を後回しにして、支払期日が現時点に最も近い取引を先に支払う。
（ルール９）支払い予算が制約されている場合、支払期日が現時点に最も近い取引を後回しにして、支払期日が先である取引を先に支払う。
（ルール１０）支払い予算が制約されている場合、支払期日が先である取引を後回しにして、支払期日が現時点に最も近い取引を先に支払う。

なお、請求入金マッチング装置２は、ルール１〜ルール６に対応して、組合せ単位作成方法情報３４（図６）を備え、ルール７〜ルール１０に対応して、組合せ単位区分情報３３（図５（ｂ））を備えているといえる。

前記ルールのうち、ルール１〜ルール６は、支払いを誰がどのように決裁するかという、顧客の組織上の習慣（特徴）を反映している。ルール７〜ルール１０は、予算が限られている場合の、顧客の支払い順序上の習慣を反映している。

図２に沿って、請求入金マッチング装置の構成を説明する。請求入金マッチング装置２は、一般的なコンピュータである。請求入金マッチング装置２は、中央制御装置１１、例えばマウス、キーボードのような入力装置１２、例えばディスプレイのような出力装置１３、主記憶装置１４、補助記憶装置１５及び通信装置１６を有している。これらの各装置は、バスによって相互に接続されている。請求入金マッチング装置２は、ネットワーク４を介して、端末装置３と接続されている。補助記憶装置１５は、債権請求情報３１、入金情報３２、組合せ単位区分情報３３、組合せ単位作成方法情報３４及び組合せ単位情報３５を格納している（いずれも詳細後記）。主記憶装置１４内に記載されている組合せ単位作成部２１及び組合せ単位突合部２２は、プログラムである。本実施形態において、「○○部は」というように主体を記した場合は、中央制御装置１１が、そのプログラムを補助記憶装置１５から主記憶装置１４にロードしたうえで、そのプログラムの機能（詳細後記）を実現するのとする。
端末装置３もまた同様に、相互にバスで接続された、中央制御装置、入力装置、出力装置、主記憶装置、補助記憶装置及び通信装置（図示せず）を有している。

図３に沿って、発明内容の理解を容易にするために、本実施形態の処理の流れの概要を説明する（詳細については後記する）。
（Ｐ１）組合せ単位作成部２１は、複数の債権を取得する。
（Ｐ２）組合せ単位作成部２１は、１又は複数の債権を集計し、「組合せ単位」を作成する。この際に、どのような条件で集計するかについては後記する。１つの債権が１つの組合せ単位となる場合もあり得る。
（Ｐ３）組合せ単位作成部２１は、組合せ単位に集計されている債権の内容に応じて、処理を行う順序を特定する。例えば、他の組合せ単位を残し、まず処理するべき「１回目」の組合せ単位を特定する。

（Ｐ４）組合せ単位作成部２１は、例えば入金金額を超過する金額を有する組合せ単位等、組合せ単位として明らかに不適であるものを除外する。詳細は、図１７を用いて後記する。
（Ｐ５）組合せ単位作成部２１は、組合せ単位の候補のうちから、入金金額と合計を突合するべき候補の数の初期値を決定する。一般的に「_ｎＣ_ｍ」は、ｎ個の要素のうちからｍ個の組合せを選択する場合の数（ｍ個の順列は無視する）を示す。組合せ単位作成部２１が決定するのは、この「ｍ」の初期値である。詳細は、図１８を用いて後記する。
（Ｐ６）組合せ単位作成部２１は、合計すべき組合せ単位の組合せを「_ｎＣ_ｍ」個だけ決定する。

（Ｐ７）組合せ単位作成部２１は、ｎとｍとの大小関係に基づいて（詳細後記）、合計方法を決定する。例えば、１０個の組合せ単位の候補から、９個の組合せ単位の組合せについて金額を合計する場合（ｎ＝１０、ｍ＝９）、９個の組合せ単位について金額を順次加算するよりは、１０個の組合せ単位の金額の合計額から１個の組合せ単位の金額を減算する方が処理を高速化できる。逆に、１０個の組合せ単位の候補から、２個の組合せ単位の組合せについて金額を合計する場合（ｎ＝１０、ｍ＝２）、単純に２個の組合せ単位について金額を順次加算する方が処理を高速化できる。詳細は、図１９を用いて後記する。
（Ｐ８）組合せ単位作成部２１は、決定した組合せ単位の組合せについて、金額を合計する。
（Ｐ９）組合せ単位突合部２２は、組合せ単位の組合せの合計金額と入金金額を突合する。

（債権請求情報）
図４に沿って、債権請求情報３１を説明する。債権請求情報３１においては、債権ＩＤ欄１０１に記憶された債権ＩＤに関連付けて、債権発生日欄１０２には債権発生日が、金額欄１０３には債権金額が、請求先欄１０４には請求先が、債権発生原因欄１０５には債権発生原因が、継続性欄１０６には継続性フラグが、入金欄１０７には入金フラグが、請求ＩＤ欄１０８には請求ＩＤが、請求日欄１０９には請求日が、支払期日欄１１０には支払期日が、請求金額欄１１１には請求金額が記憶されている。

債権ＩＤ欄１０１の債権ＩＤは、前記したように債権を一意に特定する識別子である。
債権発生日欄１０２の債権発生日は、債権が発生した年月日であり、通常は、商品又は役務の引渡（提供）があった年月日である。
金額欄１０３の債権金額は、債権の金額である。
請求先欄１０４の請求先は、顧客の名称である。
債権発生原因欄１０５の債権発生原因は、債権が発生する原因となった取引を説明する文言であり、請求書１（図１）の摘要欄１ｆの文言と同じである。
継続性欄１０６の継続性フラグ（「継続性情報」に相当する）は、同種の取引が反復的に行われることを示す「継続」又はそれ以外であることを示す「スポット」のうちのいずれかである。なお、「継続」債権には、同種かつ同額の債権だけではなく、債権金額自体は毎回変動するものの、提供される商品又は役務１単位あたりの金額が固定されている同種の債権（例えば電力料金）が含まれるものとする。
入金欄１０７の入金フラグは、入金が終了したことを示す「済」又はそれ以外であることを示す「未」（初期値）のうちのいずれかである。

請求ＩＤ欄１０８の請求ＩＤは、前記したように、請求（請求書）を一意に特定する識別子である。
請求日欄１０９の請求日は、前記したように、請求書１が発行された年月日である。
支払期日欄１１０の支払期日は、前記したように、請求金額が銀行口座に振り込まれるべき期日を示す年月日である。
請求金額欄１１１の請求金額は、前記したように、１つの請求書１に記載されている個々の債権の金額の合計金額である。

債権請求情報３１の１つのレコードは、請求書１（図１）の請求明細１ｉ〜１ｌの１つのレコード（行）に対応している。図４の１〜４行目に注目すると、請求ＩＤ欄１０８、請求日欄１０９、支払期日欄１１０及び請求金額欄１１１には、それぞれ同じ値が記憶されていることが分かる。このことは、１〜４行目の債権「Ｃ０００１」、「Ｃ０００２」、「Ｃ０００３」及び「Ｃ０００４」は、１つの請求書「Ｆ０００１」によってまとめて請求されていることを示している。

（入金情報）
図５（ａ）に沿って、入金情報３２を説明する。入金情報３２においては、入金ＩＤ欄１２１に記憶された入金ＩＤに関連付けて、入金日欄１２２には入金日が、入金金額欄１２３には入金金額が、入金元欄１２４には入金元が記憶されている。
入金ＩＤ欄１２１の入金ＩＤは、請求書１を発行した企業の銀行口座に対して請求先である顧客から資金が入金される事象（単に「入金」とも呼ぶ）を一意に特定する識別子である。
入金日欄１２２の入金日は、入金があった年月日である。
入金金額欄１２３の入金金額は、入金された資金の金額である。入金金額は、必ずしも１つの債権金額又は１つの請求金額に対応しているわけではない。
入金元欄１２４の入金元は、顧客の名称である。

（組合せ単位区分情報）
図５（ｂ）に沿って、組合せ単位区分情報３３を説明する。組合せ単位区分情報３３においては、区分ＩＤ欄１３１に記憶された区分ＩＤに関連付けて、支払月欄１３２には支払月が、継続性欄１３３には継続性フラグが、分割払欄１３４には分割払フラグが、新規発生欄１３５には新規発生フラグが記憶されている。
区分ＩＤ欄１３１の区分ＩＤは、区分を一意に特定する識別子である。区分とは、直ちに後記する、支払月、継続性フラグ、分割払フラグ及び新規発生フラグの組合せである。
支払期日欄１３２の支払月は、支払期日が属する月であり、現在の月である「当月」、現在の月より前の月である「過去月」及び現在の月より後の月である「将来月」のうちのいずれかである。
継続性欄１３３の継続性フラグは、図４の継続性フラグと同じである。

分割払欄１３４の分割払フラグは、１つの取引を複数の回数に分けて支払うことが合意された結果、複数の債権となっていることを示す「分割」、又はそれ以外であることを示す「非分割」のいずれかである。例えば、金額の大きな単発的な１つの取引を想定する。当該取引に係る支払いは、「分割払」とされることが多い。このように分割された複数の債権は、取引の性質上は、「スポット」に属するものである。しかしながら、分割された最初の債権が支払われると、次回以降の債権については、特に個別の判断をすることなく、自動的に支払われることが多い。その意味で、分割払フラグ「分割」が立っている「スポット」債権は、入金条件の観点からは、むしろ「継続」債権に近い。なお、「*」は、『「分割」、「非分割」のいずれでもよい』ことを示している。
新規発生欄１３５の新規発生フラグは、同種の取引が過去に存在しないことを示す「新規」又は存在することを示す「従来」のうちのいずれかである。なお、「*」は、『「従来」、「新規」のいずれでもよい』ことを示している。

図５（ｂ）の例えば２及び３行目のレコードに注目する。いま、ユーザが設定した区分の優先順位が「Ｋ０２→Ｋ０３」であったとする。このことは、同種の取引が過去に存在する「継続」債権のうちでは、その債権が「分割」された債権であるか否かにかかわらず、支払期日が「過去月」であるものよりも、「当月」であるものを先に支払う習慣を顧客が有していることを示す（詳細後記）。
さらに、図５（ｂ）の例えば５及び６行目のレコードに注目する。いま、ユーザが設定した区分の優先順位が「Ｋ０５→Ｋ０６」であったとする。このことは、当月に支払期限が到来する「スポット」債権のうちでは、同種の取引が過去に存在するか否かにかかわらず、「非分割」の債権よりも、「分割」された債権を先に支払う習慣を顧客が有していることを示す（詳細後記）。

（組合せ単位作成方法情報）
図６に沿って、組合せ単位作成方法情報３４を説明する。組合せ単位作成方法情報３４においては、作成方法ＩＤ欄１４１に記憶された作成方法ＩＤに関連付けて、「スポット」債権の扱い欄１４２には「スポット」債権についての組合せ単位作成方法が、「継続」債権の扱い欄１４３には「継続」債権についての組合せ単位作成方法が記憶されている。
作成方法ＩＤ欄１４１の作成方法ＩＤは、組合せ単位作成方法を一意に特定する識別子である。組合せ単位作成方法とは「継続」債権についての組合せ単位作成方法及び「スポット」債権についての組合せ単位作成方法の対（ペア）である。
「スポット」債権の扱い欄１４２の「スポット」債権についての組合せ単位作成方法は、個々の「スポット」債権を組合せ単位に集計するに際しどのような方法が適用されるかを示す。
「継続」債権の扱い欄１４３の「継続」債権についての組合せ単位作成方法は、個々の「継続」債権を組合せ単位に集計するに際しどのような方法が適用されるかを示す。

「スポット」債権についての組合せ単位作成方法と、「継続」債権についての組合せ単位作成方法とが同じであるレコードが存在する（図６の１、２、５及び６行目）。例えば、図６の１行目のレコードにおいては、「スポット」債権の扱い欄１４２及び「継続」債権の扱い欄１４３が１つの欄になっている。このことは、仮に欄を分離しても、両方の欄に全く同じ文言が記憶されることを意味する。「スポット」債権についての組合せ単位作成方法又は「継続」債権についての組合せ単位作成方法のいずれかが存在しないわけではない。

説明の都合上、図７を後回しにして、図８〜図１４を先に説明する。図８〜図１４に記載のＭ０１〜Ｍ０７は、図６のＭ０１〜Ｍ０７とそれぞれ対応している。いま、請求書１が３枚存在し、それぞれの請求書には、２つの「継続」債権及び２つの「スポット」債権についての請求明細が記載されているとする。そして、これら３つの請求書１は、同じ請求先「Ａ社」に対して発行されたものであり、支払期日はいずれの請求書についても「○年３月」であるとする（例えば図８参照）。

図８に注目すると、組合せ単位作成部２１は、個々の債権を集計することなく、１つの債権のみを含む組合せ単位を債権の数（１２個）だけ作成している。このとき、組合せ単位作成部２１は、請求書ごとのまとまりを考慮することはない。組合せ単位作成部２１は、債権の継続性フラグが「スポット」であるか、それとも「継続」であるかを区別していない。このことを、組合せ単位作成方法情報３４（図６）の１行目のレコードは示している。

図９に注目すると、組合せ単位作成部２１は、ユーザが指定した債権については、すべての債権を集計し、１つの組合せ単位としている。このとき、組合せ単位作成部２１は、請求書ごとのまとまりを無視している。なお、「指定された債権」とは、前記の「ルール６」で説明したように、顧客がその入金を予め連絡してきた債権である。一方、組合せ単位作成部２１は、ユーザが指定した債権以外の債権については、集計することなく、１つの債権のみを含む組合せ単位を債権の数だけ作成している。組合せ単位作成部２１は、債権の継続性フラグが「スポット」であるか、それとも「継続」であるかを区別していない。このことを、組合せ単位作成方法情報３４（図６）の２行目のレコードは示している。

図１０に注目すると、組合せ単位作成部２１は、債権の継続性フラグが「スポット」であるかそれとも「継続」であるかを区別している。そのうえで、組合せ単位作成部２１は、「スポット」債権については、債権を集計することなく、１つの債権のみを含む組合せ単位を債権の数（６個）だけ作成している。一方、「継続」債権については、すべてを集計して１つの組合せ単位としている。このことを、組合せ単位作成方法情報３４（図６）の３行目のレコードは示している。

図１１に注目すると、組合せ単位作成部２１は、債権の継続性フラグが「スポット」であるかそれとも「継続」であるかを区別している。そのうえで、組合せ単位作成部２１は、「スポット」債権については、債権を集計することなく、１つの債権のみを含む組合せ単位を債権の数（６個）だけ作成している。一方、「継続」債権については、請求書ごとに債権を集計し、２つの債権を含む組合せ単位を請求書の数（３個）だけ作成している。このことを、組合せ単位作成方法情報３４（図６）の４行目のレコードは示している。

図１２に注目すると、組合せ単位作成部２１は、個々の債権を請求書ごとに組合せ単位に集計し、４つの債権を含む組合せ単位を請求書の数（３個）だけ作成している。組合せ単位作成部２１は、債権の継続性フラグが「スポット」であるか、それとも「継続」であるかを区別していない。このことを、組合せ単位作成方法情報３４（図６）の５行目のレコードは示している。

図１３に注目すると、組合せ単位作成部２１は、ユーザが指定した債権については、すべての債権を集計し、１つの組合せ単位としている。このとき、組合せ単位作成部２１は、請求書ごとのまとまりを無視している。一方、組合せ単位作成部２１は、ユーザが指定した債権以外の債権については、請求書ごとに債権を集計し、３つの債権を含む組合せ単位を請求書の数（３個）だけ作成している。組合せ単位作成部２１は、債権の継続性フラグが「スポット」であるか、それとも「継続」であるかを区別していない。このことを、組合せ単位作成方法情報３４（図６）の６行目のレコードは示している。

図１４に注目すると、組合せ単位作成部２１は、債権の継続性フラグが「スポット」であるか、それとも「継続」であるかを区別している。そのうえで、組合せ単位作成部２１は、「スポット」債権については、請求書ごとに集計し、２つの債権を含む組合せ単位を請求書の数（３個）だけ作成している。一方、「継続」債権については、すべてを集計して１つの組合せ単位としている。このことを、組合せ単位作成方法情報３４（図６）の７行目のレコードは示している。

顧客の習慣が「ルール１」である場合、組合せ単位の作成方法は、「Ｍ０１」（図８）であることが望ましい。
顧客の習慣が「ルール２」である場合、組合せ単位の作成方法は、「Ｍ０５」（図１２）であることが望ましい。
顧客の習慣が「ルール３」である場合、組合せ単位の作成方法は、「Ｍ０４」（図１１）であることが望ましい。
顧客の習慣が「ルール４」である場合、組合せ単位の作成方法は、「Ｍ０３」（図１０）であることが望ましい。
顧客の習慣が「ルール５」である場合、組合せ単位の作成方法は、「Ｍ０３」（図１０）又は「Ｍ０４」（図１１）であることが望ましい。
顧客の習慣が「ルール６」である場合、組合せ単位の作成方法は、「Ｍ０２」（図９）又は「Ｍ０６」（図１３）であることが望ましい。

（組合せ単位情報）
図７に戻って、組合せ単位情報３５を説明する。組合せ単位情報３５においては、単位ＩＤ欄１５１に記憶された単位ＩＤに関連付けて、被集計債権欄１５２には被集計債権が、金額欄１５３には金額が、入金元欄１５４には入金元が、作成方法ＩＤ欄１５５には作成方法ＩＤが、区分ＩＤ欄１５６には区分ＩＤが記憶されている。

単位ＩＤ欄１５１の単位ＩＤは、組合せ単位を一意に特定する識別子である。前記のように、組合せ単位は、１又は複数の債権を集計したものである。
被集計債権欄１５２の被集計債権は、組合せ単位として集計された個々の債権の債権ＩＤである。
金額欄１５３の金額は、組合せ単位の金額、すなわち集計された１又は複数の債権の債権金額の合計である。
入金元欄１５４の入金元は、図４の請求先と同じである。
作成方法ＩＤ欄１５５の作成方法ＩＤは、図６の作成方法ＩＤと同じである。
区分ＩＤ欄１５６の区分ＩＤは、図５（ｂ）の区分ＩＤと同じである。

因みに、組合せ単位作成部２１が、債権請求情報３１（図４）の１〜１２行目の債権について、組合せ単位作成方法「Ｍ０３」（図６の３行目及び図１０参照）によって組合せ単位を作成した結果が、図７の１〜７行目のレコードである。図７の１つのレコードは、１つの組合せ単位に対応している。１、２、４〜７行目に注目すると、組合せ単位作成部２１は、「スポット」債権について、個々の債権を、集計せずにそのまま個別の組合せ単位としていることがわかる。さらに、３行目に注目すると、組合せ単位作成部２１は、「継続」債権について、支払期日が「３月」である請求に含まれる債権をすべて集計して、１つの組合せ単位を作成していることがわかる。

（処理手順）
図１５に沿って、処理手順を説明する。そして、図１５の説明の途中において、必要に応じ、図１６〜図２０を参照する。
ステップＳ２０１において、組合せ単位作成部２１は、検索条件入力画面４１（図１６）を表示する。具体的には、組合せ単位作成部２１は、ユーザが、入力装置１２（又は端末装置３の出力装置。以下同様。）を介して処理開始の指示を入力するのを受け付けると、出力装置１３に、検索条件入力画面４１を表示する。検索条件入力画面４１は、入金情報欄４２、債権請求情報欄４３、組合せ単位の作成方法欄４４、組合せ単位の区分欄４５及び「実行」ボタン４６を有する。

ステップＳ２０２において、組合せ単位作成部２１は、検索条件の入力を受け付ける。具体的には、組合せ単位作成部２１は、第１に、ユーザが、入金元、入金日及び入金金額を、入金情報欄４２の、それぞれ入金元欄４２ａ、入金日欄４２ｂ及び入金金額欄４２ｃに対し、入力装置１２を介して入力するのを受け付ける。金額及び日付は、いくらからいくらまで、又は、いつからいつまでというように、範囲で入力することができる。

組合せ単位作成部２１は、第２に、ユーザが、請求日、支払期日及び組合せ単位数上限（詳細後記）を、債権請求情報欄４３の、それぞれ請求日欄４３ｂ、支払期日欄４３ｃ及び組合せ単位数上限欄４３ｄに対し入力するのを受け付ける。組合せ単位作成部２１は、ユーザが入金元欄４２ａに入力した入金元を、そのままユーザが請求先としても請求先欄４３ａに入力したものとみなす。そして、入力された請求先（＝入金元）を初期値として請求先欄４３ａに表示する。親会社又は支払業務のアウトソース先等が、請求先に替わって入金する場合もある。この場合、ユーザは、当該表示された入金元（＝請求先）を他のものに修正することも可能である。

組合せ単位作成部２１は、第３に、ユーザが、組合せ単位の作成方法の優先順位を、組合せ単位の作成方法欄４４の、組合せ単位の作成方法入力窓４４ａに入力するのを受け付ける。このとき、「説明」ボタン４４ｂが押下されると、組合せ単位作成部２１は、別ウインドウ４４ｃに、組合せ単位作成方法情報３４（図６）を表示し、ユーザの理解を援ける。

組合せ単位作成部２１は、第４に、ユーザが、組合せ単位の区分の優先順位を、組合せ単位の区分欄４５の、組合せ単位の区分入力窓４５ａに入力するのを受け付ける。このとき、「説明」ボタン４５ｂが押下されると、組合せ単位作成部２１は、別ウインドウ４５ｃに、組合せ単位区分情報３３（図５（ｂ））を表示し、ユーザの理解を援ける。
組合せ単位作成部２１は、第５に、ユーザが、「実行」ボタン４６を押下するのを受け付ける。

ステップＳ２０３において、組合せ単位作成部２１は、入金情報を特定する。具体的には、組合せ単位作成部２１は、第１に、ステップＳ２０２の「第１」において受け付けた情報を検索キーとして、入金情報３２（図５（ａ））を検索し、該当するすべてのレコードを取得する。
組合せ単位作成部２１は、第２に、ステップＳ２０３の「第１」において取得したすべてのレコードを出力装置１３に表示し、ユーザがそのうちの１つを選択するのを受け付ける。請求入金マッチング装置２は、以降、当該選択されたレコードの入金金額に一致する組合せ単位の組合せを検索することになる。当該選択されたレコードを、以降、「検索対象入金レコード」と呼ぶことがある。

ステップＳ２０４において、組合せ単位作成部２１は、組合せ単位を作成する。具体的には、組合せ単位作成部２１は、第１に、ステップＳ２０２の「第３」において受け付けた組合せ単位の作成方法の優先順位のうち、１番目の作成方法ＩＤを取得する。いま、受け付けた組合せ単位の作成方法の優先順位が「Ｍ０３→Ｍ０２→Ｍ０１→・・・」であったとする。この場合、「Ｍ０３」が取得されることになる。
組合せ単位作成部２１は、第２に、ステップＳ２０４の「第１」において取得した作成方法ＩＤを検索キーとして、組合せ単位作成方法情報３４（図６）を検索し、「スポット」債権についての組合せ単位作成方法、及び、「継続」債権についての組合せ単位作成方法を取得する。

組合せ単位作成部２１は、第３に、ステップＳ２０２の「第２」において受け付けた情報のうち、請求先、請求日及び支払期日を検索キーとして、債権請求情報３１（図４）を検索し、該当するすべてのレコードを取得する。該当するレコードの数が、組合せ単位数上限（図１６の欄４３ｄ）を超過する場合、組合せ単位作成部２１は、出力装置１３に対して、メッセージを表示する。当該メッセージは、例えば『処理に時間がかかりそうです。作業を継続する場合は、キーボードの「Ｙ」を押下してください。作業を中断する場合は「Ｎ」を押下して下さい』である。そして、組合せ単位作成部２１は、ユーザが「Ｙ」を入力するのを受け付けた場合は、そのまま以下の処理に進み、「Ｎ」を入力するのを受け付けた場合は、処理を終了する（図１５において、フローチャートとしての記載は省略した。）。

組合せ単位作成部２１は、第４に、ステップＳ２０４の「第２」において取得した「スポット」債権についての組合せ単位作成方法、及び、「継続」債権についての組合せ単位作成方法に従って、ステップＳ２０４の「第３」において取得したレコードを集計し、１又は複数の組合せ単位を作成する（図８〜図１４参照）。
組合せ単位作成部２１は、第５に、組合せ単位情報３５（図７）のレコードを、ステップＳ２０４の「第４」において作成した組合せ単位の数だけ作成する。そして、作成した各レコードの、単位ＩＤ欄１５１、被集計債権欄１５２、金額欄１５３、入金元欄１５４及び作成方法ＩＤ欄１５５に、それぞれ、新たに採番した単位ＩＤ、集計された１又は複数の債権の債権ＩＤ、集計された債権の債権金額の合計、入金元、及び、ステップＳ２０４の「第１」において取得した作成方法ＩＤを記憶する。区分ＩＤ欄１５６は空欄としておく。

ステップＳ２０５において、組合せ単位作成部２１は、組合せ単位の区分ＩＤを決定する。具体的には、組合せ単位作成部２１は、第１に、組合せ単位情報３５（図７）の各レコードについて、被集計債権欄１５２の債権ＩＤが特定する債権が、組合せ単位区分情報３３（図５（ｂ））のいずれの区分ＩＤに該当するかを特定する。例えば、組合せ単位作成部２１は、図７のあるレコードの債権ＩＤを検索キーとして、債権請求情報３１（図４）を検索し、以下の４つの調査項目を調べる。

（調査項目１）検索の結果該当する債権請求情報３１のレコード（以降、「区分判定対象レコード」とも呼ぶ）の支払期日が、支払月「当月」、支払月「過去月」及び支払月「将来月」のうちのいずれに属するか。調査結果は、「当月」、「過去月」及び「将来月」のうちのいずれかとなる。
（調査項目２）区分判定対象レコードの継続性フラグが、「スポット」又は「継続」のいずれであるか。調査結果は、「スポット」又は「継続」のいずれかとなる。
（調査項目３）区分判定対象レコードの継続性フラグが「スポット」である場合において、区分判定対象レコードの債権発生原因を有し、かつ、区分判定対象レコードの債権発生日より前の債権発生日を有する他のレコードのうち、継続性フラグが「スポット」であるものが少なくとも１つ存在するか否か。調査結果は、存在する場合を示す「分割」、又は、存在しない場合を示す「非分割」のいずれかとなる。区分判定対象レコードの継続性フラグが「継続」である場合においては、調査結果は、無条件で「非分割」となるものとする。
（調査項目４）区分判定対象レコードの債権発生原因を有し、かつ、区分判定対象レコードの債権発生日より前の債権発生日を有する他のレコードが少なくとも１つ存在するか否か。調査結果は、存在する場合を示す「従来」、又は、存在しない場合を示す「新規」のいずれかとなる。

債権請求情報３１（図４）において、例えば債権発生原因が「商品ａａ販売」であり、継続性フラグが「スポット」であるようなレコードが複数存在する場合もあり得る。このような場合、消耗品等の定番商品の販売が複数回なされたのか、それとも、高額商品の販売が１回だけなされ、支払が「分割」されたのか、が必ずしも明らかにならない。これらの場合を明確に区別するために、例えば、債権請求情報３１は、「分割払欄１０６ｂ」を有し、当該欄には、分割払フラグ「分割」又は「非分割」が記憶されることとしてもよい。そして、「調査項目３」において、組合せ単位作成部２１は、区分判定対象レコードの分割払フラグを取得し、取得した分割払フラグそのものを、「調査結果」としてもよい。

組合せ単位作成部２１は、第２に、４つの調査項目の調査結果の組合せを特定する区分ＩＤを、組合せ単位情報３５の各レコードの区分ＩＤ欄１５６に記憶する。
ステップＳ２０５の「第１」及び「第２」の処理が組合せ単位情報３５のすべてのレコードについて終了した時点で、組合せ単位情報３５は、図７に示した状態（空欄なし）になっている。
なお、組合せ単位情報３５の３行目のレコードのように、被集計債権が複数ある場合、前記したそれぞれの調査結果が１つに決定されない場合がある。このような場合に備え、組合せ単位作成部２１は、例えば以下のように、調査項目ごとに調査結果を強制的に決定する規則を決めておいてもよい。

（調査項目１）個々の債権についての調査結果が、「当月」、「過去月」及び「将来月」のうちのいずれか２つ以上を含む場合は、「当月」→「過去月」→「将来月」の順において最も左にあるものを（代表の）調査結果とする。
（調査項目２）個々の債権についての調査結果が、「スポット」及び「継続」の両者を含む場合は、「継続」を（代表の）調査結果とする。
（調査項目３）個々の債権についての調査結果が、「分割」及び「非分割」の両者を含む場合は、「分割」を（代表の）調査結果とする。
（調査項目４）個々の債権についての調査結果が、「従来」及び「新規」の両者を含む場合は、「従来」を（代表の）調査結果とする。
なお、どの調査結果を代表の調査結果とするかは、ユーザが任意に設定し得る。

ステップＳ２０６において、組合せ単位作成部２１は、組合せ単位の一部を除外する。具体的には、組合せ単位作成部２１は、第１に、ステップＳ２０２の「第４」において受け付けた組合せ単位の区分の優先順位のうち１番目にある区分ＩＤを取得する。いま、受け付けた組合せ単位の区分の優先順位が「Ｋ０１→Ｋ０２→Ｋ０５→・・・」であったとする。この場合、「Ｋ０１」が取得されることになる。そして、組合せ単位作成部２１は、取得した区分ＩＤを検索キーとして、組合せ単位情報３５（図７）のレコードを検索し、該当したレコードをすべて取得する。さらに、取得したレコードを、金額欄１５３の値が大きい順番に並び替える。
組合せ単位作成部２１は、第２に、ステップＳ２０６の「第１」において並び替えたレコードの最初のものから順に、金額欄１５３の値が、検索対象入金レコードの入金金額を超過するものを除外する。除外するとは、並び替えたレコードのうち、そのレコードを削除する、又は無効フラグを立てる等の処理を意味する。当該処理を模式的に示したのが図１７（ａ）である。

組合せ単位作成部２１は、第３に、並び替えたレコード（ステップＳ２０６の「第２」において除外されなかったものに限る）のうち、金額欄１５３が最大であるものと最小であるものを組合せ、これらの金額を合計する。そして、合計金額が、検索対象入金レコードの入金金額を超過する場合は、当該組合せのうち、金額欄１５３が最大であるものを除外する。同様の処理を、金額欄１５３が２番目の大きさであるものと最小であるものの組合せについても実行する（以下繰り返し）。当該処理を模式的に示したのが図１７（ｂ）である。

ステップＳ２０７において、組合せ単位作成部２１は、合計すべき組合せ単位の数の初期値を決定する。具体的には、組合せ単位作成部２１は、ステップＳ２０６の「第１」において並び替えたレコード（ステップＳ２０６の「第２」及び「第３」において除外されなかったものに限る。以下同様。）のうち、１番目からｍ番目（ｍ＝１，２，・・・，ｎ、ｎは一部除外後の組合せ単位の総数）までの金額の合計を計算する。そして当該合計が、検索対象入金レコードの入金金額を超過するような最小の「ｍ」を決定する。当該処理を模式的に示したのが図１８（ａ）である。なお、組合せ単位作成部２１は、最小のｍを起点として、ｍを「１」ずつインクリメントさせて繰り返し処理を行うことになる（詳細後記）。当該処理を模式的に示したのが図１８（ｂ）である。

ステップＳ２０８において、組合せ単位作成部２１は、合計すべき組合せ単位を決定する。具体的には、組合せ単位作成部２１は、ステップＳ２０６の「第１」において並び替えたｎ個のレコード（それぞれが組合せ単位に相当する）のうちから、ｍ個を選ぶ組合せを１又は複数取得する。当該組合せの数は、「_ｎＣ_ｍ」である。

ステップＳ２０９において、組合せ単位作成部２１は、合計方法を決定する。具体的には、組合せ単位作成部２１は、当該処理時点におけるｍの値と、ｎの値との大小関係に応じて、合計方法として、「加算的合計」又は「減算的合計」のいずれかを選択する。組合せ単位作成部２１は、例えば、「ｍ≦ｎ／２」が成立する場合は、「加算的合計」を選択し、それ以外の場合は、「減算的合計」を選択する。現在、ｎ＝１０かつｍ＝２であるとする。この場合、組合せ単位作成部２１は、２個の組合せ単位の金額を合計することになる。この処理を「加算的合計」と呼ぶ。「加算的合計」が選択された場合、後記の処理において、組合せ単位作成部２１は、ｍ個の金額の合計を検索対象入金レコードの入金金額（ターゲット）に一致させる。

ｍが次第にインクリメントし、現在、ｎ＝１０かつｍ＝６となったとする。この場合、組合せ単位作成部２１は、６個の組合せ単位の金額を合計するのではなく、１０個の組合せ単位のうち、選択されない４個の組合せ単位の金額を合計する。この処理を「減算的合計」と呼ぶ。「減算的合計」が選択された場合、後記の処理において、組合せ単位作成部２１は、「ｎ−ｍ」個の組合せ単位の金額の合計を、ｎ個の組合せ単位の金額の合計から検索対象入金レコードの入金金額を減算した値（ターゲット）に一致させる。
これらの処理を模式的に示したのが図１９である。

ステップＳ２１０において、組合せ単位作成部２１は、債権額を合計する。具体的には、組合せ単位作成部２１は、ステップＳ２０８において決定した組合せ単位の金額を、ステップＳ２０９において決定した合計方法によって合計する。ステップＳ２０８において決定した組合せ単位の組合せの数は、一般的には複数となる。例えば、図３のＰ６のように、４個の組合せ単位から３個の組合せ単位を選択する場合においては、組合せ単位の組合せは、_４Ｃ_３＝４だけ存在する（（１）の組合せ〜（４）の組合せ）。

ステップＳ２１１において、組合せ単位突合部２２は、債権額の合計と入金金額を突合する。具体的には、組合せ単位突合部２２は、ステップＳ２１０において合計した組合せ単位のすべての組合せの合計金額と、検索対象入金レコードの入金金額を突合する。
突合せの結果、検索対象入金レコードの入金金額とその合計額が一致するような組合せ単位の組合せが少なくとも１つ存在する場合、組合せ単位突合部２２は、当該組合せを保持する。組合せが存在しない場合も当然存在する。

ステップＳ２１２において、組合せ単位突合部２２は、検索結果出力画面５１（図２０）を表示する。具体的には、組合せ単位突合部２２は、第１に、出力装置１３に、検索結果出力画面５１を表示する。検索結果出力画面５１は、入金情報欄５２、該当債権欄５３、「この検索結果で確定する」ボタン５４及び「他の組合せも検索する」ボタン５５を有する。

組合せ単位突合部２２は、第２に、検索対象入金レコードの入金ＩＤ、入金日、入金金額及び入金元を、入金情報欄５２に表示する。
組合せ単位突合部２２は、第３に、ステップＳ２１１において保持した組合せに含まれる債権についての債権請求情報３１のレコードを、該当債権欄５３に表示する。図２０では、このような組合せは１つだけ存在し、当該組合せは、４つの債権を含んでいる。しかしながら、合計額が同じである、組合せ単位の他の組合せも存在し得る。このとき、組合せ単位作成部２１は、そのような組合せごとに、１又は複数の債権を分けて表示する。

ステップＳ２１３において、組合せ単位突合部２２は、検索を継続するか否かを判断する。具体的には、組合せ単位突合部２２は、ユーザが「この検索結果で確定する」ボタン５４を押下するのを受け付けた場合（ステップＳ２１３“ＮＯ”）、まず、ユーザが、合計額が同じである複数の組合せのうちから１つを選択するのを受け付ける。次に、当該選択された組合せに含まれるすべての債権ＩＤを取得する。そして、取得した債権ＩＤを検索キーとして、債権請求情報３１（図４）を検索し、該当したレコードの入金フラグを「済」として上書き更新し、処理を終了する。
一方、ユーザが「他の組合せも検索する」ボタン５５を押下するのを受け付けた場合（ステップＳ２１３“ＹＥＳ”）、組合せ単位突合部２２は、ｍを「１」だけインクリメントさせて、ステップＳ２０８に戻る。
その後、組合せ単位作成部２１及び組合せ単位突合部２２は、ステップＳ２０８〜Ｓ２１２の処理を繰り返す。「ｍ」が「ｎ＋１」に達すると、組合せ単位突合部２２は、繰り返し処理を抜け出し、処理を終了する。

（ループの考え方）
前記したステップＳ２０８〜Ｓ２１３の処理が終了した時点で、請求入金マッチング装置２は、以下の（１）〜（４）の処理を終了したことになる。当該一連の処理を「内側ループ処理」と呼ぶ。
（１）最も優先順位が先である組合せ単位作成方法によって組合せ単位を作成する。
（２）作成した組合せ単位のうち、最も最初に処理するべき区分を有するものｎ個を特定する。
（３）特定したｎ個の組合せ単位について、そのうちからｍ個、「ｍ＋１」個、「ｍ＋２」個、・・・、ｎ個を選ぶ組合せを作成する。
（４）突合した結果を表示する。

すべてのｍについて「内側ループ処理」が終了すると、組合せ単位作成部２１及び組合せ単位突合部２２は、ステップＳ２０６に戻り、２番目の区分ＩＤ（説明の例では「Ｋ０２」である）を検索キーとしたうえで、ステップＳ２０６〜Ｓ２１３の処理を繰り返す。当該一連の処理を「中間ループ処理」という。
すべての区分ＩＤについて「中間ループ処理」が終了すると、組合せ単位作成部２１及び組合せ単位突合部２２は、ステップＳ２０４に戻り、２番目の作成方法ＩＤ（説明の例では「Ｍ０２」である）を検索キーとしたうえで、ステップＳ２０４〜Ｓ２１３の処理を繰り返す。当該一連の処理を「外側ループ処理」という。組合せ単位作成部２１及び組合せ単位突合部２２は、ユーザが「この検索結果で確定する」ボタン５４を押下するまで、「内側ループ処理」、「中間ループ処理」及び「外側ループ処理」を繰り返す。

（変形例）
支払元の顧客には、１つの請求書１に「スポット」債権及び「継続」債権が混在している場合、当該請求書１に含まれるすべての債権を「継続」債権とみなして処理することが多い。そこで、前記したステップＳ２０４の「第３」の処理を以下のように修正することも可能である。
『ステップＳ２０４において、組合せ単位作成部２１は、第３に、ステップＳ２０２の「第２」において受け付けた情報のうち、請求先、請求日及び支払期日を検索キーとして、債権請求情報３１（図４）を検索し、該当するすべてのレコードを取得する。そして、組合せ単位作成部２１は、取得したレコードのうち同じ請求ＩＤを有する各レコード群に着目し、その群の少なくとも１つのレコードが継続性フラグ「継続」を有する場合は、当該レコード群のすべてのレコードの継続性フラグを「継続」に上書きして更新する。なお、該当するレコードの数が、組合せ単位数上限（図１６の欄４３ｄ）を超過する場合、組合せ単位作成部２１は、出力装置１３に対して、メッセージを表示する。当該メッセージは、例えば“処理に時間がかかりそうです。作業を継続する場合は、キーボードの「Ｙ」を押下してください。作業を中断する場合は「Ｎ」を押下して下さい”である。そして、組合せ単位作成部２１は、ユーザが「Ｙ」を入力するのを受け付けた場合は、そのまま以下の処理に進み、「Ｎ」を入力するのを受け付けた場合は、処理を終了する。』

（実施形態の効果）
本実施形態の請求入金マッチング装置は以下の効果を奏する。
・請求入金マッチング装置は、顧客の組織上の習慣を反映したうえで組合せ単位を作成し、顧客の支払い順序上の習慣を反映したうえで、その順に組合せ単位の組合せと入金金額の突合を実行する。したがって、熟練者でなくとも、迅速に入金金額に突合する債権を取得し得る。
・請求入金マッチング装置は、繰り返し処理を行うことによって、複数の検索結果を表示する。したがって、ユーザは、そのうちから、真に入金されたと思われる債権を最終的に決定できる。
・請求入金マッチング装置は、債権の組合せを直接入金金額と突合するのではなく、複数の債権を集計した組合せ単位の組合せを直接入金金額と突合する。したがって、特に繰り返し処理の速度が速くなる。
・請求入金マッチング装置は、明らかに該当しない組合せ単位を除外することによって、処理速度を向上し得る。
・請求入金マッチング装置は、加算的合計及び減算的合計を使い分けることによって、処理速度を向上し得る。

なお、本発明は前記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、前記した実施例は、本発明を分かり易く説明するために詳細に説明したものであり、必ずしも説明したすべての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
また、前記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウエアで実現してもよい。また、前記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウエアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、又は、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしもすべての制御線や情報線を示しているとは限らない。実際には殆どすべての構成が相互に接続されていると考えてもよい。

１ 請求書
２ 請求入金マッチング装置
３ 端末装置
４ ネットワーク
１１ 中央制御装置（制御部）
１２ 入力装置
１３ 出力装置
１４ 主記憶装置（記憶部）
１５ 補助記憶装置（記憶部）
１６ 通信装置
２１ 組合せ単位作成部
２２ 組合せ単位突合部
３１ 債権請求情報
３２ 入金情報
３３ 組合せ単位区分情報
３４ 組合せ単位作成方法情報
３５ 組合せ単位情報
４１ 検索条件入力画面
５１ 検索結果出力画面

Claims (6)

1. 債権に関連付けて、前記債権が反復する同種の取引に係るものであるか否かを示す継続性情報と、前記債権の請求の単位と、前記請求の支払期日と、が記憶される債権請求情報を格納する記憶部と、
   前記支払期日の前後関係及び前記継続性情報が反復する同種の取引に係るものであることを示すか否かに応じて、前記債権の集合である組合せ単位ごとに定義される区分と、前記区分間の優先順位と、を受け付け、
   前記継続性情報が反復する同種の取引に係るものであることを示す債権を、個々の前記請求ごと、又は、前記支払期日が所定の期間にある複数の請求ごとに集計し、前記継続性情報が反復する同種の取引に係るものであることを示さない債権については、集計せずに個々の前記債権からなる前記組合せ単位を作成し、
   前記作成した組合せ単位のうちから、前記受け付けた優先順位が高い区分の順に、前記作成した組合せ単位の一部を抽出し、前記抽出した組合せ単位のうちから所定の数の前記組合せ単位を含む組合せを作成し、前記作成した組合せに含まれる組合せ単位の合計金額を算出し、入金金額と前記算出した合計金額が一致する前記組合せを検索し、前記検索した結果一致した組合せに含まれる債権を表示する処理を繰り返す制御部と、
   を備えることを特徴とする請求入金マッチング装置。
2. 前記制御部は、
   前記作成した組合せ単位の金額が前記入金金額より大きい場合は、当該組合せ単位を前記抽出する対象から除外すること、
   を特徴とする請求項１に記載の請求入金マッチング装置。
3. 前記制御部は、
   前記作成した組合せ単位のうち金額が最大であるものと、最小であるものとの合計金額が、前記入金金額より大きい場合は、当該金額が最大である組合せ単位を前記抽出する対象から除外すること、
   を特徴とする請求項２に記載の請求入金マッチング装置。
4. 前記制御部は、
   前記組合せ単位の合計金額を算出するに際して、
   前記所定の数と、前記抽出した組合せ単位の数との大小関係に応じて、前記組合せに含まれる組合せ単位の金額を合計するか、それとも、前記抽出した組合せ単位の合計金額から、前記組合せに含まれない組合せ単位の金額を減算するか、のいずれかを実行すること、
   を特徴とする請求項３に記載の請求入金マッチング装置。
5. 記憶部は、
   債権に関連付けて、前記債権が反復する同種の取引に係るものであるか否かを示す継続性情報と、前記債権の請求の単位と、前記請求の支払期日と、が記憶される債権請求情報を格納しており、
   制御部は、
   前記支払期日の前後関係及び前記継続性情報が反復する同種の取引に係るものであることを示すか否かに応じて、前記債権の集合である組合せ単位ごとに定義される区分と、前記区分間の優先順位と、を受け付け、
   前記継続性情報が反復する同種の取引に係るものであることを示す債権を、個々の前記請求ごと、又は、前記支払期日が所定の期間にある複数の請求ごとに集計し、前記継続性情報が反復する同種の取引に係るものであることを示さない債権については、集計せずに個々の前記債権からなる前記組合せ単位を作成し、
   前記作成した組合せ単位のうちから、前記受け付けた優先順位が高い区分の順に、前記作成した組合せ単位の一部を抽出し、前記抽出した組合せ単位のうちから所定の数の前記組合せ単位を含む組合せを作成し、前記作成した組合せに含まれる組合せ単位の合計金額を算出し、入金金額と前記算出した合計金額が一致する前記組合せを検索し、前記検索した結果一致した組合せに含まれる債権を表示する処理を繰り返すこと、
   を特徴とする、前記記憶部及び前記制御部を備える請求入金マッチング装置の請求入金マッチング方法。
6. 請求入金マッチング装置の記憶部に対し、
   債権に関連付けて、前記債権が反復する同種の取引に係るものであるか否かを示す継続性情報と、前記債権の請求の単位と、前記請求の支払期日と、が記憶される債権請求情報を格納させ、
   前記請求入金マッチング装置の制御部に対し、
   前記支払期日の前後関係及び前記継続性情報が反復する同種の取引に係るものであることを示すか否かに応じて、前記債権の集合である組合せ単位ごとに定義される区分と、前記区分間の優先順位と、を受け付け、
   前記継続性情報が反復する同種の取引に係るものであることを示す債権を、個々の前記請求ごと、又は、前記支払期日が所定の期間にある複数の請求ごとに集計し、前記継続性情報が反復する同種の取引に係るものであることを示さない債権については、集計せずに個々の前記債権からなる前記組合せ単位を作成し、
   前記作成した組合せ単位のうちから、前記受け付けた優先順位が高い区分の順に、前記作成した組合せ単位の一部を抽出し、前記抽出した組合せ単位のうちから所定の数の前記組合せ単位を含む組合せを作成し、前記作成した組合せに含まれる組合せ単位の合計金額を算出し、入金金額と前記算出した合計金額が一致する前記組合せを検索し、前記検索した結果一致した組合せに含まれる債権を表示する処理を繰り返す処理を実行させること、
   を特徴とする、前記請求入金マッチング装置を機能させるための請求入金マッチングプログラム。

Images