(57)【特許請求の範囲】
【請求項１】
構築されたマスタデータテーブルに格納された各商品についての商品データを、受信した各商品についての複数の項目データからなる更新データに基づいて商品毎に更新するＰＯＳシステムを構成するサーバ装置であって、
各商品についての複数の項目データを含む更新データを受信する受信手段と、
前記受信手段で受信した商品毎の更新データについて複数の項目データがそれぞれ予め定めた更新条件の範囲にあるか否かを判定し、すべての項目データが前記更新条件内であるとき、受信した更新データが当該商品についての正データであると判定すると共に、少なくとも一つの項目データが前記更新条件の範囲外であるとき、受信した更新データが不正データであると判定するものであり、前記受信手段で受信した更新データについて前記項目データに基づいてエラー判定を行って正・不正を判定する判定手段と、
前記判定手段の判定により前記正データであると判定された更新データにより前記マスタデータテーブルに格納される商品データを更新する更新手段と、
前記判定手段の判定により不正データであると判定された更新データについてのログファイルを生成する生成手段と、
複数の項目データを用いて行う一のエラー判定の要否を示す設定情報を格納する格納手段と、
を有し、
前記判定手段は、
前記格納手段に格納されている前記設定情報に基づき、エラー判定を要すると設定されている前記複数の項目データを用いて行う一のエラー判定を行い、エラー判定を要しないと設定されている前記複数の項目データを用いて行う一のエラー判定を行わないサーバ装置。
【請求項２】
判定処理を実行するか否かを選定する手段を備える請求項１記載のサーバ装置。
【請求項３】
更新データは、各商品についてのＰＬＵ（プライスルックアップ）データ、便コード、自社コード、共通自社コードを含むものであり、
前記判定手段は、各項目データについて判定を行い、１つの項目データでも更新条件範囲外であるとき当該商品についての更新データは不正データであると判定する請求項１又は２記載のサーバ装置。
【請求項４】
構築されたマスタデータテーブルに格納された各商品についての商品データを、受信した各商品についての複数の項目データからなる更新データに基づいて商品毎に更新するＰＯＳシステムを構成するサーバ装置で実行されるマスタデータの更新方法であって、
受信手段が、各商品についての複数の項目データを含む更新データを受信する受信ステップと、
判定手段が、前記受信ステップで受信した商品毎の更新データについて複数の項目データがそれぞれ予め定めた更新条件の範囲にあるか否かを判定し、すべての項目データが前記更新条件内であるとき、受信した更新データが当該商品についての正データであると判定すると共に、少なくとも一つの項目データが前記更新条件の範囲外であるとき、受信した更新データが不正データであると判定するものであり、前記受信ステップで受信した更新データについて前記項目データに基づいてエラー判定を行って正・不正を判定する判定ステップと、
更新手段が、前記判定ステップの判定により前記正データであると判定された更新データにより前記マスタデータテーブルに格納される商品データを更新する更新ステップと、
生成手段が、前記判定手段の判定により不正データであると判定された更新データについてのログファイルを生成する生成ステップと、
を有し、
前記判定ステップは、
所定の格納手段に格納されている複数の項目データを用いて行う一のエラー判定の要否を示す設定情報に基づき、エラー判定を要すると設定されている前記複数の項目データを用いて行う一のエラー判定を行い、エラー判定を要しないと設定されている前記複数の項目データを用いて行う一のエラー判定を行わないマスタデータの更新方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＰＯＳシステムにおけるマスタデータの更新方法に係り、特にＰＯＳシステムを構成する店舗サーバに構築されたマスタデータテーブルに格納された各商品についての商品データを受信した各商品についての複数の項目データからなる更新データに基づいて商品毎に更新するＰＯＳシステムにおけるサーバ装置およびマスタデータの更新方法に関する。
【背景技術】
【０００２】
コンビニエンスストアでは商品は頻繁に入れ替わっていく。新商品が次々投入される一方、販売中止になる商品も多い。また、売れ筋商品は日々変化していくため、毎日納品される商品も多種多様にわたる。
【０００３】
コンビニエンスストアのＰＯＳシステムでは店舗サーバのマスタデータテーブルを備え、店舗で取り扱っている商品の商品データをマスタデータとして格納している。
【０００４】
納入された商品は、それぞれバーコードリーダで商品に貼付されたバーコードを読み取り、マスタデータテーブルと照合され、検品される。
【０００５】
このため、商品の納入の前に、前記店舗サーバのマスタデータを納入された商品に対応させて更新していく必要がある。
【０００６】
このマスタデータの更新は、ホストベンダから当該店舗へ配信される更新データによって行われる。この更新データは、店舗に納入されたすべての商品について、各商品についてのＰＬＵ（プライスルックアップ）データ、便コード、自社コード、共通自社コードを含むものである。
【０００７】
ＰＯＳシステムにおいてＰＬＵファイルを更新する技術として特許文献１に記載がある。特許文献１には、センタ装置において、各店舗に対応する複数の個店ＰＬＵマスタファイルを構築し、センタ装置は、更に、共通の商品マスタファイルを備え、各店舗からのＰＬＵ訂正リクエストに応じて該商品マスタファイルを参照しつつ該個店ＰＬＵマスタファイルを訂正して訂正分を対応する店舗のＰＯＳ装置に送信し、店舗内ＰＯＳ装置においては、受信した訂正分を取り込んで自身内のＰＬＵファイルを訂正あるいは更新するものが記載されている。
【０００８】
【特許文献１】特開２０００−７６５５０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
ところで、上述したホストベンダからの更新データに誤りがある所謂不正データである場合には、この不正データが店舗サーバのマスタデータとして更新されると、業務においてＰＯＳシステムの誤動作や業務停止などの問題が発生する。すなわち、一部の商品についての不正データのためにＰＯＳシステム全体の業務に影響を及ぼすことがあるのである。
【００１０】
そこで本発明は、不正なデータで店舗サーバのマスタデータテーブルを更新するのを防止することができるＰＯＳシステムにおけるサーバ装置およびマスタデータの更新方法を提供することを目的とする。
【課題を解決するための手段】
【００１１】
前記課題を解決するために、本発明のサーバ装置は、構築されたマスタデータテーブルに格納された各商品についての商品データを、受信した各商品についての複数の項目データからなる更新データに基づいて商品毎に更新するＰＯＳシステムを構成するサーバ装置であって、各商品についての複数の項目データを含む更新データを受信する受信手段と、前記受信手段で受信した商品毎の更新データについて複数の項目データがそれぞれ予め定めた更新条件の範囲にあるか否かを判定し、すべての項目データが前記更新条件内であるとき、受信した更新データが当該商品についての正データであると判定すると共に、少なくとも一つの項目データが前記更新条件の範囲外であるとき、受信した更新データが不正データであると判定するものであり、前記受信手段で受信した更新データについて前記項目データに基づいてエラー判定を行って正・不正を判定する判定手段と、前記判定手段の判定により前記正データであると判定された更新データにより前記マスタデータテーブルに格納される商品データを更新する更新手段と、前記判定手段の判定により不正データであると判定された更新データについてのログファイルを生成する生成手段と、複数の項目データを用いて行う一のエラー判定の要否を示す設定情報を格納する格納手段と、を有し、前記判定手段は、前記格納手段に格納されている前記設定情報に基づき、エラー判定を要すると設定されている前記複数の項目データを用いて行う一のエラー判定を行い、エラー判定を要しないと設定されている前記複数の項目データを用いて行う一のエラー判定を行わないサーバ装置である。
また、本発明のマスタデータの更新方法は、構築されたマスタデータテーブルに格納された各商品についての商品データを、受信した各商品についての複数の項目データからなる更新データに基づいて商品毎に更新するＰＯＳシステムを構成するサーバ装置で実行されるマスタデータの更新方法であって、受信手段が、各商品についての複数の項目データを含む更新データを受信する受信ステップと、判定手段が、前記受信ステップで受信した商品毎の更新データについて複数の項目データがそれぞれ予め定めた更新条件の範囲にあるか否かを判定し、すべての項目データが前記更新条件内であるとき、受信した更新データが当該商品についての正データであると判定すると共に、少なくとも一つの項目データが前記更新条件の範囲外であるとき、受信した更新データが不正データであると判定するものであり、前記受信ステップで受信した更新データについて前記項目データに基づいてエラー判定を行って正・不正を判定する判定ステップと、更新手段が、前記判定ステップの判定により前記正データであると判定された更新データにより前記マスタデータテーブルに格納される商品データを更新する更新ステップと、生成手段が、前記判定手段の判定により不正データであると判定された更新データについてのログファイルを生成する生成ステップと、を有し、前記判定ステップは、所定の格納手段に格納されている複数の項目データを用いて行う一のエラー判定の要否を示す設定情報に基づき、エラー判定を要すると設定されている前記複数の項目データを用いて行う一のエラー判定を行い、エラー判定を要しないと設定されている前記複数の項目データを用いて行う一のエラー判定を行わないマスタデータの更新方法である。
【発明の効果】
【００１２】
本発明に係るＰＯＳシステムにおけるマスタデータの更新方法によれば、更新データを構成する項目データの全てが所定の更新条件を満たしていないと不正データと判定し、更新行程では当該不正データに基づく更新を実行しないので、真性データで更新される他の商品データに影響を及ぼすことが無くなる他、この更新の状態はログ生成行程で作成されるログファイルに記録されるので、不正データの確認及び訂正を迅速に行えるという効果を有する。
【発明を実施するための最良の形態】
【００１３】
以下発明に係るＰＯＳシステムにおけるマスタデータの更新方法の実施の形態例について説明する。
【００１４】
図１は実施の形態例に係るマスタデータの更新方法が実行されるＰＯＳシステムを示すブロック図である。本例において、ＰＯＳシステム１００は、店舗１０と、ホストベンダ２０とを回線３０で接続して形成されている。店舗１０には店舗サーバ２００が配置され、店舗サーバ２００には回線３１０を介して複数のＰＯＳ端末３００が接続されている。また、ホストベンダ２０には店舗サーバ２００に回線３０を介して更新データを送出するホストサーバ４００が配置されている。
【００１５】
このようなＰＯＳシステム１００において、店舗１０における店舗サーバ２００は以下の構成を備える。図２は店舗サーバの構成を示すブロック図である。店舗サーバ２００は、店舗サーバ２００の更新処理を行う処理制御部２１０と、店舗における商品データを格納するマスタデータテーブル２２０と、ホストサーバ４００からの更新データの正・不正を判定するための条件を格納する更新条件格納部２３０と、更新の履歴を格納するログファイル格納部２４０と、更新データのうち分類項目の正・不正を判定するための第１のワークテーブル２５１及び第２のワークテーブル２５２が生成されるワークテーブル領域２５０と、更新データのうちどの項目データを更新対象とするかについてのデータを格納したレジストリ領域２６０とを備える。
【００１６】
処理制御部２１０は、更新データの正・不正を判定する判定部２１１と、前記ワークテーブル領域２５０に第１のワークテーブル２５１及び第２のワークテーブル２５２を作成するワークテーブル作成部２１２と、メンテナンスデータ更新部２１３と、ログ生成部２１４とを備える。これらの各部は、ＣＰＵ、ＲＯＭ、ＲＡＭ等を備えたコンピュータでプログラムを実行することにより実現される。
【００１７】
マスタデータテーブル２２０は、店舗１０におかれる商品についての商品データを格納しており、この商品データには、項目データとして、商品についてのＰＬＵ（プライスルックアップ）データ、便コード、自社コード、共通自社コード、大分類、中分類、小分類からなる商品の分類データ、メンテナンス日時、本部売価、課税区分等のデータが格納されている。
【００１８】
ホストサーバ４００からの更新データは各商品について以下の項目データを含んでいる。
（１）適用日範囲  適用日を示す８桁のデータ
（２）発注開始日付  発注開始日付を示す８桁のデータ
（３）発注停止開始日付  発注停止開始日付を示す８桁のデータ
（４）発注停止終了日付  発注停止終了日付を示す８桁のデータ
（５）催事発注用発注締め日  催事発注用発注締め日を示す８桁のデータ
（６）値引き開始日  値引き開始日を示す８桁のデータ
（７）値引き終了日  値引き終了日を示す８桁のデータ
（８）ロット・入り数  商品の発注単位を示すロット数及びケース商品の場合の入り数を示すデータ
（９）店着便Ｎｏ．  店着便のＮｏ．  何便であるかを示すデータ（例えば、１〜３）
（１０）便Ｎｏ．  便のＮｏ．  何便であるかを示すデータ（例えば、１〜３）
（１１）ＰＬＵデータ  商品のＰＬＵデータを示す１４桁のデータ
（１２）自社コード  店舗で商品を管理するためのユニークなコード１４桁のデータ
（１３）共通自社コード  便商品など複数の自社コードを括るための１４桁のコード
（１４）分類コード  ３桁の大分類コード、３桁の中分類、３桁の小分類からなる商品の分類コード
更新条件格納部２３０には、更新時における更新条件が格納されている。日付を含む更新データの判定を行う日付データとしては、××××年××月××日（例えば更新日となり得ない将来の日時）を示す「××××××××」が格納されている。また、ロット・入り数データの更新条件としては、数量０を示す「０」、便Ｎｏ．としては、１日の店舗への商品搬入便数「１〜３」を格納している。処理制御部２１０の判定部２１１は、更新データの項目データがこの更新条件に適合するかを判定する。
【００１９】
本例に係るＰＯＳシステム１００では次の手順でマスタデータテーブル２２０の更新を行う。図３はマスタデータテーブルの更新の手順を示すフローチャートである。
【００２０】
所定のタイミングで店舗サーバ２００は、まずホストサーバ４００から更新データを受信する（ステップＳＴ１）。すべての商品についてのデータを受信して格納すると（ステップＳＴ２）、判定部２１１は商品データの正・誤を判定する（ステップＳＴ３）。
【００２１】
このとき、通常の商品データについては、判定部２１１は、更新条件格納部２３０を参照してあるいは商品データ中の項目データを比較して正・不正の判定を行う他、分類データについては、判定部２１１はワークテーブル作成部２１２でワークテーブル領域２５０に第１のワークテーブル２５１及び第２のワークテーブル２５２を作成し、この第１のワークテーブル２５１及び第２のワークテーブル２５２を使用して判定を行う。
【００２２】
そして、判定部２１１が不正データを検出した場合には、ログ生成部２１４はこの不正データをログファイル格納部２４０に格納する（ステップＳＴ４）。そして、メンテナンスデータ更新部２１３は、更新データ中から不正データを排除し（ステップＳＴ５）、残りの正データでマスタデータテーブル２２０を更新する（ステップＳＴ６）。その後ログファイル格納部２４０に格納された不正データを参照して訂正等の必要な処理を行う（ステップＳＴ７）
以下判定部２１１の判定処理について詳細に説明する。本例では、マスタメンテナンス単品追加／変更データのレコード区分＝１ｏｒ２の区分に従って処理を行う。処理制御部２１０は、まずシステムオプションを取得して判定を行うかどうかを決定する。判定を行うと売上登録が一切できなくなる使用者があり得るため、判定処理を行わないという選択を可能としている。
この選択は、ＴＣ＿ＳＹＳ＿ＣＴＬ＿ＴＢＬ（システム管理テーブル）のフィールド名ＶＡＳＣ単品メンテ整合性チェックになされている設定に従う。
【００２３】
次いでレジストリ領域２６０の各レジストリを取得して各項目データの判定の要否を取得する。レジストリ領域のレジストリキーには例えば以下の設定がなされる。
【００２４】
￥ＶＨＯＮＬＣＴＲ￥ＭＡＴＣＨＫ１  同一商品コードで同一の便が存在する場合
￥ＶＨＯＮＬＣＴＲ￥ＭＡＴＣＨＫ２  ロット・入り数が“０”の場合
￥ＶＨＯＮＬＣＴＲ￥ＭＡＴＣＨＫ３  店着便Ｎｏ．が、１〜３以外の数の場合
￥ＶＨＯＮＬＣＴＲ￥ＭＡＴＣＨＫ４  便Ｎｏ．が、１〜３以外の数の場合
￥ＶＨＯＮＬＣＴＲ￥ＭＡＴＣＨＫ５  店着便Ｎｏ．と、便Ｎｏ．が一致しない場合
￥ＶＨＯＮＬＣＴＲ￥ＭＡＴＣＨＫ６  同一自社コードで異なる共通商品コードを持つレコードが複数有る場合
￥ＶＨＯＮＬＣＴＲ￥ＭＡＴＣＨＫ７  共通商品コードで紐付けされた商品に対して、それぞれ別々の分類コードが紐付けされている場合
￥ＶＨＯＮＬＣＴＲ￥ＭＡＴＣＨＫ８  最小発注数量＞最大発注数量の場合
そして、判定部２１１は、レジストリ領域２６０の設定に基づいて以下の判定を行う。エラー理由は例えば以下の通りである。
（１）適用日範囲エラー
（２）発注開始日付範囲エラー
（３）発注停止開始日付範囲エラー
（４）発注停止終了日付範囲エラー
（５）催事発注用発注締め日範囲エラー
（６）値引き開始日範囲エラー
（７）値引き終了日範囲エラー
（８）ロット・入り数０エラー
（９）店着便Ｎｏ．範囲エラー
（１０）便Ｎｏ．範囲エラー
（１１）店着Ｎｏ．便Ｎｏ．不一致エラー
（１２）最小発注数量＞最大発注数量エラー
（１３）同一共通商品同一便エラー
（１４）同一自社コード複数エラー
（１５）分類コード不一致エラー
（１６）日付範囲エラー（実際には（１）〜（７）の判定で引っかかるためこのエラーは出力されない）
システムオプション［単品メンテ整合性判定］が判定対象の場合、上記エラーの判定は以下のように行われる。
（１）適用日範囲エラー
適用日８桁＞××××××××のとき、「適用日範囲エラー」をエラーログに出力
（２）発注開始日付範囲エラー
発注開始日付８桁＞××××××××のとき、「発注開始日範囲エラー」をエラーログに出力
（３）発注停止開始日付範囲エラー
発注停止開始日付８桁＞××××××××のとき、「発注停止開始日付範囲エラー」をエラーログに出力（××××××××は予め設定された年月日を表す）
（４）発注停止終了日付範囲エラー
発注停止終了日付８桁＞××××××××のとき、「発注停止終了日付範囲エラー」をエラーログに出力
（５）催事発注用発注締め日範囲エラー
催事発注用発注締め日８桁＞××××××××のとき、「催事発注用発注締め日範囲エラー」をエラーログに出力
（６）値引き開始日範囲エラー
値引き開始日８桁＞××××××××のとき、「値引き開始日範囲エラー」をエラーログに出力
（７）値引き終了日範囲エラー
値引き終了日８桁＞××××××××のとき、「値引き終了日範囲エラー」をエラーログに出力
（８）ロット・入り数０エラー（レジストリ￥ＶＨＯＮＬＣＴＲ￥ＭＡＴＣＨＫ２＝１又は存在しない場合を判定する）
ロット数＝０  ｏｒ  入り数＝０のとき、「ロット・入り数０エラー」をエラーログに出力
（９）店着便Ｎｏ．範囲エラー（レジストリ￥ＶＨＯＮＬＣＴＲ￥ＭＡＴＣＨＫ３＝１又は存在しない場合を判定する）
店着便Ｎｏ．＜１  ｏｒ  店着便Ｎｏ．＞３の時「店着便Ｎｏ．範囲エラー」をエラーログに出力
（１０）便Ｎｏ．範囲エラー（￥ＶＨＯＮＬＣＴＲ￥ＭＡＴＣＨＫ４＝１又は存在しない場合を判定する）
便Ｎｏ．＜１  ｏｒ  便Ｎｏ．＞３の時「便Ｎｏ．範囲エラー」をエラーログに出力
（１１）店着便Ｎｏ．便Ｎｏ．不一致エラー（レジストリ￥ＶＨＯＮＬＣＴＲ￥ＭＡＴＣＨＫ５＝１又は存在しない場合を判定する）
店着便Ｎｏ．  ！＝便Ｎｏ．のとき、「店着便Ｎｏ．便Ｎｏ．不一致エラー」をエラーログに出力
（１２）最小発注数量＞最大発注数量エラー（レジストリ￥ＶＨＯＮＬＣＴＲ￥ＭＡＴＣＨＫ８＝１又は存在しない場合を判定する）
最小発注数量＞最大発注数量のとき、「最小発注数量＞最大発注数量エラー」をエラーログに出力
（１３）同一共通商品同一便エラー（レジストリ￥ＶＨＯＮＬＣＴＲ￥ＭＡＴＣＨＫ１＝１又は存在しない場合を判定する）
共通自社コードをキーにＣＢ＿ＪＡＮ＿ＫＥＹ＿ＴＢＬを読み込む（読める間を繰り返す）
抽出条件：共通自社コード＝単品追加変更データの共通自社コード
抽出項目：自社コード、便コード
（自社コード  ！＝単品追加変更データの自社コード）ａｎｄ（便コード＝単品追加変更データの便コード）のとき、「同一商品同一便エラー」をエラーログに出力
（１４）同一自社コード複数エラー（レジストリ￥ＶＨＯＮＬＣＴＲ￥ＭＡＴＣＨＫ６＝１又は存在しない場合を判定する）
自社コードをキーにＣＢ＿ＪＡＮ＿ＫＥＹ＿ＴＢＬを読み込む（読める間を繰り返す）
抽出条件：自社コード＝単品追加変更データの自社コード
抽出項目：共通自社コード
（共通自社コード  ！＝単品追加変更データの自社コードのとき、「同一自社コード複数エラー」をエラーログに出力
（１５）分類コード不一致エラー（レジストリ￥ＶＨＯＮＬＣＴＲ￥ＭＡＴＣＨＫ７＝１又は存在しない場合を判定する）
以上のように、前記「（１）適用日範囲エラー」〜「（１４）同一自社コード複数エラー」については、判定部２１１が更新条件格納部２３０に格納された値に基づいて判定を行い、エラー判定がなされる。一方、上記「（１５）分類コード不一致エラー」については、ワークテーブル作成部２１２がワークテーブル領域２５０に第１のワークテーブル２５１及び第２のワークテーブル２５２を作成して、このワークテーブルに分類データを格納して比較が行われる。
【００２５】
次に分類データの判定について説明する。図４は分類データの判定手順を示すフローチャート、図５乃至図９は分類データの判定中における第１及び第２のワークテーブルの状態を示す模式図である。
【００２６】
分類データの判定に際して、まず判定部２１１の指示により、ワークテーブル作成部２１２はワークテーブル領域２５０に第１のワークテーブル２５１と第２のワークテーブル２５２とを作成する（ステップＳＴ１１）。
【００２７】
図５に示すように、第１のワークテーブル２５１は、連番、共通自社コード、自社コード、大分類、中分類、小分類、チェック結果の項目を備える。また、第２のワークテーブル２５２は、共通自社コード、自社コード、大分類、中分類、小分類の項目を備える。
【００２８】
次いで、ワークテーブル作成部２１２は、図６に示すように、第１のワークテーブル２５１に共通自社コード、自社コード、分類（大、中、小）の変更データを書き込む（ステップＳＴ１２）。
【００２９】
次に、ワークテーブル作成部２１２は、図７に示すように、第１のワークテーブルの共通自社コードを基にして、マスタデータテーブル２２０のCB_JAN_OWN_BASのデータに基づいて第２のワークテーブル２５２の分類を更新する（ステップＳＴ１３）。
【００３０】
そして、ワークテーブル作成部２１２は、第１のワークテーブル２５１の連番順に第２のワークテーブル２５２を更新していき、第２のワークテーブル２５２に共通自社コード及び自社コードが存在しないときは新たなテーブルを挿入し（図８（１））、第２のワークテーブル２５２に共通自社コード及び自社コードが存在するときは項目の内容を更新する（図８（２））（ステップＳＴ１４）。
【００３１】
そして、判定部２１１は、第２のワークテーブル２５２に基づいて分類（大、中、小）が取得した更新データと一致するかをチェックし、同一でない場合、分類データが不正であるものとして、図９に示すように、第１のワークテーブル２５１の判定結果に「１」（ＮＧ）を格納する（ステップＳＴ１５）。これにより、分類データの判定がなされ、判定結果「１」のとき、「分類コード不一致エラー」となる。
【００３２】
上述した判定処理においてなされたエラー判定は、ログ生成部２１４によってログファイル格納部２４０にエラーログとして出力される。エラーログは以下のようにして作成される。
エラーログに格納されるデータは以下の通りである。
（１）メンテナンス日時（ＹＹＹＹＭＭＤＤＨＨＭＭＳＳ）単品追加変更マスタメンテ起動時の日時をセットする。
（２）ＰＬＵ（１４桁固定、右詰、頭“０”埋め）
（３）自社コード（１４桁固定、右詰、頭“０”埋め）
（４）共通自社コード（１４桁固定、右詰、頭“０”埋め）
（５）分類
大分類（３桁固定、右詰、頭“０”埋め）
中分類（３桁固定、右詰、頭“０”埋め）
小分類（３桁固定、右詰、頭“０”埋め）
（６）部門（３桁固定、右詰、頭“０”埋め）
（７）本部売価（６桁固定、右詰、頭スペース）
（８）課税区分（１桁固定）
（９）エラー理由（４０桁（全角２０文字）固定、左詰、余りスペース）
エラーログの出力先は、例えば、ｃ：￥ｃｖｓ￥ｄａｔａ￥ｍｎｔｅｒｒ￥とし、ファイル名は例えば「ｍｎｔｅｒｌｏｇ．ＭＤｎ」とされる。ここで、「．」以下の「ＭＤｎ」は以下の形式で付される拡張子である。
Ｍ：（月）１〜９、Ａ（１０月）、Ｂ（１１月）、Ｃ（１２月）
Ｄ：（日）１〜９、Ａ（１０日）からＶ（３１日）
ｎ：カウント１〜９（同一月日内で１〜９）
この拡張子により作成日及び作成番号が表示される。
【００３３】
例えば、１１月３０日に２回エラーログが作成された場合、
１回目のエラーログは、「ｍｎｔｅｒｌｏｇ．ＢＵ１」とされ、２回目のエラーログは、「ｍｎｔｅｒｌｏｇ．ＢＵ２」とされる。
【００３４】
本例では、以上のような内容でエラーログが生成されるので、エラーログの拡張子を確認するだけでエラーログの作成月日及び作成順が容易に認識でき、エラーログの確認を容易なものとすることができる。尚、このエラーログは一定期間、例えば３ヶ月経過した段階で消去するようにしてもよい。
【００３５】
以上説明したように、本発明に係るＰＯＳシステムにおけるマスタデータの更新方法によれば、真性データで更新される他の商品データに影響を及ぼすことが無くなる他、この更新の状態はログ生成行程で作成されるログファイルに記録されるので、不正データの確認及び訂正を迅速に行えるという効果を有する。
【図面の簡単な説明】
【００３６】
【図１】実施の形態例に係るマスタデータの更新方法が実行されるＰＯＳシステムを示すブロック図である。
【図２】店舗サーバの構成を示すブロック図である。
【図３】マスタデータテーブルの更新の手順を示すフローチャートである。
【図４】分類データの判定手順を示すフローチャートである。
【図５】分類データの判定中における第１及び第２のワークテーブルの状態を示す模式図である。
【図６】分類データの判定中における第１のワークテーブルの状態を示す模式図である。
【図７】分類データの判定中における第２のワークテーブルの状態を示す模式図である。
【図８】分類データの判定中における第２のワークテーブルの状態を示す模式図である。
【図９】分類データの判定中における第１のワークテーブルの状態を示す模式図である。
【符号の説明】
【００３７】
１０  店舗、２０  ホストベンダ、３０  回線、１００  ＰＯＳシステム、２００  店舗サーバ、４００  ホストサーバ
【図１】
0005038035.tif 000002
【図２】
0005038035.tif 000003
【図３】
0005038035.tif 000004
【図４】
0005038035.tif 000005
【図５】
0005038035.tif 000006
【図６】
0005038035.tif 000007
【図７】
0005038035.tif 000008
【図８】
0005038035.tif 000009
【図９】
0005038035.tif 000010