JP6114850B1 - 融資事務帳票管理システムおよび方法 - Google Patents

Abstract

【課題】融資事務処理において、徴求書類の確認に非常に時間を要する。徴求書類の種類が多く、契約内容によって徴求書類も変わってくるため、徴求書類の過不足が発生している。また、徴求書類の判断は、担当者の経験にも大きく依存する。そして、本来であれば、複数の点検案件としてフロントからミドルバックに依頼すべき徴求書類を、１案件にまとめて投入し依頼してくるケースもある。【解決手段】徴求書類一覧画面および案件分割画面を提供する。徴求書類一覧画面には、予め登録された契約書データの入力値などによって、その契約に必要とされる書類の種類が把握し易いように、書類ごとに、書類名を含む書類欄が一覧表示される。徴求書類一覧画面により徴求書類の登録および過不足確認を行なうことができる。また、案件分割画面では、分割された親案件と子案件のそれぞれに対し、登録された徴求書類を割り当てていくことができる。【選択図】図７

Description

本発明は、融資事務帳票管理システムおよび方法に関する。

インターネットサービスが拡大する中、融資取引業務全般が現物を伴う（紙ベースの）処理であるため、顧客、ならびに金融機関におけるフロントオフィス（以下、「フロント」という）およびミドルバックオフィス（以下、「ミドルバック」という）などにおいて様々な負担（作業負荷および所要時間の増大など）が発生しており、融資取引業務の電子化が望まれている。なお、フロントとは、顧客と直接連絡をとるなどして、融資取引の条件を決定し、契約を締結する金融機関内の部署である。また、ミドルバックとは、顧客とフロントとの間で締結した契約内容の点検や、当該契約の実行手続（入金手続など）を行なう部署である。なお、フロントのうち、稟議書の形式点検や、融資実行の際の必要書類（以下、「徴求書類」という）の内容確認などチェック業務を行なう部門をフロントミドルということもある。

特に、フロントからミドルバックへ融資契約の実行依頼を行なう際、フロントから契約書や徴求書類の現物をミドルバックへ送付し、ミドルバックにて契約内容の点検を行っている。また、ミドルバックにおける点検において、不備があった場合は、ミドルバックからフロントに対して不備を指摘し、フロントにて補完対応（契約書の再作成など）を行なった上で、再度、契約書をミドルバックに送付するなどしている。

このように、契約書や徴求書類の現物による融資事務処理を行なっているため、現状の融資事務処理には、現物移動による時間を要する点、契約内容不備への早期対応が十分でない点、契約内容の不備に対するフロント−ミドルバック間の情報共有が十分でない点、などにおいて課題がある。そのため、契約書や徴求書類をスキャニングにより電子データ化し、融資事務処理のペーパーレス化が望まれている。さらに、契約書などの電子データ化により、融資事務処理への電子署名および印鑑照合の活用も期待されている。

しかしながら、例え、融資事務処理のペーパーレス化が実現しても、従来からの問題点である、徴求書類の確認に非常に時間を要する点は課題として残っており、この点もペーパーレス化と併せて解決することが求められている。徴求書類の確認に時間がかかる主な理由として以下の点が挙げられる。徴求書類の種類が多く、契約内容によって徴求書類も変わってくるため、フロントからミドルバックへの点検依頼時に、徴求書類の過不足が発生している。また、ミドルバックでの点検時にも、契約内容ごとに都度、徴求書類として何が必要であるかを担当者が確認する必要がある。また、徴求書類の判断は、フロントおよびミドルバック担当者の経験にも大きく依存する。さらに、本来であれば、複数の点検案件としてフロントからミドルバックに依頼すべき徴求書類を、１案件にまとめて投入し依頼してくるケースもある。このように、融資事務処理のペーパーレス化と共に、点検作業における徴求書類確認の効率化が求められている。

本発明は、このような目的を達成するために、フロントおよびミドルバックにおける融資事務を管理するサーバコンピュータであって、前記サーバコンピュータは、
前記フロントが利用する第１のコンピュータからの要求に応じて、徴求書類一覧画面を前記第１のコンピュータに表示させ、前記徴求書類一覧画面は、予め登録されている融資契約の内容に係るデータに基づいて徴求書類の種類およびその必要レベルを表示し、
前記第１のコンピュータから、１つまたは複数の徴求書類に係る徴求書類データを受信および登録し、
前記登録した徴求書類データに基づいて、登録された前記徴求書類の前記種類を判別し、
前記第１のコンピュータから前記ミドルバックが利用する第２のコンピュータへ融資契約の点検依頼を行なうための連絡票データを受信し、
前記受信した連絡票データと、前記受信した徴求書類データとを関連付け、
前記第１のコンピュータからの回付指示に応答して、前記連絡票データを前記第２のコンピュータに回付し、
前記第２のコンピュータからの要求に応じて、登録した前記徴求書類の表示を含む前記徴求書類一覧画面を前記第２のコンピュータに表示させ、前記徴求書類の前記必要レベルに基づいて必要な前記徴求書類が全て登録されていない場合、前記第２のコンピュータからの点検完了要求を受け付けないように前記第２のコンピュータに制御させる
ように構成されたことを特徴とする。

また、前段落に記載の発明において、前記徴求書類一覧画面を用いて、前記第１のコンピュータおよび／または前記第２のコンピュータにより、前記登録した徴求書類の前記種類を変更できることを特徴とする。

さらに、前２段落のいずれか１に記載の発明において、前記徴求書類の前記種類および前記必要レベルは、カスタマイズ可能であることを特徴とする。

また、前３段落のいずれか１に記載の発明において、前記サーバコンピュータは、前記第２のコンピュータからの要求に応じて、案件分割画面を前記第２のコンピュータに表示させ、前記案件分割画面は、１つの前記連絡票データを親案件とし、１つまたは複数の別の連絡票データを子案件とするように案件を分割し、前記関連付けられた徴求書類データにおける前記連絡票データとの関連付けを削除し、前記親案件および前記子案件のそれぞれに対して、前記徴求書類データを関連付けるための画面であり、
前記第２のコンピュータから割当て結果データを受信し、前記割当て結果データは、前記徴求書類データを、前記親案件および前記子案件のいずれかと関連付けるかを示すデータであり、
前記割当て結果データを受信すると、前記連絡票データに基づいて前記別の連絡票データを作成し、前記徴求書類データを徴求書類ごとに、前記親案件または前記子案件に関連付ける
ようにさらに構成されたことを特徴とする。

さらに、前段落に記載の発明において、前記案件分割画面を用いて、前記第２のコンピュータにより、前記徴求書類の写しを作成することができ、前記写しも前記親案件および前記子案件のいずれかに関連付けられることを特徴とする。

また、本発明は、フロントおよびミドルバックにおける融資事務を管理するサーバコンピュータによって実行される方法であって、前記方法は、
前記フロントが利用する第１のコンピュータからの要求に応じて、徴求書類一覧画面を前記第１のコンピュータに表示させるステップであって、前記徴求書類一覧画面は、予め登録されている融資契約の内容に係るデータに基づいて徴求書類の種類およびその必要レベルを表示する、ステップと、
前記第１のコンピュータから、１つまたは複数の徴求書類に係る徴求書類データを受信および登録するステップと、
前記登録した徴求書類データに基づいて、登録された前記徴求書類の前記種類を判別するステップと、
前記第１のコンピュータから前記ミドルバックが利用する第２のコンピュータへ融資契約の点検依頼を行なうための連絡票データを受信するステップと、
前記受信した連絡票データと、前記受信した徴求書類データとを関連付けるステップと、
前記第１のコンピュータからの回付指示に応答して、前記連絡票データを前記第２のコンピュータに回付するステップと、
前記第２のコンピュータからの要求に応じて、登録した前記徴求書類の表示を含む前記徴求書類一覧画面を前記第２のコンピュータに表示させるステップであって、前記徴求書類の前記必要レベルに基づいて必要な前記徴求書類が全て登録されていない場合、前記第２のコンピュータからの点検完了要求を受け付けないように前記第２のコンピュータに制御させる、ステップと
を備えたことを特徴とする。

さらに、本発明は、フロントおよびミドルバックにおける融資事務を管理する方法をサーバコンピュータに実行させるコンピュータプログラムであって、前記コンピュータプログラムは、前記サーバコンピュータによって実行されると、前記サーバコンピュータに、
前記フロントが利用する第１のコンピュータからの要求に応じて、徴求書類一覧画面を前記第１のコンピュータに表示させるように制御させ、前記徴求書類一覧画面は、予め登録されている融資契約の内容に係るデータに基づいて徴求書類の種類およびその必要レベルを表示し、
前記第１のコンピュータから、１つまたは複数の徴求書類に係る徴求書類データを受信および登録し、
前記登録した徴求書類データに基づいて、登録された前記徴求書類の前記種類を判別し、
前記第１のコンピュータから前記ミドルバックが利用する第２のコンピュータへ融資契約の点検依頼を行なうための連絡票データを受信し、
前記受信した連絡票データと、前記受信した徴求書類データとを関連付け、
前記第１のコンピュータからの回付指示に応答して、前記連絡票データを前記第２のコンピュータに回付し、
前記第２のコンピュータからの要求に応じて、登録した前記徴求書類の表示を含む前記徴求書類一覧画面を前記第２のコンピュータに表示させるように制御させ、前記徴求書類の前記必要レベルに基づいて必要な前記徴求書類が全て登録されていない場合、前記第２のコンピュータからの点検完了要求を受け付けないように前記第２のコンピュータに制御させる
ことを特徴とする。

以上説明したように、本発明により、融資事務処理のペーパーレス化と共に、徴求書類の確認支援、および案件分割を行なうことができ、点検作業における徴求書類確認の効率化を図ることができる。

本発明の一実施形態に係るシステム構成を示す図である。 本発明の一実施形態に係る融資事務処理を示すフローチャートである。 本発明の一実施形態に係る稟議書データ記憶部に格納されたデータを示す図である。 本発明の一実施形態に係る契約書データ記憶部に格納されたデータを示す図である。 本発明の一実施形態に係る徴求書類データ記憶部に格納されたデータを示す図である。 本発明の一実施形態に係る連絡票データ記憶部に格納されたデータを示す図である。 本発明の一実施形態に係る徴求書類一覧画面の画面イメージを示す図である。 本発明の一実施形態に係る案件分割画面の画面イメージを示す図である。

本発明の実施形態に係る融資事務管理システムの概要を説明する。図１は、本発明の一実施形態に係るシステム構成を示す図である。図１において、データセンタなどに設置された融資事務管理サーバ１０１は、ネットワーク１０２（例えば、金融機関のイントラネット）を介して、フロント端末１０３、およびミドルバック端末１０４と通信を行なうように構成されている。なお、図１において、融資事務管理サーバ１０１を単一のサーバとして示しているが、複数のサーバによる分散システムとして構成することも可能である。

フロント端末１０３は、金融機関におけるフロント担当者が使用する端末である。フロント担当者は、フロント端末１０３を用いて、稟議書や契約書を作成する。作成された稟議書データや契約書データは、フロント端末１０３から融資事務管理サーバ１０１に送信される。送信された稟議書データや契約書データは融資事務管理サーバ１０１に格納され、フロント端末１０３を介して回覧されフロントの権限者による承認を受ける。また、フロント担当者は、フロント端末１０３を用いて連絡票を作成し、契約内容の点検および実行依頼をミドルバック担当者に対して行なう。この際、フロント担当者は、フロント端末１０３を用いて（または別端末を用いて）、契約書や徴求書類をスキャニングし、各書類の電子データ（例えば、ＰＤＦファイル）が融資事務管理サーバ１０１に送信および格納される。

ミドルバック端末１０４は、金融機関におけるミドルバック担当者が使用する端末である。ミドルバック担当者は、ミドルバック端末１０４を用いて、フロント担当者から受信した連絡票に基づいて、徴求書類の過不足確認を含む契約内容の点検を行なう。点検結果は、ミドルバック担当者によりミドルバック端末１０４を介して登録され、融資事務管理サーバ１０１に格納される。契約内容に不備がない場合は、ミドルバックの権限者による検証を受けた後、問題がなければ融資実行処理が行なわれる。

契約内容に不備がある場合は、ミドルバック担当者は、ミドルバック端末１０４を用いて不備事由を登録し、融資事務管理サーバ１０１を介して、フロント担当者に対して不備を指摘する。その後、フロント担当者は、フロント端末１０３を用いて、不備事由を確認し、補完対応を行なった上で、融資事務管理サーバ１０１に回答内容を登録する。登録された回答内容は、ミドルバック端末１０４を介してミドルバック担当者にて不備が解消しているか確認される。

また、フロントからミドルバックに対し、複数の点検案件として依頼すべき徴求書類を、１案件にまとめて投入し依頼してくるケースがある。この場合、ミドルバック担当者は、ミドルバック端末１０４を用いて、案件分割を行ない、それぞれの案件に徴求書類を割り当てることができる。

なお、ミドルバックの権限者は、ミドルバック端末１０４を用いて、契約内容に応じた徴求書類をカスタマイズすることができる。これは、例えば、融資事務管理システムにおけるカスタマイズ用の画面で、どのような書類が徴求されるかを任意に指定することができる。これにより、契約書データや連絡票データが登録された際などに、徴求書類を判定し、徴求書類の過不足確認時の支援を行なうことができる。

次に、融資事務管理サーバ１０１の構成を詳細に説明する。なお、図１では、単一のサーバコンピュータシステムを想定し、必要な機能構成だけを示している。

融資事務管理サーバ１０１は、ＣＰＵ１１０に、システムバス１１５を介してＲＡＭ１１１、入力装置１１２、出力装置１１３、通信制御装置１１４、および不揮発性記憶媒体（ＲＯＭやＨＤＤなど）で構成される記憶装置１１６が接続された構成を有する。記憶装置１１６は、融資事務管理システムの各機能を奏するためのソフトウェアプログラムを格納するプログラム格納領域と、当該ソフトウェアプログラムで取り扱うデータを格納するデータ格納領域とを備えている。以下に説明するプログラム格納領域の各手段は、実際は独立したソフトウェアプログラム、そのルーチンやコンポーネントなどであり、ＣＰＵ１１０によって記憶装置１１６から呼び出されＲＡＭ１１１のワークエリアに展開されて、データベースなどを適宜参照しながら順次実行されることで、各機能を奏するものである。

記憶装置１１６におけるプログラム格納領域に格納されているソフトウェアプログラムは、本発明に関連するものだけを列挙すると、稟議書データ管理手段１２０、契約書データ管理手段１２１、徴求書類データ管理手段１２２、および連絡票データ管理手段１２３を備えている。これらの手段は、ＣＰＵ１１０によって実行される。

稟議書データ管理手段１２０は、フロント端末１０３から稟議書データを受信し、稟議書データ記憶部１３０に格納する。また、フロント端末１０３またはミドルバック端末１０４からの要求に応じて、稟議書データ記憶部１３０に格納された稟議書データを取得し、要求のあった各端末に送信する。

契約書データ管理手段１２１は、フロント端末１０３から契約書データを受信し、契約書データ記憶部１３１に格納する。また、フロント端末１０３またはミドルバック端末１０４からの要求に応じて、契約書データ記憶部１３１に格納された契約書データを取得し、要求のあった各端末に送信する。また、契約書データ管理手段１２１は、フロント端末１０３から、契約書の電子データ（例えば、ＰＤＦファイル）を受信し、契約書データ記憶部１３１に格納する（またはＰＤＦファイルを別の場所に格納し、格納場所を示すデータを契約書データ記憶部１３１に格納する）。

徴求書類データ管理手段１２２は、フロント端末１０３から、徴求書類の電子データ（例えば、ＰＤＦファイル）を受信し、徴求書類データ記憶部１３２に格納する（またはＰＤＦファイルを別の場所に格納し、格納場所を示すデータを徴求書類データ記憶部１３２に格納する）。また、案件分割により徴求書類が複数の連絡票に割り当てられた場合、徴求書類データ管理手段１２２は、割り当てられた徴求書類データを、徴求書類データ記憶部１３２に反映する。

連絡票データ管理手段１２３は、フロント端末１０３またはミドルバック端末１０４から受信した連絡票データを連絡票データ記憶部１３３に格納する。また、フロント端末１０３またはミドルバック端末１０４からの要求に応じて、連絡票データ記憶部１３３に格納された連絡票データを取得し、要求のあった各端末に送信する。また、連絡票データ管理手段１２３は、ミドルバック端末１０４からの要求に応じて、案件分割を行なうために連絡票データ記憶部１３３における対象の連絡票データを複製する。

次に、記憶装置１１６におけるデータ格納領域は、本発明に関連するものだけを列挙すると、稟議書データ記憶部１３０、契約書データ記憶部１３１、徴求書類データ記憶部１３２、および連絡票データ記憶部１３３を備える。いずれも、記憶装置１１６内に確保された一定の記憶領域である。

稟議書データ記憶部１３０は、融資取引における承認済みの稟議に係るデータを格納する。図３は、本発明の一実施形態に係る稟議書データ記憶部１３０に格納されたデータを示す図である。図３における稟議書データは、稟議書データを識別するための「稟議番号」、同一案件における稟議書のバージョンを示す「稟議通番」（すなわち、「稟議番号」と「稟議通番」とで稟議書（データ）を一意に識別することができる）、稟議書を作成した主管店を一意に示す「担当支店コード」、稟議書の作成者（フロント担当者）を一意に示す「担当者コード」、稟議書の承認者（フロントミドル担当者）を一意に示す「承認者コード」、稟議書の決裁者（審査部担当者）を一意に示す「決裁者コード」、金融機関の取引先の勘定店を一意に識別させる「勘定店番号」、取引先の口座番号を示す「口座番号」、取引先を一意に示す「取引先ＩＤ」、承認済みの稟議金額を示す「稟議金額」、融資の実行予定日を示す「実行予定日」、稟議の取り扱い期限を示す「取扱期限」、年利区分を示す「年利区分」、その他の融資実行条件の有無を示す「その他条件有無」、および電子稟議書ファイルを格納するための、または格納先を示す「稟議書ファイル」を格納する。「稟議番号」および「稟議通番」について、例えば、稟議書データを更新登録すると、「稟議通番」が、シーケンシャルに増えていく形で登録される。そのため、同一の稟議書データ（「稟議番号」が同一）を検索する場合は、「稟議通番」が最も多いデータを最新版の稟議書データとして取得することができる。「年利区分」は、融資に対する年利ベースを示す数値（１：３６５日ベース、２：３６０日ベース、など）を設定することができる。「その他条件有無」は、本データの条件以外の融資実行条件の有無を示す数値（０：その他条件無し、１：その他条件有り、など）を設定することができる。例えば、「１：その他条件有り」の場合は、本データ以外の別の条件データを参照することもできる。「稟議書ファイル」は、稟議書ファイルそのもの（例えば、ＰＤＦファイル）であってもよいし、格納先のアドレスであってもよい。なお、当該データ内容については一例であり項目の追加、削除を妨げるものではない（以下に示す各データについても同様である）。

契約書データ記憶部１３１は、稟議承認後、顧客と金融機関との間で締結された契約に係るデータを格納する。図４は、本発明の一実施形態に係る契約書データ記憶部１３１に格納されたデータを示す図である。図４における契約書データは、契約書データを識別するための「契約番号」、同一案件における契約書のバージョンを示す「契約通番」（すなわち、「契約番号」と「契約通番」とで契約書（データ）を一意に識別することができる）、顧客と金融機関の間で契約が締結した日を示す「契約日」、融資金額を示す「融資金額」、融資の実行予定日を示す「実行予定日」、融資金額の完済予定日を示す「返済予定日」、融資金額に対して適用される利率を示す「適用利率」、基準金利を示す「ベースレート区分」、年利区分を示す「年利区分」、資金手配方法であるファンディング方法を示す「ファンディング方法」、電子契約書ファイルを格納するための、または格納先を示す「契約書ファイル」、適用された稟議書を一意に示す「適用稟議番号」を格納する。「契約番号」および「契約通番」について、例えば、契約書不備などによる補完対応で契約書を再作成し契約書データを更新登録すると、「契約通番」が、シーケンシャルに増えていく形で登録される。そのため、稟議書データ同様、同一の契約書データ（「契約番号」が同一）を検索する場合は、「契約通番」が最も多いデータを最新版の契約書データとして取得することができる。「ベースレート区分」は、融資に対する基準金利を示す数値（１：短期プライムレート、２：市場金利、３：市場金利（その他）、４：その他を設定することができる。「ファンディング方法」には、資金手配方法を示す数値（１：オンラインファンディング、２：架電ファンディング、３：その他のファンディング、など）を設定することができる。オンラインファンディングとは、金融機関内の資金管理を行なっている部門に対し、例えば勘定系システムを介してオンラインで資金手配をする場合である。また、架電ファンディングとは、当該部門に対し、オンラインなどで手配をすることが出来ない別段の理由がある場合、電話連絡にて資金手配する場合である。さらに、その他のファンディングとは、オンラインファンディングおよび架電ファンディングに該当しない手配方法である（例えば、オンラインではあるが、複数の連携システムを介して資金手配を行なうため、資金手配の期間や金額に対し、人間による最終確認が必要）。「年利区分」は稟議書データ（図３）と同様である。「契約書ファイル」は稟議書データ（図３）における「稟議書ファイル」と同様である。「適用稟議番号」には、契約にあたり適用された承認済みの稟議書を一意に示す番号が格納される。これは、例えば、「稟議番号」および「稟議通番」を組み合わせた番号である（例えば、稟議番号＋“−”（ハイフン）＋稟議通番）。

徴求書類データ記憶部１３２は、契約書に添付され、フロント担当者によって登録された徴求書類（融資実行の際の必要書類）に係るデータを格納する。図５は、本発明の一実施形態に係る徴求書類データ記憶部１３２に格納されたデータを示す図である。図５における徴求書類データは、添付先の契約書を一意に示す「契約番号」、対応する連絡票を識別するための「連絡番号」、徴求書類の種類を示す「書類＊種別」、電子徴求書類ファイルを格納するための、または格納先を示す「書類＊」、および徴求書類の必要レベルを示す「書類＊必要レベル」を格納する。「契約番号」は、添付先である契約書データ（図４）における「契約番号」である。なお、「契約番号」も、契約書データ（図４）における「適用稟議番号」同様、「契約通番」も含めた形で格納することもできるし、「契約番号」のみを格納し、対応する契約書データは「契約通番」が最も多いデータであると判断することもできる。また、「連絡番号」も、後述する連絡票データ（図６）における「連絡番号」に「連絡通番」を含めた形で格納することで、対応する連絡票を一意に識別させることもできる。「書類＊種別」は、徴求書類の種類を示す数値（１：稟議書、２：銀行取引約定書、３：保証書、４：印鑑証明、５：約束手形、６：個人情報同意書、７：保証意思確認書、８：その他、９：対象外、など）を設定することができる。なお、「書類＊種別」および「書類＊」の“＊”は管理上の書類の識別番号であり、例えば、１から順番に存在する。図５においては、書類９までしか示していないが、当然ながら１０以上存在することもできるし、９未満であってもよい。また、書類の種類をデータ列として管理するのではなく、書類ごとにデータレコードとして管理することができる。この場合、徴求書類データには「契約番号」に加え、例えば、「書類番号」を設定し、書類の数分、レコードを追加していく。「書類＊」は稟議書データ（図３）における「稟議書ファイル」と同様である。「書類＊種別」における“８”（その他）は、１〜７以外の書類であることを示す他、光学文字認識（ＯＣＲ）による書類の自動判別の際に、正常に判別できなかった場合にも設定される。この場合、フロント担当者またはミドルバック担当者により、正しい書類種別に再設定されることになる。「書類＊必要レベル」は、徴求書類の必要レベルを示す数値（０：参照書類、１：必須書類、２：必要書類、９：未分類書類、など）を設定することができる。“０”（参照書類）は稟議書など、予め作成されていることが前提の書類で点検処理時に参照書類として用いられる書類を示す。“１”（必須書類）は、融資取引の契約内容（例えば、契約書データなどの入力値）により必須の書類と判断された書類を示す。必須書類が全てフロントから受信され登録されていない場合は、点検完了状態にさせないような制御を本システムに含めることもできる（例えば、ミドルバック端末１０４にその旨のメッセージを表示する、または「点検完了」ボタンなどを非活性（押下不可）状態にするなどし、ミドルバック端末１０４からの点検完了要求を受け付けないように制御し、連絡票データ（図６）における「進捗状況」を“５”（点検済み）に更新することができないようにする）。“２”（必要書類）は、必須書類ではないが、カスタマイズ画面などによって、登録が必要であると任意選択された書類を示す。必要書類も必須書類と同扱いし、全て登録されていない場合は、点検完了状態にさせないような制御を本システムに含めることもできる。“９”（未分類書類）は、上記以外のその他の書類を示す。これは、例えば、本来は必須書類であるが、光学文字認識（ＯＣＲ）による書類の自動判別が正常に行なかった書類などに設定される。なお、図５において「書類＊種別」や「書類＊」、「書類＊必要レベル」が空白のデータは、書類が存在しないことを示す。徴求書類が契約書に何種類添付されるかは、契約内容ごとに異なる。なお、徴求書類は契約内容に基づいて決定されるが、それを決定するための条件マスタ（図示せず）は別途、融資事務管理サーバ１０１に格納される。

連絡票データ記憶部１３３は、融資事務処理における契約内容の点検および実行依頼を行なうための連絡用のデータを格納する。図６は、本発明の一実施形態に係る連絡票データ記憶部１３３に格納されたデータを示す図である。図６における連絡票データは、連絡票を一意に示すための「連絡番号」および「連絡通番」、融資事務処理の進捗状況を示す「進捗状況」、点検および実行対象となる契約書を示す「契約番号」、契約内容に不備があった場合の不備の種類を示す「不備事由」、不備に対する対応状況を示す「対応状況」、ミドルバックからフロントへの連絡事項（主に不備事由に対する補足説明）を示す「フロント宛連絡事項」、ならびにフロントからミドルバックへの連絡事項（主に補完対応に対する補足説明）を示す「ミドルバック宛連絡事項」を格納する。「連絡通番」は、案件分割の際に使用される項目であり、例えば、分割元の連絡票（親案件）に係るデータレコードには「０」、分割した連絡票（子案件）に係るデータレコードには「１」、「２」、「３」・・・と分割数に応じて設定することができる（案件分割を行なっていない場合は空データのままでよい）。そのため、連絡票データは、「連絡番号」および「連絡通番」の組み合わせで一意に識別することができる。「進捗状況」は、融資事務処理の進捗状況を示す数値（１：連絡票作成中、２：点検依頼待ち、３：点検待ち、４：点検中、５：点検済み、など）を設定することができる。「不備事由」は、不備の種類を示す数値（１：稟議条件違反、２：徴求書類不足、など）を設定することができる。「対応状況」は、不備に対する対応状況を示す数値（１：フロントへの連絡未、２：フロントへ連絡済、３：フロントにて補完対応中、４：フロントからミドルバックに補完対応回答済、など）を設定することができる。また、図６では、「不備事由」および「対応状況」を１つしか登録できないように記載してあるが、「不備事由１」、「不備事由２」、「不備事由３」・・・と複数列を設定できるようにする、または不備事由ごとにレコードを作成する、などにより、複数の不備事由を登録させることもできる（「対応状況」も同様）。

次に、図２のフローチャート、および図３−６のデータを参照して、本発明の一実施形態に係る融資実行処理を流れに沿って説明する。本処理は、フロント担当者が予め承認済みの稟議書データ（図３）に基づいて顧客との間で融資契約を締結し、連絡票を用いてミドルバック担当者に契約内容の点検依頼をし、ミドルバック担当者が契約内容を点検し、契約内容に不備がある場合は補完対応を行なうという一連の融資事務を、コンピュータシステムを介して行なうものである。

なお、契約書について、紙ベースで締結され（顧客が紙に押印することにより契約締結）、当該契約書をスキャニングにより電子データ化するパターンと、予め契約書データ（図４）が作成される（顧客はコンピュータ端末を介して契約書データを確認し、電子署名することにより契約締結）ペーパーレスパターンとが想定される。

契約書をスキャニングにより電子データ化するパターンの場合、フロント担当者が紙ベースの契約書および徴求書類をスキャニングし、連絡票を用いてミドルバック担当者に対し点検依頼を行なう。

ペーパーレスパターンの場合は、フロント担当者が連絡票に契約内容（金利情報や回収情報などの融資条件）を入力し、紙ベースの徴求書類をスキャニングした上で、連絡票を用いてミドルバック担当者に対し点検依頼を行なう。

連絡票により点検依頼を受けたミドルバック担当者は、契約内容と稟議条件の確認、徴求書類の有無およびその内容の確認、ならびに印鑑照合などの点検作業を行なう。

図２は、本発明の一実施形態に係る融資事務処理を示すフローチャートである。本処理フローは、フロント担当者と顧客との間で契約が締結した後、契約内容の点検依頼を行なうために、フロント担当者がミドルバック担当者への連絡票を作成するところから始まる。

まず、ステップ２０１において、連絡票データ管理手段１２３が、フロント端末１０３から、フロント担当者により新規作成された連絡票データを受信し、連絡票データ記憶部１３３に格納する。この段階の連絡票データは、図６における「連絡番号」が“４”のレコードのように、「進捗状況」が“１”（連絡票作成中）のものである。当然ながら「不備事由」などは未だ登録されていない。また、連絡票データ（図６）における「連絡番号」は、連絡票データ記憶部１３３に新規作成される場合に採番され、格納される。連絡票データ（図６）における「契約番号」は、点検対象となる契約書データを識別するための番号であり、契約書データ（図４）における「契約番号」に対応する（または、同一の「契約番号」が契約書データに複数存在する場合は、同一の「契約番号」のレコードのうち「契約通番」が最も多いレコードに対応する）。なお、連絡票データや、以下に詳細に示す契約書データなどの作成および更新は、融資事務処理用のＷｅｂサイト（以下、「専用サイト」という）を介して行うことができる。

また、連絡票作成と同時、または前後で、契約書データ（図４）の作成を行なうことが想定される。紙ベースの契約書の場合は、フロント担当者がフロント端末１０３または別の端末により契約書をスキャニングし、契約書の電子データ（例えばＰＤＦファイル）を、融資事務管理サーバ１０１に送信する。送信された契約書の電子データは、契約書データ管理手段１２１により受信され、契約書データ記憶部１３１に格納される（またはＰＤＦファイルを別の場所に格納し、格納場所を示すデータ（例えば、図４における「契約書ファイル」）が契約書データ記憶部１３１に格納される）。契約書のペーパーレスパターンの場合は、フロント担当者は、連絡票作成と併せて、フロント端末１０３を用いて契約書データを作成し、融資事務管理サーバ１０１に送信する。送信された契約書データは、契約書データ管理手段１２１により受信され、契約書データ記憶部１３１に格納される。

また、契約書の電子データ、または契約書データの作成と共に、フロント担当者は、フロント端末１０３を用いて、紙ベースの徴求書類をスキャニングし、徴求書類の電子データ（例えば、ＰＤＦファイル）を、融資事務管理サーバ１０１に送信する。送信された徴求書類の電子データは、徴求書類データ管理手段１２２により受信され、徴求書類データ記憶部１３２に格納される（またはＰＤＦファイルを別の場所に格納し、格納場所を示すデータ（例えば、図５における「書類＊」）が徴求書類データ記憶部１３２に格納される）。また、徴求書類データ（図５）における「書類＊種別」は、フロント端末１０３を用いてフロント担当者が選択したデータに基づいて手動設定することもできるし、電子データのファイル名や、光学文字認識（ＯＣＲ）により識別された書類内の所定コードなどにより書類の種類を自動判別および設定することもできる。また、正常に自動判別できなかった場合には、「書類＊種別」に例えば、“８”（その他）を設定することにより、その後の確認の際、フロント担当者またはミドルバック担当者に正しい書類種別を設定させることもできる。

次に、ステップ２０１おいて作成した連絡票（データ）に対してフロントの権限者による承認を受けるため、連絡票データ管理手段１２３が連絡票を回覧する（ステップ２０２）。これは、例えば、連絡票を作成したフロント担当者がフロント端末１０３を用いて承認を受ける権限者を指定し、連絡票データ管理手段１２３により、指定された権限者のみが当該連絡票を承認できるように制御する。この際、徴求書類が全て登録されていない場合、フロント端末１０３にその旨のメッセージを表示させるように制御することもできる。また、この段階で連絡票データ管理手段１２３により、連絡票データ（図６）の「進捗状況」が“２”（点検依頼待ち）に更新される。なお、フロントの権限者による承認を受けない場合、連絡票データ管理手段１２３はステップ２０２−２０４を実行せず、ステップ２０１おいて作成した連絡票（データ）をミドルバックに回付（ステップ２０５）してもよい。

ステップ２０２において回覧された連絡票データ（図６）、ならびに点検対象となる契約書データ（図４）および徴求書類データ（図５）は、フロントの権限者によりチェックされ、チェックＯＫの場合はステップ２０３のＹｅｓルートに進み、連絡票データ管理手段１２３によってミドルバックに回付される（ステップ２０５）。この場合、連絡票データ管理手段１２３により、連絡票データ（図６）の「進捗状況」が“３”（点検待ち）に更新される。一方、チェックＮＧの場合はステップ２０３のＮｏルートに進み、フロント担当者または権限者はフロント端末１０３を用いて連絡票などの修正を行ない（ステップ２０４）、問題を解消した上で、修正された連絡票などが連絡票データ管理手段１２３によってミドルバックに回付される（ステップ２０５）。

ステップ２０５において連絡票などがミドルバックに回付されると、ミドルバック担当者は、ミドルバック端末１０４を用いて契約内容を点検する（ステップ２０６）。具体的には、ミドルバック端末１０４に専用サイトの点検依頼一覧が表示され、点検対象となる連絡票を選択することにより、契約内容を点検する。契約内容の点検は、例えば、フロント担当者により作成された、連絡票データ（図６）、ならびに契約書データ（図４）および徴求書類データ（図５）の内容を確認する。これは、稟議書データ（図３）の内容を参照して、契約書の内容が稟議条件に違反していないか、徴求書類の過不足や不備がないか、などを確認する。なお、稟議書データ、契約書データ、徴求書類データ、および連絡票データは、図３−６に示されるように稟議番号または契約番号により関連付けられており、ミドルバック端末１０４からの要求指示により、それぞれのデータを関連付けてミドルバック端末１０４に表示させることができる。また、融資事務管理サーバ１０１は、電子データ化された契約書上の印影と、マスタ登録された正規の印鑑の印影とを重ね合わせて照合率（一致率）を算出し、ミドルバック担当者は当該照合率に基づいて印鑑照合を行なうこともできる。

ステップ２０６における契約内容の点検により、不備が確認された場合、ステップ２０７のＹｅｓルートに進み、ミドルバック担当者は、ミドルバック端末１０４を介して不備事由を登録し、フロントに回付する（ステップ２０８）。不備事由の登録とは、例えば、連絡票データ（図６）における「不備事由」を、ミドルバック端末１０４上に表示された専用サイトから選択し、「フロント宛連絡事項」に詳細内容を登録する。また、当該専用サイト上のボタン押下などにより、フロントへの回付指示を行うことにより、連絡票データ管理手段１２３は連絡票データ（図６）における「対応状況」を“２”（フロントへ連絡済）に更新する。なお、不備内容のみを登録し、フロントへの回付指示を未だ行わない場合、当該「対応状況」を“１”（フロントへの連絡未）に更新することもできる。

ステップ２０８においてフロントへの回付が行われると、フロントにて不備の内容を確認し、補完対応した上で、ミドルバックに再回付される（ステップ２０９）。フロント担当者は、フロント端末１０３に表示した専用サイトを介して、連絡票データ（図６）、ならびに契約書データ（図４）および徴求書類データ（図５）における不備を修正（更新）し、連絡票データ（図６）における「ミドルバック宛連絡事項」に補完対応の詳細内容を登録する。なお、補完対応において、フロント担当者が契約書を再作成した場合は、契約書データ管理手段１２１は、フロント端末１０３から新たに契約書データ（図４）を受信し、契約書データ記憶部１３１に格納する。この場合、契約書データに新しいレコードが追加されることになるが、新規追加される契約書データの「契約番号」は元々の契約書データと同一で、「契約通番」が、例えば、シーケンシャルに加算されたものが設定される。また、ミドルバックへの再回付指示を行うことにより、連絡票データ管理手段１２３は連絡票データ（図６）における「対応状況」を“４”（フロントからミドルバックに補完対応回答済）に更新する。なお、当該「対応状況」は、補完対応中で、ミドルバックへの回付指示は未だ行わない場合、“３”（フロントにて補完対応中）に更新することもできる。ミドルバックに再回付されると、ミドルバック担当者により再度点検が行なわれ（ステップ２０６）、不備が解消するまでステップ２０６−２０９を繰り返す。

ステップ２０６における契約内容の点検により、不備が確認されない場合、ステップ２０７のＮｏルートに進み、ミドルバックの権限者による検証を受けた後、問題がなければ契約書データおよび徴求書類データなどに基づいて、別コンピュータなどへの融資実行処理が行なわれる（ステップ２１０）。ステップ２０６における契約内容の点検により不備が確認されない場合、連絡票データ管理手段１２３により、連絡票データ（図６）の「進捗状況」が“５”（点検済み）に更新される。すなわち、徴求書類のうち、必須書類（および必要書類）が全て登録されていない場合は「進捗状況」を“５”（点検済み）に更新することができないように制御することで、徴求書類の登録状況により、点検完了および融資実行の可否を制御することができる。「進捗状況」を“５”（点検済み）に更新することができないように制御するとは、ミドルバック端末１０４からの点検完了要求を受け付けないように制御することである。より具体的には、これは、ミドルバック端末１０４に表示される専用サイトにおいて点検完了状態にするためのボタンを非活性状態にし、押下できないようにする、または当該ボタン押下時に徴求書類不足のため点検完了できない旨のエラーメッセージを表示する（この場合、そのまま点検完了とするか否かを選択させるようにすることもできる）、などである。ステップ２１０の後、本処理は終了する。

なお、電子データ化された契約書や徴求書類の現物は、本システムまたは別システムにより、在り場所の管理を行なうこともできる。契約書や徴求書類の現物は、電子データ化された契約書などに基づいてミドルバックによる点検を受け問題ないとされた後（ステップ２１０の後）、フロントから、ミドルバックまたは所定の保管場所に郵送される。この際、システムから郵送のための送付状を発行することができる。例えば、連絡票データ（図６）における「進捗状況」が“５”（点検済み）に更新されたタイミングで、当該送付状を発行することもできる。さらに送付状に二次元コード（例えば、ＱＲコード（登録商標））を印刷し、送付状を受け取ったら当該コードを読み取り、在り場所や送付状況を示すステータスを更新することができる。さらに、送付状の発行について、徴求書類データ（図５）における「書類＊必要レベル」に応じて発行の要否を制御することもできる。より具体的には、例えば、「書類＊必要レベル」が“１”（必須書類）および“２”（必要書類）である書類の送付状のみを発行するように制御するなどである。

次に、図５および６のデータ、ならびに図７および８の画面イメージを参照して、本発明の一実施形態に係る点検処理における徴求書類の登録および確認ならびに案件分割の詳細について説明する。徴求書類の登録は、図２におけるステップ２０１の点検依頼のための連絡表作成前後で行なわれる。また、徴求書類の確認および案件分割は、図２におけるステップ２０６の点検処理の中で行われる。

まず、徴求書類一覧画面について説明する。図７は、本発明の一実施形態に係る徴求書類一覧画面の画面イメージを示す図である。徴求書類一覧画面は、融資事務管理サーバ１０１から、フロント端末１０３およびミドルバック端末１０４に配信される融資事務処理用の専用サイトの画面である。徴求書類一覧画面を用いて、フロント担当者は徴求書類の登録を行ない、ミドルバック担当者は徴求書類の過不足確認を行なう。徴求書類一覧画面は、徴求書類一覧表示部７０１、および書類詳細表示部７０２を有する。

徴求書類一覧表示部７０１には、予め登録された契約書データ（図４）などの入力値によって、およびカスタマイズ画面（図示せず）によって任意選択されることによって、その契約に必要とされる書類、すなわち、徴求書類の種類が視覚的に把握し易いように、書類ごとに、書類名を含む書類欄が一覧表示される。また、既に書類が登録済みの場合は、各書類のサムネイルを表示する。徴求書類の登録は、例えば、フロント端末１０３上の徴求書類の電子ファイルをマウスクリックなどで選択し、徴求書類一覧表示部７０１の各欄にドラッグ＆ドロップすることにより行なうことができる。また、登録するファイルを選択した際（またはスキャニングした際であってもよい）、例えば、光学文字認識（ＯＣＲ）により書類内の書類名を読み取り、判別された書類名を含む欄に自動的に登録することもできる。

７０３欄は、参照書類として既に登録済みの稟議書のサムネイルを表示している。このように徴求書類として参照書類（徴求書類データ（図５）における「書類＊必要レベル」が“０”（参照書類）の書類）を表示させることもできる。

７０４欄は、既に登録された銀行取引約定書のサムネイルを表示している。７０４欄に表示された鍵アイコンは、キー書類、すなわち、融資取引の契約内容（例えば、契約書データなどの入力値）により必須の書類と判断された書類であることを示している（徴求書類データ（図５）における「書類＊必要レベル」が“１”（必須書類）の書類）。鍵アイコンの表示された欄にサムネイルが表示されていない場合（書類が未登録の場合。後述する７０６欄のように“未登録”である旨が視覚的に把握し易いように表示される）、ミドルバック担当者は、徴求書類が不足していると判断することができる。

７０５欄は、既に登録された保証書のサムネイルを表示している。７０５欄に表示された星アイコンは、カスタマイズ画面によって必要書類として指定された書類（徴求書類データ（図５）における「書類＊必要レベル」が“２”（必要書類）の書類）であることを示している。

７０６欄は、印鑑証明が必要と書類として指定されたが、サムネイル表示はなく、未だ登録されていないことを示している。この場合、図７に示すように、“未登録”である旨を視覚的に表示し、さらに、未登録状態のまま、点検処理を完了できないようにシステム的な制御を入れることもできる。未登録状態の欄に書類を登録した場合、“未登録”である旨の表示は消え、７０５欄のように登録した書類のサムネイルが表示される。

７０７欄は、サムネイル表示部に新たに登録されたことを示す“ＮＥＷ”アイコンが表示されている。“ＮＥＷ”アイコンは、例えば、書類が登録されてから一定期間、またはミドルバック端末１０４によって本画面が表示されるまで（ミドルバック担当者が確認するまで）の間、表示することができる。

７０８欄は、光学文字認識（ＯＣＲ）による書類の自動判別の際に、正常に判別できなかった書類が登録および表示されている欄である。フロント担当者は、フロント端末１０３を介して、その他欄に表示された書類のサムネイルをドラッグ＆ドロップにより、正しい書類欄に移動させることができる。この操作は、当然ながら、ミドルバック端末１０４においても可能であり、さらに７０８欄のようなその他欄に限られず、他の書類欄の間でも、誤った書類欄に登録されている書類などを自由に移動させることができる。これにより、徴求書類の種類を正しい種類に変更することができる。

７０９欄は、書類欄を新たに追加するための欄である。「作成」ボタンを押下することで、書類名の入力フィールドが表示され、書類欄を新たに追加することができる。追加された書類欄は、例えば、７０９欄の左隣に表示される。追加された書類欄または他の書類欄は、書類欄の所定の場所（例えば、サムネイル表示部分以外）をドラッグ＆ドロップすることにより、書類欄の順番を任意に入れ替えることができる。また、新たに書類が追加された場合、徴求書類データ管理手段１２２は、徴求書類データ（図５）作成し、徴求書類データ記憶部１３２に格納する。または既に、徴求書類データ記憶部１３２に、処理中案件の徴求書類データが存在する場合は、当該データを更新する。なお、徴求書類一覧表示部７０１に表示されている書類の左上から、その右隣の書類、さらに右隣の書類・・・と順番に、徴求書類データ（図５）における書類１、２、３・・・のデータと対応させることができる。

７１０欄は、登録書類を点検対象外とするための欄である。例えば、書類が登録されていたが、キー書類でも必要書類でもない場合、ドラッグ＆ドロップにより、７１０欄に移動させることにより、点検処理の対象外とすることができる。この場合、徴求書類データ（図５）における「書類＊種別」には、“９”（対象外）が設定される。なお、当然ながら、図７の７１０欄に示されるように、同一欄に複数の書類を登録することもできる。

書類詳細表示部７０２は、選択された徴求書類の詳細を表示するための部分である。例えば、徴求書類一覧表示部７０１における７０４欄のサムネイルをマウスクリックなどにより選択すると（なお、選択中のサムネイルは太枠で囲まれる）、書類詳細表示部７０２に選択された徴求書類を拡大表示する。

書類詳細表示部７０２の下部には３つのボタンが表示される。「拡大」／「縮小」ボタンを押下することで、書類詳細表示部７０２に表示中の書類を所定率、それぞれ、拡大／縮小表示することができる。また、「回転」ボタンを押下することで、書類詳細表示部７０２に表示中の書類を、例えば、右に９０°回転させることできる。

次に、案件分割画面について説明する。図８は、本発明の一実施形態に係る案件分割画面の画面イメージを示す図である。案件分割画面は、融資事務管理サーバ１０１からミドルバック端末１０４に配信される融資事務処理用の専用サイトの画面である。フロントからミドルバックに連絡票を介して点検依頼が行なわれる際、複数の点検案件として（複数の連絡票に添付して）依頼すべき徴求書類を、１案件にまとめて投入し依頼してくるケースがある。このような場合に、ミドルバック担当者は、ミドルバック端末１０４を用いて、案件分割画面から案件分割を行ない、それぞれの案件に徴求書類を割り当てることができる。案件分割画面は、全書類表示部８０１、親案件部８０２、子案件部８０３、および案件追加部８０４を有する。

全書類表示部８０１は、処理中の案件に投入された全書類を表示する部分である。８０５欄には、キー書類が表示される。８０６欄には、キー書類以外の登録された書類が表示される。複製チェックボックス８０７については後述する。

親案件部８０２は、親案件に書類を割り当てるための部分である。子案件部８０３は、子案件に書類を割り当てるための部分である。案件分割は、２以上の案件に分割することができるが、分割された案件の中で親案件は１件だけである。８０８欄および８１２欄には、それぞれ、親案件および子案件のキー書類が表示される。なお、図８に示されるように、キー書類（８０５欄の２書類）は、本画面を開いた時点で、８０８欄および８１２欄にそれぞれ自動的に割り当てることもできる。

８０６欄に表示されるキー書類以外の登録書類は、割り当てたい書類のサムネイルをマウスクリックするなどして選択し、８０９欄または８１３欄にドラッグ＆ドロップすることにより、それぞれ、親案件または子案件に割り当てることができる。なお、割当てを解除する場合は、再度、対象のサムネイルをクリックし、８１１欄または８１４欄にドラッグ＆ドロップすることにより、割当てを解除することができる。割当て解除されると、対象の書類は、８０６欄に再度サムネイル表示され元の状態に戻る。

また、書類を割り当てる際、複製チェックボックス８０７にチェックを入れた状態で（チェックＯＮ時）、８０９欄または８１３欄に割当てを行なうと、図８に示すように、割り当てた書類のサムネイルに、対象書類が複製（写し）であることを示すための複製アイコン８０９が付く。複製書類を割り当てた場合は、８０６欄に複製元の書類（マスタ書類）は残ったままとなる（図８でも、８１０欄に印鑑証明の複製が表示されつつ、８０６欄に同書類のマスタ書類が表示されている）。この場合、さらに８０６欄のマスタ書類を、８０９欄または８１３欄（親案件または子案件）に割り当てる。

案件追加部８０４は、子案件を追加するための部分である。案件追加部８０４には「追加」ボタンが表示され、当該ボタンを押下することで、子案件部８０３に表示されるような子案件部が、例えば、子案件部８０３と、案件追加部８０４との間に挿入される。追加した子案件を削除する場合は、子案件部８０３または新たに挿入された子案件部に表示される「削除」ボタンを押下することにより、それぞれの子案件を削除することができる。なお、「削除」ボタン押下時に、子案件が１つしか存在しない場合は、削除できない旨のメッセージを表示し、子案件の削除を行なわないよう制御することもできる。

全書類表示部８０１の上部には３つのボタンが表示される。「分割完了」ボタンを押下することで、８０９欄または８１３欄（親案件または子案件）に割り当てた書類を確定させ、案件分割処理を完了させることができる。なお、「分割完了」ボタン押下時に、未割当ての書類がある場合（８０６欄に書類が残っている場合）、エラーメッセージを表示し、案件分割処理を完了させないよう制御することもできる。なお、「分割完了」ボタン押下により、案件分割処理が完了すると、ミドルバック端末１０４から融資事務管理サーバ１０１に割当て結果データが送信され、連絡票データ管理手段１２３により、連絡票データ記憶部１３３に格納された連絡票データ（図６）が分割される。具体的には、連絡票データにおける対象レコードの複製を作成し、連絡票データ記憶部１３３に格納される。この際、連絡票データにおける「連絡通番」には、親案件の場合は“０”、子案件の場合は“１”、“２”、“３”・・・（子案件の数だけシーケンシャルな値を設定する）をそれぞれ設定することができる。また、連絡票データを分割するタイミングで（または別途）、徴求書類データ管理手段１２２は、割当て結果データを、徴求書類データ記憶部１３２における徴求書類データ（図５）に反映することができる。具体的には、連絡票データ同様、徴求書類データの対象レコードの複製を作成し、徴求書類データ記憶部１３２に格納する。この際、複製した徴求書類データにおける「連絡番号」には、図５に示すように、連絡番号と連絡通番とを“−”（ハイフン）で結合し、設定することができる。例えば、徴求書類データにおける「連絡番号」が“123456-1”の場合、連絡番号“123456”の子案件１であると判断することができる。また、親案件の場合、徴求書類データにおける「連絡番号」には、連絡通番を含めてもよいし、含めなくてもよい。連絡通番が含まれない「連絡番号」は、親案件に対応すると判断することができるためである。さらに、徴求書類データにおける「書類＊種別」および「書類＊」には、割当て結果データ（親案件および子案件に割り当てた徴求書類）に基づいて、値を設定することができる。なお、複製された書類（図８における複製チェックボックスにチェックした状態で割り当てられた書類）である場合、「書類＊種別」には、例えば、複製（コピー）である旨を示す“ｃ”を付与して、“ｃ４”などと設定することができる。

「元に戻す」ボタンを押下することで、分割完了前の、割当て内容を１つ、または初期状態（本画面表示時の状態）に戻すことができる。「閉じる」ボタンを押下することで、本画面を閉じることができる（または遷移元の画面に戻ることができる）。

以上より、本発明により、融資事務処理のペーパーレス化と共に、徴求書類の確認支援、および案件分割を行なうことができ、点検作業における徴求書類確認の効率化を図ることができる。

Claims (7)

1. フロントおよびミドルバックにおける融資事務を管理するサーバコンピュータであって、前記サーバコンピュータは、
   前記フロントが利用する第１のコンピュータからの要求に応じて、徴求書類一覧画面を前記第１のコンピュータに表示させ、前記徴求書類一覧画面は、予め登録されている融資契約の内容に係るデータに基づいて徴求書類の種類およびその必要レベルを表示し、
   前記第１のコンピュータから、１つまたは複数の徴求書類に係る徴求書類データを受信および登録し、
   前記登録した徴求書類データに基づいて、登録された前記徴求書類の前記種類を判別し、
   前記第１のコンピュータから前記ミドルバックが利用する第２のコンピュータへ融資契約の点検依頼を行なうための連絡票データを受信し、
   前記受信した連絡票データと、前記受信した徴求書類データとを関連付け、
   前記第１のコンピュータからの回付指示に応答して、前記連絡票データを前記第２のコンピュータに回付し、
   前記第２のコンピュータからの要求に応じて、登録した前記徴求書類の表示を含む前記徴求書類一覧画面を前記第２のコンピュータに表示させ、前記徴求書類の前記必要レベルに基づいて必要な前記徴求書類が全て登録されていない場合、前記第２のコンピュータからの点検完了要求を受け付けないように前記第２のコンピュータに制御させる
   ように構成されたことを特徴とするサーバコンピュータ。
2. 前記徴求書類一覧画面を用いて、前記第１のコンピュータおよび／または前記第２のコンピュータにより、前記登録した徴求書類の前記種類を変更できることを特徴とする請求項１に記載のサーバコンピュータ。
3. 前記徴求書類の前記種類および前記必要レベルは、カスタマイズ可能であることを特徴とする請求項１または２に記載のサーバコンピュータ。
4. 前記第２のコンピュータからの要求に応じて、案件分割画面を前記第２のコンピュータに表示させ、前記案件分割画面は、１つの前記連絡票データを親案件とし、１つまたは複数の別の連絡票データを子案件とするように案件を分割し、前記関連付けられた徴求書類データにおける前記連絡票データとの関連付けを削除し、前記親案件および前記子案件のそれぞれに対して、前記徴求書類データを関連付けるための画面であり、
   前記第２のコンピュータから割当て結果データを受信し、前記割当て結果データは、前記徴求書類データを、前記親案件および前記子案件のいずれかと関連付けるかを示すデータであり、
   前記割当て結果データを受信すると、前記連絡票データに基づいて前記別の連絡票データを作成し、前記徴求書類データを徴求書類ごとに、前記親案件または前記子案件に関連付ける
   ようにさらに構成されたことを特徴とする請求項１乃至３のいずれか１に記載のサーバコンピュータ。
5. 前記案件分割画面を用いて、前記第２のコンピュータにより、前記徴求書類の写しを作成することができ、前記写しも前記親案件および前記子案件のいずれかに関連付けられることを特徴とする請求項４に記載のサーバコンピュータ。
6. フロントおよびミドルバックにおける融資事務を管理するサーバコンピュータによって実行される方法であって、前記方法は、
   前記フロントが利用する第１のコンピュータからの要求に応じて、徴求書類一覧画面を前記第１のコンピュータに表示させるステップであって、前記徴求書類一覧画面は、予め登録されている融資契約の内容に係るデータに基づいて徴求書類の種類およびその必要レベルを表示する、ステップと、
   前記第１のコンピュータから、１つまたは複数の徴求書類に係る徴求書類データを受信および登録するステップと、
   前記登録した徴求書類データに基づいて、登録された前記徴求書類の前記種類を判別するステップと、
   前記第１のコンピュータから前記ミドルバックが利用する第２のコンピュータへ融資契約の点検依頼を行なうための連絡票データを受信するステップと、
   前記受信した連絡票データと、前記受信した徴求書類データとを関連付けるステップと、
   前記第１のコンピュータからの回付指示に応答して、前記連絡票データを前記第２のコンピュータに回付するステップと、
   前記第２のコンピュータからの要求に応じて、登録した前記徴求書類の表示を含む前記徴求書類一覧画面を前記第２のコンピュータに表示させるステップであって、前記徴求書類の前記必要レベルに基づいて必要な前記徴求書類が全て登録されていない場合、前記第２のコンピュータからの点検完了要求を受け付けないように前記第２のコンピュータに制御させる、ステップと
   を備えたことを特徴とする方法。
7. フロントおよびミドルバックにおける融資事務を管理する方法をサーバコンピュータに実行させるコンピュータプログラムであって、前記コンピュータプログラムは、前記サーバコンピュータによって実行されると、前記サーバコンピュータに、
   前記フロントが利用する第１のコンピュータからの要求に応じて、徴求書類一覧画面を前記第１のコンピュータに表示させるように制御させ、前記徴求書類一覧画面は、予め登録されている融資契約の内容に係るデータに基づいて徴求書類の種類およびその必要レベルを表示し、
   前記第１のコンピュータから、１つまたは複数の徴求書類に係る徴求書類データを受信および登録し、
   前記登録した徴求書類データに基づいて、登録された前記徴求書類の前記種類を判別し、
   前記第１のコンピュータから前記ミドルバックが利用する第２のコンピュータへ融資契約の点検依頼を行なうための連絡票データを受信し、
   前記受信した連絡票データと、前記受信した徴求書類データとを関連付け、
   前記第１のコンピュータからの回付指示に応答して、前記連絡票データを前記第２のコンピュータに回付し、
   前記第２のコンピュータからの要求に応じて、登録した前記徴求書類の表示を含む前記徴求書類一覧画面を前記第２のコンピュータに表示させるように制御させ、前記徴求書類の前記必要レベルに基づいて必要な前記徴求書類が全て登録されていない場合、前記第２のコンピュータからの点検完了要求を受け付けないように前記第２のコンピュータに制御させる
   ことを特徴とするコンピュータプログラム。