JP2017182794A - 業務データ変更チェック装置、業務データ変更チェック方法、および、業務データ変更チェックプログラム - Google Patents

Abstract

【課題】業務処理の実行順序や不正データの有無をチェックすることが可能な業務データ変更チェック装置、業務データ変更チェック方法、および、業務データ変更チェックプログラムを提供することを課題とする。【解決手段】業務データが変更されたことをチェックする業務データ変更チェック装置であって、警告がなければ業務処理が正しく行われていることを担保すると共に、処理の順序を逸脱した変更による誤支給などを防止し、業務毎に処理の流れの単位でチェックを行えるようにしたことを特徴とする。【選択図】図１

Description

本発明は、業務データ変更チェック装置、業務データ変更チェック方法、および、業務データ変更チェックプログラムに関する。

特許文献１によると、業務の変更可否データ定義手段と、変更可否データ格納手段、変更チェック定義手段と、変更チェック定義データ格納部、業務データの変更履歴を変更履歴データ格納部に格納する変更実施処理部、データ変更が発生したとき、データ変更を通知するためのデータ変更通知処理部、変更履歴から業務データの変更を元に戻すための変更データ復元処理部を設けたデータメンテナンスシステムが開示されている。

特開２００６−８５２２４号公報

上記したように特許文献１は、変更可否データ定義処理部は、業務データの進捗に対して変更が可能かどうかという定義・編集を行い、変更可否定義データ格納部に格納する。変更チェック定義処理部は、業務データを変更するときのチェック内容の定義・編集を行い、変更チェック定義データ格納部に格納する。変更実施処理部は、業務データ格納部に格納された、業務データの変更を実施する処理部であり、変更可否定義データ格納部のデータと、変更チェック定義データ格納部のデータを参照して、指定された業務データの変更を実施し、又、変更の履歴を変更履歴データ格納部に格納する。データ変更通知処理部は、担当者が必要と判断するときに起動され、通知先データ格納部に格納された通知先に、データ変更の通知を通信制御処理部を通じて電子メールにより実施するか、別システムとして存在するワークフローシステムにより実施している。しかしながら、特許文献１では、データ変更履歴テーブルと処理履歴テーブルの情報に基づいて、業務上不正なデータが出来ていないかをチェックすることができないという課題があった。

本発明は、上記問題点に鑑みてなされたものであって、業務処理の実行順序や不正データの有無をチェックすることが可能な業務データ変更チェック装置、業務データ変更チェック方法、および、業務データ変更チェックプログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明に係る業務データ変更チェック装置は、記憶部と制御部とを備えた業務データ変更チェック装置であって、前記記憶部は、処理順序が規定された業務に含まれる複数の業務処理の更新日時、当該業務処理の領域種別、および、当該業務処理の対象年月を含む処理履歴を記憶する処理履歴記憶手段と、前記業務処理の実行元となる実行元データの変更日時、当該実行元データの領域種別、および、当該実行元データの対象年月を含むデータ変更履歴を記憶するデータ変更履歴記憶手段と、を備え、前記制御部は、前記処理履歴を前記処理履歴記憶手段から取得する処理履歴取得手段と、前記処理履歴取得手段により取得された前記処理履歴に含まれる前記業務処理の領域種別および当該業務処理の対象年月と領域種別および対象年月が同一となる前記実行元データの前記変更日時であって、当該処理履歴に含まれる前記業務処理の更新日時よりも後の日時となる当該変更日時が、前記データ変更履歴記憶手段に記憶されているか否かを判定する変更判定手段と、前記変更判定手段により前記変更日時が記憶されていると判定された場合、警告通知を出力させる警告通知手段と、を備えたことを特徴とする。

また、本発明に係る業務データ変更チェック装置は、前記警告通知手段は、更に、前記業務処理の前記処理履歴、および、前記実行元データの前記データ変更履歴を出力させることを特徴とする。

また、本発明に係る業務データ変更チェック装置は、前記処理履歴は、更に、前記業務処理の処理種別の処理種別値、および、前記業務処理の処理順ランクのランク値を含み、前記処理履歴取得手段は、前記処理履歴記憶手段に同一の前記領域種別を含む複数の前記処理履歴が記憶されている場合、前記処理種別値および／または前記ランク値が小さい順に前記処理履歴を前記処理履歴記憶手段から取得することを特徴とする。

また、本発明に係る業務データ変更チェック装置は、前記データ変更履歴は、給与項目変更履歴であることを特徴とする。

また、本発明に係る業務データ変更チェック装置は、前記処理順序が規定された業務は、給与支払業務、賞与支払業務、または、社会保険業務であることを特徴とする。

また、本発明に係る業務データ変更チェック装置は、前記給与支払業務に含まれる前記複数の業務処理は、勤怠項目登録処理、給与計算処理、および、振込データ作成処理であることを特徴とする。

また、本発明に係る業務データ変更チェック方法は、記憶部と制御部とを備えた業務データ変更チェック装置に実行させるための業務データ変更チェック方法であって、前記記憶部は、処理順序が規定された業務に含まれる複数の業務処理の更新日時、当該業務処理の領域種別、および、当該業務処理の対象年月を含む処理履歴を記憶する処理履歴記憶手段と、前記業務処理の実行元となる実行元データの変更日時、当該実行元データの領域種別、および、当該実行元データの対象年月を含むデータ変更履歴を記憶するデータ変更履歴記憶手段と、を備え、前記制御部で実行させる、前記処理履歴を前記処理履歴記憶手段から取得する処理履歴取得ステップと、前記処理履歴取得ステップにて取得された前記処理履歴に含まれる前記業務処理の領域種別および当該業務処理の対象年月と領域種別および対象年月が同一となる前記実行元データの前記変更日時であって、当該処理履歴に含まれる前記業務処理の更新日時よりも後の日時となる当該変更日時が、前記データ変更履歴記憶手段に記憶されているか否かを判定する変更判定ステップと、前記変更判定ステップにて前記変更日時が記憶されていると判定された場合、警告通知を出力させる警告通知ステップと、を含むことを特徴とする。

また、本発明に係る業務データ変更チェックプログラムは、記憶部と制御部とを備えた業務データ変更チェック装置に実行させるための業務データ変更チェックプログラムであって、前記記憶部は、処理順序が規定された業務に含まれる複数の業務処理の更新日時、当該業務処理の領域種別、および、当該業務処理の対象年月を含む処理履歴を記憶する処理履歴記憶手段と、前記業務処理の実行元となる実行元データの変更日時、当該実行元データの領域種別、および、当該実行元データの対象年月を含むデータ変更履歴を記憶するデータ変更履歴記憶手段と、を備え、前記制御部において、前記処理履歴を前記処理履歴記憶手段から取得する処理履歴取得ステップと、前記処理履歴取得ステップにて取得された前記処理履歴に含まれる前記業務処理の領域種別および当該業務処理の対象年月と領域種別および対象年月が同一となる前記実行元データの前記変更日時であって、当該処理履歴に含まれる前記業務処理の更新日時よりも後の日時となる当該変更日時が、前記データ変更履歴記憶手段に記憶されているか否かを判定する変更判定ステップと、前記変更判定ステップにて前記変更日時が記憶されていると判定された場合、警告通知を出力させる警告通知ステップと、を実行させることを特徴とする。

本発明によれば、業務処理の実行順序や不正データの有無をチェックすることが可能になるという効果を奏する。

図１は、業務データ変更チェック装置の構成の一例を示すブロック図である。 図２は、本実施形態における業務データ変更チェック装置の処理の一例を示すフローチャートである。 図３は、給与支給による処理の流れの一例を示す図である。 図４は、給与計算後の状態を説明する図である。 図５は、給与計算後に情報を変更した場合の状態を説明する図である。 図６は、給与振込データ作成前チェックの出力内容を示す図である。 図７は、業務データ変更チェック装置の処理履歴によるチェック概要を説明する図である。 図８は、データ変更履歴テーブルの一例を示す図である。 図９は、処理履歴テーブルの一例を示す図である。 図１０は、処理履歴の領域種別の一例を示す図である。 図１１は、処理履歴の領域種別の一例を示す図である。 図１２は、処理履歴の領域種別の一例を示す図である。 図１３は、チェック定義マスタの一例を示す図である。 図１４は、ジョブ別チェックマスタの一例を示す図である。 図１５は、ジョブ別チェックマスタのジョブ毎の定義の一例を示す図である。 図１６は、チェック対象テーブルマスタの一例を示す図である。 図１７は、チェック定義マスタの種別と定義の一例を示す図である。

本発明の実施形態を図面に基づいて詳細に説明する。なお、本発明は本実施形態により限定されるものではない。

［１．概要］
従来から、データ変更履歴を取得する仕組みはあったが、不整合を起こしうる変更かどうかは、目検で確認する必要があった。例えば、給与業務などにおいては、処理の実行順序が不正に行われた場合に、変更されてはいけないデータ変更が行われることがあった。具体的には、勤怠データ入力→給与計算処理→振込データ作成処理の順で処理をする業務処理において、後処理実施後に前処理を行った場合、データの不整合が発生する可能性がある。そのため、従来は、不整合が発生していないかどうかについて帳票にて人が目検で調査していた。ここで、従来から、項目をロックして入力させないようにして、不整合を防ぐことも可能であったが、項目自体が汎用的に設定できる性質上、当該の項目を変更できないようにしてよいかどうか個社毎に異なるため、項目にロックをかける制御はできなかった。また、システムにロックをかける場合、処理全体がロックされてしまうため、給与支払に関わる部分以外の内容変更まで業務運用がストップしてしまうという問題点も有していた。

そこで、本実施形態においては、業務運用を止めないことを優先する仕組みとして、処理を許可しつつ変更の影響範囲を確認出来るようにしている。それにより、本実施形態においては、警告がなければ業務処理が正しく行われていることを担保でき、処理の順序を逸脱した変更による誤支給などを防止することを可能にしている。また、本実施形態においては、給与支払業務、賞与支払業務または社会保険業務など、業務毎に処理の流れが異なる場合であっても、その流れの単位でチェックを行えるような仕組みになっている。これにより、本実施形態においては、警告が出た際に、不整合を起こしうる変更と関係のない変更履歴を削除することができ、確認しなければならないデータ量を減らすことを可能としている。

［２．構成］
本実施形態に係る業務データ変更チェック装置の構成の一例について、図１を参照して説明する。図１は、業務データ変更チェック装置の構成の一例を示すブロック図である。

業務データ変更チェック装置１００は、市販のデスクトップ型パーソナルコンピュータである。なお、業務データ変更チェック装置１００は、デスクトップ型パーソナルコンピュータのような据置型情報処理装置に限らず、市販されているノート型パーソナルコンピュータ、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）、スマートフォン、タブレット型パーソナルコンピュータなどの携帯型情報処理装置であってもよい。

業務データ変更チェック装置１００は、制御部１０２と通信インターフェース部１０４と記憶部１０６と入出力インターフェース部１０８と、を備えている。業務データ変更チェック装置１００が備えている各部は、任意の通信路を介して通信可能に接続されている。

通信インターフェース部１０４は、ルータ等の通信装置及び専用線等の有線又は無線の通信回線を介して、業務データ変更チェック装置１００をネットワーク３００に通信可能に接続する。通信インターフェース部１０４は、他の装置と通信回線を介してデータを通信する機能を有する。ここで、ネットワーク３００は、業務データ変更チェック装置１００とサーバ２００とを相互に通信可能に接続する機能を有し、例えばインターネットやＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等である。

記憶部１０６には、各種のデータベース、テーブル、及びファイルなどが格納される。記憶部１０６には、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）と協働してＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）に命令を与えて各種処理を行うためのコンピュータプログラムが記録される。記憶部１０６として、例えば、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）・ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等のメモリ装置、ハードディスクのような固定ディスク装置、フレキシブルディスク、及び光ディスク等を用いることができる。記憶部１０６は、処理履歴テーブル１０６ａと、データ変更履歴テーブル１０６ｂと、チェック定義マスタ１０６ｃと、ジョブ別チェックマスタ１０６ｄと、チェック対象テーブルマスタ１０６ｅとを備えている。

処理履歴テーブル１０６ａは、処理順序が規定された業務に含まれる複数の業務処理の更新日時、当該業務処理の領域種別、および、当該業務処理の対象年月を含む処理履歴を記憶する。ここで、処理履歴は、更に、業務処理の処理種別の処理種別値、業務処理の処理順ランクのランク値、賞与区分の値、連番の値、実行元データの領域種別である実行領域種別、および／または、備考等を含んでいてもよい。また、処理順序が規定された業務は、給与支払業務、賞与支払業務、社会保険業務、一時金支払業務、年末調整業務、有給（休暇）付与業務、貸付金貸付実行業務、給与遡及業務、または、退職金支払業務等であってもよい。ここで、給与支払業務に含まれる複数の業務処理は、勤怠項目（勤怠データ）登録処理、給与計算処理、および、振込データ作成処理であってもよい。このように、処理履歴テーブル１０６ａは、いつどんな処理を行ったかを保持していてもよい。例えば、処理履歴テーブル１０６ａは、実行元データ（社員情報等）が変更されても給与項目履歴に出力していない処理（人給連携等）の実行履歴を登録してもよい。また、処理履歴テーブル１０６ａは、主に、領域生成や計算処理の実行日時を取得する目的、および、データ変更履歴テーブル１０６ｂに履歴が出力されない処理の実行日時を取得する目的で使用されてもよい。

データ変更履歴テーブル１０６ｂは、業務処理の実行元となる実行元データの変更日時、当該実行元データの領域種別、および、当該実行元データの対象年月を含むデータ変更履歴を記憶する。ここで、データ変更履歴は、給与項目変更履歴であってもよい。また、データ変更履歴は、更に、実行元データが登録（記憶）されたテーブル等の名称、項目名称、賞与区分の値、従業員（社員）コード、変更前の値、および／または、変更後の値を含んでいてもよい。また、実行元データは、勤怠項目（勤怠データ）、または、給与データ等であってもよい。ここで、勤怠項目は、勤怠項目登録処理により登録されたデータであってもよい。また、給与データは、給与計算処理により算出されたデータであってもよい。また、データ変更履歴テーブル１０６ｂは、実行元データ（社員情報等）が変更される際の履歴を項目別に保持していてもよい。また、データ変更履歴テーブル１０６ｂは、操作履歴管理ジョブで使用されてもよい。また、データ変更履歴テーブル１０６ｂにおいて、変更されたテーブルのキー情報は、変更元のテーブルに応じて、キー項目０１から１０に更新されてもよい。

チェック定義マスタ１０６ｃは、処理履歴によるチェックを行うストアド名を特定するチェック定義マスタである。ここで、処理チェックリストにて選択された定義番号から該当するレコードを取得し、チェック定義マスタ１０６ｃを用いて、チェックに使用するストアドを特定してもよい。

ジョブ別チェックマスタ１０６ｄは、個別のジョブにチェック機能を割り当てるジョブ別チェックマスタである。ここで、ジョブ別チェックマスタ１０６ｄにデータを登録することで、起動時にチェックを実行したり、チェックボタンを表示させたりすることができる。

チェック対象テーブルマスタ１０６ｅは、データ変更履歴を取得する際に、どのデータ変更履歴を参照するか特定するためのチェック対象テーブルマスタである。また、チェック対象テーブルマスタ１０６ｅは、改定年月が登録されて場合、どの改定年月を使用するかについてのデータも保持していてもよい。

入出力インターフェース部１０８には、入力装置１１２及び出力装置１１４が接続されている。出力装置１１４には、モニタ（家庭用テレビを含む）の他、スピーカやプリンタを用いることができる。入力装置１１２には、キーボード、マウス、及びマイクの他、マウスと協働してポインティングデバイス機能を実現するモニタを用いることができる。なお、以下では、出力装置１１４をモニタ１１４とし、入力装置１１２をキーボード１１２またはマウス１１２として記載する場合がある。

制御部１０２は、業務データ変更チェック装置１００を統括的に制御するＣＰＵ等である。制御部１０２は、ＯＳ等の制御プログラム・各種の処理手順等を規定したプログラム・所要データなどを格納するための内部メモリを有し、格納されているこれらのプログラムに基づいて種々の情報処理を実行する。制御部１０２は、機能概念的に、処理履歴取得部１０２ａと、変更判定部１０２ｂと、警告通知部１０２ｃとを備えている。

処理履歴取得部１０２ａは、処理履歴を処理履歴テーブル１０６ａから取得する。ここで、処理履歴取得部１０２ａは、処理履歴テーブル１０６ａに同一の領域種別を含む複数の処理履歴が記憶されている場合、業務処理の処理種別の処理種別値および／または業務処理の処理順ランクのランク値が小さい順に処理履歴を処理履歴テーブル１０６ａから取得してもよい。

変更判定部１０２ｂは、処理履歴取得部１０２ａにより取得された処理履歴に含まれる業務処理の領域種別および当該業務処理の対象年月と領域種別および対象年月が同一となる業務処理の実行元となる実行元データの変更日時であって、当該処理履歴に含まれる業務処理の更新日時よりも後の日時となる当該変更日時が、データ変更履歴テーブル１０６ｂに記憶されているか否かを判定する。

警告通知部１０２ｃは、警告通知を出力させる。ここで、警告通知部１０２ｃは、変更判定部１０２ｂにより変更日時が記憶されていると判定された場合、警告通知を出力させてもよい。また、警告通知部１０２ｃは、更に、業務処理の処理履歴、および、実行元データのデータ変更履歴を出力させてもよい。また、警告通知は、後処理に影響を与える実行元データの変更がされた（不整合が発生している）可能性がある旨の通知であってもよい。また、警告通知部１０２ｃは、警告通知を出力装置１１４に表示させてもよい。また、警告通知部１０２ｃは、変更判定部１０２ｂにより変更日時が記憶されていないと判定された場合、処理続行可能である旨の通知を出力させてもよい。

［３．具体例］
本実施形態の具体例について、図２から図１７を参照して説明する。

［業務データ変更チェック処理］
ここで、図２を参照して、本実施形態における業務データ変更チェック処理の一例について説明する。図２は、本実施形態における業務データ変更チェック装置１００の処理の一例を示すフローチャートである。

図２に示すように、処理履歴取得部１０２ａは、給与支払業務に含まれる給与計算処理の更新日時、当該給与計算処理の領域種別、および、当該給与計算処理の対象年月を含む処理履歴を処理履歴テーブル１０６ａから取得する（ステップＳＡ−１）。

そして、変更判定部１０２ｂは、処理履歴取得部１０２ａにより取得された処理履歴に含まれる給与計算処理の領域種別および当該給与計算処理の対象年月と領域種別および対象年月が同一となる給与計算処理の実行元となる実行元データ（給与計算処理の前処理である勤怠項目登録処理により登録されたデータ）である勤怠項目の変更日時であって、当該処理履歴に含まれる給与計算処理の更新日時よりも後の日時となる当該変更日時が、データ変更履歴テーブル１０６ｂに記憶されているか否かを判定する（ステップＳＡ−２）。

そして、変更判定部１０２ｂは、変更日時が記憶されていると判定した場合（ステップＳＡ−２：Ｙｅｓ）、処理をステップＳＡ−３に移行させる。

そして、警告通知部１０２ｃは、給与計算処理の後処理である振込データ作成処理に影響を与える勤怠項目の変更がされた可能性がある旨の警告通知、ならびに、給与計算処理の処理履歴、および、当該勤怠項目のデータ変更履歴を出力装置１１４に表示させ（ステップＳＡ−３）、処理を終了する。

一方、変更判定部１０２ｂは、変更日時が記憶されていないと判定した場合（ステップＳＡ−２：Ｎｏ）、処理を終了する。ここで、警告通知部１０２ｃは、給与計算処理の後処理である振込データ作成処理の処理続行可能である旨の通知を出力装置１１４に表示させた後、処理を終了してもよい。

ここで、図３から図６を参照して、本実施形態における給与支払業務の具体的処理の一例について説明する。図３は、給与支給による処理の流れの一例を示す図である。図４は、給与計算後の状態ある。図５は、給与計算後に情報を変更した場合の状態を説明する図である。図６は、給与振込データ作成前チェックの出力内容を示す図である。

図３には、本実施形態の給与支給業務における処理の流れが記載されている。図４には、給与計算処理後の処理履歴テーブル１０６ａに記憶された処理履歴、データ変更履歴テーブル１０６ｂに記憶されたデータ変更履歴（給与項目履歴）、および、実行元データである社員勤怠テーブルの勤怠データの状態が示されている。ここで、社員勤怠テーブルの普通残業時間の欄における項目名は、時間００１のような汎用的な項目を用いてもよい。なお、社員勤怠テーブルにおいて、賞与区分の欄が給与の場合、普通残業時間の欄には、普通残業時間のデータを示されているが、賞与区分の欄が賞与の場合、普通残業時間の欄には、普通残業時間のデータを示されていない。

そして、図５には、図４における給与計算処理後の状態から、データ変更がされた場合の処理履歴テーブル１０６ａに記憶された処理履歴、データ変更履歴テーブル１０６ｂに記憶されたデータ変更履歴、および、社員勤怠テーブルの勤怠データの状態が示されている。ここで、図５に示すように、給与計算処理後に、社員の勤怠情報（社員勤怠テーブルの普通残業時間）のデータがユーザにより変更されたことで、給与計算処理の計算結果との乖離が発生している。

そこで、図６に示すように、本実施形態においては、振込データ作成前にチェック処理を実行、給与計算後に変更されたデータを（２ＸＸ５／１１／２０ １４：３０：００に）取得し、振込データ作成前チェックの出力内容として出力することができる。すなわち、図６に示すように、本実施形態においては、処理履歴テーブル１０６ａから、最後の給与計算の更新日時（最終給与計算処理日時）を取得し、データ変更履歴テーブル１０６ｂから、同じ対象年月・領域（給与）の社員勤怠テーブルのデータで最終給与計算処理日時以降の履歴日時（変更日時）のデータの取得を試み、当該履歴日時が取得された場合、不正データ候補とみなし、これらの処理履歴およびデータ変更履歴のデータをリスト化して出力することができる。

ここで、本実施形態においては、処理履歴の領域種別について、チェック種類によって、検索対象となる処理履歴、および／または、データ変更履歴が変わるため、処理履歴に領域種別を持たせている。例えば、本実施形態においては、給与支給にかかるチェックの場合、処理履歴の領域種別として給与の最終給与計算処理日時を取得してもよい。また、本実施形態において、同一領域種別内での処理は、処理履歴の処理種別および／または処理順ランクの値が若い者から順に行われるように運用してもよい。例えば、本実施形態においては、処理種別：１０の一括セット・扶養者税区分の処理が、処理種別：５０の給与計算の後に行われるのは、扶養者情報が変わると源泉所得税が変わってしまうため、正しい運用の順番ではない。また、本実施形態において、チェックにかかる項目が全て特定可能であればロック制御を掛けることで不正データを完全に防ぐことができるが、項目が汎用的に設定できるため、更新されても不正データではないこともありえる。そこで、本実施形態においては、そういった汎用的に設定できる項目に対して、ロックを掛けてしまうと変更したいのにできなくなってしまうため、ロック制御ではなく警告表示を採用している。

また、図７を参照して、本実施形態おける処理履歴によるチェック概要の一例について説明する。図７は、業務データ変更チェック装置１００の処理履歴によるチェック概要を説明する図である。

図７には、本実施形態に係る業務データ変更チェック装置１００の概要、関係するテーブル、新規でカスタムチェックする手順、および、個別ジョブにチェック機能を追加する手順について示されている。ここで、図７に示すように、本実施形態において、処理チェックリストは、指定された定義番号に対応するチェックストアドを実行させ、データをリスト表示してもよい。また、図７に示すように、本実施形態において、個別のジョブは、起動時、または、チェックボタン押下時に処理チェックを実行させ、チェック結果にデータが存在する場合、その定義番号を記載したアラートのメッセージボックスを表示してもよい。また、図７に示すように、本実施形態において、ジョブ別チェックマスタ１０６ｄにデータを登録することで、起動時にチェックを実行したり、チェックボタンを表示させたりすることができる。また、本実施形態における仕組みでは、給与計算処理後のデータ変更履歴および処理履歴を確認することが出来るため、データ変更の影響を個別かつ具体的に判断出来るようになった。また、本実施形態においては、履歴の変更または処理順序の変更が１件以上存在する場合、システム上警告を出すようにしてもよい。

ここで、本実施形態におけるチェック定義マスタ１０６ｃは、ストアドの名前を管理するマスタであり、ジョブ別チェックマスタ１０６ｄは、ジョブ・ボタン単位にチェックするストアド名と処理順序を管理するものである。従来からデータの変更履歴を取る仕組み自体はあったが、本実施形態においては、データ変更履歴と処理履歴（共通の操作ログではなく業務処理ログ）とに基づいて判断する点が従来と異なっている。また、本実施形態においては、業務独自のログ種別（ログ領域）によって情報を判断するために、処理履歴を特別なログとして用意している。

また、本実施形態においては、勤怠項目の項目数・計算定義等が顧客単位に自由に設定できることから、チェック対象項目が顧客単位に違うため、チェック機能を構築単位に汎用的に設定できるようにしている。また、本実施形態においては、顧客の運用によって、当月どこまで処理するかが変わってくるため、チェック機能を構築単位に汎用的に設定できるようにしている。

また、図８から図１７を参照して、本実施形態におけるデータ構成の一例について説明する。図８は、データ変更履歴テーブル１０６ｂの一例を示す図である。図９は、処理履歴テーブル１０６ａの一例を示す図である。図１０は、処理履歴の領域種別の一例を示す図である。図１１は、処理履歴の領域種別の一例を示す図である。図１２は、処理履歴の領域種別の一例を示す図である。図１３は、チェック定義マスタ１０６ｃの一例を示す図である。図１４は、ジョブ別チェックマスタ１０６ｄの一例を示す図である。図１５は、ジョブ別チェックマスタ１０６ｄのジョブ毎の定義の一例を示す図である。図１６は、チェック対象テーブルマスタ１０６ｅの一例を示す図である。図１７は、チェック定義マスタ１０６ｃの種別と定義の一例を示す図である。

図８には、本実施形態におけるデータ（給与項目）変更履歴テーブル１０６ｂに記憶された給与項目変更履歴の一例が示されており、Ｎｏ．１８およびＮｏ．１９に、更新前後の値が示されている。また、図９には、本実施形態において、会社毎の計算定義を管理するテーブルである処理履歴テーブル１０６ａが示されている。また、図１０には、本実施形態の給与支払業務、賞与支払業務、一時金支払業務、および、社会保険業務における処理履歴の領域種別が示されている。また、図１１には、本実施形態の年末調整業務、有給付与業務、貸付金貸付実行業務、および、給与遡及業務における処理履歴の領域種別が示されている。また、図１２には、本実施形態の退職金支払業務における処理履歴の領域種別が示されている。また、図１３には、本実施形態におけるチェック定義マスタ１０６ｃが示されている。また、図１４には、本実施形態におけるジョブ別チェックマスタ１０６ｄが示されている。また、図１５には、本実施形態のジョブ別チェックマスタ１０６ｄにおけるジョブ毎の定義が示されている。また、図１６には、本実施形態におけるチェック対象テーブルマスタ１０６ｅが示されている。また、図１７には、本実施形態のチェック定義マスタ１０６ｃにおける種別および定義が示されている。

このように、本実施形態においては、データ変更履歴テーブル１０６ｂと処理履歴テーブル１０６ａとの情報に基づいて、業務上不正なデータが出来ていないかをチェックする仕組みを提供しており、特に、処理履歴テーブル１０６ａの管理方法（業務的な内容を含む）、および、データ変更履歴をもとにしたチェック方法を特徴としている。

それにより、本実施形態においては、業務処理の実行順序や不正データの有無をチェックし、業務処理の順番が正しく行われていなかったり、不正データがあったりした場合、警告を行うことにより、処理を止めることなくデータ変更の影響範囲が確認できるようにしている。

［４．他の実施形態］
本発明は、上述した実施形態以外にも、特許請求の範囲に記載した技術的思想の範囲内において種々の異なる実施形態にて実施されてよいものである。

例えば、実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。

また、本明細書中や図面中で示した処理手順、制御手順、具体的名称、各処理の登録データや検索条件等のパラメータを含む情報、画面例、データベース構成については、特記する場合を除いて任意に変更することができる。

また、業務データ変更チェック装置１００に関して、図示の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。

例えば、業務データ変更チェック装置１００が備える処理機能、特に制御部１０２にて行われる各処理機能については、その全部または任意の一部を、ＣＰＵおよび当該ＣＰＵにて解釈実行されるプログラムにて実現してもよく、また、ワイヤードロジックによるハードウェアとして実現してもよい。尚、プログラムは、本実施形態で説明した処理を情報処理装置に実行させるためのプログラム化された命令を含む一時的でないコンピュータ読み取り可能な記録媒体に記録されており、必要に応じて業務データ変更チェック装置１００に機械的に読み取られる。すなわち、ＲＯＭまたはＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの記憶部などには、ＯＳと協働してＣＰＵに命令を与え、各種処理を行うためのコンピュータプログラムが記録されている。このコンピュータプログラムは、ＲＡＭにロードされることによって実行され、ＣＰＵと協働して制御部を構成する。

また、このコンピュータプログラムは、業務データ変更チェック装置１００に対して任意のネットワークを介して接続されたアプリケーションプログラムサーバに記憶されていてもよく、必要に応じてその全部または一部をダウンロードすることも可能である。

また、本実施形態で説明した処理を実行するためのプログラムを、一時的でないコンピュータ読み取り可能な記録媒体に格納してもよく、また、プログラム製品として構成することもできる。ここで、この「記録媒体」とは、メモリーカード、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリ、ＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）カード、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（登録商標）（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＭＯ（Ｍａｇｎｅｔｏ−Ｏｐｔｉｃａｌ ｄｉｓｋ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、および、Ｂｌｕ−ｒａｙ（登録商標） Ｄｉｓｃ等の任意の「可搬用の物理媒体」を含むものとする。

また、「プログラム」とは、任意の言語または記述方法にて記述されたデータ処理方法であり、ソースコードまたはバイナリコード等の形式を問わない。なお、「プログラム」は必ずしも単一的に構成されるものに限られず、複数のモジュールやライブラリとして分散構成されるものや、ＯＳに代表される別個のプログラムと協働してその機能を達成するものをも含む。なお、実施形態に示した各装置において記録媒体を読み取るための具体的な構成および読み取り手順ならびに読み取り後のインストール手順等については、周知の構成や手順を用いることができる。

記憶部１０６に格納される各種のデータベース等は、ＲＡＭ、ＲＯＭ等のメモリ装置、ハードディスク等の固定ディスク装置、フレキシブルディスク、及び、光ディスク等のストレージ手段であり、各種処理やウェブサイト提供に用いる各種のプログラム、テーブル、データベース、及び、ウェブページ用ファイル等を格納する。

また、業務データ変更チェック装置１００は、既知のパーソナルコンピュータまたはワークステーション等の情報処理装置として構成してもよく、また、任意の周辺装置が接続された当該情報処理装置として構成してもよい。また、業務データ変更チェック装置１００は、当該装置に本実施形態で説明した処理を実現させるソフトウェア（プログラムまたはデータ等を含む）を実装することにより実現してもよい。

更に、装置の分散・統合の具体的形態は図示するものに限られず、その全部または一部を、各種の付加等に応じてまたは機能負荷に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。すなわち、上述した実施形態を任意に組み合わせて実施してもよく、実施形態を選択的に実施してもよい。

本発明は、特に、給与・賞与支払業務、社会保険業務といった業務ごとに処理の流れのある業務における不正データのチェックなどにおいて有用である。

１００ 業務データ変更チェック装置
１０２ 制御部
１０２ａ 処理履歴取得部
１０２ｂ 変更判定部
１０２ｃ 警告通知部
１０４ 通信インターフェース部
１０６ 記憶部
１０６ａ 処理履歴テーブル
１０６ｂ データ変更履歴テーブル
１０６ｃ チェック定義マスタ
１０６ｄ ジョブ別チェックマスタ
１０６ｅ チェック対象テーブルマスタ
１０８ 入出力インターフェース部
１１２ 入力装置
１１４ 出力装置
２００ サーバ
３００ ネットワーク

Claims (8)

1. 記憶部と制御部とを備えた業務データ変更チェック装置であって、
   前記記憶部は、
   処理順序が規定された業務に含まれる複数の業務処理の更新日時、当該業務処理の領域種別、および、当該業務処理の対象年月を含む処理履歴を記憶する処理履歴記憶手段と、
   前記業務処理の実行元となる実行元データの変更日時、当該実行元データの領域種別、および、当該実行元データの対象年月を含むデータ変更履歴を記憶するデータ変更履歴記憶手段と、
   を備え、
   前記制御部は、
   前記処理履歴を前記処理履歴記憶手段から取得する処理履歴取得手段と、
   前記処理履歴取得手段により取得された前記処理履歴に含まれる前記業務処理の領域種別および当該業務処理の対象年月と領域種別および対象年月が同一となる前記実行元データの前記変更日時であって、当該処理履歴に含まれる前記業務処理の更新日時よりも後の日時となる当該変更日時が、前記データ変更履歴記憶手段に記憶されているか否かを判定する変更判定手段と、
   前記変更判定手段により前記変更日時が記憶されていると判定された場合、警告通知を出力させる警告通知手段と、
   を備えたことを特徴とする業務データ変更チェック装置。
2. 前記警告通知手段は、
   更に、前記業務処理の前記処理履歴、および、前記実行元データの前記データ変更履歴を出力させることを特徴とする請求項１に記載の業務データ変更チェック装置。
3. 前記処理履歴は、
   更に、前記業務処理の処理種別の処理種別値、および、前記業務処理の処理順ランクのランク値を含み、
   前記処理履歴取得手段は、
   前記処理履歴記憶手段に同一の前記領域種別を含む複数の前記処理履歴が記憶されている場合、前記処理種別値および／または前記ランク値が小さい順に前記処理履歴を前記処理履歴記憶手段から取得することを特徴とする請求項１または２に記載の業務データ変更チェック装置。
4. 前記データ変更履歴は、
   給与項目変更履歴であることを特徴とする請求項１から３のいずれか一つに記載の業務データ変更チェック装置。
5. 前記処理順序が規定された業務は、
   給与支払業務、賞与支払業務、または、社会保険業務であることを特徴とする請求項１から４のいずれか一つに記載の業務データ変更チェック装置。
6. 前記給与支払業務に含まれる前記複数の業務処理は、
   勤怠項目登録処理、給与計算処理、および、振込データ作成処理であることを特徴とする請求項５に記載の業務データ変更チェック装置。
7. 記憶部と制御部とを備えた業務データ変更チェック装置に実行させるための業務データ変更チェック方法であって、
   前記記憶部は、
   処理順序が規定された業務に含まれる複数の業務処理の更新日時、当該業務処理の領域種別、および、当該業務処理の対象年月を含む処理履歴を記憶する処理履歴記憶手段と、
   前記業務処理の実行元となる実行元データの変更日時、当該実行元データの領域種別、および、当該実行元データの対象年月を含むデータ変更履歴を記憶するデータ変更履歴記憶手段と、
   を備え、
   前記制御部で実行させる、
   前記処理履歴を前記処理履歴記憶手段から取得する処理履歴取得ステップと、
   前記処理履歴取得ステップにて取得された前記処理履歴に含まれる前記業務処理の領域種別および当該業務処理の対象年月と領域種別および対象年月が同一となる前記実行元データの前記変更日時であって、当該処理履歴に含まれる前記業務処理の更新日時よりも後の日時となる当該変更日時が、前記データ変更履歴記憶手段に記憶されているか否かを判定する変更判定ステップと、
   前記変更判定ステップにて前記変更日時が記憶されていると判定された場合、警告通知を出力させる警告通知ステップと、
   を含むことを特徴とする業務データ変更チェック方法。
8. 記憶部と制御部とを備えた業務データ変更チェック装置に実行させるための業務データ変更チェックプログラムであって、
   前記記憶部は、
   処理順序が規定された業務に含まれる複数の業務処理の更新日時、当該業務処理の領域種別、および、当該業務処理の対象年月を含む処理履歴を記憶する処理履歴記憶手段と、
   前記業務処理の実行元となる実行元データの変更日時、当該実行元データの領域種別、および、当該実行元データの対象年月を含むデータ変更履歴を記憶するデータ変更履歴記憶手段と、
   を備え、
   前記制御部において、
   前記処理履歴を前記処理履歴記憶手段から取得する処理履歴取得ステップと、
   前記処理履歴取得ステップにて取得された前記処理履歴に含まれる前記業務処理の領域種別および当該業務処理の対象年月と領域種別および対象年月が同一となる前記実行元データの前記変更日時であって、当該処理履歴に含まれる前記業務処理の更新日時よりも後の日時となる当該変更日時が、前記データ変更履歴記憶手段に記憶されているか否かを判定する変更判定ステップと、
   前記変更判定ステップにて前記変更日時が記憶されていると判定された場合、警告通知を出力させる警告通知ステップと、
   を実行させるための業務データ変更チェックプログラム。

Images