JP2001143006A - 電子決裁文書の自動作成システム - Google Patents

Abstract

(57)【要約】 【課題】 複数種類の電子決裁文書の原紙データの作成
作業を簡単で効率的に行うことを可能にする電子決裁文
書の自動作成システムを提供する。 【解決手段】 クライアントとサーバとを含むネットワ
ークにおいて、原紙データの作成を許可されたクライア
ント又はサーバは、異なるフォーム及び異なる処理の流
れを持つ複数の電子決裁文書の各々のフォームを定義し
たフォーム定義ファイルと処理の流れを定義した流れ定
義ファイルとを定義する定義ファイル設定手段と、電子
決裁文書に共通の原紙データ作成プログラムを用い、且
つ定義ファイル設定手段により定義された内容に基づい
て電子決裁文書の各々に対応する複数の原紙データを例
えばウエブブラウザで使用可能な形式で作成する原紙デ
ータ作成手段とを備える。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は電子決裁文書の自動
作成システムに関し、特に異なる種類の電子決裁文書の
原紙データを共通のプログラムにより作成するシステム
に関する。

【０００２】

【従来の技術】企業や官庁等において「交通費申請書」
や「稟議書」など各種の決裁文書を作成し、上長の決裁
を受けることが行われている。例えば「交通費申請書」
に必要事項を記入して、上長の決裁を受ける場合、交通
費申請書の原紙に必要事項を記入し、それを上長に提出
して決裁をあおぐ。この場合、原紙は予め作成してキャ
ビネット等の所定位置に確保しておき、必要に応じてそ
の原紙を取り出して必要事項を記入することにより起票
をすることになる。そして起票した文書は所定の回付ル
ール（例えば、課長→事業部受付→業務部長）にしたが
って審査される。

【０００３】近年、コンピュータの発達及びネットワー
クの発達に対応して、これらの決裁文書を電子化して、
ペーパレス化を促進する動きがある（例えば、特開平６
−２３１１４３号公報、特開平１０−４９５９８号公報
等を参照）。従来の電子決裁文書の原紙に対応するデー
タ（以下、原紙データをいう）は、文書の種類毎に別々
のプログラムを用いて作成していた。

【０００４】

【発明が解決しようとする課題】電子決裁文書の原紙に
対応するデータを、フィールドの属性や処理の流れが異
なる文書の種類毎に別々のプログラムを用いて作成する
のでは、文書の種類の数と同じ数のプログラムが必要と
なる。このため、従来の電子決裁文書の原紙データの作
成方法は汎用性に欠けるという問題がある。即ち、新た
な種類の電子決裁文書を作成する場合には、その都度そ
の種類の原紙データを作成するためのプログラムを作成
しなければならないので、原紙データの作成作業が極め
て煩雑で非効率的であるという問題がある。

【０００５】本発明の目的は、上記従来技術における問
題に鑑み、複数種類の電子決裁文書の各々の原紙データ
を共通の原紙データ作成プログラムを用いて作成可能に
することにより、原紙データの作成作業を簡単で効率的
に行うことを可能にする電子決裁文書の自動作成システ
ムを提供することにある。

【０００６】

【課題を解決するための手段】上記目的を達成するため
に、本発明により提供されるものは、クライアントとサ
ーバとを含むネットワークにおいて、異なるフォーム及
び異なる回付ルールを持つ複数の電子決裁文書の各々の
フォームを定義したフォーム定義ファイルと電子決裁文
書の回付ルールを定義した回付ルール定義ファイルとを
定義する定義ファイル設定手段と、定義設定手段により
定義された内容に基づいて電子決裁文書の各々に対応す
る複数の原紙データを画面上で使用可能な形式で作成す
る原紙データ作成手段と、原紙データを格納する原紙デ
ータ格納手段と、作成された原紙データを用いて所望の
電子決裁文書の起票のために必要なデータを格納する入
力データ格納テーブルを作成するための入力データ格納
テーブル作成手段と、を備え、クライアントのうち電子
決裁文書の原紙データの作成を許可されたクライアント
（２）又はサーバ（３）は、複数の電子決裁文書のそれ
ぞれに対応する複数の原紙データを作成可能であり、ク
ライアントのすべては、所望の原紙データに入力データ
格納テーブルを用いて必要な入力データを入力して所望
の電子決裁文書を起票可能であり、サーバ（３）は前記
回付ルールにしたがって、起票された電子決裁文書を回
付可能であるようにした、ことを特徴とする電子決裁文
書の自動作成システムである。

【０００７】定義設定手段により定義された内容に基づ
いて、画面上で使用可能な複数の原紙データを作成でき
る。また、任意の電子決裁文書の原紙データを作成可能
になる。定義ファイル設定手段及び原紙データ作成手段
のいずれか又は両方は、サーバに設けてもよい。

【０００８】サーバに定義ファイル格納手段を備えるこ
とにより、電子決裁文書の原紙データの作成を許可され
た任意のクライアントは、そのクライアントの持つ画面
を見ながら作成した定義ファイルに基づいて原紙データ
を作成することに代えて、サーバ内の定義ファイル格納
手段の内容を利用して原紙データを作成することができ
る。

【０００９】また、定義ファイル設定手段により定義さ
れるファイルは原紙データ作成プログラムで使用可能な
データの形式であれば何でもよいので、クライアントは
使用言語を意識することなく画面を見ながら定義ファイ
ルを作成できる。複数の原紙データは、電子決裁文書を
起票する際に使用する起票用原紙データと、電子決裁文
書の審査をする際に使用する審査用原紙データと、電子
決裁文書の審査状況を確認するための状況確認用原紙デ
ータと、電子決裁文書の起票データがサーバに受け付け
られた際に発行される起票受付画面の原紙データと、電
子決裁文書の審査データがサーバに受け付けられた際に
発行される審査受付画面の原紙データとを含んでいる。

【００１０】これらの原紙データを作成しておくことに
より、任意のクライアントにおいてユーザが電子決裁文
書を利用する際に、原紙データのコピーを用いて起票画
面、起票受付画面、審査画面、審査受付画面、及び状況
確認画面を簡単に表示して利用することができる。画面
がウエブブラウザである場合に、使用可能な形式は、少
なくともＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕ
ｐ Ｌａｎｇｕａｇｅ）形式とＳＧＭＬ（Ｓｔａｎｄａ
ｒｄ Ｇｅｎｅｒａｌｉｚｅｄ Ｍａｒｋｕｐ Ｌａｎ
ｇｕａｇｅ）形式のいずれかである。

【００１１】

【発明の実施の形態】以下、図面により本発明の実施の
形態を説明する。図１は本発明の実施の形態による電子
決裁文書の自動作成システムを示す概略ブロック図であ
る。図において、１はネットワークである。ネットワー
ク１は、電子決裁文書の原紙データの作成を許可された
クライアント２と任意のクライアント４とを含む複数の
クライアントとサーバ３とを含む。クライアント２又は
４とサーバ３とはネットワーク５を介して接続される。

【００１２】電子決裁文書の原紙データの作成を許可さ
れたクライアント２は、定義ファイル設定手段２１と、
原紙データ作成手段２２と、入力データ格納テーブル作
成手段２３とを備えている。入力データ格納テーブル作
成手段は他のすべてのクライアントにも設けられてい
る。定義ファイル設定手段２１は、後に図３及び図４に
より詳述するように、異なるフォーム及び異なる回付ル
ールを持つ異なる電子決裁文書の各々のフォームを定義
したフォーム定義ファイルと回付ルールを定義した回付
ルール定義ファイルとを定義するものである。

【００１３】原紙データ作成手段２２は、複数の電子決
裁文書に共通の原紙データ作成プログラムを用いて、定
義設定手段２１により定義された内容に基づいて電子決
裁文書の各々に対応する複数の原紙データを画面上で使
用可能な形式、例えば、ウエブブラウザで使用可能なＨ
ＴＭＬ形式又はＳＧＭＬ形式、で作成するものである。

【００１４】サーバ３はクライアント２内の定義ファイ
ル設定手段２１により設定された異なるフォーム及び異
なる回付ルールを格納する定義ファイル格納手段３１を
備えている。クライアント２内の原紙データ作成手段２
２は、定義ファイル設定手段２１からの定義ファイルを
直接使用する代わりに、サーバ３内の定義ファイル格納
手段３１から読み出した定義ファイルに基づいて複数の
原紙データを作成してもよい。

【００１５】また、原紙データ作成手段２２はサーバ３
にも存在していてもよい。あるいは原紙データ作成手段
２２をサーバ３にのみ存在させる形態でもよい。原紙デ
ータ作成手段２２により作成される複数の原紙データ
は、本発明の実施の形態においては、電子決裁文書を起
票する際に使用する起票用原紙データと、電子決裁文書
の起票データがサーバ３に受け付けられた際に発行され
る起票受付画面の原紙データと、電子決裁文書の審査を
する際に使用する審査用原紙データと、電子決裁文書の
審査データがサーバ３に受け付けられた際に発行される
審査受付画面の原紙データと、電子決裁文書の審査状況
を確認するための状況確認用原紙データとである。原紙
データは上記のものに限定されず、他の原紙データを作
成してもよい。これらの原紙データはサーバ３内の起票
用原紙データ格納手段３２、起票受付原紙データ格納手
段３３、審査用原紙データ格納手段３４、審査受付原紙
データ格納手段３５、及び状況確認用原紙データ格納手
段３６にそれぞれ格納される。

【００１６】任意のクライアント内の入力データ格納テ
ーブル作成手段２３は、起票時に使用する入力データ格
納テーブル３７を作成する。入力データ格納テーブル３
７はサーバ３内に格納される。サーバ３はまた、起票時
にクライアント２により入力される各種の数値、例えば
交通費や出張旅費等の金額、を個人別や用途別に累積す
る等の各種の演算を行う演算手段３８も備えている。

【００１７】図２は図１のシステムの動作を説明するフ
ローチャートである。図３、図４及び図５は「交通費申
請書」という電子決裁文書の原紙データの定義ファイル
を作成する際に表示される画面例を示す図である。交通
費申請書の原紙データの作成動作を図２から図５により
説明する。まず、原紙データの作成を許可されたクライ
アント２におけるパーソナルコンピュータにおいて、
「原紙データ自動作成プログラム」のアイコンをクリッ
クする等により原紙データ自動作成プログラムを選択す
る。すると、モニタには図３に示す画面のうち、左側の
“Ｌａｂｅｌ”と“Ｔｅｘｔ”と“添付ファイル”との
みが表示された画面が表示される。回付先のアドレスの
確認のためにＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃ
ｅ Ｌｏｃａｔｏｒ）及びメールアドレスを表示しても
よい。

【００１８】この状態で図２のステップＳ２１でフィー
ルドの定義設定を行う。この定義設定は、まず、画面上
の“Ｌａｂｅｌ”をマウスによりドラッグして作成した
いフィールド位置に移動する。すると図３に示すように
「ラベルＢｏｘ」が表示され、そのラベルＢｏｘに定義
したい内容を入力する。図３の状態では「交通費申請
書」というタイトルを画面上で定義しようとしていると
ころである。即ち、「交通費申請書」というタイトルを
表示したい位置に“Ｌａｂｅｌ”をドラッグすると、そ
の位置に黒い点が表示され、その位置でタイトルを囲む
長方形の左上隅の横位置、縦位置、タイトルの幅及び高
さ（図においてはそれぞれ１７、１、２４、１）を自動
的に定義し、枠の有無を定義する。図において各欄の下
向き矢印はプルダウン可能であることを示す。したがっ
て、枠の欄では「なし」が選択されている。次に入力方
式を選択する。入力方式としては「コンスタント」と
「自動入力」とがある。「コンスタント」入力方式で
は、原紙データの作成段階で設定される固定の文字が入
力される。「自動」入力方式では、原紙データを作成後
に任意のクライアントがウエブブラウザを用いてこの原
紙データから起票する場合に、そのクライアントの所属
部署名や氏名等が自動的に入力される。図３に示すラベ
ルＢｏｘを用いるフィールドの設定では「コンスタン
ト」を設定する。「コンスタント」入力方式が選択され
ると、ラベルＢｏｘの下に「コンスタント値を入力して
下さい」といったメッセージが表示される。図３では、
原紙データ作成者はこのメッセージに応答して「交通費
申請書」と入力し、ＯＫのボタンをマウスによりクリッ
クした状態を示している。以下、マウスによりボタンを
クリックすることを、ボタンを押すという。この入力の
結果、図３に示されているように原紙のタイトルとして
画面上に「交通費申請書」が表示される。

【００１９】同様にして、「提出日」、「部署」、「社
員コード」、「氏名」等の欄をそれぞれラベルＢｏｘを
用いて定義する。次に図３の画面の左側に示される“Ｔ
ｅｘｔ”をドラッグすると図４に示すようにテキストＢ
ｏｘが表示され、上記ラベルＢｏｘを使用したのと同様
にして各欄を定義する。図４においては氏名の欄を定義
しているところであり、入力方式として自動入力を選択
した結果、フィールド名として、「役職名」、「氏名
（漢字）」、「氏名（カナ）」等から「氏名（漢字）」
を選択したところを示している。

【００２０】さらに、この申請書の回付先に人が不在の
場合に転送先を明示したり、その他のメッセージを付し
たりするために、「コメント」欄に任意のコメントを記
入することができる。さらに、任意の文書を添付ファイ
ルにしてこの申請書と共に回付先に送ることもできる。
例えば契約申請書を起票する場合は大量の文書が必要と
なることがある場合があり、このような場合に「添付フ
ァイル」を利用する。

【００２１】さらに回付先のＵＲＬやメールアドレスを
表示させて回付先を確認することもできる。次に図２の
ステップＳ２２で、電子決済文書の処理の流れの定義、
即ち、回付ルールを設定する。この動作は図５に示す画
面の下側に示されるように認印を押すことが出来る人の
条件を設定する動作である。２つの×印の間で処理の流
れが設定されている。処理の流れの方向を示す矢印はマ
ウスを動かす動作により任意の数だけ作成できる。申請
者からの回付ルールは、図５においては、申請者→所属
長→業務部受付→業務部長、と定義されている。回付ル
ールの経由点は、画面上に表示される「認印」の表を用
いて定義する。即ち、任意の印を選択すると画面上に
「認印」の表が表示される。図５においては２つの黒点
で示されている「業務部長受付」の位置の認印が選択さ
れており、この「業務部長受付」の表示を「社内受付」
に変更する場合は、画面上の表内の「社内受付」をマウ
スによりクリックし、ＯＫであれば表の右上にある×印
をクリックすることにより「社内受付」を確定する。

【００２２】以上により、フィールドの定義と処理の流
れの定義の設定が終了する。原紙データ作成者は設定さ
れた画面データを保存する場合は、画面上の確認ボタン
をクリックすることにより図２のステップＳ２４にて画
面データを原紙データ作成者の定義ファイルとして設定
すると共に、サーバ３内の定義ファイル格納手段３１に
画像定義ファイル３１１および処理定義ファイル３１２
として保存する。

【００２３】サーバ３内の定義ファイル格納手段３１
は、図２に示すように複数の電子決済文書のそれぞれの
画像定義ファイル３１１および処理定義ファイル３１２
を格納する。これらの定義ファイルの内容は、後に説明
する原紙データ作成プログラムが使用可能な形式であれ
ばどんなものでもよく、したがって非ＨＴＭＬ形式、例
えばＳＧＭＬ形式で記載されてもよい。このため、ユー
ザは、ＨＴＭＬ形式を意識することなく画面を見ながら
簡単に定義ファイルを作成できる。

【００２４】次に原紙データを作成するときは、図２の
ステップＳ２５で、サーバ３内の定義ファイル格納手段
３１から作成したい原紙データに対応する文書を選択す
る。この選択は、サーバ３から定義ファイルの一覧表を
読み出し、その中から作成したい文書に対応する定義フ
ァイルを選択することにより行われる。定義ファイルが
選択されるとステップＳ２６でその定義ファイルがモニ
タに表示される。定義ファイルをサーバから読み出して
表示させることに代えて、原紙データを作成中のクライ
アントがその文書に対応する定義ファイルを保持してい
る場合は、そのクライアントが保持している定義ファイ
ルを読み出して表示させてもよい。

【００２５】次いで、ステップＳ２７の判断で、表示さ
れた画面（図５に示したような画面）を見て原紙として
完成されていれば、画面上の画面作成ボタンをマウスに
よりクリックする。すると、ステップＳ２８で原紙デー
タ作成プログラムが動作して、読み出した定義ファイル
の内容に基づいて、「起票用原紙データ」、「起票受付
原紙データ」、「審査用原紙データ」、「審査受付原紙
データ」、及び「状況確認用原紙データ」のいずれかを
ブラウザで使用可能な形式、例えばＨＴＭＬ形式又はＳ
ＧＭＬ形式で作成し、サーバ３のそれぞれの格納手段３
２、３３、３４、３５、３６に格納する。

【００２６】次いで任意のクライアントが起票時に入力
する入力データを格納する「入力データ格納テーブル」
をステップＳ２９で作成し、そのテーブルをサーバ３内
の入力データ格納テーブル３７に格納する。図６は図２
における原紙データ作成ステップＳ２８をより詳細に説
明するフロチャートである。図において、ステップＳ６
１で、起票用、審査用および状況確認用の原紙データ画
面の共通フィールドをブラウザで使用可能な形式でセッ
トする。共通フィールドとは、例えば図９に示す画面上
の上側に示されている、「起票」と、「承認」と、「否
認」のいずれの種類かを示すフィールドで、起票用原紙
データの共通フィールドのデフォルト状態では「起票」
の前のマークに黒をセットし、審査用原紙データの共通
フィールドのデフォルト状態では「承認」の前のマーク
に黒をセットし、状況確認用原紙データの共通フィール
ドでは処理状況に応じて「承認」又は「否認」の前のマ
ークに黒をセットする。

【００２７】次いでステップＳ６２で、図３を用いて説
明した各原紙データ画面のラベルＢＯＸの定義内容をブ
ラウザで使用可能な形式でセットする。次いでステップ
Ｓ６３で、図４を用いて説明した各原紙データ画面のテ
キストＢＯＸの定義内容をブラウザで使用可能な形式で
セットする。次いでステップＳ６４で、図５を用いて説
明した各原紙データの処理の流れ（回付ルール）の表示
論理をブラウザで使用可能な形式でセットする。

【００２８】以上の動作により、原紙データの作成が終
了する。原紙データが作成された後は、サーバ３にブラ
ウザで使用可能な形式で格納されている原紙データのコ
ピーを、任意のクライアントのモニタに表示させ、提出
年月日、部署名、社員ＩＤ、氏名、金額等必要な動的デ
ータを入力して電子決済文書を起票する。

【００２９】演算手段３８（図１参照）は、入力された
金額等の数字を、例えば個人別、用途別に累計して、入
力データ格納テーブル３７内の所定エリアに格納する。
次に、原紙データを用いて起票をし、審査をし、又は審
査状況を確認する方法を説明する。 （１）起票の方法 原紙データを用いた起票の仕方を図７〜図１２により説
明する。まず、任意のクライアントにおいて、起票者が
起票したい文書の原紙データのアドレスを指定する。す
ると、そのクライアントはウエブブラウザを介してサー
バ３に接続されて、原紙データの一覧表がクライアント
側のモニタに表示される。起票者がその一覧表の中から
起票したい文書のタイトルをクリックして選択すると、
サーバ３は図７に示すログイン画面をクライアント側の
モニタに表示させる。起票者はログイン画面にユーザＩ
Ｄとパスワードを入力し、ＯＫのボタンをクリックす
る。

【００３０】すると、サーバ３は図８に示す出力動作を
する。即ち、選択された文書の原紙データから共通フィ
ールドのデータと、ラベルのデータと、入力エリアのデ
ータと、フロー１の論理により得られるデータと、フロ
ー２の論理により得られるデータとをクライアントに出
力する。フロー１の論理により得られるデータとは、起
票した文書の回付ルールのうち、起票者の氏名および印
影の表示論理にしたがって得られるデータであり、ログ
イン画面で起票者が入力したユーザＩＤとパスワード
は、サーバ３内のユーザ・テーブル８１の内容と照合さ
れて、対応する起票者の氏名および印影のデータがクラ
イアントに送られる。フロー２の論理により得られるデ
ータとは、起票した文書の審査先の氏名の表示論理にし
たがって得られるデータであり、ログイン画面で起票者
が入力したユーザＩＤとパスワードは、サーバ３のユー
ザ・テーブル８１の内容と照合されて、対応する審査先
の係長名のデータがクライアントに送られる。

【００３１】この結果、図９に示すような起票画面がク
ライアント側のモニタに表示される。この画像は、図５
に示したような原紙データの画像と同じである。次いで
起票者は、図９の画像の入力エリアに提出年月日、部署
名、社員ＩＤ、氏名、等の動的なデータを入力し、審査
先を選択する。一例として入力エリアに「××××を申
請します」を入力し、審査先を選択した後の画面を図１
０に示す。この画面が起票画面としてＯＫであれば送信
ボタンを押す。すると起票画面のデータはサーバ３に転
送され、サーバ３において、図１１に示すように、入力
データを受け付け、入力データ及び演算手段３８による
入力データの演算結果を入力データ格納テーブル３７に
格納し、処理状況を処理状況格納テーブル１１１に格納
し、起票受付原紙データ格納手段３３に格納されている
原紙データに基づいて受付メッセージを作成する。入力
データ格納テーブル３７には、入力エリアに入力された
データである「××××を申請します」と、入力者の氏
名が自動的に格納される。処理状況テーブル１１１には
フロー１のレコードとして、起票済であることと、起票
の日時とが自動的に格納される。

【００３２】受付メッセージはクライアント側のモニタ
に図１２のように表示される。起票がなされた後は、起
票があった旨を審査先のクライアントに電子メール、電
話、ファクシミリ等の手段により通知するようにしても
よい。 （２）審査の方法 起票後の文書の審査の方法を図１３〜図１７により説明
する。まず、審査先のクライアントは、自端末に到着し
ている文書のリストから、審査しようとする文書を選択
し、その画面のアドレスを指定する。すると、そのクラ
イアントはウエブブラウザを介してサーバ３に接続さ
れ、サーバ３は図１３に示すログイン画面を審査先のク
ライアントのモニタに表示させる。審査者はログイン画
面に審査先である自己のユーザＩＤとパスワードを入力
し、ＯＫのボタンをクリックする。

【００３３】すると、サーバ３は図１４に示す出力動作
をする。即ち、選択された文書の原紙データから審査用
の共通フィールドのデータと、ラベルのデータと、入力
エリアのデータと、入力データを入手して表示する論理
と、フロー１の論理により得られるデータと、フロー２
の論理により得られるデータとをクライアントに出力す
る。フロー１の論理により得られるデータとは、図１１
に示した処理状況テーブル１１１の内容に基づいて状況
を入手してクライアント側のモニタに表示する論理によ
り得られるデータである。即ち、処理状況テーブル１１
１のフロー１レコードから起票者の氏名および印影を入
手してフロー１の論理にしたがって審査画面にその氏名
および印影を表示する。また、フロー２の論理により得
られるデータとは、ユーザテーブル８１から審査者の氏
名および印影を入手してクライアント側のモニタに表示
する論理により得られるデータである。ログイン画面で
審査者が入力したユーザＩＤとパスワードは、サーバ３
のユーザ・テーブルで照合されて、対応する審査者の氏
名、印影、および部署名のデータがクライアントに送ら
れる。

【００３４】この結果、図１５に示すような審査画面が
クライアント側のモニタに表示される。図示のように、
共通フィールドでは「承認」の前のマークに黒が設定さ
れている。ラベルの部分には申請内容が表示される。入
力エリアの部分には「××××を申請します」と表示さ
れている。回付ルールの部分には起票者の氏名と印影、
および審査者の氏名と印影が表示されている。審査画面
においては、入力エリアの内容に対して追加や変更はで
きない。この画面の内容を審査者が承認する場合は、送
信ボタンを押す。否認する場合は共通フィールドの「否
認」を選択する。「否認」が選択されると、クライアン
ト側のモニタでは、図１５に示す審査画面からその１つ
前の図１４に示す画面に戻る。「送信」ボタンが押され
ると、図１６に示すように、サーバ３は入力データを受
け付け、処理状況をフロー２に関する処理状況テーブル
１１２に格納し、審査受付原紙データ格納手段３５に格
納されている原紙データに基づいて受付メッセージを作
成する。処理状況テーブル１１２にはフロー２のレコー
ドとして、審査先名と、承認したことと承認の日時とが
自動的に格納される。

【００３５】受付メッセージはクライアント側のモニタ
に図１７のように表示される。 （３）状況確認の方法 任意のクライアントから送信した文書の処理状況がどう
なっているかを確認する状況確認の方法を図１８〜図２
０により説明する。まず、状況確認を要求するクライン
トは、送信済の文書のタイトルの一覧表をサーバ３から
入手してモニタに表示させ、状況を調べたい文書のタイ
トルを選択する。すると、その文書に対応する状況確認
時のログイン画面が図１８のように表示され、状況確認
のボタンを押すと、サーバ３は図１９に示す出力動作を
する。即ち、選択された文書の原紙データから状況確認
用の共通フィールドのデータと、ラベルのデータと、入
力エリアのデータと、入力エリアの入力データを入手し
て表示する論理により得られるデータと、フロー１の論
理により得られるデータと、フロー２の論理により得ら
れるデータとをクライアントに出力する。入力データは
入力データ格納テーブル３７から得る。フロー１の論理
により得られるデータとは、処理状況テーブルのフロー
１のレコードから得られる起票者の氏名および印影のデ
ータであり、これを入手してフロー１の論理にしたがっ
て状況確認画面にその氏名および印影を表示する。ま
た、フロー２の論理により得られるデータとは、処理状
況テーブルのフロー２のレコードから得られる審査者
名、承認したこと、および承認の日時のデータである。

【００３６】ログイン画面で審査者が入力したユーザＩ
Ｄとパスワードは、サーバ３のユーザ・テーブル８１で
照合されて、対応する状況確認者の氏名、印影、および
部署名のデータがクライアントに送られる。この結果、
図２０に示すような状況確認画面がクライアント側のモ
ニタに表示される。図示のように、共通フィールドの
「承認」の前のマークに黒が設定されている場合は、審
査先における審査が承認されていることを示し、「否
認」の前にマークが付けられている場合は、審査の結果
が否認されたことを示している。ラベルの部分には申請
内容が表示される。入力エリアの部分には例えば「××
××を申請します」と表示されている。回付ルールの部
分には起票者の氏名と印影および起票日時が表示される
とともに、審査者の氏名と印影および承認日時が表示さ
れている。状況確認画面においても、入力エリアの内容
に対して追加や変更はできない。送信ボタンを押すと、
このクライアント側の状況確認画面は消滅する。

【００３７】なお、上記実施例では起票後の文書の審査
において「承認」又は「否認」のいずれかがなされる
が、起票後の文書を却下し、又は差し戻すようにするこ
ともできる。この場合は、図１５の画面上に「○却
下」、「○差し戻し」という項目を設けて、審査者がマ
ークするようにすればよい。

【００３８】

【発明の効果】以上の説明から明らかなように、本願発
明により複数種類の電子決裁文書の各々の原紙データを
共通の原紙データ作成プログラムを用いて作成すること
により、原紙データの作成作業を簡単で効率的に行うこ
とが可能になり、その審査も容易になる。

【図面の簡単な説明】

【図１】本発明の実施の形態による電子決裁文書の自動
作成システムを示す概略ブロック図である。

【図２】図１のシステムの動作を説明するフローチャー
トである。

【図３】電子決裁文書の原紙データの定義ファイルを作
成する際に表示される画面例を示す図である。

【図４】電子決裁文書の原紙データの定義ファイルを作
成する際に表示される画面例を示す図である。

【図５】電子決裁文書の原紙データの定義ファイルを作
成する際に表示される画面例を示す図である。

【図６】図２における原紙データ作成ステップＳ２８を
より詳細に説明するフロチャートである。

【図７】起票時のログイン画面を示す図である。

【図８】起票時のサーバの動作を説明する図である。

【図９】起票中の起票画面を示す図である。

【図１０】起票後の起票画面を示す図である。

【図１１】起票受付時のサーバの動作を説明する図であ
る。

【図１２】起票受付画面を示す図である。

【図１３】審査時のログイン画面を示す図である。

【図１４】審査時のサーバの動作を説明する図である。

【図１５】審査画面を示す図である。

【図１６】審査受付画面作成時のサーバの動作を説明す
る図である。

【図１７】審査受付画面を示す図である。

【図１８】状況確認時のログイン画面を示す図である。

【図１９】状況確認画面作成時のサーバの動作を説明す
る図である。

【図２０】状況確認画面を示す図である。

【符号の説明】

１…イントラネットシステム ２…電子決裁文書の原紙データの作成を許可されたクラ
イアント ３…サーバ ４…クライアント ２１…定義ファイル設定手段 ２２…原紙データ作成手段 ２３…入力データ格納データ作成手段 ３１…定義ファイル格納手段 ３２…起票用原紙データ格納手段 ３３…起票受付用原紙データ格納手段 ３５…審査受付原紙データ格納手段 ３６…状況確認用原紙データ格納手段 ３７…入力データ格納テーブル

Claims (10)

【特許請求の範囲】
1. 【請求項１】 クライアント（２，４）とサーバ（３）
   とを含むネットワークにおいて、 異なるフォーム及び異なる回付ルールを持つ複数の電子
   決裁文書の各々のフォームを定義したフォーム定義ファ
   イルと前記電子決裁文書の回付ルールを定義した回付ル
   ール定義ファイルとを定義する定義ファイル設定手段
   （２１）と、 前記複数の電子決裁文書に共通の原紙データ作成プログ
   ラムを用い、且つ前記定義ファイル設定手段により定義
   された内容に基づいて前記電子決裁文書の各々に対応す
   る複数の原紙データを画面上で使用可能な形式で作成す
   る原紙データ作成手段（２２）と、 前記原紙データを格納する原紙データ格納手段（３２〜
   ３６）と、 作成された原紙データを用いて所望の電子決裁文書の起
   票のために必要なデータを格納する入力データ格納テー
   ブルを作成するための入力データ格納テーブル作成手段
   （２３）と、 を備え、 前記クライアントのうち電子決裁文書の原紙データの作
   成を許可されたクライアント（２）又はサーバ（３）
   は、前記複数の電子決裁文書のそれぞれに対応する複数
   の原紙データを作成可能であり、 前記クライアントのすべては、所望の原紙データに前記
   入力データ格納テーブルを用いて必要な入力データを入
   力して所望の電子決裁文書を起票可能であり、 前記サーバ（３）は前記回付ルールにしたがって、前記
   起票された電子決裁文書を回付可能であるようにした、 ことを特徴とする電子決裁文書の自動作成システム。
2. 【請求項２】 前記クライアント（２，４）のうち電子
   決裁文書の原紙データの作成を許可されたクライアント
   （２）は、前記定義ファイル設定手段（２１）と、前記
   原紙データ作成手段（２２）とを備えており、 前記サーバ（３）は、前記原紙データ格納手段（３２〜
   ３６）を備えていることを特徴とする請求項１に記載の
   電子決裁文書の自動作成システム。
3. 【請求項３】 前記サーバ（３）は、前記定義ファイル
   設定手段（２１）と前記原紙データ作成手段（２２）の
   少なくとも一方を備えており、 前記クライアントのうち電子決裁文書の原紙データの作
   成を許可されたクライアント（２）は、前記定義ファイ
   ル設定手段（２１）と前記データ作成手段（２２）のう
   ち前記原紙データの作成を許可されたクライアントに設
   けられるもの以外と、前記原紙データ格納手段（３２〜
   ３６）とを備えていることを特徴とする請求項１に記載
   の電子決裁文書の自動作成システム。
4. 【請求項４】 前記複数の原紙データは、前記電子決裁
   文書を起票する際に使用する起票用原紙データと、前記
   電子決裁文書の審査をする際に使用する審査用原紙デー
   タと、前記電子決裁文書の審査状況を確認するための状
   況確認用原紙データとを含んでいることを特徴とする請
   求項１から３のいずれか一項に記載の電子決裁文書の自
   動作成システム。
5. 【請求項５】 前記複数の原紙データは、前記電子決裁
   文書の起票データが前記サーバに受け付けられた際に発
   行される起票受付画面の原紙データと、前記電子決裁文
   書の審査データが前記サーバに受け付けられた際に発行
   される審査受付画面の原紙データとを含むことを特徴と
   する請求項４に記載の電子決裁文書の自動作成システ
   ム。
6. 【請求項６】 前記原紙データには、所望の申請をする
   機能、任意の添付ファイルを付加する機能、任意のコメ
   ントを付加する機能、および前記原紙データの回付先の
   アドレスを表示する機能の少なくとも１つが付与されて
   いることを特徴とする請求項１から５のいずれか一項に
   記載の電子決裁文書の自動作成システム。
7. 【請求項７】 前記サーバは、前記原紙データが作成さ
   れて回付先に送信された時に、該回付先に対して前記原
   紙データの送信があった旨を通知する手段を備えること
   を特徴とする請求項１から６のいずれか一項に記載の電
   子決裁文書の自動作成システム。
8. 【請求項８】 前記サーバは、前記原紙データが回付先
   で却下又は差し戻しされた時に、前記原紙データを回付
   前の状態に戻す手段を有することを特徴とする請求項１
   から７のいずれか一項に記載の電子決裁文書の自動作成
   システム。
9. 【請求項９】 前記サーバは、前記原紙データに含まれ
   る数値を演算する手段を備えることを特徴とする電子決
   裁文書の自動作成システム。
10. 【請求項１０】 前記画面がウエブブラウザである場合
    に、前記画面上で使用可能な形式は少なくともＨＴＭＬ
    形式とＳＧＭＬ形式のいずれかである請求項１から９の
    いずれか一項に記載の電子決裁文書の自動作成システ
    ム。