JPH1166211A - 手形発行管理システムおよびそのプログラム記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 金融機関の顧客側では手形用紙に必要事項を
自動印刷して手形を発行するだけで、手形管理を金融機
関側に委ねることができ、金融機関側では手形現物が持
ち込まれた際に手形現物から手形データを入力する操作
が不要となると共に、流通段階での改ざん等をチェック
することができ、しかも通信ネットを介して顧客側へ各
種のサービスを提供する。 【解決手段】 手形発行装置１は手形用紙の各項目に対
応する手形要件データが入力されると、この手形要件デ
ータを手形用紙の対応する項目位置に印刷出力して手形
を発行すると共に、その手形データを手形管理サーバ２
へ送信する。手形管理サーバ２はこの手形要件データを
受信して記憶管理する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、金融機関の顧客
側に設置された手形発行装置と、金融機関に設置された
手形管理装置との間で通信ネットを介してデータの送受
信を行う手形発行管理システムおよびそのプログラム記
録媒体に関する。

【０００２】

【従来の技術】従来、金融機関の顧客である企業におい
て、金融機関から配付された手形用紙の券面に必要事項
を自動印刷して手形を発行する手形発行システムは会計
システムのサブシステムとして位置付けされており、ま
た、振り出し手形管理および受け取り手形管理を行う手
形管理システムも会計システムのサブシステムとして位
置付けされており、手形の金額と期日の管理に主体がお
かれている。

【０００３】

【発明が解決しようとする課題】ところで、会計システ
ムはその導入価格が極めて高価なものとなるため、月当
たりの手形発行枚数が少ない中小企業にとっては、業務
内容とシステム導入価格とが釣り合わず、容易に導入す
ることができないのが現状であった。一方、顧客企業側
において手形発行システムや手形管理システムが導入さ
れていても企業内のみで使用されるシステムであるた
め、金融機関側においては、手形現物が持ち込まれたと
き、手形用紙の記入事項を１項目毎にキー入力する必要
があり、オペレータに負担をかけると共に入力ミスのお
それがあった。また、手形流通段階で手形が改ざんされ
てもそれを手形券面だけから確認するしかなく、不正等
に対するセキュリティの高度化が望まれていた。この発
明の課題は、金融機関の顧客側では手形用紙に必要事項
を自動印刷して手形を発行するだけで、手形管理を金融
機関側に委ねることができ、金融機関側では手形現物が
持ち込まれた際に手形現物から手形データを入力する操
作が不要となると共に、流通段階での改ざん等をチェッ
クすることができ、しかも通信ネットを介して顧客側へ
各種のサービスを提供できるようにすることである。

【０００４】

【課題を解決するための手段】この発明の手段は次の通
りである。請求項１記載の発明は、金融機関の顧客側に
設置された手形発行装置と、金融機関に設置された手形
管理装置との間で通信ネットを介してデータの送受信を
行う手形発行管理システムであって、手形発行装置は、
手形用紙の各項目に対応する手形データを入力する入力
手段と、この入力手段から入力された手形データを手形
用紙の対応する項目位置に印刷出力して手形を発行する
手形発行手段と、この手形発行手段によって発行された
手形に対応する前記手形データを金融機関側の手形管理
装置へ送信する送信手段とを具備し、手形管理装置は、
顧客側の手形発行装置から送信されて来た手形データを
受信する受信手段と、この受信手段で受信した手形デー
タを記憶管理する手形記憶管理手段とを具備するもので
ある。なお、この発明は以下のようなものであってもよ
い。 （１）、手形管理装置は、金融機関に既発行手形が持ち
込まれた際に、当該手形の記入内容とそれに対応する前
記手形データとを照合するためにその手形データを前記
手形記憶管理手段から読み出して出力する。 （２）、手形発行装置側において、前記手形発行手段に
よって手形が発行された発行タイミングに同期して前記
送信手段は、その手形データを手形管理装置へ送信し、
手形管理装置は、手形発行と同時に送信されて来た手形
データを記憶管理する。 （３）、手形管理装置は、手形発行装置から送信されて
来た手形番号が正規な手形番号か否かをチェックしてそ
のチェック結果を元の手形発行装置へ送信し、手形発行
装置は、前記チェック結果を判断し、正規な手形番号で
あることを条件に手形発行を実行する。 （４）、手形発行装置側において、手形発行に誤りが生
じた際に前記送信手段は、当該手形を無効とする手形無
効データを送信し、手形管理装置は、前記手形無効デー
タを前記手形記憶管理手段内の当該手形データに関連付
けて記憶管理する。 （５）、手形発行装置側において、既発行手形の記入内
容を変更する手形更改が行われた際に、前記手形発行手
段は手形更改されたデータに基づいて手形を再発行し、
前記送信手段は当該手形更改データを手形管理装置へ送
信し、手形管理装置は、前記手形更改データに基づい
て、前記手形記憶管理手段内に格納されている更改前の
当該手形データが更改されたことを示すと共に、手形更
改データを新たな手形データとして記憶管理する。 （６）、手形管理装置は、手形発行装置からの手形発行
状況を問い合せる手形照会に応答してその顧客に対応す
る手形データを前記手形記憶管理手段から読み出して要
求元の手形発行装置へ送信する。 （７）、手形管理装置は、金融機関に既発行手形が持ち
込まれた際に、手形受け入れ済みか手形流通中かを示す
手形流通状況を前記手形記憶管理手段内の当該手形デー
タに関連付けて記憶管理し、手形発行装置からの手形照
会に応答して手形流通状況を要求元の手形発行装置へ送
信する。 （８）、手形管理装置は、手形発行装置から手形データ
が送信されて来る毎に、当該顧客の手形用紙の残りが所
定枚数か否かを検出し、手形用紙の残りが所定枚数にな
った場合に手形用紙の発注有無を問い合せる発注問い合
せ情報をその顧客の手形発行装置へ送信し、手形発行装
置は、手形管理装置から送信されて来た発注問い合せ情
報を出力する。 （９）、手形発行装置は、次に発行すべき手形の手形番
号を手形管理装置に要求し、その要求に応答して手形管
理装置は、未使用の手形番号を検索して要求元の手形発
行装置へ送信する。 （１０）、複数の金融機関と取引のある顧客側の手形発
行装置において、前記送信手段は複数の金融機関を順次
指定すると共に、指定した金融機関側の手形管理装置へ
手形データを送信し、指定された金融機関側の手形管理
装置は、手形発行装置から送信されて来た手形データを
受信した際に、当該手形データをそれぞれ記憶管理し、
既発行手形がその支払先ではない他の金融機関に持ち込
まれた際に、当該他の金融機関の手形管理装置は、支払
先金融機関の手形管理装置に記憶管理されている手形デ
ータの送信を要求し、これに応答して支払先金融機関の
手形管理装置から送信されて来た手形データを記憶管理
する。 （１１）、複数の金融機関と取引のある顧客側の手形発
行装置において、前記送信手段は複数の金融機関のうち
特定の金融機関をメイン金融機関として指定してその手
形管理装置へ各金融機関の手形データを送信し、前記メ
イン金融機関側の手形管理装置は、手形発行装置から送
信されて来た各金融機関の手形データを一括して記憶管
理すると共に、前記複数の金融機関のうち自己を除く他
の金融機関の手形管理装置へ当該金融機関の手形データ
をそれぞれ配信し、前記他の金融機関側の手形管理装置
は、メイン金融機関から配信されて来た手形データを受
信してそれぞれ記憶管理する。

【０００５】請求項１記載の発明において、手形発行装
置は入力された手形データを手形用紙に印刷して手形を
発行すると、その手形データを金融機関側の手形管理装
置へ送信する。すると、手形管理装置はこの手形データ
を受信して記憶管理する。したがって、金融機関の顧客
側では手形用紙に必要事項を自動印刷して手形を発行す
るだけで、手形管理を金融機関側に委ねることができ、
金融機関側では手形現物が持ち込まれた際に手形現物か
ら手形データを入力する操作が不要となると共に、流通
段階での改ざん等をチェックすることができ、しかも通
信ネットを介して顧客側へ各種のサービスを提供するこ
とができる。

【０００６】

【発明の実施の形態】

（第１実施形態）以下、図１〜図１４を参照してこの発
明の第１実施形態を説明する。図１はこの手形発行管理
システムを示したシステム構成図である。この手形発行
管理システムは金融機関の顧客側に設置された手形発行
装置１と金融機関側に設置された手形管理サーバ２との
間で通信ネットを介してデータの送受信を行うもので、
手形発行装置１は入力された手形要件データを手形用紙
に自動印刷して手形を発行した際に、その手形要件デー
タをインターネットを利用して手形管理サーバ２へ送信
し、手形管理サーバ２はこの手形要件データを顧客毎に
記憶管理する。手形発行装置１は本体コンピュータ１１
に手形券面印刷プリンタ１２、通信制御装置１３を接続
した構成で、手形発行を主体とし、手形管理を手形管理
サーバ２側に委ねており、必要に応じて手形管理データ
を手形管理サーバ２に問い合せるようにしている。手形
管理サーバ２は本体コンピュータ２１に記憶装置２２、
通信制御装置２３を接続した構成で、各顧客側の手形発
行装置１から送信されて来た手形データを記憶管理する
他に、手形が現在流通しているのか、金融機関に持ち込
まれたか等の手形流通状態も記憶管理し、顧客からの問
い合せに応じて各種のサービスを提供する。なお、手形
管理サーバ２には勘定系ホストコンピュータ３が接続さ
れており、顧客の口座番号等を取り込むようにしてい
る。

【０００７】図２（Ａ）は手形発行装置１の全体構成を
示したブロック図である。ＣＰＵ１４はＲＡＭ１５内に
ロードされている各種プログラムにしたがってこの手形
発行装置１の全体動作を制御する中央演算処理装置であ
る。記憶装置１６はオペレーティングシステムや各種ア
プリケーションプログラム、データファイル、文字フォ
ントデータ等が予め格納されている記憶媒体１７やその
駆動系を有している。この記憶媒体１７は固定的に設け
たもの、もしくは着脱自在に装着可能なものであり、フ
ロッピーディスク、ハードディスク、光ディスク、ＲＡ
Ｍカード等の磁気的・光学的記憶媒体、半導体メモリに
よって構成されている。また、記憶媒体１７内のプログ
ラムやデータは、必要に応じてＣＰＵ１４の制御によ
り、ＲＡＭ１５にロードされる。更に、ＣＰＵ１４は通
信回線等を介して他の機器側から送信されて来たプログ
ラム、データを受信して記憶媒体１７に格納したり、他
の機器側に設けられている記憶媒体に格納されているプ
ログラム、データを通信回線等を介して使用することも
できる。そして、ＣＰＵ１４にはその入出力周辺デバイ
スである手形券面印刷プリンタ１２、通信制御装置１
３、入力装置１８、表示装置１９がバスラインを介して
接続されており、入出力プログラムにしたがってＣＰＵ
１４はそれらの動作を制御する。

【０００８】入力装置１８は手形用紙の各項目に対応付
けてその各項目データ（手形要件データ）、すなわち、
手形番号や支払先（受取人）、支払金額、支払期日等を
入力したり、各種コマンドを入力するキーボードやマウ
ス等のポインティングデバイスを有し、この入力装置１
８から手形要件データが入力されるとＣＰＵ１４はそれ
をＲＡＭ１５内に書き込むと共に、表示装置１９に送っ
て表示出力させる。ここで、手形印刷が指示されると、
手形要件データを手形券面印刷プリンタ１２に送る。手
形券面印刷プリンタ１２は漢字等を印刷可能な熱転写や
インクジェットなどのノンインパクトプリンタあるいは
インパクトプリンタで、手形用紙の各項目位置に手形要
件データを自動印刷して手形を発行する。ここで、手形
が発行されると同時に図２（Ｂ）に示すＲＡＭ１５内の
手形要件データはダイヤルアップによるインターネット
接続によって金融機関側の手形管理サーバ２へ送信され
る。ここで、手形発行装置１から手形管理サーバ２へ送
信される手形要件データは図２（Ｂ）に示すように、
「手形番号」、「支払先」、「支払金額」、「支払期
日」、「備考」の各項目データである。図３は手形発行
装置１によって発行された約束手形の印刷例を示し、
「支払先」、「支払金額」、「支払期日」、「振出日」
等は手形用紙の本券部と控え部の所定位置に印刷され
る。また「備考」は印紙税額や支払い理由等が控え部の
所定位置に印刷される。なお、手形番号等は手形用紙に
予め印刷形式されている。

【０００９】図４（Ａ）は手形管理サーバ２の全体構成
を示したブロック図である。ＣＰＵ２４はＲＡＭ２５内
にロードされている各種プログラムにしたがってこの手
形管理サーバ２の全体動作を制御する。記憶装置２２や
記憶媒体２６は上述した手形発行装置１側の記憶装置１
６、記憶媒体１７と基本的に同様であるため、その説明
は省略する。ＣＰＵ２４にはその入出力デバイスである
通信制御装置２３、入力装置２７、表示装置２８、プリ
ンタ２９が接続されており、ＣＰＵ２４はそれらの入出
力動作を制御する。ここで、手形発行装置１から送信さ
れて来た手形要件データを通信制御装置２３で受信する
と、ＣＰＵ２４はこの手形要件データを収集して記憶装
置２２に格納し、記憶管理する。記憶装置２２には図４
（Ｂ）に示すように当座口座管理ファイルＡＣＦ、手形
管理ファイルＨＰＦ、手形用紙発注管理ファイルＯＤＦ
が格納されており、当座口座管理ファイルＡＣＦは顧客
毎の当座口座情報を記憶するもので、勘定系ホストコン
ピュータ３から最新データが日毎に当座口座管理ファイ
ルＡＣＦにダウンロードされる。手形管理ファイルＨＰ
Ｆは発行済みの手形レコードを記憶するもので、顧客か
らの手形発行状況を問い合せる手形照会に応答してその
問い合せ条件に合致する手形管理ファイルＨＰＦ内の手
形レコードが顧客側の手形発行装置１へ送信される。手
形用紙発注管理ファイルＯＤＦは顧客毎に手形発注情報
を記憶するもので、手形管理サーバ２は顧客の手元にあ
る残り手形枚数を管理し、残り枚数が基準値以下に達し
た際に、手形用紙の発注有無を顧客に問い合せ、発注を
受けた際に手形用紙発注管理ファイルＯＤＦに発注情報
が書き込まれる。

【００１０】図５は当座口座管理ファイルＡＣＦの１レ
コード分のデータ構造を示したもので、項目毎にフィー
ルドNo、フィールド名称、データ属性、サイズ（フィー
ルド長）が記憶されている。そして、１レコードは「金
融機関番号」、「支店番号」、「当座口座番号」、「顧
客名」、「顧客番号」、「パスワード」、「振出地」、
「手形発注点枚数」の各項目から成る固定長レコードで
ある。なお、上述したように手形管理サーバ２は顧客の
手元にある残り手形枚数が基準値以下となったか否かに
基づいて手形用紙の発注有無の問い合せを行うようにし
ているが、当座口座管理ファイルＡＣＦ内の「手形発注
点枚数」はその基準値を示し、任意に設定可能なもので
ある。

【００１１】図６は手形管理ファイルＨＰＦの１レコー
ド分のデータ構造を示し、項目毎にフィールドNo、フィ
ールド名称、データ属性、サイズが記憶されている。そ
して、１レコードは「手形番号」、「金融機関番号」、
「支店番号」、「当座口座番号」、「手形流通状態フラ
グ」、「支払先名称」、「支払金額」、「支払期日」、
「振出日」、「備考」の各項目から成る固定長レコード
である。そして、フィールドNo「１」〜「５」に対応す
る「手形番号」〜「手形流通状態フラグ」までの各項目
データは、金融機関側で手形用紙の束（手形帳）を顧客
へ配付する際に、手形用紙枚数分のレコードの項目デー
タとして作成されたものである。すなわち、手形帳配付
時に、手形管理ファイルＨＰＦには手形用紙枚数分のレ
コード領域が確保され、その手形番号の項目にはその顧
客に配付された各手形に対応する固有の手形番号（一連
No）がそれぞれ固定的にセットされ、また、手形流通状
態フラグには手形未使用状態を示す「０００」がその初
期値としてセットされる。更に、フィールドNo「５」〜
「１０」に対応する「手形流通状態フラグ」〜「備考」
までの各項目データは、顧客側の手形発行装置１から送
信されて来た手形要件データを受信する毎にその手形に
対応するレコードの項目データとして生成されたもの
で、手形発行によって手形流通状態フラグは手形発行済
みであることを示すために「０００」から「００１」に
更新される。図７は手形流通状態フラグの内容に対応し
て手形が現在どのような状態にあるかの意味を示したも
ので、上述したように「０００」は手形未使用状態、
「００１」は手形発行済み（流通中）を示し、また、
「００２」は金融機関受け入れ済み（支払期日前）、
「００３」は手形代金引き落とし済みを示し、更に、
「００４」は手形発行ミス、「００５」は更改手形、
「００６」は不渡り手形、「００７」は改ざんチェック
中の状態にあることを示している。

【００１２】図８は手形用紙発注管理ファイルＯＤＦの
１レコード分のデータ構造を示したもので、項目毎にフ
ィールドNo、フィールド名称、データ属性、サイズが記
憶されている。そして、１レコードは「金融機関番
号」、「支店番号」、「口座番号」、「顧客名称」、
「金融機関担当者ＩＤ」、「発注手形属性」、「発注手
形枚数」、「発注日」……「備考」の各項目から成る固
定長レコードである。ここで、「発注手形属性」とは約
束手形か為替手形かの手形の種類を示し、また「発注手
形枚数」とはその顧客から発注を受けた手形用紙の総枚
数（手形帳の冊数）を示している。そして、「発注手形
属性」、「発注手形枚数」、「発注日」、「納入希望
日」等の各項目データは顧客から手形用紙が新規発注さ
れる毎に更新される。

【００１３】次に、この手形発行管理システムの動作を
図９〜図１３に示すフローチャートにしたがって説明す
る。ここで、これらのフローチャートに記述されている
各機能を実現するためのプログラムは、手形発行装置
１、手形管理サーバ２において、ＣＰＵ１４（２４）が
読み取り可能なプログラムコードの形態で記憶媒体１７
（２６）に記憶されており、その内容がＲＡＭ１５（２
５）内のワークメモリにロードされている。なお、この
ことは後述する他の各実施形態を説明するためのフロー
チャートについても同様である。図９は手形発行時にお
ける手形発行装置１および手形管理サーバ２側の動作を
示し、（Ａ）は手形発行装置１側の動作、（Ｂ）は手形
管理サーバ２側の動作を示したフローチャートである。
先ず、顧客側の手形発行装置１において、手形を発行す
るときにはダイヤルアップによるインターネット接続に
よって金融機関の手形管理サーバ２を呼び出しておく。
この状態において、手形用紙に印刷されている手形番号
をキー入力すると（ステップＡ１）、この手形番号は手
形管理サーバ２に送信される（ステップＡ２）。ここ
で、手形管理サーバ２は手形番号を受信すると（ステッ
プＢ１）、この手形番号に基づいて手形管理ファイルＨ
ＰＦを検索し、該当する手形番号が有るか（正規な手形
番号か）をチェックし、そのチェック結果を手形発行装
置１に送信すると共に（ステップＢ２）、チェック結果
を判断し、正規な手形番号でなければ、その時点でエラ
ー終了となるが、正規なものであればその後、手形発行
装置１から送信されて来る手形要件データを受信する受
信可能状態となる。

【００１４】一方、手形発行装置１側においては、手形
番号のチェック結果を受信すると（ステップＡ３）、こ
のチェック結果を判別し（ステップＡ４）、入力ミス等
による正規な手形番号でなければエラー終了となり、手
形発行がその時点で禁止されるが正規な手形番号であれ
ば、以降の手形データ入力処理が許可される。先ず、手
形用紙に記入すべき必要事項として“支払先”、“支払
金額”を入力する（ステップＡ５）。次に、支払期日の
自動計算を行うか否かを指示し（ステップＡ６）、自動
計算を行わない場合には、支払期日を手入力するが（ス
テップＡ７）、自動計算を指示した場合には、現在日付
（システム日付）に所定日数（９０日手形であれば、９
０日）が加算されて支払期日が求められる（ステップＡ
８）。そしてシステム日付が振出日として自動生成され
る（ステップＡ９）。次に、“備考”を入力し（ステッ
プＡ１０）、印紙税計算があれば（ステップＡ１１）、
印紙税額が求められる（ステップＡ１２）。

【００１５】このようにして手形用紙の各項目に対応す
る手形要件データが全て揃うと、それを手形項目位置に
自動印刷する処理が行われる（ステップＡ１３）。その
際、印刷エラーの有無をチェックし（ステップＡ１
４）、印刷エラーが有れば、エラー情報を手形管理サー
バ２に送信するが（ステップＡ１６）、印刷が正常に行
われて手形が発行された場合には、手形要件データ、す
なわち支払先、支払金額、支払期日、振出日、備考を含
む伝送レコードを生成し、手形管理サーバ２へ送信する
（ステップＡ１５）。すると、手形管理サーバ２におい
て、手形要件データを受信し（ステップＢ４）、それを
手形管理ファイルＨＰＦのデータ形式に合わせたレコー
ドを作成し（ステップＢ５）、手形管理ファイルＨＰＦ
に書き込む（ステップＢ６）。その際、手形管理ファイ
ルＨＰＦ内の流通状態フラグは「０００（手形未使
用）」から「００１（手形発行済み）」に更新される。
そして、手形管理ファイルＨＰＦ内において当座口座番
号が同一のレコードのうち、手形要件が書き込まれてい
ない未使用レコード件数を検索し、それを手形用紙残り
枚数として求める（ステップＢ７）。なお、印刷エラー
情報が送信されて来た場合には、その手形は使用済みと
して処理される。このようにして求められた手形用紙残
り枚数はその顧客が現在保有する手形用紙の保有量とな
る。そして、その当座口座番号に対応して当座口座管理
ファイルＡＣＦに設定されている手形発注点枚数を読み
出し（ステップＢ８）、この手形発注点枚数を基準値と
して手形用紙残り枚数と比較し（ステップＢ９）、基準
値以下であれば、手形用紙を発注すべきことを促す旨の
情報を手形発行装置１へ送信するが（ステップＢ１
０）、基準値を越えている場合には発注の必要がない旨
の情報を手形発行装置１へ送信する（ステップＢ１
１）。

【００１６】ここで、手形発行装置１においては、手形
用紙の発注有無の問い合せを受信すると（ステップＡ１
７）、その問い合せ情報を判別し（ステップＡ１８）、
発注の必要がある場合には発注画面を表示させ、その画
面内に発注枚数、納入希望日等を入力すると（ステップ
Ａ１９）、それが発注データとして手形管理サーバ２へ
送信される（ステップＡ２０）。手形管理サーバ２は手
形発行装置１から発注データを受信すると（ステップＢ
１２）、その顧客に対応する手形用紙発注管理ファイル
ＯＤＦ内のレコードに発注データを書き込む（ステップ
Ｂ１３）。以下、手形発行の終了指示がステップＡ２
１、Ｂ１４で検出されるまでステップＡ１、Ｂ１に戻
り、上述と同様の動作が繰り返される。したがって、手
形が発行される毎に、その発行タイミングに同期して手
形要件データが手形管理サーバ２へ順次送信されて手形
管理ファイルＨＰＦに記憶管理される。その際、手形用
紙の発注有無の問い合せが手形管理サーバ２からその手
形発行装置１に対して行われる。

【００１７】図１０は上述のような手形発行後におい
て、入力ミス等を発見した場合の動作を示し、（Ａ）は
手形発行装置１側、（Ｂ）は手形管理サーバ２側の動作
を示したフローチャートである。先ず、手形発行装置１
側において、手形発行をミスした手形の番号を入力する
と、手形管理サーバ２へ送信される（ステップＣ１、Ｃ
２）。すると、手形管理サーバ２はこの手形番号を受信
して正規な番号かを手形管理ファイルＨＰＦを検索する
ことによりチェックし、そのチェック結果を手形発行装
置１へ送信すると共に（ステップＤ１、Ｄ２）、そのチ
ェック結果を判定し（ステップＤ３）、正規な番号でな
ければ、エラー終了となるが、その番号が正しければ、
ステップＤ４に進み、受信待ちとなる。手形発行装置１
はそのチェック結果を判別し（ステップＣ３）、正規な
手形番号であれば（ステップＣ４）、手形発行ミスを示
す情報が入力された際にそれを手形管理サーバ２へ送信
する（ステップＣ５、Ｃ６）。手形管理サーバ２は手形
発行ミス情報を受信すると（ステップＤ４）、その手形
番号に対応する手形管理ファイルＨＰＦ内の手形流通状
態フラグを「００４（手形発行ミス）」に更新する（ス
テップＤ５）。そして、手形発行装置１側で処理終了の
指示が有ったことがステップＣ７、Ｄ６で検出されるま
でステップＣ１、Ｄ１に戻り、上述の動作が繰り返され
る。このように手形発行に誤りが生じた際に、当該手形
を無効とする手形発行ミス情報を手形管理サーバ２へ送
信すると、手形管理サーバ２は手形管理ファイルＨＰＦ
内の手形流通状態フラグを更新することによって当該手
形が無効であることを記憶管理するようにしている。

【００１８】図１１は既発行手形の記入内容を変更する
手形更改処理を示し、（Ａ）は手形発行装置１側、
（Ｂ）は手形管理サーバ２側の動作を示したフローチャ
ートである。先ず、手形発行装置１側において、更改対
象手形（既発行手形）の番号を入力すると、手形管理サ
ーバ２へ送信され（ステップＥ１、Ｅ２）、上述と同様
の番号チェック処理が行われる。すなわち、手形管理サ
ーバ２は受信した手形番号をチェックし、そのチェック
結果を手形発行装置１へ送信すると共に（ステップＦ
１、Ｆ２）、そのチェック結果を判定し（ステップＦ
３）、正規な番号でなければ、エラー終了となるが、正
しければ、ステップＦ４に進み、受信待ちとなる。手形
発行装置１は受信した手形番号のチェック結果を判定し
（ステップＥ３、Ｅ４）、正規な番号でなければ、エラ
ー終了となるが、正しければ、次のステップＥ５に進
み、キー入力可能状態となる。ここで、手形更改のため
に新たな手形番号が入力されると、手形発行装置１およ
び手形管理サーバ２との間では上述の同様の手形番号チ
ェック処理が行われる（ステップＥ６〜Ｅ８、Ｆ４〜Ｆ
６）。

【００１９】その結果、正しい番号であると認識された
場合、手形発行装置１側においては、更改される新たな
手形に対する手形要件として支払先、支払金額、支払期
日、振出日、備考、印紙税額を上述した図９のステップ
Ａ５〜Ａ１２と同様に入力・生成する処理が行われる
（ステップＥ９）。そして、手形要件の印刷処理を行う
と共に（ステップＥ１０）、印刷エラーをチェックし
（ステップＥ１１）、正常に手形を発行することができ
た場合にはその手形要件データを手形管理サーバ２へ送
信する（ステップＥ１２）。一方、手形管理サーバ２側
においては、手形更改された新たな手形要件データを受
信すると（ステップＦ７）、更改前の手形要件データを
手形管理ファイルＨＰＦから読み込み（ステップＦ
８）、その手形流通状態フラグを「００５（更改手
形）」に更新する（ステップＦ９）。そして、新たな手
形要件データに基づいて手形管理ファイルＨＰＦのデー
タ形式に合わせたレコードを作成し（ステップＦ１
０）、手形管理ファイルＨＰＦに格納する（ステップＦ
１１）。その際、当該レコードの手形流通状態フラグは
「００１（手形発行済み）」となる。次に、手形用紙発
注有無問い合せ処理および発注処理が行われるが（ステ
ップＦ１２）、これは図９のステップＢ７〜Ｂ１３と同
様であり、また、手形用紙発注有無問い合せに応答して
手形発行装置１側においては、図９のステップＡ１７〜
Ａ２０と同様の手形用紙発注処理が行われる（ステップ
Ｅ１３）。そして、手形発行装置１側で手形更改の終了
が指示されるまで（ステップＥ１４、Ｆ１３）、上述の
動作を繰り返すためにステップＥ１、Ｆ１に戻る。

【００２０】図１２は手形発行装置１から手形管理サー
バ２へ手形発行状況を問い合せる手形照会が行われた際
の動作を示し、（Ａ）は手形発行装置１側、（Ｂ）は手
形管理サーバ２側の動作を示したフローチャートであ
る。先ず、手形発行装置１側において、顧客Noと共にそ
のパスワードを入力すると、それが手形管理サーバ２へ
送信される（ステップＧ１、Ｇ２）。すると、手形管理
サーバ２はそれを受信して当座口座管理ファイルＡＣＦ
を検索し、顧客チェックを行い、そのチェック結果を手
形発行装置１へ送信すると共に（ステップＨ１、Ｈ
２）、そのチェック結果を判定し（ステップＨ３）、何
れか一方でも正しくなければ、エラー終了となるが、正
規の顧客であることを認識すればステップＨ４に進み、
問い合せ条件の受信待ちとなる。手形発行装置１はチェ
ック結果を受信すると（ステップＧ３）、そのチェック
結果を判定し（ステップＧ４）、正しくなければ、エラ
ー終了となるが、正しければ、入力可能状態となる。こ
こで、手形発行状況の問い合せ条件を入力指定する（ス
テップＧ５）。すなわち、この場合の問い合せ条件とし
ては（１）支払先指定、（２）支払金額指定、（３）支
払期日指定、（４）振出日指定、（５）支払先順指定、
（６）支払期日順指定、（７）振出日順指定、（８）手
形番号順指定、（９）流通状態指定等であり、それらを
任意に入力指定すると、入力指定された問い合せ条件は
手形管理サーバ２へ送信される（ステップＧ６）。する
と、手形管理サーバ２はこの問い合せ条件を受信して手
形管理ファイルＨＰＦを検索し、その条件に合致する手
形レコードを読み出して要求元の手形発行装置１へ送信
する（ステップＨ４〜Ｈ６）。手形発行装置１は問い合
せ結果を受信すると（ステップＧ７）、その表示画面を
開き、問い合せ結果を表示出力させる（ステップＧ８、
Ｇ９）。そして、手形発行装置１側で問い合せ終了が指
示されたかを調べ（ステップＧ１０、Ｈ７）、終了指示
が有るまでステップＧ５、Ｈ４に戻り、以下、同様の問
い合せ処理が行われる。ここで、図１４は問い合せ結果
の表示画面例を示し、金融機関名、支店名、当座口座番
号、口座顧客名称に続いて手形毎のレコードがリスト表
示される。この場合、問い合せ条件として支払日順を指
定した表示例で、レコードNoに対応して手形番号、支払
先……手形流通状態の各項目が表示される。

【００２１】図１３は手形管理サーバ２側において、既
発行手形が持ち込まれたときの動作を示したフローチャ
ートである。先ず、持ち込まれた手形現物の磁気記録部
を図示しないＭＩＣＲ（磁気インク文字読取装置）によ
って走査し、金融機関コード、支店コード、口座番号、
手形番号等を受け入れ手形要件として読み取る（ステッ
プＪ１）。すると、この受け入れ手形要件に基づいて手
形管理ファイルＨＰＦが検索され、該当する手形レコー
ドが読み出されて表示出力される（ステップＪ２、Ｊ
３）。ここで、担当者は手形現物と表示内容とを１項目
ずつ目視確認し、手形現物の記入内容と表示内容とを照
合してゆき、その結果、両者が全て一致する場合には照
合ＯＫを指示し、また手形流通中に改ざん等の疑いが有
れば、照合ＮＧを指示する（ステップＪ４）。照合ＯＫ
が指示されたものとすると、その手形レコード内の流通
状態フラグが「００２（金融機関受け入れ済み（支払期
日前））」に更新されるが（ステップＪ５）、照合ＮＧ
が指示された場合には、流通状態フラグに「００７（改
ざんチェック中）」がセットされる（ステップＪ６）。
そして、処理終了が指示されたかを調べ（ステップＪ
７）、処理終了が指示されるまでステップＪ１に戻り、
以下、次の手形現物についても同様の検査を行う。

【００２２】以上のようにこの手形管理発行システムに
おいて、手形発行装置１は手形用紙の各項目に対応する
手形要件データが入力された際に、その手形要件データ
を手形用紙の対応する項目位置に印刷出力して手形を発
行したのち、その手形要件データを通信ネットを介して
手形管理サーバ２へ送信し、手形管理サーバ２は受信し
た手形要件データを手形管理ファイルＨＰＦに書き込ん
で記憶管理するようにしたから、顧客側では手形を発行
するだけでよく、手形管理を金融機関側に委ねることが
でき、顧客側におけるシステムの低価格化を実現するこ
とが可能となる。また、金融機関の手形管理サーバ２に
おいては顧客毎の手形要件データを記憶管理するように
しているので、手形現物が金融機関に持ち込まれた際に
手形要件を入力する必要はなく、それだけオペレータの
負担を軽減することが可能となると共に、入力ミス等の
おそれもなく、安全性を高めることが可能となる。しか
も持ち込まれた手形現物に対応する手形要件データを手
形管理ファイルＨＰＦから読み出して表示出力すること
ができるので、流通段階での改ざん等を容易に発見する
ことが可能となり、セキュリティを向上させることがで
きる。また、手形発行と同時に手形要件データを送信す
るようにしたから、手形発行後、時間をあけて手形要件
を送信するよりも、手形発行直後において、改ざん等の
不正の介入を防止でき、安全性を更に高めることができ
る。

【００２３】また、手形要件入力時において、入力され
た手形番号は手形管理サーバ２へ送信されて番号チェッ
クが行われ、そのチェック結果が手形発行装置１に返信
されて来るので、手形発行装置１はこのチェック結果を
判別し、正しい番号であることを条件に手形要件の入力
を受け付けて手形の発行を許可するが、正しい番号でな
ければ手形発行を禁止するようにしたから、手形発行を
確実に行うことができる。また、手形発行に誤りが生じ
ても、当該手形を無効とする手形無効データを手形管理
サーバ２へ送信すると、手形管理サーバ２はそれを記憶
管理するようにしたから、発行ミスにも対処することが
でき、安全性を確保することが可能となる。更に、手形
更改された場合にも手形更改データを手形管理サーバ２
へ送信して手形を再発行し、手形管理サーバ２は更改前
の手形要件データについては更改されたことを示す状態
フラグをセットし、更改された後の手形要件データを新
たに発行された手形として記憶管理するようにしたか
ら、手形更改にも対処することができる。

【００２４】また、手形発行装置１から手形発行状況を
問い合せる手形照会を行うと、手形管理サーバ２はその
顧客に対応する手形要件データを手形管理ファイルＨＰ
Ｆから検索して要求元の手形発行装置１へ送信するよう
にしたから、手形発行装置１でその検索結果を表示出力
することによって、手形発行装置１側で手形管理を行わ
なくても金融機関側のサービスにより振り出し手形管理
や受け取り手形管理を行うことができる。また、手形管
理サーバ２は手形要件データを手形流通状態フラグと共
に記憶管理し、手形要件を受信した際に手形流通状態フ
ラグに発行済み（流通中）をセットし、既発行手形が金
融機関に持ち込まれた際に、受け入れ済みをセットする
ようにしたから、手形発行装置１はその流通状態を問い
合せることによって顧客は手形が現在流通しているの
か、金融機関に持ち込まれたかを確認することができ
る。また、手形照会時において、支払先指定、支払金額
指定、支払期日指定等を問い合せ条件として手形照会を
行うことができる。更に、手形管理サーバ２は手形発行
装置１側で手形発行が行われる毎に、当該顧客の手形用
紙の残り枚数が予め設定した発注枚数か否かを調べ、手
形用紙の残りが発注枚数になった場合には、手形用紙の
発注有無をその顧客の手形発行装置１へ問い合せるよう
にしたから、手形発行装置１はその問い合せによって手
形用紙を金融機関に対して発注することができるので、
用紙切れを未然に防止することができる。つまり、手形
発行時の顧客への付加サービスとして手形用紙の発注有
無を問い合せるため、顧客にとって迅速な発注が可能と
なり、また金融機関にとっても迅速なサービスによって
自己の金融機関への利用機会が増え、取引の増大を期待
することが可能となる。

【００２５】（第２実施形態）図１５はこの発明の第２
実施形態を説明するための要部を示したフローチャート
である。すなわち、図１５は手形発行時において、
（Ａ）は手形発行装置１側、（Ｂ）は手形管理サーバ２
側の動作を示したフローチャートである。なお、第１実
施形態は手形発行時において、手形現物に印刷されてい
る手形番号をキー入力するようにしたが、この第２実施
形態は手形番号を手形管理サーバ２から取り寄せるよう
にしたものである。すなわち、手形管理サーバ２は手形
管理ファイルＨＰＦに手形番号を管理しているので、手
形発行装置１は顧客の当座口座番号に対応する手形番号
のうち未使用番号を取り寄せるようにしている。先ず、
手形発行装置１において、当座口座番号を入力すると、
手形管理サーバ２へ送信される（ステップＫ１、Ｋ
２）。すると、手形管理サーバ２は、当座口座管理ファ
イルＡＣＦを参照して当座口座番号のチェックを行う
（ステップＬ１、Ｌ２）。その結果、当座口座番号が正
しくなければ、エラー送信を行ってエラー終了となるが
（ステップＬ６）、正しければ、その当座口座番号に対
応する未使用手形番号を検索する（ステップＬ３）。こ
の場合、手形管理ファイルＨＰＦ内のレコードのうち、
手形流通状態フラグが「０００（手形未使用）」のレコ
ードを検索するが、その際、最初に出現するフラグ「０
００」を持ったレコード内の手形番号を未使用手形番号
として検索する。その結果、未使用手形番号を検索する
ことができなかった場合には、エラー送信を行ってエラ
ー終了となるが（ステップＬ４、Ｌ６）、検索すること
ができた場合にはその手形番号を要求元の手形発行装置
１へ送信する（ステップＬ４、Ｌ５）。

【００２６】すると、手形発行装置１はそれを受信して
検索結果を判定し（ステップＫ３、Ｋ４）、検索エラー
であることを認識すると、その時点でエラー終了となる
が、検索が正常に行われた場合には、その未使用手形番
号を顧客に確認させるために未使用手形番号を表示出力
させて顧客からの指示待ちとなる。この状態で、その未
使用手形番号を使用して手形を発行すべき旨の指示が有
ったか否かに応じて手形発行ＯＫ、ＮＧを手形管理サー
バ２へ送信し（ステップＫ５〜Ｋ７）、手形管理サーバ
２はそれを判定し（ステップＬ７、Ｌ８）、手形発行Ｏ
Ｋが指示されたことを条件に、手形発行装置１、手形管
理サーバ２は以下、上述した図９と同様の処理に移る。
すなわち、手形発行装置１は図９のステップＡ５〜Ａ２
０に対応する手形要件入力・生成処理、印刷処理、手形
要件送信処理、手形用紙発注処理を実行し（ステップＫ
８）、また、手形管理サーバ２は図９のステップＢ４〜
Ｂ１３に対応する手形管理ファイル書き込み処理、手形
用紙発注有無問い合せ処理、受注処理を実行する（ステ
ップＬ９）。そして、ステップＫ９、Ｌ１０で手形発行
の終了指示が検出されるまで、ステップＫ２、Ｌ１に戻
り、上述の動作が繰り返される。したがって、顧客は手
形発行を連続的に行う場合には、その都度、口座番号を
入力する必要はない。以上のようにこの第２実施形態に
おいては、手形管理サーバ２側で管理されている手形番
号のうち顧客が現在発行しようとする手形の番号（未使
用番号）を手形発行装置１へ通知するようにしたから、
手形を発行する都度、顧客は手形番号を入力するという
手間を省くことができると共に、手形発行に係わるセキ
ュリティの向上にもなる。

【００２７】（第３実施形態）以下、図１６および図１
７を参照してこの発明の第３実施形態を説明する。な
お、上述した第１実施形態は顧客が１つの金融機関と取
引がある場合を例示したが、実際には複数の金融機関と
取引がある場合が多く、また、顧客によって発行された
手形は、金融機関に戻って来るが、必ずしも支払い先の
金融機関とは限らず、持ち込み人と取引のある金融機関
に持ち込まれることがある。したがって、この第３実施
形態においては、複数の金融機関に対して手形発行を別
個に行い、また金融機関に既発行手形が持ち込まれた際
にその手形が他の金融機関のものであれば、当該他の金
融機関との間で手形管理データの受け渡しを行うように
したものである。先ず、手形発行時において、複数の金
融機関と取引がある場合、手形発行装置１は各金融機関
を順次指定して手形発行を別個に行う。例えば、Ａ銀
行、Ｂ銀行、Ｃ銀行と取引がある場合において、手形発
行装置１はＡ銀行側の手形管理サーバ２と接続され、Ａ
銀行分の手形を発行し、その手形要件データをＡ銀行側
に送信したのち、Ｂ銀行側の手形管理サーバ２と接続さ
れ、Ｂ銀行分の手形を発行してその手形要件データをＢ
銀行側に送信するというように手形発行を別個に行う。
すると、Ａ銀行、Ｂ銀行、Ｃ銀行の各手形管理サーバ２
は、手形発行装置１から送信されて来た手形要件データ
を自行の手形管理データとして記憶する。

【００２８】ここで、既発行手形が何れかの銀行に持ち
込まれたものとすると、手形管理サーバ２は図１６のフ
ローチャートにしたがって動作する。先ず、ＭＩＣＲリ
ーダにより受け入れ手形要件が入力されると（ステップ
Ｍ１）、その手形要件に基づいて支払先が自行か他行か
を判断し（ステップＭ２）、自行であれば、上述した図
１３のステップＪ２〜Ｊ７と同様の処理（ステップＭ３
〜Ｍ８）が実行される。すなわち受け入れ手形要件に基
づいて手形管理ファイルＨＰＦから読み出された手形レ
コードが表示出力されると共に、手形現物と表示内容と
の照合結果に基づいてその手形レコード内の手形流通状
態フラグが更新される。一方、Ａ銀行にＢ銀行、Ｃ銀行
のように他行の手形が持ち込まれた場合には、受け入れ
手形要件を当該他の銀行へ送信することによって手形レ
コードの問い合せを行い、これに応答して当該他の銀行
から送信されて来た手形レコードを受信すると、それを
自己の手形管理ファイルＨＰＦに追加登録する（ステッ
プＭ９、Ｍ１０）。そして、他行から送信されて来た手
形レコードを表示出力させ（ステップＭ４）、以下、上
述と同様の処理が行われる（ステップＭ５〜Ｍ８）。

【００２９】図１７は銀行間での手形レコード受け渡し
状態を図式化したもので、Ａ銀行にＢ銀行支払先手形お
よびＣ銀行支払先手形が持ち込まれた場合、Ａ銀行の手
形管理サーバ２はその手形管理ファイルＨＰＦに、持ち
込まれたＢ銀行、Ｃ銀行の手形レコードを追加登録して
記憶管理する。したがって、他行の手形であっても、顧
客が手形発行時に作成した手形要件データを入手するこ
とができるため、手形要件データの入力操作が不要とな
ると共に、現物手形と照合することができ、更に他行の
手形レコードについても現物手形との照合結果に基づい
て手形流通状態を更新するようにしたから、手形発行装
置１からＡ銀行に対して手形状況の照会が要求された際
に、Ａ銀行に持ち込まれたＢ銀行やＣ銀行の手形流通状
況を顧客に通知することができる。

【００３０】（第４実施形態）以下、図１８〜図２０を
参照してこの発明の第４実施形態を説明する。なお、上
述した第３実施形態は、複数の金融機関と取引がある顧
客が手形を発行する際に、各金融機関を順次指定して手
形要件データを別個に送信すると共に手形状況の問い合
せ時にも各金融機関に対して別個に行うようにしたが、
顧客は複数の金融機関のうち主に特定の金融機関（メイ
ンバンク）と取引することが多いため、この第４実施形
態は、手形発行や手形状況の問い合せをメインバンクに
対してのみ行うようにしたものである。図１８は手形発
行時の動作を示し、（Ａ）は手形発行装置１側、（Ｂ）
はメインバンクの手形管理サーバ２側の動作を示したフ
ローチャートである。先ず、手形発行装置１側において
金融機関番号、支店番号を入力すると共に（ステップＮ
１）、手形番号を入力すると（ステップＮ２）、入力さ
れた各データはメインバンクの手形管理サーバ２へ送信
される（ステップＮ３）。すると、メインバンクの手形
管理サーバ２はそれを受信すると（ステップＰ１）、金
融機関番号、支店番号に基づいて他の金融機関かを調べ
（ステップＰ２）、自己の金融機関が指定された場合で
あれば、第１実施形態と同様の手形番号のチェック処理
および送信処理を行うと共に（ステップＰ３）、そのチ
ェック結果を判定し（ステップＰ４）、正規の手形番号
でなければ、エラー終了となるが、正しければ、ステッ
プＰ８に進み、手形要件の受信待ちとなる。また、他の
金融機関が指定された場合であれば、当該他の金融機関
へ手形番号を送信し（ステップＰ５）、それに応答して
送られて来る手形番号のチェック結果を受信すると（ス
テップＰ６）、そのチェック結果を判定する（ステップ
Ｐ７）。その結果、正規の手形番号でなければエラー終
了となるが、正しければ、手形番号を手形発行装置１へ
送信する（ステップＰ３）。

【００３１】手形発行装置１は手形番号のチェック結果
を受信すると（ステップＮ４）、そのチェック結果を判
定し（ステップＮ５）、正しくなければエラー終了とな
るが、正しければ、手形要件として支払先、支払金額、
支払期日、振出日等を上述した図９のステップＡ５〜Ａ
１２と同様に入力・生成する処理が行われる（ステップ
Ｎ６）。そして、手形要件の印刷処理を行うと共に（ス
テップＮ７）、印刷エラーをチェックし（ステップＮ
８）、正常に手形を発行することができた場合にはその
手形要件データをメインバンクの手形管理サーバ２へ送
信する（ステップＮ９）。ここで、メインバンクの手形
管理サーバ２は手形要件データを受信すると（ステップ
Ｐ８）、この手形要件データに基づいて手形管理ファイ
ルＨＰＦのデータ形式に合わせたレコードを作成し（ス
テップＰ９）、自己の手形管理ファイルＨＰＦに書き込
む（ステップＰ１０）。そして、この手形管理ファイル
ＨＰＦに書き込んだ手形レコードは他の金融機関を支払
先とするかを判断し（ステップＰ１１）、他の金融機関
であれば、この手形レコードをその金融機関へ送信する
（ステップＰ１２）。ここで、当該他の金融機関はメイ
ンバンクから送信されて来た手形要件データを自己の手
形管理ファイルＨＰＦに書き込んで記憶管理する。そし
て、手形発行装置１側で手形発行の終了が指示されるま
で（ステップＮ１０、Ｐ１３）、上述の動作を繰り返す
ためにステップＮ１、Ｐ１に戻る。図１９は手形発行前
の動作を図式化したもので、顧客と取引のあるＡ銀行、
Ｂ銀行……のうちＡ銀行がメインバンクである場合に、
手形発行装置１は各銀行を支払先とする手形の要件デー
タを全てＡ銀行側の手形管理サーバ２へ送信する。する
と、Ａ銀行側では各銀行の手形要件データをそれぞれ記
憶管理すると共に、他の銀行の手形であれば、その手形
要件データはその銀行へ配信される。

【００３２】図２０は手形状況問い合せ時におけるメイ
ンバンク側の手形管理サーバ２の動作を示したフローチ
ャートである。手形発行装置１側で入力された顧客Noお
よびパスワードを受信すると（ステップＱ１）、当座口
座管理ファイルＡＣＦを検索し、顧客チェックを行い、
そのチェック結果を手形発行装置１へ送信すると共に
（ステップＱ２）、そのチェック結果を判定する（ステ
ップＱ３）。ここで、何れか一方でも正しくなければ、
エラー終了となるが、正規な顧客であることを認識すれ
ばステップＱ４に進み、問い合せ条件の受信待ちとな
る。そして、手形発行装置１で入力された問い合せ条件
が送信されて来ると、それを受信して手形管理ファイル
ＨＰＦを検索し、その条件に合致する手形レコードを抽
出すると共に（ステップＱ４、Ｑ５）、この手形レコー
ド内の金融機関番号、支店番号に基づいて自行（メイン
バンク）に該当するレコードかを調べる（ステップＱ
６）。ここで、自行レコードであれば、問い合せ条件に
合致する全てのレコードを抽出し終ったかを調べ（ステ
ップＱ９）、その抽出が終るまでステップＱ６に戻る。
いま、他の銀行のレコードであれば、その銀行の手形管
理サーバ２を指定してレコード要求を行い、それに応答
して送信されて来た最新レコードを受信すると、その最
新レコードを条件に合致する抽出レコードとすると共
に、その最新レコードに対応する手形管理ファイルＨＰ
Ｆ内の手形レコードを最新レコードに基づいて更新する
（ステップＱ７、Ｑ８）。このようにして問い合せ条件
に合致する全てのレコードを抽出し終ったらステップＱ
１０に進み、抽出レコードを要求元の手形発行装置１へ
送信し、問い合せ終了が指示されるまでステップＱ４に
戻り、上述の動作が繰り返される。

【００３３】このように第４実施形態においては、手形
発行や手形状況の問い合せを常にメインバンクを通して
行うため、顧客にとって通信先が１個所で済み、運用上
面倒がなく、しかも金融機関の指定を間違えることもな
い。また、メインバンクにはその顧客と取引のある全て
の金融機関の手形が一括管理されているので、手形状況
の問い合せを行った場合、その照会結果を顧客側でマー
ジする必要はなく、それだけ作業を簡素化することがで
きる。また、金融機関にとってはメインバンク化によっ
て優良顧客の囲い込みが可能となり、営業効率の向上を
期待することができる。

【００３４】なお、上述した各実施形態においては、イ
ンターネットを利用するようにしたが、これに限らず、
また、手形要件印刷発行プログラムを手形発行装置１側
に常駐させずに、金融機関側の手形管理サーバ２に持た
せ、顧客側で手形を発行する際に、手形要件印刷プログ
ラムを手形管理サーバ２から手形発行装置１へダウンロ
ードするようにしてもよい。このようにすれば、プログ
ラムの変更等にも容易に対処することが可能となる。

【００３５】

【発明の効果】この発明によれば、手形発行装置は入力
された手形データを手形用紙に印刷して手形を発行する
と共に、その手形データを金融機関側の手形管理装置へ
送信し、手形管理装置はこの手形データを受信して記憶
管理するようにしたから、金融機関の顧客側では手形用
紙に必要事項を自動印刷して手形を発行するだけで、手
形管理を金融機関側に委ねることができ、金融機関側で
は手形現物が持ち込まれた際に手形現物から手形データ
を入力する操作が不要となると共に、流通段階での改ざ
ん等をチェックすることができ、しかも通信ネットを介
して顧客側へ各種のサービスを提供することが可能とな
り、手形発行管理を確実かつ安全に行うことができる。

【図面の簡単な説明】

【図１】顧客側の手形発行装置１と金融機関側の手形管
理サーバ２を備えた手形管理発行システムを説明するた
めのシステム構成図。

【図２】（Ａ）は手形発行装置１の全体構成を示したブ
ロック図、（Ｂ）は手形管理サーバ２側へ送信されるＲ
ＡＭ１５内の手形要件データを示した図。

【図３】手形用紙の印刷例を示した図。

【図４】（Ａ）は手形管理サーバ２の全体構成を示した
ブロック図、（Ｂ）は記憶装置２２内の各種ファイルを
示した図。

【図５】当座口座管理ファイルＡＣＦのデータ構造を示
した図。

【図６】手形管理ファイルＨＰＦのデータ構造を示した
図。

【図７】手形流通状態フラグを説明するための図。

【図８】手形用紙発注管理ファイルＯＤＦのデータ構造
を示した図。

【図９】手形発行時の動作を示し、（Ａ）は手形発行装
置１側、（Ｂ）は手形管理サーバ２側の動作を示したフ
ローチャート。

【図１０】手形発行システム時の動作を示し、（Ａ）は
手形発行装置１側、（Ｂ）は手形管理サーバ２側の動作
を示したフローチャート。

【図１１】手形更改時の動作を示し、（Ａ）は手形発行
装置１側、（Ｂ）は手形管理サーバ２側の動作を示した
フローチャート。

【図１２】手形発行状況問い合せ時の動作を示し、
（Ａ）は手形発行装置１側、（Ｂ）は手形管理サーバ２
側の動作を示したフローチャート。

【図１３】既発行手形が金融機関に持ち込まれた際の手
形管理サーバ２側の動作を示したフローチャート。

【図１４】手形発行装置１側における問い合せ状況画面
を示した図。

【図１５】第２実施形態における手形発行時の動作を示
し、（Ａ）は手形発行装置１側、（Ｂ）は手形管理サー
バ２側の動作を示したフローチャート。

【図１６】第３実施形態において、既発行手形が金融機
関に持ち込まれた際の手形管理サーバ２側の動作を示し
たフローチャート。

【図１７】第３実施形態において、金融機関同士で手形
管理データが受け渡される様子を図式化した図。

【図１８】第４実施形態において、手形発行時の動作を
示し、（Ａ）は手形発行装置１側、（Ｂ）はメインバン
クの手形管理サーバ２側の動作を示したフローチャー
ト。

【図１９】第４実施形態において、手形発行時の動作を
図式的に示した図。

【図２０】第４実施形態において、手形発行装置１がメ
インバンクの手形管理サーバ２に対して手形発行状況を
問い合せた際の動作を示したフローチャート。

【符号の説明】 １ 手形発行装置 ２ 手形管理サーバ ３ 勘定系ホストコンピュータ １２ 手形券面印刷プリンタ １３、２３ 通信制御装置 １４、２４ ＣＰＵ １６、２２ 記憶装置 １７、２６ 記憶媒体 １８ 入力装置 １９ 表示装置 ＡＣＦ 当座口座管理ファイル ＨＰＦ 手形管理ファイル ＯＤＦ 手形用紙発注管理ファイル

Claims (13)

【特許請求の範囲】
1. 【請求項１】金融機関の顧客側に設置された手形発行装
   置と、金融機関に設置された手形管理装置との間で通信
   ネットを介してデータの送受信を行う手形発行管理シス
   テムであって、 手形発行装置は、手形用紙の各項目に対応する手形デー
   タを入力する入力手段と、この入力手段から入力された
   手形データを手形用紙の対応する項目位置に印刷出力し
   て手形を発行する手形発行手段と、この手形発行手段に
   よって発行された手形に対応する前記手形データを金融
   機関側の手形管理装置へ送信する送信手段とを具備し、 手形管理装置は、顧客側の手形発行装置から送信されて
   来た手形データを受信する受信手段と、この受信手段で
   受信した手形データを記憶管理する手形記憶管理手段と
   を具備したことを特徴とする手形発行管理システム。
2. 【請求項２】手形管理装置は、金融機関に既発行手形が
   持ち込まれた際に、当該手形の記入内容とそれに対応す
   る前記手形データとを照合するためにその手形データを
   前記手形記憶管理手段から読み出して出力するようにし
   たことを特徴とする請求項１記載の手形発行管理システ
   ム。
3. 【請求項３】手形発行装置側において、前記手形発行手
   段によって手形が発行された発行タイミングに同期して
   前記送信手段は、その手形データを手形管理装置へ送信
   し、手形管理装置は、手形発行と同時に送信されて来た
   手形データを記憶管理するようにしたことを特徴とする
   請求項１記載の手形発行管理システム。
4. 【請求項４】手形管理装置は、手形発行装置から送信さ
   れて来た手形番号が正規な手形番号か否かをチェックし
   てそのチェック結果を元の手形発行装置へ送信し、 手形発行装置は、前記チェック結果を判断し、正規な手
   形番号であることを条件に手形発行を実行するようにし
   たことを特徴とする請求項１記載の手形発行管理システ
   ム。
5. 【請求項５】手形発行装置側において、手形発行に誤り
   が生じた際に前記送信手段は、当該手形を無効とする手
   形無効データを送信し、 手形管理装置は、前記手形無効データを前記手形記憶管
   理手段内の当該手形データに関連付けて記憶管理するよ
   うにしたことを特徴とする請求項１記載の手形発行管理
   システム。
6. 【請求項６】手形発行装置側において、既発行手形の記
   入内容を変更する手形更改が行われた際に、前記手形発
   行手段は手形更改されたデータに基づいて手形を再発行
   し、前記送信手段は当該手形更改データを手形管理装置
   へ送信し、 手形管理装置は、前記手形更改データに基づいて、前記
   手形記憶管理手段内に格納されている更改前の当該手形
   データが更改されたことを示すと共に、手形更改データ
   を新たな手形データとして記憶管理するようにしたこと
   を特徴とする請求項１記載の手形発行管理システム。
7. 【請求項７】手形管理装置は、手形発行装置からの手形
   発行状況を問い合せる手形照会に応答してその顧客に対
   応する手形データを前記手形記憶管理手段から読み出し
   て要求元の手形発行装置へ送信するようにしたことを特
   徴とする請求項１記載の手形発行管理システム。
8. 【請求項８】手形管理装置は、金融機関に既発行手形が
   持ち込まれた際に、手形受け入れ済みか手形流通中かを
   示す手形流通状況を前記手形記憶管理手段内の当該手形
   データに関連付けて記憶管理し、手形発行装置からの手
   形照会に応答して手形流通状況を要求元の手形発行装置
   へ送信するようにしたことを特徴とする請求項１記載の
   手形発行管理システム。
9. 【請求項９】手形管理装置は、手形発行装置から手形デ
   ータが送信されて来る毎に、当該顧客の手形用紙の残り
   が所定枚数か否かを検出し、手形用紙の残りが所定枚数
   になった場合に手形用紙の発注有無を問い合せる発注問
   い合せ情報をその顧客の手形発行装置へ送信し、 手形発行装置は、手形管理装置から送信されて来た発注
   問い合せ情報を出力するようにしたことを特徴とする請
   求項１記載の手形発行管理システム。
10. 【請求項１０】手形発行装置は、次に発行すべき手形の
    手形番号を手形管理装置に要求し、その要求に応答して
    手形管理装置は、未使用の手形番号を検索して要求元の
    手形発行装置へ送信するようにしたことを特徴とする請
    求項１記載の手形発行管理システム。
11. 【請求項１１】複数の金融機関と取引のある顧客側の手
    形発行装置において、前記送信手段は複数の金融機関を
    順次指定すると共に、指定した金融機関側の手形管理装
    置へ手形データを送信し、 指定された金融機関側の手形管理装置は、手形発行装置
    から送信されて来た手形データを受信した際に、当該手
    形データをそれぞれ記憶管理し、 既発行手形がその支払先ではない他の金融機関に持ち込
    まれた際に、当該他の金融機関の手形管理装置は、支払
    先金融機関の手形管理装置に記憶管理されている手形デ
    ータの送信を要求し、これに応答して支払先金融機関の
    手形管理装置から送信されて来た手形データを記憶管理
    するようにしたことを特徴とする請求項１記載の手形発
    行管理システム。
12. 【請求項１２】複数の金融機関と取引のある顧客側の手
    形発行装置において、前記送信手段は複数の金融機関の
    うち特定の金融機関をメイン金融機関として指定してそ
    の手形管理装置へ各金融機関の手形データを送信し、 前記メイン金融機関側の手形管理装置は、手形発行装置
    から送信されて来た各金融機関の手形データを一括して
    記憶管理すると共に、前記複数の金融機関のうち自己を
    除く他の金融機関の手形管理装置へ当該金融機関の手形
    データをそれぞれ配信し、 前記他の金融機関側の手形管理装置は、メイン金融機関
    から配信されて来た手形データを受信してそれぞれ記憶
    管理するようにしたことを特徴とする請求項１記載の手
    形発行管理システム。
13. 【請求項１３】コンピュータに対して、 金融機関の顧客側に設置された手形発行装置から手形用
    紙の各項目に対応して入力された手形データを手形用紙
    の対応する項目位置に印刷出力して手形を発行する機能
    と、発行された手形に対応する手形データを手形発行装
    置から金融機関側の手形管理装置へ送信する機能と、 手形発行装置から送信されて来た手形データを受信して
    記憶管理する機能を実現させるためのプログラムを記録
    した記録媒体。