(57)【要約】【課題】事業所毎のルールを変更することなくアドオンプログラムＩＤの採番を可能としたままで、アドオンプログラムＩＤの二重採番、欠落を防止し、システムが異なる他の事業所からもアドオンプログラムの検索を行うことを可能にする。【解決手段】異なる独自ルールにより記述されたアドオンプログラムＩＤをルール毎に格納管理する複数の独自（事業所）ルールＤＢ６５〜６７と、前記異なるルール内の共通な項目について、共通なコードを付与し、該共通コードに対応する前記異なるルールによるアドオンプログラムＩＤを対応させた共通フォーマットを格納管理する共通ルールＤＢ６８とを備える。アドオンプログラムの作成時、独自ルールＤＢを検索することにより作成するアドオンプログラムのアドオンプログラムＩＤを採番し、採番したＩＤと、該ＩＤの他のルールによるＩＤと共通な項目について共通なコードを付与して、共通ルールＤＢに格納する。【選択図】      図１
2006065496.tif 000002
【特許請求の範囲】
【請求項１】
アドオンプログラムＩＤの採番方法において、異なる独自ルールにより記述されたアドオンプログラムＩＤをルール毎に格納管理する複数の独自ルールＤＢと、前記異なるルール内の共通な項目について、共通なコードを付与し、該共通コードに対応する前記異なるルールによるアドオンプログラムＩＤを対応させた共通フォーマットを格納管理する共通ルールＤＢとを備え、アドオンプログラムの作成時、異なるルール毎のある１つのルールに基づいて対応する前記独自ルールＤＢを検索することにより作成するアドオンプログラムのアドオンプログラムＩＤを採番し、該採番したＩＤと、該ＩＤの他のルールによるＩＤと共通な項目について共通なコードを付与して、前記共通ルールＤＢに格納することを特徴とするアドオンプログラムの採番方法。
【請求項２】
前記アドオンプログラムの作成時、前記共通ルールＤＢを共通なコードにより検索して、独自ルールにより作成されたアドオンプログラムかあるか否かを検索可能であることを特徴とする請求項１記載のアドオンプログラムの採番方法。
【請求項３】
アドオンプログラムＩＤの採番システムにおいて、異なる独自ルールにより記述されたアドオンプログラムＩＤをルール毎に格納管理する独自ルールＤＢを有する複数のサーバと、前記異なるルール内の共通な項目について、共通なコードを付与し、該共通コードに対応する前記異なるルールによるアドオンプログラムＩＤを対応させた共通フォーマットを格納管理する共通ルールＤＢを有する共通サーバとを備え、アドオンプログラムの作成時、異なるルール毎のある１つのルールに基づいて対応する前記独自ルールＤＢを検索することにより作成するアドオンプログラムのアドオンプログラムＩＤを採番する手段と、該採番したＩＤと、該ＩＤの他のルールによるＩＤと共通な項目について共通なコードを付与して、前記共通ルールＤＢに格納する手段とを有することを特徴とするアドオンプログラムの採番システム。
【請求項４】
前記アドオンプログラムの作成時、前記共通ルールＤＢを共通なコードにより検索して、独自ルールにより作成されたアドオンプログラムかあるか否かを検索可能であることを特徴とする請求項３記載のアドオンプログラムの採番システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、アドオンプログラムＩＤを事業所毎に採番するアドオンプログラムＩＤの採番方法及びシステムに係り、特に、事業所間のコミュニケーションを容易にし、必要なアドオンが発生した場合、類似アドオンが他事業所に存在するか否かを容易に検索することを可能にしたアドオンプログラムＩＤの採番方法及びシステムに関する。
【背景技術】
【０００２】
一般に、アプリケーションプログラムに新しい機能を追加して作成したアドオンプログラムに対するＩＤの採番は、同一の企業にあっても、各事業所毎に独自のルールを決めて行われている。そして、アドオンプログラムＩＤは、機能によりコード体系を作成しユニークとなるよう追番号を付与し台帳管理されているのが一般的である。そのため、前述したようなアドオンプログラムＩＤの採番は、二重採番、欠番等の不具合を発生させる恐れがあり、また、アドオンプログラムを作成する必要が発生した場合に、他事業所で類似のアドオンプログラムが無いか否かを調査しようとする場合、他事業所でのプログラムＩＤのコード体系が判らないため、調査に工数が掛かるものである。
【０００３】
なお、前述したようなアドオンプログラムＩＤの採番方法に近似する方法関する従来技術として、例えば、特許文献１等に記載された技術が知られている。
【特許文献１】特開２００２−１８９７３５号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
前述したように、従来技術によるアドオンプログラムＩＤの採番は、事業所毎に独自に行われているため、アドオンプログラムを作成する必要が発生した場合に、他事業所で類似のアドオンプログラムが無いか否かを否かを調査しようとしても、他事業所でのプログラムＩＤのコード体系が判らないためため、調査に工数が掛かかり、しかも、二重採番、欠番等の不具合を発生させる恐れがあるという問題点を有している。このため、前述した従来技術は、同一機能を持ったアドオンプログラムを複数の事業所で１から開発してしまう場合を発生させてしまうという問題点を有している。
【０００５】
本発明の目的は、前述した従来技術の問題点を解決し、事業所毎のルールを変更することなくアドオンプログラムＩＤの採番を可能としたままで、アドオンプログラムＩＤの二重採番、欠落を防止することができ、システムが異なる他の事業所からもアドオンプログラムの検索を行うことを可能にしたアドオンプログラムＩＤの採番方法及びシステムを提供することにある。
【課題を解決するための手段】
【０００６】
本発明によれば前記目的は、アドオンプログラムＩＤの採番方法において、異なる独自ルールにより記述されたアドオンプログラムＩＤをルール毎に格納管理する複数の独自ルールＤＢと、前記異なるルール内の共通な項目について、共通なコードを付与し、該共通コードに対応する前記異なるルールによるアドオンプログラムＩＤを対応させた共通フォーマットを格納管理する共通ルールＤＢとを備え、アドオンプログラムの作成時、異なるルール毎のある１つのルールに基づいて対応する前記独自ルールＤＢを検索することにより作成するアドオンプログラムのアドオンプログラムＩＤを採番し、該採番したＩＤと、該ＩＤの他のルールによるＩＤと共通な項目について共通なコードを付与して、前記共通ルールＤＢに格納することにより達成される。
【０００７】
また、前記目的は、アドオンプログラムＩＤの採番システムにおいて、異なる独自ルールにより記述されたアドオンプログラムＩＤをルール毎に格納管理する独自ルールＤＢを有する複数のサーバと、前記異なるルール内の共通な項目について、共通なコードを付与し、該共通コードに対応する前記異なるルールによるアドオンプログラムＩＤを対応させた共通フォーマットを格納管理する共通ルールＤＢを有する共通サーバとを備え、アドオンプログラムの作成時、異なるルール毎のある１つのルールに基づいて対応する前記独自ルールＤＢを検索することにより作成するアドオンプログラムのアドオンプログラムＩＤを採番する手段と、該採番したＩＤと、該ＩＤの他のルールによるＩＤと共通な項目について共通なコードを付与して、前記共通ルールＤＢに格納する手段とを有することにより達成される。
【発明の効果】
【０００８】
本発明によれば、事業所毎のルールを変更することなくアドオンプログラムＩＤの採番を可能とし、アドオンプログラムＩＤの二重採番、欠落を防止することができ、システムが異なる他の事業所からもアドオンプログラムの検索を行うことができるので、アドオンプログラムに関する事業所間のコミュニケーションを容易にすることができる。
【発明を実施するための最良の形態】
【０００９】
図１は本発明の実施形態によるアドオンプログラムＩＤの採番が適用される事業所毎のアドオンプログラムＩＤの体系（事業所独自ルールＤＢフォーマット）の例について説明する図である。
【００１０】
図１（ａ）〜図１（ｃ）は、それぞれ、Ａ、Ｂ、Ｃの各事業所での独自ルールによるアドオンプログラムＩＤのコード体系の例を示しており、各ＩＤコード体系は、図に丸付き数字（１）〜（６）で示す６つのコードから構成される。そして、Ａ事業所のＩＤ体系は、図１（ａ）に示すように、各コードが１バイト１桁の全６桁で構成され、Ｂ事業所のＩＤ体系は、図１（ｂ）に示すように、各コードが２バイト２桁の全１２桁で構成され、Ｃ事業所のＩＤ体系は、図１（ｃ）に示すように、各コードが３バイト３桁の全１８桁で構成されている。
【００１１】
図１（ａ）〜図１（ｃ）に示すコード体系において、コード（１）は、全ての事業所で固有の固定のコード、図示例では、Ｚ、ＺＺ、ＺＺＺを有しており、コード（２）〜（６）に、各事業所で共通の項目を示すコード、及び、事業所毎に異なる項目を示すコードが割り振られている。事業所間でのコードの相違を図１（ｄ）に示しており、共通の項目のコードとして、システムコード、プログラム種別コード、機能コード、シーケンスＮｏ．コードがあり、事業所毎のオリジナル項目のコードとして、主管元、製造元、所有権の各コードがある。
【００１２】
図１（ａ）〜図１（ｃ）に示す各事業所におけるコード（２）のシステムコードには、図１（ｅ）に示すように、生産計画、販売管理、マスタ、共通のシステム区分が記述され、Ａ事業所では、これらのシステム区分をＳ、Ｈ、Ｍ、Ｋとして記述し、Ｂ事業所では、これらのシステム区分をＰＰ、ＳＤ、ＭＳ、ＣＭとして記述し、Ｃ事業所では、これらのシステム区分をＳＥＩ、ＨＡＮ、ＭＡＳ、ＫＹＯとして記述するものとしている。
【００１３】
また、Ａ事業所におけるコード（４）、Ｂ事業所におけるコード（６）及びＣ事業所におけるコード（３）のプログラム種別コードには、図１（ｆ）に示すように、例えば、バッチインプット、ディンプロ、レポートの区分を示すコードが格納可能であり、Ａ事業所では、これらのプログラム種別の区分コードをＢ、Ｏ、Ｒとして記述し、Ｂ事業所では、これらのプログラム種別の区分コードをＢＩ、ＤＹ、ＲＰとして記述し、Ｃ事業所では、これらのプログラム種別の区分コードをＢＡＴ、ＤＩＮ、ＲＥＰとして記述するものとしている。
【００１４】
さらに、Ａ事業所におけるコード（５）、Ｂ事業所におけるコード（４）及びＣ事業所におけるコード（４）の機能コードには、図１（ｇ）に示すように、例えば、日次定型処理、月次定型処理、期末処理、臨時処理の処理区分コードが格納可能であり、Ａ事業所では、これらの処理区分コードをＮ、Ｇ、Ｋ、Ｒとして記述し、Ｂ事業所では、これらの処理区分コードをＤＡ、ＭＯ、ＴＥ、ＥＸとして記述し、Ｃ事業所では、これらの処理区分コードをＮＩＣ、ＧＥＴ、ＫＩＭ、ＲＩＮとして記述するものとしている。
【００１５】
また、Ａ事業所におけるコード（３）には、事業所オリジナルのコードとして、主管元コードが、Ｂ事業所におけるコード（３）には、事業所オリジナルのコードとして、そのプログラムを作成した製造元コードが、Ｃ事業所におけるコード（５）には、事業所オリジナルのコードとして、所有権コードが設定されている。そして、Ａ事業所における主管元コードは、そのプログラムを管理している部署を示すコードであり、図１（ｈ）にその例を示すように、資材調達部、総務部等があり、これらをコードＳ、コードＭとして記述することとしている。また、Ｃ事業所における所有権のコードは、例えば、そのプログラムを外部に依頼して作成した場合に、そのプログラムの所有権が依頼元にあるか依頼先にあるかを示すコードである。
【００１６】
前述したような構成を持つ独自ルールによるアドオンプログラムＩＤは、各事業所に設けられる独自ルールＤＢに格納されて管理される。
【００１７】
図２はアドオンプログラムを作成しようとしてアドオンプログラムＩＤの採番を行う場合の処理について説明する図であり、次に、これについて説明する。図２に示す例は、Ａ事業所において、アドオンプログラムを作成しようとする場合の例である。
【００１８】
アドオンプログラムを作成しようとして、システムを立ち上げると、まず、図２（ａ）に示すようなアドオンプログラムＩＤ採番のための画面が表示される。この画面は、Ａ事業所において、どのようなプログラムを作成するかを指示するためのものであり、システム区分、プログラム種別、機能区分、主管元の項目のそれぞれについて、項目内のどの区分を選択するかを指示することが可能とされている。図２（ａ）に示す例では、システム区分の項目から生産計画の区分が、プログラム種別の項目からバッチインプットの区分が、機能区分の項目から日次定型処理の区分が、主管元の項目から資材調達部の区分が選択されたとしている。この場合、システムは、図１により説明したＡ事業所におけるアドオンプログラムＩＤ体系に従って、コード（１）〜コード（５）による“ＺＳＳＢＮ”をアドオンプログラムＩＤとして採番する。
【００１９】
前述したような区分コードの選択後、採番実行ボタンが操作されると、Ａ事業所におけるシステム内の自動採番処理は、Ａ事業所ルールＤＢを使用して、Ａ事業所ルールに従って既に採番されているアドオンプログラムの検索を開始する。Ａ事業所ルールＤＢには、図２（ｂ）に示すように、多数の既に作成されているアドオンプログラムのＩＤ体系のレコードが格納されており、採番処理は、採番のために選択された前述のコード“ＺＳＳＢＮ”をキーとしてＡ事業所ルールＤＢを検索する。この検索で、対象となるレコードが見つからなかった場合、コード（６）のシーケンスＮｏ．として“１”を採番し、作成しようとするアドオンプログラムのＩＤとして、“ＺＳＳＢＮ１”を生成する。図示例では、検索の結果、“ＺＳＳＢＮ１”、“ＺＳＳＢＮ２”というレコードがＡ事業所ルールＤＢから見つかるので、シーケンスＮｏ．として“３”を採番し、作成しようとするアドオンプログラムのＩＤとして、“ＺＳＳＢＮ３”が生成される。
【００２０】
前述では、Ａ事業所においてアドオンプログラムを作成しようとする場合のアドオンプログラムＩＤの採番について説明したが、他の事業所においても、個々のルールに従って前述した場合と同様に、アドオンプログラムＩＤの採番を行うことができる。説明している例の場合、同様な内容を持つアドオンプログラムであっても、そのアドオンプログラムＩＤは、桁数等が異なったものとなり、そのＩＤが採番されることになる。
【００２１】
本発明の実施形態では、前述したような各事業所毎に異なるアドオンプログラムＩＤ体系（ルールＤＢフォーマット）を共通的に扱うことができるようにするため、共通ＤＢフォーマットを持つＩＤ体系を事業所毎のＤＢフォーマットとは独立して用意することとする。
【００２２】
図３は本発明の実施形態で使用する共通ＤＢフォーマットの構成及び各事業所に共通な項目のコード内の内容を示すコードと共通に使用する統合コードとの対応について説明する図である。
【００２３】
既に説明したように、各事業所で共通の項目として、システムコード、機能コード、プログラム種別コード、シーケンスＮｏ．コードの４つがあるが、本発明の実施形態で使用する共通ＤＢフォーマットは、各事業所ルールＤＢフォーマットとしてのアドオンプログラムＩＤとの対応を管理するものであり、共通ルールＤＢ内に格納される。
【００２４】
この共通ＤＢフォーマットは、図３（ａ）に丸付き数字で示すように、システムコード、機能コード、プログラム種別コードをコード（１）〜コード（３）として、それぞれ２桁（２バイト）で割り当て、シーケンスＮｏ．コードをコード（４）として、５桁（５バイト）で割り当てて、共通ルールでの項目コードとしており、これらの共通ルールのコードによるＩＤで、ある１つのアドオンプログラムを表した場合に、それと同一ということのできる各事業所（図示例では、Ａ〜Ｃの各事業所）でのアドオンプログラムＩＤのコードをコード（５）〜コード（７）として、それぞれ２０桁（２０バイト）で割り当てて構成されている。
【００２５】
なお、前述において、各事業所でのアドオンプログラムＩＤのコードを２０桁（２０バイト）取ってある理由は、既に説明した事業所毎のアドオンプログラム体系が異なり、説明した例では、Ｃ事業所の場合、アドオンプログラムＩＤのコードとして１８桁を要したため、それらのコードを格納することができるようにするためである。
【００２６】
システムコードには、図１（ｅ）に示して説明したように、生産計画、販売管理、マスタ、共通のシステム区分が記述され、これらが事業所毎に異なるコードで記述されるが、共通ＤＢフォーマットでは、前述の各システム区分を、図３（ｂ）に示すように、Ｓ１、Ｓ２、Ｓ３、Ｓ４と記述することとする。また、プログラム種別コードには、図１（ｆ）に示して説明したように、バッチインプット、ディンプロ、レポートの区分を示すコードが事業所毎に異なるコードで格納可能であるが、共通ＤＢフォーマットでは、前述の各プログラム種別の区分を図３（ｃ）に示すように、Ｐ１、Ｐ２、Ｐ３と記述することとする。さらに、機能区分コードには、図１（ｇ）に示して説明したように、日次定型、月次定型、期末処理、臨時処理の各コードが事業所毎に異なるコードで格納可能であるが、共通ＤＢフォーマットでは、前述の各機能区分を、図３（ｄ）に示すように、Ｋ１、Ｋ２、Ｋ３、Ｋ４と記述することとする。
【００２７】
そして、共通ＤＢフォーマットには、そのコード（１）〜コード（３）に各事業所で共通な項目についての統合コードである前述で説明したようなシステムコード、機能コード、プログラム種別コードが格納され、それぞれの事業所でコード（１）〜コード（３）に一致するアドオンプログラムがあれば、対応するアドオンプログラムＩＤがコード（５）〜コード（７）が格納される。また、コード（４）のシーケンスＮｏ．コードについては、各事業所でコード（１）〜コード（３）に一致するアドオンプログラムが複数あり、対応するアドオンプログラムＩＤが複数となった場合に、その数に対応してシーケンスＮｏ．コードが付与されればよい。
【００２８】
図４は共通ルールＤＢ作成処理について説明する図であり、次に、これについて説明する。
【００２９】
共通ＤＢ作成処理は、各事業所毎のルールＤＢと共通ルールＤＢとを通信回線等で接続して行われる処理であり、共通ルールＤＢを管理する部署における作業者により行われるバッチ処理である。
【００３０】
作業者は、各事業所において新たなアドオンプログラムが作成されたことの報告を受けると、適当なときに、その事業所ルールＤＢから新たなアドオンプログラムに対応するアドオンプログラムＩＤを取り込み、そのアドオンプログラムＩＤの共通な項目であるシステムコード、機能コード、プログラム種別コードに対応する統合コードを付与して、共通ルールＤＢに格納する。その際、既に同一の共通な項目を持ったレコードが共通ルールＤＢ内に存在していれば、それに従ってシーケンスＮｏ．を付与する。このような処理を行うことにより、図３（ａ）で説明したような共通ＤＢフォーマットを持ったレコードが作成されて共通ルールＤＢに格納される。
【００３１】
また、共通ＤＢ作成処理は、アドオンプログラムを作成した各事業所のユーザが、登録した事業所ルールＤＢの内容を、各事業所ルールと共通ルールとの対応表を使用して、各事業所ルール体系から共通ルール体系のアドオンプログラムＩＤ作成するようにすることができる。
【００３２】
図５は共通ルールＤＢを使用して各事業所で作成されたアドオンプログラムのアドオンプログラムＩＤを検索する場合の処理について説明する図であり、次に、これについて説明する。この検索処理は、新たにアドオンプログラムを作成しようとするユーザが、同様な機能を持つプログラムが既に他の事業所で作成されていて、そのプログラムを再利用することが可能か否かを調べるために実行される。
【００３３】
アドオンプログラムＩＤの検索のためにシステムを立ち上げると、まず、図５（ａ）に示すようなアドオンプログラムＩＤの検索のための画面が表示される。この画面は、アドオンプログラムＩＤを検索するために、各事業所で共通な項目内の各区分を選択して指示するためのものであり、システム区分、プログラム種別、機能区分の項目のそれぞれについて、項目内のどの区分を選択するかを指示することが可能とされている。
【００３４】
図５（ａ）に示す例では、システム区分の項目から生産計画Ｓ１の区分コードが、プログラム種別の項目からバッチインプットＰ１の区分コードが、機能区分の項目から日次定型処理Ｋ１の区分コードが選択されたとしている。このような区分コードの選択後、検索実行ボタンが操作されると、検索処理は、指定された区分コード“Ｓ１／Ｐ１／Ｋ１”をキーとして共通ルールＤＢを検索する。このような検索の結果、図５（ｂ）に例として示すように、３つのレコードが検索される。そして、この処理を行ったユーザは、同様な機能を持つプログラムがＡ事業所で２つ、Ｂ事業所で２つ、Ｃ事業所で２つ作成されていることを知ることができ、それらのプログラムを再利用することが可能か否かを調べることができる。
【００３５】
図６は前述までに説明した本発明の実施形態によるアドオンプログラムＩＤの採番を行うシステムの構成を示すブロック図であり、次に、これについて説明する。図６において、６１〜６３はＡ、Ｂ、Ｃ各事業所サーバ、６４は共通サーバ、６５〜６７はＡ、Ｂ、Ｃ各事業所ルールＤＢ（独自ルールＤＢ）、６８は共通ルールＤＢ、６９はネットワーク、７１〜７４は端末装置である。
【００３６】
本発明の実施形態によるアドオンプログラムＩＤ採番システムは、図６に示すように、各事業所Ａ、Ｂ、Ｃのそれぞれに設けられる事業所サーバ６１〜６３と共通サーバ６４とが通信回線であるネットワーク６９を介して接続されて構成される。事業所サーバ６１〜６３は、それぞれの事業所で作成されたアドオンプログラムの事業所毎に独自に採番されたＩＤ（図１により説明したフォーマットを有する）を格納管理する事業所ルールＤＢを備えると共に、このＤＢを操作し、また、ネットワーク６９を介して共通サーバ６４に接続することが可能な端末装置７１〜７３が接続されている。また、共通サーバ６４は、各事業所ルールＤＢ６５〜６７内のアドオンプログラムＩＤを管理することができるものであり、図３により説明した共通ＤＢフォーマットを有するレコードを格納した共通ルールＤＢ６８を備えると共に、共通ルール作成等のために使用する端末装置７４が接続されている。
【００３７】
前述において、端末装置７１〜７４は、ディスプレイ装置とキーボード等の入力装置とだけを備えたものであればよいが、ＰＣ等の情報処理機能を備えたものを利用してもよい。また、サーバ６１〜６４は、よく知られているように、ＣＰＵ、ハードディスク装置、主記憶装置を備える情報処理装置であり、各ルールＤＢは、ハードディスク装置に格納されていてよい。また、前述で説明下本発明の実施形態での処理は、主記憶装置にロードされたプログラムを、同様に主記憶装置にロードされたＯＳの制御の下に実行する処理として構成することができる。
【００３８】
なお、前述において、共通サーバ６４は、事業所の１つに設けられていてもよいが、別の管理部門等がある場所に設けられていてもよい。
【００３９】
前述した本発明の実施形態でのアドオンプログラムのアドオンプログラムＩＤを検索する処理を事業所のユーザが行う場合、そのユーザは、各事業所サーバ６１〜６３に制御されている端末装置７１〜７３を使用し、ネットワーク６９を介して共通サーバ６４内の共通ルールＤＢにアクセスして行うことができる。
【００４０】
前述した本発明の実施形態によれば、アドオンプログラムＩＤの採番時に、事業所毎に決められた独自の採番ルールに決められた項目をキーとしてＤＢに保持し画面から事業所ルール項目の分類を入力することにより、入力したキー項目にマッチングしたレコードの既登録状況を元に新たなアドオンプログラムＩＤを自動採番することができる。その際、事業所内ルールでは分類不要な項目であっても、事業所共通ルールで分類が必要となる項目についてはキー項目として分けて登録しておくことができる。
【００４１】
一方、本発明の実施形態によれば、登録された事業所ルールＤＢ内容を、各事業所ルールと共通ルールとの対応表を使用して各事業所ルール体系から共通ルール体系へアドオンプログラムＩＤを変換して、共通ルールＤＢにより管理しており、共通ルール体系に変換された項目をキーにして共通ルールＤＢ検索を行うことができる。そして、検索の結果、同一機能のアドオンプログラムが他事業所で既に採番されていれば、共通ルールＤＢに登録されているレコードの事業所ＩＤ欄（自事業所ＩＤ欄も含む）に事業所ルールＤＢに登録されているアドオンプログラムＩＤを書き込む。
【図面の簡単な説明】
【００４２】
【図１】本発明の実施形態によるアドオンプログラムＩＤの採番が適用される事業所毎のアドオンプログラムＩＤの体系（事業所ルールＤＢフォーマット）の例について説明する図である。
【図２】アドオンプログラムを作成しようとしてアドオンプログラムＩＤの採番を行う場合の処理について説明する図である。
【図３】本発明の実施形態で使用する共通ＤＢフォーマットの構成及び各事業所に共通な項目のコード内の内容を示すコードと共通に使用する統合コードとの対応について説明する図である。
【図４】共通ルールＤＢ作成処理について説明する図である。
【図５】共通ルールＤＢを使用して各事業所で作成されたアドオンプログラムのアドオンプログラムＩＤを検索する場合の処理について説明する図である。
【図６】本発明の実施形態によるアドオンプログラムＩＤの採番を行うシステムの構成を示すブロック図である。
【符号の説明】
【００４３】
６１〜６３  Ａ、Ｂ、Ｃ各事業所サーバ
６４  共通サーバ
６５〜６７  Ａ、Ｂ、Ｃ各事業所ルールＤＢ
６８  共通ルールＤＢ
６９  ネットワーク
７１〜７４  端末装置
【図１】
2006065496.tif 000003
【図２】
2006065496.tif 000004
【図３】
2006065496.tif 000005
【図４】
2006065496.tif 000006
【図５】
2006065496.tif 000007
【図６】
2006065496.tif 000008