JP2003296554A

JP2003296554A - 取引先要項システム

Info

Publication number: JP2003296554A
Application number: JP2002100454A
Authority: JP
Inventors: 悦郎 ▲柳▼澤; Etsuro Yanagisawa; Masasue Oi; 正季大井; Shohei Hishiro; 章平樋代
Original assignee: HACHIJUNI BANK Ltd
Current assignee: HACHIJUNI BANK Ltd
Priority date: 2002-04-02
Filing date: 2002-04-02
Publication date: 2003-10-17
Anticipated expiration: 2022-04-02
Also published as: JP4373642B2

Abstract

(57)【要約】【課題】取引先に関する文字データの柔軟な取扱と他
のシステムとの良好な連携を維持すること。【解決手段】サーバーは、取引先の組織及び事業と、
当該取引先についての時系列での主要な動向等について
の文字データを他システム４０から取得する取得制御部
６と、予め定められたＧＵＩ定義に基づいて取得した文
字データを端末１に表示させると共に、取引先の組織の
内容を示す組織データと、事業の内容を示す事業データ
と、当該取引先の主要動向を示す動向コメントデータ等
の入力及び編集を制御する表示編集制御部８とを備えて
いる。サーバーはさらに、取得制御部６によって他シス
テムから自動的に取得した文字データと、表示編集制御
部８による制御に応じて入力及び編集された文字データ
とを一体の体系での要項データとしてデータ格納部３等
に格納する格納制御部１０を備えている。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、取引先要項システ
ムに関し、特に、取引先に関する文字情報を取り扱う取
引先要項システムに関する。

【０００２】

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

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

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

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

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

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

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

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

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

【００１１】

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

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

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

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

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

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

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

【００１８】

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

【００１９】

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

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

【００２１】第１実施形態では、取引先の主要な動向を
文章で表現した動向コメントについて、明示的に内容を
区分する主要動向区分コードを用いる（例えば、図
３）。この主要動向区分コードを他システムと取得制御
部のプロトコル又はインタフェースとすることで、動向
コメントの集約及び構造化を明確にし、且つ横検索の精
度を向上させることができる。また、主要動向区分のグ
ループ（種別）を用いて、例えばリスク管理区分の主要
動向区分コードが付された動向コメントのみを抽出して
表示する機能を備えることで、ユーザーが取引先の履歴
及び注意すべき点等を即座に視覚的に把握することがで
きる。また、主要動向区分を厳選し、主要動向区分に区
分されない動向についての入力を不可とすることで、担
当者によらず、記載する動向の粒度が一定となり、ま
た、常に主要動向区分を用いることで、取引先の様々な
動向のうち、登録すべき重要な動向の選別が明確とな
る。

【００２２】第２実施形態では、要項データをＸＭＬデ
ータとし、表示編集に関する種々の機能を備えること
で、手書きと同様な自由度でデータの入力及び参照を可
能としている。また、他システムから取引先に関する基
本的な文字データを取り込み、体系的な構造を維持する
必須の項目を自動的に取得しつつ、ＸＭＬによる階層的
なデータ構造によって各項目の位置付けの簡明で明確な
理解をユーザーに促しつつ、文字データの入力を支援す
ることで、文字データの柔軟な取扱と横検索の精度の維
持との両立を図る。さらに、役職や取引先と関係を持つ
法人又は個人との関係を示すコードを整理することで
も、入力を容易にしつつ横検索の精度を向上させる。

【００２３】

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【０１３７】

【発明の効果】本発明は、その構成によって、表示編集
制御部が、種々の他システムから自動的に収集された文
字データを一定のユーザーインタフェースを用いてユー
ザーに表示し、さらに、取引先の組織、事業及び動向コ
メントについてのデータの入力及び編集を制御する。さ
らに、格納制御部が、取得制御部によって他システムか
ら取得した文字データと、表示編集制御部による制御に
応じて入力及び編集された文字データとを一体の体系で
の要項データとしてデータ格納部等に格納する。従っ
て、本発明は、種々の他システムを用いた業務の結果の
要点を示す重要な文字データを集約し、取引先要項とし
て不足する部分については入力を促し、そして、取得し
た文字データ及び入力された文字データは、予め定めら
れた一体的な体系で構造化して格納する。このため、本
発明による取引先要項システムは、取引先に関する文字
データの最上位のＤＢに位置付けることができ、文字デ
ータを他システムから集約し、一体的な体系で構造化し
たデータを随時端末に表示又は他システムへ送信するこ
とができる。これにより、他システムとの重複記載を排
除し、従って、同一データの重複保持及び重複したデー
タ間の不整合がなくなり、さらに、他システムで決裁さ
れた文字データを自動的に登録する例では、最終的な精
度の高い且つ鮮度の良い文字情報の集約、参照及び他シ
ステムへの配布を行うことができる。

【０１３８】取引先の主要な動向を文章で表現した動向
コメントについて、明示的に内容を区分する主要動向区
分コードを用いる例では、この主要動向区分コードを他
システムと取得制御部のプロトコル又はインタフェース
とすることで、動向コメントの集約及び構造化を明確に
し、且つ横検索の精度を向上させることができる。ま
た、主要動向区分のグループ（種別）を用いて、例えば
リスク管理区分の主要動向区分コードが付された動向コ
メントのみを抽出して表示する機能を備えることで、ユ
ーザーが取引先の履歴及び注意すべき点等を即座に視覚
的に把握することができる。さらに、主要動向区分を厳
選し、主要動向区分に区分されない動向についての入力
を不可とすることで、担当者の熟練度によらず、記載す
る動向の粒度を強制的に一定とすることができ、また、
常に主要動向区分を用いることで、取引先の様々な動向
のうち、登録すべき重要な動向の選別が明確となる。従
って、取引店等の担当者は、主要動向区分の体系を理解
し、記憶することで、取引先へ整理された質問等を行う
ことができ、また、重要な動向についての記載もれや、
必ずしも重要ではない動向を詳細に記載する等の担当者
によるバラツキを防止することができる。従って、取引
先要項として蓄積される情報が均質になり、このため、
報告や引継等が明確で、さらに、各種の検索に際して有
用な粒度の揃ったデータを得ることができる。

【０１３９】さらに、要項データをＸＭＬデータとし、
表示編集に関する種々の機能を備える例では、ＸＭＬに
よる階層的なデータ構造によって各項目の位置付けと意
味の簡明で明確な理解をユーザーに促しつつ、文字デー
タの入力を支援することで、文字データの柔軟な取扱と
横検索の精度の維持との両立を図ることができる。さら
に、役職や取引先と関係を持つ法人又は個人との関係を
示すコードを整理することでも、入力を容易にしつつ横
検索の精度を向上させることができる。また、コード化
しづらい項目についても、本システムを長年使用するこ
とで、階層的なデータ構造でのデータ項目への記載が膨
大なテキストデータとして蓄積されるため、新たなコー
ド体系等の導入も容易となる。

【図面の簡単な説明】

【図１】図１は第１実施形態での構成例を示すブロック
図である。

【図２】図２は文字データの取扱に関する各システムの
関係を示す説明図である。

【図３】図３は、主要動向区分の一例を示す説明図であ
る。

【図４】図４は、動向コメントについてのＧＵＩの一例
を示す説明図である。

【図５】図５は、動向コメントの種別表示の一例を示す
説明図である

【図６】図６は、動向コメントの種別表示制御の一例を
示すフローチャートである。

【図７】図７は、営業推進種別の動向コメントを他の種
別の主要動向区分と関連させた例を示す説明図である。

【図８】図８は、第２実施形態の構成例を示すブロック
図である。

【図９】図９は本実施形態で利用するＤＴＤの一例を示
す説明図である。

【図１０】図１０は、図９に続くＤＴＤの一例を示す説
明図である。

【図１１】図１１は、図９に示す例での要項ＩＩのｘｍ
ｌデータの一例を示す説明図である。

【図１２】図１２は、図９及び図１０に示す例での要項
Ｉのｘｍｌデータの一例を示す説明図である。

【図１３】図１３は、図１２に続くｘｍｌデータの一例
を示す説明図である。

【図１４】図１４は、ＧＵＩ定義によるユーザービュー
の構成と図１１及び図１２に示すｘｍｌデータに対応し
た要項Ｉデータの内、組織区画の連絡先、従業員、役員
等、及び経理担当者の各テーブルの表示例を示す説明図
である。

【図１５】図１５は、要項Ｉデータの内、組織区画の当
行出身者、資本及び大株主（大口出資者）の各テーブル
の表示例を示す説明図である。

【図１６】図１６は、要項Ｉデータの内、組織区画の事
業施設及び関連融資先名寄せの各テーブルの表示例を示
す説明図である。

【図１７】図１７は、要項Ｉデータの内、組織区画のそ
の他関連先、会計事務所、当行関連会社利用状況及び有
価証券保有状況の各テーブルの表示例を示す説明図であ
る。

【図１８】図１８は、要項Ｉデータの内、事業区画の平
均月商、事業内容、特記事項、業界の地位、製商品及び
資金決済の各テーブルの表示例を示す説明図である。

【図１９】図１９は、要項Ｉデータの内、事業区画の製
商品、販売先及び仕入先の各テーブルの表示例を示す説
明図である。

【図２０】図２０は、要項Ｉデータの内、事業区画の仕
入先及びホームページの各テーブルの表示例を示す説明
図である。

【図２１】図２１は、従属関係コードのコード体系の一
例を示す説明図である。

【図２２】図２２は、表示モード変遷の一例を示す説明
図である。

【図２３】図２３は、ボタンと処理内容等の関係を示す
説明図である。

【図２４】図２４は、ユーザーのログインから端末への
要項データの表示までの概要を示すフローチャートであ
る。

【図２５】図２５は、ユーザーの権限とアクセス可能な
表示モード等との関係を示す説明図である。

【図２６】図２６は、ユーザーの権限を判定する処理例
を示すフローチャートである。

【図２７】図２７は、ロック可否判定処理及びロック取
得処理の一例を示すフローチャートである。

【図２８】図２８は、ロック解放処理の一例を示すフロ
ーチャートである。

【図２９】図２９は要項ＩＩでの編集モードの一例を示
す説明図である。

【図３０】図３０は要項ＩＩでの登録後の一例を示す説
明図である。

【図３１】図３１は分析制御部を備えた構成例を示すブ
ロック図である。

【図３２】分析制御部によって生成される相関図の一例
を示す説明図である。

【図３３】相関図生成機能の処理内容の一例を示すフロ
ーチャートである。

【符号の説明】

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

───────────────────────────────────────────────────── フロントページの続き (72)発明者樋代章平長野市大字中御所字岡田178番地８株式会社八十二銀行内

Claims

【特許請求の範囲】

【請求項１】ネットワークを介して端末及び他システ
ムと接続されたサーバーと、このサーバーによって処理
されるデータを格納するデータ格納部とを備え、前記サーバーが、取引先の組織及び事業と、当該取引先
についての時系列での主要な動向等についての文字デー
タを前記他システムから取得する取得制御部と、予め定められたユーザーインタフェース定義に基づいて
前記取得した文字データを前記端末に表示させると共
に、前記取引先の組織の内容を示す組織データと、事業
の内容を示す事業データと、当該取引先の主要動向を示
す動向コメントデータ等の入力及び編集を制御する表示
編集制御部と、前記取得制御部によって他システムから取得した文字デ
ータと前記表示編集制御部による制御に応じて入力及び
編集された文字データとを一体の体系での要項データと
して前記データ格納部等に格納する格納制御部とを備え
たことを特徴とする取引先要項システム。
【請求項２】前記取得制御部が、前記他システムによ
るワークフローにて決裁された結論又は結果の要点とな
る文字データを当該他システムの属性に応じて前記動向
コメントとして自動的に取得する結論要点データ取得機
能を備えたことを特徴とする請求項１記載の取引先要項
システム。
【請求項３】前記格納制御部が、前記他システムから
の要求に応じて取引先毎の要項データの一部又は全部を
当該他システムに送信する送信制御機能を備えたことを
特徴とする請求項１又は２記載の取引先要項システム。
【請求項４】前記表示編集制御部が、前記端末を使用
するユーザーの権限に応じて各文字データの表示、編集
及び削除の可否を制御する権限別機能制限制御機能を備
えたことを特徴とする請求項１、２又は３記載の取引先
要項システム。
【請求項５】ネットワークを介して端末及び他システ
ムと接続されたサーバーと、このサーバーによって処理
されるデータを格納するデータ格納部とを備え、前記サーバーが、当該取引先についての時系列での主要
な動向を明示的に区分する主要動向区分を管理すると共
に当該主要動向区分の他システムとの共有を制御する主
要動向区分管理部と、前記取引先についての時系列での主要な動向についての
文字データを主要動向区分別の動向コメントデータとし
て前記他システムから取得する取得制御部と、予め定められたユーザーインタフェース定義に基づいて
前記取引先の主要動向を示す動向コメントデータ及び前
記主要動向区分の入力及び編集を制御する表示編集制御
部と、前記取得制御部によって他システムから取得した動向コ
メントデータと前記表示編集制御部による制御に応じて
入力及び編集された動向コメントデータとを一体の時系
列での動向データとして前記データ格納部等に格納する
格納制御部とを備えたことを特徴とする取引先要項シス
テム。
【請求項６】前記主要動向区分管理部が、前記主要動
向区分の種別として、前記取引先との取引経緯に関する
取引経緯種別と、当該取引先の組織等の変遷に関する組
織・事業変遷種別と、当該取引先の財務会計の基礎事項
に関する財務会計基礎種別と、関連会社及び事業施設に
関する関連会社・施設種別と、当該取引先への債権等に
ついての信用リスクに関連するリスク管理種別とにそれ
ぞれ属する主要動向区分を管理する種別管理機能を備
え、前記表示編集制御部が、前記主要動向区分を前記動向コ
メント入力の必須入力項目として制御する主要動向区分
必須入力制御機能を備えたことを特徴とする請求項５記
載の取引先要項システム。
【請求項７】前記主要動向区分管理部が、前記各主要
動向区分を当該区分に属するさらに詳細な主要動向サブ
区分を管理するサブ区分管理機能を備えたことを特徴と
する請求項５又は６記載の取引先要項システム。
【請求項８】前記主要動向区分管理部が、前記主要動
向区分の種別毎の動向コメントの前記端末への表示を制
御する種別表示制御機能を備えたことを特徴とする請求
項６記載の取引先要項システム。
【請求項９】ネットワークを介して端末及び他システ
ムと接続されたサーバーと、このサーバーの制御に応じ
て前記他システムから取得した又は前記端末から入力さ
れた前記取引先の時系列での主要な動向に関する動向コ
メントデータ及び当該動向コメントデータの区分を示す
主要動向区分等を複数の取引先動向レコードとして格納
するデータ格納部とを備えた取引先要項システムを使用
して、前記動向コメントを前記端末に表示制御する取引
先動向表示制御方法であって、表示対象の取引先を識別するＣＩＦ番号を特定すること
で前記データ格納部に格納された当該取引先動向レコー
ド群を特定する取引先特定工程と、前記端末に表示する主要動向区分の種別又は属性を取得
すると共に当該種別等に応じて主要動向区分の抽出範囲
を設定する抽出範囲設定工程と、この抽出範囲設定工程にて設定された抽出範囲に属する
主要動向区分の取引先動向レコードを抽出する範囲内動
向コメント抽出工程と、この範囲内取引先動向レコード抽出工程にて抽出された
取引先動向レコード群を前記端末に表示する抽出表示制
御工程とを備えたことを特徴とする取引先動向表示制御
方法。
【請求項１０】ネットワークを介して端末及び他シス
テムと接続されたサーバーと、このサーバーの制御に応
じて前記他システムから取得した又は前記端末から入力
された前記取引先の時系列での主要な動向に関する動向
コメントデータ及び当該動向コメントデータの区分を示
す主要動向区分等を複数の取引先動向レコードとして格
納するデータ格納部とを備えた取引先要項システムを使
用して、前記動向コメントを前記端末に表示制御するた
めの取引先動向表示制御用プログラムであって、当該取引先動向表示制御用プログラムは、前記サーバー
及び端末を動作させる指令として、表示対象の取引先を識別するＣＩＦ番号を特定すること
で前記データ格納部に格納された当該取引先動向レコー
ド群を特定させる取引先特定指令と、前記端末に表示する主要動向区分の種別又は属性を取得
させると共に当該種別等に応じて主要動向区分の抽出範
囲を設定させる抽出範囲設定指令と、この抽出範囲設定指令に応じて設定される抽出範囲に属
する主要動向区分の取引先動向レコードを抽出させる範
囲内動向コメント抽出指令と、この範囲内取引先動向レコード抽出指令に応じて抽出さ
れる取引先動向レコード群を前記端末に表示させる抽出
表示制御指令とを備えたことを特徴とする取引先動向表
示制御プログラム。
【請求項１１】ネットワークを介して端末及び他シス
テムと接続されたサーバーと、このサーバーによって処
理されるデータを格納するデータ格納部とを備え、前記サーバーが、当該取引先についての時系列での主要
な動向を区分する主要動向区分を管理すると共に当該主
要動向区分の他システムとの共有を制御する主要動向区
分管理部と、前記取引先についての時系列での主要な動向についての
文字データを主要動向区分別の動向コメントデータとし
て前記他システムから取得する取得制御部と、予め定められたユーザーインタフェース定義に基づいて
前記取引先の主要動向を示す動向コメントデータ及び前
記主要動向区分の入力及び編集を制御する表示編集制御
部と、前記取得制御部によって他システムから取得した動向コ
メントデータ及び前記表示編集制御部による制御に応じ
て入力及び編集された動向コメントデータを時系列での
動向データとして前記データ格納部等に格納する格納制
御部とを備え、前記主要動向区分管理部が、前記主要動向区分の種別として、前記取引先との取引経
緯に関する取引経緯種別と、当該取引先の組織等の変遷
に関する組織・事業変遷種別と、当該取引先の財務会計
の基礎事項に関する財務会計基礎種別と、当該取引先へ
の債権等についての信用リスクに関連するリスク管理種
別と、前記取引先への営業推進に関する営業推進種別と
にそれぞれ属する主要動向区分を管理する種別管理機能
と、前記動向コメントに示される取引先の動向と関連した営
業推進の内容を対応する動向コメントと関連させて営業
推進種別の動向コメントとして登録する動向別推進結果
登録機能とを備えたことを特徴とする取引先要項システ
ム。
【請求項１２】前記主要動向区分管理部が、前記営業
推進種別の動向コメントを、当該営業推進結果の成約及
び不成約を示す推進結果コードで管理する推進結果コー
ド管理機能を備えたことを特徴とする請求項１１記載の
取引先要項システム。
【請求項１３】ネットワークを介して端末及び他シス
テムと接続されたサーバーと、このサーバーによって処
理されるデータを格納するデータ格納部とを備え、前記サーバーが、当該取引先についての時系列での主要
な動向を区分する主要動向区分を管理すると共に当該主
要動向区分の他システムとの共有を制御する主要動向区
分管理部と、前記取引先についての時系列での主要な動向についての
文字データを主要動向区分別の動向コメントデータとし
て前記他システムから取得する取得制御部と、予め定められたユーザーインタフェース定義に基づいて
前記取引先の主要動向を示す動向コメントデータ及び前
記主要動向区分の入力及び編集を制御する表示編集制御
部と、前記取得制御部によって他システムから取得した動向コ
メントデータと前記表示編集制御部による制御に応じて
入力及び編集された動向コメントデータとを時系列での
動向データとして前記データ格納部等に格納する格納制
御部とを備え、前記主要動向区分管理部が、取引先についての時系列での主要な動向についての動向
コメントデータを区分する主要動向区分を、主要動向区
分が属する種別と、当該主要動向区分と、当該主要動向
区分内で詳細に区分するサブ区分とのツリー構造で管理
する区分ツリー構造管理機能と、前記各動向コメントデータに前記ツリー構造とは別に当
該動向コメントデータをグループ分けするためのコメン
ト属性又は当該動向コメントデータの根拠等と関連した
コメント属性を管理するコメント属性管理機能とを備え
たことを特徴とする請求項５記載の取引先要項システ
ム。
【請求項１４】ＲＤＢと連携するマークアップランゲ
ージ（ＭＬ）のタグの体系を定義したタグ体系定義ファ
イルと、端末での表示及び入力について予め定められた
ＧＵＩ定義ファイルと、前記ＭＬのタグ付けされた取引
先毎のタグ付きデータを格納するＭＬデータＤＢと、他
システムにて一定期間毎に更新されるデータを格納した
ＲＤＢとを格納するデータ格納部と、前記取引先の組織及び事業並びに主要な動向等について
のデータの端末での表示及び入力を前記ＧＵＩ定義に従
って制御する表示編集制御部と、前記他システムから取
り込んだデータ及び前記端末から入力されたデータを前
記ＲＤＢでのデータ項目名若しくは前記ＧＵＩ定義に関
連した前記タグ体系定義に基づいてタグ付きデータに変
換すると共に、当該タグ付きデータを一体的な要項デー
タとして前記ＭＬデータＤＢに格納する格納制御部とを
備え、前記表示編集制御部が、前記ＧＵＩ定義と前記取引先の
態様とに応じて当該取引先の態様毎に入力不可とする項
目を制御する入力不可制御機能と、前記他システムにて更新されるデータを前記タグ体系定
義に基づいて取得すると共に、導出元項目への入力から
前記ＧＵＩ定義に基づいて導出先項目の内容を導出する
制御をする導出制御機能とを備えたことを特徴とする取
引先要項システム。
【請求項１５】前記表示編集制御部が、前記入力不可
制御機能によって入力されない項目及びユーザーから入
力されない項目について前記タグ付きデータを生成しな
い空タグ非生成制御機能を備えたことを特徴とする請求
項１４記載の取引先要項システム。
【請求項１６】前記表示編集制御部が、取引先の基本
属性、組織及び事業の内容の参照及び編集を要項Ｉデー
タとして管理する要項Ｉ管理機能と、前記主要な動向を
時系列で記録する動向コメントの参照及び編集を要項Ｉ
Ｉデータとして管理する要項ＩＩ管理機能とを備えたこ
とを特徴とする請求項１４記載の取引先要項システム。
【請求項１７】前記格納制御部が、当該要項データの
履歴の格納指令を受信した場合に、前記他システムから
のＲＤＢデータにて前記基本属性データを更新すると共
に、当該基本属性が更新された要項Ｉデータを当該要項
Ｉの履歴データとして格納する制御をする履歴格納制御
機能を備えたことを特徴とする請求項１６記載の取引先
要項システム。
【請求項１８】前記表示編集制御部が、要項Ｉデータ
の内容として、前記組織の内容を表示する組織区画に、連絡先、従業員
数、役員等、経理担当者、当行出身者、資本、大株主
（大口出資者）、事業施設、関連融資先名寄せ、その他
関連先、会計事務所、当行関連会社利用状況、及び有価
証券保有状況の各テーブルを有し、前記事業の内容を表示する事業区画に、平均月商、事業
内容、製商品、資金決済、販売先、仕入先の各テーブル
を有し、要項ＩＩデータの前記動向コメントの項目として、発生年月日、主要動向区分、動向コメント、記入年月
日、及び記入者を有することを特徴とする請求項１６又
は１７記載の取引先要項システム。
【請求項１９】前記表示編集制御部が、前記取引先を
当社とした場合の当社の役員等の自然人と、当社の大株
主（大口出資者）及び販売先等の法人若しくは事業性個
人とを識別するＣＩＦ番号を任意入力項目として管理す
ると共に、当該ＣＩＦ番号が入力された場合には当該Ｃ
ＩＦ番号を導出元として当該テーブルの名称項目及び住
所項目等を導出するＣＩＦ番号別入力支援機能を備えた
ことを特徴とする請求項１４又は１８記載の取引先要項
システム。
【請求項２０】前記表示編集制御部が、前記取引先の
役員の役職項目と、当該取引先と当該取引先への大口出
資者との関係項目と、関連融資先及びその他関連先と取
引先との関係項目とで使用する関係を示す従属関係コー
ドを用いて当該各項目の入力を管理する従属関係管理機
能を備えたことを特徴とする請求項１４記載の取引先要
項システム。
【請求項２１】前記表示編集制御部が、前記役職欄の
各レコードを従属関係コードの値に基づいて並べ替える
従属関係コード別ソート機能を備えたことを特徴とする
請求項１８記載の取引先要項システム。
【請求項２２】前記表示編集制御部が、前記取引先の
人格に応じて当該人格向けの従属関係コードを生成する
従属関係コード生成機能を備えたことを特徴とする請求
項１８又は１９記載の取引先要項システム。
【請求項２３】ＲＤＢと連携するマークアップランゲ
ージ（ＭＬ）のタグの体系を定義したタグ体系定義ファ
イルと、端末での表示及び入力について予め定められた
ＧＵＩ定義ファイルと、前記ＭＬのタグ付けされた取引
先毎のタグ付きデータを格納するＭＬデータＤＢと、他
システムにて一定期間毎に更新されるデータを格納した
ＲＤＢとを格納するデータ格納部と、前記取引先の組織及び事業並びに主要な動向等について
のデータの端末での表示及び入力を前記ＧＵＩ定義に従
って制御する表示編集制御部と、前記他システムから取
り込んだデータ及び前記端末から入力されたデータを前
記ＲＤＢでのデータ項目名若しくは前記ＧＵＩ定義に関
連した前記タグ体系定義に基づいてタグ付きデータに変
換すると共に、当該タグ付きデータを一体的な要項デー
タとして前記ＭＬデータＤＢに格納する格納制御部とを
備え、前記表示編集制御部が、すべての項目を入力及び編集不
可とする参照モードと、他システムから取得した項目及
び導出先の項目を入力及び編集不可とすると共に他の項
目の入力及び編集を許可する編集モードと、編集モード
での編集結果で各テーブルの内容をソートして表示を行
うと共に当該表示した内容での登録の確認を促す確認モ
ードとを備えたことを特徴とする取引先要項システム。
【請求項２４】前記表示編集制御部が、前記編集モー
ドで削除指示されたレコードを前記確認モードで削除し
て表示すると共に、当該確認モードでの確認指示に応じ
て当該レコードを削除する機能を備えたことを特徴とす
る請求項２３記載の取引先要項システム。
【請求項２５】前記表示編集制御部が、前記ユーザー
の所属店番と、取引先の取引店の店番との関係に基づい
て、前記参照モードから前記編集モードへの遷移を要求
するメッセージを前記サーバーに送信する編集ボタンの
表示及び非表示を制御するボタン表示制御機能を備えた
ことを特徴とする請求項２３記載の取引先要項システ
ム。
【請求項２６】前記表示編集制御部が、取引先の基本属性、組織及び事業の内容の参照及び編集
を要項Ｉデータとして管理する要項Ｉ管理機能と、前記主要な動向を時系列で記録する動向コメントの参照
及び編集を要項ＩＩデータとして管理する要項ＩＩ管理
機能と、前記ユーザーの所属店番と、取引先の取引店の店番とが
同一の場合に、前記要項Ｉデータ及び要項ＩＩデータの
参照及び編集を許可し、前記ユーザーの所属店番と、取引先の取引店の店番とが
異なる場合に、前記要項Ｉデータの参照を許可すると共
に、要項Ｉデータの編集及び要項ＩＩデータの参照及び
編集を不許可とする自他店別アクセス制御機能とを備え
たことを特徴とする請求項２３記載の取引先要項システ
ム。
【請求項２７】前記サーバーが、同一の取引先につい
ての複数のユーザーによる同時多重参照を許可すると共
に、同一時刻で複数のユーザーが同一の取引先について
編集モードとならないように編集モードの排他制御を行
うロック制御部を備えたことを特徴とする請求項２３記
載の取引先要項システム。
【請求項２８】前記ロック制御部が、前記編集モードへ遷移する時に、当該ＣＩＦ番号の取引
先の要項データ全体に他のユーザーによってロックが取
得されているか否かをロック管理情報に基づいて判定す
ると共に、ロックが取得されていない場合には、当該取
引先のＣＩＦ番号と、ロック取得するユーザーのユーザ
ーＩＤと、現在時間である開始時間と、開始時間に予め
定められたロック最長時間を加算した終了時間とからな
るロック管理情報を書き込むロック取得制御機能と、前記編集モードにて編集された内容が登録される時に、
当該ＣＩＦ番号の取引先の要項データ全体に他のユーザ
ーによってロックが取得されているか否かをロック管理
情報に基づいて判定すると共に、ロックが取得されてい
ない場合には、当該登録処理を許可すると共に、登録後
に当該ＣＩＦ番号のロック管理情報の終了時刻を現在時
刻に更新するロック解放制御機能と、前記ロックが取得されているか否かについて、当該判定
対象となる取引先のＣＩＦ番号で識別されるロック管理
情報のロック終了時刻が、現在時刻よりも未来であり、
且つ、当該ロック管理情報でのユーザーＩＤが異なる場
合に、ロックが取得されていると判定するロック可否判
定機能とを備えたことを特徴とする請求項２７記載の取
引先要項システム。
【請求項２９】ＲＤＢと連携するマークアップランゲ
ージ（ＭＬ）のタグの体系を定義したタグ体系定義ファ
イルと、端末での表示及び入力について予め定められた
ＧＵＩ定義ファイルと、前記ＭＬのタグ付けされた取引
先毎のタグ付きデータを格納するＭＬデータＤＢと、他
システムにて一定期間毎に更新されるデータを格納した
ＲＤＢとを格納するデータ格納部と、前記ＧＵＩ定義ファイルによる定義に基づいて前記取引
先の主要動向を示す動向コメントデータ及び前記主要動
向区分の入力及び編集を制御する表示編集制御部と、当該取引先についての時系列での主要な動向を明示的に
区分する主要動向区分を管理すると共に当該主要動向区
分の他システムとの共有を制御する主要動向区分管理部
と、前記他システムから取り込んだ動向コメントデータ及び
前記端末から入力された動向コメントデータを前記ＧＵ
Ｉ定義に関連した前記タグ体系定義に基づいてタグ付き
データに変換すると共に、当該タグ付きデータを一体的
な要項ＩＩデータとして前記ＭＬデータＤＢに格納する
格納制御部とを備え、前記表示編集制御部が、前記動向コメントを時系列で表
示すると共に表示のみで変更を不可とする取引先動向テ
ーブルと、参照モードでは既存の動向コメントを表示す
ると共に、編集モードでは既存の動向コメントの編集及
び新たな動向コメントの入力作業領域となる表示・入力
・編集エリアとを備えたことを特徴とする取引先要項シ
ステム。
【請求項３０】前記表示編集制御部が、前記表示・入
力・編集エリアにて将来の日付が入力されて当該将来日
付の動向コメントデータを登録した場合には、当該ユー
ザー等によって許可されないユーザー群に対する表示に
ついては、当該将来日付が到来するまで当該将来日付の
動向コメントを表示しない制御をする解禁指定登録制御
機能を備えたことを特徴とする請求項２９記載の取引先
要項システム。
【請求項３１】取引先の要項についてマークアップラ
ンゲージ（ＭＬ）でのタグ体系を定義したタグ体系定義
ファイルと、前記ＭＬのタグ付けされた取引先毎のタグ
付きデータを格納するＭＬデータＤＢとを格納するデー
タ格納部と、前記タグ体系定義ファイルによって定義さ
れる取引先の組織及び事業並びに各取引先の販売先及び
／又は仕入先に関する販売先等関連項目についての要項
データの端末での表示及び入力を前記ＧＵＩ定義に従っ
て制御する表示編集制御部と、前記要項データを前記タグ体系の定義に基づいてタグ付
きデータに変換すると共に、当該タグ付きデータを一体
的な要項データとして前記ＭＬデータＤＢに格納する格
納制御部と、この格納制御部によって格納された要項データから前記
取引先間の関係に関する情報を前記販売先等関連項目の
項目を検索キーとして抽出する分析制御部とを備えたこ
とを特徴とする取引先要項システム。
【請求項３２】前記タグ体系及びＧＵＩ定義が、前記
販売先等関連項目として、前記取引先及びその氏名又は名称及び住所等を唯一に識
別するＣＩＦ番号と、当該販売先及び／又は仕入先（販売先等）について前記
ＣＩＦ番号が付されている場合には当該販売先等のＣＩ
Ｆ番号と、当該販売先等について前記ＣＩＦ番号が付されていない
場合には当該販売先等の氏名又は名称並びに住所等と、前記販売先等への販売又は仕入に関する販売先等毎の売
上額又は仕入額とを有し、前記分析制御部が、前記ＣＩＦ番号又は氏名又は名称並
びに住所等を検索キーとして検索対象範囲の取引先の依
存関係を検索する汎用検索機能を備えたことを特徴とす
る請求項３１記載の取引先要項システム。
【請求項３３】前記分析制御部が、前記取引先のＣＩ
Ｆ番号等と前記販売先等関連項目の内容とに基づいて、
検索対象範囲の取引先間の販売・仕入関係を抽出すると
共に、抽出された販売先等のうち同一の販売先等を集約
し、販売・仕入関係を図示する定義ファイルを生成する
相関図生成機能を備えたことを特徴とする請求項３２記
載の取引先要項システム。
【請求項３４】前記データ格納部が、他システムにて
一定期間毎に更新されるＣＩＦ番号と氏名又は名称並び
に住所等の基本属性データを格納し、前記表示編集制御部が、前記端末に表示する法人、個人
又は個人事業主を登録するテーブルのレコードに当該Ｃ
ＩＦ番号が入力された場合には前記基本属性データを参
照して当該ＣＩＦ番号の前記基本属性を対応するレコー
ドへ導出するＣＩＦ番号別導出機能とを備えたことを特
徴とする請求項３１，３２又は３３記載の取引先要項シ
ステム。