JPWO2013114438A1 - 携帯端末管理サーバ、および携帯端末管理プログラム - Google Patents

Abstract

ユーザに帳票に関する情報を提供する業務システムにおいて、ＥＲＰシステムの維持やデータの更新に要する負荷を軽減させる。
ＥＲＰが稼動する携帯端末管理サーバ１０が、プロセスフローＤＢ１８と、業務プロセスに関する情報であって、業務プロセスが属するプロセスフローと、業務プロセス毎に発生するプロセスデータに関して許容される処理タイプ（例えば、「登録」、「変更」。）とを示すマトリクスデータを記憶するプロセスフロー制御定義マトリクスＤＢ１９とを備え、携帯端末３１から、プロセスフローと業務プロセスとを特定可能な処理対象特定情報を受け付け、処理対象特定情報に対応する処理タイプをＰＦＣＭＤＢ１９を参照して特定し、携帯端末３１から、ユーザＸによる入力データを受け付け、処理タイプと入力データとに基づいて、プロセスフローＤＢ１８に記憶されたプロセスフローデータを更新する。

Description

本発明は、ＥＲＰが稼動するサーバであって、ユーザが使用する携帯端末からの要求に応じて通信ネットワークを介して各種データを提供する携帯端末管理サーバ、および携帯端末管理サーバに搭載される携帯端末管理プログラムに関する。

従来から、企業における基幹業務システムを構築するためのパッケージソフトウェアとして、ＥＲＰ（Enterprise Resource Planning）と呼ばれるものが主流となっていた。このＥＲＰが搭載された基幹業務システム（統合基幹業務システム、ＥＲＰシステム）では、リレーショナルデータベース上で構築されることが多くなってきており、業務処理に主眼をおいたアプリケーションプログラムの設計がなされることが多く、帳票出力には主眼が置かれずに運用されることが多い。

このような状況の下、大量の業務データを高速に処理し、様々な切り口で業務データを分析し、帳票出力することを目的として、基幹業務システムの補完的な役割を担う様々なデータウェアハウスシステムが提供されるようになった（特許文献１参照）。

特開２００２―３１２２０８号公報

上記のようなデータウェアハウスシステムでは、帳票に関する各種データ（以下「帳票データ」という。）を更新する場合、例えばユーザにより入力されたデータに誤りがあるか否かを判定するのに、複数あるデータの種類に応じて作成された複数のプログラムを用いることがあった。

しかし、複数のプログラムを用いてデータの正否判定を行う方法では、ＥＲＰシステムが取り扱うデータの種類が多くなるほど、判定結果が出力されるまでに時間がかかるという問題があった。また、このような方法では、データの種類が追加される度に追加されたデータの種類に応じた正否判定用プログラムを作成する作業が必要となるため、システムの維持にかかるコストが大きくなってしまう場合があるという問題があった。

一方、従来のＥＲＰシステムでは、各業務プロセスにおいて取得されるデータ（ユーザにより入力されるデータと各種データから算出されるデータとを含む。）を、それぞれ専用のデータテーブル（テーブル）に登録し、管理している。すなわち、従来のＥＲＰシステムにおいては、受注や出荷指示などの入力プロセス毎に、更新するテーブルが異なる。なお、「入力プロセス」とは、各業務プロセスにおいてＥＲＰシステムの管理者などが取得（または決定）した各種データを、各テーブルに入力する処理を意味する。

図１２は、従来のＥＲＰシステムにおけるテーブル構成の例について説明するための説明図である。例えば、複数の業務プロセスにより構成される業務フロー（プロセスフロー）が「在庫売上」を示すものである場合、入力プロセスは、受注、出荷指示、出庫、検収、および売上の５つとなる。この場合、「在庫売上」のプロセスフローに関するデータを格納するテーブルは、例えば図１２（Ａ）から図１２（Ｅ）に示すように、入力プロセス毎にそれぞれ、受注テーブル、出荷指示テーブル、出庫テーブル、検収テーブル、および売上テーブルの５つとなる。

すなわち、従来のＥＲＰシステムでは、入力プロセス毎に更新するテーブルが異なっていた。そのため、同一のプロセスフローに属する複数の業務プロセス間の対応付けは、各業務プロセスに関するデータ（プロセスデータ）に対して識別子（図１２においては、出荷指示テーブルにおける受注番号と受注明細や、出庫テーブルにおける出荷指示番号と出荷指示明細など）を付与することにより行われていた。

そのため、従来のＥＲＰシステムでは、１つの入力プロセスに対して、入力プロセスの種類に応じたテーブルの特定と、対応する他のプロセスデータの識別子の入力とが必要となっていた。すなわち、例えば図１２に示す場合に、受注番号「Ａ００００１」と受注明細番号「００１０」とで特定されるプロセスデータ（すなわち、受注テーブルにおいて受注番号「Ａ００００１」と受注明細番号「００１０」と同一列に格納された各種データ）に関連する業務プロセス「出荷指示」に関するプロセスデータをＥＲＰシステムが備えるデータベースに登録する場合、業務プロセス「出荷指示」に関するプロセスデータとして、プロセスデータを特定するための出荷指示番号と出荷指示明細番号、業務プロセスの種類を示すタイプ、および業務プロセスの内容を示すデータ（例えば、受注先、数量、金額、出荷指示日、出荷テキストなど）と共に、受注番号「Ａ００００１」と受注明細番号「００１０」とを出荷指示テーブルに登録する必要があった。これは、複数のテーブルに一部同一のデータ（例えば、受注先や数量、金額など）が登録されてしまうことなど、効率的なデータ処理の観点からみて問題があった。

さらに、従来のＥＲＰシステムでは、各種テーブルに格納された各種データを用いてユーザの要求に応じた帳票を作成しようとする場合、プロセスデータの識別子を辿って必要なプロセスデータを検索し、それぞれ別個に取得する必要があるため、プロセスフローが多数の業務プロセスを含む場合、プロセスフローに関する帳票を出力するために要する処理負荷が過大になってしまうという問題があった。

本発明は、上述した問題を解消し、ユーザに帳票に関する情報を提供する業務システム（ＥＲＰシステム）において、業務システムの維持やデータの更新に要する処理負荷を軽減させることができるようにすることを目的とする。

本発明の携帯端末管理サーバは、ＥＲＰが稼動するサーバであり、ユーザが使用する携帯端末からの要求に応じて通信ネットワークを介して各種データを提供する携帯端末管理サーバであって、複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータを記憶するプロセスフローデータ記憶手段と、前記業務プロセスに関する情報であって、業務プロセスが属するプロセスフローと、業務プロセス毎に発生するプロセスデータに関して許容される処理タイプとを示すマトリクスデータを記憶するマトリクスデータ記憶手段と、前記携帯端末から、前記プロセスフローと前記業務プロセスとを特定可能な処理対象特定情報を受け付ける処理対象特定情報受付手段と、該処理対象特定情報受付手段によって受け付けられた処理対象特定情報に対応する処理タイプを前記マトリクスデータ記憶手段を参照して特定する処理タイプ特定手段と、前記携帯端末から、ユーザによって入力された入力データを受け付ける入力データ受付手段と、前記処理タイプ特定手段によって特定された処理タイプと、前記入力データ受付手段によって受け付けられた入力データとに基づいて、前記プロセスフローデータ記憶手段に記憶されたプロセスフローデータを更新するプロセスフローデータ更新手段とを含むことを特徴とする。

上記の構成としたことで、ユーザに帳票に関する情報を提供する業務システム（ＥＲＰシステム）において、業務システムの維持やデータの更新に要する負荷を軽減させることができるようになる。

前記マトリクスデータは、行項目に、複数種類のプロセスフローが設定されており、列項目に、複数種類の業務プロセスが設定されており、各セルに、列項目に設定された業務プロセスが対応する行項目に設定されたプロセスフローに含まれるか否かを示すフラグが設定されており、前記処理タイプ特定手段は、前記処理対象特定情報が示すプロセスフローと業務プロセスとの組み合わせに対応するセルに設定されたフラグを参照し、当該フラグが、前記業務プロセスが前記プロセスフローに含まれていることを示す場合に、当該業務プロセスのプロセスデータとして許容される処理タイプを前記処理対象特定情報に対応する処理タイプとして特定し、前記入力データ受付手段は、前記処理タイプ特定手段によって特定された処理タイプに応じた入力データを受け付ける構成とされていてもよい。

前記入力データ受付手段によって受け付けられた入力データが、前記処理対象特定情報が示すプロセスフローにおける業務プロセスに関するデータを更新するために必要な条件としてあらかじめ設定された条件である更新条件を満たすか否かを判定する入力データ判定手段を含み、前記プロセスフローデータ更新手段は、前記入力データ判定手段によって前記入力データが前記更新条件を満たすと判定された場合に、当該入力データを用いて前記プロセスフローデータを更新する構成とされていてもよい。

前記更新条件は、前記入力データが、前記処理対象特定情報が示す業務プロセスにあらかじめ設定された必須項目に対応するデータを有していることである構成とされていてもよい。

また、本発明の携帯端末管理プログラムは、ＥＲＰを稼動させ、ユーザが使用する携帯端末からの要求に応じて通信ネットワークを介して各種データを提供する処理を携帯端末管理サーバに実行させる携帯端末管理プログラムであって、複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータを記憶するプロセスフローデータ記憶手段と、前記業務プロセスに関する情報であって、業務プロセスが属するプロセスフローと、業務プロセス毎に発生するプロセスデータに関して許容される処理タイプとを示すマトリクスデータを記憶するマトリクスデータ記憶手段とを備えた前記携帯端末管理サーバに、前記携帯端末から、前記プロセスフローと前記業務プロセスとを特定可能な処理対象特定情報を受け付ける処理対象特定情報受付処理と、該処理対象特定情報受付処理にて受け付けた処理対象特定情報に対応する処理タイプを前記マトリクスデータ記憶手段を参照して特定する処理タイプ特定処理と、前記携帯端末から、ユーザによって入力された入力データを受け付ける入力データ受付処理と、前記処理タイプ特定処理にて特定した処理タイプと、前記入力データ受付処理にて受け付けた入力データとに基づいて、前記プロセスフローデータ記憶手段に記憶されたプロセスフローデータを更新するプロセスフローデータ更新処理とを実行させるためのものである。

本発明によれば、ユーザに帳票に関する情報を提供する業務システム（ＥＲＰシステム）において、業務システムの維持やデータの更新に要する負荷を軽減させることができるようになる。

帳票照会システムの構成例を示すブロック図である。 携帯端末管理サーバの構成例を示すブロック図である。 プロセスフローデータの格納状態の例を示す説明図である。 ＰＦＣＭの格納状態の例を示す説明図である。 プロセスフローデータ入力処理の例を示すフローチャートである。 データ処理対象入力画面の例を示す説明図である。 データ入力画面情報作成処理の例を示すフローチャートである。 データ入力画面の例を示す説明図である。 データ入力画面の例を示す説明図である。 データ入力画面の例を示す説明図である。 データ入力画面の例を示す説明図である。 従来のＥＲＰシステムにおけるテーブル構成の例について説明するための説明図である。

以下、本発明の一実施の形態の例について図面を参照して説明する。
図１は、本発明の一実施の形態に係る帳票照会システム５００の構成例を示すブロック図である。図１に示すように、帳票照会システム５００は、携帯端末管理サーバ１０と、中継機２０と、複数の携帯端末３１〜３Ｎ（Ｎは任意の正の整数）と、統合基幹業務システム１００と、統合基幹業務システム２００と，統合基幹業務システム３００とを含む。携帯端末管理サーバ１０と各携帯端末３１〜３Ｎとは、それぞれ、インターネットなどの通信ネットワーク４０及び中継機２０を介して接続される。携帯端末管理サーバ１０は、統合基幹業務システム１００、統合基幹業務システム２００、統合基幹業務システム３００と、それぞれＬＡＮ（Local Area Network）や専用通信回線などの通信ネットワーク５１，５２，５３を介して接続される。なお、携帯端末同士や統合基幹業務システム同士は、携帯端末管理サーバを介して通信可能な構成としてもよいし、通信不能な構成としてもよい。

統合基幹業務システム１００は、基幹業務サーバ１１０と、データウェアハウスサーバ（ＤＷＨサーバ）１２０と、プロセスフローＤＢ１０１とを含む。統合基幹業務システム２００は、ＤＷＨサーバ２２０と、プロセスフローＤＢ２０１とを含む。統合基幹業務システム３００は、基幹業務サーバ３１０と、プロセスフローＤＢ３０１とを含む。

構成が異なる複数の統合基幹業務システム１００，２００，３００は、必要に応じて（すなわち、それぞれが有する機能に応じて）携帯端末管理サーバ１０と通信（各種情報の送受信）を行うことにより、統合基幹業務システムとしての機能を発揮する。すなわち、帳票照会システムにおいては、基幹業務サーバを有さないシステム２００や、ＤＷＨサーバを有さないシステム３００であっても、携帯端末管理サーバ１０との通信を行うことにより、統合基幹業務システムとしての機能を発揮することができる。なお、図示しないが、プロセスフローＤＢを有さないシステムであっても、携帯端末管理サーバ１０にてプロセスフローデータを記憶することにより、統合基幹業務システムとしての機能を発揮することができる。各基幹業務システムが備える基幹業務サーバ等には公知の技術が用いられるため、以下、統合基幹業務システム１００を例にして説明を行う。

基幹業務サーバ１１０とＤＷＨサーバ１２０とは、専用通信回線により接続されているものとする。

基幹業務サーバ１１０は、例えば帳票照会システム５００の管理者によって管理されるサーバであり、各種業務に関する帳票情報を管理（例えば、情報の作成や更新、保存など。）するための各種の機能を有する。基幹業務サーバ１１０は、ＯＳ（Operating System）やリレーショナルＤＢを備えた一般的な情報処理装置によって構成される。

ここで、帳票とは、帳簿や伝票類の総称である。また、帳簿とは、金銭や品物の出納に関する事項が記入されるものであり、伝票とは、帳簿を作成する際の基となるデータであり業務上の取引等の証拠となるものである。本例においては、基幹業務サーバ１１０が、帳票データとして伝票データのみを示すプロセスデータを扱う場合を例に説明を行なう。

基幹業務サーバ１１０は、業務アプリケーションプログラムに従って各種の処理を実行する。業務アプリケーションプログラムとしては、例えば、販売業務管理プログラム、販売業務管理プログラム、生産管理プログラム、財務会計管理プログラム、および管理会計管理プログラムなどがある。

ＤＷＨサーバ１２０は、例えば本システムのシステム管理者によって管理されるサーバであり、データウェアハウスを実現するための各種の機能を有する。ここで、データウェアハウスとは、時系列で蓄積された帳票データなどの業務データの中から各項目間の関連性を分析するシステムをいう。また、ＤＷＨサーバ１２０は、基幹業務サーバ１１０から転送されたＣＳＶ形式のファイルを所定のデータ形式に変換するなどして、所定の格納領域（後述する業務関連データＤＢ１０１ｂ）に各種データを登録する機能を有する。なお、ＤＷＨサーバ１２０は、データ形式の変換を行わず、ＣＳＶ形式の状態から各格納領域に応じたデータを抽出する構成とされていてもよい。

プロセスフローＤＢ１０１は、基幹業務サーバ１１０の業務アプリケーションプログラムＤＢ（図示せず）に記憶された各種プログラムを用いた各種情報処理によって収集・整理等された各種のプロセスデータ（または帳票データ）により構成されるプロセスフローデータを記憶する記憶媒体である。なお、プロセスフローデータについては、後で詳しく説明する。また、本例においては、統合基幹業務システム１００は、ＤＷＨサーバ１２０によって管理される業務関連データＤＢ（図示せず）を含み、基幹業務サーバ１１０は、プロセスフローＤＢ１０１に記憶されたプロセスデータを、所定の抽出条件に応じてＣＳＶ
（Comma Separated Values）形式に変換して携帯端末管理サーバ１０に送信する機能を有する。なお、本例においては、基幹業務サーバ１１０は、ＦＴＰ（File Transfer Protocol）によりＣＳＶ形式にしたデータファイルを携帯端末管理サーバ１０に転送する。

携帯端末管理サーバ１０は、ＥＲＰが稼動するサーバであって、ユーザが使用する携帯端末からの要求に応じて通信ネットワークを介して各種データを提供するサーバである。携帯端末管理サーバ１０は、例えばＷＷＷサーバなどの情報処理装置によって構成され、帳票照会システム５００のシステム管理者によって管理される。

図２は、携帯端末管理サーバ１０の構成例を示すブロック図である。図２に示すように、携帯端末管理サーバ１０は、各種制御を行う制御部１１と、プロセスフローデータ一時保管ＤＢ１６と、業務アプリケーションプログラムＤＢ１７と、プロセスフローＤＢ１８と、ＰＦＣＭＤＢ１９と、一般的な基幹業務サーバとしての機能を実現するために必要な各種データ（例えば、業務アプリケーションプログラムＤＢ１７に格納される各種プログラムが利用するデータ）を格納するその他ＤＢ１０Ｘとを備えている。なお、その他ＤＢ１０Ｘについては、本発明に特に関係しない部分であるため、詳しい説明は省略する。制御部１１は、携帯端末３１〜３Ｎにプロセスフローデータを提供する処理などを実行する伝票データ提供処理部１１ａを含む。

プロセスフローデータ一時保管ＤＢ１６は、統合基幹業務システム１００側から取得したプロセスフローデータや、プロセスフローＤＢ１８に記憶されたプロセスフローデータを一時的に保存する記憶媒体である。プロセスフローデータ一時保管ＤＢ１６に記憶されるプロセスフローデータは、例えば定期的（１日毎、３日毎、１２時間毎など）に更新される。

業務アプリケーションプログラムＤＢ１７は、各種業務に用いられるプログラムを記憶する記憶媒体である。業務アプリケーションプログラムＤＢ１７に記憶されるプログラムとしては、販売業務管理プログラム、購買業務管理プログラム、生産管理プログラム、財務会計管理プログラム、および管理会計管理プログラムなどがある。

プロセスフローＤＢ１８は、業務アプリケーションプログラムＤＢ１７に記憶された各種プログラムを用いた各種情報処理によって収集・整理等された各種のプロセスデータ（または帳票データ）により構成されるプロセスフローデータを記憶する記憶媒体である。本例においては、プロセスフローＤＢ１８において、複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータがプロセスフローテーブルＰＴに格納される場合について説明する。また、本例においては、携帯端末管理サーバ１０が、プロセスフロー毎に発生するプロセスフローデータを１つのプロセスフローテーブルＰＴにて一元管理する場合について説明する。なお、本例においては、プロセスフローデータには、一般的に用いられている伝票データ（例えば、受注伝票に対応する伝票データについては、受注伝票ヘッダ情報、受注伝票明細情報、および納入日日程などが対応付けされ、伝票番号などのキーを元に検索可能な構造で記憶されたデータ。なお、伝票番号には、受注番号、発注番号、出荷番号、入出庫番号、請求書照会、請求番号、会計番号などが含まれる。）が含まれるものとする。

なお、携帯端末管理サーバ１０が、プロセスフローデータを、例えば、後述するタイプ毎に、あるいは後述する共通データの内容の一部（例えば、受注先など）が同じもの毎に、複数のテーブルで管理する構成としてもよい。

図３は、プロセスフローＤＢ１８におけるプロセスフローデータの格納状態の例を示す説明図である。図３に示すように、本例におけるプロセスフローデータは、主キー部と、参照キー部と、タイプ部と、ステータス部と、共通データ部と、プロセス固有データ部とを含む。なお、プロセスフローデータの各部に対応する項目（すなわち、プロセスフローテーブルＰＴにおける各列項目）が、それぞれ、プロセスフローデータを構成するプロセスデータの種類を示す。すなわち、プロセスフローを構成する各業務プロセスに関するデータは、プロセスフローデータを構成する各部に割り当てられて格納される。なお、１つのプロセスフロー（例えば、ある企業からの受注から納品までの一連のプロセスフロー）に関するプロセスデータは、プロセスフローテーブルＰＴにおいて同一エントリ（すなわち、プロセステーブルＰＴにおける同一行）に格納される。このような構成とすることにより、各プロセスデータ間の対応関係を定義することができる。

ここで、「主キー部」とは、プロセスフローデータのうち、プロセスフローデータを一意に特定するためのデータである主キーデータが格納される部分である。本例においては、主キー部は、プロセスフロー番号とプロセスフロー明細番号とにより構成される。すなわち、本例においては、プロセスフロー番号とプロセスフロー明細番号との組み合わせが、各プロセスフローデータの識別子（ＩＤ）となる。主キー部は、プロセスフローデータの初回登録時に更新される。なお、ここでの「プロセスフローデータの初回登録時」とは、プロセスフローデータにエントリ（データ行）が追加されるとき、例えば、あるプロセスフローに属するプロセスデータであって、対応する他のプロセスデータが未登録のプロセスデータが登録されるときを意味するものとする。また、ここでの「更新」とは、データの追加を含むものとする。

なお、「プロセスフロー番号」とは、１つのプロセスフローデータ（すなわち、図３に示すプロセスフローテーブルＰＴにおける１列）を特定するための識別子である。プロセスフロー番号は、所定の項目が同じプロセスデータ毎に付与される。本例においては、プロセスフロー番号は、プロセスフローデータにおけるタイプと受注先とが同じプロセスフローデータに対して同一の番号が付与される。

また、「プロセスフロー明細番号」とは、同一のプロセスフロー番号が付与されたプロセスフローデータの中から特定のプロセスフローデータを特定するための識別子である。すなわち、例えば図３に示すプロセスフローテーブルＰＴは、プロセスフローのタイプ「在庫売上」における業務プロセス「受注」において、受注先「Ｔ００１」から金額「１２００」と「２６００」の業務を受注したことを示すプロセスデータを含むプロセスフローデータを、それぞれプロセスフロー番号「０００００１」とプロセスフロー明細番号「００１０」または「００２０」の組み合わせにより一意に特定することができる。

次いで、「参照キー部」とは、プロセスフローデータのうち、売上返品に対する元取引など、プロセスフローに関連する他のプロセスフローデータ（または、他のプロセスデータ）を特定するためのデータである参照キーデータが格納される部分である。本例においては、参照キー部は、参照番号と参照明細番号とにより構成される。参照キー部は、プロセスフローデータの初回登録時に更新される。

なお、参照番号と参照明細番号には、それぞれ、プロセスフローに関連する他のプロセスフローのプロセスフロー番号とプロセスフロー明細番号とが格納される。ただし、新規取引の場合など、プロセスフローに関連する他のプロセスフローがない場合には、参照キー部には、同一エントリの主キー部と同じ値を示すデータが（すなわち、参照番号にはプロセスフロー番号が、参照明細番号にはプロセスフロー明細番号がそれぞれ）格納される。また、参照キー部が、プロセスフローに関連する他のプロセスデータを示す場合、参照キー部には、プロセスデータの種類を特定するためのデータがさらに設けられる。

また、「タイプ部」とは、プロセスフローデータのうち、在庫売上やサンプル出荷など、プロセスフローの種類を示すデータであるタイプデータが格納される部分である。タイプ部は、プロセスフローデータの初回登録時に更新される。なお、プロセスフローの種類は、在庫売上やサンプル出荷に限られない。また、プロセスフローの種類毎にどのプロセスが必要なのかが予め決まっているものとする（すなわち、プロセスフローの種類毎に含まれる業務プロセスの種類や数が異なる）。

また、「ステータス部」とは、プロセスフローデータのうち、プロセスフローの進捗を表すデータ（すなわち、プロセスフローに含まれる複数の業務プロセスそれぞれの進捗状況を示すデータ）であるステータスデータが格納される部分である。本例においては、ステータスデータは、プロセスフローが必要とする業務プロセスに対し、未済のものには「０」、既済のものには「１」が設定されることにより、各業務プロセスの進捗を示す。すなわち、例えば図３に示すように、「在庫売上」のプロセスフローであって、プロセスフローに含まれる業務プロセスが「受注」、「出荷」、「出庫」、「出庫検収」、および「売上」である場合に、業務プロセス「受注」に関するプロセス固有データ（例えば、受注日）が登録されたとする。この場合、ステータスデータは、「売上」に対応する部分が「１」になり、その他の部分は初期状態（すなわち、「０」が設定された状態）のままとなる。

すなわち、本例におけるステータス部は、業務プロセス毎に更新される。言い換えれば、ステータス部は、プロセス固有データの入力のとき、具体的には、所定のステータス変更条件が満たされたことにより各業務プロセスが完了した判定されたときに更新される。なお、ステータス変更条件は特に限定されないが、本例においては、「１つの業務プロセスに対応するプロセス固有データが全て入力されること」がステータス変更条件として携帯端末管理サーバ１０の所定の記憶領域に記憶されているものとする。

なお、本例においては、異なる種類のプロセスフローが同一のテーブルに格納されるため、テーブルを構成する項目（列項目）のうち、特定のプロセスフローには不要なプロセスデータを格納する部分が生じる場合もある。この場合、プロセスフローテーブルにおいては、不要なプロセスデータを格納する部分が空データとなり、空データに対応するステータスデータには「０」が格納されるものとする。

また、「共通データ部」とは、プロセスフローデータのうち、受注先や出荷先など、業務プロセスによらないデータ（すなわち、同一のプロセスフローに含まれる業務プロセス間で共通するデータ）である共通データが格納される部分である。共通データ部は、プロセスフローデータの初回登録時に更新される。

また、「プロセス固有データ部」とは、プロセスフローデータのうち、受注日や各業務プロセスにおいて登録されるデータ（例えば、「納期必着」や「ワレモノ（割れ物注意）」などの注意事項を示すテキストデータ）など、同一のプロセスフローに含まれる各業務プロセスに固有のデータであるプロセス固有データが格納される部分である。プロセス固有データ部は、業務プロセス毎に更新される。よって、本例においては、プロセスフローデータのうち、業務プロセスによるものが「プロセス固有データ」であり、業務プロセスによらないものが「共通データ」であるといえる。

以上が本例におけるプロセスフローデータに関する説明となるが、ここで、図３に示す各種用語の定義について簡単に説明する。

先ず、「受注」とは、得意先から注文を受け、得意先との契約を結んだ状態を意味する。また、「出荷指示」とは、倉庫業者や物流担当者に商品を出荷する指示を行った状態を意味する。また、「出庫」とは、商品が倉庫から出荷され、移動が開始された状態を意味する。また、「検収」とは、得意先の検収が完了し、商品の所有権が得意先に移行した状態を意味する。また、「売上」とは、得意先の検収を確認し、得意先に対する債権金額が確定（＝債権を計上）した状態を意味する。

また、「検収」の用語は、「納入品やサービスが、注文通りの仕様（＝注文通りの数量、色や形、品質）になっているかを検査する業務」や「検収完了時、資産の所有権が移行する」という意味でも用いられる。なお、財務会計上（または、制度会計上）やＥＲＰシステム上では、資産の所有権の移行タイミングを明確にするために、「検収」というイベントが出庫と区別して定義される。

ＰＦＣＭＤＢ１９は、ＰＦＣＭを示すＰＦＣＭデータを記憶するための記憶媒体である。ここで、ＰＦＣＭ（すなわち、プロセスフロー制御定義マトリクス）とは、複数のプロセスフローに関するデータの入力（すなわち、プロセスフローデータの更新。）を許容するか否か判定するために用いられるマトリクスである。なお、ＰＦＣＭは、例えば帳票照会システム５００の管理者によって作成されるものとする。

図４は、ＰＦＣＭＤＢ１９におけるプロセスフロー制御定義マトリクス（ＰＦＣＭ）の格納状態の例を示す説明図である。図４に示すように、本例におけるＰＦＣＭの行項目には、複数種類のプロセスフローが設定されている。また、ＰＦＣＭの列項目には、複数種類のプロセスが設定されている。なお、ＰＦＣＭの内容は、帳票照会システム５００のユーザの業務内容に応じて適宜変更・更新される。

本例においては、ＰＦＣＭの行項目には、「販売」や「購買」などの種類に分類された複数のプロセスフロー（例えば、「在庫販売」、「在庫仕入」、「棚卸」、「振替伝票処理」。）が設定されている。そして、各プロセスフローを構成するプロセスが設定された列とのセルには、フラグ（図４における「黒丸」に対応。）が設定されている。すなわち、図４に示すＰＦＣＭでは、例えば、プロセスフロー「在庫販売」を構成するプロセスにはプロセス「受注」が含まれることとなる。

また、本例においては、ＰＦＣＭの列項目には、「受注見積」や「受注契約」など、各種プロセスフローを構成し得る各種プロセスが設定されている。さらに、本例におけるＰＦＣＭの列項目には（言い換えれば、列項目に設定された各プロセスには）、プロセス毎に発生するプロセスデータに関して許容される処理タイプが設定されている。具体的には、図４に示すように、各プロセスの下側に、処理タイプを示す項目が設定されている。すなわち、本例においては、各プロセスには３つの処理タイプ「登録」、「変更」、「取消」に対応するセルが設けられており、プロセス毎に発生するプロセスデータに関して許容される処理タイプを示すセルにはフラグ（図４における「黒丸」に対応。）が設定されている。

ここで、処理タイプの意味（役割）について説明する。処理タイプ「登録」は、プロセスに対応する伝票データとして入力される伝票データが新規登録なのかを表す。処理タイプ「変更」は、プロセスに対応する伝票データとして入力される伝票データが既存データの変更なのかを表す。処理タイプ「取消」は、プロセスに対応する伝票データとして入力される伝票データが既存データの取消なのかを表す。すなわち、例えば図４におけるプロセス「受注見積」であれば、新規登録または既存データの変更としてのデータ入力が許容されることとなっている。

携帯端末管理サーバ１０は、プロセスフローＤＢ１８およびその他ＤＢ１０Ｘに格納された各種データを、所定の外部装置、本例においては携帯端末３１〜３Ｎ及び統合基幹業務システム１００，２００，３００からの要求に応じて提供する機能を有する。すなわち、携帯端末管理サーバ１０は、基幹業務サーバとしての機能を有する。言い換えれば、携帯端末管理サーバ１０は、ＥＲＰエンジンを備える。

なお、図示しないが、本例においては、携帯端末管理サーバ１０は、データウェアハウスを実現するための各種の機能を有するＤＷＨサーバとしての機能を有するものとする。携帯端末管理サーバ１０が、ＥＲＰエンジンと、ＤＷＨサーバとして機能するための構成とを備えることにより、構成の異なる統合基幹業務システム（例えば、基幹業務サーバとＤＷＨサーバのうち、両方を有する統合基幹業務システム１００と、ＤＷＨサーバのみを有する統合基幹業務システム２００と、ＤＷＨサーバのみを有する統合基幹業務システム３００。）に対しても、統合基幹業務システムとして要求される情報の提供を行うことができるようになる。

各携帯端末３１〜３Ｎは、ＣＰＵ（中央処理装置）、ＲＯＭ、ＲＡＭ、および表示部などを備えた例えばＩｐａｄ（登録商標）などの情報処理装置である。本例においては、各携帯端末３１〜３Ｎは、Ｗｅｂブラウザなど、帳票データを扱うために利用可能な各種アプリケーションを有しているものとする。また、本例においては、各携帯端末３１〜３Ｎは、例えばユーザによる操作入力に応じて、携帯端末管理サーバ１０から必要な帳票データ（本例においては、プロセスフローデータ）を取得するためのクエリ（検索項目、検索キー、抽出キーなど）を定義し、携帯端末管理サーバ１０に送信する機能を有する。

本例においては、各携帯端末３１〜３Ｎは、中継機２０及び通信ネットワーク４０を介して携帯端末管理サーバ１０と通信し、携帯端末管理サーバ１０から取得したデータを例えば所定のＷｅｂアプリケーション（Ｗｅｂブラウザ）などのソフトウェアの機能により表示部に出力する機能を有する。

ここで、プロセスフローデータ一時保管ＤＢ１６に記憶されるプロセスフローデータを更新する処理について説明する。本例において、携帯端末管理サーバ１０は、データ更新のタイミング（例えば、１日毎に更新する場合は、予め定められた所定の時間（深夜２時など）。）になると、携帯端末管理サーバ１０が備えるプロセスフローＤＢ１８に格納されているプロセスフローデータ（最新のデータとなる）を読み出して、プロセスフローデータをプロセスフローデータ一時保管ＤＢ１６の所定の格納領域に格納（新規保存、あるいは上書保存）し、プロセスフローデータ一時保管ＤＢ１６の記憶情報を更新する。このようにして、バッチ処理によりプロセスフローデータ一時保管ＤＢ１６の記憶情報が更新される。

次に、本例の帳票照会システム５００の動作について図面を参照して説明する。なお、本発明に特に関係しない動作や処理については、その内容を省略している場合がある。

図５は、本例の帳票照会システム５００における携帯端末管理サーバ１０などが実行するプロセスフローデータ入力処理（以下「データ入力処理」という。）の例を示すフローチャートである。ここでは、携帯端末管理サーバ１０が、ユーザＸが使用する携帯端末３１からの要求に応じてプロセスフローデータの入力を受け付ける場合を例に説明する。

データ入力処理は、例えば、携帯端末管理サーバ１０が、携帯端末３１が、ユーザＸがログイン状態にある携帯端末３１からのデータ入力要求を受け付けたことに応じて開始される。

データ入力処理において、先ず、携帯端末管理サーバ１０は、携帯端末３１に対して所定のデータ処理対象入力画面情報を送信する（ステップＳ１０１）。

データ処理対象入力画面情報を受信すると、携帯端末３１は、受信したデータ処理対象入力画面情報が示すデータ処理対象入力画面を自己が備える表示部に表示する（ステップＳ１０２）。

図６は、データ処理対象入力画面の例を示す説明図である。図６に示すように、データ対象入力画面には、データの入力対象（または、更新対象。）とするプロセスフロー（具体的には、プロセスフローの名称やＩＤなど。）の入力を受け付けるプロセスフロー受付領域６０１と、データの入力対象とするプロセスを示すＩＤ（以下「処理ＩＤ」という。）の入力を受け付ける処理ＩＤ受付領域６０２と、前画面に戻る際に押下される戻るボタンＢ１と、各受付領域６０１，６０２を携帯端末管理サーバ１０に送信する操作として押下される送信ボタンＢ２とが設けられている。なお、本例においては、プロセスフロー受付領域６０１は、プルダウン形式で表示される一覧の中からユーザＸが１つのプロセスフローを選択する構成であるものとする。

データ処理対象入力画面において、ユーザＸは、携帯端末３１が備える操作部（例えばタッチパネルが配置された表示部に表示されたキーボード）を操作して、プロセスフローと処理ＩＤとを入力し、送信ボタンＢ２を押下する。

プロセスフロー及び処理ＩＤが入力された状態で検索ボタンＢ２が押下されると、携帯端末３１は、携帯端末管理サーバ１０に対して、入力されたプロセスフローと処理ＩＤとの組み合わせ（以下「処理対象」という。）を示す処理対象特定情報を送信する（ステップＳ１０４）。なお、上記の処理対象特定情報の内容は一例であり、処理対象特定情報の内容は、任意のプロセスフローデータ（または、プロセスフローデータを構成するプロセスデータ。）を特定可能な内容であれば他のどのような内容であってもよい。

携帯端末管理サーバ１０は、処理対象特定情報を受信すると、ＰＦＣＭを参照して、受信した処理対象特定情報が示すプロセスに設定された処理タイプを特定する（ステップＳ１０５）。ここで、例えば、処理対象として処理ＩＤ「ｘｘｘｘ（受注を示す番号）」を示す処理対象特定情報を受信していた場合、携帯端末管理サーバ１０は、処理タイプ「登録」、「変更」を、処理タイプとして特定する（図４参照）。なお、処理タイプの特定は、後述する処理にてプロセスデータの入力を許容すると判定した後などに実行する構成としてもよい。

処理対象特定情報が示すプロセスの処理タイプを特定すると、携帯端末管理サーバ１０は、プロセスデータの入力を許容するか否かを判定する（ステップＳ１０６）。ここで、例えば処理対象としてプロセスフロー「在庫販売」、処理ＩＤ「ｘｘｘｘ（受注見積を示す番号）」を示す処理対象特定情報を受信していた場合、携帯端末管理サーバ１０は、対応するセルにフラグが設定されていないため、プロセスデータの入力を許容しないと判定し（図４参照）（ステップＳ１０６のＮ）、データ入力を許容しない旨をユーザＸに報知するためのデータ入力不能通知を携帯端末１０に送信する（ステップＳ１０７）。

一方、例えば処理対象としてプロセスフロー「在庫販売」、処理ＩＤ「ｘｘｘｘ（受注を示す番号）」を示す処理対象特定情報を受信していた場合、携帯端末管理サーバ１０は、プロセスデータの入力を許容すると判定して（図４参照）（ステップＳ１０６のＹ）、データ入力画面を示すデータ入力画面情報を作成するための処理（データ入力画面情報作成処理）を実行する（ステップＳ２００）。

図７は、本例の携帯端末管理サーバ１０が実行するデータ入力画面情報作成処理の例を示すフローチャートである。ここでは、処理対象としてプロセスフロー「在庫販売」、処理ＩＤ「ｘｘｘｘ（受注を示す番号）」を示す処理対象特定情報を受信した場合を例にして説明する。

データ入力画面情報作成処理において、先ず、携帯端末管理サーバ１０は、特定した処理タイプに応じた画面情報を特定する（ステップＳ２０１）。なお、本例においては、画面情報は、その他ＤＢ１０Ｘに格納されているものとする。また、処理タイプの内容によっては、画面情報を共有する構成としてもよい。また、処理対象とするプロセスに複数の処理タイプが設定されている場合には、ユーザに処理タイプの選択を要求する構成としてもよい。以下、プロセス「受注」に対応する処理タイプ「登録」と「変更」のうち、ユーザＸよって「登録」が選択されたものとして説明を行う。

画面情報を特定すると、携帯端末管理サーバ１０は、ＰＦＣＭを参照して、処理対象特定情報が示すプロセスフローに含まれるプロセスを特定する（ステップＳ２０２）。本例においては、携帯端末管理サーバ１０は、プロセスフロー「在庫販売」に対応するプロセス（すなわち、図４において、在庫販売の行において、「黒丸」が設定されているセルに対応する列項目に設定されたプロセス。）としてプロセス「受注」を含む複数のプロセスを特定する。

次いで、携帯端末管理サーバ１０は、プロセスフローテーブルＰＴにおけるステータス部を参照して（図３参照）、プロセスフローに含まれるプロセスとして特定したプロセスの中から、データの編集を許容するプロセス（以下「編集許容プロセス」という。）を特定する（ステップＳ２０３）。本例においては、携帯端末管理サーバ１０は、特定した処理タイプが「登録」の場合、ステータス部に「１」が設定されているプロセス（すなわち、既にその処理が行われているプロセス。）以外のプロセスを編集許容プロセスとして特定する。なお、本例においては、複数種類のプロセスの中には、処理タイプ「登録」とは異なるデータの取り扱いをするものが含まれるものとする。すなわち、プロセスの種類に応じて、ステータス部の状態以外にも、編集許容プロセスとする条件が設定されている場合があるものとする。本例においては、処理タイプが「変更」や「取消」の場合、携帯端末管理サーバ１０は、既にその処理が行われているプロセスであっても、編集許容プロセスとするものとする。そして、携帯端末管理サーバ１０は、ユーザＸによって入力されたデータに基づいていわゆるマイナス伝票としての帳票データを作成し（または、マイナス伝票としてのデータ入力をユーザＸに要求し）、作成したマイナス伝票をプロセスフローテーブルＰＴに登録することで、既に行った処理を取り消したことと同じ結果を得るものとする。

編集許容プロセスを特定すると、携帯端末管理サーバ１０は、プロセスフローテーブルＰＴを参照して、特定した編集許容プロセスに対応する伝票項目（例えば、各プロセスに紐付けられたプロセス固有データの項目。）を特定する（ステップＳ２０４）。本例においては、携帯端末管理サーバ１０は、プロセス「受注」に対応する伝票項目として、ヘッダと明細に分類された各種項目（後述する図８−１１参照）を特定する。

伝票項目を特定すると、携帯端末管理サーバ１０は、特定した編集許容プロセスと伝票項目とを含むデータ入力画面情報を作成し（ステップＳ２０５）、データ入力処理におけるステップＳ１０８の処理に移行する（図４参照）。

携帯端末管理サーバ１０は、データ入力画面情報作成処理を終えると、データ入力画面情報作成処理にて作成したデータ入力画面情報を携帯端末３１に送信する（ステップＳ１０８）。

携帯端末３１は、データ入力画面情報を受信すると、自己が備える表示部に、受信したデータ入力画面情報が示すデータ入力画面を表示する（ステップＳ１０９）。なお、このとき、携帯端末管理サーバ１０からデータ入力不能通知を受信している場合には、携帯端末３１は、所定のデータ入力不能通知画面を表示することで、ユーザＸに対してデータの入力が許容されなかったことを報知する（図示せず）。

図８は、データ入力画面の例を示す説明図である。図８に示すように、データ入力画面は、処理対象特定情報が示すプロセスフローに含まれる複数のプロセスそれぞれの伝票項目を表示する操作（以下「伝票項目表示操作」という。）を受け付けるプロセスボタン８０１ａ−８０１ｈが表示されるプロセスボタン表示領域８０１と、プロセスフロー名を表示するプロセスフロー名表示領域８０２と、ユーザが入力したデータの取扱タイプを決定する操作（以下「取扱操作決定操作」という。）を受け付けるための取扱タイプボタン８０３ａ−８０３ｄが表示される取扱タイプボタン表示領域８０３と、ヘッダに分類されたプロセスデータを表示する操作を受け付けるヘッダボタン８０４と、明細に分類されたプロセスデータを表示する操作を受け付ける明細ボタン８０５と、ユーザによるプロセスデータの入力を受け付けるプロセスデータ受付領域８０６とが設けられる。

プロセスボタン表示領域８０１に表示されるプロセスボタン８０１a−８０１ｈの表示形態は、３形態あり、図８においては、太枠で示されるプロセスボタン８０１ａ、細枠で示されるプロセスボタン８０１ｆ，８０１ｇ、及びその他のプロセスボタン８０１ｂ−８０１ｅ，８０１ｈ、に分類される。太枠で示されるプロセスボタンは、今処理しようとしているプロセスを表す。細枠で示されるプロセスボタンは、ユーザによる選択を受け付けず（すなわち、ボタンを押せなくなっている。）、そのプロセスに関する処理が既に行われていることを表す。その他のプロセスは、編集が許容されるプロセスを表す。なお、プロセスボタンの表示形態はこれに限定されず、例えば、今処理しようとしているプロセス（すなわち、プロセスデータ受付領域８０６にデータ項目が表示されるプロセス。）を表すプロセスボタンを他のプロセスボタンと異なる色で表示したり、既に処理が完了しているプロセスを表すプロセスボタンをグレイアウトで表示したりする構成としてもよい。

取扱タイプボタン８０３に表示されるクリアボタン８０３ａは、プロセスデータ受付領域８０４に入力された各データをクリア（消去）する操作を受け付ける。登録ボタン８０３ｂは、プロセスデータ受付領域８０６に入力された各データを伝票として登録する（すなわち、プロセスフローデータＤＢ１１ｂに登録する）操作を受け付ける。仮保存ボタン８０３ｃは、プロセスデータ受付領域８０６に入力された各データを一旦仮伝票として保存する操作を受け付ける。取消ボタン８０３ｄは、呼び出した伝票を取り消す処理を行うための操作を受け付ける。

プロセスデータ受付領域８０６には、ユーザＸによりヘッダ表示ボタン８０４が押下された場合には、ヘッダに分類されたデータ項目が表示される。なお、本例においては、図８に示すように、ヘッダに分類されたデータ項目のうち、さらに分類された項目（例えば、「基本」や「組織」など。）が分類項目表示領域８０６ａに表示され、ユーザＸにより入力を受け付けるデータ項目がデータ受付領域８０６ｂに表示される。

データ入力画面を表示すると、携帯端末３１は、ユーザＸによるデータの入力を受け付ける（ステップＳ１１０）。

図９は、ユーザＸによりデータの入力を受け付けた場合のデータ入力画面の例を示す説明図である。図９に示すように、データ入力画面におけるデータ受付領域８０６ｂに、ユーザＸにより入力されたデータ（例えば、「第一営業部」。）が表示される。

なお、データ入力画面の表示中に、ユーザＸにより明細ボタン８０５が押下された場合には、携帯端末３１は、プロセスデータ受付領域８０６の表示内容を変更する。

図１０は、明細ボタン８０５が押下された場合のデータ入力画面の例を示す説明図である。図１０に示すように、明細ボタン８０５が押下された場合、明細ボタン８０５が強調表示（例えば、ヘッダボタン８０４よりも太枠で表示）され、プロセスデータ受付領域８０６に表示される内容が、明細に分類されたプロセスデータの項目に変更される。

図１１は、明細ボタンが押下された後に、ユーザＸによりデータの入力を受け付けた場合のデータ入力画面の例を示す説明図である。図１１に示すように、データ入力画面におけるデータ受付領域８０６ｂに、ユーザＸにより入力されたデータ（例えば、「第一営業」や「倉庫Ａ」。）が表示される。

データ入力画面を用いたユーザＸによるデータの入力操作を受け付け、例えば登録ボタン８０３ｂが押下されたことを受け付けると、携帯端末３１は、受け付けたデータを携帯端末管理サーバ１０に送信する（ステップＳ１１１）。

携帯端末管理サーバ１０は、携帯端末３１が受け付けたデータを受信すると、プロセスフローデータを更新するために必要な項目（以下「必須項目」という。）に対応するデータがあるか否かを判定する（ステップＳ１１２）。ここで、必須項目に対応するデータがないと判定すると（ステップＳ１１２のＮ）、携帯端末管理サーバ１０は、所定のデータ不足通知を携帯端末３１に送信する（ステップＳ１１３）。なお、必須項目は、例えばプロセスフローＤＢ１８にあらかじめ登録されているものとする。

一方、必須項目に対応するデータがあると判定すると（ステップＳ１１２のＹ）、携帯端末管理サーバ１０は、特定した処理タイプと、受信したデータとに基づいて、プロセスフローデータ一時保管ＤＢ１６及びプロセスフローＢ１８に記憶されたプロセスフローテーブルＰＴを更新する（ステップＳ１１３）。本例においては、処理タイプ「登録」の場合、受信したデータを対応する記憶領域に登録する処理を行う。なお、例えば処理タイプが「取消」の場合、受信したデータに基づいてマイナス伝票を作成してプロセスフローテーブルＰＴを更新することにより、取消履歴を残す構成となっているものとする。なお、プロセスフローテーブルＰＴの更新方法はこれに限定されず、例えば、携帯端末管理サーバ１０が、プロセスフローデータ一時保管ＤＢ１６に記憶されたプロセスフローテーブルＰＴのみを更新し、所定時機、例えば、プロセスフローＤＢ１８を用いてプロセスフローデータ一時保管ＤＢ１６に記憶されたデータを更新する前に、帳票照会システムの管理者の操作に応じて、プロセスフローデータ一時保管ＤＢ１６の更新内容をプロセスフローＤＢ１８に反映させる構成としてもよい。

プロセスフローテーブルＰＴを更新すると、携帯端末管理サーバ１０は、所定の更新完了通知を携帯端末３１に送信して（ステップＳ１１５）、ここでの処理を終了する。

携帯端末３１は、データ不足通知または更新完了通知を受信したことに応じて、受信した通知に応じた所定の画面を、ユーザＸによるデータ入力の結果を示すデータ入力結果画面として表示する（ステップＳ１１６）。

データ入力結果画面を表示すると、携帯端末３１は、携帯端末管理サーバ１０へのアクセスを終了するか否かを判定する（ステップＳ１１７）。ここで、所定のデータ更新作業継続操作を受け付けたことにより、携帯端末管理サーバ１０へのアクセスを終了しないと判定すると（ステップＳ１１７のＮ）、携帯端末３１は、データ入力結果画面の表示を終了して、ステップＳ１０２の処理に移行する。

一方、例えば所定のアクセス終了操作を受け付けたことにより、携帯端末管理サーバ１０へのアクセスを終了すると判定すると（ステップＳ１１７のＹ）、携帯端末３１は、データ入力結果画面の表示を終了して、ここでの処理を終了する。

以上に説明したように、上述した実施の形態では、ＥＲＰが稼動するサーバであり、ユーザＸが使用する携帯端末３１からの要求に応じて通信ネットワーク４０を介して各種データを提供する携帯端末管理サーバ１０が、複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータを記憶するプロセスフローＤＢ１８と、業務プロセスに関する情報であって、業務プロセスが属するプロセスフローと、業務プロセス毎に発生するプロセスデータに関して許容される処理タイプ（例えば、「登録」、「変更」、「取消」。）とを示すマトリクスデータ（例えば、ＰＦＣＭデータ。）を記憶するマトリクスデータ記憶部（例えば、プロセスフロー制御定義マトリクスＤＢ１９。図４参照。）とを備え、携帯端末３１から、プロセスフローと業務プロセスとを特定可能な処理対象特定情報を受け付け、受け付けた処理対象特定情報に対応する処理タイプをマトリクスデータ記憶部を参照して特定し、携帯端末３１から、ユーザＸによって入力された入力データを受け付け、特定した処理タイプと、受け付けた入力データとに基づいて、プロセスフローＤＢ１８に記憶されたプロセスフローデータ（例えば、プロセスフローテーブルに格納されたプロセスフローデータ。）を更新する構成としているので、ユーザに帳票に関する情報を提供する業務システム（ＥＲＰシステム）において、業務システムの維持やデータの更新に要する負荷を軽減させることができるようになる。

すなわち、ユーザが更新可能なデータか否かを、マトリクスデータを用いて判定することができるようになるため、複数のプログラムを要する従来のシステムと比べてシステムにかかる処理負荷を軽減させることができるようになる。また、データの種類に応じて複数のプログラムを作成する必要がないため、プログラムの作成に要するコストを軽減させることができるようになる。

また、上述した実施の形態では、マトリクスデータ（例えば、ＰＦＣＭデータ。）は、行項目に、複数種類のプロセスフローが設定されており、列項目に、複数種類の業務プロセスが設定されており、各セルに、列項目に設定された業務プロセスが対応する行項目に設定されたプロセスフローに含まれるか否かを示すフラグが設定されており（図４参照）、携帯端末管理サーバ１０が、処理対象特定情報が示すプロセスフローと業務プロセスとの組み合わせに対応するセルに設定されたフラグを参照し、当該フラグが、業務プロセスがプロセスフローに含まれていることを示す場合に（例えば、セルに「黒丸」が設定されている場合。図４参照。）、当該業務プロセスのプロセスデータとして許容される処理タイプ（例えば、業務プロセスと処理タイプとに対応するセルに「黒丸」が設定されている処理タイプ。プロセス「受注」の場合、処理タイプ「登録」と「変更」。図４参照。）を処理対象特定情報に対応する処理タイプとして特定し、特定した処理タイプに応じた入力データ（例えば、処理タイプに応じたデータ入力画面を用いて入力されたデータ。）を受け付ける構成としているので、ＰＦＣＭデータを格納した１つのファイルを用いてプロセスフローデータの管理を行うことができるようになるため、業務システムの維持やデータの更新に要する負荷を軽減させることができるようになる。

また、上述した実施の形態では、携帯端末管理サーバ１０が、受け付けた入力データが、処理対象特定情報が示すプロセスフローにおける業務プロセスに関するデータを更新するために必要な条件としてあらかじめ設定された条件である更新条件（例えば、必須項目に応じたデータがあること。）を満たすか否かを判定し、入力データが更新条件を満たすと判定した場合に、当該入力データを用いてプロセスフローデータを更新する構成としているので、データの入力ミスを事前に防止することができるようになる。

また、上述した実施の形態では、更新条件は、入力データが、処理対象特定情報が示す業務プロセスにあらかじめ設定された必須項目に対応するデータを有していることである構成としているので、複数のプロセスで共有される過誤判定データを用いるような場合と比べ、データの入力ミスの判定を効率的に実行することができるようになる。

なお、上述した実施の形態では特に言及していないが、データベース（例えば、プロセスフローＤＢ１８）が、所定のデータが入力されたことに応じて、プロセスフローテーブルに登録済みのデータのうち少なくとも一部に、データ内容の変更に関する制限を設ける構成としてもよい。すなわち、例えば、プロセスフローＤＢ１８が備えるプロセスフローテーブルＰＴにプロセス「出庫検収」に関するプロセス固有データが登録される前では、プロセスフローテーブルＰＴにおける共通データ部の変更（例えば、データの削除や上書き）が可能であるが、プロセスフローテーブルＰＴにプロセス「出庫検収」に関するプロセス固有データが登録された後では、共通データ部の変更が自由にできないようになる構成としてもよい。この場合、例えば、ユーザが共通データ部の内容を変更する場合に入力すべきパスワードや満たすべき条件などの制限を加える構成とすればよい。このような構成とすることにより、一部のデータの変更に伴うデータ全体における矛盾の発生（すなわち、入力済みのデータの修正に伴う関連データの整合性の欠落）を防止することができるようになる。

なお、上述した実施の形態では特に言及していないが、携帯端末管理サーバ１０は、自己が備える記憶媒体に記憶されている処理プログラム（携帯端末管理プログラム）に従って、上述した各処理（図５、図７参照）を実行する。

本発明によれば、携帯通信端末に帳票に関する情報を提供する業務システム（特に、ＥＲＰシステム）において、データの更新や検索に要する処理負荷を軽減させるのに有用である。

１０ 携帯端末管理サーバ
２０ 中継機
３１〜３Ｎ 携帯端末
４０ 通信ネットワーク
５１，５２，５２ 通信ネットワーク
１００，２００，３００ 統合基幹業務システム
１１０，３１０ 基幹業務サーバ
１２０，２２０ ＤＷＨサーバ
５００ 帳票照会システム

Claims (5)

1. ＥＲＰが稼動するサーバであり、ユーザが使用する携帯端末からの要求に応じて通信ネットワークを介して各種データを提供する携帯端末管理サーバであって、
   複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータを記憶するプロセスフローデータ記憶手段と、
   前記業務プロセスに関する情報であって、業務プロセスが属するプロセスフローと、業務プロセス毎に発生するプロセスデータに関して許容される処理タイプとを示すマトリクスデータを記憶するマトリクスデータ記憶手段と、
   前記携帯端末から、前記プロセスフローと前記業務プロセスとを特定可能な処理対象特定情報を受け付ける処理対象特定情報受付手段と、
   該処理対象特定情報受付手段によって受け付けられた処理対象特定情報に対応する処理タイプを前記マトリクスデータ記憶手段を参照して特定する処理タイプ特定手段と、
   前記携帯端末から、ユーザによって入力された入力データを受け付ける入力データ受付手段と、
   前記処理タイプ特定手段によって特定された処理タイプと、前記入力データ受付手段によって受け付けられた入力データとに基づいて、前記プロセスフローデータ記憶手段に記憶されたプロセスフローデータを更新するプロセスフローデータ更新手段とを含む
   ことを特徴とする携帯端末管理サーバ。
2. 前記マトリクスデータは、
   行項目に、複数種類のプロセスフローが設定されており、
   列項目に、複数種類の業務プロセスが設定されており、
   各セルに、列項目に設定された業務プロセスが対応する行項目に設定されたプロセスフローに含まれるか否かを示すフラグが設定されており、
   前記処理タイプ特定手段は、前記処理対象特定情報が示すプロセスフローと業務プロセスとの組み合わせに対応するセルに設定されたフラグを参照し、当該フラグが、前記業務プロセスが前記プロセスフローに含まれていることを示す場合に、当該業務プロセスのプロセスデータとして許容される処理タイプを前記処理対象特定情報に対応する処理タイプとして特定し、
   前記入力データ受付手段は、前記処理タイプ特定手段によって特定された処理タイプに応じた入力データを受け付ける
   請求項１記載の携帯端末管理サーバ。
3. 前記入力データ受付手段によって受け付けられた入力データが、前記処理対象特定情報が示すプロセスフローにおける業務プロセスに関するデータを更新するために必要な条件としてあらかじめ設定された条件である更新条件を満たすか否かを判定する入力データ判定手段を含み、
   前記プロセスフローデータ更新手段は、前記入力データ判定手段によって前記入力データが前記更新条件を満たすと判定された場合に、当該入力データを用いて前記プロセスフローデータを更新する
   請求項１または請求項２記載の携帯端末管理サーバ。
4. 前記更新条件は、前記入力データが、前記処理対象特定情報が示す業務プロセスにあらかじめ設定された必須項目に対応するデータを有していることである
   請求項３記載の携帯端末管理サーバ。
5. ＥＲＰを稼動させ、ユーザが使用する携帯端末からの要求に応じて通信ネットワークを介して各種データを提供する処理を携帯端末管理サーバに実行させる携帯端末管理プログラムであって、
   複数の業務プロセスを含むプロセスフローに関する各種データを含むプロセスフローデータを記憶するプロセスフローデータ記憶手段と、
   前記業務プロセスに関する情報であって、業務プロセスが属するプロセスフローと、業務プロセス毎に発生するプロセスデータに関して許容される処理タイプとを示すマトリクスデータを記憶するマトリクスデータ記憶手段とを備えた前記携帯端末管理サーバに、
   前記携帯端末から、前記プロセスフローと前記業務プロセスとを特定可能な処理対象特定情報を受け付ける処理対象特定情報受付処理と、
   該処理対象特定情報受付処理にて受け付けた処理対象特定情報に対応する処理タイプを前記マトリクスデータ記憶手段を参照して特定する処理タイプ特定処理と、
   前記携帯端末から、ユーザによって入力された入力データを受け付ける入力データ受付処理と、
   前記処理タイプ特定処理にて特定した処理タイプと、前記入力データ受付処理にて受け付けた入力データとに基づいて、前記プロセスフローデータ記憶手段に記憶されたプロセスフローデータを更新するプロセスフローデータ更新処理とを
   実行させるための携帯端末管理プログラム。

Images