(57)【特許請求の範囲】
【請求項１】
組織の構造に対応した木構造のデータ構造によって表現した組織情報を記憶する手段と、
文書を構成する項目と型との対応関係の記述を含む文書構造の定義と、承認経路の定義と、型の定義とを含むデータである様式を記憶する手段と、
稟議書類を記憶する手段と、
前記様式に基づいて利用者に入力画面を提供する手段と、
入力画面およびチェックプログラムを生成する手段とを備え、
前記入力画面およびチェックプログラムを生成する手段は、様式に基づいて前記入力画面を生成するとともに、様式に含まれる前記型の定義に基づいて前記入力画面に入力された入力値のチェックを行うチェックプログラムを生成し、
前記チェックプログラムは、入力画面から呼び出されて入力候補を返却し、
前記入力画面は、前記チェックプログラムから返却された前記入力候補を表示することで入力補助を行い、
前記組織情報と前記様式に含まれた承認経路の定義とに基づいて書類の承認経路を決定し、
利用者により前記入力画面に入力された入力値と前記書類の承認経路とを含む稟議書類を生成し、前記稟議書類を記憶する手段に記憶させることを特徴とする稟議システム。
【請求項２】
前記入力画面は、前記文書を構成する項目に対応する複数の入力要素から構成され、
前記利用者によって入力された項目への入力値、または、複数の項目への入力値に基づいて前記承認経路を決定することを特徴とする請求項１に記載の稟議システム。
【請求項３】
前記入力画面、および、チェックプログラムを生成する手段は、さらに、前記様式に基づいて様式の説明文の生成を行うことを特徴とする請求項１に記載の稟議システム。
【請求項４】
前記様式は、前記型に対する変域の記述を含むことを特徴とする請求項１乃至３のいずれかに記載の稟議システム。
【請求項５】
前記稟議システムは、外部データベースをさらに備え、
前記様式には、前記変域の記述として前記外部データベースの問い合わせのための情報を含むことを特徴とする請求項４に記載の稟議システム。
【請求項６】
前記入力画面を提供する手段は、前記様式、または、前記文書構造の項目に割り当てられた型に対する入力画面での表示方法の定義を含む定義ファイルをさらに記憶することを特徴とする請求項１乃至５に記載の稟議システム。
【請求項７】
組織の構造に対応した木構造のデータ構造によって表現した組織情報を記憶する手段と、
文書を構成する項目と型との対応関係の記述を含む文書構造の定義と、承認経路の定義と、型の定義とを含むデータである様式を記憶する手段と、
稟議書類を記憶する手段と、
前記様式に基づいて利用者に入力画面を提供する手段と、
入力画面およびチェックプログラムを生成する手段とを備えた稟議システムにおいて実行されるプログラムであって、
前記入力画面およびチェックプログラムを生成する手段は、様式に基づいて前記入力画面を生成するとともに、様式に含まれる前記型の定義に基づいて前記入力画面に入力された入力値のチェックを行うチェックプログラムを生成するステップを含み、
前記チェックプログラムは、入力画面から呼び出されて入力候補を返却するステップを含み、
前記入力画面は、前記チェックプログラムから返却された前記入力候補を表示することで入力補助を行い、
前記組織情報と前記様式に含まれた承認経路の定義とに基づいて書類の承認経路を決定し、
利用者により前記入力画面に入力された入力値と前記書類の承認経路とを含む稟議書類を生成し、前記稟議書類を記憶する手段に記憶させるステップを含むことを特徴とするプログラム。
【請求項８】
組織の構造に対応した木構造のデータ構造によって表現した組織情報を記憶する手段と、
文書を構成する項目と型との対応関係の記述を含む文書構造の定義と、承認経路の定義と、型の定義とを含むデータである様式を記憶する手段と、
稟議書類を記憶する手段と、
前記様式に基づいて利用者に入力画面を提供する手段と、
入力画面およびチェックプログラムを生成する手段と
を備えた稟議システムにおいて実行される稟議システムの制御方法であって、
前記入力画面およびチェックプログラムを生成する手段が、様式に基づいて前記入力画面を生成するとともに、様式に含まれる前記型の定義に基づいて前記入力画面に入力された入力値のチェックを行うチェックプログラムを生成するステップを含み、
前記チェックプログラムは、入力画面から呼び出されて入力候補を返却するステップを含み、前記入力画面が、前記チェックプログラムから返却された前記入力候補を表示することで入力補助を行い、
前記組織情報と前記様式に含まれた承認経路の定義とに基づいて書類の承認経路を決定し、
利用者により前記入力画面に入力された入力値と前記書類の承認経路とを含む稟議書類を生成し、前記稟議書類を記憶する手段に記憶させるステップを含むことを特徴とする稟議システムの制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】  この発明は稟議システムに関わる。
【背景技術】
【０００２】  近年、社内や組織でやり取りされる書類の電子化が進んでおり、書類の承認・決裁についても電子で行う事が少なくない。
書類を電子化し電子的に承認・決裁するにあたり、書類がどのような様式に従うべきか、書類の様式毎にどのような経路で承認・決裁を行うべきかを事前に定めておく事が必要となる。【０００３】  従来の技術では、書類の様式の定義は、書類の電子化のためのミドルウェアを導入し、システムの管理者等がミドルウェア付属のグラフィカルな専用デザインツールによってデータベース定義及び入力画面のデザインを行っていた。【０００４】  また、承認・決裁の経路はＢＰＥＬ又は同程度の能力を持つビジネスプロセス記述言語により、グラフィカルに経路を記述していく方法がとられる。この記述は、システムの管理者によって書類の様式毎に記述されるか、一般利用者が書類を作成する際に選択するような方法を採ることが一般的である。
【先行技術文献】
【０００５】
【特許文献１】特開２００４−２４６５１６号公報
【特許文献２】特開２００７−０７２６９２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】  書類の様式の定義は、グラフィカルな専用ツールを利用して個別に様式を作成して実現することが通常行われている。このため、利用者が、大量の様式を定義しなければならなくなったり、軽微な様式の修正でも、グラフィカルな専用ツールによっては、修正の手間を考慮しておらず、利用者が該当する全ての様式を個別に全て修正しなくてはならず、修正による再利用することが困難であるなど、利用者に多大な作業を強いるものであった。【０００７】  また、会社独自の番号体系のチェックロジックを画面に埋め込みたい等の会社で使用する上で必要な要件を追加する場合は、通常専用ツールでは想定されていないため、このような画面は作成不可能であるか可能な場合でも定義が難しいことが課題であった。このため、利用者が実用的に使用するためにカスタマイズと称される大規模な改修を行い多大なコストを払って運用することが通例行われてきた。このような改造を行った場合、組織の改変や構成員の変更が発生した場合に、カスタマイズ部分がこのような変更を考慮されていない場合には、十分な対応が行えないか、若しくはさらに多大なコストと時間を費やして対応することなるため、結果的に運用コストが一層増大するか、場合によっては組織の改変を阻害する要因ともなってきた。【０００８】  次に、承認経路をＢＰＥＬ等の言語を使って記述して行く方法では、飛び決や、代行決裁など例外的な経路も含め取り得る経路を様式ごとに全て記述しておかなければ動作させることができず、あらかじめ例外的な経路を全て記述するために膨大な作業を強いられるため記述のコストが高い。また、組織構造や構成員に変更が発生した場合に、様式毎に定義された承認経路の見直しが発生してしまう。組織構造の一部を改変する場合でも、例外的な経路を記述する方法であるため、承認経路全体に渡っての見直しが発生し、改変後の確認作業も、承認経路全体に渡って行う必要があるため、確認作業が膨大となることが課題であった。【０００９】  ここでいう、飛び決とは、承認者が不在などの理由で承認できない場合、その上位の承認者が承認を行うことを指す。また、代行承認とは、承認者が不在などの理由で承認できない場合、同一組織内のユーザが代わりに承認を行うことを指す。【００１０】  特に、システムが大規模になると、小さな仕様変更であってもそれにより影響を受ける範囲が大きく、システム改修のコストは指数関数的に増大する事が課題であった。【００１１】  本発明は、このような書類の様式及び承認経路の作成と変更を最小限にすることで、システム開発および修正を容易にする事を目的とする。
【課題を解決するための手段】
【００１２】  本発明は、組織情報を記憶する手段と、様式を記憶する手段と、稟議書類を記憶する手段と、利用者に入力画面を提供する手段とを備え、利用者により前記入力画面に入力された情報から稟議書類を生成し、前記稟議書類を記憶する手段に記憶させる。【００１３】  この稟議システムにおいて、前記様式は、様式記述言語によって定義され、前記組織情報の辿り方の記述を含み、前記様式に含まれた前記組織図の辿り方の記述に基づいて、書類の承認経路を決定する。【００１４】  前記組織情報は所属と氏名が別レコードとして構成され、氏名のレコード中に所属へのリンクがある組織図を持つ。（図２）【００１５】  前記様式は、既存の型を組み合わせた新しい型の定義を含むことができ、前記既存の型と前記新しい型の定義に基づいて、前記利用者の入力する項目を表示するプログラムおよび利用者の入力した値のチェックを行うプログラムを自動生成する。
ここで、型とは利用者により入力される値に対するデータタイプのことである。例えば、「氏名」や「性別」に対応するデータタイプも型の一種である。型は、文書定義中に型定義を行うことでその文書中で使用することができる。【００１６】  前記利用者によって入力した項目、または複数の項目をパラメータとして利用して前記承認経路を決定する。【００１７】  前記自動生成するプログラムは、さらに前記様式の説明文の生成を行う。【００１８】  前記新しい型は、変域を設定できる。【００１９】  前記新しい型は、前記様式内にて変域を定義または外部データベースに問合せることで変域を定義する。【００２０】  前記チェックを行うプログラムは、利用者の入力の補助データを、前記利用者の入力する項目へ与える。【００２１】  前記様式は、さらに前記利用者の入力する項目の表示方法を定義できる。
【発明の効果】
【００２２】  発明が解決しようとする課題にて説明したように、様式については既存の型を基底として、必要な場合のみ既存の型を用いて新しい型を定義し、文書構造を記述する事で、入力画面とチェックロジックを自動生成する事ができ、承認経路については組織図を基底として、必要最低限の変更点のみを定義して承認・決裁ルートを自動生成する事が出来るため、ＢＰＥＬエンジンなどの従来のワークフローエンジンと比較し、プログラムの記述量が大幅に減るため、システムの構築コスト削減、構築速度の向上という効果を有する。【００２３】  また、型、及び承認経路を言語を用いて記述する事によって、多数の様式を用意した際にグラフィカルユーザインターフェイスを用いて実現されたものと比較し、多数の様式に関する変更を一度に行うことができ、変更にかかるメンテナンスの時間と経費を節減する効果を有する。【００２４】  また、組織図は所属と氏名が別レコードとなっているため、人員異動があった際に氏名のレコードのみ変更すればよく、変更時の修正作業を削減できるという効果を有する。所属は所属の階層構造を表すために、所属のレコード中に別の所属へのリンクを持ち、氏名のレコード中に所属へのリンクがある。【００２５】  また、書類とワークフローの知識を、当該言語を用いることで社内や組織で用いられる用語や知識とほとんど相違ない形で記述でき利用者が様式を容易に確認できるため、利用者の確認作業の労力を削減できるという効果を有する。【００２６】  また、当該言語を用いることで、高度なＲＤＢなどについての知識を必要とせず、ユーザの目線でシステム構築ができるというシステム構築のコストを削減できるという効果を有する。【００２７】  また、新しい型の定義から自動的に新しい型に関するバリデーションチェックロジックを生成するため、バリデーション用のサーブレットを書く必要がなく開発コストを削減できるという効果を有する。【００２８】  また、組織図とポリシーにより、全体の承認経路の決定を操作できるため、様々な稟議体系に対応することができる。【００２９】  ここで、ポリシーとは承認経路の決定に考慮される一種のルールであり、組織図や様式に定義されるものである。【００３０】  前記組織図には、書類の承認経路の決定を操作するためのポリシーを定義できる。このポリシーは前記言語により書類の承認経路を決定するときに考慮される。前記言語は、前記ポリシーを変更する事も出来る。【００３１】  さらに、組織図、および、書類の様式、新たな型の定義、承認ポリシーから、個々の様式に関する個別の入力画面、および、チェックロジックを自動生成して用いるため、書類作成時に用いる情報の依存関係が少なく、規模に応じたシステムのスケールアウトが行いやすいという効果を有する。
【発明を実施するための形態】
【実施例１】
【００３２】  この発明を実現するために、組織情報である組織図、様式を記述する能力を持つ言語を用意する。ここで様式とは、利用者が最終成果物である書類を作成するための基礎となるものとして定義する。様式とは一般的にテンプレートとして呼ばれることもある。【００３３】  組織図を記述する言語はいずれでも構わないが、当該実施例ではＸＭＬを利用する。この組織図を記述するＸＭＬは、ルート要素を組織図要素３０１とし、組織図要素３０１は１つ以上の組織要素３０２を持ち、組織要素３０２は０個以上の組織要素３０２及び１つ以上の役職要素３０４を持ち、役職要素３０４は１つ以上のユーザ要素３０５を持つ。このとき役職要素３０４が所属する組織の代表である場合は、役職要素は代表属性３０６を持つ。このように、実際の組織の階層構造に対応したＸＭＬによって組織図を表現する。（図３）【００３４】  組織図の組織要素３０２の属性３０３として、強制決裁と代行承認の可否が真偽値で記述される（図３）。これは組織全体の承認ポリシーとなる。【００３５】  様式を記述する言語はいずれでも構わないが、当該実施例では専用の言語（様式記述言語）とする。様式は、承認経路の定義４０２、新しい型の定義４０３、文書構造の定義４０４を記述できる。承認経路の定義４０２は、承認ポリシーの定義４０１として強制決裁と代行承認の可否を記述できる。承認経路の定義４０２は、権限の委譲、組織図に対しての経路の追加が記述できる。新しい型の定義４０３は既存の型又は定義済みの新しい型を使って新しい型を定義する。文書構造の定義４０４は文書を構成する項目の階層構造を記述し、項目に既存の型又は定義した新しい型を当てはめる。文書を構成する項目は、初期入力値を指定する事も出来る。（図４）【００３６】  新しい型は、既存の型に対して値の範囲に制限を付けることと、型を組み合わせて新たな型とすることと、型の定義は変更せずに名前だけを変更することが出来る。範囲の制限は、テキスト型を元とする場合は正規表現で指定する方法と列挙値をあげて指定する方法がある。数値型の場合は、列挙値をあげて指定する方法と、変域を指定する方法がある。【００３７】  生成される入力画面はＨＴＭＬとし、チェックロジックはアプリケーションサーバで実行可能なサーブレットとする。【００３８】  また、この言語を解釈し入力画面であるＨＴＭＬ及びチェックロジックであるサーブレットを生成する装置５０１と、組織図、様式を保存するサーバ５０２と、生成されたＨＴＭＬを配信するＷｅｂサーバ５０３と、サーブレットを実行し結果を返すアプリケーションサーバ５０４と、ＨＴＭＬを表示するＷｅｂブラウザ５０５と、書類を保存する装置５０６を用意する（図５）。既存の型については、装置５０１内に定義される。【００３９】  また、入力画面ＨＴＭＬの入力フォームの内容を変更した際に呼ばれるロジック２０１と、入力画面ＨＴＭＬから書類を提出するときに呼ばれるロジック２０２を、生成されたＨＴＭＬを配信するＷｅｂサーバ５０３に保存する。ロジック２０１は、入力フォームの内容の変更を検知し、その時点の入力フォームの内容を、サーブレットを実行し結果を返すアプリケーションサーバ５０４に非同期で送信し、��果を入力画面に反映する機能を持つ。ロジック２０２は入力画面ＨＴＭＬの入力フォームの内容から、書類を表すＸＭＬを作成し、書類を保存する装置５０６へ送信する機能を持つ。【００４０】  ユーザが組織図及び様式を組織図、様式を保存するサーバ５０２に保存すると、装置５０１が起動される。（図５▲１▼）【００４１】  装置５０１は、様式中に新しい型があれば、既存の型に分解し、既存の型に対して用意されたチェックロジックと加えられた制限を使って新しい型に対応する新たなチェックロジックを生成し実行可能なサーブレットを作成する。【００４２】  装置５０１は、様式の定義をＨＴＭＬのブロック要素６０１に置き換え、ブロック要素６０１の属性値に様式名を含める。様式の文書構造を解釈し、所定のＨＴＭＬのブロック要素６０２に置き換える。このとき項目名はブロック要素６０２の属性６０３に含める。文書構造の項目に割り当てられた型が既存の型であれば、既存の型に対して用意されたＨＴＭＬの入力フォーム要素６０４に置き換える。型が新しい型であれば、既存の型に分解し、同様にＨＴＭＬ要素６０４に置き換える。（図６）【００４３】  装置５０１は、様式に承認ポリシーの記載があれば組織図の承認ポリシーに優先し、その様式の承認ポリシーとする。【００４４】  装置５０１は、様式に権限を委譲する旨の記載があれば、該当する役職に対して、権限を委譲する属性を付与し、その様式の新たな組織図とする。例えば社長の権限を事業部長に委譲するのであれば、組織図の全ての事業部長に社長の権限を委譲する属性を付与する。この定義はこの様式を元に作成した書類に対して有効である。【００４５】  装置５０１は、様式に別部署による承認が必要な旨の記載があれば、組織図のツリー構造を変更する。例えば部長の承認の前に経理担当と経理課長の承認が必要な場合、組織図の全ての部長の直下の階層に、経理担当と経理課長による承認経路を追加する。【００４６】  装置５０１は、変更された組織図をＨＴＭＬのブロック要素７０１に置き換える。このとき組織図を構成する各要素の要素名は、ブロック要素７０１の属性７０２へ記述する。組織図を構成する各要素の全ての属性は、ブロック要素７０１の属性に置き換えられる。（図７）【００４７】  装置５０１は、文書構造を置き換えた要素６０２と、組織図を変換した要素７０１より、入力画面ＨＴＭＬを生成する。また、入力フォームの内容を変更した際に呼ばれるロジック２０１と、書類を提出するときに呼ばれるロジック２０２へのリンクを合わせて出力する。【００４８】  装置５０１は、生成した入力画面ＨＴＭＬをＷｅｂサーバ５０３へ、生成したサーブレットをアプリケーションサーバ５０４へ保存する。（図５▲２▼、▲３▼）【００４９】  ユーザがＷｅｂブラウザ５０５を利用してＷｅｂサーバ５０３へアクセスし、入力画面ＨＴＭＬおよびロジック２０１とロジック２０２を取得すると、Ｗｅｂブラウザ５０５が取得した入力画面ＨＴＭＬを表示する。（図５▲４▼）【００５０】  ユーザが入力画面へ必要事項を入力する。（図５▲５▼）【００５１】  Ｗｅｂブラウザ５０５は入力値の変更を契機に、ｊａｖａｓｃｒｉｐｔのｘｍｌ＿Ｈｔｔｐ＿Ｒｅｑｕｅｓｔ等で実装された��ジック２０１を使って非同期でアプリケーションサーバ５０４のチェックロジックサーブレットへ変更された入力値を送信し、入力値のチェックを行う。（図５▲６▼）値に問題があれば、エラーを表示する。このときチェックロジックを特定するキーとして型名を利用する。エラーの表示の形態としては、ダイアログボックスを使って警告したり、入力値をフォームの要素の色を変えて警告したり、ブロック要素の色や形等の属性値を変更して警告を行う。【００５２】  ユーザは必要事項を全て入力し、提出ボタンをクリックすると、Ｗｅｂブラウザ５０５は入力画面ＨＴＭＬからリンクされたロジック２０２を実行する。【００５３】  ロジック２０２は文書構造を表現しているＨＴＭＬのブロック要素６０２をＸＭＬ要素８０１に変換する。このときブロック要素６０２の属性６０３をＸＭＬ要素８０１の要素名とする。また、入力フォーム要素６０４は、ＸＭＬ要素８０２に変換し、入力フォーム要素６０４に入力された値を、ＸＭＬ要素８０２の内容８０３とする。（図８）【００５４】  ロジック２０２は入力画面ＨＴＭＬ中の組織図を表すブロック要素７０１から利用者のユーザｉｄが一致するユーザを探し、ユーザからツリーの階層構造に沿って上位に辿った経路を承認経路とし、その経路上の組織及び代表者属性が付与された役職、ユーザをそれぞれＸＭＬの承認予定者要素９０１、役職要素９０２、ユーザ要素９０３に置き換えて承認経路を表すＸＭＬを生成する。以上のルールで文書を表すＸＭＬを生成する。（図９）【００５５】  ロジック２０２は利用者を作成予定者として作成予定者要素９０５を作成し、作成予定者要素９０５の下位に役職要素、ユーザ要素を記述する。また、あわせて作成レたユーザを作成者要素９０６、作成した日時を、作成日時要素９０７として、作成予定者要素９０５の下位に記述する。【００５６】  ロジック２０２は文書を表すＸＭＬと承認経路を表すＸＭＬから書類ＸＭＬを生成し、書類を保存する装置５０６に送信する。（図５▲７▼）【００５７】  装置５０６は、サーバ１０４のチェックロジックサーブレットを呼び出し、書類ＸＭＬのチェックを行う。（図５▲８▼）【００５８】  書類ＸＭＬに問題がなければ書類を保存する。（図５▲９▼）【００５９】  なお、ハードウェアの構成について、当該サーバは複数台として記載してあるが、もちろん単体のサーバとして実装してもよく、また、複数の筐体で構成することを否定するものではない。
【実施例２】
【００６０】  実施例１にて、組織図から承認経路を求める詳細な方法を示す。【００６１】  様式に承認経路の設定を一切記述しなかった場合、書類を作成するユーザの所属する組織から最上位の組織まで辿った経路を承認経路とし、この経路上の各組織の代表者が承認者となる。（図１０）【００６２】  代表者は長で示される属性値であっても良いし、代表者である別の属性値を定めても良い。
【実施例３】
【００６３】  実施例１にて、権限の委譲があった場合に組織図から承認経路を求める詳細な方法を示す。【００６４】  様式に承認経路の設定として、ユーザＡの権限をユーザＢへ委譲するよう記述されていた場合、ユーザＢが承認を行えば、ユーザＡについても承認を行ったとみなす。ユーザＡが中間承認者であった場合、書類を作成するユーザの所属する組織から最上位の組織まで辿った経路のうちユーザＢの所属する組織のひとつ上位の組織からユーザＡの所属する組織までを除く経路を承認経路とする。ユーザＡが最終決裁者つまり全組織の長であった場合、書類を作成するユーザの所属する組織からユーザＢの所属する組織まで辿った経路を承認経路とする。この承認経路上の各組織の代表者が承認者となる。（図１１）
【実施例４】
【００６５】  実施例１にて、別組織の承認が必要だった場合に組織図から承認経路を求める詳細な方法を示す。【００６６】  様式に承認経路の設定として、役職Ｊが承認する前に他の組織ＷＷの承認が必要であると記述されていた場合、組織図に組織Ｋを含む承認経路を追加する。まず、組織Ｋから最上位の組織まで辿った経路を経路Ｌとする。このとき経路Ｌ上で権限の委譲設定が有れば、実施例３で示した通り経路から委譲者を取り除く。役職Ｊの所属する組織の前に経路Ｌを追加し、その上で書類を作成するユーザの所属する組織から最上位の組織まで辿った経路を承認経路とする。この経路上の各組織の代表者が承認者となる。（図１２）
【実施例５】
【００６７】  実施例１にて、保存された書類を検索し、自身が承認しなければならない書類を特定する方法を示す。【００６８】  実施例１で定めた、装置に加え、書類を検索する装置５０７を用意する。【００６９】  ユーザはＷｅｂブラウザ５０５を利用して、書類を検索する装置５０７に対して、承認者要素を持たない承認予定者要素の子孫のユーザ要素に自身のｕｓｅｒＩＤが存在し、当該承認予定者要素のひとつ下位に、承認者要素を持つ承認予定者要素があるか、作成者要素を持つ作成予定者要素がある書類を検索するよう要求する。書類を検索する装置５０７は要求された条件で検索を行い、条件に該当する書類の一覧を返す。
【実施例６】
【００７０】  実施例１にて、承認を行う方法を示す。【００７１】  実施例１及び実施例５で定めた装置に加え、承認をする装置５１２を用意する。また承認を行う画面２７０１を用意しＷｅｂサーバ５０３に保存する。承認を行う画面２７０１は、書類を取得し表示する機能と、ユーザが承認をするボタンと、ユーザの承認を承認をする装置５１２に送信する機能を持つ。【００７２】  ユーザは実施例５で示した方法で、承認を行う書類の一覧を取得し、承認を行う書類を選択する。ユーザは承認を行う画面２７０１に承認を行う書類の識別子を渡し、承認を行う画面２７０１に承認する書類を表示する。ユーザが承認ボタンを押下すると、承認を行う画面２７０１は、承認をする装置５１２に、前記識別子とユーザｉｄを送信する。承認をする装置５１２は、前記識別子により変更する書類を特定し、書類から当該ユーザを探す。当該ユーザが承認予定者として存在したならば、承認予定者要素１３０１の下位に、承認者要素１３０２と承認日時要素１３０３を追加する。（図１３）
【実施例７】
【００７３】  実施例１にて、差戻しを行う方法を示す。差戻しとは承認者が、書類を承認せず書類作成者に書類の再作成を指示することである。【００７４】  実施例１及び実施例５で定めた装置に加え、承認経路を変更する装置５１３を用意する。また差戻しを行う画面２７０２を用意しＷｅｂサーバ５０３に保存する。差戻しを行う画面２７０２は、書類を取得し表示する機能と、ユーザが差戻しをするボタンと、ユーザの差戻しにより書類の承認経路を変更する機能と、変更した承認経路を承認経路を変更する装置５１３に送信する機能を持つ。【００７５】  ユーザは実施例５で示した方法で、承認可能な書類の一覧を取得し、差戻しを行う書類を選択する。ユーザは差戻しを行う画面２７０２に差戻しを行う書類の識別子を渡し、差戻しを行う画面２７０２に書類を表示する。ユーザが差戻しボタンを押下すると、差戻しを行う画面２７０２は、書類から当該ユーザを探す。当該ユーザが承認予定者として存在したならば、承認予定者要素１４０１の下位に、差戻し者要素１４０２と差戻し日時要素１４０３を追加する。差戻しを行う画面２７０２は、書類から承認者要素及び承認日時要素、作成者要素、作成者日時を検索し、存在したならば削除する（図１４）。差戻しを行う画面２７０２は、承認経路を変更する装置５１３に、前記識別子と変更された承認経路を送信する。承認経路を変更する装置５１３は、前記識別子により変更する書類を特定し、当該書類に記述された現在の承認経路要素を承認経路履歴要素に変更する。次に、当該書類に変更された新しい承認経路を追加する。【００７６】  書類の作成者は、自身が作成予定者であり、当該作成予定者の下位に作成者要素が無い書類を検索をすると、差戻しされた書類を特定できる。
【実施例８】
【００７７】  実施例１にて、承認時に承認経路を変更する方法を示す。【００７８】  実施例１及び実施例５で定めた装置に加え、承認経路を変更する装置５１３を用意する。また承認経路を変更する画面２７０３を用意しＷｅｂサーバ５０３に保存する。承認経路を変更する画面２７０３は、書類を取得し表示する機能と、書類の承認経路を表示する機能と、表示された承認経路に経路を追加する機能と、ユーザが承認経路の変更を確定するボタンと、変更した承認経路を承認経路を変更する装置５１３に送信する機能を持つ。【００７９】  ユーザは実施例５で示した方法で、承認可能な書類の一覧を取得し、承認経路を変更する書類を選択する。ユーザは承認経路を変更する画面２７０３に承認経路を選択する書類の識別子を渡し、承認経路を変更する画面２７０３に書類と承認経路を表示する。ユーザが画面にて承認経路を追加すると、承認経路を変更する画面２７０３は書類の承認経路についても変更を行う。ユーザが承認経路の変更を確定するボタンを押下すると、承認経路を変更する画面２７０３は、承認経路を変更する装置５１３に、前記識別子と変更された承認経路を送信する。承認経路を変更する装置５１３は、前記識別子により変更する書類を特定し、当該書類に記述された現在の承認経路要素を承認経路履歴要素に変更する。次に、当該書類に変更された新しい承認経路を追加する。
【実施例９】
【００８０】  実施例１にて、強制決裁を行う方法を示す。強制決裁とは、上位者が決裁する事で、未承認のユーザがいても強制的に書類を決裁する事を指す。【００８１】  実施例１で定めた装置に加え、書類を検索する装置５０７と、承認をする装置５１２を用意する。また承認を行う画面２７０１を用意しＷｅｂサーバ５０３に保存する。承認を行う画面２７０１は、書類を取得し表示する機能と、ユーザが承認をするボタンと、ユーザの承認を承認をする装置５１２に送信する機能を持つ。【００８２】  ユーザはＷｅｂブラウザ５０５を利用して、書類を検索する装置５０６に対して、承認ポリシーの強制決裁が可能と設定されていて、自身が承認予定者として存在し、当該承認予定者要素に承認者要素が無い書類を検索するよう要求する。書類を検索する装置５０６は要求された条件で検索を行い、条件に該当する書類の一覧を返す。【００８３】  ユーザは強制決裁を行う書類を選択し、承認を行う画面２７０１に強制決裁を行う書類の識別子を渡し、承認を行う画面２７０１に承認する書類を表示する。ユーザが承認ボタンを押下すると、承認を行う画面２７０１は、承認をする装置５１２に、前記識別子とユーザＩｄを送信する。承認をする装置５１２は、前記識別子により変更する書類を特定し、書類から当該ユーザを探す。当該ユーザが承認予定者として存在したならば、承認予定者要素の下位に、承認者要素と承認日時要素を追加する。また、当該ユーザの承認予定者要素と作成者の間に、承認していない承認予定者要素があったならば、承認予定者要素の下位に、承認者要素と承認日時要素を追加する。
【実施例１０】
【００８４】  実施例１にて、代行承認を行う方法を示す。代行承認とは、承認者が不在などの理由で承認できない場合、同一組織内のユーザが代わりに承認を行うことを指す。【００８５】  実施例１で定めた装置に加え、書類を検索する装置５０７と、組織図を参照する装置５１１と、承認をする装置５１２を用意する。また承認を行う画面２７０１を用意しＷｅｂサーバ５０３に保存する。承認を行う画面２７０１は、書類を取得し表示する機能と、ユーザが承認をするボタンと、ユーザの承認を承認をする装置５１２に送信する機能を持つ。【００８６】  ユーザは組織図を参照する装置５１１に問い合わせ、自身の所属名を取得する。ユーザはＷｅｂブラウザ５０５を利用して、書類を検索する装置５０７に対して、承認ポリシー代行承認が可能と設定されていて、自身の所属名が承認予定者の所属名と一致し、当該承認予定者要素に承認者要素が無い書類を検索するよう要求する。書類を検索する装置５０７は要求された条件で検索を行い、条件に該当する書類の一覧を返す。【００８７】  ユーザは代行承認を行う書類を選択し、承認を行う画面２７０１に代行承認を行う書類の識別子を渡し、承認を行う画面２７０１に承認する書類を表示する。ユーザが承認ボタンを押下すると、承認を行う画面２７０１は、承認をする装置５１２に、前記識別子と所属名とユーザｉｄを送信する。承認をする装置５１２は、前記識別子により変更する書類を特定し、書類から当該所属名を探す。当該所属名が承認予定者として存在したならば、承認予定者要素の下位に、承認者要素と承認日時要素を追加する。
【実施例１１】
【００８８】  実施例１にて、書類の作成時に権限の委譲を行う方法を示す。【００８９】  装置５０１が、入力画面ＨＴＭＬを生成する際に、入力フォームの内容を変更した際に呼ばれるロジック２０１と、書類を提出するときに呼ばれるロジック２０２へのリンクに加えて、権限の委譲を設定するロジック２０３へのリンクを出力する。ロジック２０３は生成されたＨＴＭＬを配信するＷｅｂサーバ５０３に保存する。ロジック２０３は、入力画面ＨＴＭＬの承認経路を表示する機能と、入力画面ＨＴＭＬの承認経路に権限の委譲を設定する機能を持つ。【００９０】  ユーザは入力画面ＨＴＭＬをＷｅｂブラウザ５０５に表示する。ユーザがロジック２０３を呼び出し、書類の承認経路を表示し、表示された承認経路に対して権限の委譲を設定する。ロジック２０３は入力画面ＨＴＭＬが持つ組織図を変更する。以後実施例１の方法で書類を生成し保存する。権限委譲を設定した組織図を元に書類の承認経路が作成されるため、当該書類のみ権限の委譲が設定できる。
【実施例１２】
【００９１】  実施例１にて、様式を定義する詳細な方法を示す。【００９２】  様式は以下のような文法で定義する。
ｄｏｃｄｅｆ  様式名２１０１＝｛
定義２１０２
｝【００９３】  様式名２１０１は様式の識別子になる。【００９４】  定義２１０２には実施例１３、実施例１４、実施例１５で示す型の定義、文書構造の定義、項目の定義、承認経路の定義を記述する。
【実施例１３】
【００９５】  実施例１にて、型を定義する詳細な方法を示す。【００９６】  新しい型は次のような文法で定義する
ｔｙｐｅ  型の名前２１０２＝型記述２１０３【００９７】  型の名前２１０２は新しい型の識別子となる、型記述２１０３はエイリアス、択一、複数選択、コンテナの４種類が有る。（図２１）【００９８】  エイリアスとは、既存の型の名前か定義済みの新しい型の名前である。エイリアスとして
既存の型の名前を記述すると既存の型と同一の機能を持つ新しい名前の型を定義できる。定義済みの新しい型の名前を記述した場合も同様に定義済みの新しい型と同一の機能を持つ新しい名前の型を定義できる。（図２１）【００９９】  択一とは、複数個の値のうち、１つだけ選ぶ事の出来る型である。大カッコの中に数値若しくはダブルクォートで囲まれた文字列をカンマで区切って列挙する。（図２１）【０１００】  複数選択とは、複数個のうち、任意の個数の値を選択する事の出来る型である。小カッコの中に数値若しくはダブルクォートで囲まれた文字列をカンマで区切って列挙する。（図２１）【０１０１】  コンテナとは、既存の型を組み合わせた新たな方を定義することが出来る型である。縦棒の間に型の名前をカンマで区切って列挙する。（図２１）【０１０２】  型に必須条件等の制限を加えるために、アノテーションと呼ぶ文法を用いる。アノテーションは型の定義の前の行か、コンテナを定義した際に列挙した型の名前の後ろに記述できる。アノテーションは次のように記述する。
＠アノテーション名（引数１，…，引数ｎ）【０１０３】  引数が無いアノテーションは中カッコ以降は省略可能である。【０１０４】  アノテーションは複数記述可能で、その場合は次のように記述する。
＠［アノテーション名１（），…アノテーション名ｎ（）］【０１０５】  アノテーションには次のものがある。
・必須  このアノテーションを付与すると入力が必須な型となる。
・変域内（変域）  変域内の値のみ記述可能な型となる。
・列挙内（列挙値）  列挙した値のみ記述可能な型となる。
・正規表現（正規表現）  正規表現にマッチした値のみ記述可能な型となる。（図２２）【０１０６】  既存の型は、テキスト型や数値型など、プリミティブな型だけでなく、稟議書類で通常用いられる型が事前に用意される。次に既存の型として用意される型を列挙する。【０１０７】    ・テキスト
・数値
・択一選択
・複数選択
・金額
・住所
・住所フリガナ
・氏名
・氏名フリガナ
・年齢
・性別
・日時
・日付
・期間
・費目
・旅程
・地名
・駅名
・カード番号
・口座番号
・電話番号
・人数
・数量
・部署
・役職
・法人名
【実施例１４】
【０１０８】  実施例１にて、項目及び文書構造を定義する詳細な方法を示す。【０１０９】  様式を定義した中カッコの中には項目と文書構造を定義できる。項目は以下の文法で定義する。
項目名２１０４：型名２１０５＝初期値２１０６【０１１０】  項目名２１０４は、項目の識別子となる。【０１１１】  型名２１０５は、既存の型または定義した新しい型の型名を記述する。【０１１２】  初期値２１０６は入力画面に表示される初期値となる。数値もしくはダブルクォートで囲まれた文字列を記述できる。初期値は省略することが出来る。【０１１３】  文書構造は以下の文法で定義する。
ｄｅｆ  構造名２１０７＝｛
定義２１０８
｝【０１１４】  構造名２１０７は構造の識別子となる。【０１１５】  定義２１０８は、型の定義および文書構造の定義、項目の定義を記述する。（図２１）
【実施例１５】
【０１１６】  実施例１にて、承認経路を定義する詳細な方法を示す。【０１１７】  承認経路の定義は、新しい承認経路の定義、承認ポリシーの定義、権限委譲の定義、経路の追加が定義できる。【０１１８】  新しい承認経路の定義は以下のように記述する。
ｒｏｕｔｅｄｅｆ  承認経路名２３０１＝｛
定義２３０２
｝【０１１９】  承認経路名は、承認経路の識別子である。【０１２０】  定義２３０２は、新しい承認経路の定義、承認ポリシーの定義、権限委譲の定義、経路の追加が定義できる。（図２３）【０１２１】  承認経路を変更する場合は、様式の定義の直下に承認経路の定義を必ずひとつ記述する。【０１２２】  承認経路の定義を記述しなかった場合は、組織図を書類を作成するユーザの所属する組織から最上位の組織まで辿った経路を承認経路とし、この経路上の各組織の代表者が承認者となる。【０１２３】  後述の経路の追加にて、経路を追加するための承認経路を定義する場合は、経路の開始を指定する。その場合次のように記述する。
ｂｅｇｉｎ  組織［組織図中の組織名２３０３］  または、
ｂｅｇｉｎ  役職［組織図中の役職名２３０４］  または、
ｂｅｇｉｎ  ユーザ［組織図中のユーザ名２３０５］【０１２４】  このように指定すると、指定した要素から組織図の階層構造に沿って、最上位まで辿る経路が承認経路となる。【０１２５】  承認ポリシーの定義は以下のように記述する。
ｐｏｌｉｃｙｄｅｆ  組織［組織の名前２３０６］＝｛
ポリシー名２３０７＝設定値
｝【０１２６】  組織の名前２３０６は、組織図中の組織の名前を記述する。例えば、組織図の最上位の組織要素の名前が“株式会社ＸＸＸ”であり、その名前を指定すれば、全社のポリシーが変更される。【０１２７】  ポリシー名２３０７はポリシーの名前を指定する。実施例１では強制決裁の可否と代行承認の可否が指定できる。（図２３）【０１２８】  権限委譲の定義は以下のように記述する。
ｄｅｌｅｇａｔｉｏｎ  役職［組織図中の役職名２３０８］＝役職［組織図中の役職名２３０９］【０１２９】  左辺は権限を委譲される側、右辺は権限を委譲する側である。【０１３０】  組織図中の役職名２３０８、組織図中の役職名２３０９は組織図中の役職名を記述する。
例えば、社長の権限を事業部長へ委譲する場合は、組織図中の役職名２３０９に社長を、組織図中の役職名２３０８に事業部長を記述する。（図２３）【０１３１】  経路の追加は以下のように記述する。
ａｄｄｒｏｕｔｅ役職［組織図中の役職名２３０９］＝定義済みの承認経路名２３１０【０１３２】  左辺に追加される承認経路上の場所を、組織図中の役職名２３０９で示し、右辺に追加する承認経路を定義済みの承認経路名２３１０で指定する。（図２３）
【実施例１６】
【０１３３】  実施例５の検索を容易にする方法を示す。【０１３４】  実施例５では、要素の階層構造や前後みて検索を行わなければならないため、検索言語としてＸＰａｔｈかＸＰａｔｈと同等な能力を持つ検索言語が必要である。【０１３５】  実施例１で定めた装置に加え、書類のインデックスを作成する装置５１３と、書類のインデックスを検索する装置５１４を用意する。インデックスには、書類の識別子、全ての承認予定者、全ての承認予定組織、今の承認予定者、今の承認予定組織、承認者のフィールドを用意する。【０１３６】  書類が作成または承認されると、書類のインデックスを作成する装置５１３が起動され、書類を解析し、前記インデックスのフィールドを更新する。書類の作成時は、書類の識別子、全ての承認予定者、全ての承認予定組織、今の承認予定者、今の承認予定組織が作成される。書類の承認時は、承認者フィールドに承認者を記録し、全ての承認予定者と全ての承認予定組織から、承認を行った承認者と組織を削除し、今の承認予定者と、今の承認予定組織を次の承認予定者と承認予定組織に更新する。【０１３７】  書類を検索する際は、書類を直接検索するのではなく、インデックスを検索し、書類の識別子を得る。実施例５と同じく自身が承認しなければならない書類を検索する場合は、今の承認予定者に自身が含まれているものを検索する。実施例９と同じく強制決裁可能な書類を検索する場合は、全ての承認予定者に自身が含まれている物を検索する。実施例１０と同じく代行決裁可能な書類を検索する場合は、自身の所属する組織が今の承認予定組織に含まれるものを検索する。
【実施例１７】
【０１３８】  実施例１を元に、生成された画面に対して、文字のサイズや色、配置等画面の見た目を変更する方法を示す。【０１３９】  装置５０１が、様式の文書構造を解釈し、所定のＨＴＭＬのブロック要素６０２に置き換える際に、ブロック要素６０２のｃｌａｓｓ属性１００３に項目名を記述する。同様に、型をＨＴＭＬの入力フォーム要素６０４に置き換える際に、入力フォーム要素６０４のｃｌａｓｓ属性１００４に型名を記述する。このとき、型が新しい型の場合は、元にした既存の型名と新しい型名をスペースで区切って記述する。（図１５）【０１４０】  事前に既存の型名に対応するＣＳＳ定義がされたＣＳＳファイルをＷｅｂサーバ５０３に用意しておき、装置５０１が入力画面ＨＴＭＬを生成する際、このＣＳＳファイルをリンクする記述１００１を追記する。【０１４１】  新しい型のＣＳＳを記述できるようにするために、装置５０１が入力画面ＨＴＭＬを生成する際、様式名のＣＳＳファイルをリンクする記述１００２を追記する。ｃｌａｓｓ属性には、新しい型名と既存の型名両方が記述されているため、新しい型名のＣＳＳ定義を行わなければ、既存の型のＣＳＳ定義が採用され、新しい型のＣＳＳ定義を既存の型より下になるように行えば、新しい型のＣＳＳが優先される。【０１４２】  Ｗｅｂブラウザ５０５は、入力画面ＨＴＭＬを表示する際、このＣＳＳ定義に従いレンダリングを行う。【０１４３】  このような方法で、型名をキーにしてＣＳＳの記述を行うことが出来るため、入力画面の見た目を変更する事が容易に可能である。【０１４４】  なお、入力画面ＨＴＭＬの要素のｃｌａｓｓ属性に項目名、および、型名を直接記述し、それに対応するＣＳＳファイルを用意したが、項目名、型名に対応付けたＩＤを別途付与し、このＩＤに対応するＣＳＳファイルを用意するようにしてもよい。
【実施例１８】
【０１４５】  実施例１を元に、認可制御を行う方法を示す。【０１４６】  実施例１で定めた、この言語を解釈し入力画面であるＨＴＭＬ及びチェックロジックであるサーブレットを生成する装置５０１と、組織図、様式を保存するサーバ５０２と、生成されたＨＴＭＬを配信するＷｅｂサーバ５０３と、サーブレットを実行し結果を返すアプリケーションサーバ５０４と、ＨＴＭＬを表示するＷｅｂブラウザ５０５と、書類を保存する装置５０６に加え、認証を行う装置５０８と、認可を行う装置５０９と、書類を参照する装置５１０と、組織図を参照する装置５１１を用意する。認証を行う装置５０８と、認可を行う装置５０９は、Ｗｅｂブラウザ５０５と書類を参照する装置５１０の間に配置する。Ｗｅｂブラウザ５０５からの要求は、認証を行う装置５０８、認可を行う装置５０９の順番で通過し、書類を参照する装置５１０に送られる。要求に対する応答は、書類を参照する装置５１０から、認可を行う装置５０９、認証を行う装置５０８の順で通過し、Ｗｅｂブラウザ５０５へ送られる。（図１６）【０１４７】  また、新たに認可に関するポリシーの設定を組織図に対して行えることとする。認可に関するポリシーとは、同一組織のユーザの参照可否、組織異動後の参照可否とし、組織図の組織要素の属性として、真偽値で記述される。（図１７）【０１４８】  ユーザは、本システムを利用するために、Ｗｅｂブラウザ５０５から認証を行う装置５０８にアクセスする。認証を行う装置５０８はユーザに、ユーザＩＤとパスワードの入力を求める。ユーザーＩＤとパスワードの組み合わせが正しければ認証は成功し、以後Ｗｅｂブラウザ５０５から本システムへの通信にユーザＩＤを含める。【０１４９】  認可を行う装置５０９は、要求を受けると、要求から認証を行う装置５０８が付与したユーザＩＤを取り出し、組織図を参照する装置５１１へ問い合わせ、ユーザＩＤに該当するユーザの役職と所属する組織を求める。認可を行う装置５０９は、要求を書類を参照する装置へ転送する。【０１５０】  書類を参照する装置５１０は、要求に該当する書類を応答する。応答を受けた認可を行う装置５０９は書類の内容を確認し、書類を参照させてよいか判断する。同一組織のユーザが参照可能な場合、書類の承認経路中にユーザが所属する組織があれば参照を許可する。同一組織のユーザが参照不可で、組織異動後の参照が可能な場合、書類の承認経路中にユーザＩＤが存在すれば参照を許可する。同一組織のユーザが参照不可で、組織異動後の参照も不可な場合、書類の承認経路中にユーザＩＤが存在し、所属する部署も同一な場合参照を許可する。また、上記以外の場合は参照を許可しない。【０１５１】  参照が許可されたならば、認可を行う装置５０９、認証を行う装置５０８は応答をＷｅｂブラウザ５０５へ転送する。許可されないのであれば、認可を行う装置５０９は認可エラーを応答する。【０１５２】  このような方法で、書類中に記載された承認経路の情報を使って認可制御が可能である。
【実施例１９】
【０１５３】  実施例１を元に、画面の入力値によって、入力画面の構成要素の表示、非表示を自在に変更できるようにする方法を示す。【０１５４】  実施例１で定めた様式記述言語を拡張し、新たな文法として選択文１８０１を導入する。選択文１８０１は、条件式１８０２を与えることが出来、中カッコで文書構造の項目を囲うことが出来る。条件式１８０２の値がＴＲＵＥならば、中カッコで囲われた部分は有効、ＦＡＬＳＥであれば無効を意味する。条件式１８０２は、次の比較演算子（＝、＞、＜、＝＞、＝＜）と真偽値、数値、文字列、項目の位置を示す式１８０３が記述できる。項目の位置を示す式１８０３は、項目名を”／”でつなげたＰＡＴＨ式によって記述する。（図１８）【０１５５】  装置５０１は様式を入力画面ＨＴＭＬに変換する際、様式中に選択文１８０１があれば、ブロック要素１８０４に変換する。条件式１８０２はブロック要素１８０４の属性１８０５に記載される。【０１５６】  ロジック２０１に、条件式を評価した結果がＴＲＵＥであれば該当要素のスタイルを表示に変更し、ＦＡＬＳＥになれば該当要素のスタイルを非表示に変更する関数を用意する。例えば、該当要素のスタイル属性のｖｉｓｉｂｉｌｉｔｙプロパティを変更することで該当要素の表示、非表示を変更することが出来る。【０１５７】  Ｗｅｂブラウザ５０５は、入力値に変更があるとロジック２０１を呼び出し、該当要素の表示、非表示を切り替える。
【実施例２０】
【０１５８】  実施例１を元に、画面の入力値によって、承認経路を変更する方法を示す。【０１５９】  実施例１で定めた様式記述言語を拡張し、新たな文法として選択文１９０１を導入する。選択文１９０１は、条件式１９０２を与えることが出来、中カッコで承認経路の定義を囲うことが出来る。条件式１９０２の値がＴＲＵＥならば、中カッコで囲われた部分は有効、ＦＡＬＳＥであれば無効を意味する。条件式１９０２は、次の比較演算子（＝、＞、＜、＝＞、＝＜）と真偽値、数値、文字列、項目の位置を示す式１９０３が記述できる。項目の位置を示す式１９０３は、項目名を”／”でつなげたＰＡＴＨ式によって記述する。（図１９）【０１６０】  装置５０１は様式の承認経路設定を組織図に反映する際、各条件式の値がＴＲＵＥおよびＦＡＬＳＥの場合についてとり得る全ての組み合わせの組織図を作成する。それぞれの組織図を、ＨＴＭＬのブロック要素１９０４で囲い、条件式１９０２をブロック要素１９０４の属性１９０５に記載する。【０１６１】  ロジック２０１に、条件式を評価した結果がＴＲＵＥであれば該当要素を有効にし、ＦＡＬＳＥになれば該当要素を無効にする関数を用意する。【０１６２】  Ｗｅｂブラウザ５０５は、入力値に変更があるとロジック２０１を呼び出し、該当要素の有効、無効を切り替える。
【実施例２１】
【０１６３】  実施例１を元に、様式を定義した言語から当該プログラムの説明文を出力できるようにする方法を示す。【０１６４】  実施例１で定めた様式記述言語を拡張し、コメント記号を行頭に記述する事でコメント文を入力できるようにする。さらにコメント文の中に説明文記号を記述することで、出力する説明文を指定可能とする。【０１６５】  装置５０１は様式を解釈した後、様式に定義された独自型定義や文書構造とともにコメント中の説明文を取り出し、設計ドキュメントとして可読性の高い形式に変換し出力する。
【実施例２２】
【０１６６】  実施例１を元に、チェックロジックにて外部データベースの値を使ってチェックを行う方法を示す。【０１６７】  実施例１で定めた、この言語を解釈し入力画面であるＨＴＭＬ及びチェックロジックであるサーブレットを生成する装置５０１と、組織図、様式を保存するサーバ５０２と、生成されたＨＴＭＬを配信するＷｅｂサーバ５０３と、サーブレットを実行し結果を返すアプリケーションサーバ５０４と、ＨＴＭＬを表示するＷｅｂブラウザ５０５と、書類を保存する装置５０６に加え、外部データベース５１５を用意する。外部データベース５１５には、新しい型のとりうる値のリストが保存されており、データ名を指定する事で取り出すことが出来る。【０１６８】  新しい型の定義にて、型の制限として値を列挙する際に、この外部データベース５１５のデータ名を記述する。【０１６９】  装置５０１は、型の制限値として外部データベース５１５のデータ名が記述されていた場合、引数を外部データベース５１５に問い合わせて値の存在を確認し、存在すれば正常、無ければエラーとするチェックロジックを備えるサーブレットを生成する。
【実施例２３】
【０１７０】  実施例２２を元に、チェックロジックにエラーチェックだけでなく入力補助の機能を追加する方法を示す。【０１７１】  入力補助を行えるようにするために、装置５０１が生成するサーブレットの仕様を次のように変更する。実施例２２では入力値が外部データベース５１５に存在しなければエラーとしていたが、入力値が外部データベース５１５のデータと部分一致した場合、部分一致した値のリストを返すこととする。【０１７２】  Ｗｅｂブラウザ５０５は、入力画面ＨＴＭＬの入力フォームに値が入力される度に、ロジック２０１を使って非同期でアプリケーションサーバ５０４のチェックロジックサーブレットを呼び出し、入力値のチェックを行う。このとき、値のリストが返却された場合は入力候補を選択リストとして表示し、エラーが返却された場合は、エラーを表示する。
【実施例２４】
【０１７３】  実施例１を元に、組織図の定義言語をＸＭＬではなく、専用の言語とする場合の方法を示す。【０１７４】  実施例１では、組織図を記述する言語をＸＭＬとしたが、本実施例では専用の言語とし、文書構造と同様の文法とする。（図２０）【０１７５】  また、様式の承認経路設定に、新たに組織図そのものを記述できるようにする。【０１７６】  これにより、その様式専用の組織階層を容易に定義する事が可能となる。
【実施例２５】
【０１７７】  実施例１を元に、複数の並行した承認経路を追加出来るようにする方法を示す。【０１７８】  実施例１５で示した、承認経路の追加方法で左辺に同じ場所を指定し、複数個の経路を追加することで、並行した承認経路を追加できる。このとき並行の条件を指定できるように、承認経路の定義言語を拡張し、次の記述を可能とする。【０１７９】  ａｄｄｒｏｕｔｅ役職［組織図中の役職名２４０１］＝定義済みの承認経路名２４０２追加条件２４０３
追加条件２４０３は、”Ａｎｄ”または″Ｏｒ″を指定する。【０１８０】  様式中にこの定義があれば、組織図中の役職名２４０１を持つ組織要素の下位に、承認グループ要素２４０４を追加し、承認グループ要素の下位に並行要素２４０５を追加し、並行要素２４０５の条件属性２４０６を追加条件２４０３とする。定義済みの承認経路２４０２で示される承認経路は、並行要素の下位に並列に追加する。組織図中の役職名２４０１を持つ組織要素の下位にあった組織要素は承認グループ要素２４０４の下位に移動する。（図２４）【０１８１】  この定義が記述された様式が組織図、様式を保存するサーバ５０２に保存されると、実施例１に示した方法で、装置５０１は様式を入力画面ＨＴＭＬに変換する。変換された入力画面ＨＴＭＬの例を図２５に示す。【０１８２】  次に、ユーザが当該入力画面ＨＴＭＬから書類を作成すると、実施例１に示した方法で、書類ＸＭＬに変換される。変換された書類ＸＭＬの例を図２６に示す。【０１８３】  実施例５で示した自身が承認しなければならない書類を特定する方法のうち、検索条件を次のように変更する事で。並行した承認経路があっても検索可能である。【０１８４】  承認者要素を持たない承認予定者要素の子孫のユーザ要素に自身のｕｓｅｒＩＤが存在し、当該承認予定者要素のひとつ下位に、承認者要素を持つ承認予定者要素があるか、作成者要素を持つ作成予定者要素があるか、属性がＡＮＤである並行要素の下位の全ての承認予定者要素が承認者要素をもつ承認予定グループがあるか、属性がＯＲである並行要素の下位のいずれかの承認予定者要素が承認者要素をもつ承認予定グループがあるか、または、自身が所属する承認者グループのひとつ下位に、承認者要素を持つ承認予定者要素があるか、作成者要素を持つ作成予定者要素があるか、属性がＡＮＤである並行要素の下位の全ての承認予定者要素が承認者要素をもつ承認予定グループがあるか、属性がＯＲである並行要素の下位のいずれかの承認予定者要素が承認者要素をもつ承認予定グループがある書類を検索する。
【実施例２６】
【０１８５】  実施例１を元に、複数の様式を選択出来るようにする方法を示す。（図２７）【０１８６】  利用者が作成しようとする書類を、選択できるようにするために、様式選択画面を用意する。様式選択画面は、組織図、様式を保存するサーバ５０２から、全ての様式の一覧を取得し、表形式で表示する。表形式の一覧には、様式のＩＤ、様式名を表示する。さらに書類を検索する装置５０７から、各様式の提出件数を検索し表示する。【０１８７】  画面右上の検索ボックスに、様式ＩＤや様式名をキーワードとして入力する事で、表示されている様式の一覧を絞り込む事が可能である。【０１８８】  また、一覧表の各タイトル項目（様式名や提出件数等）をクリックすることで表示内容をソートすることが可能である。【０１８９】  表示件数が一定数を超えた場合は、次ページボタンが押下可能になり、次ページボタンを押下すると、次ページの書類一覧が表示される。同様に前のページに戻る場合は、前ページボタンを押下すると、前のページの書類一覧が表示される。【０１９０】  選択した様式の新規作成ボタンを押下することで、当該様式の入力画面が表示される。
【実施例２７】
【０１９１】実施例１を元に、書類への入力を行える方法を示す。（図２８）【０１９２】本画面は装置５０１により、生成された入力画面ＨＴＭＬをＷＥＢブラウザ５０５により表示したものである。【０１９３】入力フォームは実施例１７に示す方法で、ＣＳＳの定義に従い整形して表示される。【０１９４】プリント、提出、一時保存、破棄ボタンは、様式の定義に係らず全ての入力画面で表示される。【０１９５】利用者が入力フォームに値を入力すると、実施例１で示した通り、入力値の変更を契機にロジック２０１を使って、非同期でアプリケーションサーバ５０４のチェックロジックサーブレットに、型名と変更された入力値を送信し、入力値のチェックを行う。チェック結果がエラーであれば、入力フォームの色を赤色等に変更し、利用者に警告を行う。【０１９６】このとき、実施例２３の方法で、入力候補をセレクトボックス形式で表示する事も出来る。また、実施例１で定めた装置に加え、書類を一時保存する装置５１６を用意し、作成途中の書類を保存する事も出来る。作成途中の書類の保存は、一定期間間隔で自動的に行うが、一時保存ボタンを押下する事で、利用者の意思で保存する事も可能である。【０１９７】プリントボタンを押下するとＷＥＢブラウザ５０５の機能で、印刷を行う事が可能である。【０１９８】  破棄ボタンを押下すると、一時保存している書類を削除し、画面を閉じる。【０１９９】利用者の入力が終了し、提出ボタンを押下すると、ロジック２０１により書類の全項目について入力値のチェックが行われる。このときは、チェックロジックの結果がエラーであれば詳細なエラーメッセージを画面に表示する。エラーが無ければ、確認画面が表示され、利用者が目視確認を行った後、確認画面の提出ボタンを押下すると、チェックロジック２０２が呼ばれ、実施例１に示した方法により、書類ＸＭＬに変換され、書類を保存するサーバ５０５に送信される。書類を保存するサーバ５０５は、再度アプリケーションサーバ５０４により書類ＸＭＬのチェックを行い、問題が無ければ保存される。通常、事前にチェックを行い問題が無かった書類が送られてくるため、エラーになる事は無い。保存が正常に終了すれば、書類を保存するサーバは正常応答を返し、入力画面は正常に保存された事を画面に表示して利用者に伝える。
【実施例２８】
【０２００】  実施例１を元に、一時保存した書類の入力を再開できるようにする方法を示す。（図２９）
利用者が一時保存した書類を、再編集する事が出来るように、一時保存選択画面を用意する。一時保存選択画面を表示すると、ｕｓｅｒｉｄをキーに書類を一時保存する装置５１６を検索し、利用者が一時保存している書類の一覧を表形式で表示する。表形式の一覧には、通し番号と書類名と保存日時が表示される。【０２０１】  画面右上の検索ボックスに、書類名や保存日時をキーワードとして入力する事で、表示されている書類の一覧を絞り込む事が可能である。【０２０２】  また、一覧表の各タイトル項目（書類名や保存日時等）をクリックすることで表示内容をソートすることが可能である。【０２０３】  利用者が選択した書類の再開ボタンを押下すると、当該書類の一時保存されている内容が入力された入力画面が表示される。【０２０４】  利用者が選択した書類の削除ボタンを押下すると、当該書類を削除することが出来る。【０２０５】  利用者が、削除したい書類のチェックボックスをチェックし、一括削除ボタンを押下すると、選択した書類を一括して削除する事が可能である。
【実施例２９】
【０２０６】  実施例１を元に、利用者が作成した書類のうち、未決済の書類を表示する方法を示す。（図３０）【０２０７】  利用者が作成した書類のうち、未決済の書類を選択できるようにするために、提出済み未決済画面を用意する。提出済み未決済画面は、書類を検索する装置５０７から、作成者要素の子孫のユーザ要素のｕｓｅｒｉｄ属性が自身のｕｓｅｒｉｄに一致し、最上位の承認予定者要素が承認者要素を持たない書類を検索し、条件に該当する書類の一覧を取得し、書類のＩＤおよび様式名、提出日を表形式で表示する。【０２０８】  画面右上の検索ボックスに、様式ＩＤや様式名をキーワードとして入力する事で、表示されている書類の一覧を絞り込む事が可能である。【０２０９】  一覧表の各タイトル項目（様式名や提出日）をクリックすることで表示内容をソートすることが可能である。【０２１０】  表示件数が一定数を超えた場合は、次ページボタンが押下可能になり、次ページボタンを押下すると、次ページの書類一覧が表示される。同様に前のページに戻る場合は、前ページボタンを押下すると、前のページの書類一覧が表示される。【０２１１】  選択した書類の表示ボタンを押下することで、当該書類の参照画面が表示される。【０２１２】  いずれの承認者も承認を行っていない書類については、取り戻しを行う事が可能である。取り戻しとは、未承認の書類の提出を取り消し、書類の作成中の状態に戻す事である。取り戻し可能な書類かどうかは、書類を検索する装置５０７から、作成者要素の子孫のユーザ要素のｕｓｅｒｉｄ属性が自身のｕｓｅｒｉｄに一致し、全ての承認予定者要素が承認者要素を持たない書類を検索することで求める。条件に該当した場合は、取り戻しボタンを押下可能にする。
【実施例３０】
【０２１３】  実施例１を元に、利用者が承認可能な書類を表示する方法を示す。（図３１）【０２１４】  利用者が承認可能な書類を選択できるようにするために、承認待ち画面を用意する。承認待ち画面は、書類を検索する装置５０７から、承認ポリシーが強制決裁可能かつ代行承認不可であり、認者要素を持たない承認予定者要素の子孫のユーザ要素に自身のｕｓｅｒＩＤが存在する書類および、承認ポリシーが強制決裁不可かつ代行承認可能であり、承認者要素を持たない承認予定者要素の組織名が自身の所属する組織名が存在する書類および、承認ポリシーが強制決裁可能かつ代行承認不可であり、承認者要素を持たない承認予定者要素の子孫のユーザ要素に自身のｕｓｅｒＩＤが存在し、当該承認予定者要素のひとつ下位に、承認者要素を持つ承認予定者要素があるか、作成者要素を持つ作成予定者要素がある書類および、承認ポリシーが強制決裁不可かつ代行承認可能であり、承認者要素を持たない承認予定者要素の組織名が自身の所属する組織名が存在し、当該承認予定者要素のひとつ下位に、承認者要素を持つ承認予定者要素があるか、作成者要素を持つ作成予定者要素がある書類を検索し、条件に該当する書類の一覧を取得し、書類のＩＤおよび様式名、提出日を表形式で表示する。【０２１５】  画面右上の検索ボックスに、様式ＩＤや様式名をキーワードとして入力する事で、表示されている書類の一覧を絞り込む事が可能である。【０２１６】  一覧表の各タイトル項目（様式名や提出日）をクリックすることで表示内容をソートすることが可能である。【０２１７】  表示件数が一定数を超えた場合は、次ページボタンが押下可能になり、次ページボタンを押下すると、次ページの書類一覧が表示される。同様に前のページに戻る場合は、前ページボタンを押下すると、前のページの書類一覧が表示される。【０２１８】  選択した書類の表示ボタンを押下することで、当該書類の参照画面が表示される。【０２１９】  選択した書類の承認ボタンを押下することで、当該書類の承認画面が表示される。【０２２０】  一括で承認を行いたい場合は、一覧表左のチェックボックスにて書類を選択し、一括承認ボタンをクリックすることで、選択した書類を全て承認することが出来る。【０２２１】  また、同様の画面構成で、検索条件を変更することで、別の承認画面とすることが出来る。例えば、実施例５に相当する自身が承認しなければならない書類を特定する画面とする場合は、検索式を承認ポリシーが代行承認不可であり、承認者要素を持たない承認予定者要素の子孫のユーザ要素に自身のｕｓｅｒＩＤが存在し、当該承認予定者要素のひとつ下位に、承認者要素を持つ承認予定者要素があるか、作成者要素を持つ作成予定者要素がある書類および、承認ポリシーが代行承認可能であり、承認者要素を持たない承認予定者要素の組織名が自身の所属する組織名が存在し、当該承認予定者要素のひとつ下位に、承認者要素を持つ承認予定者要素があるか、作成者要素を持つ作成予定者要素がある書類とすればよい。【０２２２】  このような検索式を事前に定義し、セレクトボックスで選択するような、検索ボックスを設け、一覧表へ表示する書類の種類を変更できるような画面構成にする事も考えられ���。
セレクトボックスの選択項目としては次のような項目が考えられる。
・未承認の物全て（この実施例）
・自身が承認すべき書類（実施例５）
・全て
・承認済み
・決裁済み
・代行可能【０２２３】  なお、前記の実施例のうち、いくつか、または全てを組み合わせてシステムを構成することは可能である。また、ｗｅｂシステムにおける実施例が主に記載されているが、ブラウザとサーブレットの構成に変えてｊａｖａによるアプレット、Ｃ言語等によるネイティブアプリケーションにて実施することも可能である。更に通信プロトコルとしてＨＴＴＰのみならず様々なプロトコルを適用することも可能である。【０２２４】  さらに、稟議の一形態として、多人数で行うアンケートにもこれを用いることができる。
【図面の簡単な説明】
【０２２５】
【図１】組織図と様式と稟議書の関係を示したブロック図である。
【図２】組織図のツリー構造を示したブロック図である。
【図３】組織図のツリー構造をＸＭＬで表現した例である。
【図４】様式記述言語の記述例である。
【図５】本発明を実現するために必要な構成要素のブロック図である。
【図６】入力画面ＨＴＭＬに変換された文書構造の例である。
【図７】入力画面ＨＴＭＬに変換された組織図の例である。
【図８】書類を表すＸＭＬに変換された文書構造の例である。
【図９】書類を表すＸＭＬに記述された承認経路の例である。
【図１０】様式に承認経路の設定が無い場合の承認経路の例である。
【図１１】様式に権限の委譲が設定されている場合の承認経路の例である。
【図１２】様式に経路の追加が設定されている場合の承認経路の例である。
【図１３】書類に対して承認を行った例である。
【図１４】書類に対して差戻しを行った例である。
【図１５】実施例１を拡張し、型の見た目を変更できるようにした場合の入力画面ＨＴＭＬの例である。
【図１６】認可を実現するために必要な構成要素のブロック図である。
【図１７】認可のポリシーを設定可能に拡張したときの、組織図を表すＸＭＬの記述例である。
【図１８】条件によって書類の構成要素を変更する場合の記述例である。
【図１９】条件によって承認経路を変更する場合の記述例である。
【図２０】組織図の記述言語を専用言語とし、様式中に記述した場合の記述例である。
【図２１】型および文書構造の記述例である。
【図２２】アノテーションの記述例である。
【図２３】承認経路設定の記述例である。
【図２４】並行した承認経路の追加例である。
【図２５】並行した承認経路があった場合の、入力画面ＨＴＭＬに変換された承認経路の例である。
【図２６】並行した承認経路があった場合の、書類ＸＭＬに変換された承認経路の例である。
【図２７】様式選択画面の例である。
【図２８】書類の入力画面の例である。
【図２９】一時保存選択画面の例である。
【図３０】利用者が作成した書類のうち未決済書類の選択画面の例である。
【図３１】承認可能な書類の選択画面の例である。
【符号の説明】
【０２２６】        ５０１  入力画面であるＨＴＭＬ及びチェックロジックであるサーブレットを生成する装置
５０２  組織図、様式を保存するサーバ
５０３  生成されたＨＴＭＬを配信するＷｅｂサーバ
５０４  サーブレットを実行し結果を返すアプリケーションサーバ
５０５  ＨＴＭＬを表示するＷｅｂブラウザ
５０６  書類を保存する装置
５０７  書類を検索する装置
５０８  認証を行う装置
５０９  認可を行う装置
５１０  書類を参照する装置
５１１  組織図を参照する装置
５１２  承認をする装置
５１３  承認経路を変更する装置
５１４  書類のインデックスを作成する装置
５１５  書類のインデックスを検索する装置
５１６  外部データベース
５１７  書類を一時保存する装置
２０１  入力フォームの内容を変更した際に呼ばれるロジック
２０２  書類を提出するときに呼ばれるロジック
２０３  権限の委譲を設定するロジック
【図１】
0005499388.tif 000002
【図２】
0005499388.tif 000003
【図３】
0005499388.tif 000004
【図４】
0005499388.tif 000005
【図５】
0005499388.tif 000006
【図６】
0005499388.tif 000007
【図７】
0005499388.tif 000008
【図８】
0005499388.tif 000009
【図９】
0005499388.tif 000010
【図１０】
0005499388.tif 000011
【図１１】
0005499388.tif 000012
【図１２】
0005499388.tif 000013
【図１３】
0005499388.tif 000014
【図１４】
0005499388.tif 000015
【図１５】
0005499388.tif 000016
【図１６】
0005499388.tif 000017
【図１７】
0005499388.tif 000018
【図１８】
0005499388.tif 000019
【図１９】
0005499388.tif 000020
【図２０】
0005499388.tif 000021
【図２１】
0005499388.tif 000022
【図２２】
0005499388.tif 000023
【図２３】
0005499388.tif 000024
【図２４】
0005499388.tif 000025
【図２５】
0005499388.tif 000026
【図２６】
0005499388.tif 000027
【図２７】
0005499388.tif 000028
【図２８】
0005499388.tif 000029
【図２９】
0005499388.tif 000030
【図３０】
0005499388.tif 000031
【図３１】
0005499388.tif 000032