JP2005267052A - 契約管理システム、そのソフトウエア、その記録媒体、及び契約管理方法 - Google Patents

Abstract

【課題】 保存期間が経過した契約をもれなく認識できるものとする。
【解決手段】 本願発明に係る契約管理システムは、少なくとも、契約情報記憶装置１と、時期検出装置２と、確認対象検出装置３とを備える。契約情報記憶装置１は、個々の契約について、少なくとも、契約担当者又は契約担当部署を特定する担当情報と、契約開始日等の確認基準日情報とを、契約情報として保持する。時期検出装置２は、時計を備え、定期的に、確認対象検出装置３を起動する。確認対象検出装置３は、契約情報記憶装置１が保持する契約情報夫々の、確認基準日情報と現在の日付とを比較し、確認時期の到来した契約情報と確認時期の到来していない契約情報とを識別する。
【選択図】 図１

Description

本願発明は、契約管理システム、そのソフトウエア、その記録媒体及び契約管理方法に関するものである。

従来より、契約は紙文書で締結されており、企業においては各部門の契約書を統括し原本を保管・管理するといった作業を実施している。近年では、ＩＴの発達により、電子文書による契約の締結もあるが、まだ紙文書によるものが圧倒的に多い。電子文書による契約であっても、紙媒体に印刷し、紙文書で保管・管理している場合もある。
紙文書における契約書の保管・管理を効率化するにあたり、紙文書の内容を電子文書に移行し、電子文書による保管・管理・廃棄など一連の作業を自動化したシステムが考案されている（特許文献１）。

特開２００３−３３７８７６号公報

上記の特許文献１のシステムでは、紙文書を電子文書に移行した後も、一部の紙文書は残ると予想されており、それら紙文書を保管・管理する仕組みは、実際に紙文書を収納しているキャビネット番号が電子データとリンク付けされていて、瞬時にキャビネットの位置などを特定することができる。
契約書は、法律や社内規定などにより一定期間の保存が義務付けられており、その期間を経過したものについては、破棄することができる。破棄可能な契約書をピックアップするためには、各契約書の締結日と保管期限を電子データに付加することで可能となる。しかしながら、実際に破棄しても問題ないかどうかの判断については、人の判断に委ねているのが現状である。保管期限（例えば、契約書について１０年、発注書について７年など）を経過する頃には、契約締結時の担当者が異動や退職などの理由で不明となっているケースも多々見受けられ、業務（契約）の引継ぎが不完全な場合、実際に破棄しても問題ないかどうかの判断がつかない契約書が散在する。このような契約書は破棄できずに継続保管しているのが現状である。

即ち、上記特許文献１のシステムによって、契約書の原本の所在は容易に検索できたとしても、上記の通り、破棄可能な契約書をその大量のデータの中から確実に識別する手段を提供するものではない。また、例えば、データ上において機械的に、文書（行政文書等）の特定情報と担当者（決裁者）の特定情報との対を生成することはできても、現実において、保管期限が過ぎた契約書について破棄するか否かの判断を行える者がいないといった状態に陥っていたり、担当者の不明な契約書が発生したり、契約の担当を引き継ぐべき者や部署に正確に引継ぎが行えておらず他の者を誤って後任担当者としていたりするといった事態が生じている場合に、上記特許文献１のシステムは、このような現実の状態に則したデータの処理や当該処理を支援する手段を提供するものではない。

本願発明は、保管期限が到来した契約をもれなく認識できること、保管期限が到来した契約について、当該契約の担当者に確実に契約書を継続して保存するか破棄するかの見直しを促すこと、契約書の保存中に人事異動や組織変更など契約担当者や契約担当部署が変動して後任担当者や担当部署が不明となった契約書を発生させないこと、上記の見直しを後任契約担当者や担当部署に確実に行わせることを可能として、上記課題の解決を図るものである。

本願第１の発明に係る契約管理システムは、少なくとも、契約情報記憶装置１と、時期検出装置２と、確認対象検出装置３とを備える。契約情報記憶装置１は、個々の契約について、少なくとも、契約担当者又は契約担当部署を特定する担当情報ｘ１と、契約開始日等の確認基準日情報ｘ２とを、契約情報ｄとして保持する。時期検出装置２は、時計を備え、定期的に、確認対象検出装置３を起動する。確認対象検出装置３は、契約情報記憶装置１が保持する契約情報ｄ…ｄ夫々の、確認基準日情報ｘ２と現在の日付とを比較し、確認時期の到来した契約情報ｄと確認時期の到来していない契約情報ｄとを識別する。
ここでいう「契約」とは、本来の契約の他、注文など、通常の契約以外の取引を含む。
また、確認基準日は、契約開始日に限定するものではなく、契約開始日以外の日を含む。例えば、確認基準日として、契約終了日、解約日などを採用することができる。
尚、確認時期の到来には、確認基準日から０日経過の場合も含む。

本願第２の発明に係る契約管理システムは、上記本願第１の発明に係る契約管理システムにあって、データベース接続装置４と、異動検出装置５と、通知装置６と、確認要求装置７とを備える。データベース接続装置４は、人事管理データベース等の外部のデータベースＤ１を本システムに接続するものである。異動検出装置５は、契約情報記憶装置１を参照すると共に上記のデータベース接続装置４を通じて上記外部のデータベースＤ１を参照し、人事異動や組織変更などの契約担当者や契約部署を特定する情報の変更を検出する。通知装置６は、確認要求装置７に、異動検出装置５が検出した変更後の情報を通知する。確認要求装置７は、通知装置６から上記通知を受けて、データベース接続装置４を通じて上記外部のデータベースＤ１を参照し上記変更後の契約担当者又は契約担当部署の連絡先を取得し、当該変更後の契約担当者又は契約担当部署へ、確認対象検出装置３にて識別した契約情報を通知する。

本願第３の発明に係る契約管理システムは、上記本願第２の発明に係る契約管理システムにあって、入力装置８と、担当更新装置９とを備える。入力装置８は、少なくとも担当情報の入力を受け付ける。担当更新装置９は、入力装置８が受け付けた担当情報にて、契約情報記憶装置１が保持する契約情報ｄ中の担当情報ｘ１を、上記確認要求装置による通知を受けた変更後の契約担当者又は契約担当部署の確認後の内容に沿ったものに、更新する。

本願第４の発明に係る契約管理システムは、上記本願第１乃至４の何れかの発明に係る契約管理システムにあって、異動検出装置５と、通知装置６と、担当更新装置９とを備える。異動検出装置５は、契約情報記憶装置１を参照すると共に上記データベース接続装置４を通じて上記外部のデータベースＤ１を参照して、人事異動や組織変更などの契約担当者や契約部署を特定する情報の変更を検出する。通知装置６は、担当更新装置９に、異動検出装置５が検出した変更後の情報を通知する。担当更新装置９は、通知装置６から情報の変更の上記通知を受け、契約情報記憶装置１が保持する契約情報ｄ中の担当情報を更新する。

本願第５の発明に係る契約管理システムは、上記本願第１乃至４の何れかの発明に係る契約管理システムにあって、会計データベース接続装置１０と、表示装置１１とを備える。会計データベース接続装置１０は、外部の会計データベースＤ２を本システムに接続するものである。表示装置１１は、確認対象検出装置３が識別した確認時期の到来した契約情報ｄについて、会計データベース接続装置１０を通じて、外部の会計データベースＤ２から、最終取引日を取得して表示することが可能なものである。

本願第６の発明に係る契約管理ソフトウエアは、少なくとも、契約情報記憶装置１と、時計を備えた時期検出装置２と、確認対象検出装置３とを用いるものである。そして、この契約管理ソフトウエアは、上記の契約情報記憶装置１に、個々の契約について、少なくとも、契約担当者又は契約担当部署を特定する担当情報ｘ１と、契約開始日等の確認基準日情報ｘ２とを、契約情報ｄとして保持させ、時期検出装置２に、定期的に、確認対象検出装置３を起動させ、確認対象検出装置３に、契約情報記憶装置１が保持する契約情報ｄ...ｄ夫々の、確認基準日と現在の日付とを比較させ、確認時期の到来した契約情報ｄと確認時期の到来していない契約情報ｄとを識別させる。

本願第７の発明に係る契約管理ソフトウエアの記録媒体は、上記本願第６の発明に係る契約管理ソフトウエアを記録したものである。

本願第８の発明に係る契約管理方法は、少なくとも、契約情報記憶装置１と、時計を備えた時期検出装置２と、確認対象検出装置３とを用いるものである。そして、この契約管理ソフトウエアは、上記の契約情報記憶装置１に、個々の契約について、少なくとも、契約担当者又は契約担当部署を特定する担当情報ｘ１と、契約開始日等の確認基準日情報ｘ２とを、契約情報ｄとして保持させ、時期検出装置２に、定期的に、確認対象検出装置３を起動させ、確認対象検出装置３に、契約情報記憶装置１が保持する契約情報ｄ...ｄ夫々の、確認基準日と現在の日付とを比較させ、確認時期の到来した契約情報ｄと確認時期の到来していない契約情報ｄとを識別させる。

本願第１〜８の発明の実施にて、定期的に、確認対象検出装置が、契約情報記憶装置中の契約情報の確認基準日情報を、現在の日付と比べて、確認時期の到来したものとそうでないものとを識別するので、保管期限が到来した契約をもれなく認識することができ、契約書の管理者において、整理が必要な契約を確認する作業負担を軽減した。とりわけ、大量の契約情報を保持している場合に、上記の識別を行わずに全ての契約情報を確認するものとすれば、その負担は図り知れないものであるが、それを上記の通り識別しておくことにより、識別後の契約のみを確認すればよく、確認する者の負担を軽減した。

特に、上記本願第２の発明の実施によって、契約担当者や契約担当部署の異動や組織変更時に、契約担当者に前任者が担当していた契約を確実に引き継がせることができ、契約書の保存中に人事異動や組織変更など契約担当者や契約担当部署が変動したために後任担当者や担当部署が不明となった契約書を発生させてしまうということがない。また、引継ぎを機に、保管期限が到来した契約について、当該契約の後任担当者に確実に契約書を継続して保存するか破棄するかの見直しを促すことができる。従って、契約書を管理する者にとって、契約担当者の異動等を契機として後任の契約担当者や契約部署に確実に契約書の保存・破棄を確認する機会を与えることができ、管理の負担を軽減した。
また、上記本願第３の発明の実施によって、上記にて契約書の確認を求められた後任の契約担当者や、或いは当該担当者から連絡を受けた契約書の管理者が、入力装置にて入力することにより、担当更新装置にて、後任担当者の確認結果を、確実に、契約情報記憶装置内の契約情報に反映させることができる。
上記本願第４の発明の実施にあっては、人事異動や組織変更による契約担当者や担当部署の変更を、外部のデータベースから異動検出手段が検出して、担当更新装置が当該検出に従って、契約情報記憶装置１が保持する契約情報の契約担当情報を書き換えるものであるため、契約書を管理する者が、そのような異動の検出や、書き換えの作業を強いられずに済み、当該管理者の管理負担を大幅に軽減した。
また、更に、上記本願第５の発明の実施にあっては、表示装置が、外部の会計データベースから、確認対象検出装置が識別した契約情報の最終取引日を検出して、表示するものであるため、契約を管理する者或いは契約担当者が、契約の状況をより的確に把握し、確認時などに適切な判断を下すことを容易とした。

以下、図面を参照しつつ、本願発明の好ましい実施の形態について、説明する。
図１〜図１６へ本願発明の一実施の形態を示す。
図１は、本願発明に係るシステムのシステム構成を示す説明図である。図２は、図１の要部説明図である。図３（Ａ）は、契約書（注文書）からデータベースを構築する手順を示す説明図であり、図３（Ｂ）はその紙文書である契約書（注文書）の保管について示す説明図である。図４（Ａ）は本システムＳが他部門から受け取る顧客変更通知ｒ１の説明図であり、図４（Ｂ）は本システムＳが他部門から受け取る組織変更通知ｒ２の内容を示す説明図であり、図４（Ｃ）は外部のデータベースＤ１の内容を示す説明図であり、図４（Ｄ）は会計データベースＤ２の内容を示す説明図である。図５（Ａ）は顧客に変更が生じた際の本システムの処理の概要を示す説明図であり、図５（Ｂ）はその処理の流れを示す説明図である。図６（Ａ）は顧客データベースｄｂ４の内容を示す説明図であり、図６（Ｂ）は更新後の当該顧客データベースｄｂ４の内容を示す説明図であり、図６（Ｃ）は当初の顧客データベースｄｂ４の構築に用いられる顧客変更データｈ１の内容を示す説明図であり、図６（Ｄ）は図６（Ｂ）に示す顧客データベースｄｂ４の更新に用いられる顧客変更データｈ１の内容を示す説明図である。図７（Ａ）は組織変更が生じた際の本システムの処理の概要を示す説明図であり、図７（Ｂ）はその処理の流れを示す説明図である。図８（Ａ）は部門データベースｄｂ５の内容を示す説明図であり、図８（Ｂ）は部門統合の組織変更データｈ２による変更後の部門データベースｄｂ５の内容を示す説明図であり、図８（Ｃ）は部門変更の組織変更データｈ２による変更後の部門データベースｄｂ５の内容を示す説明図である。図９（Ａ）は当初の部門データベースｄｂ５の構築に用いられる組織変更データｈ２の内容を示す説明図であり、図９（Ｂ）は部門統合の組織変更データｈ２の内容を示す説明図であり、図９（Ｃ）は部門変更の組織変更データｈ２の内容を示す説明図である。図１０（Ａ）は、人事異動が生じた際の本システムの処理の概要を示す説明図であり、図１０（Ｂ）は通知を受けた契約担当者における処理を示す説明図である。図１１は図１０に示す処理の流れを示す説明図である。図１２（Ａ）〜（Ｃ）は、図１１に示す工程の要部説明図である。図１３（Ａ）は社員データベースｄｂ６の内容の例を示す説明図であり、図１３（Ｂ）は更新後の社員データベースｄｂ６の内容の例を示す説明図であり、図１３（Ｃ）は図１３（Ａ）の社員データベースｄｂ６の構築に利用した異動データｉの内容を示す説明図であり、図１３（Ｄ）は図１３（Ｂ）に示す更新に利用した異動データｉの内容を示す説明図である。図１４は、本システムにおいて、処分の確認の流れを示す説明図である。図１５は、担当特定情報更新工程３３０を支援する画面の説明図である。図１６は、管理者の通知作業を支援する画面の説明図である。

１．システムの概要
このシステムＳは、主として、一企業内における契約書（契約データ）の管理者Ｐの業務を、コンピュータを用いて、支援するものである。
即ち、このシステムＳは、上記契約書を管理する管理者Ｐに、法定或いは社内規定で定められた保存期間が経過した後の契約書を的確に把握することを可能せしめ、また、その破棄の判断にあたって、個々の契約の担当者Ｑ（或いは担当部署）の意見を反映させることを可能せしめて破棄の適否の判断をより正確に行えるものとし、更に、人事異動や組織変更による契約担当者Ｑ（や担当部署）の変更を契機として上記の意見を求めることを可能せしめて上記処分の機会を確実に確保すると共に後任担当者Ｑ（又は担当部署）への契約の確実な引継ぎを支援するものである。
この実施の形態において、当該企業における契約担当は、社員（契約担当者）とする。

２．システム構成
図１に示す通り、この契約管理システムＳは、契約情報記憶装置１と、時期検出装置２と、確認対象検出装置３と、データベース接続装置４と、異動検出装置５と、通知装置６と、確認要求装置７と、入力装置８と、更新装置９と、会計データベース接続装置１０と、表示装置１１とを備える。

上記の契約情報記憶装置１は、個々の契約について、少なくとも、契約担当者又は契約担当部署を特定する担当情報ｘ１と、契約開始日等の確認基準日情報ｘ２とを、契約情報ｄとして保持する。具体的には、契約情報記憶装置は、図２に示す通り、上記の契約情報ｄを収納する契約書データベースｄｂ１（或いは注文書データベースｄｂ２）と、保存期間データベースｄｂ３と、顧客データベースｄｂ４と、部門データベースｄｂ５と、社員データベースｄｂ６と、最終取引日データベースｄｂ７とを保持する。

上記の時期検出装置２は、時計を備え、定期的に、確認対象検出装置３を起動する。
上記の確認対象検出装置３は、契約情報記憶装置１が保持する契約情報ｄ...ｄ夫々の、確認基準日情報ｘ２と現在の日付とを比較し、確認時期の到来した契約情報ｄと確認時期の到来していない契約情報ｄとを識別する。
上記のデータベース接続装置４は、人事管理データベース等の外部のデータベースＤ１を本システムに接続するものである。
上記の異動検出装置５は、契約情報記憶装置１を参照すると共に上記のデータベース接続装置４を通じて上記外部のデータベースＤ１を参照して、人事異動や組織変更などの契約担当者や契約部署を特定する情報の変更を検出する。
上記の通知装置６は、確認要求装置７に、異動検出装置５が検出した変更後の情報を通知する。また、通知装置６は、更新装置９に、異動検出装置５が検出した変更後の情報を通知する。

上記の確認要求装置７は、通知装置６から上記通知を受けて、データベース接続装置４を通じて上記外部のデータベースＤ１を参照し上記変更後の契約担当者又は契約担当部署の連絡先を取得し、当該変更後の契約担当者又は契約担当部署へ、確認対象検出装置３にて識別した契約情報を通知する。
上記の入力装置８は、オペレータ（管理者Ｐ或いは担当者Ｑ）からの情報の入力を受け付ける。
更新装置９は、入力装置８が受け付けた情報にて、契約情報記憶装置１に収容されている各データベースｄｂ１〜ｄｂ７への各情報の入力、収容している情報の更新を行う。例えば、入力装置８にて担当情報の更新の入力を受け付けると、更新装置９は、担当更新装置として、入力装置８が受け付けた担当情報にて、契約情報記憶装置１が保持する契約情報ｄ中の担当情報ｘ１を、上記確認要求装置による通知を受けた変更後の契約担当者又は契約担当部署の確認後の内容に沿ったものに、更新する。また、更新装置９は、通知装置６から情報の変更の上記通知を受け、契約情報記憶装置１が保持する契約情報ｄ中の担当情報を更新する。
上記の会計データベース接続装置１０は、外部の会計データベースＤ２を本システムに接続するものである。
上記の表示装置１１は、（管理者Ｐなどの）オペレータが入力装置８を通じて入力を行う際に、入力の支援を行う。表示装置１１は、少なくとも、確認対象検出装置３が識別した確認時期の到来した契約情報ｄを表示することが可能である。また、表示装置１１は、当該確認時期が到来した契約情報ｄについて、会計データベース接続装置１０を通じて、外部の会計データベースＤ２から、最終取引日を取得して表示することが可能なものである。

３．ハードウエア構成
このシステムは、システムを実現するソフトウエア（システムソフトウエア）が導入されたコンピュータを用いて実現される（以下、ソフトウエアを単にソフトと呼ぶ）。
コンピュータには、Ｗｉｎｄｏｗｓ（登録商標）やＵＮＩＸ（登録商標）に代表されるＯＳ（オペレーティング・システム）が導入されたものを用い、上記管理プログラムは、当該ＯＳ上にて機能する。但し、そのような汎用ＯＳの採用に限定するものではなく、専用のソフトを利用するものとしても実施可能である。
具体的には、コンピュータは、ＣＰＵなどの演算装置（演算・制御装置）と、メモリやハードディスク等の記憶装置（内部記憶装置及び外部記憶装置）と、ディスプレイやプリンタなどの出力機能装置と、キーボードやマウスに代表される入力機能装置と、ネットワークに接続するためのモデムに代表される通信装置とを備える。
各装置については、１台のコンピュータが備え或いは１台のコンピュータに付設されたものとしてよいが、インターネットやＬＡＮ（ローカルエリア・ネットワーク）などのネットワークにて接続された複数のコンピュータによって実現されるものであっても実施可能である。

本システムＳの、契約情報記憶装置１は、上記の記憶装置とシステムソフトとにて構築される。時期検出装置２は、上記の演算装置とシステムソフトとにて構築される。確認対象検出装置３は、上記の演算装置とシステムソフトとにて構築される。データベース接続装置４は、上記の通信装置とシステムソフトとにて構築される。異動検出装置５は、上記の演算装置と記憶装置とシステムソフトとにて構築される。通知装置６は、上記の演算装置と記憶装置とシステムソフトとにて構築される。確認要求装置７は、上記の演算装置と記憶装置と通信装置とシステムソフトとにて構築される。入力装置８は、上記の演算装置と入力機能装置と出力機能装置とシステムソフトとにて構築される。更新装置９は、上記の演算装置とシステムソフトとにて構築される。会計データベース接続装置１０は、上記の通信装置とシステムソフトとにて構築される。表示装置１１は、上記の演算装置と出力機能装置とシステムソフトとにて構築される。

４．データベース構成
本システムＳ（契約情報記憶装置１）が備えるデータベースについて説明する。この実施の形態において、契約情報記憶装置１は、図２へ示す通り、契約書データベースｄｂ１と、注文書データベースｄｂ２と、保存期間データベースｄｂ３と、顧客データベースｄｂ４と、部門データベースｄｂ５と、社員データベースｄｂ６と、最終取引日データベースｄｂ７とを収容している。
この実施の形態において、確認基準日を契約の開始日とする。

契約書データベースｄｂ１は、ａ１）契約書番号（自社）、ａ２）契約書番号（顧客）、ａ３）契約顧客コード、ａ４）現顧客コード、ａ５）契約日、ａ６）契約名称、ａ７）契約本支社コード、ａ８）契約部門コード、ａ９）契約担当者コード、ａ１０）所管本支社コード、ａ１１）所管部門コード、ａ１２）所管担当者コード、ａ１３）解約番号、ａ１４）解約日、ａ１５）保管場所（バーコードまたは契約書の保管棚の番号）、ａ１６）会計番号、の各情報の対を、契約情報ｄとして有する。
上記の、ａ９）契約担当者コード（更に必要に応じて、ａ７）契約本支社コード、ａ８）契約部門コード）が、前記担当情報ｘ１であり、ａ５）契約日が、確認基準日情報ｘ２である。

注文書データベースｄｂ２は、ｂ１）注文書番号（自社）、ｂ２）注文書番号（顧客）、ｂ３）注文顧客コード、ｂ４）現顧客コード、ｂ５）注文日、ｂ６）注文名称、ｂ７）注文本支社コード、ｂ８）注文部門コード、ｂ９）注文担当者コード、ｂ１０）所管本支社コード、ｂ１１）所管部門コード、ｂ１２）所管担当者コード、ｂ１３）解約番号、ｂ１４）解約日、ｂ１５）保管場所（バーコードまたは注文契約書の保管棚の番号）、ｂ１６）会計番号、の各情報の対を、注文情報（契約情報ｄ）として収容する。

保存期間データベースｄｂ３は、ｃ１）契約書保存期間（１０年）、ｃ２）注文書保存期間（７年）、の各情報を、パラメータとして収容する。
顧客データベースｄｂ４は、ツリー構造を採り、ｅ１）顧客コード、ｅ２）顧客名称、ｅ３）開始日、ｅ４）終了日、ｅ５）旧顧客コード、ｅ６）重複フラグ、の各情報の対を、顧客情報として収容する。

部門データベースｄｂ５は、ツリー構造を採り、ｆ１）本支社コード、ｆ２）本支社名称、ｆ３）部門コード、ｆ４）部門名称、ｆ５）開始日、ｆ６）終了日、ｆ７）旧本支社コード、ｆ８）旧部門コード、の各情報の対を、部門情報として保存する。
社員データベースｄｂ６は、ｇ１）社員コード、ｇ２）氏名、ｇ３）所属本支社コード、ｇ４）所属部門コード、ｇ５）開始日、ｇ６）終了日、の各情報の対を、社員情報として保存する。
最終取引データベースｄｂ７は、ｈ１）会計番号、ｈ２）最終日（最終取引日）、ｈ３）金額、の各情報の対を、最終取引情報として収容する。
上記の各データベースが収容する情報に加えて他の情報を収容するものとしても実施可能である。例えば、契約担当者に変動があった場合、以前の（過去の）担当者の情報も、契約情報に付加しても実施可能である。

上記契約書データベースｄｂ１のａ１）契約書番号は、契約を特定する情報である。即ち、このシステムＳを利用する企業において、ａ１）契約書番号が、個々の契約を識別し、契約を特定することを可能とする識別子である。契約書データベースｄｂ１のａ３）契約顧客コードは、契約締結時の（契約を結んだ）顧客を特定する情報（識別子）である。契約書データベースｄｂ１のａ４）現顧客コードは、契約を結んだ顧客に変更があった場合（契約の承継があった場合）、現在の契約相手となっている顧客を特定する情報である。従って、契約相手に変動がない場合は、ａ３）契約顧客コードとａ４）現顧客コードとは等しい。
このａ４）現顧客コードは、顧客データベースｄｂ４が保持するｅ１）顧客コードとリンクしている。
上記のａ１）契約書番号にて特定される契約について、ａ４）現顧客コードから、顧客データベースｄｂ４が保持するｅ１）顧客コードを特定でき、該当する顧客についての情報を（当該顧客データベースｄｂ４から）取得することができる。

企業や部門によって、特定の契約の担当を、社員（契約担当者）に担わせる場合と、部署（契約担当部署）に担わせる場合とが考えられる。契約担当を社員とする場合、上記の社員データベースｄｂ６は、必須の構成である。一方、契約担当を部署とする場合、上記の部門データベースｄｂ５は、必須の構成である。
従って、契約の担当を部署とする場合、社員データベースｄｂ６は、設ける必要がない。
本実施の形態の如く、契約の担当を社員（契約担当者）とする場合、契約書データベースｄｂ１）の特定したａ１）契約書番号に対なすａ９）契約担当者コードと、社員データベースｄｂ６のｇ１）社員コードとは、リンクしており、契約書データベースｄｂ１にて、ａ１）契約書番号を特定することにより、当該ａ１）契約書番号に対なす上記ａ９）契約担当者コードから、社員データベースｄｂ６のｇ１）社員コードを取得して、当該社員の情報の詳細（他の情報）を社員データベースｄｂ６から抽出することができる。

尚、契約の担当を部署（契約担当部署）とする場合、契約書データベースｄｂ１）の特定したａ１）契約書番号に対なすａ７）契約本支社コードと、部門データベースｄｂ５のｆ１）本支社コードとは、リンクしており、契約書データベースｄｂ１にて、ａ１）契約書番号を特定することにより、当該ａ１）契約書番号に対なす上記ａ７）契約本支社コードから、部門データベースｄｂ５のｆ１）本支社コードを取得して、当該部署が属する本支社の情報の詳細（他の情報）を部門データベースｄｂ５から抽出することができる。そして、同様に、契約書データベースｄｂ１の特定したａ１）契約書番号と対なすａ８）契約部門コードと、部門データベースｄｂ５のｆ３）部門コードとは、リンクしており、契約書データベースｄｂ１にて、ａ１）契約書番号を特定することにより、当該ａ１）に対なす上記ａ８）契約部門コードから、部門データベースｄｂ５のｆ３）部門コードを取得して、当該部署の情報の詳細（他の情報）を部門データベースｄｂ５から抽出することができる。ここで、部門データベースｄｂ５が保持する各情報は、前述の通り、ツリー構造（階層構造）を採るものであり、上記ｆ１）本支社コードとｆ３）部門コードとは、上位・下位の関係にある。

部門データベースｄｂ５を社員データベースｄｂ６と併設しておけば、契約担当を社員とする場合においても、契約書データベースｄｂ１）から社員データベースｄｂ６のｇ１）社員コードを特定することによって、当該社員について、社員データベースｄｂ６のｇ３）所属本支社コードやｇ４）所属部門コードから、当該ｇ３）本支社コードやｇ４）所属部門コードに対応する部門データベースｄｂ５のｆ１）本支社コードやｆ３）部門コードを検出可能として、当該社員が所属する本支社やその所属部署についての情報を得ることができる。

５．システムの運用
（１）内部データベースの構築
契約情報記憶装置１が保持する、上記の各データベースｄｂ１〜ｄｂ７（内部データベース）は、原則として、管理者Ｐが、入力ｎして構築しておく。
例えば、新規契約の契約書発生時には、図３（Ａ）に示す通り、管理者Ｐが、実際の（紙文書である）契約書ｋ１（又は注文書ｋ２）を元に、入力装置８を（入力ｎ）操作して、契約情報記憶装置１の契約書データベースｄｂ１（又は注文書データベースｄｂ２）に、新規契約の契約情報ｄを記録する（上記契約書データベースｄｂ１のａ１）〜ａ１６）の情報が記録される）。契約書データベースｄｂ１内の個々の契約情報ｄは、既述の通り、ａ１）契約書番号にて識別される（注文書データベースｄｂ２内の個々の契約情報ｄ（注文情報）は、ｂ１）注文書番号にて識別される）。
この実施例では、契約書と注文書の双方に対応するデータを取り扱うものとして、契約書データベースｄｂ１と注文書データベースｄｂ２の双方が設けられているが、契約書と注文書の何れか一方のみを管理するのに利用する場合は、契約書データベースｄｂ１と注文書データベースｄｂ２の一方のみを備えるものとして実施することができる。

契約書ｋ１（又は注文書ｋ２）が、紙文書として、保管される場合、上記の入力作業後、契約書は、管理者Ｐの作業ｗにより図３（Ｂ）へ示す通り、保管棚ｔに（物理的に）収納される。このように、契約書が紙文書として保管されている場合、上記契約書データベースｄｂ１のａ１５）保管場所の情報は、契約書（紙）が保管されている棚の番号とする。また、契約書そのものにバーコードを付した場合は、上記棚番号に代えて、そのコードとしてもよい。
また、過去の契約を基に契約書データベースｄｂ１を構築する場合において、契約書が、紙文書と共にその保管場所が電子データ化されている場合、上記の通り、手作業での入力が必要であるが、契約書の内容そのものが別途電子データ化されている場合は、当該電子データを利用して、システムＳが上記の契約情報ｄを生成して実施するものとすることができる。但し、このように契約内容が電子データ化されていても、新規契約については、上記の管理者Ｐが、契約書を元に、入力装置８を操作して、契約情報記憶装置１の契約書データベースｄｂ１に、新規契約の契約情報ｄを記録する必要がある。
また、契約情報記憶装置１に別途画像データベースを設け、更に入力装置８の一部としてイメージスキャナなどの画像読取装置を設けて、新規契約書の発生時など、当該契約書を画像情報として、上記画像データベースに取り込み、契約情報ｄとリンクさせても実施可能である。このように、契約情報ｄに、契約書の画像情報をリンクさせることによって、契約内容の確認が即時に行なえ、処分の判断の効率化が容易である。

（２）外部データベース
本システムＳへ、データベース接続装置４にて接続されている、図１に示す外部のデータベースＤ１（以下人事データベースＤ１という。）は、当該企業の総務部或いは人事部が保有する、当該企業の社員に関するデータベースである。その内容（異動情報ｒ３）は、図４（Ｃ）に示す通りである。
人事データベースＤ１が有する異動情報ｒ３は、図４（Ｃ）へ示す通り、少なくとも、社員番号、その社員名、（異動後その社員が属する）新本支社コード、（異動後その社員が属する）新部門コード、（異動前その社員が属した）旧本支社コード、（異動前その社員が属した）旧部門コード、（異動後の勤務）開始日の日付を、備える。図４（Ｃ）に示すように、異動情報ｒ３には、終了日の項目があるが、異動後の社員について終了日の情報はないので空欄である。また、図示はしないが、メールアドレスなどの連絡先の情報も保持する。
本システムＳへ、会計データベース接続装置１０にて接続されている、図１に示す外部の会計データベースＤ２は、当該企業の経理部が保有するデータベースである。その内容（会計情報ｒ４）は図４（Ｄ）へ示す通りである。会計データベースＤ２が有する会計情報ｒ４は、図４（Ｄ）へ示す通り、少なくとも、日付、本支社名、本支社コード、部門名、部門コード、顧客名、顧客コード、金額、種別（１は支払（経費）、２は請求（販売））の各情報を備える。

（３）変更発生時の処理
ここで、契約先の顧客の変動や、本システムＳを利用する企業側の組織変更や人事異動といった現実の事情の変更が発生した際に、本システムＳにて行われる処理について説明する。
ここでは、システムＳを利用する企業において、直接上記の変動に関与する部門から、システムＳを利用する部門へ、変更の通知があるものとして説明する。１）顧客の変更の発生時
１−１）処理の概要
取引先である顧客に変動が生じた場合、管理者Ｐは、顧客と直接関与する部門（他部門）から、図４（Ａ）へ示す顧客変更通知ｒ１を受け取る。顧客変更通知ｒ１を受け取った管理者Ｐによって、図５（Ａ）に示すように、入力装置８（図１）を通じて、システムＳに顧客変更データｈ１が入力される。
上記の顧客変更通知ｒ１の内容は、図４（Ａ）へ示す通り、新顧客コード（新顧客の識別子）、その顧客名、旧顧客コード（旧顧客の識別子）、（新部門の）開始日の日付である。図４（Ａ）において、顧客変更通知ｒ１に「終了日」の項目があるが、新顧客について終了日の情報はないので空欄である。この顧客変更通知ｒ１は、紙文書と電子データの何れであっても実施可能である。
上記において、顧客変更通知ｒ１を基に、管理者Ｐによって、顧客変更データｈ１（図６（Ｃ））が作成される。但し、電子データである顧客変更通知ｒ１をシステムＳが受け付けて、システムＳが顧客変更データｈ１を生成するものとしても実施可能である（その場合、管理者Ｐの介在なしに更新するものとしても実施可能である）。
顧客変更データｈ１の受付に伴って、図５（Ａ）に示す通り、更新装置９（図１）が、契約情報記憶装置１（図１）の、顧客データベースｄｂ４（図２）と、契約書データベースｄｂ１（注文書データベースｄｂ２）とを参照する。そして、更新装置９が、顧客変更データｈ１に沿って、顧客データベースｄｂ４と、契約書データベースｄｂ１（注文書データベースｄｂ２）の各情報を更新ｍ１する。

１−２）処理の流れ
顧客の変更発生時のシステムＳ内での処理のフローについて説明すると、図５（Ｂ）へ示す通り、顧客変更データ受付工程１１０と、顧客データべース更新工程１２０と、契約書（注文書）データベース更新工程１３０とを順次遂行する。
上記の顧客変更データ受付工程１１０において、図５（Ａ）に示すように、システムＳは、入力装置８を通じて、管理者Ｐから、顧客変更データｈ１を受け付ける。
顧客データベース更新工程１２０において、更新装置９は、この顧客変更データｈ１に沿って、顧客データベースｄｂ４の該当する顧客情報を更新する。
上記の契約書データベース更新工程１３０において、更新装置９は、一定の条件に則して、この契約書データベースｄｂ１（契約書データベースｄｂ２）の該当する契約情報ｄを更新する。即ち、更新装置９は、契約書データベースｄｂ１のａ４）現顧客コードと、顧客変更データｈ１の旧顧客コードを比較する。その結果、両者が等しいと判断した場合、更新装置９は、契約書データベースｄｂ１のａ４）現顧客コードを変更する（注文書データベースｄｂ２については、ｂ４）現顧客コードと、顧客変更データｈ１の旧顧客コードを比較し、両者が等しい場合、注文書データベースｄｂ２のｂ４）現顧客コードを変更する）。

１−３）データの更新
図６（Ａ）は、具体的な顧客データベースｄｂ４の内容を示している（ここではモデルとして顧客情報を２件としている）。２件の顧客情報の夫々について、ｅ１）顧客コード（顧客情報の識別子）として「００１００１０１」と「００１００２０１」とが付与されている。顧客コード「００１００１０１」のｅ２）顧客名称は、「○×銀行」であり、契約のｅ３）開始日（顧客となった日）は、「１９８００４０１」即ち１９８０年４月１日である。ｅ４）終了日（顧客でなくなった日或いは顧客が消滅した日）は「９９９９９９９９」であり（特定の日付を指していない。）、この表示は、顧客が存続していることを示している。顧客コード「００１００２０１」のｅ２）顧客名称は、「×○銀行」であり、ｅ３）開始日は、「１９８００４０１」（１９８０年４月１日）であり、ｅ４）終了日は「９９９９９９９９」であり、この顧客も存続している。上記の何れの顧客情報についても、ｅ５）旧顧客コードとｅ６）重複フラグとが空欄（データなし）となっている。

図６（Ｃ）は、上記の顧客変更データｈ１の具体的な内容を示している。
顧客変更データｈ１は、新顧客コード、会社名（顧客名）、旧顧客コード、開始日、終了日の各情報を有する。この図６（Ｃ）に示す例では、両顧客（○×銀行と、×○銀行）に変動がないので、旧顧客コード及び終了日が空欄である。
当初の顧客データベースｄｂ４の内容は、この図６（Ｃ）に示す顧客変更データｈ１の内容を受けて構築されている（このため、図６（Ｃ）に示すデータｈ１は、厳密には、顧客「変更」データではない。但し、ここでは、便宜上、そのように呼ぶ）。
図６（Ｄ）は、２０００年３月３１日に○×銀行と×○銀行とが合併して（消滅し、）翌２０００年４月１日に○×△銀行となった場合の顧客変更データｈ１を示している。この図６（Ｄ）に示す通り、合併前の２顧客が１つの顧客として統合されたため、旧の顧客コードの２件に対応して、顧客情報は新たに２件作成されている。この新しい顧客情報夫々に（最下段とその直上の段）ついて、統合後の新顧客コードとして「００１００１０２」が付されている。そして、○×銀行と×○銀行夫々の顧客コードが旧顧客コードとされ、合併後の○×△銀行が設立された２０００年４月１日を示す「２００００４０１」が開始日の情報として付されている。
一方、消滅した○×銀行と×○銀行を特定する夫々の顧客コード（旧顧客コード）に対して（上二段）、夫々に、統合された２０００年３月３１日を示す「２００００３３１」が終了日の情報として付されている。

上記図６（Ｄ）に示す顧客変更データｈ１を受けて、更新装置９は、契約情報記憶装置１の顧客データベースｄｂ４を、図６（Ｂ）へ示すように、更新ｍ１する（顧客データベース更新工程１２０）。
具体的には、上記の図６（Ｄ）に示す顧客変更データｈ１を受けて、変更装置９により、顧客データベースｄｂ４において、当初のｅ１）顧客コード「００１００１０１」の「００１００２０１」の夫々の、終了日の情報「９９９９９９９９」が上記「２００００３３１」に書き換えられる。
そして、図６（Ｄ）に示す顧客変更データｈ１を受けて、この顧客コード「００１００１０１」と「００１００２０１」とは別に（その下）に新たな顧客情報が２件生成される。この新たな顧客情報の夫々には、顧客変更データｈ１の新顧客コード「００１００１０２」が付され、顧客変更データｈ１において当該新顧客コードに付随する新顧客名称等の各情報が、顧客変更データｈ１から取得され、顧客データベースｄｂ４に生成された上記顧客情報へ付される。
そして、生成された顧客情報に、ｅ６）重複フラグとして「１」が付される。ここでは、ｅ６）重複フラグとして立てられた上記の「１」は、統合であることを示す（同一の顧客コードが複数（２つ）生成されたので、統合と判断される）。上記のように統合（合併）でない場合は、統合と区別して、ｅ６）重複フラグとして「０」が付される。
ここでは、統合（合併）を例示した。一方、単に顧客の名称が変更した場合（実体は変わらない場合）、新たなｅ１）顧客コードを生成せず、当該顧客のｅ２）顧客名称のみ変更する。顧客が複数に分裂した場合（上記統合と逆の場合）分裂後の数に応じて、新たなｅ１）顧客コードを生成する。
そして、上記図６（Ｄ）に示す顧客変更データｈ１を受けて、更新装置９は、契約情報記憶装置１の契約書データベースｄｂ１のａ４）現顧客コードと、顧客変更データｈ１の旧顧客コードとを比較して、両者が一致するとき、契約書データベースｄｂ１のａ４）現顧客コードを顧客変更データｈ１の新顧客コードに変更する（契約書データベース更新工程１３０）。
また、上記図６（Ｄ）に示す顧客変更データｈ１を受けて、更新装置９は、契約情報記憶装置１の注文書データベースｄｂ２のｂ４）現顧客コードと、顧客変更データｈ１の旧顧客コードとを比較して、両者が一致するとき、注文書データベースｄｂ２のｂ４）現顧客コードを顧客変更データｈ１の新顧客コードに変更する（契約書データベース更新工程１３０）。

２）組織変更の発生時
２−１）処理の概要
当該企業内において、（少なくとも契約に拘わる部門に）組織変更が生じた場合、管理者Ｐは、他部門（例えば企画部）から、図４（Ｂ）に示す組織変更通知ｒ２を受け取る。組織変更通知ｒ２を受け取った管理者Ｐによって、図７（Ａ）に示すように、入力装置８（図１）を通じて、システムＳに組織変更データｈ２（図９（Ａ））が入力される。
上記の組織変更通知ｒ２の内容は、図４（Ｂ）へ示す通り、新本支社コード、本支社名、新部門コード（新部門の識別子）、部門名、旧本支社コード、旧部門コード、開始日の日付である。図４（Ｂ）において、組織変更通知ｒ２に「終了日」の表示があるが、新部門について終了日の情報はないので空欄である。この組織変更通知ｒ２は、紙文書であっても、電子データの何れであっても実施可能である。
上記において、組織変更通知ｒ２を基に、管理者Ｐによって、組織変更データｈ２（図９（Ａ））が作成される。但し、電子データである組織変更通知ｒ２をシステムＳが受け付けて、システムＳが組織変更データｈ２を生成するものとしても実施可能である（その場合、管理者Ｐの介在なしに更新するものとしても実施可能である）。
組織変更データｈ２の受付に伴って、更新装置９（図１）が、契約情報記憶装置１（図１）の、部門データベースｄｂ５（図２）と、契約書データベースｄｂ１（注文書データベースｄｂ２）とを参照する。そして、更新装置９が、組織変更データｈ２に沿って、部門データベースｄｂ５と、契約書データベースｄｂ１（注文書データベースｄｂ２）の各情報を更新ｍ２する（図７（Ａ））。
２−２）処理の流れ
組織の変更発生時のシステムＳの処理のフローについて説明すると、図７（Ｂ）へ示す通り、組織変更データ受付工程２１０と、部門データべース更新工程２２０と、契約書（注文書）データベース更新工程２３０とを順次遂行する。
上記の組織変更データ受付工程２１０において、図７（Ａ）に示すように、この実施の形態において、システムＳは、入力装置８を通じて、管理者Ｐから、組織変更データｈ２を受け付ける。
部門データベース更新工程２２０において、更新装置９は、この組織変更データｈ２に沿って、部門データベースｄｂ５の該当する部門情報を更新する。
上記の契約書データベース更新工程２３０において、更新装置９は、一定の条件に則して、この契約書データベースｄｂ１（契約書データベースｄｂ２）の該当する契約情報ｄを更新する。即ち、更新装置９は、契約書データベースｄｂ１のａ１０）所管本支社コードと、組織変更データｈ２の旧本支社コードを比較する。更に、更新装置９は、契約書データベースｄｂ１のａ１１）所管部門コードと、組織変更データｈ２の旧部門コードを比較する。その結果、ａ１０）所管本支社コードと組織変更データｈ２の旧本支社コードとが等しく、尚且つ、ａ１１）所管部門コードと組織変更データｈ２の旧部門コードとが等しいと判断した場合、更新装置９は、契約書データベースｄｂ１のａ１０）所管本支社コードとａ１１）所管部門コードとを変更する（注文書データベースｄｂ２については、ｂ１０）所管本支社コードと組織変更データｈ２の旧本支社コードを比較し、且つ、ｂ１１）所轄部門コードと組織変更データｈ２の旧部門コードを比較し、何れも等しいと判断した場合、注文書データベースｄｂ２のｂ１０）所管本支社コードとｂ１１）所管部門コードとを変更する）。

２−３）データの更新
図８（Ａ）は、具体的な部門データベースｄｂ５の内容を示している（ここではモデルとして「人事」、「総務」、「開発第一」、「開発第二」、「営業」の５部門あるものとしている）。ｆ４）部門名称として、「人事」、「総務」、「開発第一」、「開発第二」、「営業」の名称が付された、５部門の部門情報の夫々について、ｆ３）部門コード（部門情報の識別子）として「００１」〜「００５」が付与されている。何れの部門も当該企業の本社或いは支社（社名ＪＲＩ）に属するので、ｆ１）本支社コードとして、何れの部門についても共通して、「００１」が付され、ｆ２）本支社名称（ＪＲＩ）が付されている。ｆ５）開始日は、何れも「１９８００４０１」即ち１９８０年４月１日である。また、ｆ６）終了日は何れも「９９９９９９９９」であり、この表示は、上記５つの部門の何れも存続していることを示している。上記の何れの部門情報についても、ｆ７）旧本支社コードとｆ８）旧部門コードとが空欄（データなし）となっている。

図９（Ａ）は、上記の組織変更データｈ２の具体的な内容を示している。
組織変更データｈ２は、新本支社コード、新本支社名称（自社名）、新部門コード、新部門名称、旧本支社コード、旧部門コード、開始日、終了日の各情報を有する。この図９（Ａ）に示す例では、旧本支社コード、旧部門コード及び、終了日の情報が空欄（データなし）となっている。これは、「人事」、「総務」、「開発第一」、「開発第二」、「営業」の各部門は、１９８０年４月１日に、それ以前の他部門からの引継ぎでなく、新たに発足しており、現在に至るまで存続していることを示している（存続に関して変更事項がないことを示している）。
当初の部門データベースｄｂ５の内容は、この図９（Ａ）に示す組織変更データｈ２の内容を受けて構築されている（このため、図９（Ａ）に示すデータｈ２は、厳密には、組織「変更」データではない。但し、ここでは、便宜上、そのように呼ぶ）。

図９（Ｂ）は、上記の「開発第一」と「開発第二」が統合され新たに「システム開発」部門が発足した際、入力される組織変更データｈ２を示している。
即ち、図９（Ｂ）に示す組織変更データｈ２において、「開発第一」の上記ｆ３）部門コード「００３」がｆ８）旧部門コードとして付され、そのｆ１）本支社コード「００１」が旧本支社コードとして付され、「開発第二」の上記ｆ３）部門コード「００４」がｆ８）旧部門コードとして付され、そのｆ１）本支社コード「００１」が旧本支社コードとして付されている。そして、何れの部門についても、統合による消滅日（１９８０年９月３０日）を示す終了日の情報「１９８００９３０」が付されている。
更に、当該組織変更データｈ２には、統合により新たに発足した「システム開発」を新部門名称として、新部門コード「００６」が付された部門情報が２件設けられている。これは、上記旧部門となった「開発第一」と「開発第二」の２部門に対応して、２件設けられたものであり、何れも、そのｆ１）本支社コードが旧本支社コードとして付され、夫々のｆ３）部門コードが旧部門コードとして付されている。そして、「システム開発」部の上記両部門情報について、発足日である１９８０年４月１日を示す「１９８００４０１」が開始日の情報として付されている。

上記図９（Ｂ）に示す組織変更データｈ２を受けて、更新装置９（図１）は、契約情報記憶装置１（図１）の部門データベースｄｂ５（図２）を、図８（Ｂ）へ示すように、更新ｍ２する（図７（Ｂ）に示す部門データべース更新工程２２０）。
具体的には、上記の図９（Ｂ）に示す組織変更データｈ２を受けて、変更装置９により、部門データベースｄｂ５の当初の「開発第一」部及び「開発第二」部の部門情報（ｆ３）部門コード「００３」及び「００４」の部門情報）夫々のｆ６）終了日の情報「９９９９９９９９」が、消滅日である１９８０年９月３０日を示す「１９８００９３０」に書き換えられる（図８（Ｂ））。
また、図９（Ｂ）に示す組織変更データｈ２を受けて、新たにｆ３）部門コード「００６」を持つ２つの部門情報が生成される。この新たな、部門情報の夫々には、組織変更データｈ２が有する上記の各情報から、夫々、ｆ１）本支社コード「００１」、ｆ２）本支社名称「ＪＲＩ」、ｆ４）部門名称「システム開発」、ｆ５）開始日「１９８０１００１」、ｆ６）終了日「９９９９９９９９」（継続中）、ｆ７）旧本支社コード「００１」、ｆ８）旧部門コード「００３」及び「００４」が付される。
そして、上記図９（Ｂ）に示す組織変更データｈ２を受けて、更新装置９は、契約情報記憶装置１の契約書データベースｄｂ１のａ１０）所管本支社コードと、組織変更データｈ２の旧本支社コードとを比較する。また、更新装置９は、契約情報記憶装置１の契約書データベースｄｂ１のａ１１）所管部門コードと、組織変更データｈ２の旧部門コードとを比較する。上記の何れも一致する場合、更新装置９は、契約書データベースｄｂ１のａ１０）所管本支社コード及びａ１１）所管部門コードを組織変更データｈ２の新本支社コード及び新部門コードに変更する。
情報記憶装置１の注文契約書データベースｄｂ２のｂ１１）所管部門コードと、組織変更データｈ２の旧部門コードとを比較する。上記の何れも一致する場合、更新装置９は、注文書データベースｄｂ２のｂ１０）所管本支社コード及びｂ１１）所管部門コードを組織変更データｈ２の新本支社コード及び新部門コードに変更する（契約書データベース更新工程２３０）。

以上旧の２部門が新１部門に統合される場合を例示した。次に、部門の数が変わらず、旧部門がそのまま新部門に変更された場合について説明する。
例えば、上記において「営業」部（ｆ３）部門コード）が廃止され、新たに発足した「営業コンサル」部が当該「営業」部の業務を引き継ぐ場合（但し、単なる名称変更ではなく実体も変わっている場合を示す。）、図９（Ｃ）に示す組織変更データｈ２が作成される。この組織変更データｈ２は、上記「営業」部を示すｆ３）部門コード「００５」を旧部門コードとして有し、また、この「営業」部のｆ１）本支社コード「００１」を旧本支社コードとして有する。そして、消滅した日（１９８１年３月３１日）を示す「１９８１０３３１」が最終日の情報として付されている。
更に、図９（Ｃ）に示す組織変更データｈ２には、新たに発足した「営業コンサル」を新部門名称として、新部門コード「００７」が付された部門情報が１件設けられている。これは、上記旧部門となった「営業」部の業務を引き継ぐものとして設けられたものであり、そのｆ１）本支社コードが旧本支社コードとして付され、夫々のｆ３）部門コードが旧部門コードとして付されている。そして、「営業」部の上記両部門情報について、発足日である１９８１年４月１日を示す「１９８１０４０１」が開始日の情報として付されている。

上記図９（Ｃ）に示す組織変更データｈ２を受けて、更新装置９は、契約情報記憶装置１の部門データベースｄｂ５を、図８（Ｃ）へ示すように、更新ｍ２する（部門データべース更新工程２２０）。
具体的には、上記の図９（Ｃ）に示す組織変更データｈ２を受けて、変更装置９により、部門データベースｄｂ５の当初の「営業」部の部門情報（ｆ３）部門コード「００５」の部門情報）のｆ６）終了日の情報「９９９９９９９９」が消滅日である１９８１年３月３１日を示す「１９８１０３３１」に書き換えられる（図８（Ｃ））。
また、図９（Ｃ）に示す組織変更データｈ２を受けて、新たにｆ３）部門コード「００７」を持つ部門情報が１件生成される。この新たな、部門情報には、組織変更データｈ２が有する上記の各情報から、夫々、ｆ１）本支社コード「００１」、ｆ２）本支社名称「ＪＲＩ」、ｆ４）部門名称「営業コンサル」、ｆ５）開始日「１９８１０４０１」、ｆ６）終了日「９９９９９９９９」（継続中）、ｆ７）旧本支社コード「００１」、ｆ８）旧部門コード「００５」が付される。
この図９（Ｃ）に示す組織変更データｈ２による契約書データベース更新工程２３０における契約書データベースｂｄ１及び注文書データベースｄｂ２に対する処理は、図８（Ｂ）組織変更データｈ２によるものと同様である（省略する）。

３）人事異動の発生時
３−１）処理の概要
当該企業内において、契約担当者に人事異動が生じた場合に、人事を管理する他部門（総務或いは人事部）が、当該他部門の人事データベースＤ１（図１及び図４（Ｃ））の変更を行う。この人事データベースＤ１の変更を、本システムＳの異動検出装置５が、データベース接続装置４を通じて検出する。そして、特定した変更から、異動検出装置５は、図１３（Ｃ）に示す異動データｉを生成する。異動データｉは、人事異動があった社員に関するデータである。
図１へ示す通り、上記の異動データｉは、通知装置６にて異動検出装置５から更新装置９へ送られる。そして、図１０（Ａ）へ示す通り、更新装置９は、異動データｉに沿って、契約情報記憶装置１の社員データベースｄｂ６を更新ｍ３する。更に上記の異動データｉは、通知装置６にて異動検出装置５から確認要求装置７へ送られる。確認要求装置７は、通知装置６から上記異動データｉを受けて、データベース接続装置４を通じて上記外部のデータベースＤ１を参照し、上記変更後の契約担当者（異動があった社員）の電子メールアドレスなどの連絡先（図示しない。図４（Ｃ）に示す情報は、データベースＤ１が有する情報の一部と考えればよく、他にこのような連絡先の情報を有するものとする。或いは、データベースＤ１にリンクする別途のデータベースを設けて、当該連絡先を収容するものとしても実施可能である。）を取得し、電子メールで更新後の契約担当者Ｑへ、後述する、確認対象検出装置３にて識別した契約情報ｄを通知ｍ４する。

図１０（Ｂ）へ示す通り、契約担当者として、上記の通知ｍ４を受けた者は、通知された（担当すべき）契約情報ｄの内容を確認して、上記において異動検出装置５と更新装置９とにて行われた更新が適切でないと判断した場合、必要な修正（更新ｍ５）を行う。
上記の異動検出装置５は、契約情報記憶装置１の契約書データベースｄｂ１（及び注文書データベースｄｂ２）についても、担当特定情報ｘ１変更の入力を監視しており、上記の更新ｍ５により、前任契約担当者と後任契約担当者に変更があったとき、異動検出装置５は、通知手段６を通じて、確認要求装置７により、その契約情報ｄを後任契約担当者（担当者Ｑ）へ通知ｍ６する。通知ｍ６を受けた後任契約担当者は、関連部門（や必要に応じて顧客）に担当となったことを告知（引継ぎｍ７）すればよい。

３−２）処理の流れ
上記の処理の流れについて説明する。
図１１へ示す通り、上記の人事異動の処理は、異動検出工程３００と、異動データ取得工程３１０と、通知工程３２０と、担当特定情報更新工程３３０と、後任通知工程３４０とを、順に遂行するものである。

図１２（Ａ）へ示す通り、上記異動検出工程３００は、監視工程３０１と、比較工程３０２と、特定工程３０３と、異動データ生成工程３０４とを順次遂行する。
異動検出工程３０１においては、異動検出装置５は、人事データベースＤ１に対する更新の入力を監視し、人事データベースＤ１に対する更新の入力を検出する。この更新の入力の検出は、人力を直接検出する場合の他、最終入力のタイムスタンプの更新（日付の変更）を検出するなど、間接的に更新を確認できるものを検査することにより行うものであっても実施可能である。
異動検出装置５は、上記の人事データベースＤ１に対する更新の入力があったことを確認すると、次の比較工程３０２にて、更新後の人事データベースＤ１の内容（異動情報ｒ３）と社員データベースｄｂ６の内容とを比較する。当該比較の結果により、特定工程３０３にて、人事データベースＤ１に行われた変更の内容を特定する。そして、異動データ生成工程３０４において、異動検出装置５は、特定した変更から、異動があった社員について、図１３（Ｄ）に示す異動データｉを生成する。

異動データ取得工程３１０は、図１２（Ｂ）へ示す通り、第１伝達工程３１１と、社員データベース更新工程３１２と、第２伝達工程３１３と、連絡先取得工程３１４とを順次遂行する。
第１伝達工程３１１において、上記の異動データｉは、通知装置６にて異動検出装置５から更新装置９へ送られる。異動データｉを受け取った更新装置９は、社員データベース更新工程３１２において、異動データｉに沿って、契約情報記憶装置１の社員データベースｄｂ６を更新ｍ３する。第２伝達工程３１３において、上記の異動データｉは、通知装置６にて異動検出装置５から確認要求装置７へ送られる。連絡先取得工程３１４において、確認要求装置７は、通知装置６から上記異動データｉを受けて、データベース接続装置４を通じて上記人事データベースＤ１を参照し、上記変更後の契約担当者（異動があった社員）の電子メールアドレスなどの連絡先の情報を取得する。

上記の通知工程３２０において、確認要求装置７は、上記の連絡先の情報により異動のあった契約担当者Ｑ（対象社員）へ、後述する、確認対象検出装置３にて識別した契約情報ｄを電子メールにて通知ｍ４する。通知の方法については電子メールに限定するものではなく、インターネットのｗｅｂ等、他の手段を用いて通知するものとしても実施可能である。

上記の担当特定情報更新工程３３０では、人がシステムＳに対して行う作業が中心となる。即ち、契約担当者Ｑとして上記の通知ｍ４を受けた者は、通知された（担当すべき）契約情報ｄの内容を確認して、上記において異動検出装置５と更新装置９とにて行われた更新が適切でないと判断した場合、必要な修正（更新ｍ５）を行う。具体的には、更新ｍ３後の、契約情報ｄ中、担当者の所属部署が適切でないと判断した場合、契約データベースｄｂ１にある契約情報ｄ（或いは注文書データベースｄｂ２）中の該当するａ７）契約本支社コード（ｂ７）注文本支社コード）及びａ８）契約部門コード（ｂ８）注文部門コード）とを修正（更新ｍ５）する。当該修正は、担当者Ｑが直接入力装置８を操作して行うものとしてもよく、また、管理者Ｐに連絡して、管理者Ｐに行わせるものとしても実施可能である（図１）。更には、インターネット等や専用回線（ＬＡＮ含む。）といった通信手段を使用して、担当者Ｑ自ら、契約書データベースｄｂ１（或いは注文書データベースｄｂ２）の該当する契約情報ｄを更新するものとしても実施可能である（図示しない）。

後任通知工程３４０は、担当特定情報更新工程３３０における更新ｍ５の結果により遂行される。即ち、図１２（Ｃ）へ示す通り、後任通知工程３４０は、修正検出工程３４１と、判定工程３４２と、通知工程３４３とにて構成される。
上記の異動検出装置５は、社員データベースｄｂ１にて、通知した契約担当者の契約情報ｄについて少なくとも担当特定情報ｘ１を取得し保持する。
上記の異動検出装置５は、契約情報記憶装置１の契約書データベースｄｂ１（及び注文書データベースｄｂ２）についても、担当特定情報ｘ１変更の入力を監視しており、異動検出装置５は、修正検出工程３４１にて、上記の更新ｍ５の入力を検出する。そして、判定工程３４２において、異動検出装置５は、契約書データベースｄｂ１（或いは注文書データベースｄｂ２）を参照して、更新後の担当者特定情報ｘ１と、保持している更新ｍ５前の担当特定情報ｘ１とを比較する。具体的には、異動検出装置５は、更新ｍ５前のａ１１）所管担当者コードと、更新ｍ５後のａ１１）所管担当者コードとを比較する。両者が一致した場合、全工程は終了する。両者が一致しない場合、更新ｍ５後の担当者を後任担当者Ｑと判断して、通知工程３４３にて、当該後任担当者Ｑへ更新ｍ５後の契約情報ｄを、通知手段６を通じて、確認要求装置７により、後任契約担当者（担当者Ｑ）へ通知ｍ６する。この通知ｍ６は、電子メールで行う。但し、通知ｍ６の方法については電子メールに限定するものではなく、インターネットのｗｅｂ等、他の手段を用いて通知するものとしても実施可能である。
通知ｍ６を受けた後任契約担当者は、関連部門（や必要に応じて顧客に）ｍ７に担当となったことを告知（引継ぎｍ７）すればよい。

３−３）データの更新
以下社員データベースｄｂ６の一部を例示し、社員の異動による所属部署変更の更新ｍ３の例を示す。
図１３（Ａ）は、具体的な社員データベースｄｂ６の内容を示している（ここではモデルとして「総研太郎」という氏名の社員を対象として説明する）。具体的には、社員データベースｄｂ６は、氏名が「総研太郎」の社員について、ｇ１）社員コード「３１１００１」、ｇ２）氏名「総研太郎」、ｇ３）所属本支社コード「００１」、ｇ４）所属部門コード「００１」、配属のｇ５）開始日を示す「１９８００４０１」、配属のｇ６）終了日「９９９９９９９９」（異動なし）、の各情報を、社員情報として保存する。

図１３（Ｃ）は、上記の異動データｉの具体的な内容を示している。
異動データｉは、社員番号、社員氏名、新本支社コード、新部門コード、旧本支社コード、旧部門コード、開始日、終了日の各情報を有する。社員データベースｄｂ６については、図１３（Ｃ）に示す異動データｉの内容を受けて構築される（このため、図１３（Ｃ）に示すデータｉは、厳密には、社員の「異動」データではない。但し、ここでは、便宜上、そのように呼ぶ）。
この図１３（Ｃ）に示す例では、旧本支社コード、旧部門コード及び、終了日の情報が空欄（データなし）となっている。これは、それ以前に異動がなかったことを示している。

図１３（Ｄ）に示す異動データｉは、人事異動により、社員「総研太郎」の所属部署が変わったことを示している。即ち、図１３（Ｄ）に示す異動データｉは、新部門コードが「００２」となり、旧本支社コード「００１」、旧部門コード「００１」と、終了日「１９８００５３１」を備える。他の情報については、図１３（Ｃ）に示すものと同様である。これにて、社員「総研太郎」について、同一本支社内において、旧部門００１から新部門００２へ、旧部門の所属最終日を１９８０年５月３１日として、異動があったことが分かる。

上記図１３（Ｄ）に示す異動データｉを受けて、更新装置９は、契約情報記憶装置１の社員データベースｄｂ６を、図１３（Ｂ）へ示すように、更新ｍ３する。具体的には、上記の図１３（Ｄ）に示す異動データｉを受けて、変更装置９は、社員データベースｄｂ６の当初のｇ１）社員コード「３１１００１」の（社員「総研太郎」の）社員情報の「終了日」を、上記１９８０年５月３１日を示す「１９８００５３１」に変更する。
そして、同一ｇ１）社員コード「３１１００１」の新たな社員情報が生成される（図１３（Ｂ）に示す社員データベースｄｂ６の最下段）。この新たな社員情報は、ｇ４）所属部門コードとして「００２」が付されており、上記１９８０年５月３１日の翌１９８０年６月１日を示す「１９８００６０１」がｇ５）開始日として付されている。また、当該社員情報のｇ６）終了日には継続を示す「９９９９９９９９」が付されている。

前述の担当特定情報更新工程３３０において、確認要求装置７からの要求を表示装置１１に表示させて、担当者が、前述の入力装置８から入力作業を行うものとして実施することもでき（この場合図１のＰを担当者Ｑと考えればよい。）、また、このような表示装置１１や入力装置８と同様にシステムＳに接続された、別途の端末（図示しない。）を用いて、担当者が、当該肯定における処理を行うこともできる（図１の一点鎖線）。そのような入力の支援を行うインターフェースとして、上記端末画面或いは表示装置１１の備えるディスプレイの画面の好ましい実施の形態について、説明する。
上記の支援画面及び入力手段（入力装置８の一部を構成）として、システムＳは、図１５に示す支援画面Ｇ１を提供する。この支援画面Ｇ１は、画面を利用する担当者Ｑが担当する契約或いは注文の一覧の表示ａと、一覧に表示された契約情報に対応して設けられた変更ボタンｂとを備える。当該一覧の表示ａは、契約書データベースｄｂ１及び注文書データベースｄｂ２から、当該担当者に関するものを抽出して行う。表示ａを見た担当者Ｑは、内容が適切でない（担当するのが適切でない）ものを発見した場合、当該表示ａをキーボード（入力装置８の一部を構成）の入力手段を用いて編集する。そして該当する契約情報のボタンｂをマウスなどの入力手段（入力装置８の一部を構成）でクリックすることにて、編集の内容を確定する（更新ｍ３）。

尚、上記の顧客の変更や、組織変更の場合も、管理者Ｐの作業を介さずに、人事異動の更新ｍ３と同様に外部のデータベースを利用して、自動的に更新を行うものとしても実施可能である。

（４）契約書等の処分の確認
社内規定或いは法定の保存期間（契約日からの１０年、注文日から７年）を経過した契約書又は注文書について、実際に破棄してよいか否かの判断を確実に行うために、このシステムＳを運用することができる。
１）概要
前記の時期検出装置２は、セットされた間隔にて、定期的に確認対象検出装置３を起動する。この実施の形態において、セットする間隔を６ヶ月とし、６ヶ月毎に確認対象検出装置３が、時期検出装置２によって起動される。
但し、このような起動の間隔は、６ヶ月に限定するものではなく、１年或いはそれ以外のサイクルにて起動するものとしても実施可能である。
起動された確認対象検出装置３は、契約情報記憶装置１の契約書データベースｄｂ１が保持する契約情報ｄ...ｄ夫々の、ａ５）開始日（確認基準日情報ｘ２）と、時期検出装置２の時計が示す現在の日付とを、保存期間データベースｄｂ３が保持するｃ１）契約書保存期間を参照しつつ比較し、確認時期の到来した契約情報ｄと確認時期の到来していない契約情報ｄとを識別する。
また、上記にて、起動された確認対象検出装置３は、契約情報記憶装置１の注文書データベースｄｂ２が保持する注文情報（契約情報ｄ...ｄ）夫々の、ａ５）契約日（確認基準日情報ｘ２）と、時期検出装置２の時計が示す現在の日付とを、保存期間データベースｄｂ３が保持するｃ２）注文書保存期間を参照しつつ比較し、確認時期の到来した注文情報と確認時期の到来していない注文情報とを識別する。
この実施の形態において、上記の、契約書データベースｄｂ１の検査と注文書データベースｄｂ２の定期検査は、同時に行われる。但し、両データベースｄｂ１，ｄｂ２の定期検査は、別々の時期に行われるものとしても実施可能である。また、この実施の形態において、何れも検査サイクルを上記の６ヶ月としたが、異なるサイクルにて検査するものとしても実施可能である。

上記の確認対象検出装置３による検査は、契約書ｋ１について、契約日から１０年（契約書保存期間）保存するとした場合、確認対象検出装置３が、契約日（確認基準日情報ｘ２）にｃ１）契約書保存期間の１０年を加算した日付と上記現在の日付との大小を比較する。そして、当該加算後の日付が、現在の日付と同一、又は現在の日付を過ぎている（現在の日付よりも大となっている）場合、確認対象検出装置３は、当該契約情報Ｄにフラグを付加する（フラグを立てる）。
注文についても同様の処理を行う。

２）処分確認の流れ
以下、当該システムの運用の流れについて説明する。
このシステムＳにおける処分確認方法は、図１４へ示す通り、定期起動工程４００と、検査工程４１０と、確認要求工程４２０とを備える。

２−１）定期起動工程
定期起動工程４００において、自己起動工程４０１と、検査日判定工程４０２とが順次遂行される。
前述の時期検出装置２は、検査日（或いは前回検査日から次回検査日までの期間）の情報がセットされたセット部と、時計と、自己起動部と、起動喚起部とを備える。
自己起動工程４０１において、時期検出装置２は、自己起動部によって毎日起動する。そして検査日判定工程４０２において、起動した時期検出装置２は、セット部にセットされた検査日と時計の日付とを比較し、検査日であるか否か判断する。その結果、検査日でない場合と判断すると終了する。検査日と判断した場合、次の検査工程４１０へ移行する。

２−２）検査工程
検査工程４１０において、定期検査工程４１１と、判定工程４１２と、識別工程４１３が、順次遂行される。
定期検査工程４１１において、時期検出装置２の起動喚起部が、確認対象検出装置３を起動させる。確認対象検出装置３は、判定工程４１２において、契約書データベースｄｂ１（及び注文書データベースｄｂ２）の各契約情報ｄを順次検査する。このとき、確認対象検出装置３は、保存期間データベースｄｂ３を参照して、ｃ１）契約書保存期間（１０年）の情報を取得し、契約書データベースｄｂ１の契約情報ｄの有するａ５）契約日（確認基準日情報ｘ２）にｃ１）契約書保存期間の１０年を加算した日付と上記現在の日付との大小を比較する。
各契約情報ｄについて、順次上記検査を行う。
判定工程４１２において、確認対象検出装置３は、ａ５）契約日（確認基準日情報ｘ２）にｃ１）契約書保存期間の１０年を加算した日付について、上記現在の日付よりも大きいと判断した場合、識別工程４１３にて、契約書データベースｄｂ１（及び注文書データベースｄｂ２）中の当該契約情報ｄにフラグを付加する（フラグを立てる）。
但し、１０年経過の直前時期（例えば１週間前）をしきい値として上記の判定を行うものとしても実施可能である。また、経過日より後日（例えば１週間後）を当該しきい値としてもよい。
注文書ｋ２についても、注文日から７年（注文書保存期間）保存するとした場合、確認対象検出装置３が、注文日（確認基準日情報ｘ２）に７年加算した日付と上記現在の日付との大小を比較するものとして、上記と同様の処理を行う。
また、書類の保存期間は、上記１０年や７年に限定するものではなく、社内規定を採用するなど、変更可能である。従って、法定の契約書保存期間の１０年を１１年として、或いは注文書保存期間の７年を８年として実施することも可能である。

２−３）確認要求工程
上記の識別工程４１３の処理が完了することにより、確認要求工程４２０へ移行する。確認要求工程４２０において、確認対象検出装置３は、契約書データベースｄｂ１（及び注文書データベースｄｂ２）を参照し、識別された契約情報ｄを通知手段６にて確認要求装置７へ送る。
確認要求装置７は、電子メールによって、上記識別された契約情報を担当者Ｑに通知する。この通知にて、担当者に契約書を破棄してよいかどうかの判断を促すことができる。この定期検査において、担当者Ｑに送られる識別された確認情報は、フラグを付されたもののみとすることができる。但し、フラグが付されていない契約情報と共にフラグが付された契約情報を送ることも可能である。
尚、前述の人事異動時の確認要求に際しては、フラグが付されていない契約情報と共にフラグが付された契約情報を送るのが好ましい。

上記において、確認要求は、管理者Ｐを介さずに、システムが自動的に行うものとしたが、確認要求装置７による確認要求を先ず管理者Ｐに発するものとし、管理者Ｐから、担当者Ｑに処分の確認を促すものとしても実施可能である。
このように管理者Ｐを介する場合、確認要求装置７からの要求を表示装置１１に表示させて、管理者Ｐが、入力装置８から担当者への通知の作業を行うものとして実施することもできる。そのような作業の支援を行うインターフェースとして、表示装置１１の備えるディスプレイの画面の好ましい実施の形態について、説明する。
上記の支援画面及び入力手段（入力装置８の一部を構成）として、システムＳは、図１６に示す支援画面Ｇ２を提供する。

この支援画面Ｇ２は、一覧表示ボタンｃと、当該一覧ボタンｃのクリックにて表示される契約情報一覧ｆと、当該契約情報一覧ｆ中の各契約情報に対応する確認ボタンｅとを備える。一覧表示ボタンｃをマウスでクリックすることにて、契約情報一覧ｆを表示させることができる。契約情報一覧ｆの表示により、管理者Ｐは、上記においてフラグを付した契約情報ｄの内容を見ることができる。フラグにて識別した契約一覧の表示ｆは、契約書データベースｄｂ１及び注文書データベースｄｂ２から、フラグが付されたものを抽出して行う。そして、処分するのに担当者へ確認をとることが必要であると判断した契約情報ｄについて、対応する確認ボタンｅをクリックする。確認ボタンｃのクリックにて、確認要求装置７は、担当者Ｑへ上記確認の通知を行う。
尚、図示はしないが、画像データベースを設けて、スキャナ等で読み込んだ契約書の画像情報を収納して、当該画像情報を、契約書データベースｄｂ１の対応する契約情報ｄにリンクさせ、上記契約情報一覧ｆから当該画像データの閲覧を可能としても、処分の判断をより円滑且つ的確に行える点で有利である。

（５）会計データベースとの連携
会計データベースＤ２が有する会計情報ｒ４は、少なくとも、図４（Ｄ）へ示す通り、少なくとも、日付、本支社名、本支社コード、部門名、部門コード、顧客名、顧客コード、金額、種別の各情報を備える。
既述の顧客データベースｄｂ４や部門データベースｄｂ５と同様の方法にて、当該会計データベースＤ２を基に、前述の最終取引データベースｄｂ７を構築し、また更新する。即ち、最終取引データベースｄｂ７は、最終取引情報として、ｈ１）会計番号、ｈ２）最終日（最終取引日）、ｈ３）金額、の各情報の対を、上記会計データベースＤ２から得た会計データにて構築し、更新する。
そして、契約書データベースｄｂ１や注文書データベースｄｂ２のａ１６）会計番号（ｂ１６）会計番号）と、上記最終取引情報のｈ１）会計番号とをリンクさせ、上述の画面Ｇ２において、契約情報一覧ｆから閲覧可能とすることができる。これにて、より確実な判断が行える。

６．その他
上記において、契約担当を社員とし、社員の人事異動時をトリガとして、契約情報の確認（見直し）が行えるものとした。この他、契約担当は、部署としても実施可能である。この場合、上記の人事異動時の処理に代え、組織変更時が、上記の確認のトリガとなる。

７．総括
本願発明に係るシステムＳを利用することにより、特に、以下のＡ〜Ｄに示す利点がある。
Ａ．人事異動データとの連携機能
組織変更や契約書・注文書の担当者に異動があった場合、自動的に対象案件を抽出し、担当者へ変更を促す連絡をする。その結果担当者不明の契約書がなくなる。
Ｂ．会計データとの連携機能
最新の会計データを表示させ、契約書破棄の判断材料の一つとして情報提供可能になる。
Ｃ．破棄対象契約書 抽出・確認機能
破棄可能な契約書（１０年経過）及び、注文書（７年経過）を一覧表示させ、担当者に、円滑且つ確実に、確認の連絡をすることができる。
Ｄ．修正機能
システムＳが自動的に行った処理（更新）に対して、オペレータ（管理者Ｐ又は契約担当者Ｑ）が見直し、入力装置を通じて、修正を施すことができる。例えば、基準日を契約終了日とした場合、契約より３年（保存期間到達前）で解約されたものについて、契約終了日が付されないため、破棄の機会がなく、書類が残存することになるが、オペレータが、そのような解約の情報を取得している場合、入力装置を通じて上記の通り対処することができる。

本願発明に係るシステムのシステム構成を示す説明図である。 図１の要部説明図である。 （Ａ）は契約書（注文書）からデータベースを構築する手順を示す説明図であり、（Ｂ）はその紙文書である契約書（注文書）の保管について示す説明図である。 （Ａ）は本システムＳが他部門から受け取る顧客変更通知ｒ１の説明図であり、（Ｂ）は本システムＳが他部門から受け取る組織変更通知ｒ２の内容を示す説明図であり、（Ｃ）は外部のデータベースＤ１の内容を示す説明図であり、（Ｄ）は会計データベースＤ２の内容を示す説明図である。 （Ａ）は顧客に変更が生じた際の本システムの処理の概要を示す説明図であり、（Ｂ）はその処理の流れを示す説明図である。 （Ａ）は顧客データベースｄｂ４の内容を示す説明図であり、（Ｂ）は更新後の当該顧客データベースｄｂ４の内容を示す説明図であり、（Ｃ）は当初の顧客データベースｄｂ４の構築に用いられる顧客変更データｈ１の内容を示す説明図であり、（Ｄ）は（Ｂ）に示す顧客データベースｄｂ４の更新に用いられる顧客変更データｈ１の内容を示す説明図である。 （Ａ）は組織変更が生じた際の本システムの処理の概要を示す説明図であり、（Ｂ）はその処理の流れを示す説明図である。 （Ａ）は部門データベースｄｂ５の内容を示す説明図であり、（Ｂ）は部門統合の組織変更データｈ２による変更後の部門データベースｄｂ５の内容を示す説明図であり、（Ｃ）は部門変更の組織変更データｈ２による変更後の部門データベースｄｂ５の内容を示す説明図である （Ａ）は当初の部門データベースｄｂ５の構築に用いられる顧客変更データｈ２の内容を示す説明図であり、（Ｂ）は部門統合の組織変更データｈ２の内容を示す説明図であり、（Ｃ）は部門変更の組織変更データｈ２の内容を示す説明図である。 （Ａ）は、人事異動が生じた際の本システムの処理の概要を示す説明図であり、（Ｂ）は通知を受けた契約担当者における処理を示す説明図である。 図１０に示す処理の流れを示す説明図である。 （Ａ）〜（Ｃ）は、図１１に示す工程の要部説明図である。 （Ａ）は社員データベースｄｂ６の内容の例を示す説明図であり、（Ｂ）は更新後の社員データベースｄｂ６の内容の例を示す説明図であり、（Ｃ）は（Ａ）の社員データベースｄｂ６の構築に利用した異動データｉの内容を示す説明図であり、（Ｄ）は（Ｂ）に示す更新に利用した異動データｉの内容を示す説明図である。 （Ａ）〜（Ｃ）は、図１１に示す工程の要部説明図である。 担当特定情報更新工程３３０を支援する画面の説明図である。 図１６は、管理者の通知作業を支援する画面の説明図である。

符号の説明

１ 契約情報記憶装置
２ 時期検出装置
３ 確認対象検出装置
４ データベース接続装置
５ 異動検出装置
６ 通知装置
７ 確認要求装置
８ 入力装置
９ 担当更新装置
１０ 会計データベース接続装置
１１ 表示装置

Claims (8)

1. 少なくとも、契約情報記憶装置と、時期検出装置と、確認対象検出装置とを備え、
   契約情報記憶装置は、個々の契約について、少なくとも、契約担当者又は契約担当部署を特定する担当情報と、契約開始日等の確認基準日情報とを、契約情報として保持するものであり、
   時期検出装置は、時計を備え、定期的に、確認対象検出装置を起動するものであり、
   確認対象検出装置は、契約情報記憶装置が保持する契約情報夫々の、確認基準日情報と現在の日付とを比較し、確認時期の到来した契約情報と確認時期の到来していない契約情報とを識別することを特徴とする契約管理システム。
2. データベース接続装置と、異動検出装置と、通知装置と、確認要求装置とを備え、
   データベース接続装置は、人事管理データベース等の外部のデータベースを本システムに接続するものであり、
   異動検出装置は、契約情報記憶装置を参照すると共に上記のデータベース接続装置を通じて上記外部のデータベースを参照し、人事異動や組織変更などの契約担当者や契約部署を特定する情報の変更を検出するものであり、
   通知装置は、確認要求装置に、異動検出装置が検出した変更後の情報を通知するものであり、
   確認要求装置は、通知装置から上記通知を受けて、データベース接続装置を通じて上記外部のデータベースを参照し上記変更後の契約担当者又は契約担当部署の連絡先を取得し、当該変更後の契約担当者又は契約担当部署へ、確認対象検出装置にて識別した契約情報を通知することを特徴とする請求項１記載の契約管理システム。
3. 入力装置と、担当更新装置とを備え、
   入力装置は、少なくとも担当情報の入力を受け付け、
   担当更新装置は、入力装置が受け付けた担当情報にて、契約情報記憶装置が保持する契約情報中の担当情報を、上記確認要求装置による通知を受けた変更後の契約担当者又は契約担当部署の確認後の内容に沿ったものに、更新することを特徴とする請求項２記載の契約管理システム。
4. 異動検出装置と、通知装置と、担当更新装置とを備え、
   異動検出装置は、契約情報記憶装置を参照すると共に上記データベース接続装置を通じて上記外部のデータベースを参照して、人事異動や組織変更などの契約担当者や契約部署を特定する情報の変更を検出するものであり、
   通知装置は、担当更新装置に、異動検出装置が検出した変更後の情報を通知するものであり、
   担当更新装置は、通知装置から情報の変更の上記通知を受け、契約情報記憶装置が保持する契約情報中の担当情報を更新するものであることを特徴とする請求項１乃至３の何れかに記載の契約管理システム。
5. 会計データベース接続装置と、表示装置とを備え、
   会計データベース接続装置は、外部の会計データベースを本システムに接続するものであり、
   表示装置は、確認対象検出装置が識別した確認時期の到来した契約情報について、会計データベース接続装置を通じて、外部の会計データベースから、最終取引日を取得して表示することが可能なものであることを特徴とする請求項１乃至４の何れかに記載の契約管理システム。
6. 少なくとも、契約情報記憶装置と、時計を備えた時期検出装置と、確認対象検出装置とを用いるものであり、
   上記の契約情報記憶装置に、個々の契約について、少なくとも、契約担当者又は契約担当部署を特定する担当情報と、契約開始日等の確認基準日情報とを、契約情報として保持させ、
   時期検出装置に、定期的に、確認対象検出装置を起動させ、
   確認対象検出装置に、契約情報記憶装置が保持する契約情報夫々の、確認基準日と現在の日付とを比較させ、確認時期の到来した契約情報と確認時期の到来していない契約情報とを識別させる契約管理ソフトウエア。
7. 請求項６記載の契約管理ソフトウエアの記録媒体。
8. 少なくとも、契約情報記憶装置と、時計を備えた時期検出装置と、確認対象検出装置とを用いるものであり、
   上記の契約情報記憶装置に、個々の契約について、少なくとも、契約担当者又は契約担当部署を特定する担当情報と、契約開始日等の確認基準日情報とを、契約情報として保持させ、
   時期検出装置に、定期的に、確認対象検出装置を起動させ、
   確認対象検出装置に、契約情報記憶装置が保持する契約情報夫々の、確認基準日と現在の日付とを比較させ、確認時期の到来した契約情報と確認時期の到来していない契約情報とを識別させる契約管理方法。

Images