JP3872907B2 - クレジット処理装置 - Google Patents
クレジット処理装置 Download PDFInfo
- Publication number
- JP3872907B2 JP3872907B2 JP24970498A JP24970498A JP3872907B2 JP 3872907 B2 JP3872907 B2 JP 3872907B2 JP 24970498 A JP24970498 A JP 24970498A JP 24970498 A JP24970498 A JP 24970498A JP 3872907 B2 JP3872907 B2 JP 3872907B2
- Authority
- JP
- Japan
- Prior art keywords
- payment
- deposit
- record
- sales
- date
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、クレジット売上が成立した商品売買取引に対するクレジットカード会社からの入金を管理する機能を有したクレジット処理装置に関する。
【０００２】
【従来の技術】
従来のクレジット処理装置は、クレジット売上による商品売買取引が成立すると、その取引で使用されたクレジットカードの会社コード別に支払区分，売上日付，売上金額等からなる売上明細データを作成する。そしてこの売上明細データに基づいて即時または日毎のバッチ処理等によりクレジットカード会社に対して掛売金を請求していた。なお、この掛売金の請求方法としては、信用照会はオンラインや電話にてクレジット売上取引時に即時に行い、クレジット会社への請求明細は一定期間分まとめてＭＴ（磁気テーブ）に出力してクレジット会社に送付する方法、オンラインで行う信用照会をもって請求を兼ねるギャザリングという方法などがある。
【０００３】
ところで、クレジット売上が成立した商品売買取引の売上金額は、クレジットカード会社から入金があるまで一時的に店舗経営者が負担することになる。一方、クレジットカード会社からの入金時期は、会社によっても、また支払区分（一括払い，分割払いなど）によっても異なっていて一概には定まらない。そこで店舗側では、現在立て替えている金額（負担金額）がいくらなのか、またその金額の入金予定時期がいつなのか、さらには入金された実績があるか等をクレジット会社別に随時管理している必要があった。
【０００４】
ところが従来のクレジット処理装置は、クレジットカード会社に対して掛売金を請求する処理機能は有していたものの、その請求に対する入金予定や入金実績等を管理する機能はなかった。このため店舗側では、店舗経営者がクレジット売上による商品売買取引で作成されたクレジット伝票を確認したり、煩雑な計算を行ったりして、クレジットカード会社別に、掛売金の額やその入金予定時期及び入金実績等を手作業で管理しているのが実情であった。
【０００５】
【発明が解決しようとする課題】
このように、従来のクレジット処理装置では、クレジットカード会社からの入金予定や入金実績等を管理することができなかったので、それらを管理するための煩雑な手作業が要求されており、迅速かつ正確な管理ができなかった。
【０００６】
本発明はこのような事情に基づいてなされたもので、その目的とするところは、クレジットカード会社からの入金予定や入金実績等を迅速かつ正確に管理することができ、入金管理業務の効率化を図り得るクレジット処理装置を提供しようとするものである。
【０００７】
【課題を解決するための手段】
本願請求項１記載の発明は、クレジットカードの会社コード別でかつクレジット売上の支払区分別に各種取扱期間に対する入金予定日を設定記憶した入金時期テーブルと、会社コード，支払区分，取扱期間，入金予定日及び入金予定額の各項目からなる入金予定レコードを蓄積記憶する入金予定テーブルと、会社コード，支払区分，取扱期間，入金日及び入金実績額の各項目からなる入金実績レコードを蓄積記憶する入金実績テーブルと、クレジット売上による商品売買取引が成立する毎にその取引で使用されたクレジットカードの会社コード，支払区分，売上日付，売上金額からなる売上明細データを作成する売上明細作成手段と、入金時期テーブルを参照して売上明細作成手段により作成された売上明細データ中の会社コードかつ支払区分で売上日付を取扱期間とする入金予定日を取得する入金時期取得手段と、売上明細作成手段により作成された各売上明細データ中の会社コード及び支払区分と入金時期取得手段により当該売上明細データに対して得られた入金予定日とで入金予定テーブルを検索して、会社コード，支払区分及び入金予定日の各データが一致する入金予定レコードが既に記憶されているか否かを調べる入金予定検索手段と、この入金予定検索手段により会社コード，支払区分及び入金予定日の各データが一致する入金予定レコードが記憶されていない場合には、当該売上明細データ中の会社コード，支払区分及び売上金額と入金時期取得手段により当該売上明細データに対して得られた入金予定日及びそれに対する取扱期間とから入金予定レコードを作成して入金予定テーブルに追加し、既に記憶されている場合には、その既に記憶されている入金予定レコードの入金予定額に当該売上明細データ中の売上金額を加算する入金予定額集計手段と、各クレジットカード会社からの入金が発生する毎にその入金を行ったクレジットカード会社の会社コード及び入金額と入金対象の支払区分及び取扱期間とからなる入金明細データを作成する入金明細作成手段と、この入金明細作成手段により作成された各入金明細データ中の会社コード，支払区分及び取扱期間で入金実績テーブルを検索して会社コード，支払区分及び取扱期間の各データが一致する入金実績レコードが既に記憶されているか否かを調べる入金実績検索手段と、この入金実績検索手段により会社コード，支払区分，取扱期間の各データが一致する入金実績レコードが記憶されていない場合には、当該入金明細データ中の会社コード，支払区分，取扱期間，入金日及び入金額で入金実績レコードを作成して入金実績テーブルに追加し、既に記憶されている場合には、その既に記憶されている入金実績レコードの入金実績額に当該入金明細データ中の入金額を加算する入金実績集計手段と、入金予定テーブルに蓄積記憶された入金予定レコードと入金実績テーブルに蓄積記憶された入金実績レコードとから、クレジットカードの会社別に、支払区分別かつ取扱期間別の入金予定額及び入金実績額を表記したレポートを出力するレポート出力手段とを備えたクレジット処理装置である。
【０００８】
本願請求項２記載の発明は、上記請求項１記載のクレジット処理装置に、さらに、入金予定テーブルに蓄積記憶された入金予定レコードと前記入金実績テーブルに蓄積記憶された入金実績レコードとを比較して、会社コード，支払区分及び取扱期間が一致しかつ入金実績額が入金予定額を下回る未入金データを検出する未入金データ検出手段と、この未入金データ検出手段により検出された未入金データの会社コード，支払区分及び取扱期間を当該入金実績額と入金予定額との差額及び当該取扱期間に対する入金予定日とともに出力する未入金データ出力手段とを設けたものである。
本願請求項２記載の発明は、上記請求項２記載のクレジット処理装置において、未入金データ出力手段が、入金予定日からの遅滞状況を併せて出力する機能を有したものである。
【０００９】
【発明の実施の形態】
以下、本発明の一実施の形態を図面を用いて説明する。
図１において、１は本発明に関わるクレジット処理装置を示す。このクレジット処理装置１は、図２に示すように、クレジットカードの会社コード別でかつクレジット売上の支払区分別に各売上時期（取扱開始日〜取扱終了日）に対する入金時期（入金予定日）を予め設定記憶した入金時期テーブル２を設けている。
【００１０】
また、図３に示すように会社コード，支払区分，取扱開始日，取扱終了日，入金予定日，件数及び入金予定額の各項目からなる入金予定レコードを蓄積記憶する入金予定テーブル３と、図４に示すように会社コード，支払区分，取扱開始日，取扱終了日，入金日及び入金実績額の各項目からなる入金実績レコードを蓄積記憶する入金実績テーブル４を設けている。
さらに、図５に示すように会社コード，支払区分，売上日，売上金額及び処理済フラグ（未処理＝０，処理済＝１）の各項目からなる売上明細レコードを蓄積記憶する売上明細テーブル５と、図６に示すように会社コード，支払区分，取扱開始日，取扱終了日，入金日，入金額及び処理済フラグ（未処理＝０，処理済＝１）の各項目からなる入金明細レコードを蓄積記憶する入金明細テーブル６を設けている。
なお、これらのテーブル２〜６は、ＨＤＤ（Hard Disc Drive ）装置等の不揮発性の記憶装置上に形成されている。また、これらのテーブル２〜６のレコードは、詳細には説明しないが、不要となったものから順に自動的あるいは手動で削除され、容量がフルにならないように工夫されている。
【００１１】
しかして、このクレジット処理装置１は、いずれも図示しないＣＰＵ（Central Processing Unit ），ＲＯＭ（Read Only Memory），ＲＡＭ（Random Access Memory），Ｉ／Ｏ（Input/Output）ポート等で構成されるコンピュータを主体として、図１に示すように売上明細作成部７，入金明細作成部８，売上処理部９，入金処理部１０及びレポート出力部１１の各部を形成している。
【００１２】
売上明細作成部７は、インラインまたはオンラインで接続された決済端末（電子式キャッシュレジスタ，ＰＯＳ（Point Of Sales）ターミナル等）１２においてクレジット売上による商品売買取引が成立する毎に、該決済端末１２から送信される取引情報により、その取引で使用されたクレジットカードの会社コード，支払区分，売上日付，売上金額からなる売上明細レコード（処理済フラグ＝０）を作成して、前記売上明細テーブル５に書込む機能を有したもので、売上明細作成手段を構成する。
入金明細作成部８は、キーボードや磁気テーブ読取装置等の入力部１３からの入力により、若しくは通信網１４を介して接続されるクレジットカード会社のホストコンピュータからのオンライン伝送により各クレジットカード会社からの入金が発生する毎に、その入金を行ったクレジットカード会社の会社コード及び入金額と入金対象の支払区分及び売上時期（取扱開始日〜取扱終了日）とからなる入金明細レコード（処理済フラグ＝０）を作成し、前記入金明細テーブル６に書込む機能を有したもので、入金明細作成手段を構成する。
【００１３】
売上処理部９は、内部時計１５によって計時される日時が予め設定された時期になると、入金時期テーブル２を参照して、売上明細テーブル５に蓄積された売上明細データ毎にその会社コードでかつ支払区分の売上日付に対する入金時期（入金予定日）を取得する。そして、入金予定テーブル３を使用して、その売上明細データ中の売上金額を会社コード別かつ支払区分別でかつ入金時期別に集計する機能を有したもので、入金時期取得手段及び入金予定額集計手段を構成する。
【００１４】
その具体的な処理の流れを図７のフローチャートに示す。すなわち売上処理部９は、その処理を開始すると、先ず、ＳＴ（ステップ）１として売上明細テーブル５から先頭の売上明細レコードを読込む。そして、ＳＴ２として該当する売上明細レコードを読込むことができたならば、ＳＴ３としてその読込んだレコードの処理済フラグを調べる。ここで、処理済フラグが“１”にセットされていた場合には、読込んだ売上明細レコードは既に売上処理済なのでＳＴ１３に進み、売上明細テーブル５から次の売上明細レコードを読込む。そしてＳＴ２に戻り、次の売上明細レコードを読込むことができたならば、その読込んだレコードの処理済フラグを調べる。
【００１５】
一方、ＳＴ３にて読込んだレコードの処理済フラグが“０”にリセットされていた場合には、読込んだ売上明細レコードは売上処理前なのでＳＴ４に進み、その売上明細レコードの会社コード，支払区分及び売上日付を検索キーとして入金時期テーブル２を検索する。そして、入金時期テーブル２に会社コード及び支払区分が一致し、売上日付を取扱期間とする入金時期レコードが存在するか否かをチェックする。その結果、ＳＴ５として該当する入金時期レコードが存在しない場合には、入金時期設定テーブル２の設定内容が異常なので、ＳＴ６として設定エラーログデータ（当該売上明細レコードも含めるものとする）を図示しないエラーログファイルに出力する。しかる後、ＳＴ１３に進み、売上明細テーブル５から次の売上明細レコードを読込む。
【００１６】
ＳＴ５にて入金時期テーブル２に該当する入金時期レコードが存在する場合には、ＳＴ７としてその該当する入金時期レコードの会社コード，支払区分，取扱開始日，取扱終了日及び入金予定日を取得する（入金時期取得手段）。
次に、ＳＴ８としてその取得した会社コード，支払区分及び入金予定日を検索キーとして入金予定テーブル３を検索する。そして、入金予定テーブル３に会社コード，支払区分及び入金予定日が一致する入金予定レコードが存在するか否かをチェックする。その結果、ＳＴ９として該当する入金予定レコードが存在しない場合には、ＳＴ１０としてＳＴ７にて取得した会社コード，支払区分，取扱開始日，取扱終了日及び入金予定日の各データと今回読込んだ売上明細レコード中の売上金額（入金予定額）とから入金予定レコード（件数＝１）を作成する。そして、この入金予定レコードを入金予定テーブル３に登録する。この際、入金予定テーブル３内の各入金予定レコードを、会社コードの小さい順かつ支払区分の小さい順でかつ取扱開始日の早い順に並べ変える。これに対し、ＳＴ９にて入金予定テーブル３に該当する入金予定レコードが存在する場合には、ＳＴ１１としてその該当する入金予定レコードの件数に１を加算し、入金予定額に今回読込んだ売上明細レコード中の売上金額を加算する（入金予定額集計手段）。
【００１７】
しかる後、ＳＴ１２として今回読込んだ売上明細レコード中の処理済フラグを“１”にセットしたならばＳＴ１３に進み、売上明細テーブル５から次の売上明細レコードを読込む。
しかして売上処理部９は、ＳＴ２にて売上明細テーブル５から該当する売上明細レコードを読込むことができなくなるまで、ＳＴ３乃至ＳＴ１３の処理を繰返す。そして該当する売上明細レコードを読込むことができなかった時点で、今回の処理を終了する。
【００１８】
入金処理部１０は、内部時計１５によって計時される日時が予め設定された時期になると、入金実績テーブル４を使用して、入金明細テーブル６に蓄積された各入金明細データ中の入金額を会社コード別かつ支払区分別でかつ売上時期（取扱開始日〜取扱終了日）別に集計する機能を有したもので、入金実績集計手段を構成する。
【００１９】
その具体的な処理の流れを図８のフローチャートに示す。すなわち入金処理部１０は、その処理を開始すると、先ず、ＳＴ１として入金明細テーブル６から先頭の入金明細レコードを読込む。そして、ＳＴ２として該当する入金明細レコードを読込むことができたならば、ＳＴ３としてその読込んだレコードの処理済フラグを調べる。ここで、処理済フラグが“１”にセットされていた場合には、読込んだ入金明細レコードは既に入金処理済なのでＳＴ１２に進み、入金明細テーブル６から次の入金明細レコードを読込む。そしてＳＴ２に戻り、次の入金明細レコードを読込むことができたならば、その読込んだレコードの処理済フラグを調べる。
【００２０】
一方、ＳＴ３にて読込んだレコードの処理済フラグが“０”にリセットされていた場合には、読込んだ入金明細レコードは入金処理前なのでＳＴ４に進み、その入金明細レコードの会社コード，支払区分及び取扱期間（取扱開始日〜取扱終了日）を検索キーとして入金時期テーブル２を検索する。そして、入金時期テーブル２に会社コード，支払区分及び取扱期間の一致する入金時期レコードが存在するか否かをチェックする。その結果、ＳＴ５として該当する入金時期レコードが存在しない場合には、入金明細レコードの内容が異常なので、ＳＴ６として入金エラーログデータ（当該入金明細レコードも含めるものとする）を図示しないエラーログファイルに出力する。しかる後、ＳＴ１２に進み、入金明細テーブル６から次の入金明細レコードを読込む。
【００２１】
ＳＴ５にて入金時期テーブル２に該当する入金時期レコードが存在する場合には、ＳＴ７として今回読込んだ入金明細レコードの会社コード，支払区分及び取扱期間を検索キーとして入金実績テーブル４を検索する。そして、入金実績テーブル４に会社コード，支払区分及び取扱期間が一致する入金実績レコードが存在するか否かをチェックする。その結果、ＳＴ８として該当する入金実績レコードが存在しない場合には、ＳＴ９として今回読込んだ入金明細レコードの会社コード，支払区分，取扱開始日，取扱終了日，入金日及び入金額（入金実績額）から入金実績レコードを作成し、入金実績テーブル４に登録する。この際、入金実績テーブル４内の各入金実績レコードを、会社コードの小さい順かつ支払区分の小さい順でかつ取扱期間の早い順に並べ変える。これに対し、ＳＴ８にて入金実績テーブル４に該当する入金実績レコードが存在する場合には、ＳＴ１０としてその該当する入金実績レコードの入金日を今回読込んだ入金明細レコードの入金日に更新するとともに、入金実績額に今回読込んだ入金明細レコードの入金額を加算する（入金実績集計手段）。
【００２２】
しかる後、ＳＴ１１として今回読込んだ入金明細レコード中の処理済フラグを“１”にセットしたならばＳＴ１２に進み、入金明細テーブル６から次の入金明細レコードを読込む。
しかして入金処理部８は、ＳＴ２にて入金明細テーブル６から該当する入金明細レコードを読込むことができなくなるまで、ＳＴ３乃至ＳＴ１２の処理を繰返す。そして該当する入金明細レコードを読込むことができなかった時点で、今回の処理を終了する。
【００２３】
レポート出力部１１は、内部時計１５によって計時される日時が予め設定された時期になると、前記入金予定テーブル３で会社コード別かつ支払区分別でかつ入金予定日別に集計された入金予定額と、前記入金実績テーブル４で会社コード別かつ支払区分別でかつ取扱期間別に集計された入金実績額とを比較して、入金実績額が入金予定額を下回る会社コード，支払区分及び売上時期（取扱期間）の未入金データを検出する。そしてその検出した会社コード，支払区分及び売上時期の未入金データを、当該入金実績額と入金予定額との差額及び当該売上時期に対する入金時期（入金予定日）、さらには入金時期からの遅滞状況を併せて未入金レポート１６（図１３を参照）として印字出力する機能を有したもので、未入金データ検出手段及び未入金データ出力手段を構成する。
【００２４】
その具体的な処理の流れを図９，１０のフローチャートに示す。すなわちレポート出力部１１は、その処理を開始すると、先ず、ＳＴ１としてＡ〜Ｌの１２個のワークメモリエリアを「０」にクリアする。また、ＳＴ２として未入金レポート１６のヘッダ部として、タイトル（未入金レポート），出力日付及び各項目（会社，支払区分，取扱期間，入金予定額，入金額，未入金，入金予定日，入金日及び遅滞）を用紙に印字する。
なお、ワークメモリエリアＡ〜Ｉは、上記各項目「会社」，「支払区分」，「取扱期間」，「入金予定額」，「入金額」，「未入金」，「入金予定日」，「入金日」及び「遅滞」のデータを一時的に格納する。また、ワークメモリエリアＪ，Ｋ及びＬは、上記項目「入金予定額」，「入金額」及び「未入金」の合計データを一時的に格納する。
【００２５】
レポート出力部１１は、次に、ＳＴ３として入金予定テーブル３から先頭の入金予定レコードを読込む。そして、ＳＴ４として該当する入金予定レコードを読込むことができたならば、ＳＴ５としてその読込んだレコードの会社コード，支払区分，取扱期間（取扱開始日〜取扱終了日），入金予定額及び入金予定日をそれぞれワークメモリエリアＡ，Ｂ，Ｃ，Ｄ及びＧにセットする。
【００２６】
次に、ＳＴ６としてその読込んだ入金予定レコードの会社コード，支払区分及び取扱期間を検索キーとして入金実績テーブル４を検索する。そして、入金実績テーブル４に会社コード，支払区分及び取扱期間が一致する入金実績レコードが存在するか否かをチェックする。その結果、ＳＴ７として該当する入金実績レコードが存在しない場合には、ＳＴ８としてワークメモリエリアＥに「０」を、またワークメモリエリアＨに「−」をセットする。これに対し、ＳＴ７にて該当する入金実績レコードが存在する場合には、ＳＴ９としてその入金実績レコードの入金実績額及び入金日を取得し、それぞれワークメモリエリアＥ及びＨにセットする。
【００２７】
次に、ＳＴ１０としてワークメモリエリアＤのデータ，つまりは入金予定額とワークメモリエリアＥのデータ，つまりは入金実績額とを比較して、入金実績額が入金予定額を下回るか否かを判断する（未入金検出手段）。そして、入金実績額が入金予定額以上の場合にはＳＴ１１に進み、入金予定テーブル３から次の入金予定レコードを読込む。そしてＳＴ４に戻り、次の入金予定レコードを読込むことができたならば、ＳＴ５以降の処理を繰返す。
【００２８】
ＳＴ１０にて入金実績額が入金予定額を下回る場合にはＳＴ１２に進み、図示しない名称設定テーブルを参照して、ワークメモリエリアＡ内の会社コードをクレジットカード会社名に、またワークメモリエリアＢ内の支払区分を支払区分名にそれぞれ変換する。また、ＳＴ１３としてワークメモリエリアＤ内の入金予定額からワークメモリエリアＥ内の入金実績額を減じることで未入金額を算出する。そして、ＳＴ１４としてこの未入金額をワークメモリエリアＦにセットする。
【００２９】
次に、ＳＴ１５としてワークメモリエリアＧ内のデータ，つまりは入金予定日と時計部１５にて計時されている当日日付とを比較して、入金予定日を経過しているか否かを判断する。そして入金予定日を経過していない場合には、ＳＴ１６としてワークメモリエリアＩに「−」をセットする。これに対し、入金予定日を経過している場合には、ＳＴ１７として当日日付からワークメモリエリアＧ内の入金予定日を減じることにより遅滞日数を算出する。そして、ＳＴ１８としてこの遅滞日数をワークメモリエリアＩにセットする。
【００３０】
次に、ＳＴ１９としてワークメモリエリアＤのデータ，つまりは入金予定額をワークメモリエリアＪに加算し、ワークメモリエリアＥのデータ，つまりは入金額をワークメモリエリアＫに加算し、ワークメモリエリアＦのデータ，つまりは未入金額をワークメモリエリアＬに加算する。
しかる後、ＳＴ２０として用紙にワークメモリエリアＡ〜Ｉの各データをそれぞれ項目「会社」，「支払区分」，「取扱期間」，「入金予定額」，「入金額」，「未入金」，「入金予定日」，「入金日」及び「遅滞」に対応させて１行で印字する（未入金データ出力手段）。
【００３１】
そして印字後、ＳＴ２１に進み、入金予定テーブル３から次の入金予定レコードを読込む。そしてＳＴ４に戻り、次の入金予定レコードを読込むことができたならば、ＳＴ５以降の処理を繰返す。
【００３２】
しかしてレポート出力部１１は、ＳＴ４にて入金予定テーブル３から該当する入金予定レコードを読込むことができなくなるまで、ＳＴ５以降の処理を繰返す。そして該当する入金予定レコードを読込むことができなかった場合には、用紙に項目「合計」とともにワークメモリエリアＪ，Ｋ及びＬの各データを１行で印字して、今回の処理を終了する。
【００３３】
このように構成された本実施の形態のクレジット処理装置１において、今（３月１日とする）、売上時期テーブル２に図２に示すデータが設定されているものとする。なお、会社コード「０００１」の会社名を「Ｘ会社」、「０００２」の会社名を「Ｙ会社」とし、支払区分「０１」の支払区分名を「一括」，「０２」の支払区分名を「分割」とする。
【００３４】
また、売上明細テーブル５には図５に示す９つの売上明細レコードが格納されているものとする。そうすると、先頭から６番目までの売上明細レコードが売上処理済であり、その売上処理によって、入金予定テーブル３には図３に示す４つの入金予定レコードが登録されている。
さらに、入金明細テーブル６には図６に示す６つの入金明細レコードが格納されているものとする。そうすると、先頭から２番目までの入金明細レコードが入金処理済であるので、これにより入金実績テーブル４には、図４に示す２つの入金実績レコードが登録されている。
【００３５】
この状態で、内部時計１５によって計時される日時が売上処理部９の開始日時になると、売上処理部９が作動する。これにより、売上明細テーブル５に格納された７番目から９番目までの売上明細レコードが順に売上処理される。
先ず、７番目の売上明細レコードは、会社コード「０００２」，支払区分「０１」，売上日「０２０３（２月３日）」であるから、入金時期テーブル２から入金予定日「０２２５（２月２５日）」が取得される。そして入金予定テーブル３には、会社コード「０００２」，支払区分「０１」及び入金予定日「０２２５」の一致するレコードが３番目に存在するので、このレコードの件数に１が加算され、かつ入金予定額に売上金額「１５０００」が加算される。
【００３６】
次に、８番目の売上明細レコードは、会社コード「０００１」，支払区分「０２」，売上日「０２１０（２月１０日）」であるから、入金時期テーブル２から入金予定日「０２２８（２月２８日）」が取得される。そして入金予定テーブル３には、会社コード「０００１」，支払区分「０２」及び入金予定日「０２２８」の一致するレコードが２番目に存在するので、このレコードの件数に１が加算され、かつ入金予定額に売上金額「１００００」が加算される。
【００３７】
次に、９番目の売上明細レコードは、会社コード「０００２」，支払区分「０２」，売上日「０２２５（２月２５日）」であるから、入金時期テーブル２から入金予定日「０３１０（３月１０日）」が取得される。そして、入金予定テーブル３には、会社コード「０００２」，支払区分「０２」及び入金予定日「０３１０」の一致するレコードが存在しないので、会社コード「０００２」，支払区分「０２」，取扱開始日「０２０１」，取扱終了日「０２２９」，入金予定日「０３１０」，件数「１」及び入金予定額「８０００」の入金予定レコードが作成され、この入金予定レコードが入金予定テーブル３の５番目に登録される。
その結果、入金予定テーブル３の内容は、図１１に示すように更新される。
【００３８】
一方、引き続き内部時計１５によって計時される日時が入金処理部１０の開始日時になると、入金処理部１０が作動する。これにより、入金明細テーブル６に格納された３番目から６番目までの入金明細レコードが順に入金処理される。 先ず、３番目の入金明細レコードは、会社コード「０００２」，支払区分「０１」，取扱開始日「０１１０（１月１０日）」，取扱終了日「０２０９（１月１０日）」であり、これと一致する入金実績レコードは入金実績テーブル４に存在しないので、会社コード「０００２」，支払区分「０１」，取扱開始日「０１１０」，取扱終了日「０２０９」，入金日「０２２５」，入金実績額「１００００」の入金実績レコードが作成され、この入金実績レコードが入金実績テーブル４の２番目に登録される。
次に、４番目の入金明細レコードは、会社コード「０００２」，支払区分「０２」，取扱開始日「０１０１（１月１日）」，取扱終了日「０１３１（１月３１日）」であり、これと一致する入金実績レコードは入金実績テーブル４の３番目に存在するので、この３番目の入金実績レコードの入金日が「０２２５」に更新されるとともに、入金実績額に入金額「８０００」が加算される。
【００３９】
次に、５番目の入金明細レコードは、会社コード「０００１」，支払区分「０２」，取扱開始日「０１１６（１月１６日）」，取扱終了日「０２１５（２月１５日）」であり、これと一致する入金実績レコードは入金実績テーブル４に存在しないので、会社コード「０００１」，支払区分「０２」，取扱開始日「０１１６」，取扱終了日「０２１５」，入金日「０２２８」，入金実績額「３００００」の入金実績レコードが作成され、この入金実績レコードが入金実績テーブル４の２番目に登録される。
次に、６番目の入金明細レコードは、会社コード「０００２」，支払区分「０１」，取扱開始日「０１１０」，取扱終了日「０２０９」であり、これと一致する入金実績レコードは入金実績テーブル４の３番目に存在するので、この３番目の入金実績レコードの入金日が「０３０１」に更新されるとともに、入金実績額に入金額「１００００」が加算される。
その結果、入金実績テーブル４の内容は、図１２に示すように更新される。
【００４０】
その後、内部時計１５によって計時される日時がレポート出力部１１の開始日時になると、レポート出力部１１が作動する。これにより、先ず、用紙にレポートヘッダ部が印字される。
【００４１】
次に、入金予定テーブル３における先頭レコードの会社コード「０００１」，支払区分「０１」，取扱期間「０１０１〜０１３１」，入金予定額「１００００」及び入金予定日「０２１０」がワークメモリエリアＡ，Ｂ，Ｃ，Ｄ，Ｇにセットされる。また、入金実績テーブル４には会社コード「０００１」，支払区分「０１」及び取扱期間「０１０１〜０１３１」の一致する入金実績レコードが存在するので、その入金実績レコードの入金実績額「１００００」と入金日「０２１０」がワークメモリエリアＥ，Ｈに格納される。
【００４２】
そしてこの場合、ワークメモリエリアＤの入金予定額とワークメモリエリアＥの入金実績額とは等しいので、次に、入金予定テーブル３における２番目レコードの会社コード「０００１」，支払区分「０２」，取扱期間「０１１６〜０２１５」，入金予定額「４００００」及び入金予定日「０２２８」がワークメモリエリアＡ，Ｂ，Ｃ，Ｄ，Ｇにセットされる。また、入金実績テーブル４には会社コード「０００１」，支払区分「０２」及び取扱期間「０１１６〜０２１５」の一致する入金実績レコードが存在するので、その入金実績レコードの入金実績額「３００００」と入金日「０２２８」がワークメモリエリアＥ，Ｈに格納される。
【００４３】
そしてこの場合、ワークメモリエリアＥの入金実績額はワークメモリエリアＤの入金予定額より少ないので、ワークメモリエリアＡの会社コード「０００１」が会社名「Ｘ会社」に変換されるとともに、ワークメモリエリアＢの支払区分「０２」が支払区分名「分割」に変換される。また、ワークメモリエリアＦに未入金額「１００００」がセットされる。また、ワークメモリエリアＩに遅滞日数「１」がセットされる。さらに、ワークメモリエリアＪ，Ｋ，Ｌにそれぞれ「４００００」，「３００００」，「１００００」がセットされる。しかして、用紙の項目に続く１行目にワークメモリエリアＡ〜Ｉの内容が１行で印字される。
【００４４】
次に、入金予定テーブル３における３番目レコードの会社コード「０００２」，支払区分「０１」，取扱期間「０１１０〜０２０９」，入金予定額「３５０００」及び入金予定日「０２２５」がワークメモリエリアＡ，Ｂ，Ｃ，Ｄ，Ｇにセットされる。また、入金実績テーブル４には会社コード「０００２」，支払区分「０１」及び取扱期間「０１１０〜０２０９」の一致する入金実績レコードが存在するので、その入金実績レコードの入金実績額「２００００」と入金日「０３０１」がワークメモリエリアＥ，Ｈに格納される。
【００４５】
そしてこの場合、ワークメモリエリアＥの入金実績額はワークメモリエリアＤの入金予定額より少ないので、ワークメモリエリアＡの会社コード「０００２」が会社名「Ｙ会社」に変換されるとともに、ワークメモリエリアＢの支払区分「０１」が支払区分名「一括」に変換される。また、ワークメモリエリアＦに未入金額「１５０００」がセットされる。また、ワークメモリエリアＩに遅滞日数「５」がセットされる。さらに、ワークメモリエリアＪ，Ｋ，Ｌの内容がそれぞれ「７５０００」，「５００００」，「２５０００」に更新される。しかして、用紙の項目に続く２行目にワークメモリエリアＡ〜Ｉの内容が１行で印字される。
【００４６】
次に、入金予定テーブル３における４番目レコードの会社コード「０００２」，支払区分「０２」，取扱期間「０１０１〜０１３１」，入金予定額「２００００」及び入金予定日「０２１０」がワークメモリエリアＡ，Ｂ，Ｃ，Ｄ，Ｇにセットされる。また、入金実績テーブル４には会社コード「０００２」，支払区分「０２」及び取扱期間「０１０１〜０１３１」の一致する入金実績レコードが存在するので、その入金実績レコードの入金実績額「２００００」と入金日「０２２５」がワークメモリエリアＥ，Ｈに格納される。
【００４７】
そしてこの場合、ワークメモリエリアＤの入金予定額とワークメモリエリアＥの入金実績額とは等しいので、次に、入金予定テーブル３における５番目レコードの会社コード「０００２」，支払区分「０２」，取扱期間「０２０１〜０２２９」，入金予定額「８０００」及び入金予定日「０３１０」がワークメモリエリアＡ，Ｂ，Ｃ，Ｄ，Ｇにセットされる。また、入金実績テーブル４には会社コード「０００２」，支払区分「０２」及び取扱期間「０２０１〜０２２９」の一致する入金実績レコードが存在しないので、ワークメモリエリアＥ，Ｈにそれぞれデータ「０」，「−」が格納される。
【００４８】
そしてこの場合、ワークメモリエリアＥの入金実績額はワークメモリエリアＤの入金予定額より少ないので、ワークメモリエリアＡの会社コード「０００２」が会社名「Ｙ会社」に変換されるとともに、ワークメモリエリアＢの支払区分「０２」が支払区分名「分割」に変換される。また、ワークメモリエリアＦに未入金額「８０００」がセットされる。また、ワークメモリエリアＩにデータ「−」がセットされる。さらに、ワークメモリエリアＪ，Ｋ，Ｌの内容がそれぞれ「８３０００」，「５００００」，「３３０００」に更新される。しかして、用紙の項目に続く３行目にワークメモリエリアＡ〜Ｉの内容が１行で印字される。
【００４９】
最後に、ワークメモリエリアＪ，Ｋ，Ｌの内容が項目「合計」とともに用紙に印字されて、図１３に示す未入金レポート１６が発行される。
したがって、店舗経営者は、未入金レポート１６の内容から、クレジットカード会社「Ｘ会社」に対しては、１月１６日から２月１５日の期間内に取扱った分割払いのクレジット売上に対する請求４万円のうち１万円が入金されておらず、入金予定日２月２８日から１日遅滞していることがわかる。
【００５０】
同様に、クレジットカード会社「Ｙ会社」に対しては、１月１０日から２月９日の期間内に取扱った一括払いのクレジット売上に対する請求３万５千円のうち１万５千円が入金されておらず、入金予定日２月２５日から５日遅滞していること、及び２月１日から２月２９日の期間内に取扱った分割払いのクレジット売上に対する請求８千円については入金がなく、入金予定日が３月１０日であることがわかる。
【００５１】
このように本実施の形態のクレジット処理装置１を採用することによって、店舗経営者は、クレジット伝票の精査や煩雑な計算を行わなくても、クレジット会社への請求に対する入金予定や入金実績等を迅速かつ正確に管理できるようになる。
【００５２】
なお、本発明は前記一実施の形態に限定されるものではない。
例えば前記一実施の形態では、未入金のある全請求（クレジット会社別かつ支払区分別でかつ取扱期間別）を未入金レポート１６に一括して印字出力したが、例えばクレジット会社毎や支払区分毎に分けて印字出力する機能を持たせ、ユーザが適宜選択できるようにしてもよい。
また、未入金データの出力方法はレポートの印字に限定されるものではなく、レポートと同様な画像をディスプレイに表示させたり、フロッピーディスクなどのコンピュータ読取り可能な記録媒体に記録する方法等が考えられる。
【００５３】
また、前記一実施の形態における入金予定テーブル３及び入金実績テーブル４にそれぞれ蓄積されたデータを印字または表示出力できるようにしても、店舗経営者が両テーブルの内容からクレジット会社への請求に対する入金予定や入金実績等を容易に把握できるので、従来より作業性を大幅に向上できるものである。
【００５４】
【発明の効果】
以上詳述したように本願請求項１記載の発明によれば、クレジットカード会社からの入金予定や入金実績等を迅速かつ正確に管理することができ、入金管理業務の効率化を図り得るクレジット処理装置を提供できる。
また、本願請求項２記載の発明によれば、上記請求項１記載の発明と同等な効果を奏することはもとより、現時点で立て替えている負担金額分についての詳細な情報を容易に取得できる効果を奏し得る。
さらに、本願請求項３記載の発明によれば、その負担金額分についてのより詳細な情報を容易に取得できる効果を奏し得る。
【図面の簡単な説明】
【図１】 本発明の一実施の形態の要部構成を示すブロック図。
【図２】 図１における入金時期テーブルの構成図。
【図３】 図１における入金予定テーブルの構成図。
【図４】 図１における入金実績テーブルの構成図。
【図５】 図１における売上明細テーブルの構成図。
【図６】 図１における入金明細テーブルの構成図。
【図７】 図１における売上処理部で行われる処理の流れを示すフローチャート。
【図８】 図１における入金処理部で行われる処理の流れを示すフローチャート。
【図９】 図１におけるレポート出力部で行われる処理の流れを示すフローチャート。
【図１０】図１におけるレポート出力部で行われる処理の流れを示すフローチャート。
【図１１】図２における入金予定テーブルのデータの他の状態を示す図。
【図１２】図３における入金実績テーブルのデータの他の状態を示す図。
【図１３】未入金レポートの一発行例を示す図。
【符号の説明】
１…クレジット処理装置
２…入金時期テーブル
３…入金予定テーブル
４…入金実績テーブル
５…売上明細テーブル
６…入金明細テーブル
７…売上明細作成部
８…入金明細作成部
９…売上処理部
１０…入金処理部
１１…レポート出力部
１６…未入金レポート
【発明の属する技術分野】
本発明は、クレジット売上が成立した商品売買取引に対するクレジットカード会社からの入金を管理する機能を有したクレジット処理装置に関する。
【０００２】
【従来の技術】
従来のクレジット処理装置は、クレジット売上による商品売買取引が成立すると、その取引で使用されたクレジットカードの会社コード別に支払区分，売上日付，売上金額等からなる売上明細データを作成する。そしてこの売上明細データに基づいて即時または日毎のバッチ処理等によりクレジットカード会社に対して掛売金を請求していた。なお、この掛売金の請求方法としては、信用照会はオンラインや電話にてクレジット売上取引時に即時に行い、クレジット会社への請求明細は一定期間分まとめてＭＴ（磁気テーブ）に出力してクレジット会社に送付する方法、オンラインで行う信用照会をもって請求を兼ねるギャザリングという方法などがある。
【０００３】
ところで、クレジット売上が成立した商品売買取引の売上金額は、クレジットカード会社から入金があるまで一時的に店舗経営者が負担することになる。一方、クレジットカード会社からの入金時期は、会社によっても、また支払区分（一括払い，分割払いなど）によっても異なっていて一概には定まらない。そこで店舗側では、現在立て替えている金額（負担金額）がいくらなのか、またその金額の入金予定時期がいつなのか、さらには入金された実績があるか等をクレジット会社別に随時管理している必要があった。
【０００４】
ところが従来のクレジット処理装置は、クレジットカード会社に対して掛売金を請求する処理機能は有していたものの、その請求に対する入金予定や入金実績等を管理する機能はなかった。このため店舗側では、店舗経営者がクレジット売上による商品売買取引で作成されたクレジット伝票を確認したり、煩雑な計算を行ったりして、クレジットカード会社別に、掛売金の額やその入金予定時期及び入金実績等を手作業で管理しているのが実情であった。
【０００５】
【発明が解決しようとする課題】
このように、従来のクレジット処理装置では、クレジットカード会社からの入金予定や入金実績等を管理することができなかったので、それらを管理するための煩雑な手作業が要求されており、迅速かつ正確な管理ができなかった。
【０００６】
本発明はこのような事情に基づいてなされたもので、その目的とするところは、クレジットカード会社からの入金予定や入金実績等を迅速かつ正確に管理することができ、入金管理業務の効率化を図り得るクレジット処理装置を提供しようとするものである。
【０００７】
【課題を解決するための手段】
本願請求項１記載の発明は、クレジットカードの会社コード別でかつクレジット売上の支払区分別に各種取扱期間に対する入金予定日を設定記憶した入金時期テーブルと、会社コード，支払区分，取扱期間，入金予定日及び入金予定額の各項目からなる入金予定レコードを蓄積記憶する入金予定テーブルと、会社コード，支払区分，取扱期間，入金日及び入金実績額の各項目からなる入金実績レコードを蓄積記憶する入金実績テーブルと、クレジット売上による商品売買取引が成立する毎にその取引で使用されたクレジットカードの会社コード，支払区分，売上日付，売上金額からなる売上明細データを作成する売上明細作成手段と、入金時期テーブルを参照して売上明細作成手段により作成された売上明細データ中の会社コードかつ支払区分で売上日付を取扱期間とする入金予定日を取得する入金時期取得手段と、売上明細作成手段により作成された各売上明細データ中の会社コード及び支払区分と入金時期取得手段により当該売上明細データに対して得られた入金予定日とで入金予定テーブルを検索して、会社コード，支払区分及び入金予定日の各データが一致する入金予定レコードが既に記憶されているか否かを調べる入金予定検索手段と、この入金予定検索手段により会社コード，支払区分及び入金予定日の各データが一致する入金予定レコードが記憶されていない場合には、当該売上明細データ中の会社コード，支払区分及び売上金額と入金時期取得手段により当該売上明細データに対して得られた入金予定日及びそれに対する取扱期間とから入金予定レコードを作成して入金予定テーブルに追加し、既に記憶されている場合には、その既に記憶されている入金予定レコードの入金予定額に当該売上明細データ中の売上金額を加算する入金予定額集計手段と、各クレジットカード会社からの入金が発生する毎にその入金を行ったクレジットカード会社の会社コード及び入金額と入金対象の支払区分及び取扱期間とからなる入金明細データを作成する入金明細作成手段と、この入金明細作成手段により作成された各入金明細データ中の会社コード，支払区分及び取扱期間で入金実績テーブルを検索して会社コード，支払区分及び取扱期間の各データが一致する入金実績レコードが既に記憶されているか否かを調べる入金実績検索手段と、この入金実績検索手段により会社コード，支払区分，取扱期間の各データが一致する入金実績レコードが記憶されていない場合には、当該入金明細データ中の会社コード，支払区分，取扱期間，入金日及び入金額で入金実績レコードを作成して入金実績テーブルに追加し、既に記憶されている場合には、その既に記憶されている入金実績レコードの入金実績額に当該入金明細データ中の入金額を加算する入金実績集計手段と、入金予定テーブルに蓄積記憶された入金予定レコードと入金実績テーブルに蓄積記憶された入金実績レコードとから、クレジットカードの会社別に、支払区分別かつ取扱期間別の入金予定額及び入金実績額を表記したレポートを出力するレポート出力手段とを備えたクレジット処理装置である。
【０００８】
本願請求項２記載の発明は、上記請求項１記載のクレジット処理装置に、さらに、入金予定テーブルに蓄積記憶された入金予定レコードと前記入金実績テーブルに蓄積記憶された入金実績レコードとを比較して、会社コード，支払区分及び取扱期間が一致しかつ入金実績額が入金予定額を下回る未入金データを検出する未入金データ検出手段と、この未入金データ検出手段により検出された未入金データの会社コード，支払区分及び取扱期間を当該入金実績額と入金予定額との差額及び当該取扱期間に対する入金予定日とともに出力する未入金データ出力手段とを設けたものである。
本願請求項２記載の発明は、上記請求項２記載のクレジット処理装置において、未入金データ出力手段が、入金予定日からの遅滞状況を併せて出力する機能を有したものである。
【０００９】
【発明の実施の形態】
以下、本発明の一実施の形態を図面を用いて説明する。
図１において、１は本発明に関わるクレジット処理装置を示す。このクレジット処理装置１は、図２に示すように、クレジットカードの会社コード別でかつクレジット売上の支払区分別に各売上時期（取扱開始日〜取扱終了日）に対する入金時期（入金予定日）を予め設定記憶した入金時期テーブル２を設けている。
【００１０】
また、図３に示すように会社コード，支払区分，取扱開始日，取扱終了日，入金予定日，件数及び入金予定額の各項目からなる入金予定レコードを蓄積記憶する入金予定テーブル３と、図４に示すように会社コード，支払区分，取扱開始日，取扱終了日，入金日及び入金実績額の各項目からなる入金実績レコードを蓄積記憶する入金実績テーブル４を設けている。
さらに、図５に示すように会社コード，支払区分，売上日，売上金額及び処理済フラグ（未処理＝０，処理済＝１）の各項目からなる売上明細レコードを蓄積記憶する売上明細テーブル５と、図６に示すように会社コード，支払区分，取扱開始日，取扱終了日，入金日，入金額及び処理済フラグ（未処理＝０，処理済＝１）の各項目からなる入金明細レコードを蓄積記憶する入金明細テーブル６を設けている。
なお、これらのテーブル２〜６は、ＨＤＤ（Hard Disc Drive ）装置等の不揮発性の記憶装置上に形成されている。また、これらのテーブル２〜６のレコードは、詳細には説明しないが、不要となったものから順に自動的あるいは手動で削除され、容量がフルにならないように工夫されている。
【００１１】
しかして、このクレジット処理装置１は、いずれも図示しないＣＰＵ（Central Processing Unit ），ＲＯＭ（Read Only Memory），ＲＡＭ（Random Access Memory），Ｉ／Ｏ（Input/Output）ポート等で構成されるコンピュータを主体として、図１に示すように売上明細作成部７，入金明細作成部８，売上処理部９，入金処理部１０及びレポート出力部１１の各部を形成している。
【００１２】
売上明細作成部７は、インラインまたはオンラインで接続された決済端末（電子式キャッシュレジスタ，ＰＯＳ（Point Of Sales）ターミナル等）１２においてクレジット売上による商品売買取引が成立する毎に、該決済端末１２から送信される取引情報により、その取引で使用されたクレジットカードの会社コード，支払区分，売上日付，売上金額からなる売上明細レコード（処理済フラグ＝０）を作成して、前記売上明細テーブル５に書込む機能を有したもので、売上明細作成手段を構成する。
入金明細作成部８は、キーボードや磁気テーブ読取装置等の入力部１３からの入力により、若しくは通信網１４を介して接続されるクレジットカード会社のホストコンピュータからのオンライン伝送により各クレジットカード会社からの入金が発生する毎に、その入金を行ったクレジットカード会社の会社コード及び入金額と入金対象の支払区分及び売上時期（取扱開始日〜取扱終了日）とからなる入金明細レコード（処理済フラグ＝０）を作成し、前記入金明細テーブル６に書込む機能を有したもので、入金明細作成手段を構成する。
【００１３】
売上処理部９は、内部時計１５によって計時される日時が予め設定された時期になると、入金時期テーブル２を参照して、売上明細テーブル５に蓄積された売上明細データ毎にその会社コードでかつ支払区分の売上日付に対する入金時期（入金予定日）を取得する。そして、入金予定テーブル３を使用して、その売上明細データ中の売上金額を会社コード別かつ支払区分別でかつ入金時期別に集計する機能を有したもので、入金時期取得手段及び入金予定額集計手段を構成する。
【００１４】
その具体的な処理の流れを図７のフローチャートに示す。すなわち売上処理部９は、その処理を開始すると、先ず、ＳＴ（ステップ）１として売上明細テーブル５から先頭の売上明細レコードを読込む。そして、ＳＴ２として該当する売上明細レコードを読込むことができたならば、ＳＴ３としてその読込んだレコードの処理済フラグを調べる。ここで、処理済フラグが“１”にセットされていた場合には、読込んだ売上明細レコードは既に売上処理済なのでＳＴ１３に進み、売上明細テーブル５から次の売上明細レコードを読込む。そしてＳＴ２に戻り、次の売上明細レコードを読込むことができたならば、その読込んだレコードの処理済フラグを調べる。
【００１５】
一方、ＳＴ３にて読込んだレコードの処理済フラグが“０”にリセットされていた場合には、読込んだ売上明細レコードは売上処理前なのでＳＴ４に進み、その売上明細レコードの会社コード，支払区分及び売上日付を検索キーとして入金時期テーブル２を検索する。そして、入金時期テーブル２に会社コード及び支払区分が一致し、売上日付を取扱期間とする入金時期レコードが存在するか否かをチェックする。その結果、ＳＴ５として該当する入金時期レコードが存在しない場合には、入金時期設定テーブル２の設定内容が異常なので、ＳＴ６として設定エラーログデータ（当該売上明細レコードも含めるものとする）を図示しないエラーログファイルに出力する。しかる後、ＳＴ１３に進み、売上明細テーブル５から次の売上明細レコードを読込む。
【００１６】
ＳＴ５にて入金時期テーブル２に該当する入金時期レコードが存在する場合には、ＳＴ７としてその該当する入金時期レコードの会社コード，支払区分，取扱開始日，取扱終了日及び入金予定日を取得する（入金時期取得手段）。
次に、ＳＴ８としてその取得した会社コード，支払区分及び入金予定日を検索キーとして入金予定テーブル３を検索する。そして、入金予定テーブル３に会社コード，支払区分及び入金予定日が一致する入金予定レコードが存在するか否かをチェックする。その結果、ＳＴ９として該当する入金予定レコードが存在しない場合には、ＳＴ１０としてＳＴ７にて取得した会社コード，支払区分，取扱開始日，取扱終了日及び入金予定日の各データと今回読込んだ売上明細レコード中の売上金額（入金予定額）とから入金予定レコード（件数＝１）を作成する。そして、この入金予定レコードを入金予定テーブル３に登録する。この際、入金予定テーブル３内の各入金予定レコードを、会社コードの小さい順かつ支払区分の小さい順でかつ取扱開始日の早い順に並べ変える。これに対し、ＳＴ９にて入金予定テーブル３に該当する入金予定レコードが存在する場合には、ＳＴ１１としてその該当する入金予定レコードの件数に１を加算し、入金予定額に今回読込んだ売上明細レコード中の売上金額を加算する（入金予定額集計手段）。
【００１７】
しかる後、ＳＴ１２として今回読込んだ売上明細レコード中の処理済フラグを“１”にセットしたならばＳＴ１３に進み、売上明細テーブル５から次の売上明細レコードを読込む。
しかして売上処理部９は、ＳＴ２にて売上明細テーブル５から該当する売上明細レコードを読込むことができなくなるまで、ＳＴ３乃至ＳＴ１３の処理を繰返す。そして該当する売上明細レコードを読込むことができなかった時点で、今回の処理を終了する。
【００１８】
入金処理部１０は、内部時計１５によって計時される日時が予め設定された時期になると、入金実績テーブル４を使用して、入金明細テーブル６に蓄積された各入金明細データ中の入金額を会社コード別かつ支払区分別でかつ売上時期（取扱開始日〜取扱終了日）別に集計する機能を有したもので、入金実績集計手段を構成する。
【００１９】
その具体的な処理の流れを図８のフローチャートに示す。すなわち入金処理部１０は、その処理を開始すると、先ず、ＳＴ１として入金明細テーブル６から先頭の入金明細レコードを読込む。そして、ＳＴ２として該当する入金明細レコードを読込むことができたならば、ＳＴ３としてその読込んだレコードの処理済フラグを調べる。ここで、処理済フラグが“１”にセットされていた場合には、読込んだ入金明細レコードは既に入金処理済なのでＳＴ１２に進み、入金明細テーブル６から次の入金明細レコードを読込む。そしてＳＴ２に戻り、次の入金明細レコードを読込むことができたならば、その読込んだレコードの処理済フラグを調べる。
【００２０】
一方、ＳＴ３にて読込んだレコードの処理済フラグが“０”にリセットされていた場合には、読込んだ入金明細レコードは入金処理前なのでＳＴ４に進み、その入金明細レコードの会社コード，支払区分及び取扱期間（取扱開始日〜取扱終了日）を検索キーとして入金時期テーブル２を検索する。そして、入金時期テーブル２に会社コード，支払区分及び取扱期間の一致する入金時期レコードが存在するか否かをチェックする。その結果、ＳＴ５として該当する入金時期レコードが存在しない場合には、入金明細レコードの内容が異常なので、ＳＴ６として入金エラーログデータ（当該入金明細レコードも含めるものとする）を図示しないエラーログファイルに出力する。しかる後、ＳＴ１２に進み、入金明細テーブル６から次の入金明細レコードを読込む。
【００２１】
ＳＴ５にて入金時期テーブル２に該当する入金時期レコードが存在する場合には、ＳＴ７として今回読込んだ入金明細レコードの会社コード，支払区分及び取扱期間を検索キーとして入金実績テーブル４を検索する。そして、入金実績テーブル４に会社コード，支払区分及び取扱期間が一致する入金実績レコードが存在するか否かをチェックする。その結果、ＳＴ８として該当する入金実績レコードが存在しない場合には、ＳＴ９として今回読込んだ入金明細レコードの会社コード，支払区分，取扱開始日，取扱終了日，入金日及び入金額（入金実績額）から入金実績レコードを作成し、入金実績テーブル４に登録する。この際、入金実績テーブル４内の各入金実績レコードを、会社コードの小さい順かつ支払区分の小さい順でかつ取扱期間の早い順に並べ変える。これに対し、ＳＴ８にて入金実績テーブル４に該当する入金実績レコードが存在する場合には、ＳＴ１０としてその該当する入金実績レコードの入金日を今回読込んだ入金明細レコードの入金日に更新するとともに、入金実績額に今回読込んだ入金明細レコードの入金額を加算する（入金実績集計手段）。
【００２２】
しかる後、ＳＴ１１として今回読込んだ入金明細レコード中の処理済フラグを“１”にセットしたならばＳＴ１２に進み、入金明細テーブル６から次の入金明細レコードを読込む。
しかして入金処理部８は、ＳＴ２にて入金明細テーブル６から該当する入金明細レコードを読込むことができなくなるまで、ＳＴ３乃至ＳＴ１２の処理を繰返す。そして該当する入金明細レコードを読込むことができなかった時点で、今回の処理を終了する。
【００２３】
レポート出力部１１は、内部時計１５によって計時される日時が予め設定された時期になると、前記入金予定テーブル３で会社コード別かつ支払区分別でかつ入金予定日別に集計された入金予定額と、前記入金実績テーブル４で会社コード別かつ支払区分別でかつ取扱期間別に集計された入金実績額とを比較して、入金実績額が入金予定額を下回る会社コード，支払区分及び売上時期（取扱期間）の未入金データを検出する。そしてその検出した会社コード，支払区分及び売上時期の未入金データを、当該入金実績額と入金予定額との差額及び当該売上時期に対する入金時期（入金予定日）、さらには入金時期からの遅滞状況を併せて未入金レポート１６（図１３を参照）として印字出力する機能を有したもので、未入金データ検出手段及び未入金データ出力手段を構成する。
【００２４】
その具体的な処理の流れを図９，１０のフローチャートに示す。すなわちレポート出力部１１は、その処理を開始すると、先ず、ＳＴ１としてＡ〜Ｌの１２個のワークメモリエリアを「０」にクリアする。また、ＳＴ２として未入金レポート１６のヘッダ部として、タイトル（未入金レポート），出力日付及び各項目（会社，支払区分，取扱期間，入金予定額，入金額，未入金，入金予定日，入金日及び遅滞）を用紙に印字する。
なお、ワークメモリエリアＡ〜Ｉは、上記各項目「会社」，「支払区分」，「取扱期間」，「入金予定額」，「入金額」，「未入金」，「入金予定日」，「入金日」及び「遅滞」のデータを一時的に格納する。また、ワークメモリエリアＪ，Ｋ及びＬは、上記項目「入金予定額」，「入金額」及び「未入金」の合計データを一時的に格納する。
【００２５】
レポート出力部１１は、次に、ＳＴ３として入金予定テーブル３から先頭の入金予定レコードを読込む。そして、ＳＴ４として該当する入金予定レコードを読込むことができたならば、ＳＴ５としてその読込んだレコードの会社コード，支払区分，取扱期間（取扱開始日〜取扱終了日），入金予定額及び入金予定日をそれぞれワークメモリエリアＡ，Ｂ，Ｃ，Ｄ及びＧにセットする。
【００２６】
次に、ＳＴ６としてその読込んだ入金予定レコードの会社コード，支払区分及び取扱期間を検索キーとして入金実績テーブル４を検索する。そして、入金実績テーブル４に会社コード，支払区分及び取扱期間が一致する入金実績レコードが存在するか否かをチェックする。その結果、ＳＴ７として該当する入金実績レコードが存在しない場合には、ＳＴ８としてワークメモリエリアＥに「０」を、またワークメモリエリアＨに「−」をセットする。これに対し、ＳＴ７にて該当する入金実績レコードが存在する場合には、ＳＴ９としてその入金実績レコードの入金実績額及び入金日を取得し、それぞれワークメモリエリアＥ及びＨにセットする。
【００２７】
次に、ＳＴ１０としてワークメモリエリアＤのデータ，つまりは入金予定額とワークメモリエリアＥのデータ，つまりは入金実績額とを比較して、入金実績額が入金予定額を下回るか否かを判断する（未入金検出手段）。そして、入金実績額が入金予定額以上の場合にはＳＴ１１に進み、入金予定テーブル３から次の入金予定レコードを読込む。そしてＳＴ４に戻り、次の入金予定レコードを読込むことができたならば、ＳＴ５以降の処理を繰返す。
【００２８】
ＳＴ１０にて入金実績額が入金予定額を下回る場合にはＳＴ１２に進み、図示しない名称設定テーブルを参照して、ワークメモリエリアＡ内の会社コードをクレジットカード会社名に、またワークメモリエリアＢ内の支払区分を支払区分名にそれぞれ変換する。また、ＳＴ１３としてワークメモリエリアＤ内の入金予定額からワークメモリエリアＥ内の入金実績額を減じることで未入金額を算出する。そして、ＳＴ１４としてこの未入金額をワークメモリエリアＦにセットする。
【００２９】
次に、ＳＴ１５としてワークメモリエリアＧ内のデータ，つまりは入金予定日と時計部１５にて計時されている当日日付とを比較して、入金予定日を経過しているか否かを判断する。そして入金予定日を経過していない場合には、ＳＴ１６としてワークメモリエリアＩに「−」をセットする。これに対し、入金予定日を経過している場合には、ＳＴ１７として当日日付からワークメモリエリアＧ内の入金予定日を減じることにより遅滞日数を算出する。そして、ＳＴ１８としてこの遅滞日数をワークメモリエリアＩにセットする。
【００３０】
次に、ＳＴ１９としてワークメモリエリアＤのデータ，つまりは入金予定額をワークメモリエリアＪに加算し、ワークメモリエリアＥのデータ，つまりは入金額をワークメモリエリアＫに加算し、ワークメモリエリアＦのデータ，つまりは未入金額をワークメモリエリアＬに加算する。
しかる後、ＳＴ２０として用紙にワークメモリエリアＡ〜Ｉの各データをそれぞれ項目「会社」，「支払区分」，「取扱期間」，「入金予定額」，「入金額」，「未入金」，「入金予定日」，「入金日」及び「遅滞」に対応させて１行で印字する（未入金データ出力手段）。
【００３１】
そして印字後、ＳＴ２１に進み、入金予定テーブル３から次の入金予定レコードを読込む。そしてＳＴ４に戻り、次の入金予定レコードを読込むことができたならば、ＳＴ５以降の処理を繰返す。
【００３２】
しかしてレポート出力部１１は、ＳＴ４にて入金予定テーブル３から該当する入金予定レコードを読込むことができなくなるまで、ＳＴ５以降の処理を繰返す。そして該当する入金予定レコードを読込むことができなかった場合には、用紙に項目「合計」とともにワークメモリエリアＪ，Ｋ及びＬの各データを１行で印字して、今回の処理を終了する。
【００３３】
このように構成された本実施の形態のクレジット処理装置１において、今（３月１日とする）、売上時期テーブル２に図２に示すデータが設定されているものとする。なお、会社コード「０００１」の会社名を「Ｘ会社」、「０００２」の会社名を「Ｙ会社」とし、支払区分「０１」の支払区分名を「一括」，「０２」の支払区分名を「分割」とする。
【００３４】
また、売上明細テーブル５には図５に示す９つの売上明細レコードが格納されているものとする。そうすると、先頭から６番目までの売上明細レコードが売上処理済であり、その売上処理によって、入金予定テーブル３には図３に示す４つの入金予定レコードが登録されている。
さらに、入金明細テーブル６には図６に示す６つの入金明細レコードが格納されているものとする。そうすると、先頭から２番目までの入金明細レコードが入金処理済であるので、これにより入金実績テーブル４には、図４に示す２つの入金実績レコードが登録されている。
【００３５】
この状態で、内部時計１５によって計時される日時が売上処理部９の開始日時になると、売上処理部９が作動する。これにより、売上明細テーブル５に格納された７番目から９番目までの売上明細レコードが順に売上処理される。
先ず、７番目の売上明細レコードは、会社コード「０００２」，支払区分「０１」，売上日「０２０３（２月３日）」であるから、入金時期テーブル２から入金予定日「０２２５（２月２５日）」が取得される。そして入金予定テーブル３には、会社コード「０００２」，支払区分「０１」及び入金予定日「０２２５」の一致するレコードが３番目に存在するので、このレコードの件数に１が加算され、かつ入金予定額に売上金額「１５０００」が加算される。
【００３６】
次に、８番目の売上明細レコードは、会社コード「０００１」，支払区分「０２」，売上日「０２１０（２月１０日）」であるから、入金時期テーブル２から入金予定日「０２２８（２月２８日）」が取得される。そして入金予定テーブル３には、会社コード「０００１」，支払区分「０２」及び入金予定日「０２２８」の一致するレコードが２番目に存在するので、このレコードの件数に１が加算され、かつ入金予定額に売上金額「１００００」が加算される。
【００３７】
次に、９番目の売上明細レコードは、会社コード「０００２」，支払区分「０２」，売上日「０２２５（２月２５日）」であるから、入金時期テーブル２から入金予定日「０３１０（３月１０日）」が取得される。そして、入金予定テーブル３には、会社コード「０００２」，支払区分「０２」及び入金予定日「０３１０」の一致するレコードが存在しないので、会社コード「０００２」，支払区分「０２」，取扱開始日「０２０１」，取扱終了日「０２２９」，入金予定日「０３１０」，件数「１」及び入金予定額「８０００」の入金予定レコードが作成され、この入金予定レコードが入金予定テーブル３の５番目に登録される。
その結果、入金予定テーブル３の内容は、図１１に示すように更新される。
【００３８】
一方、引き続き内部時計１５によって計時される日時が入金処理部１０の開始日時になると、入金処理部１０が作動する。これにより、入金明細テーブル６に格納された３番目から６番目までの入金明細レコードが順に入金処理される。 先ず、３番目の入金明細レコードは、会社コード「０００２」，支払区分「０１」，取扱開始日「０１１０（１月１０日）」，取扱終了日「０２０９（１月１０日）」であり、これと一致する入金実績レコードは入金実績テーブル４に存在しないので、会社コード「０００２」，支払区分「０１」，取扱開始日「０１１０」，取扱終了日「０２０９」，入金日「０２２５」，入金実績額「１００００」の入金実績レコードが作成され、この入金実績レコードが入金実績テーブル４の２番目に登録される。
次に、４番目の入金明細レコードは、会社コード「０００２」，支払区分「０２」，取扱開始日「０１０１（１月１日）」，取扱終了日「０１３１（１月３１日）」であり、これと一致する入金実績レコードは入金実績テーブル４の３番目に存在するので、この３番目の入金実績レコードの入金日が「０２２５」に更新されるとともに、入金実績額に入金額「８０００」が加算される。
【００３９】
次に、５番目の入金明細レコードは、会社コード「０００１」，支払区分「０２」，取扱開始日「０１１６（１月１６日）」，取扱終了日「０２１５（２月１５日）」であり、これと一致する入金実績レコードは入金実績テーブル４に存在しないので、会社コード「０００１」，支払区分「０２」，取扱開始日「０１１６」，取扱終了日「０２１５」，入金日「０２２８」，入金実績額「３００００」の入金実績レコードが作成され、この入金実績レコードが入金実績テーブル４の２番目に登録される。
次に、６番目の入金明細レコードは、会社コード「０００２」，支払区分「０１」，取扱開始日「０１１０」，取扱終了日「０２０９」であり、これと一致する入金実績レコードは入金実績テーブル４の３番目に存在するので、この３番目の入金実績レコードの入金日が「０３０１」に更新されるとともに、入金実績額に入金額「１００００」が加算される。
その結果、入金実績テーブル４の内容は、図１２に示すように更新される。
【００４０】
その後、内部時計１５によって計時される日時がレポート出力部１１の開始日時になると、レポート出力部１１が作動する。これにより、先ず、用紙にレポートヘッダ部が印字される。
【００４１】
次に、入金予定テーブル３における先頭レコードの会社コード「０００１」，支払区分「０１」，取扱期間「０１０１〜０１３１」，入金予定額「１００００」及び入金予定日「０２１０」がワークメモリエリアＡ，Ｂ，Ｃ，Ｄ，Ｇにセットされる。また、入金実績テーブル４には会社コード「０００１」，支払区分「０１」及び取扱期間「０１０１〜０１３１」の一致する入金実績レコードが存在するので、その入金実績レコードの入金実績額「１００００」と入金日「０２１０」がワークメモリエリアＥ，Ｈに格納される。
【００４２】
そしてこの場合、ワークメモリエリアＤの入金予定額とワークメモリエリアＥの入金実績額とは等しいので、次に、入金予定テーブル３における２番目レコードの会社コード「０００１」，支払区分「０２」，取扱期間「０１１６〜０２１５」，入金予定額「４００００」及び入金予定日「０２２８」がワークメモリエリアＡ，Ｂ，Ｃ，Ｄ，Ｇにセットされる。また、入金実績テーブル４には会社コード「０００１」，支払区分「０２」及び取扱期間「０１１６〜０２１５」の一致する入金実績レコードが存在するので、その入金実績レコードの入金実績額「３００００」と入金日「０２２８」がワークメモリエリアＥ，Ｈに格納される。
【００４３】
そしてこの場合、ワークメモリエリアＥの入金実績額はワークメモリエリアＤの入金予定額より少ないので、ワークメモリエリアＡの会社コード「０００１」が会社名「Ｘ会社」に変換されるとともに、ワークメモリエリアＢの支払区分「０２」が支払区分名「分割」に変換される。また、ワークメモリエリアＦに未入金額「１００００」がセットされる。また、ワークメモリエリアＩに遅滞日数「１」がセットされる。さらに、ワークメモリエリアＪ，Ｋ，Ｌにそれぞれ「４００００」，「３００００」，「１００００」がセットされる。しかして、用紙の項目に続く１行目にワークメモリエリアＡ〜Ｉの内容が１行で印字される。
【００４４】
次に、入金予定テーブル３における３番目レコードの会社コード「０００２」，支払区分「０１」，取扱期間「０１１０〜０２０９」，入金予定額「３５０００」及び入金予定日「０２２５」がワークメモリエリアＡ，Ｂ，Ｃ，Ｄ，Ｇにセットされる。また、入金実績テーブル４には会社コード「０００２」，支払区分「０１」及び取扱期間「０１１０〜０２０９」の一致する入金実績レコードが存在するので、その入金実績レコードの入金実績額「２００００」と入金日「０３０１」がワークメモリエリアＥ，Ｈに格納される。
【００４５】
そしてこの場合、ワークメモリエリアＥの入金実績額はワークメモリエリアＤの入金予定額より少ないので、ワークメモリエリアＡの会社コード「０００２」が会社名「Ｙ会社」に変換されるとともに、ワークメモリエリアＢの支払区分「０１」が支払区分名「一括」に変換される。また、ワークメモリエリアＦに未入金額「１５０００」がセットされる。また、ワークメモリエリアＩに遅滞日数「５」がセットされる。さらに、ワークメモリエリアＪ，Ｋ，Ｌの内容がそれぞれ「７５０００」，「５００００」，「２５０００」に更新される。しかして、用紙の項目に続く２行目にワークメモリエリアＡ〜Ｉの内容が１行で印字される。
【００４６】
次に、入金予定テーブル３における４番目レコードの会社コード「０００２」，支払区分「０２」，取扱期間「０１０１〜０１３１」，入金予定額「２００００」及び入金予定日「０２１０」がワークメモリエリアＡ，Ｂ，Ｃ，Ｄ，Ｇにセットされる。また、入金実績テーブル４には会社コード「０００２」，支払区分「０２」及び取扱期間「０１０１〜０１３１」の一致する入金実績レコードが存在するので、その入金実績レコードの入金実績額「２００００」と入金日「０２２５」がワークメモリエリアＥ，Ｈに格納される。
【００４７】
そしてこの場合、ワークメモリエリアＤの入金予定額とワークメモリエリアＥの入金実績額とは等しいので、次に、入金予定テーブル３における５番目レコードの会社コード「０００２」，支払区分「０２」，取扱期間「０２０１〜０２２９」，入金予定額「８０００」及び入金予定日「０３１０」がワークメモリエリアＡ，Ｂ，Ｃ，Ｄ，Ｇにセットされる。また、入金実績テーブル４には会社コード「０００２」，支払区分「０２」及び取扱期間「０２０１〜０２２９」の一致する入金実績レコードが存在しないので、ワークメモリエリアＥ，Ｈにそれぞれデータ「０」，「−」が格納される。
【００４８】
そしてこの場合、ワークメモリエリアＥの入金実績額はワークメモリエリアＤの入金予定額より少ないので、ワークメモリエリアＡの会社コード「０００２」が会社名「Ｙ会社」に変換されるとともに、ワークメモリエリアＢの支払区分「０２」が支払区分名「分割」に変換される。また、ワークメモリエリアＦに未入金額「８０００」がセットされる。また、ワークメモリエリアＩにデータ「−」がセットされる。さらに、ワークメモリエリアＪ，Ｋ，Ｌの内容がそれぞれ「８３０００」，「５００００」，「３３０００」に更新される。しかして、用紙の項目に続く３行目にワークメモリエリアＡ〜Ｉの内容が１行で印字される。
【００４９】
最後に、ワークメモリエリアＪ，Ｋ，Ｌの内容が項目「合計」とともに用紙に印字されて、図１３に示す未入金レポート１６が発行される。
したがって、店舗経営者は、未入金レポート１６の内容から、クレジットカード会社「Ｘ会社」に対しては、１月１６日から２月１５日の期間内に取扱った分割払いのクレジット売上に対する請求４万円のうち１万円が入金されておらず、入金予定日２月２８日から１日遅滞していることがわかる。
【００５０】
同様に、クレジットカード会社「Ｙ会社」に対しては、１月１０日から２月９日の期間内に取扱った一括払いのクレジット売上に対する請求３万５千円のうち１万５千円が入金されておらず、入金予定日２月２５日から５日遅滞していること、及び２月１日から２月２９日の期間内に取扱った分割払いのクレジット売上に対する請求８千円については入金がなく、入金予定日が３月１０日であることがわかる。
【００５１】
このように本実施の形態のクレジット処理装置１を採用することによって、店舗経営者は、クレジット伝票の精査や煩雑な計算を行わなくても、クレジット会社への請求に対する入金予定や入金実績等を迅速かつ正確に管理できるようになる。
【００５２】
なお、本発明は前記一実施の形態に限定されるものではない。
例えば前記一実施の形態では、未入金のある全請求（クレジット会社別かつ支払区分別でかつ取扱期間別）を未入金レポート１６に一括して印字出力したが、例えばクレジット会社毎や支払区分毎に分けて印字出力する機能を持たせ、ユーザが適宜選択できるようにしてもよい。
また、未入金データの出力方法はレポートの印字に限定されるものではなく、レポートと同様な画像をディスプレイに表示させたり、フロッピーディスクなどのコンピュータ読取り可能な記録媒体に記録する方法等が考えられる。
【００５３】
また、前記一実施の形態における入金予定テーブル３及び入金実績テーブル４にそれぞれ蓄積されたデータを印字または表示出力できるようにしても、店舗経営者が両テーブルの内容からクレジット会社への請求に対する入金予定や入金実績等を容易に把握できるので、従来より作業性を大幅に向上できるものである。
【００５４】
【発明の効果】
以上詳述したように本願請求項１記載の発明によれば、クレジットカード会社からの入金予定や入金実績等を迅速かつ正確に管理することができ、入金管理業務の効率化を図り得るクレジット処理装置を提供できる。
また、本願請求項２記載の発明によれば、上記請求項１記載の発明と同等な効果を奏することはもとより、現時点で立て替えている負担金額分についての詳細な情報を容易に取得できる効果を奏し得る。
さらに、本願請求項３記載の発明によれば、その負担金額分についてのより詳細な情報を容易に取得できる効果を奏し得る。
【図面の簡単な説明】
【図１】 本発明の一実施の形態の要部構成を示すブロック図。
【図２】 図１における入金時期テーブルの構成図。
【図３】 図１における入金予定テーブルの構成図。
【図４】 図１における入金実績テーブルの構成図。
【図５】 図１における売上明細テーブルの構成図。
【図６】 図１における入金明細テーブルの構成図。
【図７】 図１における売上処理部で行われる処理の流れを示すフローチャート。
【図８】 図１における入金処理部で行われる処理の流れを示すフローチャート。
【図９】 図１におけるレポート出力部で行われる処理の流れを示すフローチャート。
【図１０】図１におけるレポート出力部で行われる処理の流れを示すフローチャート。
【図１１】図２における入金予定テーブルのデータの他の状態を示す図。
【図１２】図３における入金実績テーブルのデータの他の状態を示す図。
【図１３】未入金レポートの一発行例を示す図。
【符号の説明】
１…クレジット処理装置
２…入金時期テーブル
３…入金予定テーブル
４…入金実績テーブル
５…売上明細テーブル
６…入金明細テーブル
７…売上明細作成部
８…入金明細作成部
９…売上処理部
１０…入金処理部
１１…レポート出力部
１６…未入金レポート
Claims (3)
- クレジットカードの会社コード別でかつクレジット売上の支払区分別に各種取扱期間に対する入金予定日を設定記憶した入金時期テーブルと、
会社コード，支払区分，取扱期間，入金予定日及び入金予定額の各項目からなる入金予定レコードを蓄積記憶する入金予定テーブルと、
会社コード，支払区分，取扱期間，入金日及び入金実績額の各項目からなる入金実績レコードを蓄積記憶する入金実績テーブルと、
クレジット売上による商品売買取引が成立する毎にその取引で使用されたクレジットカードの会社コード，支払区分，売上日付，売上金額からなる売上明細データを作成する売上明細作成手段と、
前記入金時期テーブルを参照して前記売上明細作成手段により作成された売上明細データ中の会社コードかつ支払区分で売上日付を取扱期間とする入金予定日を取得する入金時期取得手段と、
前記売上明細作成手段により作成された各売上明細データ中の会社コード及び支払区分と前記入金時期取得手段により当該売上明細データに対して得られた入金予定日とで前記入金予定テーブルを検索して、会社コード，支払区分及び入金予定日の各データが一致する入金予定レコードが既に記憶されているか否かを調べる入金予定検索手段と、
この入金予定検索手段により前記会社コード，支払区分及び入金予定日の各データが一致する入金予定レコードが記憶されていない場合には、当該売上明細データ中の会社コード，支払区分及び売上金額と前記入金時期取得手段により当該売上明細データに対して得られた入金予定日及びそれに対する取扱期間とから入金予定レコードを作成して前記入金予定テーブルに追加し、既に記憶されている場合には、その既に記憶されている入金予定レコードの入金予定額に当該売上明細データ中の売上金額を加算する入金予定額集計手段と、
各クレジットカード会社からの入金が発生する毎にその入金を行ったクレジットカード会社の会社コード及び入金額と入金対象の支払区分及び取扱期間とからなる入金明細データを作成する入金明細作成手段と、
この入金明細作成手段により作成された各入金明細データ中の会社コード，支払区分及び取扱期間で前記入金実績テーブルを検索して会社コード，支払区分及び取扱期間の各データが一致する入金実績レコードが既に記憶されているか否かを調べる入金実績検索手段と、
この入金実績検索手段により前記会社コード，支払区分，取扱期間の各データが一致する入金実績レコードが記憶されていない場合には、当該入金明細データ中の会社コード，支払区分，取扱期間，入金日及び入金額で前記入金実績レコードを作成して前記入金実績テーブルに追加し、既に記憶されている場合には、その既に記憶されている入金実績レコードの入金実績額に当該入金明細データ中の入金額を加算する入金実績集計手段と、
前記入金予定テーブルに蓄積記憶された入金予定レコードと前記入金実績テーブルに蓄積記憶された入金実績レコードとから、前記クレジットカードの会社別に、支払区分別かつ取扱期間別の入金予定額及び入金実績額を表記したレポートを出力するレポート出力手段と、
を具備したことを特徴とするクレジット処理装置。 - 前記入金予定テーブルに蓄積記憶された入金予定レコードと前記入金実績テーブルに蓄積記憶された入金実績レコードとを比較して、会社コード，支払区分及び取扱期間が一致しかつ入金実績額が入金予定額を下回る未入金データを検出する未入金データ検出手段と、
この未入金データ検出手段により検出された未入金データの会社コード，支払区分及び取扱期間を当該入金実績額と入金予定額との差額及び当該取扱期間に対する入金予定日とともに出力する未入金データ出力手段と、
をさらに具備したことを特徴とする請求項１記載のクレジット処理装置。 - 未入金データ出力手段は、入金予定日からの遅滞状況を併せて出力する機能を有したことを特徴とする請求項２記載のクレジット処理装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP24970498A JP3872907B2 (ja) | 1998-09-03 | 1998-09-03 | クレジット処理装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP24970498A JP3872907B2 (ja) | 1998-09-03 | 1998-09-03 | クレジット処理装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000076348A JP2000076348A (ja) | 2000-03-14 |
| JP3872907B2 true JP3872907B2 (ja) | 2007-01-24 |
Family
ID=17196971
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP24970498A Expired - Fee Related JP3872907B2 (ja) | 1998-09-03 | 1998-09-03 | クレジット処理装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3872907B2 (ja) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2003044500A (ja) * | 2001-08-02 | 2003-02-14 | Tsubasa System Co Ltd | データ抽出方法、プログラム、および、データ抽出装置 |
| JP4045873B2 (ja) * | 2002-06-26 | 2008-02-13 | カシオ計算機株式会社 | 資金繰り管理装置 |
| JP2006189981A (ja) * | 2004-12-28 | 2006-07-20 | Ims Software Services Ltd | 医薬品地域販売統計データ作成システム |
| JP2008282321A (ja) * | 2007-05-14 | 2008-11-20 | Casio Comput Co Ltd | 情報サーバ装置、決済システム及びプログラム |
| JP5135556B2 (ja) * | 2010-11-15 | 2013-02-06 | 株式会社綜合キャリアオプション | 人材紹介管理システム |
| JP2012252727A (ja) * | 2012-09-26 | 2012-12-20 | Toshiba Tec Corp | 商品販売データ処理装置 |
-
1998
- 1998-09-03 JP JP24970498A patent/JP3872907B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000076348A (ja) | 2000-03-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4701510B2 (ja) | 金融取引に関する取引情報を集約する装置、及びその方法 | |
| EP1193627A1 (en) | Method and system for exchanging value points between IC cards | |
| JP2004506973A5 (ja) | ||
| US20050043963A1 (en) | Product recycle fee payment method and system | |
| US20030066880A1 (en) | Transaction management system and method | |
| JP4920887B2 (ja) | 著作権材料のインターネット購入およびワイヤレス購入に係るマイクロペイメントの回収および支払 | |
| CN107924508A (zh) | 通过会计和财务信息生成的业务管理系统和方法 | |
| JP3872907B2 (ja) | クレジット処理装置 | |
| US7309003B2 (en) | Credit card account payment systems and methods | |
| JP2007293614A (ja) | 自動販売機管理装置および自動販売機管理システム | |
| JP2003308375A (ja) | 売上データ管理システム | |
| JP2007193472A (ja) | 会計処理方法及び装置 | |
| JPH0199197A (ja) | 磁気カードによる取引点数精算システム | |
| JP4077547B2 (ja) | 特典ポイント管理方法 | |
| JP3706121B1 (ja) | 売掛債権に対応した融資回収のための入金処理システム及び入金処理方法 | |
| JP2004145877A (ja) | 情報処理システム、情報処理方法、情報処理プログラム及び記録媒体 | |
| JP5292647B2 (ja) | 売上振込装置および方法 | |
| US20040172361A1 (en) | Dutch account settlement method | |
| JP5931836B2 (ja) | 金融サービスに関する電子記録債権の情報を管理するシステムおよび方法 | |
| JP4238680B2 (ja) | 輸出手形管理装置、輸出手形管理方法、輸出手形管理プログラム、輸出手形管理プログラムを記録したコンピュータ読み取り可能な記録媒体 | |
| JP3969212B2 (ja) | 資金繰り管理装置およびプログラム | |
| JP3871106B2 (ja) | 会計処理システム | |
| JP2707222B2 (ja) | クレジット売上金の精算及び入金管理に使用する帳票 | |
| JP2003233757A (ja) | 売掛金消し込みにかかる電子決済支援装置および方法、コンピュータを電子決済支援装置として機能させるためのプログラム、このプログラムを記録した記録媒体 | |
| JP2500777B2 (ja) | 精査更新装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20040916 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060425 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060621 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20061017 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20061023 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20091027 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101027 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20101027 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111027 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20111027 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121027 Year of fee payment: 6 |
|
| LAPS | Cancellation because of no payment of annual fees |