(57)【要約】【課題】一括入金項目を個別の入金として処理しつつ、支払側と請求側が用いるデータフォーマットの差異に対応できる入金処理プログラムを提供する。【解決手段】本発明に係る入金処理プログラムは、内訳明細データを用いて一括入金データを個別の入金項目に分割する。また、分割を行なう際に、一括入金データが記載している項目と内訳明細データが記載している項目の対応関係を定義するフォーマットマスタを用い、両者を対応付けて整合を取りながら分割を実行する。【選択図】図１
2011118534.tif 000002
【特許請求の範囲】
【請求項１】
入金データをコンピュータに処理させるプログラムであって、
前記コンピュータに、
複数の入金を纏めて入金した入金額を記載した一括入金データを入力するステップと、
前記一括入金データの内訳明細を記載した内訳明細データを入力するステップと、
前記一括入金データが記載している一括入金項目と前記内訳明細データが記載している内訳明細項目の対応関係を定義するフォーマットマスタを入力するステップと、
前記一括入金項目を前記内訳明細項目にしたがって個別の入金項目に分割する分割ステップと、
を実行させ、
前記分割ステップにおいて、前記一括入金データと前記内訳明細データがそれぞれ異なるフォーマットで記載されている場合には、前記コンピュータに、
前記フォーマットマスタを用いて前記一括入金項目と前記内訳明細項目を対応付けながら前記一括入金項目を個別の入金項目に分割させる
ことを特徴とする入金処理プログラム。
【請求項２】
前記フォーマットマスタは、
前記内訳明細項目と前記一括入金項目との対応関係を取引先毎に記述しており、
前記分割ステップでは、前記コンピュータに、
前記フォーマットマスタを用いて前記一括入金項目と取引先毎の前記内訳明細項目の構成を対応付けながら前記一括入金項目を個別の入金項目に分割させ、全ての取引先について共通のフォーマットで入金明細データを作成させる
ことを特徴とする請求項２記載の入金処理プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、入金データをコンピュータに処理させるプログラムに関するものである。
【背景技術】
【０００２】
企業が取引先へ代金を支払う際に、支払先の銀行口座へ代金を入金する場合がある。支払いを受けた企業は、債権回収管理ソフトウェアなどを用いて、入金予定データと実際に振り込まれた実入金データを照合し、これらが相互に合致すれば支払いが完了したものとして債権の消し込みを行う。
【０００３】
ところが実際の支払いでは、振込手数料を削減するなどの目的で、複数の支払いをまとめて一括入金する場合がしばしばある。取引の多い相手先の場合、数百件〜数千件の支払いを一括入金する場合もある。
【０００４】
一般に債権回収管理ソフトウェアは、入金予定データと実入金データが合致しなければ両者の照合に失敗したと判断し、債権の消し込みを行なわない。そのため、上記のように複数の支払いをまとめて一括入金すると、個々の入金予定と一括入金が合致しないことになり、全ての入金予定が未照合となってしまう。
【０００５】
下記特許文献１には、上記のような不都合を回避するため、個々の支払い項目を区別するデータ識別子を付与した支払明細データを支払側が作成して請求側に送信することが記載されている。また、支払明細データまたは請求明細データが記載している項目が取引先毎に異なることに対応するため、データセンターでこれらのデータを取引先毎に適したフォーマットに変換することが記載されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００２−３２６９８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
上記特許文献１に記載の技術では、支払側と請求側はともに自社が用いるフォーマットにしたがって支払明細データや請求明細データを処理する。そのため、両者が用いるフォーマットが異なる場合は、外部のデータセンターを介して支払明細データや請求明細データを送受信しなければならず、コストやセキュリティの観点から課題がある。
【０００８】
本発明は、上記のような課題を解決するためになされたものであり、一括入金項目を個別の入金として処理しつつ、支払側と請求側が用いるデータフォーマットの差異に対応できる入金処理プログラムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明に係る入金処理プログラムは、内訳明細データを用いて一括入金データを個別の入金項目に分割する。また、分割を行なう際に、一括入金データが記載している項目と内訳明細データが記載している項目の対応関係を定義するフォーマットマスタを用い、両者を対応付けて整合を取りながら分割を実行する。
【発明の効果】
【００１０】
本発明に係る入金処理プログラムは、フォーマットマスタを用いて、一括入金データと内訳明細データそれぞれが記載する項目を対応付けながら、一括入金データを個別の入金項目に分割する。これにより、両者の記載項目が異なる場合でも、分割処理の整合を保つことができる。さらには、支払側と請求側の間のみで各データを送受信すればよいので、第三者が介在する必要はなく、コストやセキュリティの観点からも好ましい。
【図面の簡単な説明】
【００１１】
【図１】実施の形態１に係る入金処理プログラム１１０を実行するコンピュータ１００および関連するデータの入出力を示す図である。
【図２】一括入金データ２１０の構成とデータ例を示す図である。
【図３】内訳明細データ２２０の構成とデータ例を示す図である。
【図４】フォーマットマスタ２３０の構成とデータ例を示す図である。
【図５】分割後入金データ２４０の構成とデータ例を示す図である。
【図６】実施の形態２における内訳明細データ２２０のデータ例を示す図である。
【図７】実施の形態２におけるフォーマットマスタ２３０のデータ例を示す図である。
【図８】実施の形態２における分割後入金データ２４０のデータ例を示す図である。
【発明を実施するための形態】
【００１２】
＜実施の形態１＞
図１は、本実施の形態１に係る入金処理プログラム１１０を実行するコンピュータ１００および関連するデータの入出力を示す図である。コンピュータ１００は、企業などが取引先からの支払入金を管理するために用いるコンピュータである。
【００１３】
コンピュータ１００は、一括入金データ２１０と内訳明細データ２２０を入力として受け取り、分割後入金データ２４０を出力する。また必要に応じて、フォーマットマスタ２３０を補助的に用いる。これらのデータは、必要に応じてコンピュータ１００が備える記憶装置に格納される。
【００１４】
コンピュータ１００は、入金処理プログラム１１０を格納するＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）などの記憶装置と、入金処理プログラム１１０を実行するＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）などの演算装置を備える。また、各データを入出力するインタフェース、メモリなどを適宜備える。以下では説明の便宜上、入金処理プログラム１１０を動作主体として説明する場合があるが、実際に入金処理プログラム１１０を実行するのはＣＰＵなどの演算装置であることを付言しておく。
【００１５】
図２は、一括入金データ２１０の構成とデータ例を示す図である。取引先から当該企業が有する銀行口座などに支払入金があると、その銀行から当該企業に対し、入金内容を記載した入金データが送信されてくる。ここでは取引先からの入金の少なくとも一部が一括入金であることを想定し、この入金データのことを一括入金データ２１０として取り扱うことにする。
【００１６】
一括入金データ２１０は、取引先からの支払入金の内容を記載している。各行は１件分の入金内容を表す。ただし一括入金された支払入金に関しては、複数の入金が１件分の入金内容としてまとめて記載されている。
【００１７】
図３は、内訳明細データ２２０の構成とデータ例を示す図である。内訳明細データ２２０は、支払入金を行う取引先が一括入金を行った場合に、その内訳明細を支払先へ通知するためのデータである。ここでは図２の１行目に記載されている「ＡＢ株式会社」から受け取った内訳明細データ２２０の例を示した。
【００１８】
図３のデータ例によれば、図２の１行目における「１，０００，０００」円の一括入金の内訳は、３つの個別入金の合計金額であることが分かる。また、個別の支払入金の取引金額と入金日が判明するので、いずれの個別請求に対して一括入金を行ったのかも同時に分かる。個別請求との対応関係をより明確にするため、個別請求の請求番号などを内訳明細データ２２０に記載してもよい。
【００１９】
図４は、フォーマットマスタ２３０の構成とデータ例を示す図である。フォーマットマスタ２３０は、一括入金データ２１０が記載している一括入金項目と、内訳明細データが記載している内訳明細項目との対応関係を定義するデータである。ここでは図２の１行目に記載されている「ＡＢ株式会社」に関するデータ例を示した。
【００２０】
一般に、取引先が送信する内訳明細データ２２０が記載している項目は、その記載内容については支払先と共通しているものと想定されるが、記載フォーマットが支払先内で使用されているフォーマットとは異なる場合がある。例えば図２〜図３に示すデータ例によれば、「取引金額」が記載されている位置が一括入金データ２１０と内訳明細データ２２０でそれぞれ異なる。そこで入金処理プログラム１１０は、フォーマットマスタ２３０が定義している両者の対応関係を参照して、フォーマットの整合性を維持する。
【００２１】
図４に示すデータ例によれば、内訳明細データ２２０の２番目に記載されている項目「取引金額」は、一括入金データ２１０の４番目に記載されている項目「取引金額」に対応することが分かる。同様に、内訳明細データ２２０の３番目に記載されている項目「取引先」は、一括入金データ２１０の７番目に記載されている項目「取引先」に対応することが分かる。入金処理プログラム１１０は、この対応関係を用いて、一括入金データ２１０と内訳明細データ２２０の整合性を保つ。
【００２２】
図５は、分割後入金データ２４０の構成とデータ例を示す図である。入金処理プログラム１１０は、一括入金データ２１０と内訳明細データ２２０を受け取り、必要に応じてフォーマットマスタ２３０を参照して、一括入金された支払入金を個別の入金に分割し分割後入金データ２４０を出力する。
【００２３】
図５のデータ例では、図２の１行目に記載されている一括入金項目が、図５の１〜３行目に記載されている個別入金項目に分割されている。ここでは「ＸＹ株式会社」については記載を省略した。
【００２４】
以下、入金処理プログラム１１０が入金処理を行う手順を、下記（入金処理プログラム１１０：入金処理ステップ１）〜（入金処理プログラム１１０：入金処理ステップ５）で説明する。
【００２５】
（入金処理プログラム１１０：入金処理ステップ１）
入金処理プログラム１１０は、自社が入金口座を保有する金融機関より一括入金データ２１０を受け取る。また、入金元となる取引先より内訳明細データ２２０を受け取る。例えばネットワークを介して各データを受信してもよいし、各データを格納した記憶媒体を郵送により受け取るなどしてもよい。また、データ形式ではなく紙媒体などで受け取った場合には、オペレータが各データをコンピュータ１００に入力してこれらと同等のデータを作成する。
【００２６】
（入金処理プログラム１１０：入金処理ステップ２）
入金処理プログラム１１０は、内訳明細データ２２０の送信元に対応するフォーマットマスタ２３０内のデータを参照し、一括入金データ２１０と内訳明細データ２２０それぞれが記載している各項目の対応関係を把握する。一括入金データ２１０と内訳明細データ２２０が同じ形式で記載されていることがあらかじめ分かっている場合は、本ステップを省略することができる。
【００２７】
（入金処理プログラム１１０：入金処理ステップ３）
入金処理プログラム１１０は、一括入金データ２１０が記載している一括入金項目のうち、内訳明細データ２２０を受け取った取引先が入金したものを特定する。ここでは図２の１行目に記載されている一括入金項目がこれに相当する。
【００２８】
（入金処理プログラム１１０：入金処理ステップ４）
入金処理プログラム１１０は、ステップ３で特定した一括入金項目を、内訳明細データ２２０を用いて個別の入金項目に分割する。両者の対応付けについては、フォーマットマスタ２３０が記載している対応関係に準じる。ここでは図２の１行目における４番目の項目「１，０００，０００」円を、図３の１〜３行目における２番目の項目「５００，０００」「３００，０００」「１００，０００」の３つに分割することになる。
【００２９】
（入金処理プログラム１１０：入金処理ステップ５）
入金処理プログラム１１０は、ステップ４で分割した一括入金項目を、分割後入金データ２４０のフォーマットに整形する。ここでは「入金明細番号」列を通番で作成して新たに付与する。
以上、入金処理プログラム１１０が入金処理を行う手順を説明した。
【００３０】
本実施の形態１において、一括入金データ２１０と分割後入金データ２４０それぞれのフォーマットは同じでもよい。また、各データのデータフォーマットは各図で説明したものに限られず、取引上の都合などに応じて任意のフォーマットを用いることができる。
【００３１】
また、本実施の形態１において、フォーマットマスタ２３０は、一括入金データ２１０が記載している項目順と内訳明細データ２２０が記載している項目順の対応関係を定義することを説明したが、定義手法はこれに限られない。一括入金データ２１０が記載している項目と内訳明細データ２２０が記載している項目を対応付けすることができれば、その他の定義手法を用いてもよい。
【００３２】
以上のように、本実施の形態１に係る入金処理プログラム１１０は、一括入金データ２１０が記載している一括入金項目を個別の入金項目に分割する。これにより、複数の支払入金がまとめて一括入金された場合でも、個別の入金毎に入金予定データとの照合および消し込み処理を行うことができる。
【００３３】
また、本実施の形態１に係る入金処理プログラム１１０は、フォーマットマスタ２３０を用いて、一括入金データ２１０と内訳明細データ２２０それぞれが記載している項目を対応付けながら分割処理を行う。これにより、一括入金データ２１０のフォーマットと内訳明細データ２２０のフォーマットが異なっている場合でも、分割後入金データ２４０の整合性を保つことができる。
【００３４】
また、本実施の形態１に係る入金処理プログラム１１０は、一括入金データ２１０の分割処理とフォーマットマスタ２３０を用いた対応付け処理をともに行うので、請求側と支払側の間のみで各データを送受信すればよい。これにより、各データを外部の第３者などに送信する必要がなくなるので、外部の第３者のためにフォーマットを整形したり、送信手続きを行ったりするなどの手間が不要となり、コストの観点で有利である。さらには各データが外部の第３者に渡らないので、データセキュリティの観点からも好ましい。
【００３５】
また、本実施の形態１において、一括入金データ２１０が記載している項目順と内訳明細データ２２０が記載している項目順の対応関係をフォーマットマスタ２３０によって定義することにより、フォーマットマスタ２３０の記載を簡潔にできる利点がある。すなわち、単純な数値のみをフォーマットマスタ２３０として定義しておけばよいので、データサイズや形式が簡潔となり、コンピュータ１００にとって処理しやすい。
【００３６】
＜実施の形態２＞
本発明の実施の形態２では、複数の支払元から異なるデータ形式で内訳明細データ２２０を受け取った場合の動作例を説明する。コンピュータ１００と各データの構成、および入金処理プログラム１１０の動作は実施の形態１と同様である。
【００３７】
図６は、本実施の形態２における内訳明細データ２２０のデータ例を示す図である。本実施の形態２では、図２の１行目に記載されている「ＡＢ株式会社」の他に、図２の２行目に記載されている「ＸＹ株式会社」からも内訳明細データ２２０を受け取ったものとする。各会社の内訳明細データ２２０のフォーマットは、それぞれ異なっている。
【００３８】
図７は、本実施の形態２におけるフォーマットマスタ２３０のデータ例を示す図である。本実施の形態２では、「ＸＹ株式会社」から受け取る内訳明細データ２２０と一括入金データ２１０の対応関係を記載するデータが３行目に追加されている。
【００３９】
図８は、本実施の形態２における分割後入金データ２４０のデータ例を示す図である。本実施の形態２では、図２の１〜２行目のデータがそれぞれ図６で説明した内訳明細データ２２０にしたがって分割され、それぞれ３件の個別入金と４件の個別入金として記載されている。最終的に出力される分割後入金データ２４０のフォーマットは、各取引先について共通となる。
【００４０】
以上、本実施の形態２では、複数の支払元から異なるデータ形式で内訳明細データ２２０を受け取った場合の動作例を説明した。
【符号の説明】
【００４１】
１００：コンピュータ、１１０：入金処理プログラム、２１０：一括入金データ、２２０：内訳明細データ、２３０：フォーマットマスタ、２４０：分割後入金データ。
【図１】
2011118534.tif 000003
【図２】
2011118534.tif 000004
【図３】
2011118534.tif 000005
【図４】
2011118534.tif 000006
【図５】
2011118534.tif 000007
【図６】
2011118534.tif 000008
【図７】
2011118534.tif 000009
【図８】
2011118534.tif 000010