JP4373642B2 - Supplier requirements system, supplier trend display control method, and program - Google Patents

Description

Translated fromJapanese

【０００１】
【発明の属する技術分野】
本発明は、取引先要項システムに関し、特に、取引先に関する文字情報を取り扱う取引先要項システムに関する。
【０００２】
【従来の技術】
従来、種々の業種の組織で、顧客や、営業見込先（以下、取引先）についての情報を集約し、管理するために、取引先の要項や、営業日誌や、顧客名簿等を手書きで作成していた。この取引先要項等は、取引先への営業推進や、取引先への債権についての信用リスク管理や、組織内での引継や、組織内での各種の稟議・回覧並びに承認時の添付書類として用いられていた。
【０００３】
また、近年、情報技術（ＩＴ）の発達に伴い、ＣＲＭ（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百万円）となる。図３２中、取引先ボックス右側での矢印は、仕入先テーブルや販売先テーブルの構成比率項目でのその他の値である。
【０１２９】
続いて、ステップＳ８６、Ｓ８７のループにより、販売先及び仕入先の抽出を繰り返す。Ａ産業の販売先の第２階層（Ｂ工業、販売２及び販売３）と、仕入先の第２階層（仕入１及び仕入２）の抽出が完了すると、全階層完了したか否かを確認する（ステップＳ８８）。ここでは第３階層まで抽出するため、ステップＳ８９にてすでに抽出した第２階層の販売先及び仕入先のうち、最初の取引先を対象取引先とする。例えば、仕入１を対象取引先として、仕入１の業種コード等を読み出し（ステップＳ８１）、さらに販売先を抽出する（ステップＳ８２）。Ａ産業以外については平均月商等の図３２への記載を省略している。仕入１（ｓ１、サプライヤーの１番目）の要項Ｉデータの販売先としてＡ産業が格納されていたとすると、Ａ産業は既に抽出されているため、ステップＳ８４で集約する。仕入２（ｓ２）を抽出すると、仕入２の販売先としてＡ産業は格納されていなかったとする。この場合、仕入２からＡ産業への矢印は、仕入２側で点線等とするとよい。仕入２は、販売先として、仕入２の販売先１（ｓ２ッｂ１，サプライヤー２のバイヤー１）を有する。
【０１３０】
第２階層の仕入先の抽出が完了すると、続いて、第２階層の販売先を抽出する。Ｂ工業（ｂ１，バイヤーの１番目）の要項Ｉデータでの仕入先として、Ａ産業が格納されていると、ステップＳ８４で集約される。Ｂ工業の仕入先としては、Ａ産業の他、「ｂ１ッｓ２（バイヤー１のサプライヤー２）」等が抽出される。図３２に示す例では、Ｂ工業の仕入先は、仕入２の販売先と同一であるため、集約している。続いて、第３階層の情報を抽出する。仕入１の仕入先（Ｓ１＿１）は、ＣＩＦ番号を有さず、情報がなかった。Ｂ工業の販売先の一つは、一般企業である。また、仕入１（ｓ１）の販売先の一つは、Ａグループであった。全階層について抽出及び集約処理が完了すると、相関関係定義ファイルの書き出し、他のアプリケーションソフトウエアでの編集を促すか、または、直接描画や印刷等を行う（ステップＳ９０）。
【０１３１】
図３３に示す処理等にて図３２に例示する相関図を生成すると、取引先間の平均月商の構成比率の関係等から、取引先の業界での地位や、販売先にとっての対象取引先の地位等を確認することができる。図３２に示すように、ある取引先を中心に、流通経路に従って相関図を生成すると、その製商品のサプライチェーンが明示され、コスト削減に関する提案等を行うこともできる。さらに、平均月商と、構成比率と、支払の締日や支払日の情報とに基づいて、売掛金等に関して、資金需要日程を把握することができる。この場合、現金比率等を併用するとよい。また、販売についての入金や、支払先（仕入先）毎の支払日等を取り扱うようにしてもよい。このように、資金の流れに着目した場合、相関図での矢印の向きは資金の流れと同様とし、図３２に示す例とは逆向きで、例えばＡ産業から仕入１等へ向かう方向とするとよい。
【０１３２】
相関図により、どの取引先がどの程度の運転資金をどのような日程で必要とするのかが一目瞭然となり、考慮した取引先にとって適切な営業推進の内容を行いやすくなる。また、同一取引先について、ＣＩＦ番号や、氏名又は名称等を用いて集約するため、取引の実状を視覚的に把握することができる。また、図３３に示す相関図を把握しておくと、ある取引先の信用リスクが急激に高まった場合の影響等を即座に把握することができる。
【０１３３】
相関図の検索範囲としては、図３２に示すように着目する取引先から数段階の仕入・販売階層としたり、ある業種でのグループ関係を抽出したり、ある原材料から最終製品までの関係を抽出するなど、種々の目的に応じた様々な相関図を取引先要項システムで整理・蓄積したデータから生成することができる。例えば、値動きが大きい原材料がある場合に、その原材料を製商品とする取引先の一連の流通及び相関関係を把握することで、原材料費の急騰という周辺状況の変化についての影響等を予め調査し、信用リスク管理の精度を飛躍的に向上させることができる。
【０１３４】
再度図３１を参照すると、データ格納部３は、他システムにて一定期間毎に更新されるＣＩＦ番号と氏名又は名称並びに住所等の基本属性データを格納するＲＤＢ５６を備えている。そして、表示編集制御部８が、端末１に表示する法人、個人又は個人事業主を登録するテーブルのレコードに当該ＣＩＦ番号が入力された場合には基本属性データを参照して当該ＣＩＦ番号の前記基本属性を対応するレコードへ導出するＣＩＦ番号別導出機能７０Ａを備えている。これにより、取引先要項データではＣＩＦ番号を中心に取引先の名称や住所の更新を同時期にすることができ、従って、相関図作成での集約処理が容易となる。
【０１３５】
要項データは、要項Ｉ及び要項ＩＩデータの他、今後の融資に関する当行の方針を示す融資方針等を含め、汎用検索機能１１４により、一定以上の融資方針となっている先を抽出できるようにしても良い。分析制御部１１０による抽出や検索を精緻で有用なものとするためには、表示編集制御部８が、主要動向区分コードを用いて主要な動向を記述した動向コメントを明示的に区分する主要動向区分管理機能１６Ａを備えるとよい。これにより、動向コメントの主要動向区分に該当する取引先の抽出が容易となる。例えば海外事業関連の主要動向区分での記入がある特定の業種の取引先を抽出し、また、ある営業店に着任直後に、その営業店を取引店とする取引先で、役員等異動の動向コメントが記入されている取引先の一覧を抽出する等の処理が可能となる。
【０１３６】
表示編集制御部８が、組織の役員、関連会社、大株主（大口出資者）、当該取引先の販売先並びに仕入先等のテーブルにて従属関係コードを用いて当該取引先との関係の区分を促す従属関係管理機能７２を備える例では、相関図や影響度をさらに詳細に且つコードによる精緻な検索を実行することができる。
【０１３７】
【発明の効果】
請求項１に係る本発明は、その構成によって、取引先の主要な動向を文章で表現した動向コメントデータについて、明示的に内容を区分する主要動向区分名称及びコードが選択され、この主要動向区分コードを他システムとのインタフェース（又はプロトコル）とするため、動向コメントデータの集約及び構造化を主要動向区分名称及びコードを用いてユーザーにとっても他システムにとっても明確とすることができ、且つ横検索の精度を向上させることができる。さらに、ＤＴＤの定義及びＸＭＬパーサーによる検証処理により、主要動向区分に区分されない動向についての登録を不可とすることで、担当者の熟練度によらず、記載する動向の粒度を強制的に一定とすることができ、また、主要動向区分のリストを工夫し、常に主要動向区分を用いることで、取引先の様々な動向のうち、登録すべき重要な動向の選別が明確となる。従って、取引店等の担当者（ユーザー）は、主要動向区分の体系を本発明に係るシステムの操作により理解し、記憶することを強制されるため、取引先へ整理された質問等を行うことができ、また、重要な動向についての記載もれや、必ずしも重要ではない動向を詳細に記載する等の担当者によるバラツキを防止することができる。従って、主要動向区分名称の選択と蓄積とにより、取引先要項として蓄積される情報が均質になり、このため、報告や引継等が明確で、さらに、各種の検索に際して有用な粒度の揃ったデータを得ることができる。
【０１３８】
請求項２、４及び５に係る本発明では、前記動向コメントデータを前記区分種別毎に表示をする際には、当該区分種別に属する前記主要動向区分コードの動向コメントデータを前記端末へ表示する制御をするため、例えばリスク管理区分の主要動向区分コードが付された動向コメントのみを抽出して表示する機能を備えることで、ユーザーが取引先の履歴及び注意すべき点等を即座に視覚的に把握することができる。
【０１３９】
請求項３に係る本発明では、動向コメントデータを、発生年月日によりソートして表示し、蓄積するため、ＸＭＬ技術を採用しつつ、視認性の高い、他システムで取扱い易いＸＭＬデータの表示、送信及び蓄積を行うことができる。
【図面の簡単な説明】
【図１】図１は第１実施形態での構成例を示すブロック図である。
【図２】図２は文字データの取扱に関する各システムの関係を示す説明図である。
【図３】図３は、主要動向区分の一例を示す説明図である。
【図４】図４は、動向コメントについてのＧＵＩの一例を示す説明図である。
【図５】図５は、動向コメントの種別表示の一例を示す説明図である
【図６】図６は、動向コメントの種別表示制御の一例を示すフローチャートである。
【図７】図７は、営業推進種別の動向コメントを他の種別の主要動向区分と関連させた例を示す説明図である。
【図８】図８は、第２実施形態の構成例を示すブロック図である。
【図９】図９は本実施形態で利用するＤＴＤの一例を示す説明図である。
【図１０】図１０は、図９に続くＤＴＤの一例を示す説明図である。
【図１１】図１１は、図９に示す例での要項ＩＩのｘｍｌデータの一例を示す説明図である。
【図１２】図１２は、図９及び図１０に示す例での要項Ｉのｘｍｌデータの一例を示す説明図である。
【図１３】図１３は、図１２に続くｘｍｌデータの一例を示す説明図である。
【図１４】図１４は、ＧＵＩ定義によるユーザービューの構成と図１１及び図１２に示すｘｍｌデータに対応した要項Ｉデータの内、組織区画の連絡先、従業員、役員等、及び経理担当者の各テーブルの表示例を示す説明図である。
【図１５】図１５は、要項Ｉデータの内、組織区画の当行出身者、資本及び大株主（大口出資者）の各テーブルの表示例を示す説明図である。
【図１６】図１６は、要項Ｉデータの内、組織区画の事業施設及び関連融資先名寄せの各テーブルの表示例を示す説明図である。
【図１７】図１７は、要項Ｉデータの内、組織区画のその他関連先、会計事務所、当行関連会社利用状況及び有価証券保有状況の各テーブルの表示例を示す説明図である。
【図１８】図１８は、要項Ｉデータの内、事業区画の平均月商、事業内容、特記事項、業界の地位、製商品及び資金決済の各テーブルの表示例を示す説明図である。
【図１９】図１９は、要項Ｉデータの内、事業区画の製商品、販売先及び仕入先の各テーブルの表示例を示す説明図である。
【図２０】図２０は、要項Ｉデータの内、事業区画の仕入先及びホームページの各テーブルの表示例を示す説明図である。
【図２１】図２１は、従属関係コードのコード体系の一例を示す説明図である。
【図２２】図２２は、表示モード変遷の一例を示す説明図である。
【図２３】図２３は、ボタンと処理内容等の関係を示す説明図である。
【図２４】図２４は、ユーザーのログインから端末への要項データの表示までの概要を示すフローチャートである。
【図２５】図２５は、ユーザーの権限とアクセス可能な表示モード等との関係を示す説明図である。
【図２６】図２６は、ユーザーの権限を判定する処理例を示すフローチャートである。
【図２７】図２７は、ロック可否判定処理及びロック取得処理の一例を示すフローチャートである。
【図２８】図２８は、ロック解放処理の一例を示すフローチャートである。
【図２９】図２９は要項ＩＩでの編集モードの一例を示す説明図である。
【図３０】図３０は要項ＩＩでの登録後の一例を示す説明図である。
【図３１】図３１は分析制御部を備えた構成例を示すブロック図である。
【図３２】分析制御部によって生成される相関図の一例を示す説明図である。
【図３３】相関図生成機能の処理内容の一例を示すフローチャートである。
【符号の説明】
１ 端末
２ ネットワーク
３ データ格納部
４ 取引先要項システム
６ 取得制御部
８ 表示編集制御部
１０ 格納制御部
１６ 主要動向区分管理部[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a supplier requirement system, and more particularly to a supplier requirement system that handles character information related to a supplier.
[0002]
[Prior art]
Conventionally, in order to aggregate and manage information on customers and prospects (hereinafter referred to as business partners) in organizations of various types of business, manuals for business partners, business diaries, and customer lists are created by hand. Was. These supplier requirements are attached to the business promotion to the business partner, credit risk management of the credits to the business partner, takeover within the organization, various types of approval / circulation within the organization and approval. It was used.
[0003]
In recent years, with the development of information technology (IT), CRM (Customer Relationship Management) and the like have been introduced, and a mechanism for sharing transaction details with customers in the organization is introduced. For example, a PC (Personal Computer) is distributed to a person in charge in the organization, the PC and a server in the organization are connected via a network, and the information of the business partner is stored in a DB (Data Base) provided in the server. Store. Then, in response to a request from the Web browser of the PC, the server determines the access right of the user of the Web browser and searches for necessary data from the DB. The server converts the search result into data using HTML (Hyper Text Markup Language) or the like, and transmits the data to a Web browser on the PC. By using such a server and a PC, information about a business partner is shared between persons in charge of distributing the PC.
[0004]
RDB (Relational Data Base) is widely used as a DB that cooperates with a Web server. The RDB is a DB that creates a plurality of tables according to real-world entities and defines the relationship between the tables, and uses an SQL (Structured Query Language) statement to insert, update, search, etc. Perform data manipulation. In RDB, when handling a plurality of data for the same item (or attribute, field, column) from the point of data consistency, an upper limit number is set in advance and different item names are used, or a plurality of items may occur. Defines another table and associates it. For example, when managing group companies of business partners, there are a wide variety of business partners with 0 group companies and hundreds of business partners. To develop with RDB, a group company presence flag, a group company table, It is necessary to assign a sequence number of a group company. As described above, in the RDB, it is difficult to handle an entity in which the number of records for one item may be significantly different depending on a business partner, and its development is complicated.
[0005]
In the RDB, normalization is performed in order to perform a reliable search and avoid inconsistencies in data. In order to perform normalization, an item to be a key of the table is set as an essential input item, and when there are a plurality of the same item, a sequence number or the like is given. If the number of arbitrary input items is increased and the degree of freedom of input is increased, it becomes difficult to execute an accurate and reliable search. Therefore, it has been difficult to increase the degree of freedom by reducing the required input items and to improve the workability and usability at the time of user input.
[0006]
In addition, simple memos and comments on information on business partners and their officers were easy to manage when handwritten, and it was easy to convey the situation. It is difficult to construct a system that realizes the same ease of use as handwriting, because it is necessary to decide in advance whether or not it will occur, or simply to use remarks.
[0007]
Further, in the RDB, in order to increase the use efficiency of a data storage unit such as a hard disk and to improve the search efficiency, it is necessary to predetermine the data type and data length for all items. Therefore, there has been a certain limit to flexibly handle character information such as comments in the RDB.
[0008]
On the other hand, in order to share the description contents in the handwritten supplier guidelines etc. within the organization, it is necessary to copy and mail them with a copying machine or the like. In addition, in order to grasp the latest state of business partners, it is necessary to recreate business partners and the like at regular intervals. In other words, since the titles of business partners, manufactured products, and the like change, it is necessary to rewrite this part. However, at the time of renewal, in order to fill in a new form, useless work such as copying items that have not changed occurs. In addition, at the time of this renewal, there is a risk that the information content may change or be missed due to a mistake in posting by the person in charge at that time, and therefore this renewal work will be a heavy burden on paperwork including confirmation work. It was.
[0009]
In addition, in the handwritten supplier guidelines, it is necessary to duplicate almost the same contents in other forms every time a business diary, various discussions, credit risk management, etc. are performed, which increases the administrative burden. When there are a large number of handwritten forms, it is cumbersome to manage which form is to be written and where the form is currently located, and in order to know the contents already described, the investigation is performed again.
[0010]
In addition, in the handwritten supplier guidelines, there is a case where the information is not necessarily uniform and uniform because of the skill level and personality when expressing the situation of the supplier. Therefore, it is difficult to use a business partner form in order to extract a business partner with a certain situation or attribute, and when there are a large number of business partners, there is a certain situation from a paper form. Since it takes a lot of labor to extract the suppliers in the field, there is a limit to its use. Therefore, it has been difficult to share the contents described in the supplier guidelines with the organization.
[0011]
[Problems to be solved by the invention]
It is conceivable to use information of contents to be described as a supplier guideline by creating a database and systematizing this supplier guideline. However, since there are various types and forms of suppliers, it is difficult to systematically handle abundant information similar to handwriting. In addition, when dealing with information such as the sales history of the product, the organization, business, and trend of the business partner, there are a lot of text information and there are entities and items that are not input depending on the business partner. In addition, if the corporate personality (hereinafter referred to as the personality) of a business partner such as a corporation or business person is different, the items handled will change, so modeling with RDB complicates entity relationships, and system development and operation And management cost will become large.
[0012]
In addition, for systematization of supplier requirements, it is desirable to have a mechanism that enables good extraction (horizontal search) of suppliers that correspond to the status, attributes, or characteristics of suppliers. If it can be described arbitrarily, the accuracy of the horizontal search will be reduced.
[0013]
Moreover, it is necessary to deal with the point that the update frequency of information related to suppliers differs depending on each supplier and item. And when referring to information related to business partners on a terminal such as a PC, it is difficult to grasp the freshness of the information at what point in time and the information is still valid. Handling is required. However, when the content of an item is updated, it is difficult to automatically handle which range of data is confirmed as the latest by updating the item.
[0014]
Furthermore, when referring to information related to a business partner on a terminal, it is difficult to intuitively inform the user whether the data is in the middle of a work workflow or approved data.
[0015]
And the burden of office processing due to duplicate handwriting in a form cannot be improved by simply systematizing individual tasks. In other words, if work such as inputting and registering the same contents in each system is generated, the burden of paperwork due to duplicate descriptions will not be reduced as a result.
[0016]
Conventionally, when supplier requirements are renewed at regular intervals, the person in charge memorized and reviewed the customer's situation more strongly as a result of this rewriting work. Systematization of supplier guidelines only refers to items other than the changes, and there is a possibility that the degree of understanding of the situation of the supplier by the person in charge may be reduced compared to the case of copying by handwriting and renewal at the time of renewal Can also be assumed.
[0017]
  In this way, in systematization of supplier guidelines that were done by handwriting, firstly, the relationship with other systems was organized,2In addition, we strive to achieve both the flexible handling of character data and the maintenance of lateral search accuracy.3In addition, it is desirable to have a mechanism for maintaining and improving the skills of the person in charge.
  In particular, the present invention is to make the supplier summary system according to the present invention a top-level DB among a plurality of systems that handle trend comment data, which is character data about major trends in time series for suppliers. Consider the features you need, andSearch from other systemsThe problem to be solved is to accumulate trend comment data such as maintaining the accuracy of horizontal search so that it can be used effectively.
[0018]
  The present invention provides a supplier requirements system capable of effectively utilizing data relating to a business partner stored while maintaining a flexible linkage with character data relating to a business partner and other systems. Objective.
  The present invention is particularly useful for trend comment data in a state that is highly available to users and other systems, that is, to clarify reporting and handover, etc. Accumulating data on new business partnersThat is the purpose.
[0019]
  In the present invention, as a premise of the invention,Handle character dataWith terminals and other systemsOver the networkConnected servers and data processed by this serverAs XML data including the character dataAnd a data storage unit for storing. AndThe data storage unit includes a DTD that is a tag system definition file that defines an XML system and tags for hierarchizing the data items, a GUI definition file that defines a display area and an input area in the terminal, Tagged data tagged according to DTD is stored as XML data including the character data, and an XML data DB retrieved from the server and the other system is provided.
Furthermore, the server displays the character data in the display area of the terminal by transmitting the data to the terminal.
  The server, on the other hand, receives data entered, selected or edited by the user of the terminal in the input area of the terminal, tags the data as defined by the DTD, and validates the validity by the XML parser. A verification process is performed, and the XML data subjected to the verification process is stored in the data storage unit. Also,The serverSearch from the other system is permitted.
Further, as a feature of the present invention, the tag system definition file includes a CIF number as an element of the DTD according to the tag system definition for the XML data, and an occurrence frequency of one or more times in parallel with the CIF number. With emerging customer trends.
  The customer trend has a main trend category name that appears once and a trend comment data that appears 0 times or once, and the CIF number is data that uniquely identifies the customer, The trend comment data is the character data, and is character data that is a text that is input or edited by a user of the terminal indicating a main trend of the business partner, and the main trend category name is the character data It is character data belonging to a predetermined classification type that is preliminarily classified in advance with respect to the user's terminal user.
  Also,In accordance with the GUI definition file, the server displays, as the display area, a transaction for displaying the data in the items of the main trend category name and the trend comment data for each business partner specified by the CIF number. A future trend table area is displayed on the terminal.
  In addition, the serverSupplier trend table, display editing control unit, mainIt has a trend category management unit and a storage control unit.
  The supplier trend table has the main trend category name and the trend comment data as data to be displayed in the supplier trend table area, or as data input, selected or edited in the input area. .
  The main trend category management unit manages the category type to which each major trend category belongs by storing, for each category type, the range of the main trend category code specifying the main trend category name.
  The display editing control unit fetches the XML data from the XML data file when displaying the data in the customer trend table area of the terminal, and stores the XML data according to a tag of the XML data. And the edited supplier trend table is displayed in the supplier trend table area of the terminal.
  When the user of the terminal inputs trend comment data in the input area, the user is allowed to select the main trend category name from the list of the main trend category names. When the main trend category name and trend comment data are input, selected or edited in the input area of the terminal, the data is received and edited in the supplier trend table.
  When storing the data of the supplier trend table, the storage control unit attaches a tag corresponding to each item to each data of the supplier trend table, and data relating to the supplier trend for each CIF number Is verified by the XML parser to determine whether the data is valid in relation to the tag system definition. By storing, the XML data in which the main trend category name appears only once for each supplier trend is stored in the XML data file,
  The server stores the XML data file in the database that allows the search from the other system using the main trend category name or the main trend category code for the trend comment data as an interface with the other system. Control sharing of trend comment data with other systems, Is adopted. Thus, the above-described problem is to be solved.
[0020]
The present invention employs XML technology in order to increase the availability of trend comment data, and accumulates trend comment data with tags as trend comment data. Furthermore, the trend comment data has a category of trend comment data selected from the list by the user in the same hierarchy as the trend comment data, and if there is trend comment data, the fact that the major trend category name exists is XML. Store after verifying with parser. Then, by using this main trend category name (or code) as an interface related to trend comment data, search from other systems is permitted to accumulate in a state where the availability of character data related to supplier trends is enhanced.Accordingly, the supplier guideline system according to the present invention isTrendsIt is positioned as the highest-level DB of character data regarding. That is, according to the present invention,By DTDStructured dataThe endIt can be displayed at the end or sent to another system. “Transmission” to another system is a process for permitting another system to access (search) the data storage unit according to the present invention.Is.
[0021]
In the first embodiment, a main trend classification code that explicitly classifies contents is used for a trend comment that expresses a main trend of a business partner in text (for example, FIG. 3). By using this main trend classification code as a protocol or interface between another system and the acquisition control unit, it is possible to clarify the aggregation and structuring of trend comments and improve the accuracy of lateral search. In addition, by using the group (type) of the main trend category, for example, it has a function to extract and display only the trend comments with the main trend category code of the risk management category, so that the user can record the history and attention of the business partner. It is possible to instantly grasp the points to be performed. In addition, by carefully selecting the main trend categories and disabling the input of trends that are not classified into the main trend categories, the granularity of the trends to be described is constant regardless of the person in charge, and the main trend categories are always used. This makes clear the selection of important trends to be registered among various trends of business partners.
[0022]
In the second embodiment, the essential data is XML data, and various functions relating to display editing are provided, so that data can be input and referenced with the same degree of freedom as in handwriting. In addition, basic character data related to business partners is imported from other systems, and essential items that maintain a systematic structure are automatically acquired, and the positioning of each item is simplified and clarified by the hierarchical data structure using XML. By supporting the input of character data while encouraging the user to understand, flexible handling of character data and maintaining the accuracy of horizontal search are achieved at the same time. Furthermore, the accuracy of the horizontal search is improved while facilitating the input by organizing codes indicating the relationship with the corporation or the individual having a relationship with the position or the business partner.
[0023]
DETAILED DESCRIPTION OF THE INVENTION
<First Embodiment>
FIG. 1 is a block diagram illustrating a configuration example according to the first embodiment. As shown in FIG. 1, asupplier summary system 4 according to the present embodiment includes a server connected to aterminal 1 and anothersystem 40 via anetwork 2, and adata storage unit 3 that stores data processed by the server. And. The server includes anacquisition control unit 6 that acquires character data about the organization and business of the business partner and the main trends in the time series of the business partner from theother system 40, and a predetermined user interface definition. The character data acquired based on (GUI definition etc.) is displayed on theterminal 1, the organization data indicating the contents of the organization of the business partner, the business data indicating the business content, and the trend indicating the main trend of the business partner. And a displayediting control unit 8 for controlling input and editing of comment data and the like.
[0024]
The server further stores character data automatically acquired from another system by theacquisition control unit 6 and character data input and edited according to control by the displayediting control unit 8 as essential data in an integrated system. Astorage control unit 10 for storing in theunit 3 and the like is provided.
[0025]
Theterminal 1 is a PC that can be used by headquarters and branch office users. Moreover, you may make it use portable terminals, such as a mobile telephone or PDA. Theterminal 1 displays data transmitted from the server according to data and programs transmitted from the server, and controls input of data to be transmitted to the server. Introduce an execution environment to the terminal, send the program to be executed on the terminal from the server to the terminal, and execute it on the terminal, so that the display on the terminal screen, button operations input from the terminal, combo box Select and send input character data to the server. Moreover, the above mechanism may be realized by introducing a web browser to the terminal and transmitting / receiving HTML data or the like according to HTTP, or by introducing an application to all terminals and communicating with the server. It may be a mechanism.
[0026]
Thenetwork 2 is a communication line such as a LAN or WAN, and connects a PC and a server using a protocol such as TCP / IP. Thedata storage unit 3 is a nonvolatile memory such as a hard disk. When thedata storage unit 3 viewed from the server is abstracted and handled as a resource or DB, DBMS or other data management software may be introduced into thedata storage unit 3. In this case, the server can use thedata storage unit 3 using a general data operation command such as SQL or a database access API. In the example shown in FIG. 1, the number ofdata storage units 3 is one, but they may be distributed or may be arranged at other locations via a network.
[0027]
When using the business partner system according to the present embodiment in a financial institution, as shown in FIG. 2, other systems include anonline system 42 such as an account system and an information system, afinancial analysis system 43, and a business partner (debtor).Credit rating system 44A for qualitative and quantitative assessment of credit risk, etc., self-assessment system 44B for assessing assets of financial institutions such as loan balances (credits), and financing under any conditions A loan deliberation system (project management system) 45 for managing a workflow such as whether or not to perform, abusiness diary system 47 for managing business contents, reports, etc. of a person in charge at a sales office or a head office sales department.
[0028]
Theacquisition control unit 6 acquires character data about the organization and business of the business partner and the main trends in the time series of the business partner among the data input, examined and approved by theother system 40. . As shown in FIG. 1, theacquisition control unit 6 automatically acquires the conclusion approved in the workflow by theother system 40 or the character data that is the main point of the result as a trend comment according to the attribute of the other system. A gistdata acquisition function 7 may be provided. For example, theacquisition control unit 6 searches the DB of another system using an SQL sentence or the like, and inserts / updates the search result in thedata storage unit 3. In theonline system 42 that performs account processing such as deposit and withdrawal to / from an account at a financial institution, a new operation may be defined on theonline system 42 side in order to acquire data from a system that is not an RDB. A base DB that updates and manages the data stored in theonline system 42 on a monthly basis may be constructed and used.
[0029]
The displayediting control unit 8 displays the character data acquired based on a predetermined user interface definition (GUI definition or the like) on theterminal 1 and also displays the organization data indicating the contents of the business partner organization and the business contents. Controls the input and editing of business data to be displayed and trend comment data indicating the main trends of the business partner. When the data registered in accordance with the input and edit control is stored in thedata storage unit 3, the display /edit control unit 8 also displays this data on the terminal. Examples of terminal display are shown in FIGS. As shown in FIG. 1, the displayediting control unit 8 is provided with a function restriction control function for each authority that controls whether or not each character data can be displayed, edited, and deleted according to the authority of the user who uses theterminal 1. Also good.
[0030]
Thestorage control unit 10 integrates character data automatically acquired from another system by theacquisition control unit 6 and character data input and edited in the past or in accordance with control by the displayediting control unit 8 in an integrated system. Is stored in thedata storage unit 3 or the like as essential data. The “integrated system” is preferably a hierarchical structuring of the entire essential data. In addition, a systematic construction of entity relationships may be used. An example of using XML to perform hierarchical structuring will be described later as a second embodiment. Thestorage control unit 10 stores essential data in thedata storage unit 3 in an integrated system using a language or API for operating the database. In the example illustrated in FIG. 1, thestorage control unit 10 includes a transmission control function that transmits part or all of the essential data for each business partner to theother system 40 in response to a request from theother system 40. Organize the data items handled by the supplier requirements system in an integrated system, collect data fromother systems 40, input and edit on theterminal 1, store this integrally, and part or all of the data in the hierarchy Send to other systems with information such as structure added. For this reason, in this invention, the handling at the time of taking in essential data to RDB with another system, or displaying on a screen becomes easy. In this way, important information according to the use and attributes in other systems can be aggregated in the supplier system, and the aggregated data can be transmitted to each other system.
[0031]
Thesupplier requirements system 4 according to the present embodiment aggregates important information according to the use and attributes in other systems and transmits the aggregated data to each other system. It can be positioned as the uppermost DB of character data to be processed. Position the supplier requirements system at the top of the character DB, collect character data from other systems, and supply all or part of the system data to the other systems as systematic requirements data, eliminating duplicate descriptions and Usability can be increased. Since standard character data handling (interface) can be provided to other systems, the development load related to character data handling can be reduced when developing other systems, and the development load is stable while maintaining a small development load. The necessary character data can be received from the supplier requirement system managed in the same manner. In addition, even if the data items are acquired from multiple other systems, the data is positioned in the structure / system as essential data. It is easy to maintain consistency.
[0032]
FIG. 2 is an explanatory diagram showing an example of cooperation between another supplier system and a supplier guideline system when the supplier guideline system is used in a financial institution. Theonline system 42 manages the CIF number for identifying the business partner, the name or name, and the basic attribute data of the business partner such as an address from the necessity for managing the account. Further, these basic attribute data are stored in an RDB such as a base DB as monthly customer information. The supplier requirement system acquires basic attribute data from this base DB on a monthly basis. In addition, history data or the like of essential points may be transmitted for searching to the base DB. In addition, when working with a company name identification process (related loan name identification) related to financing in the business partner system, the name identification result (group number and CIF number pair, etc.) should be sent to the online system. May be.
[0033]
Thecredit rating system 44A is a system that determines the credit rating of the business partner based on the evaluation of the financial status of the business partner, and receives a headquarters approval. When dealing with ratings in the supplier requirements system, it is preferable to obtain rating data from this credit rating system. For example, since trend comments indicating supplier trends are managed in chronological order, rating changes after these trends may be displayed together with main trends in the supplier requirements system. In the credit rating work, data on the business position of the business partner, the type of business, the products handled, etc. are required. For this reason, thesupplier requirements system 4 may transmit to the credit rating system the overview of the supplier, the result of company name identification, the presence / absence of the parent company or subsidiary, product information, etc. In addition, when a comment on the business position of a business partner or a comment regarding a manufactured product is input in thecredit rating system 44A and finalized, it is preferable to automatically incorporate this comment information into the business partner system. .
[0034]
Thefinancial analysis system 43 is a system for analyzing the financial state of a business partner who can obtain a financial statement from the necessity of financing or credit risk management. The average monthly sales, profit margin, etc. may be managed by an online system or may be managed by a financial analysis system. For this reason, you may make it acquire from the financial analysis system the average monthly sales of each supplier used by a supplier's essential point, the number of employees at the time of the account settlement of the supplier, etc. In addition, when a major shareholder or the like is changed at the time of financial registration, the necessary circulation may be performed in the workflow of the financial analysis system, and the registration may be automatically registered in the business partner system after approval.
[0035]
The self-assessment system evaluates assets such as loans from the viewpoint of credit risk management. Self-assessment is conducted twice a year in accordance with the bank closing date, and is classified into obligor categories such as normal, sensitive, and bankrupt depending on the obligor's situation, and the receivables are classified from class I. Classify by IV classification. Based on this classification, etc., allowance for doubtful accounts is calculated and the bank's asset status is reflected in the account settlement. In the work of classifying the debtors, the business type of the business partner, the position in the industry, the monthly sales for each product manufactured, etc. are also considered. For this reason, the industry code and average monthly quotient acquired from theonline system 42 and thefinancial analysis system 43 are transmitted to the self-assessment system. In addition, the self-assessment often includes an overview of the business partner. In this case, essential data on the date of self-assessment is transmitted to the self-assessment system.
[0036]
With regard to this self-assessment, the applicant has developed anasset assessment system 44 for assessing assets at any time throughout the year, such as when the business condition of a business partner (debtor) changes or when a financial registration is made. And filed a patent application. Thisasset assessment system 44 issues a self-assessment work when there is a change in the business conditions of a business partner. This business condition change of the business partner is one of the main trends of business partners in the businesspartner requirement system 4. When there is a change in business conditions, through self-assessment work using theasset assessment system 44, the contents of the business condition changes of the business partners are accurately grasped, and examination is repeated through the workflow from the sales office to the audit department. Approved and credit rating and debtor classification are maintained or changed. Thesupplier requirement system 4 automatically acquires the approved self-assessment reason as a trend comment. In addition, theasset appraisal system 44 may automatically acquire the general condition of the debtor from the corresponding item in the supplier requirements.
[0037]
Theloan appraisal system 45 makes a loan proposal to a business partner, or when a loan application is received from a business partner, sorts out the business condition of the business partner, and provides a workflow for approval / approval of loan conditions and availability. It is a system to manage. It is necessary to attach the supplier's guideline for the loan request. For this reason, the supplier requirement system transmits the requirement data at the time of making the loan request to the loan request system. If a loan policy is approved at the time of self-assessment, the loan policy or comment is made a part of the supplier's guidelines, and the loan policy is sent from the supplier's guidelines system to the loan approval system. May be. On the other hand, in the workflow controlled by theloan appraisal system 45, when the application for loan is refused and the request is abandoned, depending on the importance of the abduction, the transaction background or business promotion with the relevant business partner You may make it register into a supplier essential point system as a trend.
[0038]
The sales diary system is a system for managing a sales promotion workflow such as a person in charge at a sales office reporting a business situation. The business diary system may manage sales, response to DM shipment, etc. in cooperation with project management, loan appraisal system, and the like. In this case, the progress of the business promotion is managed by the business diary system, etc., and any comments that have been made or not made as a result of the business promotion are commented on trends depending on the importance of the business promotion. May be automatically registered in the supplier's guidelines.
[0039]
In this way, thesupplier requirements system 4 is positioned as the highest-level DB for handling character data, and as a system for registering character data that briefly indicates the main points when the workflow is completed and conclusions and results are obtained. Can be used. With regard to the handling of character data, when using thesupplier requirement system 4 having such character, it is possible to easily handle the aggregation and distribution of character data indicating conclusions with respect to the character data handled by many systems while maintaining consistency. it can. In particular, since the supplier requirements system handles the items in an integrated system, it is easy to share character data with other systems, allowing users to handle consistent character data consistently across all systems. This can be realized without increasing the burden of
[0040]
When important character data is collected in the supplier's guideline system, it is possible to prevent the information from being lost and to refer to it at any time by operating a terminal such as a PC in order to confirm the contents. That is, by using the supplier requirements system, detailed work results in each system can be referred to as a list, and consistency with data of other systems can be maintained while preventing duplicate registration.
[0041]
As a business, it is possible to maintain the homogeneity and accuracy of comment information by establishing a consistent and stable business process of registering conclusions based on the workflows of other systems, and the systematic structure of essential data. As a part of the system and the mechanism that clearly shows the basis of the character data, it becomes easy to access the basis of the character data, and thesupplier requirement system 4 is used as a window related to the information of the supplier. be able to. When such systematic and organized information is accumulated, it is possible to shorten the time taken over at a sales office or the like, and to effectively prevent the occurrence of takeover. In addition, since the workflow for obtaining a conclusion or the like is performed by another system, circulation or the like in the supplier guideline system becomes unnecessary.
[0042]
Referring to FIG. 1 again, thesupplier guideline system 4 according to the present embodiment manages the main trend categories in which the server explicitly classifies the main trends in time series for the suppliers, and the main trends. A main trendcategory management unit 16 that controls sharing of categories with other systems is provided. “Explicit classification” means, for example, that the main trend classification is an indispensable input item in the customer trend record. Furthermore, as the main trend category, a category such as “others” where the type or attribute cannot be specified may not be provided.
[0043]
FIG. 3 shows examples of main trend category codes and major trend category names when used in financial institutions. In the example shown in FIG. 3, when trend comments are input according to the control of the displayediting control unit 8 of thesupplier requirement system 4, the categories to which the trend comments belong are arranged in advance. There are various modes for starting a loan transaction, but a trend comment on the start of a loan transaction always belongs to the main trend category of “start of the Bank's loan transaction” of 00190.
[0044]
The main trendcategory management unit 16 includes atype management function 18 for managing the type of the main trend category. As shown in FIG. 3, the major trend categories are as follows: a transaction history type relating to a transaction history with a business partner, an organization / business transition type relating to the organization and business transition of the business partner, and financial accounting of the business partner. Financial accounting basic types related to the basic matters, affiliated companies / facility types related to affiliated companies and business facilities, and risk management types related to credit risk related to receivables, etc. to the business partners. Further, as a type of main trend category, a main trend category belonging to a business promotion type related to business promotion to a business partner may be defined.
[0045]
FIG. 4 shows a GUI and an example of contents of a supplier system for handling trend comments. In the following, examples of screens and business partners will be disclosed for explanation, but the contents are virtual examples and are irrelevant to actual corporations and individuals.
[0046]
In the example shown in FIG. 4, transaction details handled by the supplier requirement system are displayed in the supplier trend table 100. The supplier trend table 100 has a plurality of supplier trend records (one line in the table) as a list display. The supplier trend record includes the date of occurrence, main trend category, and details (trend comment). ), Entry date, and entry person. In the example shown in FIG. 4, the displayediting control unit 8 includes a main trend category mandatoryinput control function 20 that controls the major trend category as an essential input item for the trend comment input. Accordingly, all trend comments handled by thesupplier requirements system 4 are assigned major trend categories. For this reason, trends that are not in the main trend categories are not described. By explicitly classifying trend comments according to major trend categories, the trends of business partners that do not fall under the major trend categories are not registered as unnecessary in the relevant supplier guidelines system. As a result, the granularity related to the importance of trend comments can be systematically enforced regardless of the user's skill, and uniform data accumulation can be achieved.
[0047]
In the example shown in FIG. 4, the date of occurrence of the loan transaction is October 1, 1960, and the trend of the business partner before the start of the transaction is registered on the same day. In the entry field, the store number and full name are displayed, but are omitted in the figure. Since then, only important matters defined for major trends such as receiver / account receivable accidents and establishment of business facilities have been registered. “Recipient” is a bill of exchange. In October 1970, there was a transfer, which is a change of the dealer. At this time, the entrants changed from the person in charge at the Nagano branch to the person in charge at the head office sales department. After that, the company was listed and established a subsidiary. The trend comment regarding the poor performance can be automatically acquired from theasset assessment system 44B when, for example, theasset assessment system 44B reviews the obligor category according to the poor performance.
[0048]
Further, as shown in FIG. 1, the main trendcategory management unit 16 may include a sub-category management function 22 for managing each main trend category in more detailed main trend sub-category belonging to the category. In this case, by using the main trend subcategory, the trend comment can be described more simply and shortly, and the relevance rate in the horizontal search can be further increased. Examples of sub-categories include the type and extent of worsening surrounding conditions, the level of poor performance, and applicable laws in filing legal proceedings.
[0049]
In a preferred example, the main trendcategory management unit 16 includes a typedisplay control function 24 that controls the display of trend comments for each type of main trend category on theterminal 1. The type display function maintains and improves the skills of the person in charge, and promotes accurate grasp of the status of business partners in a short time. For example, the typedisplay control function 24 extracts and displays only trend comments belonging to the risk management type and only trend comments belonging to the organization / business transition type. In the example shown in FIG. 4, two types of display, that is, all display and display of only the risk management type are provided.
[0050]
FIG. 5 is an explanatory diagram illustrating an example of a trend comment type display. Among the customer trend records shown in FIG. 4, there are two records to which the main trend category belonging to the risk management type is attached, that is, a receiver / account receivable accident and poor performance. The user compares the display of only this risk management type (management item) with the display of all indications, and grasps the trends of business partners in a short time and accurately by performing a detailed examination of the risk management items. be able to.
[0051]
In order to display only the management items, in the example shown in FIG. 3, a supplier trend record having a main trend category code of 10,000 or more and less than 20,000 is extracted. FIG. 6 is a flowchart illustrating an example of trend comment type display control. First, the trend comment group of the said customer stored in thedata storage part 3 is specified by specifying the CIF number which identifies the supplier of a display object (step S1, supplier identification process). Subsequently, the type of the main trend category displayed on theterminal 1 is acquired (step S2), and the extraction range of the main trend category is set according to the type or the like (step S3, extraction range setting step). For example, if the management item display button shown in FIG. 4 is pressed, the type of main trend category to be displayed is the risk management type shown in FIG. 3, and the main trend category code to be extracted is 10,000 or more and less than 20,000. To do. Subsequently, the supplier trend is read for one record (one line) (step S4), and it is determined whether the main trend classification code of the supplier trend record is 10,000 or more and less than 20,000 (step S5). ). If it is within the range, it is added to the display target of the type. For example, it is stored in an array for screen display. Then, it is confirmed whether or not reading of all the records in the supplier trend table has been completed (step S7). If there is an unread record, the next record is set as a reading target (step S8).
[0052]
Steps S4 to S8 are repeated to extract all supplier records in the main trend category belonging to the extraction range set in the extraction range setting steps S2 and S3 (intra-range trend comment extraction step). Subsequently, the supplier trend record that is the type display target is displayed on the terminal 1 (step S9, extraction display control step).
[0053]
The configuration shown in FIG. 1 and the processing shown in FIG. 6 and the like can be realized by the CPU of the server executing a predetermined program. The server of the supplier summary system and the CPU (not shown) of the terminal perform various calculations according to a predetermined program (command). The CPU displays character data or the like on the screen of theterminal 1 according to various processing requests, and promotes input of trend comment data or the like.
[0054]
Particularly in the present embodiment, the supplier trend display program includes the following commands.
A supplier identification command for specifying the supplier trend record group stored in thedata storage unit 3 by specifying the CIF number for identifying the supplier to be displayed.
An extraction range setting command for acquiring the type or attribute of the main trend category displayed on theterminal 1 and setting the extraction range of the main trend category according to the type or the like.
An in-range trend comment extraction command for extracting a supplier trend record of a main trend category belonging to the extraction range set according to this extraction range setting command.
An extraction display control command for causing the terminal to display a supplier trend record group extracted according to the in-range supplier trend record extraction command.
[0055]
This supplier trend display program is stored in arecording medium 11 </ b> A such as a magnetic tape (MT) or disk, conveyed, and read by thedisk drive 11. The supplier trend display program stored in the recording medium is read by thedisk drive 11 and then stored in a program storage unit (not shown). Also, the program can be provided from another host device to the program storage unit via a communication line.
[0056]
When referring to a program as an instruction to operate the CPU, an instruction to operate the CPU only with each instruction and an instruction to operate the CPU depending on other programs such as an operating system stored in advance in the program storage unit Or both. Here, “operating system” is interpreted broadly. Includes transaction manager, database manager, execution environment, etc.
[0057]
In the example of accumulating trend comments relating to business promotion, a main trend category corresponding to the transaction history type of the main trend category may be added. In a preferred example, when trend comments relating to sales promotion are stored in relation to other types of trend comments, it is possible to generate supplier trends that are easy to register and reference and are easy to understand. In this example, the main trendclassification management unit 16 registers the business promotion content related to the business partner trend indicated in the trend comment as a trend comment of the sales promotion type in association with the corresponding trend comment. Aregistration function 26 is provided. The trend-by-trend promotionresult registration function 26 registers the contents of business promotion such as the execution of financing in relation to the trends of business partners classified into business development / change and business facility installation.
[0058]
In a preferred example, the main trendclassification management unit 16 may include a promotion resultcode management function 28 that manages trend comments of the sales promotion type with a promotion result code indicating the conclusion and non-success of the sales promotion result. Closing is when a loan agreement is established, and non-promise is a loan proposal, but the loan is not accepted by the customer, and the loan application review results and the conditions do not match. There is a case where it is determined that the execution of the system cannot be performed. The major trend category “Abandonment” is a category for cases where it is determined that such loans cannot be executed. At that time, there is a strong meaning of a higher credit risk, such as the discovery of excessive powder on the financial statements. In such cases, it is registered as a transaction history.
[0059]
FIG. 7 is an explanatory diagram illustrating an example in which a trend comment of a sales promotion type is associated with a main trend category of another type. In the example shown in FIG. 7, the trend of business partners, the contents and results of business promotion are described in the detailed comments. Then, between the detailed comment and the date of entry, the contract or non-contract of the result of business promotion is displayed. For example, at the start of the Bank's loan transaction on October 1, 1960, it was closed. At this time, a comment is written: “A bank fund transaction will be a parallel transaction due to the start of this bank transaction. On October 1, 1965, a new person in charge at the dealership promoted the business, and the construction of the plant and capital investment of 100 million yen were concluded (period 15 years). In April 1973, paying attention to the establishment of a subsidiary, “Promotion of working capital was promoted, but funds were raised from A Shinkin”, which was a breach of contract. In the example shown in FIG. 7, only these items can be displayed by depressing the promotion item display button.
[0060]
In the example shown in FIG. 3 and the like, the main trend categories for classifying trend comments have a hierarchical structure of a plurality of types and categories belonging to various types. In addition, when sub-partitions are used, there are three layers. This hierarchical handling can systematize the importance of customer trends. On the other hand, in the hierarchical structure, there is a case where one item wants to temporarily belong to another item. Further, if links regarding the grounds and relations of each item can be attached, the relationship with work result files and the like in other systems can be handled systematically. In such an example, as shown in FIG. 1, the main trend category belongs to the main trend category in which the main trendcategory management unit 16 classifies trend comment data about main trends in time series for business partners. A category treestructure management function 30 that manages a tree structure of a type, the main trend category, and a sub-category that is classified in detail within the main trend category, and the trend comment separately from the tree structure for each trend comment data It is preferable to provide a comment attribute management function 32 for managing a comment attribute for grouping data or a comment attribute related to the basis of the trend comment data.
[0061]
The category treestructure management function 30 manages major trend categories in three layers. The comment attribute management function 32 manages attribute information of each comment. When file names of other systems are stored as comment attribute information, the automatic registration of trend comments and the file name of the material on which the comment is based can be automatically registered in the supplier requirements system. For example, when “business development / variation” is a risk management target (cause), by setting this attribute as a risk management type, this trend comment can be included in the management item display. In this example, in step S3 of FIG. 6, an extraction range is set for the code value of the main trend category code and the attribute information of the trend comment. For example, in the type display by pushing down the promotion item display button shown in FIG. 7, the trend comment in which the promotion result code is registered as attribute information and the main trend category code belonging to the transaction history type shown in FIG. 3 are registered. Trend comments may be extracted and displayed. Further, the type display may be controlled only by the attribute information such as the display flag without using the code value of the main trend category. Further, the type display and the transmission of the type to another system can be realized with substantially the same function. Therefore, the type transmission to other systems can be realized by using only the main trend classification, only the attribute information, or using both.
[0062]
Second Embodiment
In the second embodiment, an example will be described in which a supplier requirement system is constructed using a structured markup language (ML) such as XML (eXtensible Markup Language). XML is a document description format derived from SGML (Standard Generalized Markup Language), which simplifies SGML and is adapted for use on the Internet. In XML, by defining a document type definition (DTD), a tag system (tag set) corresponding to the use of data is used. By using the tag system, document types of elements and attributes can be defined. XML data is a text file that indicates the structure of a document with tags defined by DTD. Since XML is based on SGML, it is suitable for processing non-standard documents such as books and Web pages. For example, the length of data included in one item cannot be determined in advance, and it is difficult to manage a document in which the number of items changes with the RDB, but XML data is tagged text data. Therefore, character information can be handled flexibly.
[0063]
The tag system indicating the structure of the XML document is a hierarchical type. The hierarchical type is, for example, a tree structure in which an element of an organism includes animals, plants, and microorganisms, and an element of an animal includes species such as mammals and reptiles. The tree structure is useful for humans to understand the semantic content of the elements. On the other hand, the tree structure is easy for a computer in that data can be manipulated by accessing a parent-child relationship in which elements are nodes. XML data, which is a set of character data clearly defined in a hierarchical structure, is used not only for page markup but also for describing meta contents for managing various properties, exchanging data with RDB, and messaging can do. That is, a tag indicating the structure of a document is used for specifying an expression format on a page or the like, an attribute specification in a character data system as an element, or a correspondence with an item in an RDB table.
[0064]
In the DTD that defines the tag system, the data type of elements is only character data. An XML document that correctly follows the specified DTD is said to be valid. A valid XML document conforms to the element name, hierarchy, order, and number of appearances such as whether the element is essential or optional as defined in the DTD.
[0065]
A software module that handles XML data is called an XML parser (XML processor). The XML parser parses the XML data and verifies the validity. The XML data whose validity has been verified follows a predetermined tag system. Examples of API (Application Programming Interface) for accessing the internal structure of XML data include DOM (Document Object Model) and SAX (Simple API for XML). DOM expresses XML data as a tree (DOM tree) composed of nodes of elements and character data. A valid XML data DOM tree follows the hierarchical definition by DTD. The DOM API is suitable for processing that sorts the elements of an XML document in a certain order, moves them to another place, or inserts new elements.
[0066]
XML is often used by Web applications that realize certain functions while transmitting and receiving data and programs between a server and a terminal. For this reason, XML parsers or the like having a function for verifying validity are object-oriented. Many have been developed for the Java language (registered trademark). In the Java development / execution environment, class hierarchies have already been defined, and by utilizing interfaces (also called protocols in other languages) without multiple inheritance, programs called modules and components Increases reusability and independence of parts. In a Java development environment, an existing module can be used for XML validation. In Web application development, particularly J2EE (Java 2 Platform, Enterprise Edition), a database, a server, and a terminal are conceptually and role-divided into three to five layers. For example, in J2EE, a Web layer that provides a presentation function for generating a GUI and an EJB layer for executing application logic can be separated. EJB (Enterprise Java Beans) is a component for business logic in J2EE. The EJB container, which is the execution environment of EJB, manages details such as transaction processing, security, and load balancing. You can concentrate on coding. For example, when EJB is used, distributed transactions are automatically supported, and even if a plurality of databases are used, transactions can be updated atomically. This means that, for example, it is possible to easily store the registration of data in the database of the supplier requirement system and the registration of data in the database of another system within one transaction.
[0067]
In J2EE, the terminal often uses a Web browser or a Java application equipped with a GUI. When using a Java application, it is easy to define a GUI by using Swing as a GUI or a screen design tool using the same. The EJB maintains a session with the Java application of theterminal 1 and can receive an event such as a button press directly or via the presentation layer. The EJB instructs the change of the display mode according to the event, calculates the composition ratio between the elements, searches the RDB using the input of the derivation source as a search key, operates the DOM tree, and executes the search result. Can be added as a derivation element, or elements can be sorted. When sorting elements is considered a presentation problem, implement this sort in the presentation layer.
[0068]
Various methods have been proposed for storing XML data in a database. Mapping XML tags to RDB tables and storing them in RDB, storing XML data as huge text data, generating search indexes as side tables, and class hierarchy in object-oriented databases For example, a method of mapping XML data.
[0069]
In XML data operations, instead of using a DOM tree, the schema definition of complex records is performed, and XML data tags, Java objects, and database records can be converted to each other at any time. An execution environment is also provided. In addition, XML Schema is defined as a technique for making document type definition easier to use in XML-related technology. When XML Schema is used, the data type and the like can be verified by validating the XML data.
[0070]
In the present embodiment, a database that stores DTD, DOM tree, and XML data as text and can be searched by SQL using a side table, EJB by J2EE, GUI by Swing, applet executed by Web browser, It uses techniques such as type checking using EJB, servlets, and applets, display editing control, and data fetching from other systems using RDB. Instead of DTD, DOM tree, SQL search, applet, and Web browser, XML Schema, complex record, XQuery, a combination of Web browser and XSLT may be used. When the terminal is a portable terminal such as a PDA or a mobile phone, for example, in order to provide only a display, XML data may be converted into HTML by XSLT and transmitted.
[0071]
FIG. 8 is a block diagram illustrating a configuration example of the second embodiment. A supplier system according to the present embodiment includes a tagsystem definition file 50 that defines a tag system of a markup language (ML) that cooperates with an RDB, and a GUI definition file 52 that is predetermined for display and input on a terminal. , ML data DB (XML data DB in the example shown in FIG. 8) 54 that stores tagged data for each business partner tagged with the ML, and data that is updated every other period in the other system 40 Adata storage unit 3 for storing the storedRDB 56;
[0072]
The tagsystem definition file 50 is, for example, a DTD file. GUI definition includes screen layout definition by Swing etc., data type defined in relation to table items (fields) used on each screen, definition of derivation relationship between items, display property data and display This is the relationship of buttons to be performed. For example, when theXML data DB 54 stores the XML as a huge text file and uses the extension of the RDB that creates a side table for search, it becomes possible to handle the increase / decrease in the number of items relatively flexibly. The RDB may be an RDB having a function of taking in data of an online system that uses a hierarchical data structure such as IMS.
[0073]
In the example shown in FIG. 8, the server captures from theother system 40 the displayediting control unit 8 that controls the display and input of data about the organization and business of the business partner and main trends on the terminal according to the GUI definition. Data and data input from theterminal 1 are converted into tagged data based on the data item name in theRDB 56 or the tag system definition related to the GUI definition, and the tagged data is converted into integral data. And astorage control unit 10 for storing in the ML data DB.
[0074]
The displayediting control unit 8 is a software group in the presentation layer and an EJB that executes business logic. Thestorage control unit 10 uses an EJB component for storing XML data in theXML data DB 54, a parser module that performs verification by DTD before storage, and an API of theJDBC data DB 54 when using, for example, JDBC. DB54 driver or the like to be mapped.
[0075]
The displayediting control unit 8 includes an input disablingcontrol function 60 that controls items that cannot be input for each aspect of the supplier in accordance with the GUI definition and the aspect of the supplier. Thisfunction 60 performs control such that, for example, a corporation is not permitted to input a shop name field, while an individual business owner is permitted to input. As a result, all tags used with various personalities can be defined by one DTD, and the layout of the screen can be the same for the corporation and the individual business owner.
[0076]
In addition, the displayediting control unit 8 obtains data updated in theother system 40 based on the tag system definition and derives the content of the derivation destination item from the input to the derivation source item based on the GUI definition. Aderivation control function 62 is provided. Of the data updated by theother system 40, basic attribute data and basic loan attribute data acquired monthly from theonline system 42 via the infrastructure DB and the like are managed in the RDB with the CIF number as a key. For this reason, in various tables of the supplier requirements, in the record having the CIF number, the name or name, address, loan destination number, main transaction store, industry code, etc. can be derived from the CIF number.
[0077]
Thederivation control unit 62 performs control for deriving a name or name that is a derivation destination item from a CIF number that is a derivation source item. In the derivation control, for example, in the presentation layer, when the derivation source item becomes active and the input is started, the derivation destination item is grayed out to make the input impossible. In the EJB layer, necessary item data is extracted from theRDB 56 using the CIF number as a search key, and inserted into the corresponding derivation destination item of the data edited for the DOM tree or screen display.
[0078]
Thederivation control unit 62 further calculates the composition ratio. For example, when the number of issued shares of a business partner is known and the major shareholders and the number of shares held are registered in the supplier's guidelines, the shareholding ratio of each shareholder is calculated from the number of shares issued and the number of shares held by each shareholder. . The field for inputting the number of shares is the derivation source, and the field for displaying the shareholding ratio is the derivation destination. In actuality, when the derivation button is pressed or the registration button is pressed, data is received from theterminal 1 and theRDB 56 is searched and the ratio is calculated by the EJB on the server side.
[0079]
In a preferred example, the displayediting control unit 8 includes an empty tagnon-generation control function 64 that does not generate tagged data for items that are not input by the input disablecontrol function 60 and items that are not input by the user. Thenon-input control function 60 allows a single DTD independent of personality to be used. Since the empty tagnon-generation control function 64 does not generate tags for items that are not input, as a result, from the single DTD, the XML data of the individual business owner uses only the tags used for the personal business owner, The corporate XML data uses only tags used for the corporate body. For example, when the business partner is a corporation, the shop name is not input, so that an empty tag for the shop name is not generated. Therefore, XML data similar to that for creating a DTD only for a corporation can be obtained. Thereby, construction of data transmission to other systems can be simplified.
[0080]
In the present embodiment, the displayediting control unit 8 records the main trends in time series, and the essential I management function 66 that manages the reference and editing of the basic attributes, organization, and business contents of the business partners as essential I data. A requirement IImanagement function 68 for managing trend comment reference and editing as requirement II data is provided. In order to collect information on business partners more broadly, for example, data relating to a guarantor may be managed as the essential item III, or data relating to a loan policy may be managed as the essential item IV. In the present embodiment, examples of DTD and GUI will be described for the essential points I and II.
[0081]
FIG. 9 is an explanatory diagram showing an example of a DTD used in the present embodiment. The description of DTD is by SGML. yoko2.dtd is the DTD of supplier requirements II. The element (ELEMENT) of supplier essential point II has a CIF number and a supplier trend. The + at the end of the supplier trend indicates that this element appears one or more times. If nothing is added at the end, it must be specified once.? Is 0 or 1 and * is 0 or more. No end and + are required items, and + and * can be written repeatedly on XML. ? And * may not appear. For this reason, the essential item II data is generated when one supplier trend is input for the supplier of the CIF number. The supplier trend may be entered repeatedly.
[0082]
The supplier trend includes the date of occurrence, major trend category code, major trend category name, detailed comment, date of entry, store name, store name, store user ID, and store name. The detailed comment is a trend comment, and if the main trend category and the date of occurrence are entered, the essential point II data is registered even if no comment exists. An example of the essential item II data by this DTD is shown in FIG.
[0083]
yoko1.dtd is the definition of supplier requirements I. As the basic attribute, the industry code and the industry name are enclosed in parentheses in order to specify that the industry name is also required when the industry code is input. Since? Is added outside the parentheses, the number of appearances of the set of industry code and industry name is designated 0 times or once. As a customer, the base date, basic attributes, etc. are defined. This customer stores the data of theother system 40 in theRDB 56 and is the data acquired by the supplier requirement system. Data belonging to this customer cannot be entered. This customer tag definition is a definition for storing XML data history and the like. (Birth date | date of establishment) means either the date of birth or the date of establishment. For individuals, the former, for corporations, the latter. The Bank is the entity that uses this supplier system, and the Company is a customer. Examples of XML data for the essential item I are shown in FIGS.
[0084]
In the example shown in the figure, the tag is written in full-width Japanese for ease of understanding, but the software and programs are easy to handle alphabets and numbers, so in fact, English notation or Japanese Roman notation is used. Use it.
[0085]
In a preferred example, when thestorage control unit 10 receives a storage command for the history of the relevant item data, thestorage control unit 10 updates the basic attribute data with the RDB data from the other system and updates the basic attribute. A historystorage control function 78 that controls to store I data as history data of the essential item I is provided. The essential item I deals with items that are updated with the latest information such as officers, business details, and manufactured products. For this reason, the historystorage control function 78 stores the history of the requirement I data for the business partners whose requirement I data has been updated during the year at a frequency of once a year or the like. In order to manage the history of the essential item I, the history creation date is defined as an element of the XML data itself in the history of FIG.
[0086]
In addition, when a supplier requirement is attached as a basis for self-assessment, since the supplier requirement at the time of the assessment is required, the historystorage control function 78 is configured to send RDB data in response to a request from another system. And the data may be transmitted to another system using a function of storing the current item I data and item II data as a history. However, since the essential point II is for managing the trend of business partners based on the date of occurrence, it itself is the latest data and is a history. For this reason, there is almost no reason to create a history with a certain frequency.
[0087]
Referring to FIG. 11, the CIF number and the date of occurrence are a fixed-length numeric string without a break. In this embodiment, the XML data does not include a hyphen or the like, and a hyphen is inserted in the GUI definition as a kind of display data type. In yoko2.dtd, the supplier requirements have a unique CIF number and one or more supplier trends in parallel. Specification of document type by tag starts with <tag name> and ends with </ tag name>. This tag is defined by overlapping according to the hierarchy. For example, the main trend classification code belongs to the supplier trend, and the supplier trend belongs to the supplier guideline II. This hierarchy can be managed by a DOM tree having a tree structure. The relationship between the main trend category codes and the main trend category names is as shown in FIG.
[0088]
Referring to FIG. 12, the XML data of the supplier requirement I is updated after the CIF number. This order is the order in parentheses that defines the child element of the element of the supplier requirement I in FIG. The customer following the renewal is omitted here. The title subordinate relationship codes and the names of officers and the like are a list of relationships between the Company (business partners) and officers in advance, and FIG. 21 shows an example. For representatives, etc., the representative right presence /absence code 1 is present, and is 0 when there is no representative right. Not only the representation right but also the same handling in which all presence codes are set to 1 or 0 may be used.
[0089]
FIG. 14 to FIG. 20 are explanatory diagrams illustrating examples of screens of supplier requirements I. In the essential point I, two sections (pages) of an organization and a business are defined, and transitions are made by tabs. As the contents of the essential I data, the organization section that displays the contents of the organization, contact information, shop name, number of employees, officers, etc., accounting staff, bankers, capital, major shareholders (large investors), business facilities, related It has tables for loan name identification, other related parties, accounting offices, bank affiliated company usage status, and securities holding status. The business section for displaying the business content includes tables of average monthly sales, business content, manufactured products, special notes, fund settlement, sales destination, supplier, and homepage address. The special notes are comments on the business contents and the characteristics of the manufactured products, and comments on the status of the industry.
In the example shown in FIG. 14 and the like, the items that can be input and the entire update date are February 10, 2002, and the update date of data acquired from theRDB 56 is the end of the month before February. Day. About the essential point I, if the page of an organization and the page of a business are scrolled, the general general condition of the business partner can be grasped. For this reason, it can be handled that the updater is not the updater for the changed or added item, but has confirmed the entire essential item I data on February 10.
[0090]
The DTD hierarchy and the screen display hierarchy are different. The element definition of DTD is not a semantic content system, but collects data acquired from the RDB as a customer, and collects data related to an input customer as a customer or the like. The DOM tree is generated at the DTD hierarchy. In the presentation layer, that is, the displayediting control unit 8 may edit the data of the DOM tree structure into the above-described screen display system, and handle the data as screen display data in an array or the like. For example, an EJB that processes each table reads out necessary items from the DOM tree. In this embodiment, the average monthly quotient of the business partner is used in the average monthly quotient table, the business content table, the manufactured product table, and the sales destination table. Then, thestorage control unit 10 constructs a DOM tree from the array or the like for the data displayed on the screen and edited, and stores the data in theXML data DB 54 after verifying the validity.
[0091]
Since A Sangyo Co., Ltd. is a corporation, the name of the shop name cannot be entered. Fields that cannot be entered should be grayed out. Here, the upper left and lower right diagonal lines of the field (box for inputting each item) indicate that input is not possible. A black circle is added to the upper left of the CIF number field. This black circle indicates that the field is a derivation item. When you enter the CIF number of the president, such as an officer, your name and date of birth are derived. The derivation destination field is grayed out because it cannot be entered. This table of officers and the like is displayed for five records. However, when data of six or more records is registered, the sixth and subsequent contents can be referred to by operating the right slider.
[0092]
In a preferred example, the displayediting control unit 8 identifies a natural person such as an officer of our company when a business partner is our company, and a corporate or business individual such as a major shareholder (large investor) of the company and a sales destination. When the CIF number is managed as an arbitrary input item and the CIF number is input, the CIF numberinput support function 70 for deriving the name item and address item of the table from the CIF number as a derivation source is provided. Good.
[0093]
In the example shown in FIG. 14, since Shiro Osaka does not have a CIF number as a managing officer or the like, his / her name is directly input. In normal RDB, it is not possible to permit entry of items in the table without inputting a key value such as a CIF number. However, in this embodiment, the data structure is XML, and each item can be arbitrary. On the other hand, when a CIF number is input, derivation can be performed. By separating the definition of the tag system based on DTD and the business logic of derivation, the CIF number can be an optional input item, and flexible handling of derivation when input can be performed.
[0094]
In a preferred example, the displayediting control unit 8 may include a dependencyrelationship management function 72. The subordinaterelationship management function 72 includes the position items of the officers of the business partners, the relationship items between the business partners and the major investors in the business partners, and the related items between the related lenders and other related business partners. The input of each item is managed using a dependency relationship code indicating the relationship to be used. Since the relationship between the individual or the corporation related to the business partner is registered using the dependency relationship code, the lateral search can be performed precisely. In the table of officers and the like shown in FIG. 14, the title can be selected by a combo box. In this case, among the dependency relationship codes shown in FIG. 21, items whose positions are flagged are set as position dependency relationship codes. The combo box prompts you to select from the list. A combo box is indicated by placing a downward black triangle in the field. In the combo box, contents other than the list cannot be input, so the information can be made uniform. Even in a combo box, a value can not be input according to the definition of DTD.
[0095]
The dependency codes shown in FIG. 21 are systematized in a certain order with the president, chairman, and vice chairman. A plurality of records for the same element of XML have no concept of sequence number or order in the DTD in the present embodiment. In the present embodiment, positions such as officers are coded, and the numbers of the dependency relationship codes are given in the order to be displayed. The arrangement of records of officers and the like (a plurality of identical elements in the XML data) is arranged in ascending order of dependency code. That is, in the present embodiment, the displayediting control unit 8 includes a dependency code sorting function 74 that rearranges the records in the post column based on the value of the dependency relationship code. Accordingly, the items can be displayed in a predetermined order instead of the order of input and registration, and the visibility of items can be improved without assigning a sequence number or the like for each item. Then, when a senior managing director becomes the president, only the position column is reselected, and the display is updated to the optimum order by the sorting function 74 for each dependency code. This sort is a server function when performed by the server-side EJB, and a terminal function when executed by a terminal-side applet. In the example shown in FIG. 14 and the like, the sorting function 74 by dependency relationship code sorts the items in each table according to the dependency when the registration button is pressed.
[0096]
In the example shown in FIG. 21, the dependency relationship codes are flagged with corporations, individuals, and positions. Thereby, it is possible to have separate code systems for the subordinate relationship in the case of a corporation, the subordinate relationship in the case of an individual business owner, and the case of a position subordinate relationship. In this example, the displayediting control unit 8 may include a dependencycode generation function 76 that generates a dependency code for the personality according to the personality of the supplier.
[0097]
In the example shown in FIG. 15, the shareholding ratio is derived from the total and the number of shares held by each shareholder, with the number of shares held by the major shareholders (large investors) as the derivation source. This derivation is performed by EJB. In the example illustrated in FIG. 16, name management of related loan destinations is performed. At this time, the dependency code is used in relation to the Company. Since A Sangyo Co., Ltd. is a corporation, this relation is selected from the subordinate relation codes in which the corporation flag is 1 among the subordinate relations shown in FIG. Related loan name identification (group name identification) is useful for managing credit risk, ascertaining the details of guarantees, and identifying parties that are substantially the same. Particularly in this embodiment, since the correlation is organized using the dependency relationship code, the accuracy of credit risk management for the entire group can be improved. In addition, if the relationship between the Company and A Opto Device is a subsidiary, the A Op Device related lender can automatically add the opposite concept of the subsidiary to the A industry.
[0098]
The other related parties shown in FIG. 17 are, for example, companies that have no business with the Bank but are related to the Company. The Company's shares owned by the Bank in the case of securities holdings are cases where the entity using the supplier's requirements system owns the shares of the counterparty, and vice versa.
[0099]
In the business section shown in FIG. 18 and FIG. 19, the composition ratio of the business content is derived from the business content, the average monthly quotient for each business content, and the average monthly quotient total. For example, when the payment is made on the payment deadline, the payment is closed on the last day of the current month, and the payment is made on the 15th of the following month. The reason why there are two columns is that there are two settlement months in cases where the payment date differs depending on the counterparty or where the settlement is made twice a year (six months settlement). In the fund settlement in FIG. 10, thepayment deadline month 1 / division code is a code representing the current month in the left column of the fund settlement table in FIG. 18, and thepayment deadline month 1 / month division name is, for example, the current month. In the example shown in FIG. 18, thebonus payment month 2 month code is 12, and thebonus payment month 2 month is December.
[0100]
19 and 20, the CIF number is an optional input item, and when it is input, it is used as a derivation source for the name, address, loan number, and the like. The main transaction store is derived from the loan number. The displayedit control unit 8 derives the component ratio when the average monthly quotient for each sales point as viewed from the Company is input. The cash ratio is the value of what percentage of the deposits for sales is cash. Similarly, for the supplier, enter the cash ratio of the average monthly sales sold to the Company from the supplier within the range that the user knows. From the relationship between the average monthly quotient of this purchase, the cash ratio, and the fund settlement date, the demand for funds in January can be obtained. When the payment date is also registered as the fund settlement date, it is possible to analyze the cash flow and propose an optimal fund procurement. In addition, this actual situation can be referred to when calculating a normal working capital in the asset assessment.
[0101]
FIG. 22 is an explanatory diagram showing an example of display mode transition. As shown in FIG. 22, the displayediting control unit 8 disables input and editing of thereference mode 80 in which all items cannot be input and edited, and the items acquired from other systems and the derivation destination items. An editing mode that allows entry and editing of items, and a confirmation mode that prompts confirmation of registration with the displayed contents while sorting and displaying the contents of each table according to the editing result in theediting mode 82 in the essential item I 84. In the essential point II, a confirmation message 85 for prompting confirmation is displayed before registration or deletion.
[0102]
When the user logs in to the supplier requirement system or the loan support system including the same, the user inputs the CIF number and selects the requirement I or II. FIG. 23 is an explanatory diagram showing the relationship between the edit button to be displayed in each edit mode and the processing contents when an event of pressing the button is received. For example, select item I and press the open button. Then, a transition is made to the reference mode of item I. In the reference mode, a return button for transitioning to the selection screen, a point II button for transitioning to the reference mode of the point II, and an editing button for transitioning to the edit mode are handled. The edit button is displayed only when the user has editing authority, and the item II button is also displayed only when the user has the reference authority of item II. In the edit mode, gray-out is canceled for fields that can be input, enabling input and editing. When the back button is pressed, the edited content is discarded and the screen shifts to the item selection screen. When the registration button is pressed down in the edit mode, sorting is performed, and a transition is made to a confirmation mode in which the edited content is displayed on the screen in an uneditable state. In the confirmation mode, an inquiry is made as to whether or not registration is possible. When the Yes button is pressed, after confirmation in a confirmation dialog box or the like, the entire item I data including the editing result is updated to the XML data DB. When the undo button is pressed, the editing mode is restored while maintaining the editing result so far. When the transition is made between the requirement selection screen, the requirement I, and the requirement II, the CIF number already input is taken over. Accordingly, when the point I is referred to and the point II button is pressed down, the reference point II of the same supplier is referred to.
[0103]
In the example shown in FIG. 14 and the like, there is a delete check box at the left end of each table. When the record to be deleted is selected in the edit mode and the check box is turned on, when the registration button is pushed down and the mode is changed to the confirmation mode, the displayedit control unit 8 selects the record in which the delete check box is turned on. Delete and display on screen for confirmation. If registered in this state, the checked record is deleted.
[0104]
FIG. 24 is a flowchart showing an outline from user login to display of essential data on the terminal. The supplier requirement system identifies the worker who has logged into the supplier requirement system based on the user ID (step S11). The user inputs the CIF number, selects item I or II, and depresses the open button (step S12). The authority to refer to the supplier requirements is confirmed from the user ID or the like (step S13). If there is an authority, data such as the basic attributes of the supplier is acquired from theRDB 56 for the supplier having the CIF number (step S14). Before and after this, XML data is fetched from the XML data DB (step S15). Further, display control of buttons according to the user authority is performed (step S16), and the screen definition file based on the GUI definition and the captured data are combined and displayed on the terminal 1 (step S17).
[0105]
In the example of controlling whether or not editing is possible according to the authority of the user, the displayediting control unit 8 refers to the essential points I and II based on the relationship between the store number of the user and the store number of the partner store. A buttondisplay control function 90 for controlling display and non-display of an edit button for transmitting a message requesting a transition from the mode to the edit mode to the server is provided. FIG. 25 is an explanatory diagram showing an example of authority setting according to the relationship between the user's affiliated store number and the business partner's business store. The transaction store is a main transaction store or a transaction store when there are a plurality of transactions. The other store is a case where the store to which the user belongs is neither the main store nor a multi-transaction store. The headquarters is a review, audit, secretariat and other headquarters organizations. In the example shown in FIG. 25, only reference to the essential point I is permitted in the case of another store. Accordingly, the item II button is not displayed in the item I reference mode. The person in charge at the store can edit and delete items that are not allowed to be input by the GUI definition or the like. However, since the trend of suppliers is not intended to be deleted, a certain authority is required to delete the trend of suppliers. The headquarters can only refer to the essential points I and II.
[0106]
In the example in which the access control shown in FIG. 25 is performed, the displayediting control unit 8 may include anaccess control function 92 for each other store. Theaccess control function 92 for each other's own store stores the required item I data and the required item II data when the store number of the user is the same as the store number of the customer's store (the main store and the store in the case of multiple transactions). Allows browsing and editing. On the other hand, theaccess control function 92 for each other's own store permits the reference of the essential item I data and permits the editing of the essential item I data and the essential item II when the store number of the user is different from the store number of the transaction store of the customer. Disallow data browsing and editing.
[0107]
FIG. 26 is a flowchart illustrating an example of processing for determining user authority. When the supplier requirement system identifies the worker who has successfully logged in (step S21), it subsequently checks whether or not the supplier has a loanee number (step S23). Since the supplier requirements system accumulates information on suppliers who have loanee numbers that can specify dealer information, suppliers who do not have loanee numbers are not subject to the preparation of the guidelines. . The store information includes a store number or the like that identifies one or a plurality of business stores (transaction stores) that conduct business with the business partner. Further, in the case of accumulating information on a destination with no transaction record such as a prospective customer, a loanee number is assigned to the prospective customer or this step S23 is reviewed. Subsequently, the store to which the user belongs is confirmed (step S24). If you are a headquarters user, you can only refer to it. On the other hand, in the case of a store, first, it is confirmed whether the selection of the essential item is I or II (step S25). In the case of the essential item I, when the store number of the user belongs and the store number of the customer's transaction store match, the edit button is displayed (step S27), the reference and the edit are permitted, and the reference mode screen of the essential item I is changed. To do. Under this condition, since reference and editing of the essential point II are permitted at the same time, the basic item II button is also displayed. On the other hand, in the case of inconsistency, since it is another store, only reference is permitted while editing is not allowed. In this case, the reference item II button is not displayed because reference to the item I is not permitted.
[0108]
In the case of the essential point II, it is confirmed in step S28 whether or not it is another store, and if it is another store, reference is also impossible. Therefore, the transition from the supplier requirement selection screen to the requirement II screen is not performed. On the other hand, if the user's affiliation is a main store or a store with multiple store transactions, an edit button is displayed (step S29), reference and editing are permitted, and a transition is made to the reference mode screen of item II. . Under this condition, the reference I button is also displayed because reference and editing of the guideline I are permitted at the same time.
[0109]
Next, a lock for preventing data inconsistency due to multiple writing to the XML data DB or the like will be described. In this example, the server permits simultaneous multiple references by a plurality of users for the same business partner, and performs exclusive control in edit mode so that a plurality of users do not enter the edit mode for the same business partner at the same time. A lock control unit 94 is provided. As shown in FIG. 22 and the like, in this embodiment, reference and editing are clearly separated. Even if many users refer to it at the same time, there is no need to lock it because writing is not performed. On the other hand, if one user transitions to the edit mode and then allows other users to edit, double writing occurs and one update is discarded. For this reason, in this embodiment, while permitting multiple access for reference, the edit mode is registered in the confirmation mode or locked in units of CIF numbers until editing is interrupted by returning to the selection screen. It was.
Since the edit mode is clearly defined and all edits such as addition, update, and change are disabled at the time of reference, exclusive control can be performed when transitioning to the edit mode and at the time of registration after completion of editing. In this embodiment, by handling the access from the other system to thedata storage unit 3 of the supplier requirement system in the same manner as in the reference mode, complicated processing such as exclusive control between systems and design such as database duplication are avoided. be able to.
[0110]
Further, in a Web application using J2EE or the like, it can be assumed that a terminal such as a PC crashes, the session with the terminal is forcibly disconnected, and only the state where the lock is secured remains in the server.
[0111]
In the example illustrated in FIG. 8, the lock control unit includes a lock acquisition control function 96, a lockrelease control function 97, and a lock availability determination function 98. In this example, it consists of the CIF number of the business partner, the user ID of the user who acquires (acquires) the lock, the start time which is the current time, and the end time obtained by adding the predetermined maximum lock time to the start time. Lock management information is stored in the RDB, and the lock management information is referenced to determine whether or not lock is possible. At this time, the lock management information is used to determine whether or not the user is locked, and when the maximum lock time has elapsed, the lock is forcibly released without any operation from the terminal. Thus, confusion due to the forced termination of the terminal can be avoided.
[0112]
The lock availability determination function 98 indicates that the lock end time of the lock management information identified by the CIF number of the business partner to be determined for lock is later than the current time, and the user ID in the lock management information is If they are different, it is determined that the lock has been acquired.
[0113]
Specifically, as shown in FIG. 27, when the lock acquisition control function 96 shifts to the edit mode (step S41), the lock is acquired by the other users in the main item data of the supplier of the CIF number. It is determined based on the lock management information (step S42). If the lock has not been acquired, after confirming that there is no own lock management information (step S43), the lock management information is written (step S44). If there is own lock management information, the end time of the lock information is updated (step S45).
[0114]
If there is a locked user in step S42, the user IDs in the lock management information are compared to confirm whether or not the user is himself. If the terminal is forcibly terminated and the edit button is pushed down after the restart and before the lock end time, the terminal is locked. If it is own lock, the lock information is updated (step S50), the XML data is locked, and the edit mode is started.
[0115]
Following step S44 or S45, the lock information is checked again, and it is determined whether there is another user who has written the lock information at the same timing. When the other party reads the lock information in step S42 between immediately after step S42 and the completion of step S44, there is another user. In the opposite case, there are other users who precede. If there is no other user, the lock is acquired and the mode is changed to the edit mode. On the other hand, if there is another user, the user with the earlier lock start time or the other user is selected by other methods (step S47). If another user is selected, the lock end time is updated and the lock is released (step S48). In steps S48 and S49, if another user has already acquired the lock, editing may be disabled and a message indicating that multiple access has occurred may be displayed on the terminal.
[0116]
As shown in step S28, the lockrelease control function 97 locks the entire contents of the CIF number's business partner data by another user when the edited contents are registered (steps S61 and 62). Is determined based on the lock management information (steps S42 to S50). If the lock has not been acquired (step S63), the registration process is permitted and the end time of the lock management information of the CIF number is updated to the current time after registration (step S64). On the other hand, if the lock has been acquired by another user and the lock is impossible, the editing result cannot be registered, and the editing is interrupted by a return button or the like. At this time, a message indicating that multiple access has occurred may be displayed on the terminal. If it is determined in step S62 that the interruption has occurred, the lock end time is updated to the current time, and the lock is released.
[0117]
FIG. 29 is an explanatory diagram showing an example of the GUI of the supplier essential point II. The GUI of the essential item II displays the trend comments in a time series and the supplier trend table 100 that cannot be changed only by display, the existing trend comments in the reference mode, and the existing trend comments in the edit mode. A display / input /edit area 102 is provided as an input work area for editing and new trend comments. Since the supplier trend is not character data to be edited in principle, the supplier trend table 100 does not allow editing. New trend comments are entered in the display / input / edit area.
[0118]
  FIG.9As shown in FIG. 5, in the edit mode in the essential point II, clear, add, change, and delete buttons are arranged in the vicinity of the display / input /edit area 102. When the user inputs the date of occurrence, selects the main trend category, fills in details (trend comments) and presses the add button, the contents entered in thearea 102 are reflected in the supplier trend table. FIG. 30 shows a state in which the confirmation message regarding whether to reflect is registered by depressing the Yes button and the mode is returned to the reference mode. Thisarea 102 is also used for displaying a portion that cannot be displayed in the supplier trend table 100.
[0119]
In the supplier trend table 100, records of supplier trends are sorted using the date of occurrence as a sorting key. For this reason, for example, when major trends in several years ago are identified and comments about the trends are entered, the date of occurrence is set to be several years ago, so that the date of occurrence is independent of the entry / registration order. Sorted in order. XML data is generated and stored in this rearranged state.
[0120]
Even within a branch, you may get information that should be limited to the person in charge and their supervisor. For example, information such as executing M & A on a date that is coming soon needs to be handled with care. On the other hand, at the moment of the announcement date, various actions are required. In such a case, if the date of occurrence is registered as a future date, the date is set as the ban date, and the date is displayed when the date is reached, the main points are already on the same day. And can use the information immediately within the organization. Requirement II in the supplier requirements system is for registering important business trends that have occurred in the past. As an exception to the mechanism for registering past results, a mechanism such as ban is introduced. If the displayedit control unit 8 inputs a future date in the display / input /edit area 102 and registers trend comment data on the future date, the displayedit control unit 8 applies to a user group that is not permitted by the user or the like. Regarding the display, a ban prohibition designationregistration control function 99 is provided which performs control not to display a trend comment on the future date until the future date arrives.
[0121]
FIG. 31 is a block diagram illustrating an example of a supplier requirements system including an analysis control unit. In this example, the server stores a tagsystem definition file 50 that defines a tag system in the markup language (ML) for the requirements of the business partner, and XML data that stores tagged data for each business partner tagged with ML.Data storage unit 3 for storing theDB 54 and the organization and business of the business partners defined by the tagsystem definition file 50 and the essential data on the related items such as the sales customers and / or suppliers of each business partner A displayediting control unit 8 that controls display and input on theterminal 1 in accordance with the GUI definition file 52 is provided. For items related to sales partners, etc., for business partners where both sales and suppliers are registered, in each of the items in both tables, only one of the customers or suppliers is registered. Is an item in one of the tables. That is, when referring to a sales destination and / or a supplier, it is both or either one. The server also includes astorage controller 10 that converts the item data into tagged data based on the definition of the tag system, and stores the tagged data in theXML data DB 54 as integral item data.
[0122]
In the example shown in FIG. 31, in particular, the server extracts information related to the relationship between the business partners from the essential data stored by thestorage control unit 10 using the item of the related item such as the seller as a search key. It has. The analysis control unit generates analysis data by lateral search using the item data accumulated using the supplier item system shown in FIG. 1 or FIG. The essential data is a collection of character data and codes whose meaning is defined by the tag hierarchy definition, and is therefore a basic material for credit risk management, business promotion, new service development, and the like. Conventionally, in the example where the supplier's guideline was described in the form, due to problems such as the storage location of the form paper, it was used for work such as extracting a certain business partner across sales offices and analyzing the relationship between business partners Took a lot of work. In the example shown in FIG. 8 and the like, the essential item I data can be accessed at both the own store and other stores, so that analysis across sales offices can be easily performed.
[0123]
In the example shown in FIG. 31, related items such as sales destinations are particularly useful in the tag system and GUI definition shown in FIGS. 9 and 14. That is, as the tag system, the CIF number of the subject matter itself, and the CIF number of the seller etc. when the seller and / or supplier (seller etc.) are attached, If the CIF number is not attached to the seller, etc., the name or name and address of the seller, etc., and the sales amount or purchase amount for each seller, etc. regarding sales or purchase to the seller, etc. It is good to have. Here, the CIF number is a unique number that uniquely identifies the customer and the name or name and address.
[0124]
In the example illustrated in FIG. 31, the analysis control unit 110 includes a general-purpose search function 114 that searches for a dependency relationship of a business partner in a search target range using a CIF number, a name, a name, and an address as search keys. The general search function 114 may use thegeneral search system 48 of theother system 40. In this case, the essential data is transmitted to the general-purpose search system 48 and the search is performed by the general-purpose search system 48. When general-purpose search based on supplier requirements data becomes possible, if there is a sudden increase in the credit risk of the bank's business partner or a party without business with the bank, there is a transaction with a party whose credit risk has suddenly increased. Customers can be extracted. For example, it is possible to extract a list of business partners who are dealing with credit risk increased or a related business partner. Traditionally, if you are in a fund settlement route such as currency exchange, you could grasp to some extent where the credit risk increased and where the transaction was, but it is difficult to identify with funds settlement data, and it is accurate and broad extraction It was difficult. In the example shown in FIG. 31, a general search can be performed based on a CIF number when there is a CIF number, and based on character data such as a name or name and an address when no CIF number is input. Higher accuracy and wider extraction are possible. The ratio of the average monthly sales of sales may also be used as a secondary search key.
[0125]
As an example of general-purpose search in relation to sales promotion, for example, high-quality companies that do not have business with the Bank have no supplier requirements, and it is difficult to grasp the business relationship, but the above-mentioned companies are in the sales destination of the requirement I By searching for the destination, it can be used for bill discount promotion. In addition, when a certain customer has a “PC display” for a manufactured product, it is also possible to search for a destination having “PC display” data for the product name of the supplier and use it for business arrangement.
[0126]
FIG. 32 is an explanatory diagram showing an example of a correlation diagram of sales / purchase relationships of business partners. In this example, the industry A shown in FIG. In order to generate the correlation diagram as shown in FIG. 32, the analysis control unit includes a correlationdiagram generation function 116. Thisfunction 116 extracts sales / purchase relationships between business partners in the search target range based on the CIF number of business partners and the contents of related items such as business partners. The same sales destinations are aggregated, and a definition file illustrating sales / purchase relationships is generated.
[0127]
FIG. 33 is a flowchart showing an example of correlation diagram generation processing by the correlationdiagram generation function 116. Here, the industry A shown in FIG. 14 and the like is set as the first hierarchy, and the purchase / sales relationship is extracted for three hierarchy levels. In correspondence with FIG. 32, the correlationdiagram generation function 116 first reads out the name of the target customer, the type of business, the group name of the related lenders, the main transaction store, the average monthly quotient, payment related information, and the like (step S81). . In the example shown in FIG. 32, the correlationdiagram generation function 116 is centered on the name of the industry A, and the supplier box in which the group name is located in the upper left, the main trading store is located in the upper right, the industry name is located in the lower left, and the average monthly sales is placed below it. Is generated. In addition, since the payment has items such as a closing date and a payment date, payment related information is added to the upper left of the business partner box when it is input to the essential item I data.
[0128]
Subsequently, the correlationdiagram generation function 116 extracts the direct sales destination of the A industry as the second hierarchy (step S82). In the example shown in FIG. 32, only the B industry corresponds to FIG. Since B industry was extracted for the first time in this process (step S83), the sales / purchase relationship, the composition ratio of the average monthly quotient, and the product name are defined for drawing. For example, the source of the arrow is the supplier, the end of the arrow is the purchaser, and the product name and the composition ratio of the average monthly quotient are placed at the end of the arrow. In the example shown in FIG. 32, the sales of the A industry to the B industry are printed circuit boards, which is 50% of the average monthly sales (4,000 million yen). In FIG. 32, the arrows on the right side of the supplier box are other values in the component ratio items of the supplier table and the seller table.
[0129]
Subsequently, the extraction of the seller and the supplier is repeated through the loop of steps S86 and S87. When the extraction of the second tier (B industry,sales 2 and sales 3) of the A industry sales destination and the second tier (purchasing 1 and purchase 2) of the supplier is completed, whether or not all the tiers are completed Is confirmed (step S88). Here, in order to extract up to the third hierarchy, the first supplier among the sales and suppliers of the second hierarchy already extracted in step S89 is the target supplier. For example, with thepurchase 1 as an object supplier, the business type code of thepurchase 1 is read (step S81), and the sales destination is further extracted (step S82). Except for the A industry, the description of the average monthly sales etc. in FIG. 32 is omitted. Assuming that A industry is stored as the sales destination of the item I data of the purchase 1 (s1, first supplier), the A industry has already been extracted, and is collected in step S84. When the purchase 2 (s2) is extracted, it is assumed that the A industry is not stored as the sales destination of thepurchase 2. In this case, the arrow from thepurchase 2 to the A industry may be a dotted line or the like on thepurchase 2 side. Thepurchase 2 has thesale 1 of the purchase 2 (s2b1,buyer 1 of the supplier 2) as the sale.
[0130]
When the extraction of the second-tier supplier is completed, the second-tier sales destination is subsequently extracted. If industry A is stored as a supplier in the essential data I of industry B (b1, the first of buyers), it is collected in step S84. As a supplier of B industry, “b1 ss2 (supplier 2 of buyer 1)” and the like are extracted in addition to A industry. In the example shown in FIG. 32, the suppliers of the B industry are the same as the suppliers of thepurchase 2 and are therefore consolidated. Subsequently, information on the third hierarchy is extracted. The supplier (S1_1) ofPurchase 1 did not have a CIF number and had no information. One of the customers of B Industry is a general company. In addition, one of the customers of purchase 1 (s1) was Group A. When the extraction and aggregation processing is completed for all layers, the correlation definition file is written out, editing with other application software is urged, or direct drawing or printing is performed (step S90).
[0131]
When the correlation diagram illustrated in FIG. 32 is generated by the processing shown in FIG. 33, etc., from the relationship of the composition ratio of the average monthly sales among the business partners, the business position of the business partners and the target business partners for the sales business Can be confirmed. As shown in FIG. 32, when a correlation diagram is generated according to a distribution route centering on a certain customer, the supply chain of the manufactured product is clearly indicated, and a proposal for cost reduction can be made. Furthermore, it is possible to grasp the fund demand schedule for accounts receivable and the like based on the average monthly quotient, the composition ratio, and the payment due date and payment date information. In this case, a cash ratio or the like may be used in combination. Further, payment for sales, payment date for each payee (supplier), and the like may be handled. In this way, when paying attention to the flow of funds, the direction of the arrow in the correlation diagram is the same as the flow of funds, and is the opposite direction to the example shown in FIG. Good.
[0132]
The correlation diagram makes it clear at a glance which business partners need and how much working capital is needed, and makes it easier to carry out the contents of business promotion appropriate for the business partners considered. Further, since the same business partners are aggregated using a CIF number, a name or a name, etc., it is possible to visually grasp the actual state of the business. In addition, if the correlation diagram shown in FIG. 33 is grasped, it is possible to immediately grasp the influence or the like when the credit risk of a certain supplier suddenly increases.
[0133]
As shown in FIG. 32, the search range of the correlation diagram is a purchase / sales hierarchy in several stages from a focused business partner, a group relationship in a certain industry is extracted, and a relationship from a certain raw material to a final product is expressed. Various correlation diagrams according to various purposes, such as extraction, can be generated from data organized and stored in the supplier requirements system. For example, when there is a raw material with a large price movement, by grasping a series of distributions and correlations of business partners who use the raw material as a product, we investigate in advance the impact of changes in the surrounding situation, such as a sharp rise in raw material costs. , Credit risk management accuracy can be dramatically improved.
[0134]
Referring to FIG. 31 again, thedata storage unit 3 includes anRDB 56 that stores basic attribute data such as a CIF number, a name, a name, and an address that are updated every other period in another system. When the CIF number is input to the record of the table for registering the corporation, the individual, or the private business owner displayed on theterminal 1, the displayediting control unit 8 refers to the basic attribute data and stores the CIF number. A CIFnumber derivation function 70A for deriving basic attributes to corresponding records is provided. As a result, in the supplier essential data, the name and address of the supplier can be updated at the same time centering on the CIF number, and therefore, the aggregation process for creating the correlation diagram is facilitated.
[0135]
In addition to the essential I and essential II data, the essential data includes the loan policy that indicates the Bank's policy regarding future loans, and the general search function 114 enables the extraction of the destinations that have a certain loan policy or more. Also good. In order to make the extraction and search by the analysis control unit 110 precise and useful, the main trend in which the displayediting control unit 8 explicitly classifies trend comments describing major trends using the major trend classification code. Adivision management function 16A may be provided. This facilitates the extraction of business partners that fall under the main trend category of trend comments. For example, we extract business partners of a specific industry with entries in major trends related to overseas business, and immediately after arriving at a certain sales office, changes in directors, etc. It is possible to perform processing such as extracting a list of business partners in which comments are entered.
[0136]
The displayedit control unit 8 uses the dependency code in the table of the officers of the organization, affiliated companies, major shareholders (major investors), sellers of the suppliers, suppliers, etc. In the example provided with the dependencyrelationship management function 72 that prompts the classification, it is possible to execute a detailed search using the code with more detailed correlation diagrams and influence levels.
[0137]
【The invention's effect】
  The present invention according toclaim 1 is a trend comment that expresses a main trend of a business partner by means of a sentence.dataMajor trend categories that explicitly categorize contentName andcodeIs selected, This main trend classification code with other systemsNoInterface(Or protocol)ToFor, Trend commentsdataConsolidation and structuringFor users and other systems using main trend category names and codesClear andCanIn addition, the accuracy of the horizontal search can be improved. further,By DTD definition and verification process by XML parser,Trends not classified into major trendsClimbingBy disabling recording, regardless of the skill level of the person in charge,RecordThe granularity of the trends to be posted can be forced to be constant,Devise a list of major trends,By always using the main trend classification, it becomes clear to select important trends to be registered among various trends of the business partners. Therefore, the person in charge at the store, etc.(user)Because it is compulsory to understand and memorize the system of the main trend categories by operating the system according to the present invention, it is possible to ask questions etc. arranged to suppliers, and to describe important trends It is possible to prevent variations from being made by a person in charge such as leaks and detailed descriptions of trends that are not necessarily important. Therefore, major trend zonesBy selecting and accumulating minute names,The information accumulated as the supplier requirements is uniform, so that reports and handovers are clear, and data having a uniform granularity useful for various searches can be obtained.
[0138]
  Claim 2,4as well as5In the present invention according to,in frontWhen the trend comment data is displayed for each category type, the trend comment data of the main trend category code belonging to the category type is controlled to be displayed on the terminal. By providing a function for extracting and displaying only trend comments with codes attached, it is possible for the user to immediately visually grasp the supplier's history and points to be noted.
[0139]
  Claim3In the present invention,Because trend comment data is sorted and displayed according to the date of occurrence, it is possible to display, transmit, and store XML data that is highly visible and easy to handle in other systems while adopting XML technology. .
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating a configuration example according to a first embodiment.
FIG. 2 is an explanatory diagram showing the relationship of each system regarding handling of character data.
FIG. 3 is an explanatory diagram showing an example of main trend categories;
FIG. 4 is an explanatory diagram illustrating an example of a GUI for a trend comment.
FIG. 5 is an explanatory diagram illustrating an example of a trend comment type display;
FIG. 6 is a flowchart illustrating an example of trend comment type display control;
FIG. 7 is an explanatory diagram illustrating an example in which a trend comment of a business promotion type is associated with a main trend category of another type.
FIG. 8 is a block diagram illustrating a configuration example of the second embodiment.
FIG. 9 is an explanatory diagram showing an example of a DTD used in the present embodiment.
FIG. 10 is an explanatory diagram showing an example of a DTD following FIG. 9;
FIG. 11 is an explanatory diagram showing an example of xml data of the essential point II in the example shown in FIG. 9;
FIG. 12 is an explanatory diagram illustrating an example of xml data of the essential item I in the example illustrated in FIGS. 9 and 10;
FIG. 13 is an explanatory diagram showing an example of xml data following FIG. 12;
FIG. 14 is a view of a user view based on a GUI definition and the essential section I data corresponding to the xml data shown in FIGS. 11 and 12, contact information of an organization section, employees, officers, and accounting staff It is explanatory drawing which shows the example of a display of each table of.
FIG. 15 is an explanatory diagram showing a display example of each table of the bank originator, capital, and major shareholder (major investor) of the organizational block in the essential item I data.
FIG. 16 is an explanatory diagram showing a display example of each table of the business facility of the organizational section and the related loan destination name identification in the essential item I data.
FIG. 17 is an explanatory diagram showing a display example of each table of the other related destinations of the organizational block, the accounting office, the bank affiliated company usage status, and the securities holding status in the essential item I data.
FIG. 18 is an explanatory diagram showing a display example of each table of average monthly sales of business sections, business contents, special notes, industry status, manufactured products, and funds settlement in the item I data.
FIG. 19 is an explanatory diagram showing a display example of each table of manufactured products, sales destinations, and suppliers in the business section in the essential item I data.
FIG. 20 is an explanatory diagram showing a display example of each table of the supplier and the homepage of the business section in the essential item I data.
FIG. 21 is an explanatory diagram illustrating an example of a code system of a dependency relationship code;
FIG. 22 is an explanatory diagram showing an example of display mode transition;
FIG. 23 is an explanatory diagram showing a relationship between a button and processing contents.
FIG. 24 is a flowchart showing an overview from user login to display of essential data on a terminal;
FIG. 25 is an explanatory diagram showing the relationship between user authority and accessible display modes and the like.
FIG. 26 is a flowchart illustrating an example of processing for determining user authority;
FIG. 27 is a flowchart illustrating an example of lock permission determination processing and lock acquisition processing;
FIG. 28 is a flowchart illustrating an example of lock release processing;
FIG. 29 is an explanatory diagram showing an example of an edit mode in item II.
FIG. 30 is an explanatory diagram showing an example after registration in the essential point II.
FIG. 31 is a block diagram illustrating a configuration example including an analysis control unit.
FIG. 32 is an explanatory diagram illustrating an example of a correlation diagram generated by an analysis control unit.
FIG. 33 is a flowchart illustrating an example of processing contents of a correlation diagram generation function.
[Explanation of symbols]
1 terminal
2 network
3 Data storage
4 Supplier Guidelines System
6 Acquisition control unit
8 Display editing control unit
10 Storage controller
16 Major Trend Classification Management Department

Claims (5)

Translated fromJapanese

文字データを扱う端末及び他システムとネットワークを介して接続されたサーバーと、このサーバーによって処理されるデータを前記文字データを含むＸＭＬデータとして格納するデータ格納部とを備え、
前記データ格納部が、前記データの項目を階層化するＸＭＬの体系及びタグを定義したタグ体系定義ファイルであるＤＴＤと、前記端末での表示領域及び入力領域を予め定めたＧＵＩ定義ファイルと、前記ＤＴＤに従ってタグ付けされたタグ付きデータを前記文字データを含むＸＭＬデータとして格納すると共に前記サーバー及び前記他システムから検索されるＸＭＬデータＤＢとを備え、
前記サーバーは、前記端末に前記データを送信することで当該端末の表示領域に当該文字データを表示し、
一方、前記端末の前記入力領域にて当該端末のユーザーによって入力、選択又は編集されたデータを受信し、当該データに前記ＤＴＤによって定義されたタグ付けをし、ＸＭＬパーサーによる妥当性の検証処理をし、当該検証処理したＸＭＬデータを前記データ格納部に格納し、
当該サーバーが、前記他システムからの検索を許可する所定のシステムにおいて、
前記タグ体系定義ファイルは、前記ＸＭＬデータに対する前記タグ体系定義による前記ＤＴＤの要素として、
ＣＩＦ番号と、このＣＩＦ番号と並列で発生頻度が１回以上出現の取引先動向とを有し、
当該取引先動向は、発生頻度が１回出現の主要動向区分名称と、０回又は１回出現の動向コメントデータとを有し、
前記ＣＩＦ番号は、前記取引先を唯一に識別するデータで、
前記動向コメントデータは、前記文字データであって、前記取引先についての主要な動向を示し前記端末のユーザーによって入力又は編集される文章となった文字データで、
前記主要動向区分名称は、前記取引先の主要な動向を前記端末のユーザーに対して予め明示的に区分すると共に、予め定められた所定の区分種別に属する文字データで、
前記サーバーは、前記ＧＵＩ定義ファイルに従って、前記表示領域として、前記ＣＩＦ番号で特定される取引先毎に、前記主要動向区分名称と、前記動向コメントデータとの項目で当該データを表示するための取引先動向テーブル領域を前記端末に表示させ、
当該サーバーは、
取引先動向テーブルと、表示編集制御部と、主要動向区分管理部と、格納制御部とを有し、
前記取引先動向テーブルは、
前記取引先動向テーブル領域に表示するデータとして、又は、前記入力領域にて入力、選択若しくは編集されたデータとして、前記主要動向区分名称と、前記動向コメントデータとを有し、
前記主要動向区分管理部は、
前記主要動向区分名称を特定する主要動向区分コードの範囲を前記区分種別毎に記憶することで、前記各主要動向区分が属する前記区分種別を管理し、
前記表示編集制御部は、
前記データを前記端末の前記取引先動向テーブル領域に表示する際に、
前記ＸＭＬデータファイルから前記ＸＭＬデータを取り込み、当該ＸＭＬデータのタグに従って当該ＸＭＬデータを取引先動向テーブルに編集し、当該端末の前記取引先動向テーブル領域に当該編集した取引先動向テーブルを表示し、
前記端末のユーザーが前記入力領域に動向コメントデータを入力する際に、
前記主要動向区分名称を当該主要動向区分名称の一覧から当該ユーザーに選択させ、
前記端末の入力領域に主要動向区分名称及び動向コメントデータが入力、選択又は編集された際には、
当該データを受信して、前記取引先動向テーブルに編集し、
前記格納制御部は、
前記取引先動向テーブルのデータを格納する際には、
前記取引先動向テーブルの各データに前記各項目に応じたタグを付し、前記ＣＩＦ番号毎の取引先動向に関するデータが前記タグ体系定義に定義された階層及び出現回数となっているかを前記ＸＭＬパーサーにより検証処理し、当該データが当該タグ体系定義との関係で妥当性を有する場合に当該処理されたＸＭＬデータを格納することで、前記主要動向区分名称が前記取引先動向毎に１回のみ出現するＸＭＬデータを前記ＸＭＬデータファイルに格納し、
前記サーバーが、このＸＭＬデータファイルを、当該動向コメントデータについて当該主要動向区分名称又は主要動向区分コードを当該他システムとのインタフェースとし、前記他システムからの検索を許可する前記データベースに格納することで、当該動向コメントデータの他システムとの共有を制御することを特徴とする取引先要項システム。Comprising a connected servervia the terminal and other systems andnetworksthat handles character data, and a data storage unit for storing data to be processed by the server as XML data includingthe character data,
The data storage unit includes a DTD that is a tag system definition file that defines an XML system and tags for hierarchizing the data items, a GUI definition file that defines a display area and an input area in the terminal, An XML data DB that stores tagged data tagged according to DTD as XML data including the character data and is retrieved from the server and the other system;
The server displays the character data in the display area of the terminal by transmitting the data to the terminal,
On the other hand, data input, selected or edited by the user of the terminal in the input area of the terminal is received, the data is tagged as defined by the DTD, and validity verification processing by an XML parser is performed. And storing the verified XML data in the data storage unit,
Ina predetermined system in which the serverpermits a search from the other system,
The tag system definition file is an element of the DTD by the tag system definition for the XML data.
A CIF number and a trend of a customer whose frequency of occurrence appears at least once in parallel with the CIF number,
The supplier trend has a main trend category name that appears once and a trend comment data that appears zero or once.
The CIF number is data that uniquely identifies the customer,
The trend comment data is the character data, and is character data that has become a sentence that is input or edited by a user of the terminal indicating a main trend of the business partner,
The main trend category name is a character data belonging to a predetermined category type, in addition to explicitly classifying the main trend of the business partner in advance to the user of the terminal,
In accordance with the GUI definition file, the server displays, as the display area, a transaction for displaying the data in the items of the main trend category name and the trend comment data for each customer specified by the CIF number. Display the trend table area on the terminal,
The server
Hasa customer trend table, and a display editing control unit, and the main trend section management module, and astorage control section,
The supplier trend table is:
As data to be displayed in the supplier trend table area, or as data input, selected or edited in the input area, the main trend category name and the trend comment data,
The main trend category management department
By storing, for each category type, a range of major trend category codes that specify the major trend category name, managing the category type to which each major trend category belongs,
The display editing control unit
When displaying the data in the customer trend table area of the terminal,
Incorporating the XML data from the XML data file, editing the XML data into a customer trend table according to the XML data tag, and displaying the edited customer trend table in the customer trend table area of the terminal,
When the user of the terminal inputs trend comment data in the input area,
Let the user select the main trend category name from the list of major trend category names,
When the main trend category name and trend comment data are input, selected or edited in the input area of the terminal,
Receive the data, edit it in the supplier trend table,
The storage control unit
When storing the data of the supplier trend table,
A tag corresponding to each item is attached to each data of the supplier trend table, and whether the data related to the supplier trend for each CIF number has the hierarchy and the number of appearances defined in the tag system definition. When the data is validated in relation to the tag system definition by storing it with a parser and storing the processed XML data, the main trend category name is only once for each supplier trend. Storing the appearing XML data in the XML data file;
The server stores the XML data file in the database that allows the search from the other system using the main trend category name or the main trend category code for the trend comment data as an interface with the other system. And a supplier requirements systemfor controlling sharing of the trend comment data with other systems. 前記主要動向区分管理部は、
前記端末又は前記他システムに当該区分種別毎の前記動向コメントデータを送信する際に、
当該区分種別に属する前記主要動向区分コードを特定し、当該主要動向区分コードの動向コメントデータを前記取引先動向テーブルから抽出することを特徴とする請求項１記載の取引先要項システム。The main trend category management department
When sending the trend comment data for each category type to the terminal or the other system,
2. The supplier requirement system according to claim 1, wherein the main trend category code belonging to the category type is specified, and trend comment data of the main trend category code is extracted from the supplier trend table.前記ＤＴＤの要素として、主要動向区分名称と同一階層に１回出現の発生年月日を有し、
当該発生年月日は、前記動向コメントデータで示される当該取引先の動向が発生した年月日であり、
前記取引先動向テーブルは、前記取引先動向テーブル領域に表示する項目として前記発生年月日を有し、
前記入力領域が、表示・入力・編集エリアとして、前記ユーザーに前記主要動向区分名称のリストからの選択を促す主要動向区分名称のコンボボックスと、前記発生年月日の入力を促す発生年月日エリアと、前記動向コメントデータの入力を促す詳細エリアとを有し、
前記表示編集制御部が、
前記端末に表示する編集ボタン又は登録ボタンへの操作を受信して、当該端末の表示モードを変遷させ、
当該表示編集制御部は、前記表示モードとして、前記取引先動向テーブルへの入力及び編集を不可とする参照モードと、前記取引先動向テーブルへの入力及び編集を許可する編集モードと、当該編集モードでの編集結果で前記取引先動向テーブルの内容をソートして表示を行うと共に当該表示した内容での登録の確認を促す確認モードとを備え、
前記詳細エリアは、前記参照モードでは既存の動向コメントデータを表示する領域とし、前記編集モードでは既存の動向コメントの編集及び新たな動向コメントの入力作業領域とし、
当該表示編集制御部は、
前記参照モードでの表示に際して、前記編集モードへ変遷するために操作される編集ボタンを表示し、
編集モードでの表示に際して、前記確認モードへ変遷するための登録ボタンを表示し、
当該表示編集制御部は、
前記編集モードにて入力及び編集された取引先動向テーブルを前記発生年月日をキーとしてソートし、入力編集不可で前記ユーザーへの確認のために前記端末に表示し、
前記格納制御部は、当該ユーザーによって確認された際には、当該ソートした順序で格納することを特徴とする請求項１又は２記載の取引先要項システム。As an element of the DTD, it has an occurrence date of occurrence once in the same hierarchy as the main trend category name,
The date of occurrence is the date on which the trend of the customer indicated in the trend comment data occurred,
The supplier trend table has the date of occurrence as an item to be displayed in the supplier trend table area,
The input area is a display / input / edit area, a combo box of a main trend category name that prompts the user to select from the list of major trend category names, and an occurrence date that prompts the user to input the date of occurrence An area, and a detailed area that prompts input of the trend comment data,
The display editing control unit
Receiving an operation to the edit button or registration button to be displayed on the terminal, changing the display mode of the terminal,
The display edit control unit includes, as the display mode, a reference mode that disables input and editing to the supplier trend table, an edit mode that allows input and edit to the supplier trend table, and the edit mode. And a confirmation mode that prompts confirmation of registration with the displayed contents while sorting and displaying the contents of the supplier trend table according to the edited result in
The details area is, in the above-reference modeand an area to display the existing trend commentdata, and in the edit mode as editing and new trends comment input work area of the existing trendscomment,
The display editing control unit
When displaying in the reference mode, an edit button operated to change to the edit mode is displayed,
When displaying in the edit mode, a registration button for changing to the confirmation mode is displayed.
The display editing control unit
Sortthe customer trend table entered and edited in the edit mode with the date of occurrence as a key, display on the terminalfor confirmation to the user without input editing ,
3. The supplier requirement system according to claim 1, wherein the storage control unit stores the items in thesorted order when confirmed by the user . 取引先要項システムを使用して、取引先の動向に関するデータの表示を制御する取引先動向表示制御方法であって、
前記取引先要項システムが、
文字データを扱う端末及び他システムとネットワークを介して接続されたサーバーと、このサーバーによって処理されるデータを前記文字データを含むＸＭＬデータとして格納するデータ格納部とを備え、
前記データ格納部が、前記データの項目を階層化するＸＭＬの体系及びタグを定義したタグ体系定義ファイルであるＤＴＤと、前記端末での表示領域及び入力領域を予め定めたＧＵＩ定義ファイルと、前記ＤＴＤに従ってタグ付けされたタグ付きデータを前記文字データを含むＸＭＬデータとして格納すると共に前記サーバー及び前記他システムから検索されるＸＭＬデータタグ付けをし、ＸＭＬパーサーによる妥当性の検証処理をし、当該検証処理したＸＭＬデータを前記データ格納部に格納し、
当該サーバーは、前記他システムからの検索を許可し、
前記タグ体系定義ファイルは、前記ＸＭＬデータに対する前記タグ体系定義による前記ＤＴＤの要素として、
ＣＩＦ番号と、このＣＩＦ番号と並列で発生頻度が１回以上出現の取引先動向とを有し、
当該取引先動向は、発生頻度が１回出現の主要動向区分名称と、０回又は１回出現の動向コメントデータとを有し、
前記ＣＩＦ番号は、前記取引先を唯一に識別するデータで、
前記動向コメントデータは、前記文字データであって、前記取引先についての主要な動向を示し前記端末のユーザーによって入力又は編集される文章となった文字データで、、
前記主要動向区分名称は、前記取引先の主要な動向を前記端末のユーザーに対して予め明示的に区分すると共に、予め定められた所定の区分種別に属する文字データで、
前記サーバーは、前記ＧＵＩ定義ファイルに従って、前記表示領域として、前記ＣＩＦ番号で特定される取引先毎に、前記主要動向区分名称と、前記動向コメントデータとの項目で当該データを表示するための取引先動向テーブル領域を前記端末に表示させ、
当該サーバーは、
取引先動向テーブルと、表示編集制御部と、主要動向区分管理部と、格納制御部とを有し、
前記取引先動向テーブルは、
前記取引先動向テーブル領域に表示するデータとして、又は、前記入力領域にて入力、選択若しくは編集されたデータとして、前記主要動向区分名称と、前記動向コメントデータとを有し、
前記主要動向区分管理部は、
前記主要動向区分名称を特定する主要動向区分コードの範囲を前記区分種別毎に記憶することで、前記各主要動向区分が属する前記区分種別を管理し、
前記表示編集制御部は、
前記データを前記端末の前記取引先動向テーブル領域に表示する際に、
前記ＸＭＬデータファイルから前記ＸＭＬデータを取り込み、当該ＸＭＬデータのタグに従って当該ＸＭＬデータを取引先動向テーブルに編集し、当該端末の前記取引先動向テーブル領域に当該編集した取引先動向テーブルを表示し、
前記端末のユーザーが前記入力領域に動向コメントデータを入力する際に、
前記主要動向区分名称を当該主要動向区分名称の一覧から当該ユーザーに選択させ、
前記端末の入力領域に主要動向区分名称及び動向コメントデータが入力、選択又は編集された際には、
当該データを受信して、前記取引先動向テーブルに編集し、
前記格納制御部は、
前記取引先動向テーブルのデータを格納する際には、
前記取引先動向テーブルの各データに前記各項目に応じたタグを付し、前記ＣＩＦ番号毎の取引先動向に関するデータが前記タグ体系定義に定義された階層及び出現回数となっているかを前記ＸＭＬパーサーにより検証処理し、当該データが当該タグ体系定義との関係で妥当性を有する場合に当該処理されたＸＭＬデータを格納することで、前記主要動向区分名称が前記取引先動向毎に１回のみ出現するＸＭＬデータを前記ＸＭＬデータファイルに格納し、
前記サーバーが、このＸＭＬデータファイルを、当該動向コメントデータについて当該主要動向区分名称又は主要動向区分コードを当該他システムとのインタフェースとし、前記他システムからの検索を許可する前記データベースに格納することで、当該動向コメントデータの他システムとの共有を制御し、
ここで、前記サーバーの情報処理として、
前記サーバーが、表示対象の取引先を識別するＣＩＦ番号を特定し、当該ＣＩＦ番号の前記取引先動向を特定し、当該取引先動向に含まれる主要動向区分名称と動向コメントデータと取引先動向レコードとして前記ＸＭＬデータから読み出して前記取引先動向テーブルに編集する取引先特定工程と、
前記サーバーが、前記端末に表示する主要動向区分の種別である前記区分種別を受信した際には、当該区分種別に属する前記主要動向区分コードの範囲を抽出範囲として設定する抽出範囲設定工程と、
前記サーバーが、前記取引先動向テーブルの各取引先動向レコードの主要動向区分名称の主要動向区分コードと前記抽出範囲とを比較して、当該抽出範囲に属すると判定した際には、当該取引先動向レコードを抽出して前記区分種別の表示対象に追加し、前記全ての取引先動向レコードについて当該判定及び追加を繰り返す当該範囲内動向コメント抽出工程と、
前記サーバーが、前記区分種別の表示対象に追加された取引先動向レコード群を前記抽出範囲の取引先動向テーブルとして前記端末に表示する抽出表示制御工程とを備えたことを特徴とする取引先動向表示制御方法。A supplier trend display control method for controlling display of data relating to a supplier trend using a supplier requirement system,
The supplier requirements system is
A server connectedto a terminalthat handles character data and other systemsvia a network, and a data storage unit that stores data processed by the serveras XML data including the character data ,
The data storage unit includes a DTD that is a tag system definition file that defines an XML system and tags for hierarchizing the data items, a GUI definition file that defines a display area and an input area in the terminal, The tagged data tagged according to the DTD is stored as XML data including the character data, the XML data tagged from the server and the other system is tagged, and the validity verification process by the XML parser is performed. The verified XML data is stored in the data storage unit,
The serverallows search from the other system,
The tag system definition file is an element of the DTD by the tag system definition for the XML data.
A CIF number and a trend of a customer whose frequency of occurrence appears at least once in parallel with the CIF number,
The supplier trend has a main trend category name that appears once and a trend comment data that appears zero or once.
The CIF number is data that uniquely identifies the customer,
The trend comment data is the character data, and is character data that is a sentence that is input or edited by a user of the terminal indicating a main trend of the business partner,
The main trend category name is a character data belonging to a predetermined category type, in addition to explicitly classifying the main trend of the business partner in advance to the user of the terminal,
In accordance with the GUI definition file, the server displays, as the display area, a transaction for displaying the data in the items of the main trend category name and the trend comment data for each business partner specified by the CIF number. theabove trends table area is displayed on the terminal,
The server
A supplier trend table, a display editing control unit, a main trend category management unit, and a storage control unit;
The supplier trend table is:
As data to be displayed in the supplier trend table area, or as data input, selected or edited in the input area, the main trend category name and the trend comment data,
The main trend category management department
By storing, for each category type, a range of major trend category codes that specify the major trend category name, managing the category type to which each major trend category belongs,
The display editing control unit
When displaying the data in the customer trend table area of the terminal,
Incorporating the XML data from the XML data file, editing the XML data into a customer trend table according to the XML data tag, and displaying the edited customer trend table in the customer trend table area of the terminal,
When the user of the terminal inputs trend comment data in the input area,
Let the user select the main trend category name from the list of major trend category names,
When the main trend category name and trend comment data are input, selected or edited in the input area of the terminal,
Receive the data, edit it in the supplier trend table,
The storage control unit
When storing the data of the supplier trend table,
A tag corresponding to each item is attached to each data of the supplier trend table, and whether the data related to the supplier trend for each CIF number has the hierarchy and the number of appearances defined in the tag system definition. When the data is validated in relation to the tag system definition by storing it with a parser and storing the processed XML data, the main trend category name is only once for each supplier trend. Storing the appearing XML data in the XML data file;
The server stores the XML data file in the database that allows the search from the other system using the main trend category name or the main trend category code for the trend comment data as an interface with the other system. , Control sharing of the trend comment data with other systems,
Here, as information processing of the server,
The server specifiesa CIF number that identifies a business partner to be displayed, identifies thebusiness partner trend of the CIF number, main trend category name, trend comment data, and business partner trend record included in the business partner trend and suppliers specific stepstaken to edit the the suppliers trend table is read from the XML data as,
The server,upon receivingthe segment type is a classification of the main trends segment to be displayed on theterminal, the extraction range setting step of settinga range of the major trends classification code belonging to thiscategory typeas the extraction range ,
When the server compares the main trend categorycode of the main trend category name of each customer trend record of the customer trend table with theextraction range, and determines that theserverbelongs to the extraction range, A trend record is extractedand added to the display target of the category type, and the in- range trend comment extraction stepfor repeating the determination and addition for all the customer trend records ,
Asupplier trend characterized in that the server comprises an extraction display control step for displaying, on the terminal, a supplier trend record groupadded tothe display target of the category type as asupplier trend table of the extraction range. Display control method. 取引先要項システムを使用して、取引先の動向に関するデータの表示を制御するための取引先動向表示制御用プログラムであって、
前記取引先要項システムが、
文字データを扱う端末及び他システムとネットワークを介して接続されたサーバーと、このサーバーによって処理されるデータを前記文字データを含むＸＭＬデータとして格納するデータ格納部とを備え、
前記データ格納部が、前記データの項目を階層化するＸＭＬの体系及びタグを定義したタグ体系定義ファイルであるＤＴＤと、前記端末での表示領域及び入力領域を予め定めたＧＵＩ定義ファイルと、前記ＤＴＤに従ってタグ付けされたタグ付きデータを前記文字データを含むＸＭＬデータとして格納すると共に前記サーバー及び前記他システムから検索されるＸＭＬデータＤＢとを備え、
前記サーバーは、前記端末に前記データを送信することで当該端末の表示領域に当該文字データを表示し、
一方、前記端末の前記入力領域にて当該端末のユーザーによって入力、選択又は編集されたデータを受信し、当該データに前記ＤＴＤによって定義されたタグ付けをし、ＸＭＬパーサーによる妥当性の検証処理をし、当該検証処理したＸＭＬデータを前記データ格納部に格納し、
当該サーバーは、前記他システムからの検索を許可し、
前記タグ体系定義ファイルは、前記ＸＭＬデータに対する前記タグ体系定義による前記ＤＴＤの要素として、
ＣＩＦ番号と、このＣＩＦ番号と並列で発生頻度が１回以上出現の取引先動向とを有し、
当該取引先動向は、発生頻度が１回出現の主要動向区分名称と、０回又は１回出現の動向コメントデータとを有し、
前記ＣＩＦ番号は、前記取引先を唯一に識別するデータで、
前記動向コメントデータは、前記文字データであって、前記取引先についての主要な動向を示し前記端末のユーザーによって入力又は編集される文章となった文字データで、、
前記主要動向区分名称は、前記取引先の主要な動向を前記端末のユーザーに対して予め明示的に区分すると共に、予め定められた所定の区分種別に属する文字データで、
前記サーバーは、前記ＧＵＩ定義ファイルに従って、前記表示領域として、前記ＣＩＦ番号で特定される取引先毎に、前記主要動向区分名称と、前記動向コメントデータとの項目で当該データを表示するための取引先動向テーブル領域を前記端末に表示させ、
当該サーバーは、
取引先動向テーブルと、表示編集制御部と、主要動向区分管理部と、格納制御部とを有し、
前記取引先動向テーブルは、
前記取引先動向テーブル領域に表示するデータとして、又は、前記入力領域にて入力、選択若しくは編集されたデータとして、前記主要動向区分名称と、前記動向コメントデータとを有し、
前記主要動向区分管理部は、
前記主要動向区分名称を特定する主要動向区分コードの範囲を前記区分種別毎に記憶することで、前記各主要動向区分が属する前記区分種別を管理し、
前記表示編集制御部は、
前記データを前記端末の前記取引先動向テーブル領域に表示する際に、
前記ＸＭＬデータファイルから前記ＸＭＬデータを取り込み、当該ＸＭＬデータのタグに従って当該ＸＭＬデータを取引先動向テーブルに編集し、当該端末の前記取引先動向テーブル領域に当該編集した取引先動向テーブルを表示し、
前記端末のユーザーが前記入力領域に動向コメントデータを入力する際に、
前記主要動向区分名称を当該主要動向区分名称の一覧から当該ユーザーに選択させ、
前記端末の入力領域に主要動向区分名称及び動向コメントデータが入力、選択又は編集された際には、
当該データを受信して、前記取引先動向テーブルに編集し、
前記格納制御部は、
前記取引先動向テーブルのデータを格納する際には、
前記取引先動向テーブルの各データに前記各項目に応じたタグを付し、前記ＣＩＦ番号毎の取引先動向に関するデータが前記タグ体系定義に定義された階層及び出現回数となっているかを前記ＸＭＬパーサーにより検証処理し、当該データが当該タグ体系定義との関係で妥当性を有する場合に当該処理されたＸＭＬデータを格納することで、前記主要動向区分名称が前記取引先動向毎に１回のみ出現するＸＭＬデータを前記ＸＭＬデータファイルに格納し、
前記サーバーが、このＸＭＬデータファイルを、当該動向コメントデータについて当該主要動向区分名称又は主要動向区分コードを当該他システムとのインタフェースとし、前記他システムからの検索を許可する前記データベースに格納することで、当該動向コメントデータの他システムとの共有を制御し、
ここで、前記取引先要項システムの前記サーバーに情報処理である所定の工程を実現させるための取引先要項システム用プログラムであって、
前記サーバーが、前記表示対象の取引先を識別するＣＩＦ番号を特定し、当該ＣＩＦ番号の前記取引先動向を特定し、当該取引先動向に含まれる主要動向区分名称と動向コメントデータと取引先動向レコードとして前記ＸＭＬデータから読み出して前記取引先動向テーブルに編集する取引先特定工程と、
前記サーバーが、前記端末に表示する主要動向区分の種別である前記区分種別を受信した際には、当該区分種別に属する前記主要動向区分コードの範囲を抽出範囲として設定する抽出範囲設定工程と、
前記サーバーが、前記取引先動向テーブルの各取引先動向レコードの主要動向区分名称の主要動向区分コードと前記抽出範囲とを比較して、当該抽出範囲に属すると判定した際には、当該取引先動向レコードを抽出して前記区分種別の表示対象に追加し、前記全ての取引先動向レコードについて当該判定及び追加を繰り返す当該範囲内動向コメント抽出工程と、
前記サーバーが、前記区分種別の表示対象に追加された取引先動向レコード群を前記抽出範囲の取引先動向テーブルとして前記端末に表示する抽出表示制御工程とを実現させることを特徴とする取引先動向表示制御用プログラム。A supplier trend display control program for controlling the display of data relating to a supplier trend using the supplier requirement system,
The supplier requirements system is
A server connectedto a terminalthat handles character data and other systemsvia a network, and a data storage unit that stores data processed by the serveras XML data including the character data ,
The data storage unit includes a DTD that is a tag system definition file that defines an XML system and tags for hierarchizing the data items, a GUI definition file that defines a display area and an input area in the terminal, An XML data DB that stores tagged data tagged according to DTD as XML data including the character data and is retrieved from the server and the other system;
The server displays the character data in the display area of the terminal by transmitting the data to the terminal,
On the other hand, data input, selected or edited by the user of the terminal in the input area of the terminal is received, the data is tagged as defined by the DTD, and validity verification processing by an XML parser is performed. And storing theverified XML data in the data storage unit,
The serverallows search from the other system,
The tag system definition file is an element of the DTD by the tag system definition for the XML data.
A CIF number and a trend of a customer whose frequency of occurrence appears at least once in parallel with the CIF number,
The supplier trend has a main trend category name that appears once and a trend comment data that appears zero or once.
The CIF number is data that uniquely identifies the customer,
The trend comment data is the character data, and is character data that is a sentence that is input or edited by a user of the terminal indicating a main trend of the business partner,
The main trend category name is a character data belonging to a predetermined category type, in addition to explicitly classifying the main trend of the business partner in advance to the user of the terminal,
In accordance with the GUI definition file, the server displays, as the display area, a transaction for displaying the data in the items of the main trend category name and the trend comment data for each customer specified by the CIF number. Display the trend table area on the terminal,
The server
A supplier trend table, a display editing control unit, a main trend category management unit, and a storage control unit;
The supplier trend table is:
As data to be displayed in the supplier trend table area, or as data input, selected or edited in the input area, the main trend category name and the trend comment data,
The main trend category management department
By storing, for each category type, a range of major trend category codes that specify the major trend category name, managing the category type to which each major trend category belongs,
The display editing control unit
When displaying the data in the customer trend table area of the terminal,
Incorporating the XML data from the XML data file, editing the XML data into a supplier trend table according to the tag of the XML data, displaying the edited supplier trend table in the customer trend table area of the terminal ,
When the user of the terminal inputs trend comment data in the input area,
Let the user select the main trend category name from the list of major trend category names,
When the main trend category name and trend comment data are input, selected or edited in the input area of the terminal,
Receive the data, edit it in the supplier trend table,
The storage control unit
When storing the data of the supplier trend table,
A tag corresponding to each item is attached to each data of the supplier trend table, and whether the data related to the supplier trend for each CIF number has the hierarchy and the number of appearances defined in the tag system definition. When the data is validated in relation to the tag system definition by storing it with a parser and storing the processed XML data, the main trend category name is only once for each supplier trend. Storing the appearing XML data in the XML data file;
The server stores the XML data file in the database that allows the search from the other system using the main trend category name or the main trend category code for the trend comment data as an interface with the other system. , Control sharing of the trend comment data with other systems,
Here, a program for a supplier requirements system for realizing a predetermined process that is information processing in the server of the supplier requirements system,
The server specifiesa CIF number for identifying the business partner to be displayed, identifies thebusiness partner trend of the CIF number, main trend category name, trend comment data, and business partner trend included in the business partner trend. and suppliers specific stepstaken for the as records are read from the XML data to edit the suppliers trend table,
The server,upon receivingthe segment type is a classification of the main trends segment to be displayed on theterminal, the extraction range setting step of settinga range of the major trends classification code belonging to thiscategory typeas the extraction range ,
When the server compares the main trend categorycode of the main trend category name of each customer trend record of the customer trend table with theextraction range, and determines that theserverbelongs to the extraction range, A trend record is extractedand added to the display target of the category type, and the in- range trend comment extraction stepfor repeating the determination and addition for all the customer trend records ,
Thesupplier trend is torealize an extraction display control step of displaying, on the terminal, a supplier trend record groupadded tothe display target of the category type as asupplier trend table of the extraction range. Display control program.

Images