JP2005122758A

JP2005122758A - 取引先要項システム

Info

Publication number: JP2005122758A
Application number: JP2004343435A
Authority: JP
Inventors: 悦郎 ▲柳▼澤; Etsuro Yanagisawa; Masasue Oi; 正季大井; Shohei Hishiro; 章平樋代
Original assignee: HACHIJUNI BANK Ltd
Current assignee: HACHIJUNI BANK Ltd
Priority date: 2004-11-29
Filing date: 2004-11-29
Publication date: 2005-05-12

Abstract

【課題】取引先に関する情報につき手書きと同様な自由度でデータの入力及び参照を可能としつつ、横検索の精度の維持を図る。
【解決手段】マークアップランゲージ（ＭＬ）のタグの体系を定義したタグ体系定義ファイルと、端末での表示及び入力について予め定められたＧＵＩ定義ファイルと、前記ＭＬのタグ付けされた取引先毎のタグ付きデータを格納するＭＬデータＤＢと、前記取引先の組織及び事業についてのデータの端末での表示及び入力を前記ＧＵＩ定義に従って制御する表示編集制御部を備えている。この表示編集制御部は、前記表示編集制御部が、前記ＧＵＩ定義と前記取引先の態様とに応じて当該取引先の態様毎に入力不可とする項目を制御する入力不可制御機能や、当該任意項目であるＣＩＦ番号が入力された場合には当該ＣＩＦ番号を導出元として当該テーブルの名称項目及び住所項目等を導出するＣＩＦ番号別入力支援機能を備えた。
【選択図】図８

Description

本発明は、取引先要項システムに関し、特に、取引先に関する文字情報を取り扱う取引先要項システムに関する。

従来、種々の業種の組織で、顧客や、営業見込先（以下、取引先）についての情報を集約し、管理するために、取引先の要項や、営業日誌や、顧客名簿等を手書きで作成していた。この取引先要項等は、取引先への営業推進や、取引先への債権についての信用リスク管理や、組織内での引継や、組織内での各種の稟議・回覧並びに承認時の添付書類として用いられていた。

また、近年、情報技術（ＩＴ）の発達に伴い、ＣＲＭ（Customer Relationship Management）等を導入し、顧客との取引経緯を組織内の担当者で共有する仕組み等が導入されている。これは、例えば、組織内の担当者にＰＣ（Personal Computer）を配布し、ＰＣと組織内のサーバー等とをネットワークで接続し、サーバーに併設されたＤＢ（Data Base）に取引先の情報を格納する。そして、サーバーは、ＰＣのＷｅｂブラウザ等からの要求に応じて、そのＷｅｂブラウザ等の使用者のアクセス権を判定し、ＤＢから必要なデータを検索する。サーバーは、検索結果をＨＴＭＬ（Hyper Text Markup Language）等によるデータに変換して、ＰＣのＷｅｂブラウザに送信する。このようなサーバーとＰＣの活用により、ＰＣが配布された担当者間で取引先についての情報を共有している。

Ｗｅｂサーバーと連携するＤＢとして、ＲＤＢ（Relational Data Base）が広く利用されている。ＲＤＢは、現実世界の実体（Entity）に応じた複数のテーブルを作成し、そのテーブル間の関係を定義するＤＢであり、ＳＱＬ（Structured Query Language）文を用いて、挿入、更新、検索等のデータ操作を行う。ＲＤＢでは、データの整合性の点から、同一の項目（または、属性，フィールド，列）について複数のデータを取り扱う場合、予め上限数を定めて異なる項目名とするか、又は複数生じ得る項目については別のテーブルを定義し、関連付けを行う。例えば、取引先のグループ会社を管理する場合、グループ会社数が０の取引先や、数百社の取引先まで多様であり、ＲＤＢで開発するには、グループ会社有無フラグや、グループ会社テーブルや、グループ会社のシーケンス番号等の付与等を行う必要がある。このように、ＲＤＢでは、１項目についてのレコード数が取引先によって大幅に異なる可能性のある実体の取扱が難しく、その開発は煩雑であった。

ＲＤＢでは、確実な検索を行い、データに矛盾を生じないようにするために、正規化を行う。正規化を行うためには、テーブルのキーとなる項目を必須入力項目とし、また、同一項目で複数存在する場合にはシーケンス番号等を付与する。そして、任意入力項目を増やし、入力の自由度を高めると、正確で確実な検索の実行が困難となる。従って、必須入力項目を減らすことで、自由度を高め、ユーザーの入力時の作業性や使い勝手を向上させることが難しかった。

また、取引先やその役員等の情報について、簡易なメモやコメントは、手書きでの場合には管理しやすく、状況を伝えやすかったが、これをＲＤＢで管理するには、どのようなメモが生じるかを事前にすべて決定するか、単に備考とするしかなく、手書きと同様の使いやすさを実現するシステムの構築は困難であった。

さらに、ＲＤＢでは、ハードディスク等のデータ格納部の使用効率を高め、且つ、検索の効率を高めるため、全ての項目について、データ型や、データ長を予め定める必要があった。従って、ＲＤＢでコメント等の文字情報を柔軟に取り扱うには、一定の限界があった。

一方、手書きの取引先要項等では、記載内容を組織内で共有するためには複写機等で複写して郵送等する必要がある。また、取引先の最新の状態を把握するためには、取引先要項等を一定期間毎に再作成する必要がある。すなわち、取引先の役職者等や製商品等は変化するため、この部分を書き直す必要がある。しかし、更改時には、新たな帳票に記入するため、変更のない項目を書き写すなど、無駄な作業が発生してしまう。また、この更改時に、その時の担当者の転記ミス等で情報の内容変化又は記載もれが発生してしまう恐れもあり、従って、この更改作業は確認作業を含め事務処理負担の大きいものとなっていた。

また、手書きの取引先要項では、営業日誌、各種稟議、信用リスク管理等を行う毎に、ほぼ同一の内容を重複して他の帳票に記載する必要があり、事務負担が大きくなっていた。そして、手書きの帳票が多数存在すると、どの帳票に記載し、その帳票が現在どこにあるのかを管理することが煩雑で、既に記述した内容を知るために再度調査等を行うこともあった。

そして、手書きの取引先要項では、取引先の状況を文章表現する際の熟練度や個性などから、必ずしも均質で粒度のそろった情報とならない場合もあった。従って、手書きの取引先要項では、ある状況又は属性の取引先を抽出するために取引先要項の帳票等を利用するのが難しく、さらに、取引先数が多いと、紙の帳票から一定の状況にある取引先を抽出するには多大な労力を要することから、その活用には限界があった。従って、取引先要項に記載の内容を、組織で共有することが難しかった。

この取引先要項をデータベース化、システム化することで、取引先要項として記載等行う内容の情報活用を図ることが考えられる。しかしながら、取引先の種類や態様は多様であるため、手書きと同様の豊富な情報をシステム的に取り扱うことが難しい。しかも、商品の販売履歴等のみならず、取引先の組織や、事業や、動向等の情報を扱う場合には、文字情報が多く、且つ取引先によっては入力されない実体や項目もある。さらに、法人、事業性個人等取引先の法人格（以下人格）が異なると、取り扱う項目が変化してしまうため、ＲＤＢでのモデリングを行うと、エンティティのリレーションシップが複雑になり、システム開発、運用及び管理コストが大きくなってしまう。

また、取引先要項のシステム化に際しては、取引先の状況、属性又は特徴等に該当する取引先の抽出等（横検索）を良好に行えるような仕組みが望ましいが、コメントや文章を担当者が随意に記述できることとすると、横検索の精度が落ちてしまう。

また、取引先に関する情報は、それぞれの取引先や項目によって更新頻度が異なる点に対する対応が必要となる。そして、ＰＣ等の端末で取引先に関する情報を参照する際には、その情報がどの時点での情報で、現在も有効なのかという情報の鮮度を把握しづらいため、データの更新について一定の安定した取扱が必要となる。しかし、ある項目の内容が更新された場合、その項目の更新によって、どの範囲のデータが最新のものとして確認されたかを自動的に取り扱うことは難しい。

さらに、端末で取引先に関する情報を参照する場合、業務のワークフローでの途中のデータであるのか、それとも決裁されたデータであるのかをユーザーに直感的に知らせることも難しい。

そして、帳票での重複した手書きによる事務処理負担は、単純に個別の業務をシステム化したのみでは改善することができない。すなわち、各システムへ同様の内容を重複して入力・登録する等の作業が生じると、結果的に重複記載による事務処理負担を軽減することにならない。

また、従来、一定期間毎に取引先要項を更改している場合には、この更改による書き写し作業によって、結果的に、担当者がより強く取引先の状況を記憶し、見直していた。取引先要項をシステム化すると、変更点以外は参照するのみであり、従来の手書き及び更改時の書き写しによる場合と比較して、担当者の取引先の状況の把握の程度が落ちてしまう可能性も想定できる。

このように、手書きで行っていた取引先要項のシステム化では、第１に、他のシステムとの関係を整理し、第２に、手書きと同様な自由度でデータの入力及び参照を可能とし、第３に、文字データの柔軟な取扱と横検索の精度の維持との両立を図り、第４に、担当者のスキルを維持及び向上させる仕組みとすることが望ましい。

＜発明の目的＞
本発明は、取引先に関する文字データの柔軟な取扱と他のシステムとの良好な連携を維持しつつ、蓄積される取引先に関するデータを有効に活用できる取引先要項システムを提供することを、その目的とする。

本発明では、ネットワークを介して端末及び他システムと接続されたサーバーと、このサーバーによって処理されるデータを格納するデータ格納部とを備えている。しかも、サーバーが、取引先の組織及び事業と、当該取引先についての時系列での主要な動向等についての文字データを前記他システムから取得する取得制御部と、予め定められたユーザーインタフェース定義に基づいて前記文字データを前記端末に表示させると共に、取引先の組織の内容を示す組織データと、事業の内容を示す事業データと、当該取引先の主要動向を示す動向コメントデータ等の入力及び編集を制御する表示編集制御部とを備えている。サーバーはさらに、取得制御部によって他システムから取得した文字データと前記表示編集制御部による制御に応じて入力及び編集された文字データとを一体の体系での要項データとして前記データ格納部等に格納する格納制御部とを備えた、という構成を採っている。これにより前述した課題を解決しようとするものである。

取得制御部は、取引先の組織及び事業と、当該取引先についての時系列での主要な動向等についての文字データを他システムから取得する。また、表示編集制御部は、予め定められたユーザーインタフェース定義（例えば、ＧＵＩ）に基づいて他システムから取得した文字データを端末に表示させる。従って、種々の他システムから自動的に収集した文字データを一定のＧＵＩを用いてユーザーに表示する。さらに、表示編集制御部は、取引先の組織の内容を示す組織データと、事業の内容を示す事業データと、当該取引先の主要動向を示す動向コメントデータ等の入力及び編集を制御する。取得したデータの編集を許可するか否かは、業務内容や各種の権限等に応じて定める。表示編集制御部は、取得した文字データの表示と、取引先の組織、事業及び動向コメントについてのデータの入力及び編集を制御する。データのうち、顧客番号（ＣＩＦ番号）をキーとして他システムで既に管理されている氏名や住所等の項目があれば、取得した文字データとして編集不可としてもよい。また、他システムを用いたワークフローの決裁を受けた結論・結果の要点を示すコメントを、動向コメントデータとして取得する場合にも、編集不可としても良い。
本発明ではさらに、格納制御部が、取得制御部によって他システムから取得した文字データと、表示編集制御部による制御に応じて入力及び編集された文字データとを一体の体系での要項データとしてデータ格納部等に格納する。従って、他システムから自動的に取得できるデータは取得し、取引先の担当者等のユーザーの日々の活動に応じて得た情報については、予め定められたユーザーインタフェースに応じて入力及び編集し、これを一体的な体系での要項データとして格納する。一体的というのは、例えばＸＭＬ等のマークアップランゲージで一定の構造化がなされた状態である。
すると、本発明による取引先要項システムは、種々の他システムを用いた業務の結果の要点を示す重要な文字データを集約し、取引先要項として不足する部分については入力を促すものとなる。そして、取得した文字データ及び入力された文字データは、予め定められた一体的な体系で格納される。従って、集約された文字データを、他システムへ送信することが容易である。このように、本発明による取引先要項システムは、取引先に関する文字データの最上位のＤＢと位置付けられる。すなわち、本発明によると、文字データを他システムから集約し、一体的な体系で構造化したデータを随時端末に表示又は他システムへ送信することができる。他システムへの「送信」は、他システムに対して、本発明によるデータ格納部へのアクセス（検索）を許可する処理としてもよい。

第１実施形態では、取引先の主要な動向を文章で表現した動向コメントについて、明示的に内容を区分する主要動向区分コードを用いる（例えば、図３）。この主要動向区分コードを他システムと取得制御部のプロトコル又はインタフェースとすることで、動向コメントの集約及び構造化を明確にし、且つ横検索の精度を向上させることができる。また、主要動向区分のグループ（種別）を用いて、例えばリスク管理区分の主要動向区分コードが付された動向コメントのみを抽出して表示する機能を備えることで、ユーザーが取引先の履歴及び注意すべき点等を即座に視覚的に把握することができる。また、主要動向区分を厳選し、主要動向区分に区分されない動向についての入力を不可とすることで、担当者によらず、記載する動向の粒度が一定となり、また、常に主要動向区分を用いることで、取引先の様々な動向のうち、登録すべき重要な動向の選別が明確となる。
第２実施形態では、要項データをＸＭＬデータとし、表示編集に関する種々の機能を備えることで、手書きと同様な自由度でデータの入力及び参照を可能としている。また、他システムから取引先に関する基本的な文字データを取り込み、体系的な構造を維持する必須の項目を自動的に取得しつつ、ＸＭＬによる階層的なデータ構造によって各項目の位置付けの簡明で明確な理解をユーザーに促しつつ、文字データの入力を支援することで、文字データの柔軟な取扱と横検索の精度の維持との両立を図る。さらに、役職や取引先と関係を持つ法人又は個人との関係を示すコードを整理することでも、入力を容易にしつつ横検索の精度を向上させる。

本発明は、その構成によって、表示編集制御部が、種々の他システムから自動的に収集された文字データを一定のユーザーインタフェースを用いてユーザーに表示し、さらに、取引先の組織、事業及び動向コメントについてのデータの入力及び編集を制御する。さらに、格納制御部が、取得制御部によって他システムから取得した文字データと、表示編集制御部による制御に応じて入力及び編集された文字データとを一体の体系での要項データとしてデータ格納部等に格納する。従って、本発明は、種々の他システムを用いた業務の結果の要点を示す重要な文字データを集約し、取引先要項として不足する部分については入力を促し、そして、取得した文字データ及び入力された文字データは、予め定められた一体的な体系で構造化して格納する。このため、本発明による取引先要項システムは、取引先に関する文字データの最上位のＤＢに位置付けることができ、文字データを他システムから集約し、一体的な体系で構造化したデータを随時端末に表示又は他システムへ送信することができる。これにより、他システムとの重複記載を排除し、従って、同一データの重複保持及び重複したデータ間の不整合がなくなり、さらに、他システムで決裁された文字データを自動的に登録する例では、最終的な精度の高い且つ鮮度の良い文字情報の集約、参照及び他システムへの配布を行うことができる。
取引先の主要な動向を文章で表現した動向コメントについて、明示的に内容を区分する主要動向区分コードを用いる例では、この主要動向区分コードを他システムと取得制御部のプロトコル又はインタフェースとすることで、動向コメントの集約及び構造化を明確にし、且つ横検索の精度を向上させることができる。また、主要動向区分のグループ（種別）を用いて、例えばリスク管理区分の主要動向区分コードが付された動向コメントのみを抽出して表示する機能を備えることで、ユーザーが取引先の履歴及び注意すべき点等を即座に視覚的に把握することができる。さらに、主要動向区分を厳選し、主要動向区分に区分されない動向についての入力を不可とすることで、担当者の熟練度によらず、記載する動向の粒度を強制的に一定とすることができ、また、常に主要動向区分を用いることで、取引先の様々な動向のうち、登録すべき重要な動向の選別が明確となる。従って、取引店等の担当者は、主要動向区分の体系を理解し、記憶することで、取引先へ整理された質問等を行うことができ、また、重要な動向についての記載もれや、必ずしも重要ではない動向を詳細に記載する等の担当者によるバラツキを防止することができる。従って、取引先要項として蓄積される情報が均質になり、このため、報告や引継等が明確で、さらに、各種の検索に際して有用な粒度の揃ったデータを得ることができる。
さらに、要項データをＸＭＬデータとし、表示編集に関する種々の機能を備える例では、ＸＭＬによる階層的なデータ構造によって各項目の位置付けと意味の簡明で明確な理解をユーザーに促しつつ、文字データの入力を支援することで、文字データの柔軟な取扱と横検索の精度の維持との両立を図ることができる。さらに、役職や取引先と関係を持つ法人又は個人との関係を示すコードを整理することでも、入力を容易にしつつ横検索の精度を向上させることができる。また、コード化しづらい項目についても、本システムを長年使用することで、階層的なデータ構造でのデータ項目への記載が膨大なテキストデータとして蓄積されるため、新たなコード体系等の導入も容易となる。

＜第１実施形態＞
図１は第１実施形態での構成例を示すブロック図である。図１に示すように、本実施形態による取引先要項システム４は、ネットワーク２を介して端末１及び他システム４０と接続されたサーバーと、このサーバーによって処理されるデータを格納するデータ格納部３とを備えている。そして、サーバーは、取引先の組織及び事業と、当該取引先についての時系列での主要な動向等についての文字データを他システム４０から取得する取得制御部６と、予め定められたユーザーインタフェース定義（ＧＵＩ定義等）に基づいて取得した文字データを端末１に表示させると共に、取引先の組織の内容を示す組織データと、事業の内容を示す事業データと、当該取引先の主要動向を示す動向コメントデータ等の入力及び編集を制御する表示編集制御部８とを備えている。

サーバーはさらに、取得制御部６によって他システムから自動的に取得した文字データと、表示編集制御部８による制御に応じて入力及び編集された文字データとを一体の体系での要項データとしてデータ格納部３等に格納する格納制御部１０を備えている。

端末１は、本部や営業店のユーザーが使用できるＰＣである。また、携帯電話又はＰＤＡ等の携帯端末を用いるようにしても良い。端末１は、サーバーから送信されるデータやプログラムに従って、サーバーから送信されるデータを表示し、またサーバーに送信するデータの入力等を制御する。端末に実行環境を導入し、端末で実行するプログラムをサーバーから端末へ送信し、これを端末で実行することで、端末の画面への表示や、端末から入力されるボタン操作や、コンボボックスの選択や、入力される文字データのサーバーへの送信を行う。また、端末にＷｅｂブラウザを導入し、ＨＴＴＰに従ったＨＴＭＬデータ等の送受信を行うことで、上述の仕組みを実現しても良いし、全ての端末にアプリケーションを導入し、サーバーと通信するような仕組みとしても良い。

ネットワーク２は、ＬＡＮやＷＡＮ等の通信回線で、ＴＣＰ／ＩＰ等のプロトコルでＰＣとサーバーとを接続する。データ格納部３は、例えばハードディスク等の不揮発性メモリである。また、サーバーからみたデータ格納部３を、リソースやＤＢとして抽象化して取扱う場合には、データ格納部３にＤＢＭＳやその他のデータ管理用のソフトウエアを導入するとよい。この場合、サーバーはＳＱＬ等の一般的なデータ操作コマンドや、データベースアクセス用ＡＰＩを用いてデータ格納部３を利用することができる。図１に示す例では、データ格納部３を一つとしているが、分散させても良いし、ネットワークを介して他の場所に配置するようにしても良い。

本実施形態による取引先要項システムを金融機関で用いる場合、他システムは、図２に示すように、勘定系や情報系等のオンラインシステム４２や、財務分析システム４３や、取引先（債務者）等の信用リスクを定性的、定量的に判定するための信用格付システム４４Ａや、融資残高（債権）等の金融機関の資産査定を行うための自己査定システム４４Ｂや、どのような条件で融資を行うか否か等のワークフローを管理する融資稟議システム（案件管理システム）４５や、営業店や本店営業部の担当者の業務内容や報告等を管理する営業日誌システム４７等である。

取得制御部６は、上記他システム４０で入力、検討及び決裁されたデータのうち、取引先の組織及び事業と、当該取引先についての時系列での主要な動向等についての文字データを取得する。図１に示すように、取得制御部６は、他システム４０によるワークフローにて決裁された結論又は結果の要点となる文字データを当該他システムの属性に応じて動向コメントとして自動的に取得する結論要点データ取得機能７を備えると良い。取得制御部６は、例えば、他システムのＤＢにＳＱＬ文などで検索し、その検索結果をデータ格納部３に挿入・更新する。金融機関で口座への入出金等の口座処理を行うオンラインシステム４２で、ＲＤＢではないシステムからのデータの取得には、オンラインシステム４２側で新たなオペレーションを定義するようにしても良いし、また、オンラインシステム４２で蓄積したデータを月次等で更新管理する基盤ＤＢを構築し、使用するようにしても良い。

表示編集制御部８は、予め定められたユーザーインタフェース定義（ＧＵＩ定義等）に基づいて取得した文字データを端末１に表示させると共に、取引先の組織の内容を示す組織データと、事業の内容を示す事業データと、当該取引先の主要動向を示す動向コメントデータ等の入力及び編集を制御する。表示編集制御部８は、この入力及び編集制御に応じて登録されたデータがデータ格納部３に格納されている場合には、このデータも端末に表示する。端末表示の例を図４及び１３等に示す。図１に示すように、表示編集制御部８は、端末１を使用するユーザーの権限に応じて各文字データの表示、編集及び削除の可否を制御する権限別機能制限制御機能を備えるようにしても良い。

格納制御部１０は、取得制御部６によって他システムから自動的に取得した文字データと、表示編集制御部８による制御に応じて現在又は過去に入力及び編集された文字データとを一体の体系での要項データとしてデータ格納部３等に格納する。「一体の体系」は、好ましくは、要項データ全体での階層的な構造化である。また、実体のリレーションシップを体系的に構築したものでも良い。階層的な構造化を行うために、ＸＭＬを用いる例を第２実施形態として後述する。格納制御部１０は、データベースを操作する言語やＡＰＩを用いて、データ格納部３に要項データを一体的な体系で格納する。図１に示す例では、格納制御部１０は、他システム４０からの要求に応じて取引先毎の要項データの一部又は全部を当該他システム４０に送信する送信制御機能を備えている。取引先要項システムで取り扱うデータ項目を一体の体系で整理し、他システム４０からデータの収集を行い、端末１で入力及び編集し、これを一体的に格納し、その一部又は全部を当該階層構造等の情報を付加した状態で他システムに送信する。このため、本発明では、他システムで要項データをＲＤＢへ取り込む場合や、画面表示する際の取扱が容易となる。このように、他システムでの用途や属性に応じた重要な情報を取引先要項システムに集約し、且つ、集約されたデータを各他システムに送信することができる。

本実施形態による取引先要項システム４は、他システムでの用途や属性に応じた重要な情報を集約し、且つ、集約されたデータを各他システムに送信するものであるため、取引先に関連する文字データの最上位のＤＢと位置付けることができる。取引先要項システムを文字ＤＢの最上位に位置付け、他システムから文字データを収集し、体系付けられた要項データとして全部又は一部を他システムへ供給することで、重複記載をなくし、データの再利用性を高めることができる。そして、他システムへ標準的な文字データの取扱（インタフェース）を提供することができるため、他システムの開発に際して、文字データの取扱に関する開発負荷を軽減し、且つ、少ない開発負荷でありながら、安定して管理される取引先要項システムから必要な文字データを受け取ることができる。また、複数の他システムから取得するデータ項目であっても、要項データとしての構造・体系に位置付けられたデータとなるため、他システム間や、他システムと取引先要項システムとの間でデータの整合性を維持しやすい。

図２は取引先要項システムを金融機関で使用する場合の他システムと取引先要項システムとの連携の例を示す説明図である。オンラインシステム４２は、口座を管理する必要性から、取引先を識別するためのＣＩＦ番号と、氏名又は名称と、住所等の取引先の基本属性データを日々管理している。また、これらの基本属性データは、月次での顧客情報として基盤ＤＢ等のＲＤＢに格納される。取引先要項システムは、この基盤ＤＢから月次で基本属性データを取得する。また、基盤ＤＢに対して、検索用に要項の履歴データ等を送信するようにしても良い。さらに、融資に関連した企業間の名寄せ処理（関連融資先名寄せ）を取引先要項システムで作業する場合には、オンラインシステムに名寄せ結果（グループ番号と、ＣＩＦ番号の組など）を送信するようにしても良い。

信用格付システム４４Ａは、取引先の財務状況等の評価に基づいて、取引先の信用格付を判定し、本部決裁を受けるシステムである。取引先要項システムで格付を取り扱う場合には、この信用格付システムから格付データ等を取得すると良い。例えば、取引先動向を示す動向コメントは時系列で管理するため、これらの動向があった後の格付変化等を取引先要項システムで主要動向と共に表示するようにしても良い。信用格付の作業では、取引先の業界での地位や、業種や、取り扱う製商品等のデータが必要となる。このため、取引先要項システム４は、信用格付システムに、取引先の概況や、企業名寄せの結果や、親会社又は子会社の有無や製商品情報等を送信すると良い。また、取引先の業界での地位についてのコメントや、製商品に関するコメントを信用格付システム４４Ａで入力し、決裁する場合には、このコメント情報を取引先要項システムに自動的に取り込むようにすると良い。

財務分析システム４３は、融資や、信用リスク管理などの必要性から、決算書を徴求できる取引先の財務状態を分析するシステムである。平均月商や、利益率等はオンラインシステムで管理しても良いし、財務分析システムで管理しても良い。このため、取引先要項で使用する各取引先の平均月商や、その取引先の決算時の従業員数等を財務分析システムから取得するようにしても良い。また、財務登録時に、大株主等の異動があった場合には、財務分析システムのワークフローで必要な回覧を行い、決裁後に取引先要項システムに自動的に登録するようにしても良い。

自己査定システムは、信用リスク管理の観点から、融資等の債権の資産査定を行うものである。自己査定は、銀行の決算期に併せて年二回実施し、債務者の状況に応じて正常先、要注意先、破綻懸念先等の債務者区分に区分し、さらにその債権をＩ分類からＩＶ分類までに分類する。この分類額等に基づいて、貸倒引当金を算出し、銀行の資産状況を決算に反映する。この債務者を区分する作業では、取引先の業種や、業界での地位や、取扱製商品毎の月商等をも検討する。このため、オンラインシステム４２や財務分析システム４３から取得した業種コードや平均月商を、自己査定システムに送信する。また、自己査定では、取引先の概況を添付することが多い。この場合、自己査定の日付での要項データを自己査定システムに送信する。

この自己査定に関して、出願人は、取引先（債務者）に業況変化があった時や、財務登録があった時など、年間を通じて随時のタイミングで資産査定を行うための資産査定システム４４を開発し、特許出願した。この資産査定システム４４では、取引先の業況変化があった場合に、自己査定作業を起票する。この取引先の業況変化は、取引先要項システム４での取引先の主要な動向のひとつでもある。業況変化があった場合には、資産査定システム４４を使用した自己査定作業を通じて、取引先の業況変化の内容を正確に把握し、営業店から監査部門までのワークフローを経由して検討を重ね、決裁され、信用格付及び債務者区分等が維持又は変更される。取引先要項システム４は、この決裁された自己査定起票理由を動向コメントとして自動的に取得する。その他、資産査定システム４４は、債務者の概況を取引先要項の対応する項目から自動的に取得するようにしても良い。

融資稟議システム４５は、融資の提案を取引先に行い、または融資の申込を取引先から受けた場合に、取引先の状況等を整理し、融資の条件や可否等の承認・決裁のワークフローを管理するシステムである。融資稟議では、取引先要項を添付する必要がある。このため、取引先要項システムは、融資稟議を行う時点での要項データを融資稟議システムに送信する。また、自己査定時に融資の方針等を決裁している場合には、その融資方針やコメントを取引先要項の一部とし、当該融資方針等を取引先要項システムから融資稟議システムに送信するようにしても良い。一方、融資稟議システム４５によって制御されるワークフローにて、融資の申込を断り、謝絶することとなった場合には、その謝絶の重要度に応じて、当該取引先との取引経緯又は営業推進に関する動向として取引先要項システムに登録するようにしても良い。

営業日誌システムは、営業店での担当者が業務状況を報告等、営業推進のワークフローを管理するためのシステムである。営業日誌システムは、案件管理や、融資稟議システム等と連携させて、売り込みや、ＤＭ発送への応答の管理等を行うようにしても良い。この場合、営業推進の業務の途中経過は営業日誌システム等で管理し、営業推進の結果なんらかの成約を得たか、又は不成約となった事項について、その営業推進の重要度に応じて、動向コメントとして取引先要項に自動的に登録するようにしても良い。

このように、取引先要項システム４は、文字データ取扱の最上位のＤＢと位置付けられ、ワークフローが完了し、結論、結果が出た状態で、その要点を簡潔に示す文字データを登録するシステムとして利用することができる。文字データの取扱に関して、このような性格の取引先要項システム４を使用すると、多数のシステムで取り扱う文字データに関して、結論を示す文字データの集約と配布とを整合性を保ちつつ容易に取り扱うことができる。特に、取引先要項システムではその項目を一体的な体系で取り扱うため、他システムとの文字データの共有を行いやすく、すると、全てのシステムで矛盾のない一貫性のある文字データの取扱を、ユーザーの負担を増加することなく実現することができる。

そして、取引先要項システムに重要な文字データが集約されると、情報の散逸を防止することができ、且つ、内容を確かめたい場合にはＰＣ等の端末の操作で随時参照することができる。すなわち、取引先要項システムを利用することで、詳細な各システムでの作業結果を一覧として参照することができ、重複登録を防止しつつ、他システムのデータとの整合性を保つことができる。

業務としても、他システムのワークフローによる結論を登録するという一貫した且つ安定した業務プロセスの確立により、コメント情報の均質さ及び正確さを維持することができ、また、要項データの体系的な構造の一部として、文字データの根拠となったシステム及びデータを明示する仕組みとすると、この文字データの根拠へのアクセスが容易となり、取引先要項システム４を取引先の情報に関係する窓口として利用することができる。このような体系的で整理された情報の蓄積が行われると、営業店等での引継時間を短縮し、さらに引継もれ等の発生を有効に防止することができる。また、結論等を得るまでのワークフローは他システムで行うため、取引先要項システムでの回覧等は不要となる。

再度図１を参照すると、本実施形態による取引先要項システム４は、サーバーが、当該取引先についての時系列での主要な動向を明示的に区分する主要動向区分を管理すると共に、当該主要動向区分の他システムとの共有を制御する主要動向区分管理部１６を備えている。「明示的に区分」というのは、例えば、主要動向区分を、取引先動向のレコードでの必須入力項目とすることをいう。さらに、主要動向区分として「その他」のように種類や属性を明示できない区分を設けないようにしても良い。

金融機関で利用する場合の主要動向区分コード及び主要動向区分名称の例を図３に示す。図３に示す例では、取引先要項システム４の表示編集制御部８の制御に応じて動向コメントを入力する場合、その動向コメントが属する区分を予め整理している。融資取引の開始は種々の態様があるが、融資取引の開始についての動向コメントは常に00200の「当行融資取引開始」という主要動向区分に属する。

主要動向区分管理部１６は、この主要動向区分の種別を管理する種別管理機能１８を備えている。主要動向区分の区分種別は、図３に示すように、取引先との取引経緯に関する取引経緯種別と、当該取引先の組織や事業の変遷に関する組織・事業変遷種別と、当該取引先の財務会計の基礎事項に関する財務会計基礎種別と、関連会社及び事業施設に関する関連会社・施設種別と、当該取引先への債権等についての信用リスクに関連するリスク管理種別とである。また、主要動向区分の種別として、取引先への営業推進に関する営業推進種別に属する主要動向区分を定義しても良い。

図４に動向コメントを取り扱う取引先要項システムのＧＵＩ及び内容例を示す。以下、画面や取引先の例を説明のために開示するが、内容は仮想的な事例であり、実在の法人、個人とは無関係である。

図４に示す例では、取引先要項システムで取り扱う取引経緯は、取引先動向テーブル１００に表示されている。取引先動向テーブル１００は、一覧表示として複数の取引先動向レコード（表内の一行）を有しており、この取引先動向レコードは、発生年月日と、主要動向区分と、詳細（動向コメント）と、記入年月日と、記入者とを有する。図４に示す例では、表示編集制御部８が、前記主要動向区分を前記動向コメント入力の必須入力項目として制御する主要動向区分必須入力制御機能２０を備えているため、この機能２０による制御に応じて、取引先要項システム４で取り扱う動向コメントには、全て主要動向区分が付されている。このため、主要動向区分にない動向については、記載がなされていない。主要動向区分によって動向コメントを明示的に区分することで、主要動向区分に当てはまらない取引先の動向については、不要なものとして、当該取引先要項システムには登録しないことになる。これにより、動向コメントの重要性に関する粒度をユーザーの熟練によらず、システム的に強制し、均質なデータ蓄積を図ることができる。

図４に示す例では、融資取引の発生年月日は１９６０年１０月１日であり、同日に、取引開始前の取引先の動向を登録している。記入者欄については、店番やフルネームを表示するが、図中省略している。その後、受手・売掛金事故や、事業施設設置等の主要動向区分に定義された重要事項のみが登録されている。「受手」は、受取手形である。１９７０年１０月には、取引店の変更である移管が生じている。このとき、記入者は長野支店の担当者から本店営業部の担当者となった。その後、上場や子会社の設立を経て、２００１年には業績不振となっている。この業績不振に関する動向コメントは、例えば資産査定システム４４Ｂにて当該業績不振に応じた債務者区分の見直しを行った場合には、この資産査定システム４４Ｂから自動的に取得することができる。

また、主要動向区分管理部１６は、図１に示すように、各主要動向区分を当該区分に属するさらに詳細な主要動向サブ区分を管理するサブ区分管理機能２２を備えるようにしても良い。この場合、主要動向サブ区分を用いることで、動向コメントの記載をさらに端的で短いものとすることができ、さらに、横検索での適合率をより高めることができる。サブ区分の例としては、周辺状況の悪化の種類及び程度や、業績不振の度合いや、法的手続申立での適用法律等などがある。

好ましい例では、主要動向区分管理部１６が、主要動向区分の種別毎の動向コメントの端末１への表示を制御する種別表示制御機能２４を備える。種別表示機能により、担当者のスキルを維持及び向上させると共に、取引先の状況を短時間での正確な把握を促す。種別表示制御機能２４は、例えば、リスク管理種別に属する動向コメントのみの表示や、組織・事業変遷の種別に属する動向コメントのみを抽出して表示させる。図４に示す例では、全表示と、リスク管理種別のみの表示との二通りを提供している。

図５は、動向コメントの種別表示の一例を示す説明図である。図４に示す取引先動向レコードのうち、リスク管理種別に属する主要動向区分が付されたレコードは、受手・売掛金事故と、業績不振の２つである。ユーザーは、このリスク管理種別（管理項目）のみの表示と、全表示との表示を見比べ、リスク管理項目については特に精査するなどの作業により、取引先の動向を短時間で且つ正確に把握することができる。

管理項目のみの表示を行うには、図３に示す例では、主要動向区分コードが１０，０００以上２０，０００未満の取引先動向レコードを抽出する。図６は、動向コメントの種別表示制御の一例を示すフローチャートである。まず、表示対象の取引先を識別するＣＩＦ番号を特定することで、データ格納部３に格納された当該取引先の動向コメント群を特定する（ステップＳ１，取引先特定工程）。続いて、端末１に表示する主要動向区分の種別を取得し（ステップＳ２）と共に当該種別等に応じて主要動向区分の抽出範囲を設定する（ステップＳ３，抽出範囲設定工程）。例えば、図４に示す管理項目表示ボタンの押下があれば、表示する主要動向区分の種別を図３に示すリスク管理種別として、抽出対象の主要動向区分コードを１０，０００以上２０，０００未満とする。続いて、取引先動向を１レコード分（一行分）読み込み（ステップＳ４）、この取引先動向レコードの主要動向区分コードが１０，０００以上２０，０００未満であるか否かを判定する（ステップＳ５）。範囲内であれば、種別の表示対象に追加する。例えば、画面表示用の配列に格納する。そして、取引先動向テーブルの全レコードの読み込みが完了したか否かを確認し（ステップＳ７）、未読のレコードがあれば、次のレコードを読み取り対象に設定する（ステップＳ８）。

このステップＳ４乃至Ｓ８を繰り返し、抽出範囲設定工程Ｓ２，Ｓ３にて設定された抽出範囲に属する主要動向区分の全ての取引先レコードを抽出する（範囲内動向コメント抽出工程）。続いて、種別表示対象となった取引先動向レコードを端末１に表示する（ステップＳ９，抽出表示制御工程）。

図１に示す構成や、図６等に示す処理は、サーバーのＣＰＵが所定のプログラムを実行することで実現することができる。取引先要項システムのサーバー及び端末のＣＰＵ（図示せず）は、所定のプログラム（指令）に従って各種の演算を行う。ＣＰＵは、各種の処理要求に従って端末１の画面に文字データ等を表示し、動向コメントデータ等の入力を促進する。

本実施形態では特に、取引先動向表示用プログラムは、下記指令を備える。
表示対象の取引先を識別するＣＩＦ番号を特定することでデータ格納部３に格納された当該取引先動向レコード群を特定させる取引先特定指令。
端末１に表示する主要動向区分の種別又は属性を取得させると共に当該種別等に応じて主要動向区分の抽出範囲を設定させる抽出範囲設定指令。
この抽出範囲設定指令に応じて設定される抽出範囲に属する主要動向区分の取引先動向レコードを抽出させる範囲内動向コメント抽出指令。
この範囲内取引先動向レコード抽出指令に応じて抽出される取引先動向レコード群を前記端末に表示させる抽出表示制御指令。

この取引先動向表示用プログラムは、磁気テープ（ＭＴ）やディスク等の記録媒体１１Ａに格納されて搬送され、ディスクドライブ１１によって読み取られる。記録媒体に格納されていた取引先動向表示用プログラムは、ディスクドライブ１１にて読み取られた後、図示しないプログラム記憶部に格納される。また、他のホスト装置から通信回線を経由してプログラム記憶部に当該プログラムを提供することもできる。

プログラムについて、ＣＰＵを「動作させる指令」というときには、各指令のみでＣＰＵを動作させる指令と、プログラム記憶部に予め格納されているオペレーティングシステム等の他のプログラムに依存して当該ＣＰＵを動作させる指令とのいずれかまたは双方を含む。ここでは、「オペレーティングシステム」は広義に解釈している。トランザクションマネージャーや、データベースマネージャーや、実行環境等を含む。

営業推進に関する動向コメントを蓄積する例では、主要動向区分の取引経緯種別に対応する主要動向区分を追加するようにしてもよい。好ましい例では、営業推進に関する動向コメントは、他の種別の動向コメントと関係して格納すると、登録及び参照が容易で、且つ理解しやすい取引先動向を生成することができる。この例では、主要動向区分管理部１６が、動向コメントに示される取引先の動向と関連した営業推進の内容を対応する動向コメントと関連させて営業推進種別の動向コメントとして登録する動向別推進結果登録機能２６を備える。動向別推進結果登録機能２６は、事業の展開・変動や、事業施設設置等に区分される取引先の動向と関連して、融資の実行等の営業推進内容を登録する。

好ましい例では、主要動向区分管理部１６が、営業推進種別の動向コメントを、当該営業推進結果の成約及び不成約を示す推進結果コードで管理する推進結果コード管理機能２８を備えると良い。成約は、融資等の契約が成立した場合で、不成約は、融資等の提案を行ったが、取引先から断られた場合と、融資の申込の審査の結果、条件等が合わず、融資の実行ができないと判断した場合とがある。主要動向区分の「謝絶」は、こうした融資の実行ができないと判断した場合の区分であるが、「謝絶」という場合には、手形交換所での取引停止処分を受けているとか、融資の審査に際して、決算書の過度の粉飾を発見した等、より信用リスクの高い状態の意味合いが強く、こうした場合には取引経緯としての登録となる。

図７は、営業推進種別の動向コメントを他の種別の主要動向区分と関連させた例を示す説明図である。図７に示す例では、詳細コメントに取引先の動向と、営業推進の内容及び結果を記載している。そして、詳細コメントと記入年月日の間に、営業推進の結果の成約又は不成約を表示している。例えば、１９６０年１０月１日の当行融資取引開始では、成約となっている。このとき、「Ａ信金１行取引から当行取引開始により併行取引となる。手貸１０百万円及び当座開設新規成約」とのコメントを記載する。１９６５年１０月１日には、取引店の新しい担当者が営業推進を行い、工場建設及び設備資金で証貸１００百万円成約（期間15年）となっている。１９７３年４月には、子会社の設立に着目し、「運転資金を推進したが、Ａ信金より資金調達」となり、不成約となっている。図７に示す例では、推進項目表示ボタンを押し下げることにより、これらのみ表示することも可能である。

図３等に示す例では、動向コメントを区分する主要動向区分は、複数の種別と、各種別に属する区分という階層構造となっている。また、サブ区分を用いる場合には、三階層となる。この階層的な取扱により、取引先の動向の重要性を体系付けることができる。一方、階層的な構造では、ある項目を別の項目に一時的に所属させたい場合が生じる。また、各項目の根拠や関連に関するリンクを付すことができれば、他システムでの作業結果ファイル等との関係をシステム的に取り扱うことができる。このような例では、図１に示すように、主要動向区分管理部１６が、取引先についての時系列での主要な動向についての動向コメントデータを区分する主要動向区分を、主要動向区分が属する種別と、当該主要動向区分と、当該主要動向区分内で詳細に区分するサブ区分とのツリー構造で管理する区分ツリー構造管理機能３０と、各動向コメントデータに前記ツリー構造とは別に当該動向コメントデータをグループ分けするためのコメント属性又は当該動向コメントデータの根拠等と関連したコメント属性を管理するコメント属性管理機能３２とを備えるとよい。

区分ツリー構造管理機能３０は、主要動向区分を三階層で管理する。そして、コメント属性管理機能３２は、各コメントの属性情報を管理する。コメントの属性情報として他システムのファイル名等を格納すると、動向コメントの自動登録と、そのコメントの根拠となる資料のファイル名とを自動的に取引先要項システムに登録することができる。また、例えば、「事業の展開・変動」がリスク管理の対象（原因）となる場合、この属性をリスク管理種別とすることで、管理項目表示に際してこの動向コメントを含めることができる。この例では、図６のステップＳ３では、主要動向区分コードのコード値と、動向コメントの属性情報とに関して抽出範囲を設定する。例えば、図７に示す推進項目表示ボタンの押し下げによる種別表示では、推進結果コードが属性情報として登録されている動向コメントと、図３に示す取引履歴種別に属する主要動向区分コードが登録されている動向コメントとを抽出し、表示するようにしてもよい。また、主要動向区分のコード値を用いずに、表示用フラグ等の属性情報のみで種別表示を制御するようにしてもよい。また、種別表示と、種別の他システムへの送信はほぼ同様の機能で実現できる。従って、他システムへの種別送信は、主要動向区分のみや、属性情報のみや、両者の使用で実現することができる。

＜第２実施形態＞
第２実施形態では、ＸＭＬ(eXtensible Markup Language)等の構造化されたマークアップ言語（ＭＬ）を使用して取引先要項システムを構築する例を説明する。ＸＭＬは、ＳＧＭＬ(Standard Generalized Markup Language)から派生した文書記述形式であり、ＳＧＭＬを簡略化すると共に、インターネットでの利用に適合させている。ＸＭＬでは、ＤＴＤ(document type definition)を定義することで、データの用途に応じたタグの体系（タグセット）を使用する。タグの体系を用いることで、要素や属性の文書型を定義することができる。ＸＭＬデータは、文書の構造をＤＴＤで定義されたタグで示したテキストファイルである。ＸＭＬはＳＧＭＬに基づいているため、書籍やＷｅｂページ等の非定型文書の処理に適している。例えば、１つの項目に入るデータの長さを予め定めることができず、また、項目数が変化するような文書をＲＤＢで管理することは困難であるが、ＸＭＬデータはタグ付けされたテキストデータであるため、文字情報を柔軟に取り扱うことができる。

ＸＭＬの文書の構造を示すタグの体系は、階層型となっている。階層型は、例えば、生物という要素が動物と植物と微生物とを含み、動物という要素がほ乳類、は虫類という種を含み、というツリー構造である。ツリー構造は、人間にとって、その要素の意味内容を理解する上で有用である。一方、ツリー構造は、コンピュータにとって、要素をノードとする親子関係へのアクセスでデータを操作することができる点で扱いやすい。階層構造で明確に定義された文字データの集合であるＸＭＬデータは、ページのマークアップのみならず、各種のプロパティを管理するためのメタコンテンツの記述や、ＲＤＢとのデータ交換や、メッセージングに利用することができる。すなわち、文書の構造を示すタグは、ページ等での表現形式の指定や、要素である文字データのシステムにおける属性の指定や、ＲＤＢのテーブルの項目との対応を示す用途に用いられる。

タグの体系を定義するＤＴＤでは、要素のデータ型は文字データのみとなっている。指定されたＤＴＤに正しく従っているＸＭＬ文書を、妥当（Valid）であるという。妥当なＸＭＬ文書は、ＤＴＤに定義されている要素の名前や、階層や、順序や、要素が必須であるか又は任意であるか等の出現回数の指定に従っている。

ＸＭＬデータを取り扱うソフトウエア・モジュールをＸＭＬパーサー（ＸＭＬプロセッサ）という。ＸＭＬパーサーは、ＸＭＬデータを構文解析し、妥当性の検証等を行う。妥当性が検証されたＸＭＬデータは、予め定められたタグ体系に従っている。ＸＭＬデータの内部構造にアクセスするためのＡＰＩ（Application Programming Interface）としては、ＤＯＭ（Document Object Model）やＳＡＸ（Simple API for XML）等がある。ＤＯＭは、ＸＭＬデータを要素や文字データというノードからなるツリー（ＤＯＭツリー）として表現する。妥当なＸＭＬデータのＤＯＭツリーは、ＤＴＤによる階層定義に従っている。ＸＭＬ文書の要素をある順序でソートしたり、別の場所に移したり、新たな要素を挿入したりする処理には、ＤＯＭＡＰＩが適している。

ＸＭＬはサーバーと端末間でデータ及びプログラムを送受信しつつ一定の機能を実現するＷｅｂアプリケーションによって利用されることが多く、このため、妥当性の検証を行う機能を持ったＸＭＬパーサー等は、オブジェクト指向言語であるＪａｖａ（登録商標）向けに開発されたものが多い。Ｊａｖａの開発環境／実行環境では、クラス階層が既に定義されており、また、多重継承を行わずにインタフェース（他の言語では、プロトコルとも呼ばれる）を活用することで、モジュールやコンポーネントと呼ばれるプログラムの部品の再利用性と独立性を高めている。Ｊａｖａの開発環境では、ＸＭＬの妥当性検証などは既存のモジュールを利用することができる。また、Ｗｅｂアプリケーションの開発、特にＪ２ＥＥ（Java 2 Platform, Enterprise Edition）では、データベース、サーバー及び端末を概念的、役割的に三層から五層に分けて把握する。例えば、Ｊ２ＥＥでは、ＧＵＩを生成するためのプレゼンテーション機能を提供するＷｅｂ層と、アプリケーションロジックを実行するためのＥＪＢ層とを分離することができる。ＥＪＢ(Enterprise Java Beans)は、Ｊ２ＥＥでのビジネスロジック用のコンポーネントであり、ＥＪＢの実行環境であるＥＪＢコンテナがトランザクション処理、セキュリティ、負荷分散等の詳細を管理するため、ＥＪＢのプログラマはビジネスロジックのコーディングに集中することができる。例えば、ＥＪＢを用いると、分散トランザクションは自動的にサポートされ、複数のデータベースを利用しても、トランザクションの原子的な更新を行うことができる。これは、例えば、取引先要項システムのデータベースへのデータの登録と、他システムのデータベースへのデータの登録とを一つのトランザクション内で原子的に格納することを容易に実現できることを意味する。

Ｊ２ＥＥでは、端末は、Ｗｅｂブラウザか、ＧＵＩを装備したＪａｖａアプリケーションを用いる例が多い。Ｊａｖａアプリケーションを利用する場合には、ＧＵＩとしてＳｗｉｎｇ又はこれを利用した画面設計ツールを用いると、ＧＵＩの定義が容易となる。ＥＪＢは、端末１のＪａｖａアプリケーションとセッションを維持し、ボタン押下等のイベントを直接に又はプレゼンテーション層を介して受信することができる。ＥＪＢは、イベントに応じて、表示モードの変更を指示したり、要素間での構成比率の算出を行ったり、導出元の入力を検索キーとしてＲＤＢから検索し、ＤＯＭツリーを操作して検索結果を導出先の要素として追加したり、要素のソートを行うことができる。要素のソートをプレゼンテーションの問題と捉える場合には、このソートをプレゼンテーション層に実装する。

ＸＭＬデータのデータベースへの格納には、種々の方式が提案されている。ＸＭＬのタグをＲＤＢのテーブルにマッピングし、ＲＤＢに格納する方式や、ＸＭＬデータを巨大なテキストデータとして格納し、検索用のインデックスをサイド表として生成する方式や、オブジェクト指向データベースでのクラス階層にＸＭＬデータをマッピングする方式などである。

ＸＭＬデータの操作では、ＤＯＭツリーを用いるのではなく、コンプレックスレコードのスキーマ定義を行い、ＸＭＬデータのタグと、Ｊａｖａのオブジェクトと、データベースのレコードとを任意のタイミングで相互に変換可能とする開発・実行環境も提供されている。また、文書型定義をよりＸＭＬ関連技術で使用しやすくするための手法として、ＸＭＬＳｃｈｅｍａが定められている。ＸＭＬＳｃｈｅｍａを用いる場合には、ＸＭＬデータの妥当性検証にてデータ型等の検証を行うことができる。

本実施形態では、ＤＴＤ、ＤＯＭツリー、ＸＭＬデータをテキストとして格納しサイド表を用いてＳＱＬでの検索を可能とするデータベース、Ｊ２ＥＥによるＥＪＢ、さらに、ＳｗｉｎｇによるＧＵＩ、Ｗｅｂブラウザで実行されるアプレット、ＥＪＢやサーブレットやアプレットを使用した型チェックや表示編集制御、ＲＤＢを用いた他システムからのデータの取込等の技術を利用する。ＤＴＤや、ＤＯＭツリーや、ＳＱＬによる検索や、アプレット及びＷｅｂブラウザに代えて、ＸＭＬＳｃｈｅｍａや、コンプレックスレコードや、ＸＱｕｅｒｙや、ＷｅｂブラウザとＸＳＬＴの組み合わせ等を用いるようにしてもよい。端末をＰＤＡや携帯電話等の携帯端末とする場合、例えば表示のみを提供するために、ＸＭＬデータをＸＳＬＴでＨＴＭＬに変換し、送信する仕組みとしてもよい。

図８は、第２実施形態の構成例を示すブロック図である。本実施形態による取引先要項システムは、ＲＤＢと連携するマークアップランゲージ（ＭＬ）のタグの体系を定義したタグ体系定義ファイル５０と、端末での表示及び入力について予め定められたＧＵＩ定義ファイル５２と、前記ＭＬのタグ付けされた取引先毎のタグ付きデータを格納するＭＬデータＤＢ（図８に示す例では、ＸＭＬデータＤＢ）５４と、他システム４０にて一定期間毎に更新されるデータを格納したＲＤＢ５６とを格納するデータ格納部３とを備えている。

タグ体系定義ファイル５０は、例えばＤＴＤファイルである。ＧＵＩ定義は、Ｓｗｉｎｇ等による画面のレイアウト定義と、各画面で使用するテーブルの項目（フィールド）と関連して定義したデータ型等と、項目間の導出関係の定義と、表示のプロパティデータと表示するボタン等の関係等である。ＸＭＬデータＤＢ５４は、例えば、ＸＭＬを巨大なテキストファイルとして格納し、検索用のサイド表を作成するＲＤＢの拡張を用いると、項目数の増減について比較的柔軟な取扱が可能となる。ＲＤＢは、ＩＭＳ等の階層型データ構造を使用するオンラインシステムのデータを取り込む機能を有するＲＤＢを用いるとよい。

図８に示す例では、サーバーは、取引先の組織及び事業並びに主要な動向等についてのデータの端末での表示及び入力を前記ＧＵＩ定義に従って制御する表示編集制御部８と、他システム４０から取り込んだデータ及び端末１から入力されたデータをＲＤＢ５６でのデータ項目名若しくは前記ＧＵＩ定義に関連した前記タグ体系定義に基づいてタグ付きデータに変換すると共に、当該タグ付きデータを一体的な要項データとして前記ＭＬデータＤＢに格納する格納制御部１０とを備えている。

表示編集制御部８は、プレゼンテーション層のソフトウエア群と、ビジネスロジックを実行するＥＪＢである。格納制御部１０は、ＸＭＬデータＤＢ５４へＸＭＬデータを格納するためのＥＪＢコンポーネントと、格納前にＤＴＤによる検証を行うパーサーモジュールと、例えばＪＤＢＣ等を用いる場合にはＪＤＢＣのＡＰＩをＸＭＬデータＤＢ５４のＡＰＩにマッピングするＤＢ５４のドライバー等である。

表示編集制御部８は、ＧＵＩ定義と取引先の態様とに応じて、当該取引先の態様毎に入力不可とする項目を制御する入力不可制御機能６０を備えている。この機能６０は、例えば法人であれば屋号フィールドの入力を不可にする一方、個人事業主であれば入力可にする等の制御を行う。これにより、種々の人格で利用する全てのタグを１つのＤＴＤで定義し、また、画面のレイアウトも法人と個人事業主とで同一とすることができる。

また、表示編集制御部８は、他システム４０にて更新されるデータをタグ体系定義に基づいて取得すると共に、導出元項目への入力からＧＵＩ定義に基づいて導出先項目の内容を導出する制御をする導出制御機能６２を備えている。他システム４０で更新されるデータのうち、オンラインシステム４２から基盤ＤＢ等を介して月次で取得する基本属性データや融資基本属性データは、ＣＩＦ番号をキーとしてＲＤＢで管理されている。このため、取引先要項の各種のテーブルで、ＣＩＦ番号を有するレコードでは、ＣＩＦ番号から、氏名又は名称、住所、融資先番号、主取引店、業種コード等を導出することができる。

導出制御部６２は、導出元項目であるＣＩＦ番号から、導出先項目である氏名又は名称等を導出する制御を行う。導出制御は、例えば、プレゼンテーション層では、導出元項目がアクティブになり、入力が開始された場合に、導出先項目をグレーアウトするなどして入力不可とする。ＥＪＢ層では、ＣＩＦ番号を検索キーとしてＲＤＢ５６から必要な項目のデータを抽出し、ＤＯＭツリー又は画面表示用に編集したデータの対応する導出先項目へ挿入する。

導出制御部６２は、さらに、構成比率の算出等を行う。例えば、取引先の発行済株式数が判明しており、大株主とその持株数を取引先要項に登録する場合、発行済株式数と各株主の持株数から、各株主の持株比率を算出する。株数を入力するフィールドが導出元で、持株比率が表示するフィールドが導出先となる。これらの導出は、実際には、導出ボタンの押下か、登録ボタンの押下があったときに、端末１からデータを受信し、ＲＤＢ５６の検索や比率算出をサーバー側のＥＪＢで行う。

好ましい例では、表示編集制御部８が、入力不可制御機能６０によって入力されない項目及びユーザーから入力されない項目について、タグ付きデータを生成しない空タグ非生成制御機能６４を備える。入力不可制御機能６０によって、人格によらない単一のＤＴＤを使用することができる。そして、空タグ非生成制御機能６４は、入力されない項目についてはタグを生成しないため、結果的に、単一のＤＴＤから、個人事業主のＸＭＬデータは個人事業主に用いるタグのみを使用し、法人のＸＭＬデータは法人に用いるタグのみを使用することとなる。例えば、取引先が法人の場合には屋号は入力されないため、屋号の空タグは生成されず、このため、法人向けのみにＤＴＤを作成するのと同様のＸＭＬデータを得ることができる。これにより、他システムへのデータ送信の構築をより簡易にすることができる。

本実施形態では、表示編集制御部８は、取引先の基本属性、組織及び事業の内容の参照及び編集を要項Ｉデータとして管理する要項Ｉ管理機能６６と、主要な動向を時系列で記録する動向コメントの参照及び編集を要項ＩＩデータとして管理する要項ＩＩ管理機能６８とを備えている。より広く取引先の情報を集約するには、例えば、要項ＩＩＩとして保証人に関するデータを管理したり、要項ＩＶとして融資方針に関するデータを管理するようにしても良い。本実施形態では、要項Ｉ及びＩＩについてＤＴＤ及びＧＵＩの例を説明する。

図９は本実施形態で利用するＤＴＤの一例を示す説明図である。ＤＴＤの記載は、ＳＧＭＬによる。yoko2.dtdは取引先要項ＩＩのＤＴＤである。取引先要項ＩＩという要素（ELEMENT）は、ＣＩＦ番号と、取引先動向とを有する。取引先動向末尾の+は、この要素が１回以上出現することの指定である。末尾に何も付加されない場合には必ず１回出現する指定で、?は０回又は１回、*は０回以上である。末尾なしと+は必須項目であり、+と*は、ＸＭＬ上は繰り返し何度書いても良い。?と*は出現しないこともある。このため、要項ＩＩデータは、ＣＩＦ番号の取引先について、１つの取引先動向が入力されると生成される。取引先動向は、繰り返し何度記入しても良い。

取引先動向は、発生年月日、主要動向区分コード、主要動向区分名称、詳細コメント、記入年月日、記入者所属店番、記入者所属店名、記入者ユーザーＩＤ及び記入者氏名を有する。詳細コメントは、動向コメントであり、要項ＩＩデータは、主要動向区分と発生年月日が入力されると、コメントが存在しなくとも登録する。このＤＴＤによる要項ＩＩデータの一例を図１１に示す。

yoko1.dtdは、取引先要項Ｉの定義である。基本属性として、業種コード及び業種名が括弧でくくられているのは、業種コードが入力される場合には業種名も必要であるとの指定である。括弧の外に?が付されているため、業種コードと業種名のセットの出現回数の指定は０回又は１回である。顧客として、基準日、基本属性等を定義している。この顧客は、他システム４０のデータをＲＤＢ５６に格納し、取引先要項システムが取得するデータである。この顧客に属するデータは入力不可とする。この顧客のタグ定義は、ＸＭＬデータの履歴等の保存用の定義である。（生年月日｜設立年月日）とあるのは、生年月日又は設立年月日の一方という意味である。個人の場合には前者で、法人の場合は後者である。当行というのはこの取引先要項システムを使用する主体で、当社は取引先である。要項ＩのＸＭＬデータの例を図１２及び図１３に示す。

図示する例では、理解を容易とするためにタグを全角日本語で表記しているが、ソフトウエア及びプログラムとしてはアルファベットや数字が扱いやすいため、実際には英文表記又は日本語のローマ字表記を用いるとよい。

好ましい例では、格納制御部１０が、当該要項データの履歴の格納指令を受信した場合に、前記他システムからのＲＤＢデータにて前記基本属性データを更新すると共に、当該基本属性が更新された要項Ｉデータを当該要項Ｉの履歴データとして格納する制御をする履歴格納制御機能７８を備える。要項Ｉは、役員等や、事業内容や、製商品等最新の情報で更新されていく項目を扱う。このため、履歴格納制御機能７８は、年に１度等の頻度で、その１年間に要項Ｉデータが更新された取引先について、要項Ｉデータの履歴を格納する。要項Ｉの履歴を管理するため、図９の履歴では、履歴の作成日をＸＭＬデータ自体の要素として定義している。

また、自己査定の根拠資料として取引先要項を添付する場合には、査定の時点での取引先要項が必要であるため、履歴格納制御機能７８は、他システムからの要求に応じて、ＲＤＢデータで更新し、現在の要項Ｉデータ及び要項ＩＩデータを履歴として格納する機能を用いて、他システムにデータを送信するようにしても良い。ただし、要項ＩＩは、取引先動向をその発生年月日で管理するものであるため、それ自体が最新のデータで、且つ履歴である。このため、一定の頻度での履歴を特に作成する理由はほとんどない。

図１１を参照すると、ＣＩＦ番号、発生年月日は、切れ目のない固定長の数字列となっている。本実施形態では、ＸＭＬデータとしてはハイフン等を含ませず、表示のデータ型の一種として、ＧＵＩ定義にてハイフンの挿入等を行う。yoko2.dtdでは、取引先要項は唯一のＣＩＦ番号と、これと並列の１つ以上の取引先動向とを有する。タグによる文書型の指定は、<タグ名>で始まり、</タグ名>で終了する。階層に応じてこのタグが重ねて定義される。例えば、主要動向区分コードは、取引先動向に属し、取引先動向は、取引先要項ＩＩに属する。この階層は、ツリー構造のＤＯＭツリー等で管理することができる。主要動向区分コードと、主要動向区分名称の関係については、図３に示すとおりである。

図１２を参照すると、取引先要項ＩのＸＭＬデータは、ＣＩＦ番号の次が、更新となっている。この順序は図９の取引先要項Ｉという要素の子要素を定義する括弧内の順序である。更新の次は顧客であるが、ここでは省略している。役員等の役職従属関係コード及びその名称は、当社（取引先）と役員等との関係を予め一覧表にしたものであり、図２１に一例を示す。役員等での、代表権有無コードの１は有りで、無しの場合には０となる。代表権のみならず、全ての有無コードで１又は０とする同様の取扱としてもよい。

図１４から図２０は、取引先要項Ｉの画面例を示す説明図である。要項Ｉでは、組織と事業との２つの区画（ページ）を定義し、タブで遷移する。要項Ｉデータの内容として、組織の内容を表示する組織区画に、連絡先、屋号、従業員数、役員等、経理担当者、当行出身者、資本、大株主（大口出資者）、事業施設、関連融資先名寄せ、その他関連先、会計事務所、当行関連会社利用状況、及び有価証券保有状況の各テーブルを有する。そして、事業の内容を表示する事業区画に、平均月商、事業内容、製商品、特記事項、資金決済、販売先、仕入先、ホームページアドレスの各テーブルを有する。特記事項は、事業内容及び製商品の特色に関するコメントと、業界の地位に関するコメントである。
図１４等に示す例では、入力可能な項目及び全体の更新日は２００２年２月１０日で、ＲＤＢ５６から取得するデータの更新日は、２月の前月末であるため、２００２年１月３１日である。要項Ｉについては、組織のページと事業のページとをスクロールすると、その取引先の全体的な概況を把握することができる。このため、更新者が、変更又は追加した項目についての更新者ではなく、要項Ｉデータの全体について２月１０日に確認したこととして取り扱うことができる。

ＤＴＤによる階層と、画面表示の階層は異なっている。ＤＴＤの要素定義は、意味内容の体系ではなく、ＲＤＢからの取得するデータを顧客としてまとめ、また、入力される顧客に関するデータを顧客その他としてまとめている。ＤＯＭツリーはＤＴＤの階層で生成される。プレゼンテーション層では、すなわち、表示編集制御部８は、このＤＯＭツリー構造のデータを上記画面表示での体系に編集し、画面表示用のデータとして、配列等で取り扱うとよい。例えば、各テーブルの処理を行うＥＪＢが、ＤＯＭツリーから必要な項目を読み出す。本実施形態では、取引先の平均月商は、平均月商テーブルと、事業内容テーブルと、製商品テーブルと、販売先テーブルで用いられている。そして、画面表示し、編集された結果のデータについては、格納制御部１０が、配列等からＤＯＭツリーを構築し、妥当性の検証を行った上でＸＭＬデータＤＢ５４への格納を行う。

Ａ産業株式会社は法人であるため、屋号の名称は入力不可となっている。入力が不可であるフィールドは、グレーアウトするとよい。ここでは、フィールド（各項目を入力するボックス）の左上及び右下の斜線で、入力不可であることを示している。ＣＩＦ番号のフィールドの左上に、黒丸が付されている。この黒丸は、そのフィールドが導出元の項目であることを示す。役員等の社長のＣＩＦ番号を入力すると、氏名及び生年月日が導出される。導出先のフィールドは入力不可であるため、グレーアウトされている。この役員等のテーブルは、５レコード分表示しているが、６レコード以上のデータが登録される場合には、右のスライダーを操作することで６番目以降の内容を参照することができる。

好ましい例では、表示編集制御部８が、取引先を当社とした場合の当社の役員等の自然人と、当社の大株主（大口出資者）及び販売先等の法人若しくは事業性個人とを識別するＣＩＦ番号を任意入力項目として管理すると共に、当該ＣＩＦ番号が入力された場合には当該ＣＩＦ番号を導出元として当該テーブルの名称項目及び住所項目等を導出するＣＩＦ番号別入力支援機能７０を備えるとよい。

図１４に示す例では、役員等の常務で大阪四郎は、ＣＩＦ番号を有していないため、氏名が直接入力されている。通常のＲＤＢでは、ＣＩＦ番号のようなキーとなる値を入力せずに、そのテーブルの項目の入力を許可することはできない。しかし、本実施形態では、データの構造はＸＭＬであり、各項目を任意とすることができる一方、ＣＩＦ番号が入力された場合には導出を行うことができる。ＤＴＤによるタグ体系の定義と、導出というビジネスロジックを分離したことで、ＣＩＦ番号を任意入力項目としつつ、入力された場合には導出するという柔軟な取扱を行うことができる。

また、好ましい例では、表示編集制御部８が、従属関係管理機能７２を備えるとよい。従属関係管理機能７２は、取引先の役員の役職項目と、当該取引先と当該取引先への大口出資者との関係項目と、関連融資先及びその他関連先と取引先との関係項目とで使用する関係を示す従属関係コードを用いて、当該各項目の入力を管理する。従属関係コードを用いて、取引先と関係する個人又は法人等の関係を登録するため、横検索を精緻に行うことができる。図１４に示す役員等のテーブルでは、役職はコンボボックスによる選択が可能となっている。これは、図２１に示す従属関係コードの内、役職にフラグが立っている項目を役職従属関係コードとするものである。コンボボックスは、そのリストからの選択を促す。コンボボックスであることを、そのフィールドに下向き黒三角を配置することで示す。コンボボックスでは、リスト以外の内容を入力することはできないため、情報を均質にすることができる。また、コンボボックスであっても、ＤＴＤの定義に従って値を入力しないことはできる。

図２１に示す従属関係コードは、社長、会長、副会長と一定の順序で体系化されている。ＸＭＬの同一要素についての複数レコードは、本実施形態でのＤＴＤ上、シーケンス番号や、順序の概念はない。本実施形態では、役員等の役職をコード化し、かつ表示すべき順序で従属関係コードの番号を与えている。そして、役員等のレコードの並び（ＸＭＬデータの複数ある同一要素の並び）を従属関係コードの小さい順としている。すなわち、本実施形態では、表示編集制御部８が、役職欄の各レコードを従属関係コードの値に基づいて並べ替える従属関係コード別ソート機能７４を備える。これにより、入力及び登録した順ではなく、予め定められた順序で表示することができ、項目毎にシーケンス番号等を付与することなく、項目の視認性を向上することができる。そして、ある専務が社長となった場合には、役職欄を選択し直すのみで、従属関係コード別ソート機能７４による最適な順序での表示に更新されることとなる。このソートは、サーバー側のＥＪＢで行う場合にはサーバーの機能であり、端末側のアプレットで実行する場合には端末側の機能となる。この従属関係コード別ソート機能７４は、図１４等に示す例では、登録ボタンが押し下げられたときに各テーブルの項目を従属関係に従ってソートする。

図２１に示す例では、従属関係コードは、法人、個人及び役職のフラグが付されている。これにより、法人の場合の従属関係と、個人事業主の場合の従属関係と、役職従属関係の場合とで、個別のコード体系とすることができる。この例では、表示編集制御部８が、取引先の人格に応じて当該人格向けの従属関係コードを生成する従属関係コード生成機能７６を備えるとよい。

図１５に示す例では、大株主（大口出資者）の持株数を導出元とし、合計と各株主の持株数から、持株比率を導出している。この導出は、ＥＪＢで行う。図１６に示す例では、関連融資先の名寄せ管理を行う。このとき、当社との関係で、従属関係コードを用いる。Ａ産業株式会社は法人であるため、図２１に示す従属関係のうち、法人フラグが１になっている従属関係コードからこの関係を選択する。関連融資名寄せ（グループ名寄せ）は、信用リスク管理や、保証の内容や、実質同一である関係者等の把握等に役立つ。本実施形態では特に、従属関係コードを用いて相関関係を整理するため、グループ全体に対する信用リスク管理の精度の向上を図ることができる。また、当社とＡオプトデバイスの関係が子会社である場合、Ａオプトデバイスの関連融資先名寄せでは、子会社の反対概念をＡ産業に対して自動的に付することもできる。

図１７に示すその他関連先は、例えば、当行との取引はないが、当社と関連する企業等である。有価証券保有状況で、当行所有当社株式は、取引先要項システムを使用している主体が、取引先の株式を所有している場合であり、当社所有当行株式は、その逆である。

図１８及び図１９に示す事業区画では、事業内容や事業内容毎の平均月商と、平均月商合計とから、事業内容の構成比率を導出している。資金決済は、例えば、支払締切日であれば、請求を受けた当月の末日に締め、これを翌月の１５日に支払う場合、図示のとおりとなる。欄が２つであるのは、相手先によって支払日が異なる場合や、年２回の決算（６ヶ月決算）を行う先では、決算月が２つになるためである。図１０の資金決済で、支払締切月１・区分コードは、図１８の資金決済テーブルの左側の欄での当月を表すコードであり、支払締切月１・月区分名称は、例えば当月である。賞与支給月２・月コードは、図１８に示す例では12で、賞与支給月２・月は１２月である。

図１９及び図２０に示す販売先及び仕入先では、ＣＩＦ番号を任意入力項目としつつ、入力された場合には氏名、住所、融資先番号等の導出元としている。主取引店は融資先番号から導出する。表示編集制御部８は、当社からみた販売先毎の平均月商を入力すると、その構成比率を導出する。現金比率は、売上に対する入金のうち、何割が現金であるかの値である。仕入先についても同様に、ユーザーが知り得た範囲で、仕入先から当社に販売している平均月商の、現金比率を入力する。この仕入れの平均月商と、現金比率と、資金決済日との関係から、一月での資金需要を求めることもできる。資金決済日として入金日も登録する場合には、キャッシュフローを分析し、最適な資金調達の提案等も行うことができる。また、資産査定にて正常な運転資金を算出するのに、この実態を参照することもできるようになる。

図２２は、表示モード変遷の一例を示す説明図である。表示編集制御部８は、図２２に示すように、すべての項目を入力及び編集不可とする参照モード８０と、他システムから取得した項目及び導出先の項目を入力及び編集不可とすると共に他の項目の入力及び編集を許可する編集モードと８２、要項Ｉにて編集モード８２での編集結果で各テーブルの内容をソートして表示を行うと共に当該表示した内容での登録の確認を促す確認モード８４とを備えている。要項ＩＩでは、登録や削除前にそれぞれの確認を促す確認メッセージ８５を表示する。

ユーザーは、取引先要項システム又はこれを含む融資支援システム等にログインすると、ＣＩＦ番号を入力し、要項Ｉ又はＩＩの選択を行う。図２３は、各編集モードで表示する編集ボタンと、そのボタン押下のイベントを受信した場合の処理内容等の関係を示す説明図である。例えば、要項Ｉを選択して、開くボタンを押し下げる。すると、要項Ｉの参照モードへ遷移する。参照モードでは、選択画面へ遷移する戻るボタンと、要項ＩＩの参照モードへ遷移する要項ＩＩボタンと、編集モードへ遷移する編集ボタンとを取り扱う。編集ボタンは、編集権限のあるユーザーの場合にのみ表示し、要項ＩＩボタンについても、要項ＩＩの参照権限のあるユーザーの場合にのみ表示する。編集モードでは、入力可能なフィールドについてはグレーアウトを解除し、入力及び編集を可能とする。戻るボタンの押下があると、編集内容を破棄して、要項選択画面に推移する。編集モードで登録ボタンが押し下されると、ソート等を行って、編集不可の状態で画面に編集後の内容を表示する確認モードに遷移する。確認モードでは、登録の可否を問い合わせ、はいボタンが押し下げられると、確認のダイアログボックス等での確認の後、編集結果を含む要項Ｉデータの全体をＸＭＬデータＤＢへ更新する。元に戻すボタンの押下では、今までの編集結果を維持しながら編集モードへ戻る。要項選択画面と、要項Ｉと、要項ＩＩ間で遷移する場合、すでに入力されたＣＩＦ番号を引き継ぐようにしている。従って、要項Ｉを参照し、要項ＩＩボタンを押し下げると、同一の取引先の取引先要項ＩＩの参照となる。

図１４等に示す例では、各テーブルの左端に削除チェックボックスがある。編集モードにて削除対象のレコードを選択し、チェックボックスをオンとした状態で、登録ボタンを押し下げて確認モードに遷移すると、表示編集制御部８は、削除チェックボックスがオンとなっているレコードを削除して確認用に画面表示する。この状態で登録すると、チェックしたレコードが削除される。

図２４はユーザーのログインから端末への要項データの表示までの概要を示すフローチャートである。取引先要項システムは、取引先要項システムにログインした作業者をユーザーＩＤに基づいて識別する（ステップＳ１１）。ユーザーは、ＣＩＦ番号を入力し、且つ要項Ｉ又はＩＩを選択して開くボタンを押し下げる（ステップＳ１２）。ユーザーＩＤ等から取引先要項の参照権限を確認し（ステップＳ１３）、権限がある場合には、当該ＣＩＦ番号の取引先について、ＲＤＢ５６から取引先の基本属性等のデータを取得し（ステップＳ１４）、これに前後して、ＸＭＬデータＤＢからＸＭＬデータを取り込む（ステップＳ１５）。さらに、ユーザーの権限に応じたボタンの表示制御を行い（ステップＳ１６）、ＧＵＩ定義による画面定義ファイルと取り込んだデータとを合成して端末１に表示する（ステップＳ１７）。

ユーザーの権限に応じて編集の可否を制御する例では、要項Ｉ及び要項ＩＩに関して、表示編集制御部８は、ユーザーの所属店番と、取引先の取引店の店番との関係に基づいて、参照モードから編集モードへの遷移を要求するメッセージをサーバーに送信する編集ボタンの表示及び非表示を制御するボタン表示制御機能９０を備える。図２５は、ユーザーの所属店番と、取引先の取引店との関係に応じた権限設定の一例を示す説明図である。取引店は、主取引店か、または、複数取引のある場合の取引店である。他店は、ユーザーの所属店が主取引店でも複数取引の取引店でもない場合である。本部は、審査、監査、秘書室その他の本部組織である。図２５に示す例では、他店の場合には要項Ｉの参照のみ許可する。従って、要項Ｉ参照モードでは要項ＩＩボタンを表示しない。取引店担当者は、ＧＵＩ定義等によって入力不可とされていない項目について、編集及び削除が可能である。しかし、取引先動向は本来的に削除するものではないため、取引先動向の削除には一定の権限を要することとした。本部は、要項Ｉ及びＩＩの参照のみを可能としている。

図２５に示すアクセス制御を行う例では、表示編集制御部８が、自他店別アクセス制御機能９２を備えると良い。自他店別アクセス制御機能９２は、ユーザーの所属店番と、取引先の取引店（主取引店及び複数取引の場合の取引店）の店番とが同一の場合に、要項Ｉデータ及び要項ＩＩデータの参照及び編集を許可する。一方、自他店別アクセス制御機能９２は、ユーザーの所属店番と、取引先の取引店の店番とが異なる場合に、前記要項Ｉデータの参照を許可すると共に、要項Ｉデータの編集及び要項ＩＩデータの参照及び編集を不許可とする。

図２６はユーザーの権限を判定する処理例を示すフローチャートである。取引先要項システムは、ログインに成功した作業者を識別すると（ステップＳ２１）、続いて、取引先が融資先番号を有しているか否かを確認する（ステップＳ２３）。取引先要項システムは、取引店情報を特定できる融資先番号を保有する取引先について、その情報を蓄積するものであるため、融資先番号を保有していない取引先は要項作成の対象外となる。取引店情報は、取引先と取引を行う一又は複数の営業店（取引店）を特定する店番等を含む。また、見込み先等取引実績のない先についての情報を蓄積する場合には、見込み先に融資先番号を付与するか、またはこのステップＳ２３を見直す。続いて、ユーザーの所属店を確認する（ステップＳ２４）。本部のユーザーである場合には、参照のみ可となる。一方、営業店の場合には、まず、要項の選択がＩ又はＩＩのどちらであるかを確認する（ステップＳ２５）。要項Ｉの場合、ユーザーの所属店番と取引先の取引店の店番が一致する場合には、編集ボタンを表示して（ステップＳ２７）、参照及び編集を許可し、要項Ｉの参照モード画面に遷移する。この条件では、要項ＩＩの参照及び編集も同時に許可されるため、要項ＩＩボタンも表示する。一方、不一致の場合には、他店であるため、編集は不可としつつ、参照を許可する。この場合は、要項Ｉの参照が不許可のため、要項ＩＩボタンも表示しない。

要項ＩＩの場合、ステップＳ２８で他店であるか否かを確認し、他店である場合には参照をも不可とする。従って、取引先要項選択画面から要項ＩＩ画面への遷移は行わない。一方、ユーザーの所属が主取引店又は複数店取引がある場合の取引店であれば、編集ボタンを表示して（ステップＳ２９）、参照及び編集を許可し、要項ＩＩの参照モード画面に遷移する。この条件では、要項Ｉの参照及び編集も同時に許可されるため、要項Ｉボタンも表示する。

次に、ＸＭＬデータＤＢ等への多重書き込みによるデータの不整合発生を防止するためのロックについて説明する。この例では、サーバーが、同一の取引先についての複数のユーザーによる同時多重参照を許可すると共に、同一時刻で複数のユーザーが同一の取引先について編集モードとならないように編集モードの排他制御を行うロック制御部９４を備えている。図２２等に示すように、本実施形態では参照と編集とを明確に分離している。同時に多数のユーザーが参照したとしても、書き込みが行われないため、ロックする必要がない。一方、一人のユーザーが編集モードへ遷移した後に、他のユーザーへも編集を許可すると、二重の書き込みが生じ、一方の更新が破棄されてしまう。このため、本実施形態では、参照については多重アクセスを許可しつつ、編集モードについては確認モードを介した登録か、要項選択画面へ戻ることで編集を中断するまで、ＣＩＦ番号単位にロックすることとした。
編集モードを明確に定義し、参照時には追加、更新、変更等の全ての編集を不可としたため、排他制御は編集モードへ遷移する場合と、編集完了後、登録時とに行うことができる。本実施形態では、他システムから取引先要項システムのデータ格納部３へのアクセスを参照モードと同様に取り扱うことで、システム間の排他制御という複雑な処理や、データベースの二重化等の設計を回避することができる。

また、Ｊ２ＥＥ等を用いたＷｅｂアプリケーションでは、ＰＣ等の端末がクラッシュし、端末とのセッションが強制的に切れてしまい、ロックを確保した状態だけがサーバーに残ることも想定できる。

図８に示す例では、ロック制御部が、ロック取得制御機能９６と、ロック解放制御機能９７と、ロック可否判定機能９８とを備えている。この例では、当該取引先のＣＩＦ番号と、ロック取得（獲得）するユーザーのユーザーＩＤと、現在時間である開始時間と、開始時間に予め定められたロック最長時間を加算した終了時間とからなるロック管理情報をＲＤＢに格納し、このロック管理情報を参照してロックの可否を判定する。このとき、ロック管理情報によるロック中のユーザーが自分であるか否かを判定する処理と、ロック最長時間が経過した場合には端末からの操作がなくとも強制的にロックを解除する仕組みとしたことで、端末の強制終了による混乱を回避することができる。

ロック可否判定機能９８は、ロックの判定対象となる取引先のＣＩＦ番号で識別されるロック管理情報のロック終了時刻が、現在時刻よりも未来であり、且つ、当該ロック管理情報でのユーザーＩＤが異なる場合に、ロックが取得されていると判定する。

具体的には、ロック取得制御機能９６は、図２７に示すように、編集モードへ遷移する時に（ステップＳ４１）、当該ＣＩＦ番号の取引先の要項データ全体に他のユーザーによってロックが取得されているか否かをロック管理情報に基づいて判定する（ステップＳ４２）。ロックが取得されていない場合には、自分のロック管理情報がないことを確認した後に（ステップＳ４３）、ロック管理情報を書き込む（ステップＳ４４）。もし、自分のロック管理情報がある場合には、ロック情報の終了時刻を更新する（ステップＳ４５）。

ステップＳ４２にて、ロック中のユーザーがいる場合には、ロック管理情報のユーザーＩＤを比較して、自分自身であるか否かを確認する。端末が強制終了し、再起動後にロック終了時刻前に編集ボタンを押し下げた場合、自分自身がロック中となっている。自分自身のロックである場合には、ロック情報を更新し（ステップＳ５０）、当該ＸＭＬデータをロックして、編集モードを開始する。

ステップＳ４４又はＳ４５に続いて、ロック情報を再度確認し、ロック情報を同一タイミングで書き込んだ他ユーザーがいるか否かを判定する。自分がステップＳ４２の直後からステップＳ４４の完了までの間に、相手がステップＳ４２でのロック情報の読み込みを行った場合に、他ユーザーが存在する。また、逆の場合にも先行する他ユーザーが存在する。他ユーザーがいなければ、ロックを取得し、編集モードに遷移する。一方、他ユーザーがいる場合、ロック開始時刻の早いユーザー又はその他の手法で唯一のユーザーを選択する（ステップＳ４７）。他ユーザーが選択された場合には、ロック終了時刻を更新し、ロックを解除する（ステップＳ４８）。ステップＳ４８及びＳ４９にて、他のユーザーが既にロックを取得している場合には、編集を不可とし、多重アクセスが生じた旨のメッセージを端末に表示するようにしても良い。

ロック解放制御機能９７は、ステップＳ２８に示すように、編集モードにて編集された内容が登録される時に（ステップＳ６１，６２）、当該ＣＩＦ番号の取引先の要項データ全体に他のユーザーによってロックが取得されているか否かをロック管理情報に基づいて判定する（ステップＳ４２からＳ５０）。そして、ロックが取得されていない場合には（ステップＳ６３）、当該登録処理を許可すると共に、登録後に当該ＣＩＦ番号のロック管理情報の終了時刻を現在時刻に更新する（ステップＳ６４）。一方、ロックが他ユーザーによって取得されており、ロック不可の場合には、編集結果の登録を不可として、元に戻すボタン等による編集の中断を促す。このとき、多重アクセスが生じた旨のメッセージを端末に表示するようにしても良い。ステップＳ６２で中断と判定した場合には、ロック終了時刻を現在時刻に更新して、ロックを解放する。

図２９は取引先要項ＩＩのＧＵＩの一例を示す説明図である。要項ＩＩのＧＵＩは、動向コメントを時系列で表示すると共に表示のみで変更を不可とする取引先動向テーブル１００と、参照モードでは既存の動向コメントを表示すると共に、編集モードでは既存の動向コメントの編集及び新たな動向コメントの入力作業領域となる表示・入力・編集エリア１０２とを備えている。取引先動向は原則的に編集する文字データではないため、取引先動向テーブル１００では、編集を不可としている。新しい動向コメントの入力等は、表示・入力・編集エリアで行う。

図２３に示すように、要項ＩＩでの編集モードでは、表示・入力・編集エリア１０２の近傍に、クリア、追加、変更、及び削除の各ボタンを配置する。ユーザーは、発生年月日を入力し、主要動向区分を選択し、詳細（動向コメント）を記入して追加ボタンを押し下げると、当該エリア１０２に記入した内容が取引先動向テーブルに反映される。反映の可否に関する確認メッセージに対して、はいボタンを押し下げることで登録し、参照モードに戻った状態を図３０に示す。このエリア１０２は、取引先動向テーブル１００にて表示しきれない部分を表示するためにも用いられる。

取引先動向テーブル１００では、発生年月日をソートのキーとして取引先動向のレコードをソートしている。このため、例えば、数年前での主要な動向が判明し、その動向コメントを入力すると、発生年月日を数年前とすることで、記入・登録順序とは無関係に、発生年月日順に並べ替えられる。ＸＭＬデータは、この並べ替えられた状態で生成及び格納される。

営業店内といえども、担当者及びその上司限りとすべき情報を得ることがある。例えば、Ｍ＆Ａ等を近日のある日付で実行する等の情報は、取扱に注意を要する。一方、その発表日になった瞬間に、種々の対応を迫られることとなる。このような場合に、発生年月日を将来の日付として登録しておき、その日付を解禁日とし、その日付を迎えた段階で表示するようにすると、当日には要点がすでに取引先要項システムに登録されており、その情報を組織内で即座に活用できる。取引先要項システムでの要項ＩＩは、過去に生じた取引先の動向のうち、重要なものを登録するものであるが、この過去の結果を登録するという仕組みの例外として、解禁等の仕組み導入するには、表示編集制御部８が、表示・入力・編集エリア１０２にて将来の日付が入力されて当該将来日付の動向コメントデータを登録した場合には、当該ユーザー等によって許可されないユーザー群に対する表示については、当該将来日付が到来するまで当該将来日付の動向コメントを表示しない制御をする解禁指定登録制御機能９９を備える。

図３１は、分析制御部を備えた取引先要項システムの一例を示すブロック図である。この例では、サーバーが、取引先の要項についてマークアップランゲージ（ＭＬ）でのタグ体系を定義したタグ体系定義ファイル５０と、ＭＬのタグ付けされた取引先毎のタグ付きデータを格納するＸＭＬデータＤＢ５４とを格納するデータ格納部３と、タグ体系定義ファイル５０によって定義される取引先の組織及び事業並びに各取引先の販売先及び／又は仕入先に関する販売先等関連項目についての要項データの端末１での表示及び入力をＧＵＩ定義ファイル５２に従って制御する表示編集制御部８とを備えている。販売先等関連項目は、販売先及び仕入先の両方が登録されている取引先については、その両方のテーブルの各項目で、販売先又は仕入先の一方のみが登録されている取引先については、その一方のテーブルの各項目である。すなわち、販売先及び／又は仕入先というときには、両方か、又はどちらか一方である。サーバーはまた、要項データをタグ体系の定義に基づいてタグ付きデータに変換すると共に、当該タグ付きデータを一体的な要項データとしてＸＭＬデータＤＢ５４に格納する格納制御部１０を備えている。

図３１に示す例では、特に、サーバーが、格納制御部１０によって格納された要項データから前記取引先間の関係に関する情報を前記販売先等関連項目の項目を検索キーとして抽出する分析制御部１１０を備えている。分析制御部は、図１又は図８に示す取引先要項システム等を用いて蓄積した要項データを用いて、横検索による分析資料の生成を行う。要項データは、タグの階層定義によって意味が定義された文字データやコードの集合であるため、信用リスク管理や、営業推進や、新しいサービスの開発等の基礎資料となる。従来、帳票で取引先要項を記載していた例では、帳票用紙の保存箇所等の問題で、営業店を横断して一定の取引先を抽出し、取引先の関係を分析する等の作業には大きな手間を要していた。図８等に示す例では、要項Ｉデータについては自店であっても他店であってもアクセス可能であるため、営業店を横断する分析を容易に行うことができる。

図３１に示す例では、図９や図１４等に示す前記タグ体系及びＧＵＩ定義のうち、販売先等関連項目が特に有用である。すなわち、タグ体系として、要項対象自身のＣＩＦ番号と、当該販売先及び／又は仕入先（販売先等）について前記ＣＩＦ番号が付されている場合には当該販売先等のＣＩＦ番号と、当該販売先等について前記ＣＩＦ番号が付されていない場合には当該販売先等の氏名又は名称並びに住所等と、販売先等への販売又は仕入に関する販売先等毎の売上額又は仕入額とを備えるとよい。ここで、ＣＩＦ番号は、その取引先と、その氏名又は名称及び住所等とを唯一に識別するユニークな番号である。

図３１に示す例では、分析制御部１１０は、ＣＩＦ番号又は氏名又は名称並びに住所等を検索キーとして検索対象範囲の取引先の依存関係を検索する汎用検索機能１１４を備える。この汎用検索機能１１４は、他システム４０の汎用検索システム４８を用いてもよい。この場合、要項データを汎用検索システム４８に送信し、検索を汎用検索システム４８で行う。取引先要項データに基づいた汎用検索が可能となると、当行の取引先又は当行との取引のない先の信用リスクが突然に高まった場合に、この信用リスクが突然に高まった先と取引のある取引先を抽出することができる。例えば、信用リスクの高まった先を販売先にしている取引先や関連先にしている取引先の一覧等の抽出が可能となる。従来、為替等の資金決済ルートに入っていれば、信用リスクが高まった先と取引のある先をある程度把握できたが、資金決済データではそのような取引のある先を確実に特定するのが難しく、正確で幅広い抽出を行うことは困難であった。図３１に示す例では、ＣＩＦ番号がある場合にはＣＩＦ番号に基づいて、ＣＩＦ番号が入力されていない場合には氏名又は名称並びに住所等の文字データに基づいて汎用検索を行うことができるため、より精度の高い、且つ幅広い抽出が可能となる。販売の平均月商の構成比率も副次的な検索のキーとしてもよい。

営業推進との関係での汎用検索の例としては、例えば、当行と取引のない優良企業等は取引先要項がなく、取引関係を把握しづらかったが、要項Ｉの販売先に上記企業を持つ先を検索することで、手形割引推進等に利用できる。また、ある取引先が製商品に「ＰＣ用ディスプレイ」を持つ場合に、仕入先の製商品名に「ＰＣ用ディスプレイ」のデータを持つ先を検索し、営業斡旋に利用することもできる。

図３２は、取引先の販売・仕入関係の相関図の一例を示す説明図である。この例では、図１４等に示すＡ産業を第１階層として、仕入販売関係を３階層分抽出している。この図３２に示すような相関図を生成するには、分析制御部が、相関図生成機能１１６を備える。この機能１１６は、取引先のＣＩＦ番号等と販売先等関連項目の内容とに基づいて、検索対象範囲の取引先間の販売・仕入関係を抽出すると共に、抽出された販売先等のうち同一の販売先等を集約し、販売・仕入関係を図示する定義ファイルを生成する。

図３３は相関図生成機能１１６による相関図生成処理の一例を示すフローチャートである。ここでは、図１４等に示すＡ産業を第１階層として、仕入販売関係を３階層分抽出する。相関図生成機能１１６は、図３２との対応では、まず、対象取引先の名称、業種、関連融資先名寄せのグループ名、主取引店、平均月商及び支払関連情報等を読み出す（ステップＳ８１）。図３２に示す例では、相関図生成機能１１６は、Ａ産業の名称を中心として、左上にグループ名、右上に主取引店、左下に業種名、その下に平均月商を配置した取引先ボックスを生成する。また、支払に関しては締日や支払日の項目を有しているため、要項Ｉデータに入力されていた場合には、取引先ボックスの左上に支払関連情報を付加する。

相関図生成機能１１６は、続いて、Ａ産業の直接の販売先を第２階層として抽出する（ステップＳ８２）。図３２に示す例では、Ｂ工業のみ図１４等と対応させている。Ｂ工業はこの処理で初めて抽出されたため（ステップＳ８３）、販売仕入関係、平均月商の構成比率及び製商品名を描画用に定義する。例えば、矢印の元を供給者、矢印の先を購買者とし、矢印の元に製商品名及び平均月商の構成比率を配置する。図３２に示す例では、Ａ産業のＢ工業向け販売はプリント基板で、平均月商の５０％（4,000百万円）となる。図３２中、取引先ボックス右側での矢印は、仕入先テーブルや販売先テーブルの構成比率項目でのその他の値である。

続いて、ステップＳ８６、Ｓ８７のループにより、販売先及び仕入先の抽出を繰り返す。Ａ産業の販売先の第２階層（Ｂ工業、販売２及び販売３）と、仕入先の第２階層（仕入１及び仕入２）の抽出が完了すると、全階層完了したか否かを確認する（ステップＳ８８）。ここでは第３階層まで抽出するため、ステップＳ８９にてすでに抽出した第２階層の販売先及び仕入先のうち、最初の取引先を対象取引先とする。例えば、仕入１を対象取引先として、仕入１の業種コード等を読み出し（ステップＳ８１）、さらに販売先を抽出する（ステップＳ８２）。Ａ産業以外については平均月商等の図３２への記載を省略している。仕入１（ｓ１、サプライヤーの１番目）の要項Ｉデータの販売先としてＡ産業が格納されていたとすると、Ａ産業は既に抽出されているため、ステップＳ８４で集約する。仕入２（ｓ２）を抽出すると、仕入２の販売先としてＡ産業は格納されていなかったとする。この場合、仕入２からＡ産業への矢印は、仕入２側で点線等とするとよい。仕入２は、販売先として、仕入２の販売先１（ｓ２ッｂ１，サプライヤー２のバイヤー１）を有する。

第２階層の仕入先の抽出が完了すると、続いて、第２階層の販売先を抽出する。Ｂ工業（ｂ１，バイヤーの１番目）の要項Ｉデータでの仕入先として、Ａ産業が格納されていると、ステップＳ８４で集約される。Ｂ工業の仕入先としては、Ａ産業の他、「ｂ１ッｓ２（バイヤー１のサプライヤー２）」等が抽出される。図３２に示す例では、Ｂ工業の仕入先は、仕入２の販売先と同一であるため、集約している。続いて、第３階層の情報を抽出する。仕入１の仕入先（Ｓ１＿１）は、ＣＩＦ番号を有さず、情報がなかった。Ｂ工業の販売先の一つは、一般企業である。また、仕入１（ｓ１）の販売先の一つは、Ａグループであった。全階層について抽出及び集約処理が完了すると、相関関係定義ファイルの書き出し、他のアプリケーションソフトウエアでの編集を促すか、または、直接描画や印刷等を行う（ステップＳ９０）。

図３３に示す処理等にて図３２に例示する相関図を生成すると、取引先間の平均月商の構成比率の関係等から、取引先の業界での地位や、販売先にとっての対象取引先の地位等を確認することができる。図３２に示すように、ある取引先を中心に、流通経路に従って相関図を生成すると、その製商品のサプライチェーンが明示され、コスト削減に関する提案等を行うこともできる。さらに、平均月商と、構成比率と、支払の締日や支払日の情報とに基づいて、売掛金等に関して、資金需要日程を把握することができる。この場合、現金比率等を併用するようにしてもよい。また、販売についての入金や、支払先（仕入先）毎の支払日等を取り扱うようにしてもよい。このように、資金の流れに着目した場合、相関図での矢印の向きは資金の流れと同様とし、図３２に示す例とは逆向きで、例えばＡ産業から仕入１等へ向かう方向とするとよい。

相関図により、どの取引先がどの程度の運転資金をどのような日程で必要とするのかが一目瞭然となり、考慮した取引先にとって適切な営業推進の内容を行いやすくなる。また、同一取引先について、ＣＩＦ番号や、氏名又は名称等を用いて集約するため、取引の実状を視覚的に把握することができる。また、図３３に示す相関図を把握しておくと、ある取引先の信用リスクが急激に高まった場合の影響等を即座に把握することができる。

相関図の検索範囲としては、図３２に示すように着目する取引先から数段階の仕入・販売階層としたり、ある業種でのグループ関係を抽出したり、ある原材料から最終製品までの関係を抽出するなど、種々の目的に応じた様々な相関図を取引先要項システムで整理・蓄積したデータから生成することができる。例えば、値動きが大きい原材料がある場合に、その原材料を製商品とする取引先の一連の流通及び相関関係を把握することで、原材料費の急騰という周辺状況の変化についての影響等を予め調査し、信用リスク管理の精度を飛躍的に向上させることができる。

再度図３１を参照すると、データ格納部３は、他システムにて一定期間毎に更新されるＣＩＦ番号と氏名又は名称並びに住所等の基本属性データを格納するＲＤＢ５６を備えている。そして、表示編集制御部８が、端末１に表示する法人、個人又は個人事業主を登録するテーブルのレコードに当該ＣＩＦ番号が入力された場合には基本属性データを参照して当該ＣＩＦ番号の前記基本属性を対応するレコードへ導出するＣＩＦ番号別導出機能７０Ａを備えている。これにより、取引先要項データではＣＩＦ番号を中心に取引先の名称や住所の更新を同時期にすることができ、従って、相関図作成での集約処理が容易となる。

要項データは、要項Ｉ及び要項ＩＩデータの他、今後の融資に関する当行の方針を示す融資方針等を含め、汎用検索機能１１４により、一定以上の融資方針となっている先を抽出できるようにしても良い。分析制御部１１０による抽出や検索を精緻で有用なものとするためには、表示編集制御部８が、主要動向区分コードを用いて主要な動向を記述した動向コメントを明示的に区分する主要動向区分管理機能１６Ａを備えるとよい。これにより、動向コメントの主要動向区分に該当する取引先の抽出が容易となる。例えば海外事業関連の主要動向区分での記入がある特定の業種の取引先を抽出し、また、ある営業店に着任直後に、その営業店を取引店とする取引先で、役員等異動の動向コメントが記入されている取引先の一覧を抽出する等の処理が可能となる。

表示編集制御部８が、組織の役員、関連会社、大株主（大口出資者）、当該取引先の販売先並びに仕入先等のテーブルにて従属関係コードを用いて当該取引先との関係の区分を促す従属関係管理機能７２を備える例では、相関図や影響度をさらに詳細に且つコードによる精緻な検索を実行することができる。

図１は第１実施形態での構成例を示すブロック図である。図２は文字データの取扱に関する各システムの関係を示す説明図である。図３は、主要動向区分の一例を示す説明図である。図４は、動向コメントについてのＧＵＩの一例を示す説明図である。図５は、動向コメントの種別表示の一例を示す説明図である図６は、動向コメントの種別表示制御の一例を示すフローチャートである。図７は、営業推進種別の動向コメントを他の種別の主要動向区分と関連させた例を示す説明図である。図８は、第２実施形態の構成例を示すブロック図である。図９は本実施形態で利用するＤＴＤの一例を示す説明図である。図１０は、図９に続くＤＴＤの一例を示す説明図である。図１１は、図９に示す例での要項ＩＩのｘｍｌデータの一例を示す説明図である。図１２は、図９及び図１０に示す例での要項Ｉのｘｍｌデータの一例を示す説明図である。図１３は、図１２に続くｘｍｌデータの一例を示す説明図である。図１４は、ＧＵＩ定義によるユーザービューの構成と図１１及び図１２に示すｘｍｌデータに対応した要項Ｉデータの内、組織区画の連絡先、従業員、役員等、及び経理担当者の各テーブルの表示例を示す説明図である。図１５は、要項Ｉデータの内、組織区画の当行出身者、資本及び大株主（大口出資者）の各テーブルの表示例を示す説明図である。図１６は、要項Ｉデータの内、組織区画の事業施設及び関連融資先名寄せの各テーブルの表示例を示す説明図である。図１７は、要項Ｉデータの内、組織区画のその他関連先、会計事務所、当行関連会社利用状況及び有価証券保有状況の各テーブルの表示例を示す説明図である。図１８は、要項Ｉデータの内、事業区画の平均月商、事業内容、特記事項、業界の地位、製商品及び資金決済の各テーブルの表示例を示す説明図である。図１９は、要項Ｉデータの内、事業区画の製商品、販売先及び仕入先の各テーブルの表示例を示す説明図である。図２０は、要項Ｉデータの内、事業区画の仕入先及びホームページの各テーブルの表示例を示す説明図である。図２１は、従属関係コードのコード体系の一例を示す説明図である。図２２は、表示モード変遷の一例を示す説明図である。図２３は、ボタンと処理内容等の関係を示す説明図である。図２４は、ユーザーのログインから端末への要項データの表示までの概要を示すフローチャートである。図２５は、ユーザーの権限とアクセス可能な表示モード等との関係を示す説明図である。図２６は、ユーザーの権限を判定する処理例を示すフローチャートである。図２７は、ロック可否判定処理及びロック取得処理の一例を示すフローチャートである。図２８は、ロック解放処理の一例を示すフローチャートである。図２９は要項ＩＩでの編集モードの一例を示す説明図である。図３０は要項ＩＩでの登録後の一例を示す説明図である。図３１は分析制御部を備えた構成例を示すブロック図である。分析制御部によって生成される相関図の一例を示す説明図である。相関図生成機能の処理内容の一例を示すフローチャートである。

符号の説明

１端末
２ネットワーク
３データ格納部
４取引先要項システム
６取得制御部
８表示編集制御部
１０格納制御部
１６主要動向区分管理部

Claims

ＲＤＢと連携するマークアップランゲージ（ＭＬ）のタグの体系を定義したタグ体系定義ファイルと、端末での表示及び入力について予め定められたＧＵＩ定義ファイルと、前記ＭＬのタグ付けされた取引先毎のタグ付きデータを格納するＭＬデータＤＢと、他システムにて一定期間毎に更新されるデータを格納したＲＤＢとを格納するデータ格納部と、
前記取引先の組織及び事業並びに主要な動向等についてのデータの端末での表示及び入力を前記ＧＵＩ定義に従って制御する表示編集制御部と、前記他システムから取り込んだデータ及び前記端末から入力されたデータを前記ＲＤＢでのデータ項目名若しくは前記ＧＵＩ定義に関連した前記タグ体系定義に基づいてタグ付きデータに変換すると共に、当該タグ付きデータを一体的な要項データとして前記ＭＬデータＤＢに格納する格納制御部とを備え、
前記表示編集制御部が、前記ＧＵＩ定義と前記取引先の態様とに応じて当該取引先の態様毎に入力不可とする項目を制御する入力不可制御機能と、
前記他システムにて更新されるデータを前記タグ体系定義に基づいて取得すると共に、導出元項目への入力から前記ＧＵＩ定義に基づいて導出先項目の内容を導出する制御をする導出制御機能とを備えたことを特徴とする取引先要項システム。
前記表示編集制御部が、前記入力不可制御機能によって入力されない項目及びユーザーから入力されない項目について前記タグ付きデータを生成しない空タグ非生成制御機能を備えたことを特徴とする請求項１記載の取引先要項システム。
前記表示編集制御部が、要項Ｉデータの内容として、
前記組織の内容を表示する組織区画に、連絡先、従業員数、役員等、経理担当者、当行出身者、資本、大株主（大口出資者）、事業施設、関連融資先名寄せ、その他関連先、会計事務所、当行関連会社利用状況、及び有価証券保有状況の各テーブルを有し、
前記事業の内容を表示する事業区画に、平均月商、事業内容、製商品、資金決済、販売先、仕入先の各テーブルを有し、
要項ＩＩデータの前記動向コメントの項目として、
発生年月日、主要動向区分、動向コメント、記入年月日、及び記入者を有することを特徴とする請求項２記載の取引先要項システム。
前記表示編集制御部が、前記取引先を当社とした場合の当社の役員等の自然人と、当社の大株主（大口出資者）及び販売先等の法人若しくは事業性個人とを識別するＣＩＦ番号を任意入力項目として管理すると共に、当該ＣＩＦ番号が入力された場合には当該ＣＩＦ番号を導出元として当該テーブルの名称項目及び住所項目等を導出するＣＩＦ番号別入力支援機能を備えたことを特徴とする請求項１，２又は３記載の取引先要項システム。
前記表示編集制御部が、前記取引先の役員の役職項目と、当該取引先と当該取引先への大口出資者との関係項目と、関連融資先及びその他関連先と取引先との関係項目とで使用する関係を示す従属関係コードを用いて当該各項目の入力を管理する従属関係管理機能を備えたことを特徴とする請求項１記載の取引先要項システム。
前記表示編集制御部が、前記役職欄の各レコードを従属関係コードの値に基づいて並べ替える従属関係コード別ソート機能を備えたことを特徴とする請求項５記載の取引先要項システム。
前記表示編集制御部が、前記取引先の人格に応じて当該人格向けの従属関係コードを生成する従属関係コード生成機能を備えたことを特徴とする請求項５又は６記載の取引先要項システム。
前記表示編集制御部が、取引先の基本属性、組織及び事業の内容の参照及び編集を要項Ｉデータとして管理する要項Ｉ管理機能と、前記主要な動向を時系列で記録する動向コメントの参照及び編集を要項ＩＩデータとして管理する要項ＩＩ管理機能とを備え、
前記格納制御部が、当該要項データの履歴の格納指令を受信した場合に、前記他システムからのＲＤＢデータにて前記基本属性データを更新すると共に、当該基本属性が更新された要項Ｉデータを当該要項Ｉの履歴データとして格納する制御をする履歴格納制御機能を備えたことを特徴とする取引先要項システム。
取引先の要項についてマークアップランゲージ（ＭＬ）でのタグ体系を定義したタグ体系定義ファイルと、前記ＭＬのタグ付けされた取引先毎のタグ付きデータを格納するＭＬデータＤＢとを格納するデータ格納部と、
前記タグ体系定義ファイルによって定義される取引先の組織及び事業並びに各取引先の販売先及び／又は仕入先に関する販売先等関連項目についての要項データの端末での表示及び入力を前記ＧＵＩ定義に従って制御する表示編集制御部と、
前記要項データを前記タグ体系の定義に基づいてタグ付きデータに変換すると共に、当該タグ付きデータを一体的な要項データとして前記ＭＬデータＤＢに格納する格納制御部と、
この格納制御部によって格納された要項データから前記取引先間の関係に関する情報を前記販売先等関連項目の項目を検索キーとして抽出する分析制御部とを備えたことを特徴とする取引先要項システム。
前記タグ体系及びＧＵＩ定義が、前記販売先等関連項目として、
前記取引先及びその氏名又は名称及び住所等を唯一に識別するＣＩＦ番号と、
当該販売先及び／又は仕入先（販売先等）について前記ＣＩＦ番号が付されている場合には当該販売先等のＣＩＦ番号と、
当該販売先等について前記ＣＩＦ番号が付されていない場合には当該販売先等の氏名又は名称並びに住所等と、
前記販売先等への販売又は仕入に関する販売先等毎の売上額又は仕入額とを有し、
前記分析制御部が、前記ＣＩＦ番号又は氏名又は名称並びに住所等を検索キーとして検索対象範囲の取引先の依存関係を検索する汎用検索機能を備えたことを特徴とする請求項９記載の取引先要項システム。
前記分析制御部が、前記取引先のＣＩＦ番号等と前記販売先等関連項目の内容とに基づいて、検索対象範囲の取引先間の販売・仕入関係を抽出すると共に、抽出された販売先等のうち同一の販売先等を集約し、販売・仕入関係を図示する定義ファイルを生成する相関図生成機能を備えたことを特徴とする請求項１０記載の取引先要項システム。
前記データ格納部が、他システムにて一定期間毎に更新されるＣＩＦ番号と氏名又は名称並びに住所等の基本属性データを格納し、
前記表示編集制御部が、前記端末に表示する法人、個人又は個人事業主を登録するテーブルのレコードに当該ＣＩＦ番号が入力された場合には前記基本属性データを参照して当該ＣＩＦ番号の前記基本属性を対応するレコードへ導出するＣＩＦ番号別導出機能とを備えたことを特徴とする請求項９，１０又は１１記載の取引先要項システム。