以下、本発明を適用した実施の形態を説明する。なお、このような実施の形態はあくまでも本発明の一例であり、これらの実施の形態に本発明が限定されるものではない。
[システム構成]
図1は、実施の形態の管理装置1で電子商取引の仲介及び管理が行われる電子商取引システム(EDIシステム、EDI:Electronic Data Interchange)のシステム構成を示す図である。この図1に示すように、EDIシステムは、実施の形態の管理装置1を含む運営会社の管理システム、商取引を行う得意先の得意先端末装置100、及び、仕入先の仕入先端末装置200を含んで構成されている。この図1に例示するように、運営会社の管理システムは、実施の形態の管理装置1等により、得意先端末装置100からの在庫確認、発注入力、及び、仕入先端末装置200からの発注、注文請等を仲介するようになっている。なお、得意先及び仕入先は、取引先の一例である。
(運営会社のシステム構成)
図2は、運営会社の管理システムの構成図である。この図2に示すように、運営会社の管理システムは、実施の形態の管理装置1で構成されるフロント環境(第1の通信装置の一例)、運営会社の管理用の端末装置80で構成されるバックヤード環境(第2の通信装置の一例)、及び、フロント環境とバックヤード環境を連携する端末装置である連携ツール90とを備えている。
フロント環境は、インターネット8等の広域網を介して、運営会社のユーザの端末装置の他、得意先及び仕入先の各ユーザの端末装置に接続されている。このフロント環境は、取引先(得意先及び仕入先)のユーザ、及び、運営会社のユーザがログインして使用する環境となっている。
また、フロント環境は、インターネット上に公開され、運営会社のユーザ及び運営会社と取引先関係にあるユーザが接続して利用可能となっている。具体的には、運営会社のフロント環境に含まれる実施の形態の管理装置1の記憶部2には、運営会社のユーザ、商品又は役務等の提供先(得意先)のユーザ、及び、商品又は役務等の調達先(仕入先)のユーザのユーザ情報が記憶されている。また、記憶部2には、得意先及び仕入先間の商取引による業務データが一時保管されている。運営会社のユーザ及び運営会社と取引先関係にあるユーザは、管理装置1にアクセスして、記憶部2のユーザデータ(名前及びメールアドレス等、ユーザ情報の一例)及び一時保管されている業務データ(=商取引データ)を利用可能となっている。
なお、取引先数が少ない場合は、接続元を制限してフロント環境を公開してもよい。これにより、より高いセキュリティの下、フロント環境を公開できる。
バックヤード環境は、取引先の外部会社等の接続は許可されておらず、運営会社の権限のあるユーザのみがログインして利用可能な端末装置80で構成された環境となっている。このため、このバックヤード環境の端末装置80は、例えばインターネット等の広域網には接続されていないプライベート網等のネットワーク9又は専用回線を介して、運営会社の権限のあるユーザの端末装置と接続されることが好ましい。
運営会社の権限のあるユーザは、このバックヤード環境の端末装置80の通信インターフェース部81を介して、データ管理用の業務データ(商取引データ)が記憶された記憶部(商取引業務データ管理データベース)82にアクセス可能となっている。
連携ツール90は、定期的又は不定期にフロント環境の記憶部2及びバックヤード環境の記憶部82にアクセスし、フロント環境の記憶部2に記憶された一時保管用の業務データと、バックヤード環境の記憶部82に記憶されたデータ管理用の業務データとの同期を図っている。換言すると、連携ツール90は、記憶部2の一時保管用の業務データ、及び、記憶部82のデータ管理用の業務データが同じデータとなるように、定期的又は不定期に両者の連携を図っている。
このようにフロント環境とバックヤード環境を分離することで、いずれか一方の環境がダウンしても、他方の環境で業務を継続することができる。また、例えばフロント環境は利用人数が多いため、高スペックの端末装置で構築し、バックヤード環境は、限られたユーザがアクセスできれば良いため、低スペックの端末装置で構築する等のように、想定される各環境の利用人数に応じたスペックで、それぞれの環境を構築でき、リソースを最適化することができる。
また、例えばフロント環境の記憶部2(データベース)には、各取引先のユーザの個人情報が登録されるため、特殊な暗号化処理を施して登録する等のように、各環境のデータベース(記憶部2又は記憶部82)に保存されるデータの性質に応じた運用とすることができる。
また、連携ツール90による、特定通信のみ(上述のデータの同期)を許可することで、フロント環境及びバックヤード環境の間にインフラ的な境界を設けて分断でき、セキュリティを強化することができる。
(管理装置のハードウェア構成)
次に、図3に、運営会社の管理装置1のハードウェア構成を示す。上述のように、この管理装置1は、例えばインターネット8等の広域網を介して得意先端末装置100及び仕入先端末装置200に接続されている。このような管理装置1は、記憶部2、制御部3、及び通信インターフェース部4を備えている。通信インターフェース部4は、ネットワーク8を介して、得意先端末装置100及び仕入先端末装置200に接続されている。また、通信インターフェース部4は、ネットワーク8及び連携ツール90を介してバックヤード環境の端末装置80に接続されている。
記憶部2としては、例えばROM(Read Only Memory)、RAM(Random Access Memory)、HDD(Hard Disk Drive)又はSSD(Solid State Drive)等の記憶装置を用いることができる。記憶部2には、WebEDI取引先分類マスタ11、WebEDI取引先マスタ12、WebEDIユーザグループマスタ13及びWebEDIユーザマスタ14が記憶されている。また、記憶部2には、商取引管理を行うための管理プログラムの他、上述のユーザデータ及び一時保管用の業務データ(商取引データ)が記憶されている。
図4は、WebEDI取引先分類マスタ11の一例を示す図である。この図4に示すように、WebEDI取引先分類マスタ11は、「得意先」及び「仕入先」が取引先分類として記憶されている。
図5は、WebEDI取引先マスタ12の一例を示す図である。この図5に示すように、WebEDI取引先マスタ12には、取引先分類及び取引先となる会社毎に、ユーザ登録可能なユーザ数の上限値、及び、取引先となる会社がEDIシステムを利用可能であるか否かを示すステータス情報が記憶されている。この図5の例は、得意先となるA会社は、登録可能なユーザ数の上限値が「3人」で、EDIシステムの利用の可否を示すステータス情報が「有効」に設定された例を示している。
また、この図5の例は、仕入先となるX会社は、登録可能なユーザ数の上限値が「8人」で、EDIシステムの利用の可否を示すステータス情報が「無効」に設定された例を示している。後述するが、実施の形態の管理装置1は、ステータス情報が「無効」とされた会社の各ユーザのユーザID有効期限を、有効期限切れの日付に更新する。これにより、会社の対するステータス情報を「無効」とすることで、その会社の各ユーザのEDIシステムの利用を、一括して利用不可に制限可能となっている。
図6は、WebEDIユーザグループマスタ13の一例を示す図である。取引先分類、ユーザグループ、運営会社管理可否情報、及び、取引先管理可否情報が記憶されている。
このうち、ユーザグループは、運営会社、得意先及び仕入先の業務(職務)の各ユーザを示している。すなわち、「運営会社管理者」のユーザグループは、運営会社で管理業務を行っている各ユーザで構成されるグループを示している。また、「得意先担当者」のユーザグループは、得意先で担当者となっている各ユーザで構成されるグループを示している。
また、「仕入先見積担当者」のユーザグループは、仕入先で見積業務を担当する各ユーザで構成されるグループを示している。また、「仕入先実作業担当者」のユーザグループは、仕入先で実作業を担当する各ユーザで構成されるグループを示している。
運営会社管理可否情報は、運営会社側でユーザ登録の管理を行うことが可能なユーザグループを示す情報である。この図6の例の場合、運営会社は、運営会社自身、得意先及び仕入先の全てのユーザグループに対するユーザ登録の管理(ユーザ登録の権限)が可能となっている。
また、実施の形態の管理装置1では、ユーザ登録の権限を、得意先及び仕入先の所望のユーザグループに対して委託可能(設定可能)となっている。このユーザ登録の権限の委託の有無を示す情報が、取引先管理可否情報である。図6の例は、運営会社側が管理装置1を介して、得意先の「得意先管理者」及び「得意先担当者」の各ユーザグループに対する、ユーザ登録の権限を委託(設定)した例を示している。すなわち、この場合の登録権限を有するユーザは得意先管理者で、「得意先管理者」及び「得意先担当者」の各ユーザグループに対してのみ、ユーザ登録が可能であることを示している。
また、図6の例は、運営会社側が仕入先の仕入先管理者に対して、仕入先の「仕入先実作業担当者」のユーザグループに対するユーザ登録の権限を委託(設定)した例を示している。すなわち、この場合の登録権限を有するユーザは仕入先管理者で、この仕入先管理者は、「仕入先実作業担当者」のユーザグループに対してのみ、ユーザ登録が可能であることを示している。
なお、この例では、ユーザ登録の権限は、取引先のユーザグループ毎に設定されていることとして説明を行うが、取引先単位でユーザ登録の権限を設定してもよい。
図7は、上述のユーザデータが登録されたWebEDIユーザマスタ14の一例を示す図である。この図7に示すように、WebEDIユーザマスタ14には、運営会社及び各取引先のユーザグループに所属する各ユーザのユーザ識別情報(ユーザID)、ユーザ名、及び、ユーザID有効期限が記憶されている。ユーザID有効期限は、EDIシステムを利用可能な日付を示す情報である。
この図7の例は、運営会社の「運営会社管理者」のユーザグループに所属するユーザIDが「UK01」の「運営会社管理者UK1」のユーザ、及び、ユーザIDが「UK02」の「運営会社管理者UK2」のユーザのユーザID有効期限は、それぞれ「2030年3月31日」であることを示している。また、この図7の例は、A会社の「得意先担当者」のユーザグループに所属するユーザIDが「AT01」の「A会社担当者AT1」のユーザ、及び、ユーザIDが「AT03」の「A会社担当者AT3」のユーザのユーザID有効期限は、それぞれ「2030年3月31日」であるが、ユーザIDが「AT02」の「A会社担当者AT2」のユーザのユーザID有効期限は、「2010年1月1日」で有効期限切れとなっていることを示している。
同様に、この図7の例は、X会社の「X会社管理者XK1」及び「X会社見積担当者XMT1」のユーザのユーザID有効期限は、共に「2022年3月1日」で有効期限切れとなっていることを示している。
次に、図8は、運営会社及び各取引先のユーザグループのユーザに対して管理装置1から提供される各種画面を一覧的に示す図である。この図8に示すように、「運営会社管理者」のユーザグループの各ユーザに対しては、「取引先マスタメンテナンス画面」、「運営会社ユーザマスタメンテナンス画面」及び「運営会社用取引先ユーザマスタメンテナンス画面」が管理装置1から提供される。また、「運営会社担当者」のユーザグループの各ユーザに対しては、「運営会社業務画面」が管理装置1から提供される。
また、「得意先管理者」のユーザグループのユーザに対しては、「取引先用取引先ユーザマスタメンテナンス画面」が、得意先担当者のユーザグループのユーザに対しては、「得意先業務画面」が、それぞれ管理装置1から提供される。
また、「仕入先管理者」のユーザグループのユーザに対しては、「取引先用取引先ユーザマスタメンテナンス画面」が、「仕入先見積担当者」のユーザに対しては、「仕入先の見積業務画面」が、「仕入先実作業担当者」のユーザに対しては、「仕入先の実作業画面」が、それぞれ管理装置1から提供される。
さらに具体的に説明すると、図9は、「運営会社管理者」のユーザグループの各ユーザに対して提供される「取引先マスタメンテナンス画面」の画面例を示す図である。この図9に示す「取引先マスタメンテナンス画面」は、EDIシステムを利用する取引先の登録を行う画面である。運営会社側は、この「取引先マスタメンテナンス画面」を介して、取引先分類、取引先名、ユーザ数上限、及び、ステータスを登録する。
取引先分類としては、「仕入先」又は「得意先」が選択されて登録される。取引先名は、例えば「X会社」等の取引先名が登録される。ユーザ数上限としては、EDIシステムの利用を可能とするユーザ数の上限値を登録する。ステータスは、EDIシステムの利用を可能とするか否か(有効又は無効)を示すステータス情報を登録する。この図9の例は、X会社のステータス情報が「無効」とされ、X会社はEDIシステムの利用が不可とされた例である。
図10は、「運営会社管理者」のユーザグループの各ユーザに対して提供される「運営会社ユーザマスタメンテナンス画面」の画面例を示す図である。この図10に示すように、「運営会社ユーザマスタメンテナンス画面」は、「運営会社側のユーザ」をユーザグループに分類してユーザ情報の登録を行う画面である。運営会社側のユーザは、この「運営会社ユーザマスタメンテナンス画面」を介して、ユーザグループ(運営会社管理者又は運営会社担当者)、ユーザID、ユーザ名、初期パスワード、ユーザID有効期限の登録を行う。
図11は、「運営会社管理者」のユーザグループの各ユーザに対して提供される「運営会社用取引先ユーザマスタメンテナンス画面」の画面例を示す図である。この図11に示すように、「運営会社用取引先ユーザマスタメンテナンス画面」は、「運営会社側で取引先のユーザ」をユーザグループに分類してユーザ情報の登録を行う画面である。運営会社側のユーザは、この「運営会社用取引先ユーザマスタメンテナンス画面」を介して、取引先分類、取引先名、ユーザグループ、ユーザID、ユーザ名、初期パスワード、ユーザID有効期限の登録を行う。取引先分類は、仕入先又は得意先が選択される。取引先名は、例えば「X会社」又は「Y会社」等の取引先名が選択される。ユーザグループは、例えば「仕入先担当者」又は「得意先管理者」等の上述のユーザグループが選択される。
図12は、「得意先管理者」又は「仕入先管理者」のユーザグループの各ユーザに対して提供される「取引先用取引先ユーザマスタメンテナンス画面」の画面例を示す図である。このうち、図12(a)は、「得意先管理者」に対して提供される「取引先用取引先ユーザマスタメンテナンス画面」の画面例であり、図12(b)は、「仕入先管理者」に対して提供される「取引先用取引先ユーザマスタメンテナンス画面」の画面例である。
「得意先管理者」は、図12(a)に示すように、「取引先用取引先ユーザマスタメンテナンス画面」を介して、自社のユーザを所属させるユーザグループを選択し、ユーザID、ユーザ名、初期パスワード、及び、ユーザID有効期限を登録する。
同様に、「仕入先管理者」は、図12(b)に示すように、「取引先用取引先ユーザマスタメンテナンス画面」を介して、自社のユーザを所属させるユーザグループを選択し、ユーザID、ユーザ名、初期パスワード、及び、ユーザID有効期限を登録する。なお、この図12(b)の例は、ユーザグループとして「仕入先実作業担当者」のユーザグループが選択された例である。
(管理装置の機能構成)
次に、図3に示す管理装置1の制御部3は、記憶部2に記憶されている管理プログラムを実行することで、通信制御部21、ユーザ管理権限設定部22、データ生成部23、判別部24、記憶制御部25、表示画面生成部26、ステータス設定部27、及び、通知制御部28として機能する。
通信制御部21は、ネットワーク8を介して電子商取引を行う各取引先の端末装置100、200の間における各種商取引データの送受信を仲介するように通信部の一例となる通信インターフェース部4を制御する。ユーザ管理権限設定部22は、正規のユーザ権限を有する有効期限を示す有効期限情報を含む所定のユーザ情報の登録又は編集を行うユーザ管理権限を、前記取引先に設定する。「編集」は、ユーザ情報の修正及び削除等のデータの内容の変更及び削除等を行う行為を含む概念である。
表示画面生成部26は、取引先の端末装置100、200を介してユーザの新規登録又は編集(削除を含む)が要求された際に、ユーザの新規登録等を要求した取引先の端末装置に、通信インターフェース部4を介して送信される、ユーザの新規登録等を行うためのユーザ登録画面(図12(a)及び図12(b)に示す取引先用取引先ユーザマスタメンテナンス画面)を生成する。
判別部24は、ユーザの新規登録等の要求を行った取引先が、ユーザ管理権限が設定された取引先であるか否かを判別する。記憶制御部25は、ユーザの新規登録等の要求を行った取引先が、ユーザ管理権限が設定された取引先であることを示す判別結果が判別部24から得られた場合に、取引先毎に設定された、各ユーザの有効期限情報(ユーザID有効期限情報)を含むユーザ情報が記憶された記憶部2のWebEDIユーザマスタ14に対して、新規登録等が行われたユーザのユーザID有効期限情報を含むユーザ情報を記憶させる。
なお、ユーザ管理権限設定部22は、各取引先の管理者又は担当者で構成されるユーザグループ毎にユーザ管理権限を設定する。また、ユーザ管理権限設定部22は、登録可能なユーザ数の上限数を取引先毎に設定する。
また、ステータス設定部27は、各取引先に対する取引の有効又は無効を示すステータスを設定する。記憶制御部25は、各取引先のユーザのユーザ情報及びユーザID有効期限情報と共に、取引先毎に、ステータス設定部27により設定されたステータスを示すステータス情報を付加して記憶部2のWebEDI取引先マスタ12に記憶する。
また、記憶制御部25は、ステータス設定部27により、取引先に対して「無効」のステータスが設定された場合、WebEDI取引先マスタ12に記憶されている、取引が無効とされた取引先のステータス情報を、「無効」のステータス情報に更新処理する。また、これと共に、記憶制御部25は、WebEDIユーザマスタ14に記憶されている、取引が「無効」とされた取引先のユーザのユーザID有効期限情報を、有効期限切れの日付に更新処理する。
データ生成部23は、図8~図12を用いて説明した各種画面を介して入力されたユーザグループ、ユーザID、初期パスワード、ユーザID有効期限等を含むユーザデータを生成する。
通知制御部28は、記憶部2に記憶されたユーザデータに含まれる電子商取引を正規に利用するユーザ権限の有効期限を示す有効期限情報(ユーザID有効期限情報)に基づいて、正規のユーザ権限が有効期限切れとなる日付の所定日数前の日付から、正規のユーザ権限が有効期限切れとなることを示す警告を通知する。「所定日数前の日付」としては、例えば有効期限切れとなる日付から30日前等のように、予め設定されている。
また、「警告の通知」としては、表示部に警告メッセージを表示してもよいし、有効期限切れとなる期日が近いことを示す電子音又は音声メッセージ等の音声出力を用いてもよい。また、「警告の通知」としては、有効期限切れとなる期日が近いことを示す文章が記述された電子メール又はショートメッセージ等の電子文章を送信してもよい。
以下、電子商取引を正規に利用するユーザ権限の有効期限切れを示す「警告の通知」としては、有効期限切れとなる期日が近いユーザが存在することを示す警告メッセージ、又は、有効期限切れとなったユーザが存在することを示す警告メッセージを表示することとして説明を進める。
また、通知制御部28は、有効期限切れとなる旨の警告メッセージの他、この警告メッセージを将来的に不要とするか否かの、「警告の無効化」を指定するための警告無効選択オブジェクト(図30の「警告を無効化する」との文字とチェックボックスが表示される領域)を表示する。この際、通知制御部28は、正規のユーザ権限が有効期限切れとなる日付の、例えば30日前等の予め設定された所定日数前の日付から警告無効選択オブジェクトの表示を行う。さらに、通知制御部28は、警告の対象となっているユーザの有効期限の延長登録が行われた場合、警告無効選択オブジェクトを、例えば次年度の警告期間までの間等の所定期間、非表示とする。
また、記憶制御部25は、警告無効選択オブジェクトを介して警告の無効化が指定された場合、記憶部2に記憶されている、警告の対象となっているユーザのユーザ情報に含まれる、警告を行うか否かを示す警告情報を、将来的に警告を行わないことを示す「無効」に更新処理する。
また、通知制御部28は、警告の対象となっているユーザの有効期限の延長登録の際に、例えば「365日」等の所定の上限値を超える有効期限が入力された場合、「ユーザID有効期限の設定上限を超えています」等の所定のエラー通知(エラーメッセージの表示)を行う。なお、所定のエラー通知は、上述のように電子音又は音声メッセージでもよい。
また、通知制御部28は、延長登録が行われることなく、有効期限切れとなったユーザが存在する旨の警告の通知を行うと共に、上述の警告無効選択オブジェクトを表示する。そして、通知制御部28は、警告の対象となっているユーザの有効期限の延長登録が行われた場合、警告無効選択オブジェクトを非表示とする。記憶制御部25は、有効期限の延長登録が行われることなく、警告無効選択オブジェクトを介して警告の無効化が指定された場合、記憶部2に記憶されている、警告の対象となっているユーザのユーザ情報に含まれる、警告を行うか否かを示す警告情報を、将来的に警告を行わないことを示す「無効」に更新処理する。
また、通知制御部28は、警告の通知として、
(警告パターン0)正規のユーザ権限が有効期限切れとなるユーザに対する通知、
(警告パターン1)正規のユーザ権限が有効期限切れとなるユーザの管理者に対する通知、
(警告パターン2)正規のユーザ権限が有効期限切れとなるユーザが取引先のユーザである場合に、取引先の管理者に対する通知、
(警告パターン3)正規のユーザ権限が有効期限切れとなるユーザが取引先のユーザである場合に、全取引先を管理している運営会社の運営会社管理者に対する通知、
(警告パターン4)正規のユーザ権限が有効期限切れとなるユーザが取引先のユーザである場合に、取引先の管理者、及び、全取引先を管理している運営会社の運営会社管理者に対する通知、
のうち、いずれか一つの警告パターン又は複数の警告パターンの通知を行う。これらの警告パターンは、予め一つ又は複数が設定されており、通知制御部28は、この設定情報に基づいて、設定された警告バターンの警告を行う。
また、通知制御部28は、全取引先を管理している運営会社の運営会社管理者のユーザ情報に含まれる、正規のユーザ権限の有効期限の設定が必須か否かを示す有効期限設定有無情報が、有効期限の非設定を示す場合、警告を非通知とする。この有効期限設定有無情報(有効期限必須フラグ)を「FALSE」とすると、有効期限を設定しないユーザ登録を許す設定が可能となる。また、運営会社については、無期限で取引先管理・ユーザ管理業務を行うことが通常に想定されるため、有効期限設定有無情報(有効期限必須フラグ)をOFFにする、という運用の選択が可能となる。なお、有効期限を設定しなかった場合、WebEDIユーザマスタ14の有効期限は「NULL」となる(図47参照)。
また、記憶部2に記憶されているユーザ情報には、正規のユーザ権限を有する有効期限を示す前記有効期限情報と共に、前記警告の通知を行う期間である警告期間を示し、電子商取引のシステム全体で一意に設定され、又は、所定のグループ単位で設定され、或いは、ユーザ毎に設定された警告期間情報が含まれている。記憶制御部25は、指定された有効期限を示す有効期限情報、及び、指定された警告期間を示す警告期間情報を、対象となるユーザのユーザ情報に含めて、記憶部2に記憶する。
(運営会社による自社の新規ユーザの登録動作)
次に、このような運営会社の管理装置1における、運営会社による自社の新規ユーザの登録動作を図13のフローチャートを用いて説明する。なお、以下、新規ユーザの「登録」を例に説明を行うが、ユーザ情報の修正又は削除等の「編集」を行う場合も、下記と同様の動作となる。このため、ユーザ情報の修正又は削除等の編集時の動作も、下記の説明を参照されたい。この図13のフローチャートの各処理は、管理装置1の制御部3により、記憶部2に記憶されている管理プログラムに基づいて実行される。すなわち、運営会社の新規ユーザの登録を行うユーザは、管理者端末装置を介して管理装置1にログイン要求を行う。これにより、図13のフローチャートがスタートとなり、ステップS1から順に処理が実行される。
ステップS1では、管理装置1の表示画面生成部26が、図14(a)に例示するログイン画面を生成する。通信制御部21は、このログイン画面を、ログイン要求が行われた運営会社のユーザの管理者端末装置に送信する。ログイン要求を行った運営会社のユーザは、管理者端末装置の表示画面に表示されるログイン画面に対して、ユーザID及びパスワードを入力する。この入力されたユーザID及びパスワードは、管理装置1に送信される。
管理装置1の判別部24は、ログイン画面を介して入力されたユーザIDに基づいて、図14(b)に例示するWebEDIユーザマスタ14のユーザID有効期限を参照する(ステップS2)。そして、判別部24は、本日の日付が、ユーザID有効期限として設定されている日付を超過しているか否かを判別することで、入力されたユーザIDが有効期限切れであるか否かを判別する(ステップS3)。判別部24により、入力されたユーザIDが有効期限切れであると判別された場合(ステップS3:Yes)、そのユーザはユーザ登録を行う権限は無いため、そのまま図13のフローチャートの処理が終了となる。
これに対して、入力されたユーザIDが有効期限内であると判別された場合(ステップS3:No)、判別部24は、運営会社ユーザマスタメンテナンス画面の起動要求の有無を判別する(ステップS4)。そして、運営会社ユーザマスタメンテナンス画面の起動要求を検出した場合(ステップS4:Yes)、判別部24は、ステップS5において、ユーザIDに基づいて図14(c)に示すWebEDIユーザマスタ14を参照することで、そのユーザが、新規ユーザの登録権限を有する「運営会社管理者」のユーザグループのユーザであるか否かを判別する。「運営会社管理者」のユーザグループのユーザではない場合(ステップS5:No)、そのユーザはユーザ登録を行う権限は無いため、そのまま図13のフローチャートの処理が終了となる。
「運営会社管理者」のユーザグループのユーザである場合(ステップS5:Yes)、ステップS6に処理が進む。ステップS6では、判別部24が図15(a)に示すようにWebEDIユーザグループマスタ13を参照し、取引先分類が未設定で運営会社が管理可能なユーザグループを特定する。
すなわち、取引先分類が未設定のユーザグループは、得意先又は仕入先のいずれかのユーザグループではなく、運営会社のユーザグループであることを意味する。このため、判別部24は、取引先分類が未設定となっている運営会社のユーザグループを検出する。そして、判別部24は、WebEDIユーザグループマスタ13の運営会社管理可否情報を参照することで、取引先分類が未設定となっている運営会社のユーザグループのうち、ユーザ登録を行うことが可能なユーザグループ(運営会社内におけるユーザ管理が可能なユーザグループ)を特定する。図15(a)の例は、「運営会社管理者」及び「運営会社担当者」の各ユーザグループに対して、新規ユーザの登録が許可されている例である。
次に、ステップS7では、表示画面生成部26は、図15(b)に例示する運営会社ユーザマスタメンテナンス画面を生成し、通信制御部21が、この運営会社ユーザマスタメンテナンス画面を管理者端末装置に送信する。
管理者端末装置のユーザは、図15(b)に例示する運営会社ユーザマスタメンテナンス画面に基づいて、ユーザ登録が許可されているユーザグループである、「運営会社管理者」又は「運営会社担当者」のいずれかのユーザグループを選択する。また、管理者端末装置のユーザは、図15(b)に例示する運営会社ユーザマスタメンテナンス画面に対して、新規にユーザ登録を行うユーザのユーザID、ユーザ名、初期パスワード、及び、ユーザID有効期限を入力して登録操作を行う。
これにより、運営会社ユーザマスタメンテナンス画面を介して入力されたユーザグループ、ユーザID、ユーザ名、初期パスワード、及び、ユーザID有効期限の各情報が、管理者端末装置から管理装置1に送信され登録要求が行われる。この登録要求が管理装置1で受信されると、管理装置1のデータ生成部23は、登録操作が行われたものと判別し(ステップS8:Yes)、管理者端末装置から受信したユーザグループ、ユーザID、ユーザ名、初期パスワード、及び、ユーザID有効期限を含む、WebEDIユーザマスタ14の明細データ(レコード)を生成する。
記憶制御部25は、ステップS9において、データ生成部23により生成された明細データ(レコード)を、図15(c)に示すようにWebEDIユーザマスタ14に追加して記憶させる。これにより、例えば運営会社の「運営会社担当者」のユーザグループに、ユーザIDが「UT99」でユーザ名が「運営会社担当者UT99」のユーザが、「2030年12月31日」をユーザID有効期限として新たに登録される。
(運営会社のユーザによる、仕入先の新規ユーザの登録動作)
次に、このような運営会社の管理装置1における、運営会社のユーザによる仕入先の新規ユーザの登録動作を図16のフローチャートを用いて説明する。この図16のフローチャートの各処理は、管理装置1の制御部3により、記憶部2に記憶されている管理プログラムに基づいて実行される。
すなわち、仕入先の新規ユーザの登録を行う運営会社のユーザは、管理者端末装置を介して管理装置1にログイン要求を行う。これにより、図16のフローチャートがスタートとなるが、ログイン画面に入力されたユーザIDに基づいてユーザ有効期限の超過の有無を判別するまでの、ステップS1~ステップS3の動作は、図13のフローチャートのステップS1~ステップS3の動作と同じ動作である。このため、ステップS1~ステップS3の詳細な動作の説明は、図13のフローチャートのステップS1~ステップS3の動作の説明を参照されたい。
次に、ステップS3でユーザID有効期限切れではないものと判別されると(ステップS3:No)、図16のフローチャートのステップS11に処理が進む。ステップS11では、判別部24が、運営会社のユーザからの、図17(a)に例示する運営会社用取引先ユーザマスタメンテナンス画面の起動要求の有無を判別する。
運営会社用取引先ユーザマスタメンテナンス画面の起動要求を検出すると(ステップS11:Yes)、判別部24は、ステップS5において、ユーザIDに基づいてWebEDIユーザマスタ14を参照し、そのユーザが、新規ユーザの登録権限を有する「運営会社管理者」のユーザグループのユーザであるか否かを判別する。「運営会社管理者」のユーザグループのユーザではない場合(ステップS5:No)、そのユーザはユーザ登録を行う権限は無いため、そのまま図16のフローチャートの処理が終了となる。
「運営会社管理者」のユーザグループのユーザである場合(ステップS5:Yes)、ステップS12に処理が進む。ステップS12では、表示画面生成部26が、図17(a)に例示する運営会社用取引先ユーザマスタメンテナンス画面を生成し、通信制御部21が、この運営会社用取引先ユーザマスタメンテナンス画面を管理者端末装置に送信する。
管理者端末装置のユーザは、図17(b)に示すように、運営会社用取引先ユーザマスタメンテナンス画面に基づいて、「仕入先」等の取引先分類を選択する。また、管理者端末装置のユーザは、図17(c)に示すように、運営会社用取引先ユーザマスタメンテナンス画面に基づいて、「Y会社」等の取引先名を入力する。また、管理者端末装置のユーザは、図17(d)に示すように、運営会社用取引先ユーザマスタメンテナンス画面に基づいて、ユーザグループ、ユーザID、ユーザ名、初期パスワード、及び、ユーザID有効期限を入力し、登録操作を行う。
これにより、運営会社用取引先ユーザマスタメンテナンス画面を介して入力された取引先分類、取引先、ユーザグループ、ユーザID、ユーザ名、初期パスワード、及び、ユーザID有効期限の各情報が、管理者端末装置から管理装置1に送信され、登録要求が行われる。この登録要求が管理装置1で受信されると、管理装置1の判別部24は、登録操作を行われたものと判別する(ステップS13:Yes)。そして、判別部24は、ステップS14において、図18(a)に示すWebEDI取引先マスタ12を参照し、入力された取引先に対するユーザ数の上限値を検出する。この図18(a)の例の場合、ユーザ数の上限値は「10人」に設定されている。
また、判別部24は、図18(b)に示すWebEDIユーザマスタ14を参照することで、現在、新規ユーザのユーザ登録を行おうとしている取引先の、現在の有効ユーザ数を検出する。この図18(b)の例は、現在、新規ユーザのユーザ登録を行おうとしている取引先はY会社であり、このY会社の現在の有効ユーザ数は「3人」であることを示している。
そして、この例の場合、Y会社のユーザ数の上限値は「10人」であり、現在の有効ユーザ数は「3人」であるため、新規のユーザを登録しても、Y会社のユーザ数の上限値を超過することはない。このため、判別部24は、ユーザ数の上限値は超過しないと判別する(ステップS14:No)。これにより、データ生成部23は、管理者端末装置から受信した取引先分類、取引先、ユーザグループ、ユーザID、ユーザ名、初期パスワード、及び、ユーザID有効期限を含む、WebEDIユーザマスタ14の明細データ(レコード)を生成する。
なお、後述するが、新規のユーザを登録することで、取引先に対して設定されているユーザ数の上限値を超過する場合(ステップS14:Yes)、表示画面生成部26は、図23(a)に示すように、例えば「ユーザ数上限を超えてユーザを追加できません」等のエラーメッセージを表示した運営会社用取引先ユーザマスタメンテナンス画面を生成する。そして、通信制御部21が、このエラーメッセージを表示した運営会社用取引先ユーザマスタメンテナンス画面を、運営管理者端末装置に送信する。これにより、運営管理者端末装置のユーザは、これ以上の新規なユーザのユーザ登録はできないことを認識し、不要なユーザの削除、又は、ユーザ数の上限値の追加拡大操作等を行うこととなる。
次に、ステップS9において、記憶制御部25は、データ生成部23により生成された明細データ(レコード)を、図18(c)に示すようにWebEDIユーザマスタ14に追加して記憶させる。これにより、例えばY会社の「仕入先実作業担当者」のユーザグループに、ユーザIDが「YJT99」でユーザ名が「Y会社実作業担当者YJT99」のユーザが、「2030年12月31日」をユーザID有効期限として新たに登録される。
(取引先による自社の新規ユーザの登録動作)
次に、取引先の一例である仕入先の会社が自社の新規ユーザの登録を行う際の管理装置1の動作を図19のフローチャートを用いて説明する。この図19のフローチャートの各処理は、管理装置1の制御部3により、記憶部2に記憶されている管理プログラムに基づいて実行される。すなわち、新規ユーザの登録を行う仕入先の会社のユーザは、仕入先端末装置200を介して管理装置1にログイン要求を行う。これにより、図19のフローチャートがスタートとなり、ステップS21から順に処理が実行される。
ステップS21では、管理装置1の表示画面生成部26が、図20(a)に例示するログイン画面を生成する。通信制御部21は、このログイン画面を、ログイン要求が行われた仕入先の会社のユーザの仕入先端末装置200に送信する。ログイン要求を行った仕入先の会社のユーザは、仕入先端末装置200の表示画面に表示されるログイン画面に対して、ユーザID及びパスワードを入力する。この入力されたユーザID及びパスワードは、管理装置1に送信される。
管理装置1の判別部24は、ログイン画面を介して入力されたユーザIDに基づいて、図20(b)に例示するWebEDIユーザマスタ14のユーザID有効期限を参照する(ステップS22)。そして、判別部24は、本日の日付が、ユーザID有効期限として設定されている日付を超過しているか否かを判別することで、入力された仕入先の会社のユーザのユーザIDが有効期限切れであるか否かを判別する(ステップS23)。判別部24により、入力されたユーザIDが有効期限切れであると判別された場合(ステップS23:Yes)、その仕入先の会社のユーザはユーザ登録を行う権限は無いため、そのまま図19のフローチャートの処理が終了となる。
これに対して、入力されたユーザIDが有効期限内であると判別された場合(ステップS23:No)、判別部24は、取引先用取引先ユーザマスタメンテナンス画面の起動要求の有無を判別する(ステップS24)。そして、取引先用取引先ユーザマスタメンテナンス画面の起動要求を検出した場合(ステップS24:Yes)、判別部24は、ステップS25において、ユーザIDに基づいて図20(c)に示すWebEDIユーザマスタ14を参照することで、その仕入先の会社のユーザが、新規ユーザの登録権限を有する「仕入先管理者」のユーザグループのユーザであるか否かを判別する。「仕入先管理者」のユーザグループのユーザではない場合(ステップS25:No)、その仕入先の会社のユーザはユーザ登録を行う権限は無いため、そのまま図19のフローチャートの処理が終了となる。
「仕入先管理者」のユーザグループのユーザである場合(ステップS25:Yes)、ステップS26に処理が進む。ステップS26では、判別部24が図21(a)に示すWebEDI取引先マスタ12を参照し、その仕入先のY会社のステータス情報が「有効」であることを確認する。また、判別部24は、図21(b)に示すWebEDIユーザグループマスタ13を参照することで、取引先分類がログインユーザと同じ「仕入先」で、取引先が管理可能なユーザグループを特定する。この図21(b)の例の場合、判別部24は、「仕入先実作業担当者」のユーザグループを、ユーザ登録が可能なユーザグループとして特定する。
次に、ステップS27では、表示画面生成部26は、図21(c)に例示する取引先用取引先ユーザマスタメンテナンス画面を生成し、通信制御部21が、この取引先用取引先ユーザマスタメンテナンス画面を仕入先端末装置200に送信する。
仕入先端末装置200の仕入先管理者は、図21(c)に例示する取引先用取引先ユーザマスタメンテナンス画面に基づいて、ユーザ登録が許可されている「仕入先実作業担当者」のユーザグループを選択する。また、仕入先端末装置200の仕入先管理者は、図21(c)に例示する取引先用取引先ユーザマスタメンテナンス画面に対して、新規にユーザ登録を行うユーザのユーザID、ユーザ名、初期パスワード、及び、ユーザID有効期限を入力して登録操作を行う。
これにより、取引先用取引先ユーザマスタメンテナンス画面を介して入力されたユーザグループ、ユーザID、ユーザ名、初期パスワード、及び、ユーザID有効期限の各情報が、仕入先端末装置200から管理装置1に送信され登録要求が行われる。この登録要求が管理装置1で受信されると、管理装置1の判別部24は、登録操作を行われたものと判別し(ステップS28:Yes)、ステップS29に処理が進む。
ステップS29では、判別部24が、図22(a)に示すWebEDIマスタ12を参照し、現在、ユーザ登録の対象となっている会社の「ユーザ数上限」を検出する。この例の場合、判別部24は、図22(a)に示すように、新規ユーザ登録の対象となっている仕入先であるY会社のユーザ数上限を「10人」として検出する。
また、判別部24は、図22(b)に示すWebEDIユーザマスタを参照し、新規ユーザ登録の対象となっている仕入先における、現在、有効ユーザ数を検出する。図22(b)の例の場合、判別部24は、新規ユーザ登録の対象となっている仕入先であるY会社における現在の有効ユーザ数として「3人」の有効ユーザ数を検出する。
そして、判別部24は、ステップS29において、新規にユーザ登録を行った場合に、有効ユーザ数がユーザ上限値を超過するか否かを判別する。新規にユーザ登録を行うことで、有効ユーザ数がユーザ数上限を超過することとなる場合は(ステップS29:Yes)、ユーザ登録数が規定数を超過することとなるため、表示画面生成部26が、図23(a)に示すように、例えば「ユーザ数上限を超えてユーザを追加できません」等のエラーメッセージを表示した取引先用取引先ユーザマスタメンテナンス画面を生成し、仕入先端末装置200に送信して、図19のフローチャートの処理を終了する。この場合、仕入先端末装置200の仕入先担当者は、これ以上の新規なユーザのユーザ登録はできないことを認識し、不要なユーザの削除、又は、ユーザ数上限の追加拡大操作等を運営会社側に要求する。このような要求が行われると、運営会社側は、WebEDIマスタ12のユーザ上限数の拡大変更等を行う。これにより、仕入先担当者は、新規なユーザのユーザ登録が可能となる。
これに対して、有効ユーザ数がユーザ上限値を超過しない場合(ステップS29:No)管理装置1のデータ生成部23は、仕入先端末装置200から受信したユーザグループ、ユーザID、ユーザ名、初期パスワード、及び、ユーザID有効期限を含む、WebEDIユーザマスタ14の明細データ(レコード)を生成する。
記憶制御部25は、ステップS30において、データ生成部23により生成された明細データ(レコード)を、図23(b)に示すようにWebEDIユーザマスタ14に追加して記憶させる。これにより、例えば仕入先となるY会社の「仕入先実作業担当者」のユーザグループに、ユーザIDが「YJT99」でユーザ名が「Y会社実作業担当者YJT99」のユーザが、「2030年12月31日」をユーザID有効期限として新たに登録される。
(取引先の無効動作)
次に、運営会社管理者が取引先のステータスを「無効」にすることで、その取引先のユーザを一括して無効にする動作を、図24のフローチャートを用いて説明する。この図24のフローチャートの各処理は、管理装置1の制御部3により、記憶部2に記憶されている管理プログラムに基づいて実行される。
すなわち、取引先のステータスを「無効」にするユーザは、管理者端末装置を介して管理装置1にログイン要求を行う。これにより、図24のフローチャートがスタートとなるが、ログイン画面に入力されたユーザIDに基づいてユーザ有効期限の超過の有無を判別するまでの、ステップS1~ステップS3の動作は、図13のフローチャートのステップS1~ステップS3の動作と同じ動作である。このため、ステップS1~ステップS3の詳細な動作の説明は、図13のフローチャートのステップS1~ステップS3の動作の説明を参照されたい。
次に、ユーザID有効期限が有効期限内であると判別されることで(ステップS3:Yes)、ステップS11に処理が進むと、表示画面生成部26は、管理者端末装置からの、図9に例示した取引先マスタメンテナンス画面の起動要求の有無を判別する。そして、管理者端末装置から、取引先マスタメンテナンス画面の起動要求が行われると(ステップS11:Yes)、判別部24は、ステップS5において、ログイン要求時のユーザIDに基づいて、現在、取引先マスタメンテナンス画面の起動要求を行っているユーザは、「運営会社管理者」のユーザグループのユーザであるか否かを判別する。
現在、取引先マスタメンテナンス画面の起動要求を行っているユーザが、「運営会社管理者」のユーザグループのユーザではない場合(ステップS5:No)、取引先のステータスを「無効」にする権限を有するユーザではないため、そのまま図24のフローチャートの処理が終了となる。
これに対して、現在、取引先マスタメンテナンス画面の起動要求を行っているユーザが、「運営会社管理者」のユーザグループのユーザである場合(ステップS5:Yes)、表示画面生成部26が、図9に例示した取引先マスタメンテナンス画面を生成し、通信制御部21が、この取引先マスタメンテナンス画面を管理者端末装置に送信する(ステップS12)。
「運営会社管理者」のユーザは、図9に例示する取引先マスタメンテナンス画面に基づいて、取引先分類、取引先名及びユーザ上限を指定し、ステータスを「無効」とする。図24のフローチャートのステップS41では、ステータス設定部27が、このような無効操作の有無を判別する。そして、ステータス設定部27は、無効操作を検出すると(ステップS41:Yes)、ステップS42において、取引先マスタメンテナンス画面で指定された取引先のステータスを「無効」とするステータス情報を生成する(=取引先のステータスを「無効」に設定する)。
記憶制御部25は、「無効」のステータス情報が生成されると、図25(a)に示すように例えば仕入先となっていたX会社のステータス情報を「無効」に更新処理する。これにより、X会社は、EDIシステムの利用が制限される。
また、これと共に、ステータス設定部27は、ステップS43において、ステータス情報が「無効」とされた取引先であるX会社の全ユーザグループに所属する全ユーザに対するユーザID有効期限として、有効期限切れの日付のユーザID有効期限を生成する。記憶制御部25は、生成された有効期限切れの日付のユーザID有効期限を、図25(b)に示すように、X会社の全ユーザグループの全ユーザのユーザID有効期限として入力する。
これにより、ステータスを「無効」としたX会社の全ユーザグループの全ユーザのユーザID有効期限を、一括して有効期限切れに更新してEDIシステムの利用を制限できる。運営会社が取引先に対する取引を無効にしても、取引先に所属する各ユーザが無効化されない場合、本来、EDIシステムを利用できないはずのユーザが、引き続き利用可能となる不都合を生ずる。しかし、実施の形態の管理装置1は、このような不都合を防止して、「無効」とされた取引先の各ユーザによりEDIシステムの利用を制限できる。
(ユーザID有効期限切れが看過されることによる問題点)
ここで、異動又は退職となったユーザのユーザ情報が有効な状態で記憶部2に記憶されていた場合、異動又は退職となったユーザが、有効な状態で残っているユーザアカウントを使用してEDIシステムにログインし、データを不正に取得する等の不正が行われることが懸念される。これは、セキュリティ上、好ましいことではない。
特に、上述のようにユーザ管理権限を委託した取引先におけるユーザ管理の運用レベルが低い場合、このようなセキュリティの問題が、より顕著となる。このため、実施の形態の管理装置1は、各ユーザのユーザ情報に含まれるユーザID有効期限情報に基づいて、各ユーザの正当なユーザ権限を有する期間を管理し、正当なユーザ権限の有効期限切れとなる日付の所定日数前から有効期限切れとなる警告を行う。管理者は、引き続きEDIシステムを利用可能とするユーザに対しては、有効期限の延長登録を行う。
これにより、有効期限の延長登録を行ったユーザに対しては、引き続きEDIシステムの利用を可能とすることができ、有効期限の延長登録を行わなかったユーザに対しては、有効期限日を境にしてEDIシステムの利用を不可とすることができる。従って、EDIシステムのセキュリティを維持でき、また、EDIシステムに登録されたユーザを定期的に検査して、正当使用の有無を判断する等の面倒な作業を不要とすることができる。
(運営会社又は取引先の有効期限切れ間近のユーザを、運営会社の管理者に対して警告する動作)
以下、具体例を説明する。図26のフローチャートは、運営会社の管理者が管理装置1に対してログインした際に、運営会社又は取引先の有効期限切れ間近のユーザを検出して、運営会社の管理者に警告となる通知を行う動作の流れを示すフローチャートである。管理装置1の制御部3は、記憶部2に記憶されている管理プログラムに基づいて動作することで、この図26のフローチャートの処理を実行する。
すなわち、運営会社の管理者が、管理者端末装置を介してログイン要求を行うと、管理装置1の表示画面生成部26により、図27に例示するログイン画面が生成され、通信制御部21により管理者端末装置に送信される。運営会社の管理者は、管理者端末装置に表示されるログイン画面に対して、ユーザID及びパスワードを入力して管理装置1に送信する。これにより、管理装置1の制御部3は、入力されたユーザID及びパスワードに基づいてユーザ認証処理を行う。このユーザ認証処理で、ログイン要求を行っているユーザが正規のユーザ(この例の場合は、運営会社の管理者)であることが認証された場合に、図26のフローチャートがスタートとなる。
ステップS51では、通知制御部28が、図7に示したWebEDIユーザマスタ14に記憶されている運営会社及び取引先の全ユーザのユーザID有効期限を検出する。そして、通知制御部28は、ステップS52において、有効期限が近いユーザが存在するか否か(有効期限切れの警告期間に相当するユーザの有無)を判別する。警告期間としては、例えば有効期限切れとなる日付から30日前から有効期限切れとなる日付までの期間が設定されている。このため、通知制御部28は、ログインの日付が、警告期間に含まれるユーザID有効期限のユーザの有無を判別する。ログインの日付が、警告期間に含まれるユーザID有効期限のユーザが存在しない場合は、この図26のフローチャートの処理を終了する。
ログインの日付が、警告期間に含まれるユーザID有効期限のユーザが存在する場合、通知制御部28は、ステップS53において、図28に例示するように所定の警告メッセージ(有効期限切れの間近のユーザの確認を促すメッセージ)を表示したメニュー画面を、表示画面生成部26を介して生成し、通信制御部21を介して、管理者端末装置に送信する。一例ではあるが、図28に示すようにメニュー画面には、受注入力、受注照会・・・ユーザメンテナンス等の各選択項目が含まれる。ステップS53では、このメニュー画面に対して、「A会社に所属するユーザの中に有効期限が近づいているユーザが1人います。ユーザマスタメンテナンスメニューで確認してください。」等の警告メッセージを表示する。
運営会社の管理者は、有効期限が近づいているユーザを確認する場合、図28に示すメニュー画面のユーザマスタメンテナンスの選択項目を選択操作する。これにより、メニュー画面のユーザマスタメンテナンスの選択項目が選択操作されたことを示す選択データが、管理者端末装置から管理装置1に送信される。管理装置1の通知制御部28は、この選択データの有無を監視することで、ユーザマスタメンテナンスの選択項目が選択操作されたか否かを判別する(ステップS54)。ユーザマスタメンテナンスの選択項目が選択操作されない場合は(ステップS54:No)、そのまま図26のフローチャートの処理を終了する。
ユーザマスタメンテナンスの選択項目が選択操作された場合は(ステップS54:Yes)、通知制御部28が、運営会社の全ユーザ及び各取引先の全ユーザの一覧を、管理者端末装置に表示すると共に、有効期限切れ間近のユーザの明細(レコード)は、有効期限切れ間近であることを示す所定の表示形態で表示すると共に、所定のアイコンを付して表示する(ステップS55)。
なお、この例では、通知制御部28が一覧を表示することとしたが、正確には、通知制御部28が、表示画面生成部26を介して一覧画面を生成し、この一覧画面を、通信制御部21を介して管理者端末装置に送信することで、一覧画面を管理者端末装置に表示する。以後、このような詳細な説明は省略するが、「通知制御部28が、画面を表示する」との記載は、このような表示画面生成部26における画面の生成動作、及び、通信制御部21による送信動作が含まれているものと理解されたい。
図29は、株式会社XXXの全ユーザを指定して一覧表示した例である。通知制御部28は、運営会社及び各取引先の全ユーザを一覧表示してもよいし、図29に示すように、取引先となる会社を指定して、取引先のユーザのみを表示することも可能である。図29に示すように、一覧画面には各ユーザの「状態」、「ユーザグループ」、「所属取引先」、ユーザID、ユーザ名、「警告のステータス」及び「ユーザID有効期限(有効期限)」が表示される。
この一覧画面において、「状態」は、通知制御部28が、各ユーザの有効期限に基づいて判別して表示するようになっており、本日の日付≦有効期限の場合は「有効」と表示し、本日の日付>有効期限の場合は「期限切れ」と表示する。また、「警告」は、有効期限切れの警告を行うことが「有効」となっているか、又は「無効」となっているかを示す情報である。この図29の例の場合、全ユーザが、期限切れの警告を行うことを示す「有効」となっている。
また、図29において、ユーザIDが「X004」でユーザ名が「担当者R」のユーザは、有効期限が「2022年3月31日」である。この一覧画面を表示した日付(=運営会社の管理者がログインした日付)が「2022年3月1日」であり、上述の警告期間が「30日」に設定されていたとすると、この「担当者R」のユーザの警告期間に、運営会社の管理者がログインした日付が含まれることとなる。
このため、通知制御部28は、図29に示すように、「担当者R」のユーザの有効期限の表示欄又は文字を、例えば赤色又は黄色で表示する等のように、他のユーザの有効期限の表示欄とは異なる表示形態で表示する。さらに、通知制御部28は、「担当者R」のユーザの有効期限の表示欄に、有効期限が間近に迫っていることを示す所定のアイコンを表示する。この図29の例は、△のマークの中に「!」が描かれたアイコンが表示された例である。運営会社の管理者は、有効期限の表示欄が、このような表示形態でアイコンが付されているユーザを、有効期限が迫っているユーザとして認識する。
なお、この例では、有効期限が迫っているユーザの有効期限の表示欄を、他とは異なる表示形態とし所定のアイコンを付すことで警告の通知を行うこととしたが、所定のメッセージを表示して警告を行ってもよいし、電子音又は音声メッセージで警告を行ってもよい。
次に、運営会社の管理者は、このような警告が行われたユーザの有効期限の延長操作又は警告の無効化操作を行うために、ユーザマスタ詳細画面の表示指示操作を行う。一例ではあるが、管理装置1の場合、図29に示した一覧画面の各ユーザのうち、所望のユーザの明細(レコード)をダブルクリック操作することで、所望のユーザを指定してユーザマスタ詳細画面を表示するようになっている。この場合、運営会社の管理者は、警告が行われたユーザの明細(レコード)をダブルクリック操作する。図26のフローチャートのステップS56では、通知制御部28が、このようなユーザマスタ詳細画面の表示指示操作の有無を判別している。そして、ユーザマスタ詳細画面の表示指示操作を検出すると(ステップS56:Yes)、通知制御部28は、表示画面生成部26を介してユーザマスタ詳細画面を生成し、通信制御部21を介して運営会社の管理者端末装置に送信する。これにより、図30に例示するユーザマスタ詳細画面が管理者端末装置に表示される(ステップS57)。
ユーザマスタ詳細画面には、図30に示すようにユーザグループ名、ユーザID、ユーザ名、及び、ユーザID有効期限(有効期限)が表示される。なお、この例の場合、有効期限が間近のユーザのユーザマスタ詳細画面であるため、有効期限の表示欄は、上述と同様に、例えば赤色又は黄色の文字等で表示され、所定のアイコンが付加される。
また、通知制御部28は、表示画面生成部26を介して、警告を将来的に不要とするか否かの、警告の無効化を指定するための警告無効選択オブジェクトをユーザマスタ詳細画面に表示制御する。一例として、警告無効選択オブジェクトとしては、「警告を無効化する」との文字と、チェックボックスが表示される。
次に、このようなユーザマスタ詳細画面に基づいて有効期限の延長設定を行う場合、運営会社の管理者は、図31(a)に示すように、有効期限の表示欄に対して、例えば「2023年3月31日」等のように、延長した有効期限の入力を行う。図26のフローチャートのステップS58では、通知制御部28が、このような有効期限の延長設定の有無を判別する。有効期限の延長設定が検出されると(ステップS58:Yes)、処理がステップS59に進む。
ここで、有効期限として例えば100年先の日付等の長期の日付の登録を可能とすると、EDIシステムのセキュリティ管理が困難となる。このため、実施の形態の管理装置1では、例えば「365日」等の、入力可能な有効期限の上限値(最大有効期限)が予め定められている。ステップS59では、通知制御部28が、入力された有効期限が「本日日付+最大ユーザ有効期間]以降の日付か否かを判別する。すなわち、ステップS59では、通知制御部28が、入力された有効期限が、最大有効期限を超過するか否かを判別する。
入力された有効期限が、最大有効期限を超過する場合(ステップS59:Yes)、通知制御部28は、ステップS63において、図32に例示するように、例えば「ユーザID有効期限の設定上限を超えています(最大ユーザID有効期限日数:365日)。」等のエラーメッセージを表示する。
これに対して、入力された有効期限が、最大有効期限以内であった場合(ステップS59:No)、通知制御部28は、ステップS60において、図31(b)に例示するように、一覧画面(図29参照)の、有効期限が延長されたユーザの明細(レコード)を、入力された有効期限日に基づいて更新して表示する。この例の場合、ユーザIDが「X004」でユーザ名が「担当者R」のユーザの有効期限を、「2023年3月31日」に更新して表示した例である。また、記憶制御部28は、このように有効期限日が延長操作されると、図31(c)に示すように、WebEDIユーザマスタ14のユーザID有効期限を、延長された日付である「2023年3月31日」に更新して記憶する。
さらに、入力された有効期限が、警告期間外であった場合(ステップS59:No)、通知制御部28は、図31(a)に示すように、「警告を無効化する」との文字及びチェックボックスである警告無効選択オブジェクトを非表示とする。これにより、有効期限の延長登録後も、警告無効選択オブジェクトが継続して表示されている間に、警告無効選択オブジェクトのチェックボックスを誤ってチェック操作してしまい、以後、そのユーザに対する有効期限の警告が行われない状態となる不都合を防止できる。
一方、運営会社の管理者は、図29に示した一覧画面を見て、有効期限切れ間近であることが警告されているユーザは、そのまま有効期限切れとしてもよいユーザであると判断した場合、図33(a)に示すように、有効期限の延長入力を行うことなく、警告無効選択オブジェクトのチェックボックスにチェックを入れる入力操作を行う。この警告無効選択オブジェクトのチェックボックスにチェックを入れる入力操作が行われると、ステップS58及びステップS61を介してステップS62に処理が進む。
ステップS62では、通知制御部28が、図33(b)に例示するように、一覧画面(図29参照)の、警告無効選択オブジェクトのチェックボックスにチェックが入れられたユーザの明細(レコード)の「警告」の入力欄を、「有効」から「無効」に更新して表示する。これにより、運営会社の管理者は、警告無効選択オブジェクトのチェックボックスにチェックを入れたユーザに対する、有効期限切れの警告は、以後、無効となることを、一覧画面を介して認識できる。
また、WebEDIユーザマスタ14には、ユーザID有効期限等と共に、警告無効化フラグが記憶されている。この警告無効化フラグは、有効期限切れの警告を無効化するか(=警告を行わない=TRUE)、又は、有効期限切れの警告を無効化しないか(=警告を行う=FALSE)を示す情報である。この警告無効化フラグのデフォルト設定は、有効期限切れの警告を無効化せず、警告を行うことを意味する「FALSE」の設定となっている。
このため、記憶制御部23は、警告無効選択オブジェクトのチェックボックスにチェックを入れる入力操作が行われると、ステップS62において、図33(c)に示すように、そのユーザの警告無効化フラグを「FALSE」から「TRUE」に更新してWebEDIユーザマスタ14に記憶する。これにより、この時点から、このユーザに対する有効期限切れ間近の警告は行われず、予め設定されている有効期限切れの日付で、EDIシステムを利用する権限が失効する。
(運営会社又は取引先で有効期限切れとなったユーザを、運営会社の管理者に対して警告する動作)
上述の例は、有効期限切れ間近のユーザの警告を行う例であったが、以下の例は、有効期限切れの日付を経過することで、実際に有効期限切れとなったユーザの存在を示す警告を行う例である。図34のフローチャートは、このような動作の流れを示している。管理装置1の制御部3は、記憶部2に記憶されている管理プログラムに基づいて動作することで、この図34のフローチャートの処理を実行する。
この図34のフローチャートにおいて、運営会社の管理者が、管理者端末装置を介してログイン要求を行うと、上述のように図27に例示したログイン画面を介して入力されたユーザID及びパスワードに基づいてユーザ認証処理が行われ、ステップS71に処理が進む。
ステップS71では、通知制御部28が、図7に示したWebEDIユーザマスタ14に記憶されている運営会社及び取引会社の全ユーザのユーザID有効期限を検出する。そして、通知制御部28は、ステップS72において、ログインの日付と、各ユーザのユーザID有効期限の日付を比較することで、有効期限切れとなったユーザが存在するか否かを判別する。有効期限切れとなっているユーザが存在しない場合は(ステップS72:No)、この図34のフローチャートの処理を終了する。
有効期限切れとなっているユーザが存在する場合(ステップS72:Yes)、通知制御部28は、ステップS73において、図35に例示するように所定の警告メッセージ(有効期限切れのユーザの確認を促すメッセージ)を表示したメニュー画面を管理者端末装置に表示する。図35は、「C会社に所属するユーザの中で有効期限が切れたユーザが1人います。ユーザマスタメンテナンスメニューで確認してください。」との警告メッセージがメニュー画面に表示された例である。
運営会社の管理者は、有効期限が切れたユーザを確認する場合、図35に示すメニュー画面のユーザマスタメンテナンスの選択項目を選択操作する。これにより、ステップS74では、管理装置1の通知制御部28が、ユーザマスタメンテナンスの選択項目の選択操作の有無を監視している。ユーザマスタメンテナンスの選択項目の選択操作されない場合は(ステップS74:No)、そのまま図34のフローチャートの処理を終了する。
ユーザマスタメンテナンスの選択項目が選択操作された場合は(ステップS74:Yes)、通知制御部28が、運営会社の全ユーザ及び各取引先の全ユーザの一覧を、管理者端末装置に表示すると共に、有効期限切れのユーザの明細(レコード)は、有効期限切れであることを示す所定の表示形態で表示すると共に、所定のアイコンを付して表示する(ステップS75)。
図36は、株式会社XXXの全ユーザを指定して一覧表示した例である。通知制御部28は、運営会社及び各取引先の全ユーザを一覧表示してもよいし、図36に示すように、取引先となる会社を指定して、取引先のユーザのみを表示することも可能である。図36に示すように、一覧画面には各ユーザの「状態」、「ユーザグループ」、「所属取引先」、「ユーザID」、「ユーザ名」、「警告のステータス」及び「ユーザID有効期限(有効期限)」が表示される。
この一覧画面において、「状態」は、通知制御部28が、各ユーザの有効期限に基づいて判別して表示するようになっており、本日の日付≦有効期限の場合は「有効」と表示し、本日の日付>有効期限の場合は「期限切れ」と表示する。また、「警告」は、有効期限切れの警告を行うことが「有効」となっているか、又は「無効」となっているかを示す情報である。この図36の例の場合、全ユーザが、期限切れの警告対象であることを示す「有効」となっている。
また、図36において、ユーザIDが「X003」でユーザ名が「担当者Q」のユーザは、有効期限切れ間近であるため、上述の表示形態及びアイコンにより、有効期限切れ間近であることを示す警告が行われている。
また、ログインした日付が「2022年4月1日」であるとした場合、ユーザIDが「X004」でユーザ名が「担当者R」のユーザの有効期限は「2022年3月31日」であるため、有効期限切れとなっている。このため、通知制御部28は、本日の日付>有効期限であるため、「状態」として「期限切れ」を表示する。
また、通知制御部28は、図36に示すように、「担当者R」のユーザの有効期限の表示欄又は文字を、例えば赤色又は黄色で表示する等のように、他のユーザの有効期限の表示欄とは異なり、かつ、上述の有効期限切れ間近のユーザの警告に用いた色とは異なる色を用いた表示形態で表示する。さらに、通知制御部28は、「担当者R」のユーザの有効期限の表示欄に、有効期限切れであることを示し、かつ、上述の有効期限切れ間近のユーザの警告で用いたアイコンとは異なるアイコンを表示する。この図36の例は、×のマークのアイコンで期限切れを表示した例である。運営会社の管理者は、有効期限の表示欄が、このような表示形態でアイコンが付されているユーザを、有効期限切れのユーザとして認識する。
なお、この例では、上述の表示形態及びアイコンで、有効期限切れのユーザの存在を警告することとしたが、メッセージを表示して警告を行ってもよいし、電子音又は音声メッセージで警告を行ってもよい。
次に、運営会社の管理者は、このような警告が行われたユーザの有効期限の延長操作又は警告の無効化操作を行うために、ユーザマスタ詳細画面の表示指示操作を行う。上述のように、管理装置1の場合、図36に示した一覧画面の各ユーザのうち、所望のユーザの明細(レコード)をダブルクリック操作することで、所望のユーザを指定してユーザマスタ詳細画面を表示するようになっている。この場合、運営会社の管理者は、有効期限切れとなっている「担当者R」のユーザの明細(レコード)をダブルクリック操作する。図34のフローチャートのステップS76では、通知制御部28が、このようなユーザマスタ詳細画面の表示指示操作の有無を判別している。そして、ユーザマスタ詳細画面の表示指示操作を検出すると(ステップS76:Yes)、通知制御部28は、図37に例示するユーザマスタ詳細画面を管理者端末装置に表示する(ステップS77)。
ユーザマスタ詳細画面には、図37に示すようにユーザグループ名、ユーザID、ユーザ名、及び、ユーザID有効期限(有効期限)が表示される。なお、この例の場合、有効期限切れのユーザのユーザマスタ詳細画面であるため、有効期限の表示欄は、有効期限切れを示す表示形態の文字で、「×」等の所定のアイコンが付加されて、期限切れとなった有効期限日が表示される。
また、通知制御部28は、表示画面生成部26を介して、このような期限切れの警告を将来的に不要とするか否かの、警告の無効化を指定するための警告無効選択オブジェクトをユーザマスタ詳細画面に表示制御する。一例として、警告無効選択オブジェクトとしては、「警告を無効化する」との文字と、チェックボックスが表示される。
次に、このようなユーザマスタ詳細画面に基づいて有効期限の延長設定を行う場合、運営会社の管理者は、図38(a)に示すように、有効期限の表示欄に対して、例えば「2023年3月31日」等のように、延長した有効期限の入力を行う。図34のフローチャートのステップS78では、通知制御部28が、このような有効期限の延長設定の有無を判別する。有効期限の延長設定が検出されると(ステップS78:Yes)、処理がステップS79に進む。
ステップS79では、上述のステップS59で説明したように、入力された有効期限が最大有効期限を超過する設定か否かを通知制御部28が判別する。入力された有効期限が、最大有効期限を超過する場合(ステップS79:Yes)、通知制御部28は、ステップS83において、図32に例示したように、例えば「ユーザID有効期限の設定上限を超えています(最大ユーザID有効期限日数:365日)。」等のエラーメッセージを表示する。
これに対して、入力された有効期限が、最大有効期限以内であった場合(ステップS79:No)、通知制御部28は、ステップS80において、図38(b)に例示するように、一覧画面(図36参照)の、有効期限が延長されたユーザの明細(レコード)を、入力された有効期限日に基づいて更新して表示する。この図38(b)例は、ユーザIDが「X004」でユーザ名が「担当者R」のユーザの有効期限を、「2023年3月31日」に更新して表示した例である。また、通知制御部28は、「担当者R」のユーザの「状態」を、「期限切れ」から「有効」に更新して一覧画面に表示する。記憶制御部28は、このように有効期限日が延長操作されると、図38(c)に示すように、WebEDIユーザマスタ14のユーザID有効期限を、延長された日付である「2023年3月31日」に更新して記憶する。
さらに、入力された有効期限が、警告期間外であった場合(ステップS79:No)、通知制御部28は、図38(a)に示すように、「警告を無効化する」との文字及びチェックボックスである警告無効選択オブジェクトを非表示とする。これにより、有効期限の延長登録後も、警告無効選択オブジェクトが継続して表示されている間に、警告無効選択オブジェクトのチェックボックスを誤ってチェック操作してしまい、以後、そのユーザに対する有効期限の警告が行われない状態となる不都合を防止できる。
一方、運営会社の管理者は、図36に示した一覧画面を見て、有効期限切れが警告されているユーザは、そのまま有効期限切れとしてもよいユーザであると判断した場合、図39(a)に示すように、有効期限の延長入力を行うことなく、警告無効選択オブジェクトのチェックボックスにチェックを入れる入力操作を行う。この警告無効選択オブジェクトのチェックボックスにチェックを入れる入力操作が行われると、ステップS78及びステップS81を介してステップS82に処理が進む。
ステップS82では、通知制御部28が、図39(b)に例示するように、一覧画面(図36参照)の、警告無効選択オブジェクトのチェックボックスにチェックが入れられたユーザの明細(レコード)の「警告」の入力欄を、「有効」から「無効」に更新して表示する。これにより、運営会社の管理者は、警告無効選択オブジェクトのチェックボックスにチェックを入れたユーザに対する、有効期限切れの警告は、以後、無効となることを、一覧画面を介して認識できる。
また、記憶制御部23は、警告無効選択オブジェクトのチェックボックスにチェックを入れる入力操作が行われると、ステップS82において、図33(c)に示すように、そのユーザの警告無効化フラグを「FALSE」から「TRUE(警告を行わない)」に更新してWebEDIユーザマスタ14に記憶する。これにより、この時点から、このユーザに対する有効期限切れの警告は行われず、予め設定されている有効期限切れの日付で、EDIシステムを利用する権限が失効する。
(警告パターンの種別)
次に、通常のシステムの場合、全ユーザに対して同一のポリシーでユーザ管理を行うことが好ましい。しかし、EDIシステムの場合、取引先毎にユーザ管理権限の委託に有無及び取引関係が異なるため、取引先毎に異なるポリシーでユーザ管理を行う方が好ましい。これは、通常のシステムとEDIシステムの大きな違いである。このため、実施の形態の管理装置1では、以下に説明する警告パターン0~警告パターン4を運営会社又は取引先毎に選択して設定可能となっている。これにより、運営会社又は取引先毎に警告通知者(=警告を通知するユーザ)を設定して、上述の有効期限切れ間近のユーザ又は有効期限切れのユーザの警告を行うことができる。
設定されている警告パターンを示す警告パターン情報は、記憶部2に記憶されている。通知制御部28は、所定のタイミングで記憶部2に記憶されている警告パターン情報で示される警告パターンで、上述の警告を行う。
(警告パターン0)
まず、「警告パターン0」は、ログインしたユーザの利用期限が近付いている場合、本人に対して警告を行う警告パターンである。この警告パターン0が設定されている場合、通知制御部28は、有効期限切れが間近のユーザがログインした際に、そのユーザに対して、例えば「ユーザ有効期限切れが近づいています。管理者にお問い合わせください。有効期限:{○○年/○○月/○○日}」等の、有効期限切れ間近であることを示す警告を行う。
なお、この警告パターン0が設定されている場合、通知制御部28は、管理者又は担当者を問わず、全てのユーザに対して警告を行う。また、警告パターン0が設定されている場合、有効期限切れとなったユーザは、ログインすることができないため、通知制御部28は、上述の警告は行わない。
(警告パターン1)
次に、「警告パターン1」は、図40に示すように、運営会社のユーザ内に警告対象者が存在する場合、運営会社の管理者に対して警告を行う警告パターンである。この場合、通知制御部28は、管理者自身も警告の対象とする。すなわち、警告パターン1が設定されている場合、通知制御部28は、管理者及び運営会社の全ユーザの有効期限切れ間近及び有効期限切れの警告を行う。
(警告パターン2)
次に、「警告パターン2」は、図41に示すように、例えば得意先等の取引先の管理者及び担当者の中に、警告対象者が存在する場合、取引先の管理者に対して警告を行う警告パターンである。この警告パターン2では、通知制御部28は、管理者自身も警告の対象となる。図41は、得意先のA社内に2名の警告対象者が存在する例である。この場合、通知制御部28は、例えば「A社に所属するユーザの中に、有効期限切れが近づいているユーザが2人います。ユーザマスタメンテナンスで確認してください。」の警告のメッセージをA社の管理者の端末装置に通知する。
また、図41は、得意先のB社内に3名の警告対象者が存在する例である。この場合、通知制御部28は、例えば「B社に所属するユーザの中に、有効期限切れが近づいているユーザが3人います。ユーザマスタメンテナンスで確認してください。」等の警告のメッセージをB社の管理者の端末装置に通知する。
(警告パターン3)
次に、「警告パターン3」は、図42に示すように、例えば仕入先等の取引先の全担当者の管理を運営会社側で行っており、取引先の担当者の中に、警告対象者が存在する場合、運営会社の管理者に対して警告を行う警告パターンである。図42は、仕入先のC社内に3名の警告対象者が存在する例である。この場合、通知制御部28は、例えば「C社に所属するユーザの中に、有効期限切れが近づいているユーザが3人います。ユーザマスタメンテナンスで確認してください。」の警告のメッセージを運営会社の管理者端末装置に通知する。
(警告パターン4)
次に、「警告パターン4」は、図43に示すように、例えば○○先となる会社の管理者及び担当者の中に、警告対象者が存在する場合、○○先の管理者、及び、運営会社の管理者の両方に対して警告を行う警告パターンである。図43は、〇〇先となるC社内に3名の警告対象者が存在する例である。この場合、通知制御部28は、例えば「C社に所属するユーザの中に、有効期限切れが近づいているユーザが3人います。ユーザマスタメンテナンスで確認してください。」の警告のメッセージを運営会社の管理者の管理者端末装置、及び、C社の管理者に、それぞれ通知する。
(警告パターン0の警告動作)
次に、各警告パターンの警告動作を説明する。まず、図44は、ログインしたユーザの有効期限が間近に迫っている場合に、そのユーザに対して警告を行う警告パターン0の警告動作の流れを示すフローチャートである。管理装置1の制御部3は、記憶部2に記憶されている管理プログラムに基づいて、この図44のフローチャートの警告動作を実行制御する。すなわち、この図44のフローチャートは、制御部3が、記憶部2に記憶されている警告パターン情報で「警告パターン0」が設定されていることを認識することでスタートとなり、ステップS91から処理が実行される。
ステップS91では、通知制御部28が、ログインの際に図27に例示したログイン画面に対して入力されたユーザIDに基づいて図47に例示するWebEDIユーザマスタ14を参照し、そのユーザに付されている有効期限及び警告無効化フラグを検出する。また、ステップS92において、通知制御部28は、ユーザIDに基づいて図46に例示するWebEDIユーザグループマスタ13を参照し、ログインしたユーザが所属しているユーザグループに設定されている警告期間を検出する。
ステップS93では、通知制御部28が、以下の条件を満たすか否かを判別する。
条件=
「警告を無効化するFLG」=「FALSE」かつ
「有効期限」≠「NULL」かつ
「有効期限」≦「本日の日付」+「ユーザが所属するユーザグループに設定されている警告期間」
この条件を満たす場合、通知制御部28は、ステップS94において、そのログインしたユーザに対して、有効期限が迫っていることを示す警告を通知する(=警告パターン0の通知)。
(警告パターン1の警告動作)
次に、図45は、運営会社ユーザ内に警告対象者が存在する場合、運営会社の管理者に対して警告を行う警告パターン1の警告動作の流れを示すフローチャートである。管理装置1の制御部3は、記憶部2に記憶されている管理プログラムに基づいて、この図45のフローチャートの警告動作を実行制御する。すなわち、この図45のフローチャートは、制御部3が、記憶部2に記憶されている警告パターン情報で「警告パターン1」が設定されていることを認識することでスタートとなり、ステップS101から処理が実行される。
ステップS101では、通知制御部28が、ログインの際に図27に例示したログイン画面に対して入力されたユーザIDに基づいて図47に例示するWebEDIユーザマスタ14を参照し、そのユーザの明細(レコード)を取得する。また、通知制御部28は、ステップS102において、ユーザIDに基づいて図46に例示するWebEDIユーザグループマスタ13を参照し、ログインしたユーザが所属しているユーザグループの各ユーザの明細(レコード)を取得する。
ステップS103では、通知制御部28が、図46に示すWebEDIユーザグループマスタ13を参照し、ログインしたユーザが所属しているユーザグループに設定されている所属ユーザ警告対象フラグが「FALSE」であるか否かを判別する。所属ユーザ警告対象フラグが「FALSE」である場合(ステップS103:Yes)、ログインしたユーザが所属しているユーザグループは、警告の対象ではないことを意味するため、そのまま図45のフローチャートの処理を終了する。
これに対して、所属ユーザ警告対象フラグが「TRUE」であるということは(ステップS103:No)、ログインしたユーザが所属しているユーザグループは、警告の対象であることを意味する。このため、通知制御部28は、ステップS104において、ログインしたユーザのユーザIDに基づいて図47に示すWebEDIユーザマスタ14を参照し、ログインしたユーザは、運営管理会社の運営会社管理者のユーザグループの管理者又は担当者のうち、管理者であるか否かを判別する。
このステップS104の動作を詳しく説明すると、まず、通知制御部28は、WebEDIユーザマスタ14を参照し、ログインしたユーザが所属するユーザグループを取得する。次に、通知制御部28は、取得したユーザグループに基づいてWebEDIユーザグループマスタ13を参照し、運営会社グループフラグを取得する。この取得した運営会社グループフラグが「TRUE」の場合、通知制御部28は、ログインしたユーザが運営会社の管理者であると判別する(ステップS104:Yes)。なお、ログインしたユーザが運営会社の管理者ではない場合(ステップS104:No)、この警告パターン1において警告を通知するユーザではないため、そのまま図45のフローチャートの処理を終了する。
一方、ログインしたユーザが運営会社の管理者である場合(ステップS104:Yes)、通知制御部28は、ステップS105において、図46に示すWebEDIユーザグループマスタ13を参照し、運営会社グループフラグが「TRUE」のユーザグループの明細を取得する。また、通知制御部28は、ステップS106において、図47に示すWebEDIユーザマスタ14を参照し、運営会社グループフラグが「TRUE」のユーザグループの明細を取得する。
そして、通知制御部28は、ステップS107において、運営会社の全ユーザが下記の条件を満たすか否かを判別する。
条件=
「警告を無効化するFLG」=「FALSE」かつ
「有効期限」≠「NULL」かつ
「有効期限」≦「本日の日付」+「ユーザが所属するユーザグループに設定されている警告期間」
この条件を満たすユーザは、有効期限切れが迫っているユーザであるため、通知制御部28は、ステップS108において、運営会社の管理者に上述の警告の通知を行う(=警告パターン1の通知)。
(警告パターン3及び警告パターン4の警告動作)
次に、図48は、取引先の担当者が警告対象者であった場合に、運営会社の管理者に警告の通知を行う警告パターン3、及び、取引先(又は〇〇先)の担当者が警告対象者であった場合に、運営会社の管理者及び取引先(又は〇〇先)の管理者の両方に警告の通知を行う警告パターン4の警告動作の流れを示すフローチャートである。
管理装置1の制御部3は、記憶部2に記憶されている管理プログラムに基づいて、この図48のフローチャートの警告動作を実行制御する。すなわち、この図48のフローチャートは、制御部3が、記憶部2に記憶されている警告パターン情報で「警告パターン3」又は「警告パターン4」が設定されていることを認識することでスタートとなり、ステップS101から処理が実行される。
ステップS101では、上述と同様に通知制御部28が、ログインの際に図27に例示したログイン画面に対して入力されたユーザIDに基づいて図47に例示するWebEDIユーザマスタ14を参照し、そのユーザの明細(レコード)を取得する。また、通知制御部28は、ステップS102において、ユーザIDに基づいて図46に例示するWebEDIユーザグループマスタ13を参照し、ログインしたユーザが所属しているユーザグループの各ユーザの明細(レコード)を取得する。
ステップS103では、通知制御部28が、図46に示すWebEDIユーザグループマスタ13を参照し、ログインしたユーザが所属しているユーザグループに設定されている所属ユーザ警告対象フラグが「FALSE」であるか否かを判別する。所属ユーザ警告対象フラグが「FALSE」である場合(ステップS103:Yes)、ログインしたユーザが所属しているユーザグループは、警告の対象ではないことを意味するため、そのまま図48のフローチャートの処理を終了する。このステップS103の処理により、警告の通知を行うユーザを、担当者を除外して管理者のみとすることができる。
これに対して、所属ユーザ警告対象フラグが「TRUE」であるということは(ステップS103:No)、ログインしたユーザが所属しているユーザグループは、警告の対象であることを意味する。このため、通知制御部28は、ステップS111において、ログインしたユーザのユーザIDに基づいて図47に示すWebEDIユーザマスタ14を参照し、ログインしたユーザは、運営管理会社の運営会社管理者のユーザグループの管理者又は担当者のうち、管理者であるか否かを判別する。
このステップS111の動作を詳しく説明すると、まず、通知制御部28は、WebEDIユーザマスタ14を参照し、ログインしたユーザが所属するユーザグループを取得する。次に、通知制御部28は、取得したユーザグループに基づいてWebEDIユーザグループマスタ13を参照し、運営会社グループフラグを取得する。この取得した運営会社グループフラグが「TRUE」の場合、通知制御部28は、ログインしたユーザが運営会社の管理者であると判別する(ステップS111:Yes)。なお、ログインしたユーザが運営会社の管理者ではない場合(ステップS111:No)、そのまま図45のフローチャートの処理を終了する。
一方、ログインしたユーザが運営会社の管理者である場合(ステップS111:Yes)、通知制御部28は、ステップS112において、図49に示すWebEDI取引先分類マスタ11を参照し、運営会社の管理者に対して警告の通知を行うことを示す運営会社通知フラグが「TRUE(運営会社の管理者に通知を行う)」の取引先分類の明細を取得する。また、通知制御部28は、ステップS113において、図46に示すWebEDIユーザグループマスタ13を参照し、運営会社に対して警告の通知が必要な取引先のユーザグループの明細を取得する。
次に、通知制御部28は、ステップS114において、取引先の全ユーザが下記の条件を満たすか否かを判別する。
条件=
「警告を無効化するFLG」=「FALSE」かつ
「有効期限」≠「NULL」かつ
「有効期限」≦「本日の日付」+「ユーザが所属するユーザグループに設定されている警告期間」
この条件を満たすユーザは、有効期限切れが迫っているユーザであるため、通知制御部28は、ステップS115において、運営会社の管理者に上述の警告の通知を行う(=警告パターン3又は警告パターン4の通知)。
(警告パターン2及び警告パターン4の警告動作)
次に、図50は、取引先の担当者が警告対象者であった場合に、取引先の管理者に警告の通知を行う警告パターン2、及び、取引先(又は〇〇先)の担当者が警告対象者であった場合に、運営会社の管理者及び取引先(又は〇〇先)の管理者の両方に警告の通知を行う警告パターン4の警告動作の流れを示すフローチャートである。
管理装置1の制御部3は、記憶部2に記憶されている管理プログラムに基づいて、この図50のフローチャートの警告動作を実行制御する。すなわち、この図50のフローチャートは、制御部3が、記憶部2に記憶されている警告パターン情報で「警告パターン2」又は「警告パターン4」の設定を認識することでスタートとなり、ステップS101から処理が実行される。
ステップS101では、上述と同様に通知制御部28が、ログインの際に図27に例示したログイン画面に対して入力されたユーザIDに基づいて図47に例示するWebEDIユーザマスタ14を参照し、そのユーザの明細(レコード)を取得する。また、通知制御部28は、ステップS102において、ユーザIDに基づいて図46に例示するWebEDIユーザグループマスタ13を参照し、ログインしたユーザが所属しているユーザグループの各ユーザの明細(レコード)を取得する。
ステップS103では、通知制御部28が、図46に示すWebEDIユーザグループマスタ13を参照し、ログインしたユーザが所属しているユーザグループに設定されている所属ユーザ警告対象フラグが「FALSE」であるか否かを判別する。所属ユーザ警告対象フラグが「FALSE」である場合(ステップS103:Yes)、ログインしたユーザが所属しているユーザグループは、警告の対象ではないことを意味するため、そのまま図50のフローチャートの処理を終了する。このステップS103の処理により、警告の通知を行うユーザを、担当者を除外して管理者のみとすることができる。
これに対して、所属ユーザ警告対象フラグが「TRUE」であるということは(ステップS103:No)、ログインしたユーザが所属しているユーザグループは、警告の対象であることを意味する。このため、通知制御部28は、ステップS120において、ログインしたユーザのユーザIDに基づいて図47に示すWebEDIユーザマスタ14を参照し、ログインしたユーザは、取引先のユーザグループの管理者であるか否かを判別する。
このステップS120の動作を詳しく説明すると、まず、通知制御部28は、WebEDIユーザマスタ14を参照し、ログインしたユーザが所属するユーザグループを取得する。次に、通知制御部28は、取得したユーザグループに基づいてWebEDIユーザグループマスタ13を参照し、運営会社グループフラグを取得する。この取得した運営会社グループフラグが「FALSE」の場合、通知制御部28は、ログインしたユーザが取引先のユーザグループの管理者であると判別する(ステップS120:Yes)。なお、ログインしたユーザが取引先のユーザグループの管理者ではない場合(ステップS120:No)、そのまま図50のフローチャートの処理を終了する。
一方、ログインしたユーザが取引先の管理者である場合(ステップS120:Yes)、通知制御部28は、ステップS121において、図47に示すWebEDIユーザマスタ14を参照し、ログインしたユーザと同じ取引先のユーザの明細を取得する。
次に、通知制御部28は、ステップS122において、取引先の全ユーザが下記の条件を満たすか否かを判別する。
条件=
「警告を無効化するFLG」=「FALSE」かつ
「有効期限」≠「NULL」かつ
「有効期限」≦「本日の日付」+「ユーザが所属するユーザグループに設定されている警告期間」
この条件を満たすユーザは、有効期限切れが迫っているユーザであるため、通知制御部28は、ステップS123において、取引先の管理者に上述の警告の通知を行う(=警告パターン2又は警告パターン4の通知)。
(実施の形態の効果)
管理装置1を介してEDIシステムを提供する運営会社は、取引先の管理と同時に取引先に所属するユーザの管理も行う必要があり、運営会社の管理コストが非常に大きい。また、取引先は、ユーザの追加、修正、削除を行う場合、これを運営会社に依頼する必要があり、ユーザ設定の正確性及びリアルタイム性に問題がある。
また、運営会社が取引先のステータスを無効にしても、取引先に所属する各ユーザが無効化されない場合、本来、EDIシステムを利用できないはずのユーザが、引き続き利用可能となる不都合を生ずる。また、運営会社の設定ミスで、本来登録するはずの取引先とは異なる取引先に関連づけてユーザ登録を行った場合、このユーザは、自分が所属していない取引先の取引先情報の閲覧等が可能となる不都合を生ずる。
ここで、運営会社が1社で管理を行うことが困難であるため、各取引先にもユーザ管理権限を委託することを考える。しかし、ユーザ管理権限を無条件で取引先に委託すると、委託された取引先はユーザ管理権限に制限がないため、他の取引先のユーザまで管理が可能となる不都合を生ずる。また、委託された取引先は、無制限にユーザを登録できるため、年月の経過と共に在籍しないユーザが多く登録されている状態となり、セキュリティリスクが高くなる不都合を生ずる。このため、取引先に対して制限的なユーザ管理権限の委託を行う必要がある。
このようなことから、実施の形態の管理装置1は、正規のユーザ権限を有する有効期限を示す有効期限情報を含むユーザ情報の登録又は編集を行うユーザ管理権限を、取引先に設定する。これにより、取引先毎にユーザ管理権限を委託することができ、管理装置1の運営会社が管理する電子商取引システムの管理コストを軽減できる。また、信用のある取引先に対してユーザ管理権限を委託できるため、管理コストの分散を安全に行うことができる。また、ユーザ管理権限を委託された取引先は、取引先自身でユーザ管理を行うことができるため、正確かつリアルタイムにユーザ管理を行うことができる。
また、ユーザ管理権限は、各取引先の所望のユーザグループの管理者毎又は担当者毎に設定できる。これにより、所望のユーザグループの管理者又は担当者に対してユーザ管理権限を委託することができ、管理コストの細かな分散設定、及び、さらなる安全性の向上を図ることができる。
また、新規に登録可能なユーザの登録数の上限を取引先毎に設定できるため、例えば取引先が無制限にユーザ登録を行うことで、年月の経過と共に在籍しないユーザが多く登録されている状態となり、セキュリティリスクが高くなる不都合を防止できる。
また、取引先単位で、EDIシステムを利用する権限の「有効」又は「無効」を示すステータスを付して管理している。そして、取引先のステータスを「無効」とした場合には、この取引先に所属する各ユーザのユーザID有効期限を「有効期限切れ」に更新してEDIシステムを利用する権限を無効化する。これにより、取引先のステータスを「無効」とすることで、この取引先に所属する各ユーザの、EDIシステムを利用する権限も一括して無効化でき、管理コストをさらに軽減できる。また、運営会社のユーザ管理ミスが生じた場合でも、セキュリティリスクを軽減できる。
また、実施の形態の管理装置1は、ユーザ情報を登録する際に、ユーザID有効期限を付して登録する。そして、各ユーザがシステムにログインした際に、有効期限が近付いているユーザ、運営会社の管理者又はそのユーザが所属する取引先の管理者に対して警告を通知して、ユーザ有効期限の見直しを促す。そして、管理者は、引き続きEDIシステムの利用を可能とするユーザは、有効期限の延長登録を行い、EDIシステムの利用を不可とするユーザに対しては、有効期限の延長登録を行わない。
これにより、有効期限の延長登録を行わなかったユーザに対しては、有効期限日を境にしてEDIシステムの利用を不可とすることができる。従って、EDIシステムのセキュリティを維持でき、また、EDIシステムに登録されたユーザを定期的に検査して、正当使用の有無を判断する等の面倒な作業を不要とすることができる。
従って、ユーザ管理権限を委託した取引先におけるユーザ管理の運用レベルが低い場合でも、EDIシステムのセキュリティを維持することができる。
また、図33(a)を用いて説明したように、有効期限の延長登録を行わない場合、警告無効選択オブジェクトにより、そのユーザに対する有効期限の警告を将来的に行わないことを指定することができる。これにより、以後、有効期限の警告を非通知とすることができ、有効期限の延長登録を行わないユーザの警告が通知され続ける不都合を防止できる。
[国連が主導する持続可能な開発目標(SDGs)への貢献]
本実施形態により、業務効率化や企業の適切な経営判断を推進することに寄与することができるので、SDGsの目標8及び目標9に貢献することが可能となる。
また、本実施形態により、廃棄ロス削減や、ペーパレス・電子化を推進することに寄与することができるので、SDGsの目標12、目標13及び目標15に貢献することが可能となる。
また、本実施形態により、統制、ガバナンス強化に寄与することができるので、SDGsの目標16に貢献することが可能となる。
[他の実施の形態]
本発明は、上述した実施形態以外にも、特許請求の範囲に記載した技術的思想の範囲内において種々の異なる実施形態にて実施されてよいものである。
例えば、実施の形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、或いは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。
また、本明細書中や図面中で示した処理手順、制御手順、具体的名称、各処理の登録データや検索条件等のパラメータを含む情報、画面例、データベース構成については、特記する場合を除いて任意に変更することができる。
また、管理装置1に関して、図示の各構成要素は機能概念的なものであり、必ずしも図示の如く物理的に構成されていることを要しない。
例えば、管理装置1が備える処理機能、特に制御部3にて行われる各処理機能については、その全部又は任意の一部を、CPU(Central Processing Unit)および当該CPUにて解釈実行されるプログラムにて実現してもよく、また、ワイヤードロジックによるハードウェアとして実現してもよい。なお、プログラムは、各実施の形態で説明した処理を情報処理装置に実行させるためのプログラム化された命令を含む一時的でないコンピュータ読み取り可能な記録媒体に記録されており、必要に応じて管理装置1に機械的に読み取られる。すなわち、ROM又はHDD等の記憶部等には、OSと協働してCPUに命令を与え、各種処理を行うためのコンピュータプログラムが記録されている。このコンピュータプログラムは、RAMにロードされることによって実行され、CPUと協働して制御部3又は制御部43を構成する。
また、この管理装置1の管理プログラムは、管理装置1に対して任意のネットワークを介して接続された他のサーバ装置に記憶されていてもよく、必要に応じてその全部又は一部をダウンロードすることも可能である。
また、各実施の形態で説明した処理を実行するための管理プログラムを、一時的でないコンピュータ読み取り可能な記録媒体に格納してもよく、また、プログラム製品として構成することもできる。ここで、この「記録媒体」とは、メモリーカード、USB(Universal Serial Bus)メモリ、SD(Secure Digital)カード、フレキシブルディスク、光磁気ディスク、ROM、EPROM(Erasable Programmable Read Only Memory)、EEPROM(登録商標)(Electrically Erasable and Programmable Read Only Memory)、CD-ROM(Compact Disk Read Only Memory)、MO(Magneto-Optical Disk)、DVD(Digital Versatile Disk)、及び、Blu-ray(登録商標) Disc等の任意の「可搬用の物理媒体」を含むものとする。
また、「プログラム」とは、任意の言語または記述方法にて記述されたデータ処理方法であり、ソースコード又はバイナリコード等の形式を問わない。なお、「プログラム」は必ずしも単一的に構成されるものに限られず、複数のモジュールやライブラリとして分散構成されるものや、OSに代表される別個のプログラムと協働してその機能を達成するものをも含む。なお、実施の形態に示した管理装置1において記録媒体を読み取るための具体的な構成および読み取り手順ならびに読み取り後のインストール手順等については、周知の構成や手順を用いることができる。
記憶部2は、RAM、ROM等のメモリ装置、ハードディスク等の固定ディスク装置、フレキシブルディスク、及び、光ディスク等のストレージ手段であり、各種処理やウェブサイト提供に用いる各種のプログラム、テーブル、データベース、及び、ウェブページ用ファイル等を格納する。
また、管理装置1は、既知のパーソナルコンピュータ装置又はワークステーション等の情報処理装置で構成してもよく、また、任意の周辺装置が接続された情報処理装置で構成してもよい。また、情報処理装置は、本実施形態で説明した処理を実現させるソフトウェア(プログラム又はデータ等を含む)を実装することにより実現してもよい。
さらに、装置の分散・統合の具体的形態は図示するものに限られず、その全部又は一部を、各種の付加等に応じて又は機能付加に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。すなわち、上述した実施形態を任意に組み合わせて実施してもよく、実施形態を選択的に実施してもよい。