JP2016014915A - 文書生成システムおよびその制御方法、並びにプログラム - Google Patents

Abstract

【課題】文書を生成する際、データが無いページに対しても出力され、その結果、不要なページが出力されることによる課金等の問題があった。クラウドサービス等ではこの問題を解消するために、個別に目的に合わせた制御用プログラムなどの作成が必要であった。
【解決手段】文書生成システムであって、クライアントからの要求に応じて文書データを生成する生成手段と、前記生成手段が文書データを作成する際に用いる、ページごとのフォームの情報と、ページに埋め込まれるデータとを管理する管理手段とを備え、前記生成手段は、前記文書データを構成するページのうち、ページに対応するフォームに前記管理手段にて管理するデータを埋め込む領域であるフィールド図形が含まれ、かつ、当該フィールド図形に埋め込むためのデータが前記管理手段にて管理されていないページは出力しない。
【選択図】 図１４

Description

本発明は、文書生成システムおよびその制御方法、並びにプログラムに関し、特に、イントラネットのデータベースやクラウド上に保存されたデータをフォームオーバレイして文書を作成するシステムに関する。

近年、サーバ側で業務データの管理や各種処理を行う形態として、クラウドコンピューティングシステムが普及し始めている。ユーザは、クライアント側のブラウザからインターネットを介してクラウドサーバのＷｅｂページにアクセスし、そのＷｅｂページ上で閲覧したい業務データを表示させる。その画面から文書作成指示を行うと、文書生成サーバにリダイレクトされ、文書生成サーバから返される画面にてフォームオーバレイに使用するフォームをユーザが選択する。そして、文書生成サーバがクラウドサーバ上にあるデータを取得して文書を生成し、文書がブラウザへダウンロードされる。クラウドサーバの代表例として、例えば、Ｓａｌｅｓｆｏｒｃｅ．ｃｏｍ社のＳａｌｅｓｆｏｒｃｅ ＣＲＭ（登録商標）がある。

文書生成サーバでは、クラウドサーバ上にあるデータを使用して様々な文書が生成される。例えば、業務帳票のような形式の場合、複数のテンプレート（例えば請求のサマリと請求明細）を組み合わせてひとつの文書とする場合が多い。このような形式において、クラウドサーバ上に該当のデータ（例えば請求明細）がない（取得データがゼロ件）場合には、表等の枠線のみが表示された空のページが生成されてしまうという問題がある。従来、取得データがゼロ件になる場合に、ユーザ指定の条件により各ページ内の特定項目の表示を制御することはできる（特許文献１参照）。しかし、ページそのものの制御は行えず、複数のテンプレートを使用した文書を生成する際には、枠線のみの「空の」明細ページを出さざるを得なかった。これは、データがゼロ件である場合でも、出力する必要のあるページが存在するため、これらを考慮して出力している。例えば、約款のような固定データのみでバリアブルデータが存在しないテンプレートが該当する。

特開平９−１６６９５号公報

従来技術では、データが無い場合にページそのものの出力を制御できない。クラウド環境の場合、ページ単位で課金しているケースが多い。このため、ユーザとしては本来出力したくない枠線のみの意味のないページが出力され課金されてしまうという問題がある。

また、イントラネットにおける文書生成システムにおいては、従来、上記の問題に対して、文書生成システムを呼び出す上位システムにて、入力データを加工することで対応していた。入力データの加工を行うためには、ユーザ自らが上位システムにて独自のプログラムを組み必要がある。そして、そのプログラムで、各文書・テンプレートおよびそこに指定するデータを管理し、文書毎に入力データの加工方法を切り替える必要があったため非常に手間がかかっていた。

上記課題を解決するために本願発明は以下の構成を有する。すなわち、文書生成システムであって、クライアントからの要求に応じて文書データを生成する生成手段と、前記生成手段が文書データを作成する際に用いる、ページごとのフォームの情報と、ページに埋め込まれるデータとを管理する管理手段とを備え、前記生成手段は、前記文書データを構成するページのうち、ページに対応するフォームに前記管理手段にて管理するデータを埋め込む領域であるフィールド図形が含まれ、かつ、当該フィールド図形に埋め込むためのデータが前記管理手段にて管理されていないページは出力しないことを特徴とする。

本発明によれば、文書を生成するシステムにおいて、データが取得できない場合でも、ユーザによる入力データの加工を行うことなく、ユーザ所望の出力を得られる。

システム構成を示すブロック図。 ハードウェア構成を示す図。 文書生成システムの全体構成を示す図。 クラウドプラットフォームサービスのソフトウェアの構成例を示す図。 Ｗｅｂサーバのソフトウェアの構成例を示す図。 文書生成サービスのソフトウェアの構成例を示す図。 クラウドプラットフォームサービスの業務画面の例を示す図。 クラウドプラットフォームサービスの業務データのテーブル構造の例を示す図。 クラウドプラットフォームサービスのカスタムボタンの定義情報の例を示す図。 フォーム情報テーブルのテーブル構造の例を示す図。 Ｗｅｂブラウザで表示する画面フローの概略を示す図。 第一の実施形態に係る文書生成システムが行う処理シーケンスを示す図。 第一の実施形態に係るフォームファイルの一例を示す図。 第一の実施形態に係る文書生成サービスの処理を示すフローチャート。 第二の実施形態に係るフォームファイルの一例を示す図。 第二の実施形態に係る設定ダイアログを示す図。 第二の実施形態に係る入力データの一例を示す図。 第二の実施形態に係る文書生成サービスの処理を示すフローチャート。 第三の実施形態に係る文書生成サービスの処理を示すフローチャート。 第四の実施形態に係る帳票出力イメージの一例を示す図。 第四の実施形態に係る文書生成サービスの処理を示すフローチャート。 第四の実施形態に係る入力データの一例を示す図。 第二の実施形態に係る文書生成処理のパターンを示す表。

＜第一の実施形態＞
以下、本発明を実施するための一実施形態について図面を用いて説明する。

［システム構成］
図１は、本発明の実施形態に係るシステム構成の例を示すブロック図である。クライアント端末１０１は、クラウドプラットフォームサービス１０２および文書生成サーバ１０３に対してリクエストを発行する。クラウドプラットフォームサービス１０２は、クライアント端末１０１や文書生成サーバ１０３からのリクエストに応じて、保持するデータの表示・更新等を行う。文書生成サーバ１０３は、クライアント端末１０１からリクエストを受信して文書生成を行う。

各構成要素は、ネットワーク１００により通信可能に接続されている。ネットワーク１００は、例えば、インターネット等のＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等のいずれであってもよい。もしくは、ネットワーク１００は、これらの組み合わせにより実現される、いわゆる通信ネットワークであり、データの送受信が可能であればよい。

また、クライアント端末１０１からクラウドプラットフォームサービス１０２、文書生成サーバ１０３への通信手段、文書生成サーバ１０３からクラウドプラットフォームサービス１０２への通信手段、及び各サーバ間の通信手段が異なっていてもよい。

［ハードウェア構成］
図２は、図１に示す、情報処理装置としてのクライアント端末１０１、クラウドプラットフォームサービス１０２、および文書生成サーバ１０３のハードウェア構成を示す。ＣＰＵ２０１は、内部バスで接続される各デバイスを直接或いは間接的に制御し、本発明を実現するためのプログラムを実行する。ＲＯＭ２０２は、ＢＩＯＳが格納される。ＲＡＭ２０３は、ＣＰＵ２０１のワーク領域として利用されたり、本発明を実現するためのソフトウェアモジュールをロードするための一時記憶として利用されたりする。ＨＤＤ２０４は、間接記憶装置であり、基本ソフトウェアであるＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）やソフトウェアモジュールが記憶される。入力装置２０５は、不図示のキーボードやポインティングデバイスなどである。出力装置２０６は、ディスプレイなどである。Ｉ／Ｆ２０７は、ネットワーク１００に接続するためのインタフェースである。

これらハードウェアでは、起動後、ＣＰＵ２０１によりＢＩＯＳが実行され、ＯＳがＨＤＤ２０４からＲＡＭ２０３に実行可能にロードされる。ＣＰＵ２０１は、ＯＳの動作に従って各種ソフトウェアモジュールをＨＤＤ２０４からＲＡＭ２０３に随時、実行可能にロードする。各種ソフトウェアモジュールは各デバイスの協調によりＣＰＵ２０１によって実行され動作する。また、Ｉ／Ｆ２０７はネットワーク１００に接続され、ＯＳの動作に従ってＣＰＵ２０１により制御され、上述した通信手段による通信を実現する。

［システム連携］
図３は、本実施形態に係る文書生成システムにおける各装置の連携の全体概要を示す図である。

クライアント端末１０１は、ユーザインタフェースアプリケーションとしてＷｅｂブラウザ３０１を備える。クラウドプラットフォームサービス１０２は、サービスを利用するユーザの管理や、業務データ、文書生成サーバ１０３へのリダイレクトを行うための設定を管理する。また、クラウドプラットフォームサービス１０２は、マルチテナントを前提とし、使用する企業・組織毎に前述のユーザ管理、業務データ管理等が行われる。

文書生成サーバ１０３は、Ｗｅｂサーバ３０３、および、文書生成サービス３０４を備える。Ｗｅｂサーバ３０３は、いわゆるＷｅｂアプリケーションの機能を有するよう構成され、クライアント端末１０１はＷｅｂブラウザ３０１を介してアクセスする事が出来る。

Ｗｅｂサーバ３０３は、Ｗｅｂブラウザ３０１からのリクエストに対してユーザインタフェース情報を返答する。Ｗｅｂブラウザ３０１は、Ｗｅｂサーバ３０３から得られたユーザインタフェース情報をレンダリングし、表示する。表示されたユーザインタフェース情報には、例えば、文書生成サーバ１０３が管理するフォームの一覧や、文書生成をリクエストするためのインタフェース等が含まれる。また、Ｗｅｂサーバ３０３は、Ｗｅｂブラウザ３０１から文書生成リクエストを受信すると、クラウドプラットフォームサービス１０２から業務データを取得し、その業務データとともに文書生成サービス３０４に対して文書生成のリクエストを送信する。

文書生成サービス３０４は、受信したデータと、自身で管理するフォームおよびクエリコマンドとを使用してオーバレイ処理を行い、文書データを生成する。クエリコマンドには、クラウドプラットフォームサービス１０２からの業務データ取得方法等が設定されている。

［ソフトウェア構成］
図４は、クラウドプラットフォームサービス１０２上で動作するソフトウェアモジュールの構成例を示す図である。各ソフトウェアモジュールは図２で示したＨＤＤ２０４に記憶されており、前述したようにＣＰＵ２０１によってＲＡＭ２０３にロードされ実行される。

クラウドプラットフォームサービス１０２は、送受信部４０１、制御部４０２、ページ生成部４０３、セッション管理部４０４、認証部４０５、データ管理部４０６、および設定管理部４０７を備える。

送受信部４０１は、クライアント端末１０１のＷｅｂブラウザ３０１や文書生成サーバ１０３のＷｅｂサーバ３０３との通信を処理する。制御部４０２は、送受信部４０１が受け付けたリクエストに従って処理を実行する。ページ生成部４０３は、Ｗｅｂブラウザ３０１にレスポンスを返すためのＷｅｂページを生成する。認証部４０５は、ログイン要求してきたユーザを認証する。セッション管理部４０４は、認証部４０５にて認証に成功したユーザのセッション情報を管理する。データ管理部４０６は、業務データをＤＢ４０８に保持し、要求に応じてＤＢ４０８から業務データの取得、あるいは業務データの更新を行う。設定管理部４０７は、文書生成サーバ１０３へのリダイレクトを行うための設定を保持する。クラウドプラットフォームサービス１０２は、各構成要素の協調により、後述する処理を実行する。

ＤＢ４０８は、管理ユーザデータや業務データを格納するデータベースであり、図２で示したＨＤＤ２０４に記憶される。管理ユーザデータや業務データは、企業・組織（以降、「組織」と表記）毎に管理される。各組織には組織ＩＤが自動的に割り当てられ、組織ＩＤとともに各データが管理される。ユーザ認証時、ユーザが所属する組織の組織ＩＤを取得しセッション管理部４０４に保存する。以降のデータ取得等の処理は組織ＩＤに基づいて行われ、組織ＩＤの一致するデータのみを参照することが可能である。

また、ＤＢ４０８には、文書生成サーバ１０３へのリダイレクトを行うための設定も格納される。ＤＢ４０８に格納された業務データや文書生成サーバ１０３へリダイレクトを行うための設定は、Ｗｅｂブラウザ３０１を介して、ユーザ（管理者）により任意のタイミングで設定更新が行われる。

図５は、文書生成サーバ１０３のＷｅｂサーバ３０３上で動作するソフトウェアモジュールの構成例を示す図である。各ソフトウェアモジュールは図２で示したＨＤＤ２０４に記憶されており、前述したようにＣＰＵ２０１によってＲＡＭ２０３にロードされ実行される。

Ｗｅｂサーバ３０３は、送受信部５０１、制御部５０２、ページ生成部５０３、データアクセス部５０４、フォーム情報管理部５０５、セッション管理部５０６、およびフォーム保存部５０７を有する。

送受信部５０１は、クライアント端末１０１のＷｅｂブラウザ３０１やクラウドプラットフォームサービス１０２、文書生成サービス３０４との通信を処理する。制御部５０２は、受け付けたリクエストに従って処理を実行する。ページ生成部５０３は、Ｗｅｂブラウザ３０１にレスポンスを返すためのＷｅｂページを生成する。データアクセス部５０４は、クラウドプラットフォームサービス１０２にアクセスして業務データを取得する。フォーム情報管理部５０５は、フォーム情報テーブルを管理する。セッション管理部５０６は、Ｗｅｂブラウザ３０１のセッション情報を管理する。フォーム保存部５０７は、フォームファイルの作成および保存を行う。Ｗｅｂサーバ３０３は、これら各構成要素の協調により、後述する処理を実行する。

図６は、文書生成サーバ１０３の文書生成サービス３０４上で動作するソフトウェアモジュールの構成例を示す図である。各ソフトウェアモジュールは図２で示したＨＤＤ２０４に記憶されており、前述したようにＣＰＵ２０１によってＲＡＭ２０３にロードされ実行される。

文書生成サービス３０４は、要求受信部６０１、制御部６０２、フォーム管理部６０３、文書生成部６０４、文書送信部６０５を有する。要求受信部６０１は、Ｗｅｂサーバ３０３からの文書生成リクエストを受け付ける。制御部６０２は、受け付けたリクエストに従って処理を実行する。フォーム管理部６０３は、フォームデータを管理する。文書生成部６０４は、Ｗｅｂサーバ３０３から送信された業務データとフォームを使用してオーバレイ処理を行い、文書データを生成する。文書送信部６０５は、生成された文書データをＷｅｂサーバ３０３またはクライアント端末１０１に送信する。

［データ構成例］
図７は、クライアント端末１０１のＷｅｂブラウザ３０１から、クラウドプラットフォームサービス１０２にアクセスして業務データを表示した場合の業務画面７０１の例である。なお、図７は、ユーザがクラウドプラットフォームサービス１０２にログイン済の状態である。業務画面７０１は、あるレコードの詳細情報７０２や商品７０３が表示されている。図７では、商談に関する業務画面の商談レコードの詳細を表示している。また、文書生成サーバ１０３へリダイレクトを行うための設定がなされたカスタムボタン７０４が表示される。カスタムボタン７０４は、ボタン押下時の動作や、どの画面に表示するか、等を任意に設定可能であり、ユーザ（管理者）によって画面に配置される。

図８は、クラウドプラットフォームサービス１０２のデータ管理部４０６が保持する業務データのうち、商談に関するデータのテーブル構造例を示す図である。業務データはデータテーブル８００で管理され、商談テーブル８０１および商品テーブル８１１によって構成される。

商談テーブル８０１は、レコードの識別子であるレコードＩＤ８０２、レコードをユーザが容易に区別するために任意の名前を設定可能な商談名８０３を含む。なお、商談テーブル８０１の構成はこれに限定するものではなく、他の項目を含んで構成されても良い。

商品テーブル８１１は、商談レコードＩＤ８１２、商品テーブルのレコードの識別子であるレコードＩＤ８１３、品名８１４、数量８１５、価格８１６を含む。また、商談レコードＩＤ８１２は、商談テーブルのレコードＩＤ８０２とリレーションしている。なお、商品テーブル８１１の構成はこれに限定するものではなく、他の項目を含んで構成されても良い。

図９は、クラウドプラットフォームサービス１０２の設定管理部４０７で保持するカスタムボタンの定義情報の例を示す図である。図９では、カスタムボタンが「商談」画面と「顧客」画面に定義されており、「商談」画面に表示するカスタムボタンの設定情報には、ボタン表示名９０３、および、文書生成サーバ１０３へリダイレクトを行うためのパラメータ情報が格納されている。文書生成サーバＵＲＩ９０４は、文書生成サーバ１０３のＵＲＩを「ｈｔｔｐ：／／〜」の形式で指定したパラメータである。セッションＩＤ９０５は、ログインしたユーザのセッションＩＤを取得して文字列「ｓｉｄ＝＜セッションＩＤ＞」をＵＲＬパラメータに付加する設定である。このパラメータにおいて、＜＞で挟まれる位置に、具体的な値が設定される。ＣＰＳＵＲＬ９０６は、文書生成サーバ１０３がクラウドプラットフォームサービス１０２にアクセスするためのＵＲＬを文字列「ｓｒｖ＿ｕｒｌ＝＜クラウドプラットフォームサービスＵＲＬ＞」としてＵＲＬパラメータに付加する設定である。

クラウドプラットフォームサービス１０２にアクセスするためのＵＲＬは組織毎に固有であり、ユーザ認証時に、制御部５０２が、ユーザが所属する組織に応じたＵＲＬを取得してセッション管理部４０４に保存する。組織ＩＤ９０７は、ログインしたユーザの組織ＩＤを取得して文字列「ｏｒｇｉｄ＝＜組織ＩＤ＞」をＵＲＬパラメータに付加する設定である。レコードＩＤ９０８は、画面に表示した商談レコードのレコードＩＤ１２０２を取得して文字列「ｒｅｃｉｄ＝＜レコードＩＤ＞」をＵＲＬパラメータに付加する設定である。なお、カスタムボタンテーブル９０１には更なるカスタムボタンが定義されてよく、また、設定パラメータの項目も追加されてよい。

図１０は、Ｗｅｂサーバ３０３のフォーム情報管理部５０５が保持するフォーム情報テーブルのテーブル構造の例を示す図である。フォーム情報テーブル１００１のフォーム情報レコードは、組織ＩＤ１００３、表示名１００４、フォームファイル名１００５、クエリコマンド１００６、フォーム情報１０７を含む。組織ＩＤ１００３は、レコードの所有者である組織を識別するための識別子である。表示名１００４は、フォーム選択画面に表示する名称である。フォームファイル名１００５は、文書生成サービス３０４のフォーム管理部６０３で管理されているフォームのファイル名である。クエリコマンド１００６は、クラウドプラットフォームサービス１０２からデータを取得するためのクエリが記述されている。フォーム情報１０７は、フォームファイル内に定義されている固定的なデータに関する情報である。レコードの項目はこれに限定するものではなく、さらに追加してもよい。

図１１は、図１の文書生成システムにおけるクライアント端末１０１のＷｅｂブラウザ３０１で表示する画面のフローの例を示す図である。なお、以降の図では、クラウドプラットフォームサービスを「ＣＰＳ」と略して表記する。

業務画面１１０１は、クラウドプラットフォームサービス１０２が作成し、クライアント端末１０１に返す画面であり、例えば、図７の業務画面７０１が表示される。文書生成ボタン１１０２は、クラウドプラットフォームサービス１０２へ文書生成リクエストを発行するためのボタンである。クラウドプラットフォームサービス１０２は文書生成ボタン１１０２が押下されると、文書生成サーバ１０３へリダイレクトするＵＲＬを返却する。

クライアント端末１０１のＷｅｂブラウザ３０１は、リダイレクトするＵＲＬを受け付けると、このＵＲＬに従って文書生成サーバ１０３へリダイレクトする。リダイレクトでリクエストを受けた文書生成サーバ１０３は、フォーム選択画面１１０３をクライアント端末１０１のＷｅｂブラウザ３０１に返す。フォーム選択画面１１０３は、文書生成に使用するフォームを選択するフォーム選択１１０４を備える。

また、クライアント端末１０１のＷｅｂブラウザ３０１は、ユーザから文書作成ボタン１１０５の選択を受け付けると、フォーム選択１１０４の選択結果を文書生成サーバ１０３に送信する。文書生成サーバ１０３は、クライアント端末１０１から選択結果の情報を受け付けると、業務画面１１０１の業務データをクラウドプラットフォームサービス１０２から取得する。データ取得中画面１１０６は、文書生成サーバ１０３がクラウドプラットフォームサービス１０２から業務データを取得中の間、クライアント端末１０１のＷｅｂブラウザ３０１に表示される。文書生成サーバ１０３がクラウドプラットフォームサービス１０２からの業務データ取得が完了すると、文書生成サーバ１０３は、取得したデータを確認可能なデータ確認画面１１０７をクライアント端末１０１のＷｅｂブラウザ３０１に返す。

クライアント端末１０１のＷｅｂブラウザ３０１は、ユーザから作成ボタン１１０８の選択を受け付けると、文書生成サーバ１０３に文書生成リクエストを送信する。文書生成サーバ１０３は、クライアント端末１０１から文書生成リクエストを受けると、選択されたフォームとクラウドプラットフォームサービス１０２から取得した業務データを使用して文書生成処理を行う。文書生成処理の間、クライアント端末１０１のＷｅｂブラウザ３０１は、作成中画面１１０９を表示する。クライアント端末１０１のＷｅｂブラウザ３０１は、文書の作成が完了すると、完了画面１１１０を表示する。

［処理シーケンス］
図１２は、本実施形態に係る文書生成システムが行う処理の流れを示している。なお、ユーザはログイン画面（不図示）にてクラウドプラットフォームサービス１０２にログイン済とし、Ｗｅｂブラウザ３０１には図７の業務画面７０１が表示されており、カスタムボタン７０４は、予め図９の設定がなされているものとする。本処理は、各処理主体のＣＰＵが、ＲＯＭ等の記憶部に記憶されたプログラムを読み出して実行することにより、実現されるものとする。また、処理フローに伴う画面遷移は、図１１の流れに対応する。

ユーザによりクライアント端末１０１のＷｅｂブラウザ３０１に表示された業務画面７０１のカスタムボタン７０４が押下されると、Ｓ１２０１にて、その旨がＷｅｂブラウザ３０１からクラウドプラットフォームサービス１０２へ通知される。Ｓ１２０２にて、クラウドプラットフォームサービス１０２は、リダイレクトＵＲＬ作成処理を行う。ここで、制御部４０２は、カスタムボタンに設定された文書生成サーバＵＲＩ９０４、セッションＩＤ９０５、ＣＰＳＵＲＬ９０６、組織ＩＤ９０７、およびレコードＩＤ９０８を取得し、これら取得したパラメータからリダイレクトＵＲＬを生成する。そして、クラウドプラットフォームサービス１０２は、リダイレクトさせるためのレスポンスをＷｅｂブラウザ３０１に返す。

Ｓ１２０３にて、Ｗｅｂブラウザ３０１は、クラウドプラットフォームサービス１０２から返されたレスポンスを受信すると、セッションＩＤ９０５、ＣＰＳＵＲＬ９０６、組織ＩＤ９０７、レコードＩＤ９０８を文書生成サーバ１０３に送信する。Ｓ１２０４にて、Ｗｅｂサーバ３０３は、Ｗｅｂブラウザ３０１からのリダイレクトを受信すると、まず制御部５０２は、セッションＩＤ９０５、ＣＰＳＵＲＬ９０６、組織ＩＤ９０７、およびレコードＩＤ９０８をセッション管理部５０６に保存する。次に、制御部５０２は、フォーム情報レコード１００２に含まれるフォームの表示名１００４のリストをフォーム情報管理部５０５から取得し、フォームの表示名１００４のリストからフォーム選択画面１１０３を作成し、クライアント端末１０１に送る。

Ｓ１２０５にて、Ｗｅｂブラウザ３０１は、ユーザによりフォーム選択画面１１０３のフォーム選択１１０４が選択され、文書作成ボタン１１０５が押下されると、Ｗｅｂサーバ３０３に対してフォーム選択１１０４とともに文書生成リクエストを送信する。

Ｓ１２０６にて、Ｗｅｂサーバ３０３は、文書生成リクエストを受信すると、フォーム選択１１０４で指定されたフォームに一致するクエリコマンド１００６を発行し、クラウドプラットフォームサービス１０２にデータ取得リクエストを行う。その際、クラウドプラットフォームサービス１０２のＵＲＬおよび取得データの内容は、セッション管理部５０６に保存されているＣＰＳＵＲＬ９０６および組織ＩＤ９０７、レコードＩＤ９０８をそれぞれ使用する。次に、Ｓ１２０７にて、文書生成サーバ１０３は、データ取得中画面１１０６を作成し、Ｗｅｂブラウザ３０１に送る。

Ｓ１２０８にて、Ｗｅｂブラウザ３０１は、定期的にデータ取得完了の確認リクエストを文書生成サーバ１０３に送信する。文書生成サーバ１０３のＷｅｂサーバ３０３は、クラウドプラットフォームサービス１０２からデータ取得のレスポンスが返るまでは、Ｓ１２０７と同様のデータ取得中画面１１０６をＷｅｂブラウザ３０１に送る。次に、クラウドプラットフォームサービス１０２は、データ取得のレスポンスを文書生成サーバ１０３に返す。Ｗｅｂサーバ３０３の制御部５０２は、取得データをセッション管理部５０６へ保存する。その後、Ｗｅｂブラウザ３０１からデータ取得完了の確認リクエストが送られてくると、Ｓ１２０９にて、Ｗｅｂサーバ３０３は、クラウドプラットフォームサービス１０２から取得したデータを用いてデータ確認画面１１０７を生成し、Ｗｅｂブラウザ３０１へ返す。

Ｓ１２１０にて、Ｗｅｂブラウザ３０１は、Ｗｅｂサーバ３０３０から返されたデータ確認画面１１０７上にて、ユーザにより作成ボタン１１０８が押下されると、Ｗｅｂサーバ３０３に対して、文書生成リクエストが送信される。

Ｗｅｂサーバ３０３は、文書生成リクエストを受信すると、Ｓ１２１１にて、その旨を文書生成サーバ１０３に通知する。そして、Ｓ１２１２にて、文書生成サーバ１０３は、図１４を用いて後述する文書生成処理を行う。

図１３は、本発明におけるフォームファイルの一例を示す図である。図１３に示すフォームファイル１３０１には、クラウドプラットフォームサービス１０２から取得したデータ（以降、入力データ）をセットする（埋め込む）フィールド図形１３０２や、入力データとは無関係の固定的な図形であるフォーム図形１３０３が定義される。フィールド図形１３０２は、入力データを指定の形式で書式化して出す機能を備える。セットされた入力データを何桁まで出力するかの設定や、フォントサイズや文字色、太字や下線等見た目の制御をどのように行うかなどの設定を定義する。フォーム図形１３０３は、文書上の固定的な情報である。表のラベル文字列、企業ロゴなどの画像ファイルといったものをフォーム図形として定義する。

フォームファイル１３０１には、図１３（ａ）に示すようにフィールド図形１３０２とフォーム図形１３０３がともに定義されているものと、図１３（ｂ）に示すようにフォーム図形のみ定義されているものが存在する。図１３（ｂ）のようなフォームファイルの例としては、約款などが挙げられる。保険帳票の約款は、可変の入力データがセットされる保険帳票とひとまとまり（１つの文書）にする必要があるが、約款自体のページには可変データがないためフォーム図形のみのフォームファイルとなる。

図１４は、本発明における文書生成サービス３０４の文書生成処理を示すフローチャートである。本処理フローは、文書生成サーバ１０３のＣＰＵが、ＨＤＤ等の記憶部に記憶されたプログラムを読み出して実行することにより、実現される。

Ｓ１４０１にて、文書生成部６０４は、フォーム管理部６０３から図１３に示すようなフォームファイルを読み込み、そのフォームファイルの解析を行う。解析を行うことで、文書生成部６０４は、該当のフォームファイル内に定義されたフィールド図形１３０２およびフォーム図形１３０３の情報を保持する。Ｓ１４０２にて、文書生成部６０４は、図１２のＳ１２０６にてクエリコマンド１００６を発行してクラウドプラットフォームサービス１０２から取得した入力データの解析を行う。

Ｓ１４０３にて、文書生成部６０４は、帳票のレイアウト処理を行う。文書生成部６０４は、実際のページ出力処理（たとえば、ＰＤＦファイル生成処理）を行う前に、解析したフォームファイル及び入力データの情報を使用して、各ページのレイアウトを決定する。レイアウト処理では、入力データが、各ページに何レコードまで入るか、各入力データの出力位置などを決定する。Ｓ１４０４〜Ｓ１４１４はページごとの処理のループを示す。

Ｓ１４０５にて、文書生成部６０４は、ページ出力フラグを「ＯＦＦ」で初期化する。ページ出力フラグはページ毎の出力制御を行うためのフラグであり、文書生成部６０４により管理される。Ｓ１４０６にて、文書生成部６０４は、対象のフォームファイル１３０１に、フィールド図形１３０２が１つ以上存在するか否かを判定する。判定にはＳ１４０１での解析結果が使用される。フィールド図形１３０２が１つも存在しないと判定された場合には（Ｓ１４０６にてＮＯ）、Ｓ１４１２の処理に移る。すなわち、入力データを埋め込む領域がないページが該当する。一方、フィールド図形１３０２が１つ以上存在すると判定された場合（Ｓ１４０６にてＹＥＳ）、Ｓ１４０７〜Ｓ１４１０において、文書生成部６０４は、フィールド図形ごとの処理を行う。

Ｓ１４０８にて、文書生成部６０４は、Ｓ１４０３のレイアウト処理にてフィールド図形１３０２に入力データがセットされたか否かを判定する。入力データが空（取得できない）場合には、該当のフィールド図形にデータがセットされない。このため、フィールド図形毎にデータがセットされたか否かの確認を行う。フィールド図形１３０２に入力データがセットされたと判定された場合（Ｓ１４０８にてＹＥＳ）、Ｓ１４０９にて、文書生成部６０４は、ページ出力フラグを「ＯＮ」にする。フィールド図形１３０２に入力データがセットされていないと判定された場合（Ｓ１４０８にてＮＯ）、もしくは、Ｓ１４０９の処理の後、Ｓ１４１０の処理に移る。

Ｓ１４０７〜Ｓ１４１０の処理によって、フォームファイル１３０１に定義されたすべてのフィールド図形１３０２に対して入力データがセットされたか否かの確認が行われる。この結果、すべてのフィールド図形のデータがセットされていない場合のみ、ページ出力フラグが「ＯＦＦ」となる。

Ｓ１４１１にて、文書生成部６０４は、ページ出力フラグが「ＯＮ」か否かを判定する。ページ出力フラグが「ＯＮ」と判定された場合には（Ｓ１４１１にてＹＥＳ）、Ｓ１４１２にて、文書生成部６０４は、該当ページを出力する。一方、ページ出力フラグが「ＯＦＦ」と判定された場合には（Ｓ１４１１にてＮＯ）、Ｓ１４１３にて文書生成部６０４は、該当ページの出力をスキップして、そのページの出力を行わない。

Ｓ１４１４まで処理すると、Ｓ１４０４に戻り、ページごとの処理を続行する。全てのページに対して処理を行ったら本処理フローを終了する。

以上、フォームファイル１３０１にフォーム図形１３０３のみが定義されていた場合には入力データに関係なくページ出力を行い、それ以外の場合には入力データがフィールド図形１３０２にセットされたか否かによりページ出力の判定を行う。これにより、入力データが存在しない場合でもユーザの所望の帳票を得ることが可能になる。なお、本実施形態はクラウド環境での文書生成であるが、イントラネットにおける文書生成システムにおいても、文書生成部自体の構成については同様であり、同様の効果を得ることが出来る。

＜第二の実施形態＞
本実施形態では、入力データが切り替わった際に出力される、ブレイクヘッダもしくはブレイクフッタと呼ばれるレイヤーがフォームファイルのテンプレートに設定されていた場合の実施形態について述べる。ブレイクヘッダレイヤー（もしくはブレイクフッタレイヤー）は、例えば１１月の明細から１２月の明細のデータに切り替わった際に表示される。このレイヤー定義がなされたテンプレートへの入力データが取得できない場合の動作について処理の詳細を説明する。なお、入力データが切り替わる場合とは、月単位のデータに限定するものではなく、他の処理単位でデータが切り替わる時点であってもよい。

図１５は、ブレイクヘッダレイヤーが定義されたテンプレートの一例である。フォームファイル１３０１には、ブレイクヘッダレイヤー１５０１および明細レイヤー１５０２が定義されている。ブレイクヘッダレイヤー１５０１は、入力データが切り替わったタイミングで出力されるレイヤーである。その際には、ブレイクヘッダレイヤー１５０１上に定義されているフィールド図形１５０３やその他のフォーム図形が表示される。つまり、ブレイクヘッダレイヤー１５０１もフォーム図形を含み、明細レイヤー１５０２と異なる層として表示される。

明細レイヤー１５０２は、入力データの切り替わりに関係なく常に表示されるレイヤーである。表示される際には、明細レイヤー１５０２上に存在するフィールド図形１５０４やその他のフォーム図形が表示される。ブレイクヘッダレイヤー１５０１の作成およびレイヤー上へのフィールド図形の配置操作は、テンプレートエディタ（不図示）で行う。また、フィールド図形１３０２やフォーム図形１３０３は、ブレイクヘッダレイヤー１５０１や明細レイヤー１５０２ごとに管理されテンプレートの一部として保存される。ブレイクヘッダレイヤー１５０１と明細レイヤー１５０２は、同時に（同じページとして）表示することも可能であり、別のページとして表示することも可能である。また、同じページに表示される際には、重畳して表示されてもよいし、重畳されなくてもよい。また、明細レイヤー、ブレイクヘッダレイヤー、およびブレイクヘッダレイヤーがすべて同じページ表示されてもよい。また、本実施形態は複数のレイヤーとして３つを例に挙げているが、これに限定するものではなく、他の種類のレイヤーを含んでもよい。

図１６は、各レイヤーを同時に表示するか否かを設定するユーザインタフェースの一例である。設定ダイアログ１６０１のチェックボックス１６０２をチェックすることによって、ブレイクヘッダレイヤー１５０１が明細レイヤー１５０２と別のページとして出力される。設定ダイアログ１６０１は、テンプレートエディタ（不図示）のメニューから呼び出されるものとする。設定ダイアログ１６０１で設定した内容は、フォームファイル１３０１の一部としてハードディスク等の記憶部に保存される。図１５（ａ）は、ブレイクヘッダレイヤー１５０１と明細レイヤー１５０２を同時に表示することを想定したテンプレートデザインになっている。一方、図１５（ｂ）は、各レイヤーを別ページとして出力することを想定したテンプレートデザインである。

図１７は、本実施形態で想定する入力データの一例である。ここでは、ＣＳＶ（Ｃｏｍｍａ Ｓｅｐａｒａｔｅｄ Ｖａｌｕｅｓ）の形式で示しているが、これに限定するものではない。入力データ１７０１の１行目は、各データがどのフィールド図形に対応するか（埋め込まれるか）を示す識別情報である（以下、見出し行１７０２と称す）。２行目以降、実データ１７０３が続いている。１つの実データ（１つの行）において、レコード１からレコード３までの３つのフィールド図形に対応するデータが示されている。ここでは、レコード１に対応する実データが存在していない（空である）例を示している。

［処理フロー］
図１８は、本実施形態に係る文書生成サービス３０４の文書生成処理を示すフローチャートである。図１４と異なる部分のみ説明し、重複する部分は第一の実施形態と同様である。本処理フローは、文書生成サーバ１０３のＣＰＵが、ＨＤＤ等の記憶部に記憶されたプログラムを読み出して実行することにより、実現される。

Ｓ１４０１にて、文書生成部６０４は、フォーム管理部６０３からフォームファイル１３０１を読み込み、そのフォームファイル１３０１の解析を行う。文書生成部６０４は、解析を行うことで、フォームファイル１３０１内に定義されたフィールド図形１３０２およびフォーム図形１３０３の情報を保持する。この際、文書生成部６０４は、フィールド図形１３０２およびフォーム図形１３０３の情報をブレイクヘッダレイヤー１５０１および明細レイヤー１５０２毎に保持する。また、文書生成部６０４は、フォームファイル１３０１に含まれる、各レイヤーを同一ページに出力するか否かのフラグ情報も取得する。

Ｓ１４０３にて、文書生成部６０４は、帳票のレイアウト処理を行う。第一の実施形態で述べた処理に加え、文書生成部６０４は、各ページのレイアウト処理中に、そのページで出力されるレイヤーが何かを判別し、その情報を保持する。例えば、入力データが切り替わった際にブレイクヘッダレイヤー１５０１が出力される場合、そのページのページ番号とともにブレイクヘッダレイヤーが出力される旨を情報として保持する。文書生成部６０４は、これをレイアウトするすべてのページに対して行う。この結果、文書生成部６０４では、レイアウト完了後、各ページでどのレイヤーが出力されるかの判別が可能となる。

Ｓ１８０１にて、文書生成部６０４は、処理中のフォームファイルが、ブレイクヘッダレイヤー１５０１と明細レイヤー１５０２を同一ページに出力する設定になっているか否かを判定する。この判定は、Ｓ１４０１で取得した各レイヤーを同一ページに出力するか否かのフラグ情報を元に行われる。同一ページに出力する設定になっていると判定された場合には（Ｓ１８０１にてＹＥＳ）、Ｓ１８０２に進む。そうでない場合には（Ｓ１８０１にてＮＯ）Ｓ１８０６に進む。

文書生成部６０４は、対象の全フィールド図形に対してＳ１８０２〜Ｓ１８０５の処理を繰り返し行う。対象となるフィールド図形は、ブレイクヘッダレイヤー１５０１および明細レイヤー１５０２の両方に含まれるもの全てである。

Ｓ１８０３にて、文書生成部６０４は、対象のフィールド図形（ブレイクヘッダレイヤー１５０１もしくは明細レイヤー１５０２上のフィールド図形）に入力データが設定されるか否かを判定する。入力データが設定されていないと判定された場合には（Ｓ１８０３にてＮＯ）、Ｓ１８０５に進む。一方、入力データが設定されていると判定された場合には（Ｓ１８０３にてＹＥＳ）、Ｓ１８０４にて、文書生成部６０４は、ページ出力フラグを「ＯＮ」にする。その後、Ｓ１８０５へ進む。以降、フィールド図形毎にＳ１８０２〜Ｓ１８０５の処理を繰り返す。Ｓ１８０２〜Ｓ１８０５の繰り返し処理が終了したら、Ｓ１４１１へ進む。

Ｓ１８０６にて、文書生成部６０４は、処理中のページに明細レイヤー１５０２が出力されるか否かを判定する。明細レイヤー１５０２が出力されると判定された場合には（Ｓ１８０６にてＹＥＳ）、文書生成部６０４は、対象の全フィールド図形に対してＳ１８０７〜Ｓ１８１０の処理を繰り返し行う。対象となるフィールド図形は、明細レイヤー１５０２に含まれるもの全てである。

Ｓ１８０８にて、文書生成部６０４は、対象のフィールド図形に入力データが設定されるか否かを判定する。入力データが設定されていないと判定された場合には（Ｓ１８０８にてＮＯ）、Ｓ１８１０に進む。一方、入力データが設定されていると判定された場合には（Ｓ１８０８にてＹＥＳ）、Ｓ１８０９にて、文書生成部６０４は、ページ出力フラグを「ＯＮ」にする。その後、Ｓ１８１０へ進む。以降、フィールド図形毎にＳ１８０７〜Ｓ１８１０の処理を繰り返す。Ｓ１８０７〜Ｓ１８１０の繰り返し処理が終了したら、Ｓ１４１１へ進む。

一方、明細レイヤー１５０２が出力されないと判定された場合には（Ｓ１８０６にてＮＯ）、文書生成部６０４は、対象の全フィールド図形に対してＳ１８１１〜Ｓ１８１４の処理を繰り返し行う。対象となるフィールド図形は、ブレイクヘッダレイヤー１５０１に含まれるもの全てである。

Ｓ１８１２にて、文書生成部６０４は、対象のフィールド図形に入力データが設定されるか否かを判定する。入力データが設定されていないと判定された場合には（Ｓ１８１２にてＮＯ）、Ｓ１８１４に進む。一方、入力データが設定されていると判定された場合には（Ｓ１８１２にてＹＥＳ）、Ｓ１８１３にて、文書生成部６０４は、ページ出力フラグを「ＯＮ」にする。その後、Ｓ１８１４へ進む。以降、フィールド図形毎にＳ１８１１〜Ｓ１８１４の処理を繰り返す。Ｓ１８１１〜Ｓ１８１４の繰り返し処理が完了したら、Ｓ１４１１へ進む。

なお、ブレイクフッタについても同様の処理を行う。本実施形態により、ブレイクヘッダもしくはブレイクフッタと呼ばれるレイヤーが設定されているフォームファイルの場合でも、入力データが存在しない場合にユーザの所望の帳票を得ることが可能になる。図２３は本実施形態における文書生成処理のパターンをまとめた表である。

＜第三の実施形態＞
本実施形態では、ユーザが明示的にページの出力を制御する場合の実施形態について述べる。フォームファイル１３０１上に、必ず表示したいフォーム図形を定義しており、かつ、オプションとして表示されるフィールド図形も併せて定義している場合がある。例えば、保険の約款では、どの契約でも必ず該当する事項については約款の文字列をフォーム図形で作成し、オプション契約に該当する事項の文字列についてはフィールド図形で作成することが考えられる。オプション契約についての文字列（入力データ）は空になる場合があるため、このケースでは第一、第二の実施形態で示した方法では約款を表示できない。本実施形態では、そのようなケースを鑑み、ユーザが明示的にページまたはフォーム図形にページ出力の制御フラグを設定することでページ出力を制御する実施形態について述べる。

ページ出力を制御するフラグについては２種類を想定する。各ページの出力を直接制御するフラグを「レイヤー常時表示フラグ」と呼ぶ。レイヤー常時表示フラグが「ＯＮ」の場合は、そのレイヤーを含むページは常に表示される。「ＯＦＦ」の場合は上述した実施形態の処理に従う。レイヤー常時表示フラグは、フォームファイルエディタ（不図示）によって、フォームファイル１３０１に設定される。設定対象は、ブレイクヘッダレイヤー１５０１や明細レイヤー１５０２である。レイヤー毎に出力の制御が行える。また、各ページの出力をその存在によって間接的に制御するフラグを「フォーム図形常時表示フラグ」と呼ぶ。このフラグの設定対象は、各フォーム図形である。このフラグが「ＯＮ」の場合、そのフォーム図形が存在するレイヤー（を含むページ）が出力される。フォーム図形常時表示フラグについても、フォームファイルエディタ（不図示）によってフォームファイル１３０１に設定される。

図１９は、本実施形態に係る文書生成サービス３０４の文書生成処理を示すフローチャートである。図１８と異なる部分のみ説明し、重複する部分は第二の実施形態と同様である。本処理フローは、文書生成サーバ１０３のＣＰＵが、ＨＤＤ等の記憶部に記憶されたプログラムを読み出して実行することにより、実現される。

Ｓ１４０１にて、文書生成部６０４は、フォーム管理部６０３からフォームファイル１３０１を読み込み、そのフォームファイル１３０１の解析を行う。第二の実施形態の処理に加え、各レイヤーのレイヤー常時表示フラグと、全フォーム図形のフォーム図形常時表示フラグを取得する。

Ｓ１９０１にて、文書生成部６０４は、Ｓ１４０１で読み込んだ各レイヤーのレイヤー常時表示フラグ情報を元に、該当ページを常時出力すべきか否かを判定する。文書生成部６０４は、該当ページで表示すべき各レイヤーの、レイヤー常時表示フラグを全てチェックし、１つでもＯＮのものがあれば常時出力すべきと判定する。

該当ページを常時出力すべきと判定された場合には（Ｓ１９０１にてＹＥＳ）、Ｓ１４１２に移り、文書生成部６０４は、該当ページの出力を行う。一方、該当ページを常時出力すべきでないと判定された場合には（Ｓ１９０１にてＮＯ）、Ｓ１９０２に移る。

Ｓ１９０２にて、文書生成部６０４は、Ｓ１４０１で読み込んだフォーム図形常時表示フラグ情報を元に、該当ページを常時出力すべきか否かを判定する。文書生成部６０４は、該当ページで表示すべき各レイヤー上に定義されたフォーム図形のフォーム図形常時表示フラグを全てチェックし、１つでも「ＯＮ」のものがあれば常時出力すべきと判定する。

該当ページを常時出力すべきと判定された場合には（Ｓ１９０２にてＹＥＳ）、Ｓ１４１２に移り、文書生成部６０４は、該当ページの出力を行う。一方、該当ページを常時出力すべきでないと判定された場合には（Ｓ１９０２にてＮＯ）、Ｓ１４０５に移り、文書生成部６０４は、上記の実施形態で述べた自動的なページ出力制御処理を継続する。

以上、本実施形態により、入力データが省略される場合にページ出力を自動的に抑制する場合でも、ユーザが明示的にページの出力を制御することが可能になる。

＜第四の実施形態＞
本実施形態では、フォームファイル１３０１上に定義された複数のテーブル（表）への入力データが空となる場合について述べる。

図２０は、複数のテーブルを定義したフォームファイルを使用して出力した帳票イメージの一例である。この帳票は、企業内で使用される各種機器の管理帳票であり、部署ごとのメンバ及び部署が管理する機器をまとめたものである。ここでは４ページから構成されている例を示している。メインテーブル２００１には、各部署のメンバが一覧される。サブテーブル２００２には、部署で管理する機器が一覧される。また、各ページにはページ番号２００３が出力される。メインテーブル２００１は、フォームファイルにて、１ページ当たり最大４つのレコードを表示するように定義され、また、サブテーブル２００２は、１ページ当たり最大７つのレコードを表示するように定義されている。この最大値を超えるレコードがある場合には、次のページに続けて表示される。また、ここでは、メインテーブルとサブテーブルには主従関係があるものとし、メインテーブルを主とする。

「開発室１」に関するデータが１ページ目および２ページ目に出力され、「開発室２」のデータが４ページ目に出力されている。３ページ目のメインテーブル２００１には何も出力されていない。つまり、３ページ目はいずれの部署にも対応付けられていないレコードが表示されている例を示している。組織変更で部署の構成が変化した場合等で、企業システムのデータベースからメインテーブルのデータが削除されてしまうケースでこのような状況が生じる。本来、「機器１１」等は別の部署の管理機器として紐付けられるはずだが、システム変更が間に合っていない場合も考えられる。このようなタイミングで帳票出力を行うと、本来ユーザとしては出力されてほしくない３ページ目が出力されてしまうという問題がある。本実施形態では、上記問題を解決することを目的とする。

［処理フロー］
図２１は、本発明における文書生成サービス３０４の文書生成処理を示すフローチャートである。図１４と異なる部分のみ説明し、重複する部分は第一の実施形態と同様である。

Ｓ１４０１にて、文書生成部６０４は、フォーム管理部６０３からフォームファイル１３０１を読み込み、そのフォームファイル１３０１の解析を行う。上述した実施形態の処理に加え、文書生成部６０４は、フォームファイル１３０１に定義された全てのメインテーブル、サブテーブルの読み込みと、各テーブルで表示するフィールド図形の情報を取得する。そして、文書生成部６０４は、テーブルごとの情報とフィールド図形の情報を紐付けて管理する。

Ｓ２１０１にて、文書生成部６０４は、読み込んだフォームファイル及び入力データの情報から、関連情報の取得を行う。なお、文書生成システムにおいてどのように各テーブルのデータの関連性を表現方法については、いずれの方法を用いてもよく、ここでの説明は省略する。同様に、関連情報の取得処理の内容についても特に限定するものではない。

本実施形態では、入力データが設定されるメインテーブルおよびサブテーブルのフィールド図形に対して、フォームファイルエディタ（不図示）で関連付けの設定を明示的に行うことでデータの関連性を表現することとする。つまり、図２０の例の場合、部署のメンバと部署の機器とがそれぞれ、メインおよびサブとして関連付けられている。

Ｓ２１０１にて文書生成部６０４は、フォームファイル１３０１の関連付け設定から、各テーブルがメインかサブかの情報を取得する。さらに文書生成部６０４は、入力データの１行目に含まれる見出し情報から、メインテーブルおよびサブテーブルのフィールド図形に設定されるのが入力データのどのカラムなのかの情報を取得する。

図２２は、メインテーブル及びサブテーブルに入力される入力データの一例である。入力データは、メインテーブルへの入力データ２２０１とサブテーブルへの入力データ２２０２とを含む。データの関連性としては、メインテーブルの入力データ２２０１の「ＩＤ」カラム２２０３が、サブテーブルの入力データ２２０２の「ＡｃｃｏｕｎｔＩＤ」カラム２２０４に対応している。この両カラムのデータが設定される、メインテーブルの「ＩＤ」フィールド図形と、サブテーブルの「ＡｃｃｏｕｎｔＩＤ」フィールド図形に関連付けて設定されているものとする。

Ｓ２１０２にて、文書生成部６０４は、対象のページが、初回のページである、もしくは、サブテーブルのデータ出力が完了した、のいずれかであるか否かを判定する。Ｓ２１０１で取得した関連情報およびレイアウト処理（Ｓ１４０３）によって、どのページでサブテーブルの出力が完了するか否かは事前に判定可能となっている。すなわち、１ページ当たりの配置可能なレコード数および取得されたレコード数により、出力が完了するページが特定できる。

対象のページが、初回のページもしくはサブテーブル出力完了でない場合（Ｓ２１０２にてＮＯ）、Ｓ２１０４に移る。一方、対象のページが初回のページもしくはサブテーブル出力完了である場合には（Ｓ２１０２にてＹＥＳ）、Ｓ２１０３にて、文書生成部６０４は、サブデータ出力フラグを「ＯＮ」で初期化する。サブデータ出力フラグは、サブテーブルが含まれるページの出力を制御するフラグであり、文書生成部６０４が本実施形態に係る処理の実行中にメモリ上に保持する。文書生成部６０４は、サブデータ出力フラグが「ＯＮ」であれば、現在処理対象のページを出力し、「ＯＦＦ」であれば出力しない。ＯＦＦとなる場合とは、現在処理中のページより前に、メインテーブルが出力されていて、かつそのメインテーブルに入力されるデータがなかった場合である。この場合、サブテーブルのデータが空でなかったとしても、メインテーブルのデータが空のため該当ページ自体を出力しないように制御される。なお、メインテーブルのデータが空でなく、サブテーブルのデータが空である場合には、そのページは出力されるように制御する。

Ｓ２１０４にて、文書生成部６０４は、対象ページにメインテーブルが存在するか否かを判定する。メインテーブルが存在しない判定された場合には（Ｓ２１０４にてＮＯ）、Ｓ２１１１へ移る。一方、メインテーブルが存在すると判定された場合には（Ｓ２１０４にてＹＥＳ）、Ｓ２１０５にて、文書生成部６０４は、対象ページにサブテーブルが１つ以上存在するか否かを判定する。

サブテーブルが１つも存在しないと判定された場合には（Ｓ２１０５にてＮＯ）、Ｓ２１０８に移る。一方、サブテーブルが１つ以上存在すると判定された場合には（Ｓ２１０５にてＹＥＳ）、Ｓ２１０６にて、文書生成部６０４は、メインテーブルに入力データが設定されているか否かを判定する。

メインテーブルに入力データが設定されていると判定された場合には（Ｓ２１０６にてＹＥＳ）、Ｓ２１０７にて、文書生成部６０４は、対象ページの出力を行う。その後、Ｓ１４１４へ進む。

一方、メインテーブルに入力データが設定されていないと判定された場合には（Ｓ２１０６にてＮＯ）、Ｓ２１１０にて、文書生成部６０４は、対象ページの出力をスキップする。すなわち、その対象ページは出力されない。その後、Ｓ１４１４へ進む。

Ｓ２１０８にて、文書生成部６０４は、メインテーブルに入力データが設定されているか否かを判定する。メインテーブルに入力データが設定されていると判定された場合には（Ｓ２１０８にてＹＥＳ）、Ｓ２１０７にて、文書生成部６０４は、対象ページの出力を行う。その後、Ｓ１４１４へ進む。

一方、メインテーブルに入力データが設定されていないと判定された場合には（Ｓ２１０８にてＮＯ）、Ｓ２１０９にて、文書生成部６０４は、サブデータ出力フラグをＯＦＦにセットし、Ｓ２１１０にて現在対象のページの出力をスキップする。その後、Ｓ１４１４へ進む。

Ｓ２１１１にて、文書生成部６０４は、対象ページにサブテーブルが存在するか否かを判定する。サブテーブルが存在しない判定された場合には（Ｓ２１１１にてＮＯ）、文書生成部６０４は、データに関連性がないと判断し、Ｓ２１０７にて、対象ページを出力する。その後、Ｓ１４１４へ進む。

一方、サブテーブルが存在すると判定された場合には（Ｓ２１１１にてＹＥＳ）、Ｓ２１１２にて、文書生成部６０４は、対象ページに存在する全てのサブテーブルに入力されるデータが空か否かを判定する。全てのサブテーブルのデータが空と判定された場合には（Ｓ２１１２にてＹＥＳ）、Ｓ２１１１にて、文書生成部６０４は、対象ページの出力をスキップする。その後、Ｓ１４１４へ進む。

一方、１つでもサブテーブルのデータが存在すると判定された場合には（Ｓ２１１２にてＮＯ）、Ｓ２１１３にて、文書生成部６０４は、サブデータ出力フラグがＯＮか否かを判定する。サブデータ出力フラグがＯＮだった場合には（Ｓ２１１３にてＹＥＳ）、Ｓ２１０７にて、文書生成部６０４は、対象ページの出力を行う。その後、Ｓ１４１４へ進む。

一方、サブデータ出力フラグがＯＦＦだった場合には（Ｓ２１１３にてＮＯ）、Ｓ２１１０にて、文書生成部６０４は、対象ページの出力をスキップする。その後、Ｓ１４１４へ進む。

以上、本実施形態により、データおよびテーブル間に関連性があるケースにおいても、入力データが存在しない場合にユーザの所望の帳票を得ることが可能になる。

＜その他の実施形態＞
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。

１０１…クライアント装置、１０２…クラウドプラットフォームサービス、１０３…文書生成サーバ、３０１…Ｗｅｂブラウザ、３０３…Ｗｅｂサーバ、３０４…文書生成サービス、５０２…制御部、５０３…ページ生成部

Claims (9)

1. 文書生成システムであって、
   クライアントからの要求に応じて文書データを生成する生成手段と、
   前記生成手段が文書データを作成する際に用いる、ページごとのフォームの情報と、ページに埋め込まれるデータとを管理する管理手段と
   を備え、
   前記生成手段は、前記文書データを構成するページのうち、ページに対応するフォームに前記管理手段にて管理するデータを埋め込む領域であるフィールド図形が含まれ、かつ、当該フィールド図形に埋め込むためのデータが前記管理手段にて管理されていないページは出力しないことを特徴とする文書生成システム。
2. 前記生成手段は、前記文書データを構成するページのうち、
   ページに対応するフォームに、前記フィールド図形を含まない場合には、当該ページを出力し、
   ページに対応するフォームに、前記フィールド図形を含み、かつ、当該フィールド図形に埋め込むためのデータが前記管理手段にて管理されている場合には、当該ページを出力する
   ことを特徴とする請求項１に記載の文書生成システム。
3. 前記文書データを構成するページは、複数のレイヤーから構成され、
   前記生成手段は、前記複数のレイヤーそれぞれにおいて、フィールド図形が含まれるか否か、および、当該フィールド図形に埋め込むためのデータの前記管理手段にて管理されているか否かを判定し、ページを出力するか否かを決定することを特徴とする請求項１または２に記載の文書生成システム。
4. 前記複数のレイヤーの少なくとも一つは、ヘッダもしくはフッタであることを特徴とする請求項３に記載の文書生成システム。
5. 前記ヘッダもしくはフッタを、レイヤーとしてページに含めるか、別のページとして構成するかの設定を受け付けるための画面を表示する手段を更に有することを特徴とする請求項４に記載の文書生成システム。
6. 前記複数のレイヤーのうちのいずれかの出力の設定を受け付ける手段を更に有し、
   前記生成手段は、前記出力をすると設定されたレイヤーを含むページは、前記判定の結果に関わらず出力を行うことを特徴とする請求項３乃至５のいずれか一項に記載の文書生成システム。
7. 前記フィールド図形に埋め込まれるデータは、主従関係からなる複数のテーブルから構成され、
   前記ページのフォームは、前記複数のテーブルそれぞれのデータを埋め込むための複数のフィールド図形を含み、
   前記生成手段は、前記複数のテーブルのうち、主のテーブルのデータが前記管理手段にて管理されていない場合、当該複数のテーブルのデータを埋め込むフィールド図形を含むページを出力しないことを特徴とする請求項１または２に記載の文書生成システム。
8. 文書データを作成する際に用いる、ページごとのフォームの情報と、ページに埋め込まれるデータとを管理する管理部を備える文書生成システムの制御方法であって、
   クライアントからの要求に応じて、前記管理部にて管理されたデータを用いて文書データを生成する生成工程を有し、
   前記生成工程において、前記文書データを構成するページのうち、ページに対応するフォームに前記管理部にて管理するデータを埋め込む領域であるフィールド図形が含まれ、かつ、当該フィールド図形に埋め込むためのデータが前記管理部にて管理されていないページは出力しないことを特徴とする文書生成システムの制御方法。
9. コンピュータを、
   クライアントからの要求に応じて文書データを生成する生成手段、
   前記生成手段が文書データを作成する際に用いる、ページごとのフォームの情報と、ページに埋め込まれるデータとを管理する管理手段
   として機能させ、
   前記生成手段は、前記文書データを構成するページのうち、ページに対応するフォームに前記管理手段にて管理するデータを埋め込む領域であるフィールド図形が含まれ、かつ、当該フィールド図形に埋め込むためのデータが前記管理手段にて管理されていないページは出力しないことを特徴とするプログラム。

Images