(57)【要約】【課題】伝票の起票漏れを抑制する。【解決手段】チェック部は、定期的に起票する伝票の過去の起票状況を格納する伝票チェック通知管理マスタ４０を参照して、過去の単位期間（例えば１カ月間）における伝票の起票数の傾向と、現在を含む単位期間（例えば直近１カ月）における伝票の起票数の傾向とに基づき、現在の起票数が不足している場合に、伝票の起票状況が不足していることをメール送信部を介して通知する。【選択図】図１８
2020197813.tif 000002
【特許請求の範囲】
【請求項１】
定期的に起票する伝票の過去の起票状況を格納する記憶部を参照して、過去の単位期間における前記伝票の起票数の傾向と、現在を含む単位期間における前記伝票の起票数の傾向とに基づき、現在の起票数が不足している場合に、前記伝票の起票状況が不足していることを通知する、
処理をコンピュータに実行させるための起票漏れ抑制プログラム。
【請求項２】
前記通知する処理では、前記記憶部を参照して、前記伝票の締日と前記通知を行う日との差を特定し、特定した差に応じて通知内容を異ならせることを特徴とする請求項１に記載の起票漏れ抑制プログラム。
【請求項３】
前記通知する処理では、前記記憶部を参照して、前記過去の単位期間において前記伝票を起票した人の起票時の所属部門と現在の所属部門とを特定し、前記起票時の所属部門と前記現在の所属部門が同一であるか異なるかに応じて、通知先を異ならせることを特徴とする請求項１又は２に記載の起票漏れ抑制プログラム。
【請求項４】
前記通知する処理では、前記伝票を起票する人が現在の所属部門に所属している期間、及び前記記憶部に格納されている前記伝票を起票する人の過去の実績、の少なくとも一方に基づいて、通知内容を異ならせることを特徴とする請求項１〜３のいずれか一項に記載の起票漏れ抑制プログラム。
【請求項５】
前記通知する処理では、前記現在の起票数が不足しているかを、前記過去の単位期間における前記伝票の起票数の伸率を考慮して判断する、ことを特徴とする請求項１〜４のいずれか一項に記載の起票漏れ抑制プログラム。
【請求項６】
定期的に起票する伝票の過去の起票状況を格納する記憶部を参照して、過去の単位期間における前記伝票の起票数の傾向と、現在を含む単位期間における前記伝票の起票数の傾向とに基づき、現在の起票数が不足している場合に、前記伝票の起票状況が不足していることを通知する、
処理をコンピュータが実行することを特徴とする起票漏れ抑制方法。
【請求項７】
伝票を起票する人が利用する端末と、前記端末と接続され、前記伝票に関する処理を実行する情報処理装置とを備える情報処理システムであって、
定期的に起票する伝票の過去の起票状況を格納する記憶部と、
前記記憶部を参照して、過去の単位期間における前記伝票の起票数の傾向と、現在を含む単位期間における前記伝票の起票数の傾向とに基づき、現在の起票数が不足している場合に、前記伝票の起票状況が不足していることを通知する通知部と、
を備える情報処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、起票漏れ抑制プログラム及び方法、並びに情報処理システムに関する。
【背景技術】
【０００２】
従来、会社間で取引が発生した時点で伝票が日々起票されており、伝票の起票には経理システムが利用されている。近年、インターネットを介したクラウド環境で動作可能な経理ソフトにより、伝票データを管理することが可能となってきている（例えば、特許文献１等参照）。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００８−１８１２３６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、経理システムを利用した場合でも、担当者に支払いに関する情報が届かなければ、担当者は起票すべき伝票に気づかず、起票漏れが生じるおそれがある。
【０００５】
１つの側面では、本発明は、伝票の起票漏れを抑制することが可能な起票漏れ抑制プログラム及び方法、並びに情報処理システムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
一つの態様では、起票漏れ抑制プログラムは、定期的に起票する伝票の過去の起票状況を格納する記憶部を参照して、過去の単位期間における前記伝票の起票数の傾向と、現在を含む単位期間における前記伝票の起票数の傾向とに基づき、現在の起票数が不足している場合に、前記伝票の起票状況が不足していることを通知する、処理をコンピュータに実行させるための起票漏れ抑制プログラムである。
【発明の効果】
【０００７】
伝票の起票漏れを抑制することができる。
【図面の簡単な説明】
【０００８】
【図１】一実施形態に係る経理システムの構成を概略的に示す図である。
【図２】図２（ａ）は、サーバのハードウェア構成を示す図であり、図２（ｂ）は、端末のハードウェア構成を示す図である。
【図３】サーバの機能ブロック図である。
【図４】図４（ａ）は、管理マスタを示す図であり、図４（ｂ）は、日付マスタを示す図である。
【図５】伝票チェック管理マスタを示す図である。
【図６】対象伝票マスタを示す図である。
【図７】図７（ａ）は、社員マスタを示す図であり、図７（ｂ）は、部門マスタを示す図である。
【図８】図８（ａ）は、異動履歴マスタを示す図であり、図８（ｂ）は、配属マスタを示す図である。
【図９】取引先マスタを示す図である。
【図１０】伝票ジャーナルを示す図である。
【図１１】伝票チェック通知管理マスタを示す図である。
【図１２】伝票チェック通知管理マスタの作成処理を示すフローチャートである。
【図１３】チェック枚数を伸率で算出する方法を示す図である。
【図１４】起票漏れの可能性チェック処理を示すフローチャートである。
【図１５】図１４のステップＳ３２の詳細処理を示すフローチャートである。
【図１６】図１４のステップＳ３４の詳細処理を示すフローチャートである。
【図１７】図１４のステップＳ３６の詳細処理を示すフローチャートである。
【図１８】図１８（ａ）は、チェックタイミング１用のメール内容を示す図であり、図１８（ｂ）は、チェックタイミング２用のメール内容を示す図である。
【図１９】図１９（ａ）は、チェックタイミング３用のメール内容を示す図であり、図１９（ｂ）は、チェックタイミング４用のメール内容を示す図である。
【図２０】メール宛先として部門長を設定する場合のメール内容を示す図である。
【図２１】伝票チェック通知管理マスタの更新処理を示すフローチャートである。
【図２２】返信メールの例を示す図（その１）である。
【図２３】返信メールの例を示す図（その２）である。
【発明を実施するための形態】
【０００９】
以下、経理システムの一実施形態について、図１〜図２３に基づいて詳細に説明する。図１には、一実施形態に係る経理システム１００の構成が概略的に示されている。経理システム１００は、会社の経理担当者が入力するデータに基づいて、経理処理を実行するシステムである。例えば、経理システム１００は、経理担当者が伝票のデータを入力した場合に、起票処理を実行する。
【００１０】
本実施形態の経理システム１００は、図１に示すように、情報処理装置としてのサーバ１０と、複数の端末７０と、を備える。サーバ１０と端末７０は、インターネットやＬＡＮ（Local Area Network）などのネットワーク８０に接続されている。端末７０は、伝票の起票を行う者（起票者）が利用するＰＣ（Personal Computer）等である。
【００１１】
サーバ１０は、一例として、端末７０から入力された伝票のデータに基づいて、起票処理を実行するとともに、起票漏れの可能性がある場合に、担当者等の端末７０に対してその旨を通知する。
【００１２】
図２（ａ）には、サーバ１０のハードウェア構成が示されている。図２（ａ）に示すように、サーバ１０は、ＣＰＵ（Central Processing Unit）９０、ＲＯＭ（Read Only Memory）９２、ＲＡＭ（Random Access Memory）９４、記憶部（ここではＨＤＤ（Hard Disk Drive））９６、ネットワークインタフェース９７、及び可搬型記憶媒体用ドライブ９９等を備えている。これらサーバ１０の構成各部は、バス９８に接続されている。サーバ１０では、ＲＯＭ９２あるいはＨＤＤ９６に格納されているプログラム（起票漏れ抑制プログラムを含む）、或いは可搬型記憶媒体用ドライブ９９が可搬型記憶媒体９１から読み取ったプログラム（起票漏れ抑制プログラムを含む）をＣＰＵ９０が実行することにより、図３に示す各部の機能が実現される。なお、図３には、サーバ１０のＨＤＤ９６等に格納されている各種マスタやジャーナルも図示されている。なお、図３の各部の機能は、例えば、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等の集積回路により実現されてもよい。
【００１３】
サーバ１０においては、ＣＰＵ９０がプログラムを実行することにより、図３に示すように、データ更新部１２、作成部１４、チェック部１６、メール送信部１８、返信メール受信部１９、として機能する。
【００１４】
データ更新部１２は、担当者が端末７０に入力した伝票のデータを取得して、伝票ジャーナル３０を更新する。また、担当者や管理者が、端末７０を介して、各マスタのデータを修正等した場合には、修正内容に基づいて各マスタを更新する。なお、伝票ジャーナル３０や各マスタのデータ構造については後述する。
【００１５】
作成部１４は、伝票ジャーナル３０やマスタ２１〜２９に基づいて、記憶部としての伝票チェック通知管理マスタ４０を作成する。この伝票チェック通知管理マスタ４０は、伝票の起票漏れが生じている可能性がないかを判断するための情報を集約したテーブルであり、定期的に起票する伝票の過去の起票状況を格納するテーブルである。ここで、過去の起票状況とは、過去の起票数の平均、率等から定まる各期間における起票数の傾向を意味する。なお、伝票チェック通知管理マスタ４０のデータ構造等については、後述する。
【００１６】
チェック部１６は、伝票チェック通知管理マスタ４０を参照して、伝票の起票漏れの可能性がないかをチェックし、起票漏れの可能性がある場合には、適切な人に対して通知を行うためのメールを作成する。チェック部１６は、作成したメールをメール送信部１８に受け渡す。
【００１７】
メール送信部１８は、チェック部１６から受け取ったメールを設定されているメールアドレスに対して送信する。
【００１８】
返信メール受信部１９は、メール送信部１８が送信したメールに対する返信メールの有無を監視し、返信メールがあった場合に伝票チェック通知管理マスタ４０を更新する。
【００１９】
次に、各種マスタ２１〜２９、４０、及び伝票ジャーナル３０のデータ構造について、図４（ａ）〜図１１に基づいて詳細に説明する。
【００２０】
（管理マスタ２１）
管理マスタ２１は、経理システム１００の会計年度の情報をもつテーブルであり、図４（ａ）に示すようなデータ構造を有する。図４（ａ）の例では、会計年度として、「２０１８年度」が定義されている。
【００２１】
（日付マスタ２２）
日付マスタ２２は、経理システム１００において日付を管理するためのテーブルであり、図４（ｂ）に示すように、各日付に対して、曜日と休日フラグが定義されている。ここで、休日フラグは、「０」が平日を意味しており、「１」が休日を意味している。
【００２２】
（伝票チェック管理マスタ２３）
伝票チェック管理マスタ２３は、伝票の起票漏れの可能性をチェックする際や、返信メールを監視する際のルール等を管理するテーブルである。伝票チェック管理マスタ２３は、図５に示すように、「作成タイミング」、「作成終了月」、「保有期間」、「チェックタイミング」、「締日、チェック日が休日の場合の振る舞い」、「返信メール監視時間」を管理するテーブルである。ここで、「作成タイミング」は、伝票チェック通知管理マスタ４０を作成するタイミングを意味し、図５の例では、「毎月１日」となっている。「作成終了月」は、伝票チェック通知管理マスタ４０を作成するときにどの月までのデータを用いるかを意味する。図５の例では「（システム月−１）月」、すなわち、現在が２０１９年３月であれば、その１月前の２０１９年２月までのデータを用いることになる。「保有期間」は、現在からどのくらいの範囲のデータを用いて伝票チェック通知管理マスタ４０を作成するかを意味する。図５の例では、現在から３６か月前までのデータを用いることとなる。
【００２３】
「チェックタイミング」は、チェック部１６が起票漏れの可能性をどのタイミングでチェックするかを複数段階（チェックタイミング１〜４）で定義している。図５の例では、締日から５、３，１，０営業日前をチェックタイミング１，２，３，４としている。「締日、チェック日が休日の場合の振る舞い」は、締日やチェック日が休日にあたる場合に、処理を前倒しにするのか、先送りにするのかを意味する。図５の例では、「１営業日前の日付とする」こと、すなわち、１日処理を前倒しすることが定義されている。「返信メール監視時間」は、メール送信部１８が送信したメールに対して、担当者等から返信メールがあったか否かを返信メール受信部１９が監視する時間範囲を意味する。図５の例では、８時から１８時までの間、返信メール受信部１９が返信メールを監視することが定義されている。
【００２４】
（対象伝票マスタ２４）
対象伝票マスタ２４は、定期的に起票する伝票（起票漏れ可能性のチェック対象の伝票）の情報を登録し、管理するテーブルである。対象伝票マスタ２４には、図６に示すように、「対象伝票」、「締日」、「チェック枚数算出方法」、「差戻率チェック」、「差戻率算出方法」、「差戻率チェック閾値」、「所属後チェック期間（カ月））」の情報が格納されている。
【００２５】
「対象伝票」は、起票漏れの可能性を通知する対象とすべき伝票の名称である。「締日」は、締日をいつにするのかを意味する。図６の例では、取引先マスタ２９で定義されている「支払日」を締日とすることが定義されている。「チェック枚数算出方法」は、過去の対象伝票の実績枚数（チェック枚数）の算出方法を意味する。図６の例において、「前年同月」とあれば、前年の同月における対象伝票の起票枚数をチェック枚数とし、「過去同月平均」とあれば、図５の伝票チェック管理マスタ２３で定義されている保有期間（３６カ月）に含まれる同月の平均起票枚数をチェック枚数とする。また、「伸率で算出（過去同月）」とある場合には、後述する伸率を用いて過去同月の起票枚数からチェック枚数を算出することとする。なお、「チェック枚数算出方法」としては、「前年同月」、「過去同月平均」、「伸率で算出（過去同月）」以外の算出方法（例えば、過去各月平均など）が含まれていてもよい。
【００２６】
「差戻率チェック」は、後述する差戻率に基づくメール内容の変更処理を行う場合に「あり」、行わない場合に「なし」となる。「差戻率算出方法」は、差戻率を算出する方法を意味し、「前年平均」であれば、前年において当該伝票が差し戻された確率を算出する。また、「過去同月平均」であれば、過去の同一の月において当該伝票が差し戻された確率を算出する。なお、「差戻率算出方法」としては、「前年平均」、「過去同月平均」以外の算出方法が含まれていてもよい。「差戻率チェック閾値」は、差戻率が高いか低いかを判断する際の閾値を意味する。「所属後チェック期間（カ月）」は、担当者が異動してからの期間が長いか短いかを判断する際の閾値を意味する。
【００２７】
（社員マスタ２５）
社員マスタ２５は、社員の情報を管理するテーブルである。社員マスタ２５には、一例として、図７（ａ）に示すように、「氏名」、「社員コード」、「部門コード」、「職位」、「メールアドレス」が格納されている。「社員コード」及び「部門コード」は社員を識別するための識別情報及び社員が所属する部門を識別するための識別情報を意味する。「職位」は、「一般」や「部長」などの社員の職位（役職）を意味する。「メールアドレス」は、社員それぞれが有するメールアドレスを意味する。
【００２８】
（部門マスタ２６）
部門マスタ２６は、部門の情報を管理するテーブルである。部門マスタ２６においては、一例として、図７（ｂ）に示すように、各部門に対して部門コード（部門の識別情報）が対応付けられている。
【００２９】
（異動履歴マスタ２７）
異動履歴マスタ２７は、社員の異動履歴を管理するテーブルである。異動履歴マスタ２７には、一例として、図８（ａ）に示すように、「社員コード」、「異動元」、「異動先」、「異動申請」、「異動日」が格納されている。この異動履歴マスタ２７においては、社員の異動元及び異動先の部門の部門コードと、異動申請日と、実際の異動日が管理されている。
【００３０】
（配属マスタ２８）
配属マスタ２８は、社員が各部門に配属されている期間を管理するテーブルである。配属マスタ２８には、一例として、図８（ｂ）に示すように、「社員コード」、「部門コード」、「開始日」、「終了日」が格納されている。この配属マスタ２８からは、社員が部門に配属された日（開始日）と配属が終わった日（終了日）がわかるようになっている。なお、終了日に「９９９９／９９／９９」が格納されている場合、その部門に現在も配属されていることを意味している。
【００３１】
（取引先マスタ２９）
取引先マスタ２９は、取引先の情報を管理するテーブルであり、図９に示すように、各取引先の取引先コードと、各取引先との間で定められている支払日（支払期限）とが管理されている。
【００３２】
（伝票ジャーナル３０）
伝票ジャーナル３０は、起票処理にて登録された伝票データを管理するテーブルである。伝票ジャーナル３０は、一例として、図１０に示すようなデータ構造を有する。
【００３３】
伝票ジャーナル３０においては、図１０に示すように、「伝票番号」、「伝票種別」、「摘要」、「金額」、「取引先コード」、「起票者コード」、「起票部門コード」、「作成日」、「申請日」、「承認日」、「差戻日」、「承認者コード」の各データが管理されている。
【００３４】
「伝票番号」は、伝票に付与される識別番号であり、「伝票種別」は、伝票の種別情報である。「摘要」は、取引の内容であり、「金額」は、取引金額である。「取引先コード」は、取引先に付与されたコードであり、「起票者コード」は、起票を行った担当者の社員コードであり、「起票部門コード」は、起票を行った担当者が所属する部門の部門コードである。「作成日」は、起票を行った日付であり、「申請日」は、承認を申請した日付、「承認日」は、承認が行われた日付である。「差戻日」は、承認者から差し戻しが行われた場合における差し戻しの日付であり、「承認者コード」は、承認を行った人の社員コードである。なお、図１０において灰色で塗られた行については、差し戻しがあった伝票を示している。
【００３５】
（伝票チェック通知管理マスタ４０）
伝票チェック通知管理マスタ４０は、チェック部１６が起票漏れの可能性をチェックする際に利用するテーブルであり、作成部１４が伝票ジャーナル３０等から抽出したデータを纏めたものである。伝票チェック通知管理マスタ４０は、図１１に示すようなデータ構造を有する。なお、伝票チェック通知管理マスタ４０のデータ構造の詳細については、後述する。
【００３６】
（サーバ１０の処理について）
次に、サーバ１０により実行される処理について、フローチャートに沿って、その他図面を適宜参照しつつ詳細に説明する。なお、サーバ１０は、起票漏れの可能性をチェックするために、伝票チェック通知管理マスタ４０の作成処理（図１２）と、起票漏れの可能性チェック処理（図１４〜図１７）と、伝票チェック通知管理マスタ４０の更新処理（図２１）とを実行するものとする。
【００３７】
（伝票チェック通知管理マスタ４０の作成処理）
まず、作成部１４により実行される伝票チェック通知管理マスタ４０の作成処理について、図１２のフローチャートに沿って詳細に説明する。
【００３８】
ステップＳ１０では、作成部１４が、伝票チェック通知管理マスタ４０の作成タイミングになるまで待機する。この場合、伝票チェック管理マスタ２３（図５）の作成タイミングにおいて規定されているタイミング（図５の場合、毎月１日）になると、作成部１４は、ステップＳ１２に移行する。
【００３９】
ステップＳ１２に移行すると、作成部１４は、伝票チェック管理マスタ２３（図５）から保有期間と作成終了月を取得し、管理マスタ２１（図４（ａ））から管理年度を取得する。本実施形態では、保有期間として３６カ月、作成終了月として（システム月−１）月が取得され、管理年度として２０１８年度が取得されたものとする。
【００４０】
次いで、ステップＳ１４では、作成部１４が、保有期間内のデータを用いて伝票チェック通知管理マスタ４０を作成する。本実施形態においては、作成タイミングが２０１９年２月１日であり、保有期間が３６カ月であるならば、作成部１４は、２０１９年１月から遡って３６カ月分のデータを抽出する。つまり、作成部１４は、２０１６年２月〜２０１９年１月のデータを伝票ジャーナル３０から抽出して、伝票チェック通知管理マスタ４０を作成するものとする。以下、伝票チェック通知管理マスタ４０の作成方法について、伝票チェック通知管理マスタ４０のデータ構造とともに、詳細に説明する。
【００４１】
作成部１４は、伝票チェック通知管理マスタ４０を作成する場合に、対象伝票マスタ２４（図６）に登録された対象伝票を伝票ジャーナル３０から抽出する。より具体的には、作成部１４は、伝票種別と、取引先コードをキーとして、件数などの情報をサマリーして伝票チェック通知管理マスタ４０を作成する。
【００４２】
ここで、伝票チェック通知管理マスタ４０の「伝票種別」、「取引先コード」には、伝票ジャーナル３０の「伝票種別」、「取引先コード」のデータがそのままセットされる。
【００４３】
伝票チェック通知管理マスタ４０の「起票者コード」、「起票時部門コード」には、伝票ジャーナル３０の「起票者コード」、「起票時部門コード」の直近の月内で一番古いデータがセットされる。
【００４４】
伝票チェック通知管理マスタ４０の「取引先」には、「取引先コード」にセットされたデータに対応する取引先の名称が、取引先マスタ２９（図９）から抽出されてセットされる。
【００４５】
伝票チェック通知管理マスタ４０の「起票者」と「起票者現部門コード」には、「起票者コード」にセットされたデータに対応する情報が、社員マスタ２５（図７（ａ））から抽出されてセットされる。
【００４６】
伝票チェック通知管理マスタ４０の「起票時部門」には、「起票時部門コード」にセットされたデータに対応する部門が、部門マスタ２６（図７（ｂ））から抽出されてセットされる。
【００４７】
伝票チェック通知管理マスタ４０の「起票者現部門」には、「起票者現部門コード」にセットされたデータに対応する部門が、部門マスタ２６（図７（ｂ））から抽出されてセットされる。なお、起票時部門（起票時部門コード）と起票者現部門（起票者現部門コード）とが異なる場合には、直近の月内において起票者が他部門に異動したことを意味する。
【００４８】
伝票チェック通知管理マスタ４０の「締日（タイミング）」には、「取引先コード」にセットされたデータに対応する支払日の情報が、取引先マスタ２９（図９）から抽出されてセットされる。
【００４９】
伝票チェック通知管理マスタ４０の「締日（日付）」には、「締日（タイミング）」にセットされたデータに対応する日付の情報が、日付マスタ２２（図４（ｂ））から抽出されてセットされる。ここで、日付マスタ２２から抽出された日付の「休日フラグ」が「１（休日）」であった場合には、作成部１４は、伝票チェック管理マスタ２３（図５）の「締日、チェック日が休日の場合の振る舞い」の内容に沿って「休日フラグ」が「０（平日）」になる日付を日付マスタ２２から抽出する。
【００５０】
伝票チェック通知管理マスタ４０の「チェック日１」〜「チェック日４」には、「締日（日付）」にセットされたデータと、伝票チェック管理マスタ２３の「チェックタイミング（タイミング１〜４）」と、日付マスタ２２と、から得られる各チェックタイミングの日付がセットされる。なお、セットする日付が休日の場合の振る舞いは、「締日（日付）」で説明したのと同様とする。
【００５１】
伝票チェック通知管理マスタ４０の「チェック枚数算出方法」、「差戻率チェック」、「所属後チェック期間（ヶ月）」、「差戻率チェック閾値」には、対象伝票マスタ２４（図６）の対象伝票に対応する「チェック枚数算出方法」、「差戻率チェック」、「所属後チェック期間（ヶ月）」、「差戻率チェック閾値」の情報がセットされる。
【００５２】
伝票チェック通知管理マスタ４０の「チェック枚数」には、作成部１４が「チェック枚数算出方法」にセットされた内容に沿って伝票ジャーナル３０から該当する伝票をカウントし、カウントされた数をセットする。
【００５３】
伝票チェック通知管理マスタ４０の「差戻率」には、作成部１４が伝票ジャーナル３０から該当する伝票数と差し戻された伝票数をカウントし、「差戻率算出方法」にセットされた内容に沿ってカウントされた数から算出された差戻率をセットする。
【００５４】
伝票チェック通知管理マスタ４０の「完了フラグ」には、担当者から完了通知があった場合に「済」がセットされるが、この「完了フラグ」のセットの処理は、返信メール受信部１９が実行するため、詳細については後述する。
【００５５】
伝票チェック通知管理マスタ４０の「後任者コード」、「後任者」には、起票を担当する部門の部門長から後任者の通知があった場合に、後任者の情報がセットされるが、この「後任者コード」、「後任者」のセットの処理は、返信メール受信部１９が実行するため、詳細については後述する。
【００５６】
ここで、「チェック枚数算出方法」にセットされる「伸率で算出（過去データ同月）」について説明する。この「伸率で算出（過去データ同月）」は、徐々に起票数が増える傾向にある伝票に対してセットされ、その伸率から起票すべき伝票の枚数を予測することを意味している。例えば、図１３に示すように、「えええ伝票」の２０１６年２月、２０１７年２月、２０１８年２月の起票枚数がそれぞれ６枚、７枚、８枚であったとする。この場合、２０１６年と２０１７年の間の伸率は、７／６×１００≒１１７％であり、２０１７年と２０１８年の間の伸率は、８／７×１００≒１１４％である。したがって、２０１９年のチェック枚数は、これらの平均（１１７＋１１４）／２≒１１５％を算出用伸率とし、２０１８年の起票枚数（８枚）を用いて、次式（１）から算出することになる。
８×１１５％＝９．２≒９枚      …（１）
【００５７】
上記のようにして、ステップＳ１４の処理が実行された後は、ステップＳ１０に戻る。そして、作成部１４は、伝票チェック通知管理マスタ４０の作成タイミングが到来する度に、ステップＳ１２、Ｓ１４の処理を繰り返し実行する。
【００５８】
（起票漏れの可能性チェック処理）
次に、チェック部１６により実行される起票漏れの可能性チェック処理について、図１４〜図１７のフローチャートに沿って詳細に説明する。チェック部１６は、作成部１４が作成した伝票チェック通知管理マスタ４０を参照して、起票漏れの可能性をチェックし、必要に応じて起票者等に対してメールを送信する。なお、チェック部１６は、日付マスタ２２（図４（ｂ））のうち、休日フラグが０（平日）となっている日付の所定時刻（例えば０６：００）になったタイミングで図１４の処理を実行するものとする。
【００５９】
図１４の処理では、まず、ステップＳ２０において、チェック部１６が、最新の伝票チェック通知管理マスタ４０を取得する。
【００６０】
次いで、ステップＳ２２では、チェック部１６が、伝票チェック通知管理マスタ４０を参照して、チェックタイミング（チェック日１〜４）が到来した伝票があるか否かを判断する。このステップＳ２２の判断が否定された場合には、図１４の全処理を終了するが、肯定された場合には、ステップＳ２４に移行する。
【００６１】
ステップＳ２４に移行すると、チェック部１６は、チェックタイミングが到来した伝票（及び取引先コードの組み合わせ）の全てを対象伝票に設定する。
【００６２】
次いで、ステップＳ２６では、チェック部１６が、１つの対象伝票について、月内に作成された伝票数をカウントし、伝票チェック通知管理マスタ４０の「チェック枚数」と比較する。より具体的には、チェック部１６は、対象伝票の「伝票種別」、「取引先コード」と一致するデータを、伝票ジャーナル３０においてシステム月内に作成されたデータの中でカウントする。そして、チェック部１６は、カウントした数と、伝票チェック通知管理マスタ４０の「チェック枚数」にセットされている数（チェック枚数）とを比較する。
【００６３】
ステップＳ２８では、チェック部１６が、チェック枚数の方が多いか否かを判断する。このステップＳ２８の判断が肯定された場合、すなわち、当月において起票された枚数が過去の起票枚数の傾向に比べて不足している場合には、ステップＳ３０に移行する。一方、ステップＳ２８の判断が否定された場合、すなわち、当月において起票された枚数が過去の起票枚数の傾向に比べて多い又は同一である場合には、現在の対象伝票に関する通知は不要であるため、ステップＳ４０に移行する。
【００６４】
ステップＳ２８の判断が肯定されて、ステップＳ３０に移行すると、チェック部１６は、完了フラグが「済」か否かを判断する。このステップＳ３０の判断が肯定された場合、すなわち、対象伝票についての起票漏れの可能性を知らせるメールを起票者に送り、起票者が全ての伝票を起票している旨の返信メールを既に返信している場合には、ステップＳ４０に移行する。一方、ステップＳ３０の判断が否定された場合には、ステップＳ３２に移行する。
【００６５】
ステップＳ３２に移行すると、チェック部１６は、チェックタイミングに基づくメール内容決定処理のサブルーチンを実行する。このステップＳ３２においては、図１５のフローチャートに沿った処理が実行される。
【００６６】
図１５の処理では、まず、ステップＳ５０において、チェック部１６が、チェックタイミング１か否かを判断する。すなわち、チェック部１６は、伝票チェック通知管理マスタ４０を参照して、対象伝票のチェックタイミング１とシステム日付とが同一であるか否かを判断する。このステップＳ５０の判断が肯定されると、チェック部１６は、ステップＳ５２に移行し、メール内容をチェックタイミング１用とする。ここで、チェックタイミング１用のメール内容とは、図１８（ａ）に示すようなメール内容である。図１８（ａ）のメールには、タイトルとして「[会計システム]伝票起票チェックのご連絡」が記載され、チェック結果の詳細と、いつまでに伝票を作成すべきかの情報が記載される。また、必要な伝票が起票済みの場合の手続き方法（返信メールを送る方法）についても記載される。なお、この段階では、メール宛先は、空欄となっている。
【００６７】
一方、ステップＳ５０の判断が否定された場合には、ステップＳ５４に移行し、チェック部１６が、チェックタイミング２か否かを判断する。すなわち、チェック部１６は、伝票チェック通知管理マスタ４０を参照して、対象伝票のチェックタイミング２とシステム日付とが同一であるか否かを判断する。このステップＳ５４の判断が肯定された場合には、ステップＳ５６に移行し、チェック部１６は、メール内容をチェックタイミング２用とする。ここで、チェックタイミング２用のメール内容とは、図１８（ｂ）に示すようなメール内容である。図１８（ｂ）のメールにおいては、タイトルが図１８（ａ）とは異なり、「[重要][会計システム]伝票起票チェックのご連絡」になっており、いつまでに伝票を作成すべきかの情報の表現も一部変更されている（図１８（ｂ）の下線部参照）。なお、この段階では、メール宛先は、空欄となっている。
【００６８】
これに対し、ステップＳ５４の判断が否定された場合には、ステップＳ５８に移行し、チェック部１６が、チェックタイミング３か否かを判断する。すなわち、チェック部１６は、伝票チェック通知管理マスタ４０を参照して、対象伝票のチェックタイミング３とシステム日付とが同一であるか否かを判断する。このステップＳ５８の判断が肯定された場合には、ステップＳ６０に移行し、チェック部１６は、メール内容をチェックタイミング３用とする。ここで、チェックタイミング３用のメール内容とは、図１９（ａ）に示すようなメール内容である。図１９（ａ）のメールにおいては、タイトルがこれまでとは異なり、「[至急][会計システム]伝票起票チェックのご連絡」になっており、いつまでに伝票を作成すべきかの情報の表現も一部変更されている。なお、この段階では、メール宛先は、空欄となっている。
【００６９】
一方、ステップＳ５８の判断が否定された場合には、ステップＳ６２に移行し、チェック部１６は、メール内容をチェックタイミング４用とする。ここで、チェックタイミング４用のメール内容とは、図１９（ｂ）に示すようなメール内容である。図１９（ｂ）のメールにおいては、タイトルがこれまでとは異なり、「[緊急][会計システム]伝票起票チェックのご連絡」になっており、いつまでに伝票を作成すべきかの情報の表現も一部変更されている。また、締日を超過する場合の手続き方法についても記載されている。なお、この段階では、メール宛先は、空欄となっている。
【００７０】
上記のようにして、ステップＳ５２、Ｓ５６、Ｓ６０、Ｓ６２のいずれかが実行された後は、図１４のステップＳ３４に移行する。
【００７１】
図１４のステップＳ３４に移行すると、チェック部１６が、異動有無に基づくメール内容決定処理のサブルーチンを実行する。このステップＳ３４においては、図１６のフローチャートに沿った処理が実行される。
【００７２】
ステップＳ７０では、チェック部１６が、起票時部門と起票者現部門は同一か否かを判断する。すなわち、チェック部１６は、伝票チェック通知管理マスタ４０を参照して、対象伝票の起票時部門と起票者現部門とを取得し、これらが同一であるか否かを判断する。このステップＳ７０の判断が肯定された場合には、ステップＳ７２に移行し、チェック部１６は、メール宛先に起票者を設定し、送信先に起票者のメールアドレスを設定する。なお、チェック部１６は、起票者のメールアドレスとして、伝票チェック通知管理マスタ４０の起票者コードに対応するメールアドレスを社員マスタ２５から特定するものとする。
【００７３】
一方、ステップＳ７０の判断が否定された場合には、ステップＳ７４に移行し、チェック部１６は、後任者の情報が入力されているか否かを判断する。すなわち、チェック部１６は、伝票チェック通知管理マスタ４０を参照して、後任者コードと後任者の情報が格納されているか否かを判断する。このステップＳ７４の判断が肯定された場合には、ステップＳ７６に移行して、チェック部１６は、メール宛先に後任者を設定し、送信先に後任者のメールアドレスを設定する。これに対し、ステップＳ７４の判断が否定された場合には、ステップＳ７８に移行して、チェック部１６は、メール宛先に対応部門の部門長を設定し、送信先に部門長のメールアドレスを設定する。なお、チェック部１６は、部門長のメールアドレスとして、伝票チェック通知管理マスタ４０の起票者部門コードに対応する部門の部門長（例えば部長）のメールアドレスを社員マスタ２５から特定するものとする。なお、ステップＳ７８において、送信先を部門長に設定した場合には、図２０において下線を付して示すように、メール内容を変更することとする。具体的には、部門長に対して、後任者が決まっている場合には、後任者の氏名を記載した返信メールを送るようにお願いする文面と、後任者に対して、メール内容を伝えるようにお願いする文面が記載される。
【００７４】
上記のようにして、ステップＳ７２、Ｓ７６、Ｓ７８のいずれかが実行された後は、図１４のステップＳ３６に移行する。
【００７５】
図１４のステップＳ３６に移行すると、チェック部１６が、処理能力に基づくメール内容決定処理のサブルーチンを実行する。このステップＳ３６においては、図１７のフローチャートに沿った処理が実行される。
【００７６】
図１７のステップＳ８０では、チェック部１６が、起票者又は後任者の所属期間と所属後チェック期間とを比較する。具体的には、チェック部１６は、伝票チェック通知管理マスタ４０から、対象伝票の起票者コード又は後任者コードを特定する。そして、チェック部１６は、配属マスタ２８から、特定した起票者コード又は後任者コードに対応する最新の開始日を取得し、システム日付との差分から所属期間を算出する。そして、チェック部１６は、算出した所属期間と伝票チェック通知管理マスタ４０の所属後チェック期間とを比較する。
【００７７】
ステップＳ８２では、チェック部１６が、所属後チェック期間の方が長いか否かを判断する。このステップＳ８２の判断が肯定された場合、すなわち、起票者又は後任者が現在の部署に配属されてからあまり時間が経過していない場合には、ステップＳ８４に移行する。
【００７８】
ステップＳ８４に移行すると、チェック部１６は、メールに、問い合わせ先として、前任者、前々任者の部署、連絡先、メールアドレス等を追記する。
【００７９】
一方、ステップＳ８２の判断が否定された場合、すなわち、起票者又は後任者が現在の部署に配属されてから比較的長い時間が経過している場合には、ステップＳ８６に移行する。
【００８０】
ステップＳ８６に移行すると、チェック部１６は、差戻率と、差戻率チェック閾値とを比較する。具体的には、チェック部１６は、伝票チェック通知管理マスタ４０から、対象伝票の差戻率と、差戻率チェック閾値を読み出し、比較する。
【００８１】
次いで、ステップＳ８８では、チェック部１６が、差戻率の方が大きいか否かを判断する。このステップＳ８８の判断が否定された場合には、そのまま、ステップＳ３６の処理を終了する。一方、ステップＳ８８の判断が肯定された場合、すなわち、対象伝票の起票作業に慣れていないなどの理由で差戻率が大きい場合には、ステップＳ８４に移行し、上述した処理を実行する。なお、伝票チェック通知管理マスタ４０において、「差戻チェック」が「なし」になっている場合には、ステップＳ８６、Ｓ８８の処理を実行しないものとする。
【００８２】
ステップＳ８４の処理が行われた後は、ステップＳ３６の処理を終了し、図１４のステップＳ３８に移行する。なお、ステップＳ３２、Ｓ３４、Ｓ３６を経て作成されたメールは、チェック部１６からメール送信部１８に対して受け渡される。
【００８３】
ステップＳ３８に移行すると、メール送信部１８は、メール送信を実行する。これにより、起票者や後任者、部門長に対して起票漏れの可能性があることを通知することができる。なお、メール送信部１８は、どの宛先にどの伝票に関するメールを送信したかの情報を、返信メール受信部１９に通知しておくものとする。このステップＳ３８の処理の後は、ステップＳ４０に移行する。
【００８４】
ステップＳ２８（否定）、ステップＳ３０（肯定）、又はステップＳ３８の処理を経て、ステップＳ４０に移行すると、チェック部１６が、全ての対象伝票の処理が終了したか否かを判断する。このステップＳ４０の判断が否定された場合、すなわち、まだ対象伝票が残っている場合には、ステップＳ２６に戻り、次の対象伝票に対して、ステップＳ２６〜Ｓ３８の処理を実行する。一方、ステップＳ４０の判断が肯定された場合には、図１４の全処理を終了する。
【００８５】
（伝票チェック通知管理マスタ４０の更新処理）
次に、返信メール受信部１９により実行される伝票チェック通知管理マスタ４０の更新処理について、図２１のフローチャートに沿って詳細に説明する。返信メール受信部１９は、メール送信部１８が送信したメールに対する返信メールを監視し、返信メールがあった場合に、返信メールの内容に応じて伝票チェック通知管理マスタ４０を更新する。
【００８６】
図２１の処理では、まず、ステップＳ１００において、返信メール受信部１９が、返信メール監視時間内であるか否かを判断する。このステップＳ１００の判断が否定された場合には、ステップＳ１００の判断を繰り返すが、肯定された場合には、ステップＳ１０２に移行する。
【００８７】
ステップＳ１０２に移行すると、返信メール受信部１９は、返信メールを監視する。次いで、ステップＳ１０４では、返信メール受信部１９が、部門長からの返信メールを受信したか否かを判断する。この場合、部門長は、後任者が決まっていれば、図２２に示すような後任者の氏名（例えば「山上四朗」）を先頭に記載した返信メールを作成して、送信するようになっている。このステップＳ１０４の判断が肯定された場合には、返信メール受信部１９は、ステップＳ１０６に移行する。
【００８８】
ステップＳ１０６に移行すると、返信メール受信部１９は、返信メールの先頭に記載されている後任者の氏名を用いて、伝票チェック通知管理マスタ４０の後任者情報を更新する。ここで、前述のように、返信メール受信部１９は、どの宛先にどの伝票に関するメールを送信したかの情報を保持している。このため、返信メール受信部１９は、返信メールがどの伝票に関する返信メールであるかを特定することができる。したがって、返信メール受信部１９は、返信メールに記載されている後任者の氏名に基づいて、社員マスタ２５から後任者の社員コードを特定し、特定した社員コードと後任者の氏名とで、伝票チェック通知管理マスタ４０の返信メールに対応する「後任者コード」と、「後任者」とを更新する。このようにステップＳ１０６の処理が行われた後、又はステップＳ１０４の判断が否定された後には、返信メール受信部１９は、ステップＳ１０８に移行する。
【００８９】
ステップＳ１０８に移行すると、返信メール受信部１９は、起票者又は後任者からの返信メールを受信したか否かを判断する。ここで、起票者や後任者は、必要な伝票が起票済みであれば、図２３に示すように、先頭に「あ」を記載した返信メールを作成して、送信する。このステップＳ１０８の判断が肯定された場合には、返信メール受信部１９は、ステップＳ１１０に移行する。
【００９０】
ステップＳ１１０に移行すると、返信メール受信部１９は、伝票チェック通知管理マスタ４０の「完了フラグ」を「済」に更新する。ここで、前述のように、返信メール受信部１９は、返信メールがどの伝票に関する返信メールであるかを特定することができる。したがって、返信メール受信部１９は、返信メールに対応する伝票の「完了フラグ」を「済」に更新する。その後は、返信メール受信部１９は、ステップＳ１００に戻る。一方、ステップＳ１０８の判断が否定された場合にも、返信メール受信部１９は、ステップＳ１００に戻る。
【００９１】
その後、返信メール受信部１９は、図２１の処理を繰り返し実行する。
【００９２】
これまでの説明からわかるように、本実施形態では、チェック部１６及びメール送信部１８により、起票漏れの可能性があることを通知する通知部としての機能が実現されている。
【００９３】
以上、詳細に説明したように、本実施形態によると、チェック部１６は、定期的に起票する伝票の過去の起票状況を格納する伝票チェック通知管理マスタ４０を参照して、起票数の平均、率等から定まる各期間における起票数の傾向について比較をおこなう。具体的にはチェック部１６は、過去の単位期間（例えば１カ月間）における伝票の起票数と、現在を含む単位期間（例えば締日前１カ月）における伝票の起票数とを比較する（Ｓ２６）。そして、チェック部１６は、比較の結果、現在を含む単位期間における伝票の起票数が、過去の単位期間における伝票の起票数と比べて不足していると判断した場合（Ｓ２８：肯定）に、伝票の起票数が不足していることを通知する（Ｓ３２〜Ｓ３６）。これにより、本実施形態では、定期的に起票すべき伝票の起票数が、過去に比べて不足している場合に通知を行うため、伝票の起票漏れの可能性がある場合に通知を行うことができる。この通知により、起票者は、起票が行われていない伝票の存在に気付くことができるため、起票漏れを抑制することが可能である。
【００９４】
また、本実施形態では、チェック部１６は、伝票チェック通知管理マスタ４０を参照して、伝票の締日を特定し、特定した締日と通知を行う日との差（すなわち、チェックタイミング１〜４のいずれであるか）に応じて、メール内容を異ならせる（図１５）。これにより、締日が迫っている場合に、緊急性を高めた通知を行うなどすることができるため、通知の見忘れ等を防止し、起票漏れを抑制することができる。
【００９５】
また、本実施形態では、チェック部１６は、伝票チェック通知管理マスタ４０を参照して、過去の単位期間において伝票を起票した人の起票時の所属部門と現在の所属部門とを特定する。そして、チェック部１６は、起票時の所属部門と現在の所属部門が同一であるか異なるかに応じて、メールの宛先を異ならせる（図１６）。これにより、伝票の起票漏れの可能性を通知すべき適切な人に対して通知を行うことができる。
【００９６】
また、本実施形態では、チェック部１６は、伝票を起票する人が現在の所属部門に所属している期間と、前記伝票を起票する人の過去の実績（差戻率）に基づいて、メール内容を異ならせることとしている。これにより、伝票を起票する人のキャリアや実績に基づいて、適切な通知を行うことができる。
【００９７】
また、本実施形態では、チェック部１６は、伝票チェック通知管理マスタ４０のチェック枚数を算出する際に、過去の単位期間における伝票の起票数の伸率を考慮することがある。これにより、定期的に起票すべき伝票が時々刻々と変化するような場合であっても、伸率を考慮することで適切なチェック枚数の算出、及び適切な起票漏れチェックを行うことができる。
【００９８】
なお、上記実施形態では、１カ月ごとに起票状況をチェックする場合について説明したが、これに限られるものではない。例えば、取引先マスタ２９の「支払日」において、支払日が各週のある曜日（例えば水曜日とする）と設定されている場合には、水曜日ごとに１週間ごとの起票状況をチェックするようにしてもよい。この場合、過去の複数週の起票数の平均や、前週の起票数などをチェック枚数とすることができる。また、起票状況のチェックの実施タイミングは、１年に１回や半年に１回などであってもよい。
【００９９】
なお、上記実施形態において示した各マスタ及びジャーナルのデータ構造は一例である。したがって、必要に応じて、各マスタ及びジャーナルのデータ構造を種々変更してもよい。
【０１００】
なお、上記の処理機能は、コンピュータによって実現することができる。その場合、処理装置が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体（ただし、搬送波は除く）に記録しておくことができる。
【０１０１】
プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。
【０１０２】
プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。
【０１０３】
上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。
【０１０４】
なお、以上の実施形態の説明に関して、更に以下の付記を開示する。
（付記１）  定期的に起票する伝票の過去の起票状況を格納する記憶部を参照して、過去の単位期間における前記伝票の起票数の傾向と、現在を含む単位期間における前記伝票の起票数の傾向とに基づき、現在の起票数が不足している場合に、前記伝票の起票状況が不足していることを通知する、
処理をコンピュータに実行させるための起票漏れ抑制プログラム。
（付記２）  前記通知する処理では、前記記憶部を参照して、前記伝票の締日と前記通知を行う日との差を特定し、特定した差に応じて通知内容を異ならせることを特徴とする付記１に記載の起票漏れ抑制プログラム。
（付記３）  前記通知する処理では、前記記憶部を参照して、前記過去の単位期間において前記伝票を起票した人の起票時の所属部門と現在の所属部門とを特定し、前記起票時の所属部門と前記現在の所属部門が同一であるか異なるかに応じて、通知先を異ならせることを特徴とする付記１又は２に記載の起票漏れ抑制プログラム。
（付記４）  前記通知する処理では、前記伝票を起票する人が現在の所属部門に所属している期間、及び前記記憶部に格納されている前記伝票を起票する人の過去の実績、の少なくとも一方に基づいて、通知内容を異ならせることを特徴とする付記１〜３のいずれかに記載の起票漏れ抑制プログラム。
（付記５）  前記通知する処理では、前記現在の起票数が不足しているかを、前記過去の単位期間における前記伝票の起票数の伸率を考慮して判断する、ことを特徴とする付記１〜４のいずれかに記載の起票漏れ抑制プログラム。
（付記６）  定期的に起票する伝票の過去の起票状況を格納する記憶部を参照して、過去の単位期間における前記伝票の起票数の傾向と、現在を含む単位期間における前記伝票の起票数の傾向とに基づき、現在の起票数が不足している場合に、前記伝票の起票状況が不足していることを通知する、
処理をコンピュータが実行することを特徴とする起票漏れ抑制方法。
（付記７）  伝票を起票する人が利用する端末と、前記端末と接続され、前記伝票に関する処理を実行する情報処理装置とを備える情報処理システムであって、
定期的に起票する伝票の過去の起票状況を格納する記憶部と、
前記記憶部を参照して、過去の単位期間における前記伝票の起票数の傾向と、現在を含む単位期間における前記伝票の起票数の傾向とに基づき、現在の起票数が不足している場合に、前記伝票の起票状況が不足していることを通知する通知部と、
を備える情報処理システム。
（付記８）  前記通知部は、前記記憶部を参照して、前記伝票の締日と前記通知を行う日との差を特定し、特定した差に応じて通知内容を異ならせることを特徴とする付記７に記載の情報処理システム。
（付記９）  前記通知部は、前記記憶部を参照して、前記過去の単位期間において前記伝票を起票した人の起票時の所属部門と現在の所属部門とを特定し、前記起票時の所属部門と前記現在の所属部門が同一であるか異なるかに応じて、通知先を異ならせることを特徴とする付記７又は８に記載の情報処理システム。
（付記１０）  前記通知部は、前記伝票を起票する人が現在の所属部門に所属している期間、及び前記記憶部に格納されている前記伝票を起票する人の過去の実績、の少なくとも一方に基づいて、通知内容を異ならせることを特徴とする付記７〜９のいずれかに記載の情報処理システム。
（付記１１）  前記通知部は、前記現在の起票数が不足しているかを、前記過去の単位期間における前記伝票の起票数の伸率を考慮して判断する、ことを特徴とする付記７〜１０のいずれかに記載の情報処理システム。
【符号の説明】
【０１０５】
１０  サーバ（情報処理装置）
１６  チェック部（通知部の一部）
１８  メール送信部（通知部の一部）
４０  伝票チェック通知管理マスタ（記憶部）
【図１】
2020197813.tif 000003
【図２】
2020197813.tif 000004
【図３】
2020197813.tif 000005
【図４】
2020197813.tif 000006
【図５】
2020197813.tif 000007
【図６】
2020197813.tif 000008
【図７】
2020197813.tif 000009
【図８】
2020197813.tif 000010
【図９】
2020197813.tif 000011
【図１０】
2020197813.tif 000012
【図１１】
2020197813.tif 000013
【図１２】
2020197813.tif 000014
【図１３】
2020197813.tif 000015
【図１４】
2020197813.tif 000016
【図１５】
2020197813.tif 000017
【図１６】
2020197813.tif 000018
【図１７】
2020197813.tif 000019
【図１８】
2020197813.tif 000020
【図１９】
2020197813.tif 000021
【図２０】
2020197813.tif 000022
【図２１】
2020197813.tif 000023
【図２２】
2020197813.tif 000024
【図２３】
2020197813.tif 000025