(57)【要約】【課題】  支払企業及び仕入先企業の間で日々発生する債権について、支払手形の発行事務を一層低減できると共に、決済方法の変更等にも迅速に対応できる債権データの管理方法及びシステムを提供する。【解決手段】  金融機関２に設置したホストコンピュータが、支払明細マスタ１０から支払企業８及び仕入先企業３のコードを含む債権データを取得する工程と、仕入先企業コードに基づいて仕入先企業マスタ２６から仕入先企業３の支払手形発行の要否の情報を抽出して判別する工程と、手形発行不要と判別された場合に仕入先企業３の債権管理システム４から前記債権データの特定情報を取得して手形発行のリクエストを受付ける工程と、手形の発行要と判別された場合、若しくは手形発行のリクエストを受付けた場合に、債権データに基づいて手形発行基礎データを生成し手形発行システム７に出力する工程とを実行する。【選択図】  図１
2006195825.tif 000002
【特許請求の範囲】
【請求項１】
支払企業（債務者）に対して有償で商品又はサービスを提供した仕入先企業（債権者）の債権管理システムと手形発行システムとがネットワークを介して接続されるホストコンピュータによって当該仕入先企業の債権データ（支払企業の債務データ）を管理する方法であって、
Ａ）  前記コンピュータの債権データ取得手段が、支払明細マスタから支払企業及び仕入先企業の識別情報と、債権の支払期日及び金額とを含む債権データを取得する工程と、
Ｂ）  取得した債権データに含まれる仕入先企業の識別情報に基づいて、前記コンピュータの手形発行要否判別手段が、仕入先企業マスタから当該仕入先企業について登録されている支払手形発行の要否を含む決済方法を抽出して当該債権について支払手形発行の要否を判別する工程と、
Ｃ）  前記Ｂ）工程で支払手形の発行不要と判別された場合に、前記コンピュータのリクエスト受付手段が、前記仕入先企業の債権管理システムから前記債権データを特定する情報を取得して当該債権データについて手形発行のリクエストを受付ける工程と、
Ｄ）  前記Ｂ）工程で支払手形の発行要と判別された場合、若しくは前記Ｃ）工程で手形発行のリクエストを受付けた場合に、前記コンピュータの手形発行基礎データ出力手段が、前記債権データに基づいて手形発行基礎データを生成し手形発行システムに対して出力する工程と
を備えたことを特徴とする方法。
【請求項２】
請求項１記載の債権データ管理方法であって、
前記Ｃ）工程は、前記コンピュータのリクエスト受付手段が、手形発行のリクエスト受付日が債権データの支払期日よりも所定日数以前であるかに基づいて手形発行の可否を判別するものであり、
前記Ｄ）工程は、手形発行可能と判別された場合に、手形発行基礎データを生成して手形発行システムに出力するものである
ことを特徴とする方法。
【請求項３】
請求項１記載の債権データ管理方法であって、
さらに、
Ｅ）  前記コンピュータの決済方法変更受付手段が、前記仕入先企業の債権管理システムから支払企業の情報を取得して、当該仕入先企業と支払企業との債権データについて支払手形発行の要否を変更するリクエストを受付けて前記仕入先企業マスタを更新する工程を備え、
前記Ａ）工程は、前記コンピュータの債権データ取得手段が、前記支払明細マスタから当該仕入先企業及び支払企業の間の全ての債権データを収集し、収集された債権データの中から前記Ｅ）工程の決済方法変更の受付日が支払期日から所定日数以前の債権データを抽出するものである
ことを特徴とする方法。
【請求項４】
請求項１記載の債権データ管理方法であって、
前記Ｄ）工程は、債権データの支払企業識別情報に基づいて、手形発行に必要な情報であって債権データに含まれないこの支払企業に関する情報を支払企業マスタから抽出し、抽出した情報及び債権データに基づいて手形発行基礎データを生成するものであることを特徴とする方法。
【請求項５】
支払企業（債務者）に対して有償で商品又はサービスを提供した仕入先企業（債権者）の債権管理システムと手形発行システムとがネットワークを介して接続されたホストコンピュータによって当該仕入先企業の債権データ（支払企業の債務データ）を管理するシステムであって、
支払明細マスタから支払企業及び仕入先企業の識別情報と、債権の支払期日及び金額とを含む債権データを取得する債権データ取得手段と、
取得した債権データに含まれる支払企業の識別情報に基づいて、仕入先企業マスタから当該仕入先企業について登録されている支払手形発行の要否を含む決済方法を抽出して当該債権について支払手形発行の要否を判別する手形発行要否判別手段と、
支払手形の発行不要と判別された場合に、前記仕入先企業の債権管理システムから前記債権データを特定する情報を取得して当該債権データについて手形発行のリクエストを受付ける手形発行申込受付手段と、
支払手形の発行要と判別された場合、若しくは手形発行のリクエストを受付けた場合に、前記債権データに基づいて手形発行基礎データを生成し手形発行システムに対して出力する手形発行基礎データ出力手段と
を備えたことを特徴とするシステム。
【請求項６】
請求項５記載の債権データ管理システムであって、
前記手形発行申込受付手段は、手形発行のリクエスト受付日が債権データの支払期日よりも所定日数以前であるかに基づいて手形発行の可否を判別するものであり、
前記手形発行基礎データ出力手段は、手形発行可能と判別された場合に、手形発行基礎データを生成して手形発行システムに出力するものである
ことを特徴とするシステム。
【請求項７】
請求項５記載の債権データ管理システムであって、
さらに、前記仕入先企業の債権管理システムから支払企業の情報を取得して、当該仕入先企業と支払企業との債権データについて支払手形発行の要否を変更するリクエストを受付けて前記仕入先企業マスタを更新する決済方法変更受付手段を備え、
前記債権データ取得手段は、前記支払明細マスタから当該仕入先企業及び支払企業の間の全ての債権データを収集し、収集された債権データの中から前記決済方法変更の受付日が支払期日から所定日数以前の債権データを抽出するものである
ことを特徴とするシステム。
【請求項８】
請求項５記載の債権データ管理システムであって、
前記手形発行基礎データ出力手段は、債権データの支払企業識別情報に基づいて、手形発行に必要な情報であって債権データに含まれないこの支払企業に関する情報を支払企業マスタから抽出し、抽出した情報及び債権データに基づいて手形発行基礎データを生成するものであることを特徴とするシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、支払企業（債務者）に対して有償で商品又はサービスを提供した仕入先企業（債権者）の債権管理システムと手形発行システムとがネットワークを介して接続されるホストコンピュータによって当該仕入先企業の債権データ（支払企業の債務データ）を管理する方法及びシステムに関する。
【背景技術】
【０００２】
従来より、金融機関等においては、買掛債務を有する顧客（支払先）からの依頼によって支払手形の発行の一部を代行するサービスを提供している。このようなサービスは、金融機関にとっては、顧客情報を収集でき発行代行手数料を得られるというメリットがあり、また顧客にとっても、煩雑な手形発行の事務手続を低減できるというメリットがある。ここで、手形発行の事務手続は金融機関にとっても煩雑なものではあるが、例えば、以下の特許文献１および２に開示された手形の自動発行技術を利用することで事務手続の軽減を図ることが可能になる。
【０００３】
一方で、顧客は手形発行の一部を金融機関に委託した場合でも、債権額に応じた所定の印紙代を負担することに変わりはなく、金融機関は上記の手形自動発行技術を利用した場合でも、手形の現物管理（仕入先企業への郵送やセキュリティ維持・管理等）の負荷がかかることになる。また、仕入先企業（債権者）にとっては、支払債権を早期に現金化したいというニーズが強い。そのため、近年では、支払企業（債務者）と仕入先企業（債権者）と金融機関やファクタリング会社などの当事者間で予め所定の契約を締結し、一括ファクタリングや債務引受型決済、一括信託などの手法によって、手形を発行せずに支払債権を流動化して仕入先企業が早期に資金を調達できるスキームも普及してきている。
【０００４】
このようなスキームとして、例えば以下の特許文献３、４に記載されたものが参考になる。
【０００５】
【特許文献１】特開平８−１９４８４７号公報
【特許文献２】特開平１０−２７８３９４号公報
【特許文献３】特開２００２−１０９２２４号公報
【特許文献４】特開２００３−１３２２２７号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
ところで、従来の手形発行システムと手形の発行を要しないファクタリングなどのサービス提供システムとは夫々独立して設計されており、債権の情報（支払明細データ等）や債権処理のスケジュールなどの情報は共有されていない。そのため、例えば、ファクタリング契約を締結している仕入先企業が、個別の債権について手形発行を希望する場合に迅速に対応することができない。また、支払企業は、いわゆる下請法等の規制により仕入先企業から個別の債権について手形発行の要求があった場合に手形を発行しなければならないため、支払企業から手形発行の一部を委託された金融機関等も個別に対応せざるを得ない。特に、手形は法令などによって発行要件が厳格に規定されているため、個別対応は金融機関等にとって非常に煩雑となる。
【０００７】
また、仕入先企業の経営方針の転換や支払企業の経営状態などにより、特定の若しくは全ての支払企業との決済方法をファクタリング等から手形発行に切替えたいという要請があった場合に、未処理の対象債権を特定した上で、この債権について手形発行に必要な情報を改めて収集して、手形発行システムに伝送する必要がある。ここで、ファクタリングなどにおける債権処理スケジュールは、債権の振出日や支払期日及びファクタリング機関の処理スケジュール（営業日、サーバの処理周期等）に基づいて設定され、手形の発行スケジュールとは大きく相違するものである。そのため、決済方法変更の要請があった場合に未処理の債権データを収集すること自体が容易でなく、変更の要請の受付けてから実際に変更するまでのタイムラグが長くなり、それだけ変更前の方法で決済される債権が増えることになる。
【０００８】
本発明は、このような課題を解決するためになされたもので、手形の発行が不要な債権処理スキームと手形発行の代行スキームとをシームレスで連動させることで、支払企業及び仕入先企業の間で日々発生する債権について、支払手形の発行事務を一層低減できると共に、決済方法の変更等にも迅速に対応できる債権データの管理方法及びシステムを提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の第１の主要な観点によれば、支払企業（債務者）に対して有償で商品又はサービスを提供した仕入先企業（債権者）の債権管理システムと手形発行システムとがネットワークを介して接続されるホストコンピュータによって当該仕入先企業の債権データ（支払企業の債務データ）を管理する方法であって、Ａ）前記コンピュータの債権データ取得手段が、支払明細マスタから支払企業及び仕入先企業の識別情報と、債権の支払期日及び金額とを含む債権データを取得する工程と、Ｂ）取得した債権データに含まれる仕入先企業の識別情報に基づいて、前記コンピュータの手形発行要否判別手段が、仕入先企業マスタから当該仕入先企業について登録されている支払手形発行の要否を含む決済方法を抽出して当該債権について支払手形発行の要否を判別する工程と、Ｃ）前記Ｂ）工程で支払手形の発行不要と判別された場合に、前記コンピュータのリクエスト受付手段が、前記仕入先企業の債権管理システムから前記債権データを特定する情報を取得して当該債権データについて手形発行のリクエストを受付ける工程と、Ｄ）前記Ｂ）工程で支払手形の発行要と判別された場合、若しくは前記Ｃ）工程で手形発行のリクエストを受付けた場合に、前記コンピュータの手形発行基礎データ出力手段が、前記債権データに基づいて手形発行基礎データを生成し手形発行システムに対して出力する工程とを備えたことを特徴とする方法が提供される。
【００１０】
このような構成によれば、支払明細マスタから取得した債権データに基づいて手形発行の要否を判別すると共に、手形を発行する場合にはその債権データから手形発行に必要なデータを生成して手形発行システムに出力するようにした。これにより、債権データの取得から手形発行までの処理を効率的・自動的に行うことができる。また、債権データや処理状況を統一的に管理することができるので、債権一括処理を実行している途中で仕入先企業から手形発行のリクエストを受け付けた場合でも、対象債権を抽出して円滑に手形発行処理に移行することができる。なお、債権者若しくは債務者が個人であることもあるが、本明細書においては説明の便宜のため、仕入先企業、支払企業と総称する。
【００１１】
また、本発明の第２の主要な観点によれば、支払企業（債務者）に対して有償で商品又はサービスを提供した仕入先企業（債権者）の債権管理システムと手形発行システムとがネットワークを介して接続されたホストコンピュータによって当該仕入先企業の債権データ（支払企業の債務データ）を管理するシステムであって、支払明細マスタから支払企業及び仕入先企業の識別情報と、債権の支払期日及び金額とを含む債権データを取得する債権データ取得手段と、取得した債権データに含まれる支払企業の識別情報に基づいて、仕入先企業マスタから当該仕入先企業について登録されている支払手形発行の要否を含む決済方法を抽出して当該債権について支払手形発行の要否を判別する手形発行要否判別手段と、支払手形の発行不要と判別された場合に、前記仕入先企業の債権管理システムから前記債権データを特定する情報を取得して当該債権データについて手形発行のリクエストを受付ける手形発行申込受付手段と、支払手形の発行要と判別された場合、若しくは手形発行のリクエストを受付けた場合に、前記債権データに基づいて手形発行基礎データを生成し手形発行システムに対して出力する手形発行基礎データ出力手段とを備えたことを特徴とするシステムが提供される。
【００１２】
このような構成によれば、上記した第１の主要な観点における債権データ方法をホストコンピュータを利用して好適に実行できる債権データ管理システムを得ることができる。
【発明の効果】
【００１３】
本発明によれば、支払企業及び仕入先企業の間で日々発生する債務データについて、手形の発行事務を一層低減することができる。
【００１４】
なお、この発明の他の特徴と顕著な効果は、次の発明を実施するための最良の形態の項の記載と添付した図面とを参照することで、より明確に理解される。
【発明を実施するための最良の形態】
【００１５】
以下、本発明の実施の形態を図面に基づいて説明する。以下においては、金融機関と手形発行代行の委託契約及び債権一括処理契約を締結した複数の顧客の一方（仕入先企業）が、他方の顧客（支払企業）に対して有償で商品又はサービスを提供した場合の債権データを管理する例を説明する。
【００１６】
図１は本発明の一実施形態に係るネットワーク構成を示す図である。この図で符号１で示す債権データ管理システムは、金融機関２に設置されたホストコンピュータで構成され、専用回線、公衆回線などのネットワークを介して、この金融機関２の顧客である仕入先企業３の債権管理システム４と通信可能に接続されている。なお、ファイアウォール、ゲートウェイサーバ、ネットバンキング用のＷｅｂサーバ、金融機関のフロントエンド（ＦＥ）サーバなどの周知の構成は図示を省略してある。
【００１７】
この債権データ管理システム１は、金融機関２の情報系システム５、勘定系システム６及び手形発行システム７と専用回線を介して接続されている。また、情報系システム５は、支払企業８の債務管理システム９と上記ネットワークを介して接続され、この債務管理システム９から債務データを取得して支払明細マスタ１０に格納する機能を有する。そして、債権データ管理システム１は、この支払明細マスタ１０から支払企業８の債権データを定期的に取得し、後述する支払企業マスタ２５及び仕入先企業マスタ２６を参照して当該債権データの決済方法を判別する機能と、決済方法が手形発行である場合に、債権データから手形発行に必要な情報を抽出して手形発行基礎情報を生成して前記手形発行システム７に伝送する機能と、決済方法が一括ファクタリングなどである場合は、従来周知のスキームで債権一括処理を実行する機能とを有する。
【００１８】
支払明細マスタ１０には、支払企業８の債務管理システム９から取得した債権データについて処理が完了した場合に処理済を識別するフラグ（処理済：１）が登録される。本実施形態では、債権一括処理については、「支払期日から所定日数」が経過して手形発行処理への移行ができなくなった時点で「処理済」のフラグを登録するようにしている。この「支払期日から所定日数」は、対象となる債権データの抽出や、行内の資金化処理、当該仕入先企業３や支払企業８への処理済通知等に要する期間を考慮して、例えば２〜４営業日が設定される。なお、この支払明細マスタ１０を債権データ管理システム１の機能として取り込んでも良い。
【００１９】
また、本実施形態の債権データ管理システム１は、債権データが処理される前に、仕入先企業３から個別に手形発行のリクエスト（債権譲渡契約の解約など）や決済方法変更のリクエストを受け付けた場合に、該当する債権データを支払明細マスタ１０や図示しない手形明細管理ＤＢ若しくは支払明細管理ＤＢから収集して当該リクエストに応じた処理を実行する機能も有している。
【００２０】
前記手形発行システム７は、伝送された手形発行基礎情報を手形実行管理データベース（ＤＢ）に一旦格納し、この情報と、予め支払企業８から入手して管理している印影データとに基づいて所定様式で支払手形を印刷（自動発行）し、仕入先企業３に郵送するものである。手形発行システム７の全部又は一部の機能を、金融機関２とは独立した特定目的会社（ＳＰＣ）や専門子会社、共同事業体（ＪＶ：Ｊｏｉｎｔ  Ｖｅｎｔｕｒｅ）などに設置したコンピュータに行わせるようにしても良い。
【００２１】
なお、仕入先企業３及び支払企業８は、他の商取引や他の取引先との関係では逆の立場となることもあり得る。また、債権データ管理システム１も、支払企業８から見れば債務データを管理するシステムとなる。さらに、債権管理システム４及び債務管理システム９は、何れも顧客企業の売上管理システムや経理システムなどの汎用のコンピュータシステム、若しくは金融機関２が提供する本システムの専用Ｗｅｂサイトにログインして債権データの入力・伝送が可能な端末（ＰＣなど）で構成される他、仕入先企業３及び支払企業８の社内の経理用台帳などの全ての経理データ管理の仕組みが含まれる。経理台帳などで管理される場合は、本システム１は、支払企業８からＦＡＸなどで取得した文書に記載された債権データを金融機関２のオペレータがホストコンピュータに入力することで取得できる。
【００２２】
上記した機能を奏するため、本実施形態の債権データ管理システム１は、図２に示すような構成を備えている。  
具体的には、このシステム１は、図２（Ａ）に示すように、金融機関２のホストコンピュータのＣＰＵ１１にシステムバス１２を介してＲＡＭ１３、ＲＯＭ１４、ＨＤＤ（記憶装置）１５及び入出力インタフェース（Ｉ／Ｆ）１６が接続されて構成される。入出力Ｉ／Ｆ１６には、液晶ディスプレイなどの出力装置１７、キーボードやマウスなどの入力装置１８、モデムなどの通信デバイス１９及びＦＤやＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭなどのリムーバブル記録媒体２０用のドライバ２１が夫々接続されている。本発明の機能を実現するソフトウェアプログラムは図２（Ｂ）に概念的に示すように、ＨＤＤ１５やＲＯＭ１４などの記憶装置にインストールされている。オペレータが入力装置１８を操作して各種の指令（コマンド）を入力すると、このソフトウェアプログラムがＣＰＵ１１によってＲＡＭ１３上に呼び出されて実行されることで、ＯＳ（オペレーションシステム）と協働してこの発明の機能を奏するようになっている。上記プログラムはリムーバブル記録媒体２０から導入することもできる。
【００２３】
図２（Ｂ）に示すように、前記ＨＤＤ１５などの記憶装置の一定の領域には、支払企業マスタ２５、仕入先企業マスタ２６及び印紙代テーブル２７が格納される。各マスタ２５〜２７は、後述するマスタ管理部３７によって、ソフトウェアプログラムによる後述の各機能によって入力される情報や、外部通信Ｉ／Ｆ２７を介して外部機関から取得した情報が随時記録・更新される。
【００２４】
支払企業マスタ２５及び仕入先企業マスタ２６は、仕入先企業３及び支払企業８の名称、本社住所、代表者名、決算情報、外部格付機関による格付情報、被仕向銀行や仕向銀行の情報（銀行コード、口座情報等）などを、これらの企業３、８を一意で識別可能な顧客コードに関連付けて格納するものである。また、仕入先企業マスタ２６は、仕入先企業３が金融機関２との契約時に指定した決済方法の情報を、この仕入先企業３の顧客コードに関連付けて格納するものである。この決済方法の情報には、支払手形の発行が必要な場合の記号（フラグ：１）が含まれる。手形発行不要の場合は、手形の発行不要の記号（フラグ：０）が登録される。当事者間で契約された通りの債権一括処理の種別（一括ファクタリングや債務引受決済、一括信託等）を示す記号を登録するようにしても良い。
【００２５】
これらの各マスタ２５、２６は、金融機関２が保有する顧客マスタ（図示せず）から取得する最新の顧客情報によって所定周期で更新されると共に、ネットワークを通じて行内の営業担当者の端末や仕入先企業３の債権管理システム４などから入力された情報も格納される。なお、これらのマスタ２５、２６を１つのデータベースで構成したり、前記顧客マスタ（図示せず）に必要なフィールドを追加して兼用させることもできる。
【００２６】
前記ソフトウェアプログラムは、主として、債権データ取得部３０、手形発行要否判別部３１、手形発行申込受付部３２、決済方法変更受付部３３、印紙代演算部３４、手形発行基礎データ出力部３５、債権一括処理部３６およびマスタ管理部３７を備えている。
【００２７】
債権データ取得部３０は、毎営業日などの所定周期で、前記支払明細マスタ１０から支払企業８及び仕入先企業３の顧客コード（識別情報）と、債権の支払期日及び金額とを含む債権データを取得してメモリに一時的に登録するものである。取得するのは、上記のように、処理済のフラグ：１が登録されていない債権データである。
【００２８】
ここで、債権データの概略について図３、図４を参照して説明する。この債権データは、仕向金融機関から被仕向金融機関に対してネットワークを経由して専用ソフトで伝送できるよう、全銀フォーマットなどの所定フォーマットで作成される。基本的には、図３に示すように、債権の決済日単位で作成されたヘッダーレコード、データレコード及びトレーラレコードと、エンドレコードとで構成される。各レコードに含まれるデータ項目を図４に示す。ヘッダーレコードには、支払企業の情報（企業コード及び企業名）と支払期日とが含まれている。データレコードには、仕入先企業３の情報（企業コード及び企業名）と債権金額と、後述する手形分割済を示すフラグとが含まれている。なお、被仕向銀行や仕向銀行の情報（銀行コード、口座情報等）は、前記マスタ２５、２６に登録されているので、ここでは任意取得項目となっている。
【００２９】
また、この債権データ取得部３０は、後述するように、仕入先企業３から手形発行や決済方法変更のリクエストを受け付けた場合には、前記支払明細マスタ１０から当該仕入先企業３及び支払企業８の間で未処理となっている全ての債権データを収集するものである。本実施形態では、上述のように「支払期日から所定日数」が経過して手形発行処理への移行ができなくなった時点で「処理済」のフラグを登録しているため、ここで収集する債権データは全て「支払期日から所定日数」が経過していない債権データである。なお、データ登録などの狭義の債権一括処理が完了した時点で前記支払明細マスタ１０に「処理済」のフラグ：１を登録し、上記リクエストを受け付けた場合に、債権データ取得部３０が収集された債権データの中から前記リクエストの受付日が支払期日から所定日数以前の債権データを抽出するようにしても良い。
【００３０】
手形発行要否判別部３１は、取得した債権データに含まれる仕入先企業３の顧客コードに基づいて、仕入先企業マスタ２６から当該仕入先企業３について登録されている支払手形発行の要否を示す記号（手形発行：１）を抽出して当該債権について支払手形発行の要否を判別するものである。また、手形発行要否判別部３１は、この判別結果に基づいて、図示しない手形明細管理ＤＢ若しくは支払明細管理ＤＢを生成して、取得した債権データをこれらのＤＢに格納すると共に、印紙代演算部３４や債権一括処理部３６に対して処理を指示する。
【００３１】
ここで、手形発行要と判別した場合で、当該債権データに前記手形分割済フラグが設定されていない場合（フラグ：０）には、印紙代演算部３４に対して印紙代が最小となる手形発行パターンの演算を指示する。逆に、手形分割済フラグが設定されている場合（フラグ：１）には、印紙代演算の工程をスキップして、手形発行基礎データ出力部３５に処理を指示する。なお、債権一括処理の種別を示す記号が登録されている場合に、その記号に基づいて処理の種別を判別して債権一括処理部３６に指示するようにしても良い。
【００３２】
手形発行申込受付部３２は、支払手形の発行不要と判別され、債権一括処理が実行されている債権について、前記仕入先企業３の債権管理システム４からその債権データを特定する情報（仕入先企業３及び支払企業８の企業コードと支払期日等）を取得して当該債権データについて個別の手形発行のリクエストを受付けて、前記債権データ取得部３０に対して対象となる債権データの収集を指示するものである。ここで、上記した狭義の債権一括処理が完了した後（「支払期日から２〜４営業日」が経過する前）に支払明細マスタ１０に「処理済」が登録される場合には、この手形発行申込受付部３２が、手形発行のリクエスト受付日が債権データの支払期日よりも所定日数以前であるかに基づいて手形発行の可否を判別し、当該手形発行が可能と判別した場合に前記債権データ取得部３０に指示を出すようにする。
【００３３】
決済方法変更受付部３３は、前記仕入先企業３の債権管理システム４から支払企業８の企業コードを取得して、当該仕入先企業３と支払企業８との間の債権データについて支払手形発行の要否を変更するリクエストを受付け、前記仕入先企業マスタ２６を更新すると共に、前記債権データ取得部３０に対して決済方法の変更を通知するものである。この通知を受け付けた債権データ取得部３０は、上記したように、支払明細マスタ１０から対象となる債権データを収集する。この決済方法変更受付部３３は、仕入先企業３と支払企業８との間で将来発生する債権／債務の決済方法を変更するリクエストを受付けるもので、既に発生している特定の債権データについて個別に手形発行のリクエストを受付ける前記手形発行申込受付部３２とは区別される。
【００３４】
印紙代演算部３４は、前記手形発行要否判別部３１によって手形発行要と判別された場合に、この手形発行要否判別部３１からの指令に基づいて前記債権データに含まれる金額（図４参照）と前記印紙代テーブル２７とを参照して、手形を分割して発行した場合の印紙代が最小となる手形分割パターンを演算するものである。
【００３５】
ここで、手形の発行代行について１枚当たり所定の発行手数料が設定されている場合には、手形を分割発行して印紙代が低額になっても、発行手数料が増額されて結果的にコスト高にならないよう、この発行手数料を加算して発行パターンをシミュレーションするのが好ましい。具体的には、印紙代テーブル２７に記述された手形１枚当たりの手形発行代行手数料（ａ）と、分割前の印紙代（ｂ）と、分割後の印紙代総額（ｃ）と、分割後の手形枚数（ｎ）とが、ａ＋ｂ>ａ×ｎ＋ｃとなる手形分割パターンを演算する。
【００３６】
演算した分割パターンは手形発行基礎データ出力部３５に通知される。該当する分割パターンが存在しなかった場合には、債権データの分割済フラグを１にリセットして手形発行基礎データ出力部３５に通知する。なお、印紙代テーブル２７を省略し、印紙代演算部３４は必要に応じて手形発行システム７の印紙代テーブルにアクセスするようにしても良い。
【００３７】
手形発行基礎データ出力部３５は、前記手形発行要否判別部３１若しくは前記手形発行申込受付部３２からの指示に基づいて、前記債権データに基づいて手形発行基礎データを生成し手形発行システム７に対して出力するものである。ここで、手形発行に必要な情報であって債権データに含まれてない情報が存在する場合に、仕入先企業３や支払企業８の企業コードに基づいて各マスタ２５、２６から必要な情報を抽出して手形発行基礎データを生成するのが好ましい。また、前記印紙代演算部３４から手形分割パターンを取得した場合には、その手形分割パターンに基づいて手形発行基礎データを生成する。
【００３８】
債権一括処理部３６は、金融機関２が仕入先企業３や支払企業８と締結した一括ファクタリング、債務引受型決済、一括信託などの債権一括処理について、従来周知の手法でそれらの処理を実行するものである。ここで、前記手形発行申込受付部３２や決済方法変更受付部３３が、仕入先企業３の債権管理システム４から夫々のリクエストを受け付けた場合には、これらの受付部３２、３３から債権一括処理部３６に対して手続中断の指示が出される。この中断指示は、例えば、個別の手形発行不可と判別された場合や、対象債権データが抽出されなかった場合に、各受付部３２、３３からの解除通知によって解除され、債権一括処理を再開する。なお、各決済手法の詳細やそれらの処理方法は、本実施形態の特徴とは関連しないため説明は省略する。
【００３９】
以下、このシステム１の詳細な機能を実際の動作と共に、図５を参照して説明する。なお、これらの図のＳ１〜Ｓ１４は処理順序を示す符号であり、以下の説明のステップＳ１〜Ｓ１４に対応する。
【００４０】
まず、前記債権データ取得部３０が、毎営業日の定時（２４時等）に支払明細マスタ１０にアクセスして債権データを収集してメモリに一時的に格納する（ステップＳ１）。次いで、前記手形発行要否判別部３１が起動し、この債権データに含まれる仕入先企業３の企業コードに基づいて仕入先企業マスタ２６から抽出したこの仕入先企業３の決済方法に基づいて、決済方法を判別する（ステップＳ２）。この判別結果に基づいて、手形明細管理ＤＢ若しくは支払明細管理ＤＢを生成し、前記メモリに登録されている債権データを夫々格納する（ステップＳ３、Ｓ４）。
【００４１】
判別した決済方法が手形発行である場合（ステップＳ２のＹｅｓ）、前記手形発行要否判別部３１からの指示に基づいて前記印紙代演算部３４が手形発行パターンを演算する（ステップＳ５）。なお、上記したように、取得した債権データに分割済のフラグ（１）が設定されている場合には、この工程はスキップされる。
【００４２】
この印紙代演算部３４が演算した手形発行パターンが伝送されることで前記手形発行基礎データ出力部３５が起動する。この手形発行基礎データ出力部３５は、手形発行パターン及び前記ステップＳ１でメモリに登録された債権データと、必要に応じて支払企業マスタ２５及び仕入先企業マスタ２６から収集した情報とに基づいて、手形発行基礎データを生成し、前記手形発行システム７に送信する（ステップＳ６）。送信が完了すると、前記手形明細管理ＤＢ及び支払明細マスタ１０に「処理済」のフラグ：１を登録してこの手形発行処理を完了する（ステップＳ７）。
【００４３】
一方、前記ステップＳ２で判別された仕入先企業３の決済方法が債権一括処理である場合（ステップＳ２のＮｏ）、前記債権一括処理部３６によって所定の債権処理が開始される（ステップＳ８）。この処理工程中、前記手形発行申込受付部３２及び決済方法変更受付部３３は、仕入先企業３の債権管理システム４から手形発行のリクエスト若しくは決済方法変更のリクエストを受付ける（ステップＳ９〜Ｓ１２）。
【００４４】
具体的には、手形発行のリクエストを受付けた場合（ステップＳ９のＹｅｓ）、手形発行申込受付部３２が、リクエスト受付日が当該債権データの支払期日から２〜４営業日前であるかに基づいて手形発行の可否を判別する（ステップＳ１０）。手形発行が可能と判別された場合は（ステップＳ１０のＹｅｓ）、前記ステップＳ３以降の手形発行処理に移行する。この場合には、手形発行申込受付部３２が前記手形明細管理ＤＢに処理済を登録する。
【００４５】
また、決済方法の変更のリクエストを受け付けた場合（ステップＳ１１のＹｅｓ）、前記決済方法変更受付部３３は前記債権データ取得部３０に対して対象データの収集を指示する。債権データ取得部３０は、前記手形明細管理ＤＢから未処理の債権データを抽出する（ステップＳ１２）。未処理データを抽出できた場合は（ステップＳ１２のＹｅｓ）、前記ステップＳ３以降の手形発行処理に移行する。
【００４６】
上記したステップＳ９〜Ｓ１２の処理を、債権一括処理が完了するまで、すなわち、手形発行処理への移行ができなくなるまで繰り返す（ステップＳ１３）。債権一括処理が完了すると（ステップＳ１３のＹｅｓ）、前記支払明細マスタ１０及び支払明細管理ＤＢの該当レコードに「処理済」のフラグ：１を登録してこの処理を終了する（ステップＳ１４）。
【００４７】
以上のような構成によれば、手形の自動発行と債権一括処理とをシームレスに連動させることができるので、債権一括処理を行った債権データについて仕入先企業から手形発行のリクエストを受け付けた場合でも、迅速かつ容易に手形発行処理に移行できる。また、支払明細マスタ１０から手形発行及び債権一括処理に必要な債権データを取得しておくことで、何れの決済方法で処理することになっても、データの追加や確認等の工程が不要で、債権データを効率的に処理することができる。
【００４８】
なお、この発明は上記の実施形態に限定されるものではなく、発明の要旨を変更しない範囲で種々変形可能である。
【図面の簡単な説明】
【００４９】
【図１】図１は、本発明の一実施形態に係るネットワーク構成を示す図である。
【図２】図２は、同、債権データ管理システムの概略構成を示すブロック図である。
【図３】債権データの構造を示す図である。
【図４】債権データの各レコードに含まれるデータ項目を示す図である。
【図５】本発明の処理工程を示すフローチャートである。
【符号の説明】
【００５０】
１…債権データ管理システム
２…金融機関
３…仕入先企業
４…債権管理システム
５…情報系システム
６…勘定系システム
７…手形発行システム
８…支払企業
９…債務管理システム
１０…支払明細マスタ
１１…ＣＰＵ
１２…システムバス
１３…ＲＡＭ
１４…ＲＯＭ
１５…ＨＤＤ
１６…入出力インタフェース
１７…出力装置
１８…入力装置
１９…通信デバイス
２０…リムーバブル記録媒体
２１…ドライバ
２５…支払企業マスタ
２６…仕入先企業マスタ
２７…印紙代テーブル
３０…債権データ取得部
３１…手形発行要否判別部
３２…手形発行申込受付部
３３…決済方法変更受付部
３４…印紙代演算部
３５…手形発行基礎データ出力部
３６…債権一括処理部
３７…マスタ管理部
【図１】
2006195825.tif 000003
【図２】
2006195825.tif 000004
【図３】
2006195825.tif 000005
【図４】
2006195825.tif 000006
【図５】
2006195825.tif 000007