JP2020003914A - 情報処理装置、情報処理方法および情報処理プログラム - Google Patents

Abstract

【課題】支払が発生する申請を起票する際に、様々な申請パターンに対して正しい債務管理部署や支払部署が設定できるようにする。【解決手段】記憶部１０６には、申請を起票する社員に関する情報とその所属部署とを登録する社員情報マスタ１０６ａと、申請に用いられる用途のパターンを登録する用途マスタ１０６ｂと、所属部署と前記用途との組み合わせと紐付く債務管理部署あるいは支払部署が登録された部署別用途別支払部署マスタ１０６ｃとが格納され、制御部１０２は、社員情報マスタ１０６ａにより申請する社員の所属部署を入力し、用途マスタ１０６ｂにより申請の用途を入力する申請情報入力部１０２ａと、入力された所属部署と用途との組み合わせで、部署別用途別支払部署マスタ１０６ｃの該当する債務管理部署あるいは支払部署を抽出する部署抽出部１０２ｂとを備える。【選択図】図１

Description

本発明は、情報処理装置、情報処理方法および情報処理プログラムに関する。

従来では、支払が発生する申請を行う際に、申請者が債務管理部署あるいは支払部署を選択して入力していた。例えば、非特許文献１には、交通費精算を行う画面上で申請者が支払部署としての負担部署を選択して入力を行う交通費精算システムが開示されている。また、どの部署で債務管理や支払を行うかは、申請者が所属する部署によって自動で決定していた。例えば、非特許文献２には、旅費／交通費申請書において、申請者の名前や所属部署を入力することで、支払部署としての負担部署が自動で決定される差額支給処理システムが開示されている。

ラクス 楽楽精算"ｈｔｔｐｓ：／／ｋｅｉｒｉｐｌｕｓ．ｊｐ／ｅｆｆｉｃｉｅｎｃｙ／ｋｏｕｔｓｕｈｉｓｙｓｔｅｍ＿ｎｏｒｉａｅａｎｎａｉ／" ヴァル研究所 駅すぱあと旅費交通費精算Ｗｅｂ"ｈｔｔｐｓ：／／ｓｅｉｓａｎ．ｅｋｉｓｐｅｒｔ．ｊｐ／ｓｅｒｖｉｃｅ／ｈｅｌｐ／ａｐｐ／ｄａｔａ／ｓａｇａｋｕ．ｈｔｍｌ"

しかしながら、上記非特許文献１では、申請者が負担部署を自ら選択して入力していたため、誤った部署を選択する可能性があり、確認や修正の手間が生じるという課題があった。また、上記非特許文献２では、入力された申請者の名前や所属部署に対応した負担部署が登録されたマスタなどを利用することで、入力者の所属部署を費用負担部署として決定していたが、所属部署と費用負担部署とが異なるパターンには対応できないという課題があった。

本発明は、上記に鑑みてなされたものであって、支払が発生する申請を起票する際に、様々な申請パターンに対して正しい債務管理部署や支払部署を設定することができる情報処理装置、情報処理方法および情報処理プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明に係る情報処理装置は、記憶部と制御部とを備え、支払が発生する申請を起票する場合に、当該申請に対する債務管理部署あるいは支払部署を設定する情報処理装置であって、前記記憶部には、前記申請を起票する社員に関する情報とその所属部署とを登録する社員情報マスタと、前記申請に用いられる用途のパターンを登録する用途マスタと、前記所属部署と前記用途との組み合わせに対し、これと紐付く債務管理部署あるいは支払部署が登録された部署別用途別支払部署マスタと、が格納されており、前記制御部は、前記社員情報マスタにより申請を起票する社員の所属部署を入力し、前記用途マスタにより前記申請に用いる用途を入力する申請情報入力手段と、入力された前記所属部署と前記用途との組み合わせに基づいて、前記部署別用途別支払部署マスタの該当する債務管理部署あるいは支払部署を抽出する部署抽出手段と、を備えたこと、を特徴とする。

また、本発明に係る情報処理装置は、前記記憶部には、前記部署抽出手段により抽出された債務管理部署あるいは支払部署と、申請の種類や金額とを含む申請に関するデータを記憶する申請データがさらに格納され、前記制御部は、前記申請データを出力する出力手段をさらに備えたこと、を特徴とする。

また、本発明に係る情報処理装置は、前記制御部は、前記社員情報マスタ、前記用途マスタ、および、前記部署別用途別支払部署マスタの少なくとも１つのマスタ情報を登録するマスタメンテ手段をさらに備えたこと、を特徴とする。

また、本発明に係る情報処理装置は、前記申請情報入力手段は、前記申請に用いる用途を入力する場合に、前記用途マスタに登録されている用途のパターンを一覧表示し、その中から選択入力させること、を特徴とする。

また、本発明に係る情報処理方法は、記憶部と制御部とを備え、支払が発生する申請を起票する場合に、当該申請に対する債務管理部署あるいは支払部署を設定する情報処理装置で実行される情報処理方法であって、前記記憶部には、前記申請を起票する社員に関する情報とその所属部署とを登録する社員情報マスタと、前記申請に用いられる用途のパターンを登録する用途マスタと、前記所属部署と前記用途との組み合わせに対し、これと紐付く債務管理部署あるいは支払部署が登録された部署別用途別支払部署マスタと、が格納されており、前記制御部で実行される、前記社員情報マスタにより申請を起票する社員の所属部署を入力し、前記用途マスタにより前記申請に用いる用途を入力する申請情報入力ステップと、入力された前記所属部署と前記用途との組み合わせに基づいて、前記部署別用途別支払部署マスタの該当する債務管理部署あるいは支払部署を抽出する部署抽出ステップと、を含むこと、を特徴とする。

また、本発明に係る情報処理プログラムは、記憶部と制御部とを備え、支払が発生する申請を起票する場合に、当該申請に対する債務管理部署あるいは支払部署を設定する情報処理装置で実行させるための情報処理プログラムであって、前記記憶部には、前記申請を起票する社員に関する情報とその所属部署とを登録する社員情報マスタと、前記申請に用いられる用途のパターンを登録する用途マスタと、前記所属部署と前記用途との組み合わせに対し、これと紐付く債務管理部署あるいは支払部署が登録された部署別用途別支払部署マスタと、が格納されており、前記制御部で実行させるための、前記社員情報マスタにより申請を起票する社員の所属部署を入力し、前記用途マスタにより前記申請に用いる用途を入力する申請情報入力ステップと、入力された前記所属部署と前記用途との組み合わせに基づいて、前記部署別用途別支払部署マスタの該当する債務管理部署あるいは支払部署を抽出する部署抽出ステップと、を含むこと、を特徴とする。

本発明によれば、支払が発生する申請を起票する際に、様々な申請パターンに対して正しい債務管理部署や支払部署を設定することができるという効果を奏する。

図１は、本実施形態に係る情報処理装置の構成の一例を示すブロック図である。 図２は、記憶部を構成するマスタの内部構造の一例を示す図である。 図３は、情報処理装置の処理の流れの一例を示すフローチャートである。 図４は、本実施形態の記憶部を構成するマスタの具体例を示す図である。 図５は、静岡店に所属する社員が出張申請を行う場合の申請処理の一例を示す図である。 図６は、滋賀店に所属する社員が出張申請を行う場合の申請処理の一例を示す図である。 図７は、静岡店に所属する社員が滋賀店へ応援に行く場合の申請処理の一例を示す図である。 図８は、滋賀店に所属する社員が研修に行く場合の申請処理の一例を示す図である。 図９は、滋賀店に所属する社員が支給申請を行う場合の一例を示す図である。 図１０は、申請し承認された後の処理イメージの一例を示す図である。 図１１は、比較例１における申請処理の一例を示す図である。 図１２は、比較例１において所属部署と支払部署とを紐付けるマスタの一例を示す図である。 図１３は、比較例２における申請処理の一例を示す図である。 図１４は、比較例３における申請処理の一例を示す図である。 図１５は、比較例１から３の所属部署と用途と支払部署との関係の一例を示す図である。

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

［１．概要］
従来は、支払の申請者が所属する所属部署によって、どの部署で債務管理や支払を行うかを自動的に決定していた。しかしながら、起票者が同じであっても費用の用途に応じて債務管理部署や支払部署が変わる場合があるため、自動設定で対応することができなかった。

そこで、本実施形態に係る情報処理装置は、申請者の“所属部署”と“用途”との組み合わせにより、債務管理部署や支払部署を自動で入力するようにしたものである。入力が必要な“用途”については、申請者も適切に指定することができるため、“所属部署”と“用途”との組み合わせと紐付けることで、適切な債務管理部署や支払部署を自動で入力することができる。また、申請者の“所属部署”が同じ場合でも、費用の“用途”に応じて債務管理部署や支払部署が変わる場合もあり、これに対応することができる。このように、本実施形態に係る情報処理装置は、費用申請に関する債務管理部署や支払部署を自動で入力することができるため、業務担当者の作業効率を従来よりも大幅に向上させることができる。さらに、本実施形態に係る情報処理装置は、運用スキルの高くない現場担当者（末端の申請者）であっても適切に運用することが可能となる。

［２．構成］
本実施形態に係る情報処理装置の構成の一例について、図１および図２を参照して説明する。図１は、本実施形態に係る情報処理装置の構成の一例を示すブロック図である。図２は、記憶部を構成するマスタの内部構造の一例を示す図である。

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

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

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

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

社員情報マスタ１０６ａは、支払申請を起票する社員に関する情報とその所属部署とを登録するマスタである。例えば、社員情報マスタ１０６ａは、図２に示すように、主キーとしての“社員名”と、それに紐付く“所属部署”とが登録されている。このため、ログイン処理の際に、“社員名”や“社員ＩＤ”などを入力すると、社員情報マスタ１０６ａから“所属部署”が抽出される。

用途マスタ１０６ｂは、支払申請に用いられる用途のパターンを登録するマスタである。例えば、用途マスタ１０６ｂは、図２に示すように、主キーとして使用可能な“用途名（用途）”のパターンが登録されている。このため、申請者が画面上で“用途名”を入力する際に、登録されている“用途名”のパターンをドロップダウンリストとして表示させ、その中から選択させることにより、運用スキルが高くなくても適切に入力することができる。

部署別用途別支払部署マスタ１０６ｃは、“所属部署”と“用途名（用途）”との組み合わせに対し、これと紐付く債務管理部署あるいは支払部署が登録されたマスタである。例えば、部署別用途別支払部署マスタ１０６ｃは、図２に示すように、主キーとして“所属部署”と“用途名（用途）”との組み合わせに対応した債務管理部署や支払部署が登録されている。このため、主キーの“所属部署”と“用途名（用途）”とを入力すると、この組み合わせに応じた債務管理部署や支払部署を抽出することができる。

申請データ１０６ｄは、部署抽出部１０２ｂによって抽出された債務管理部署や支払部署の他、申請の種類や金額などを含む申請に関するデータを記憶している。この申請データ１０６ｄには、申請の種類によって色々なデータが記憶される。例えば、本実施形態の申請処理の一例を示す図５では、出張申請に係る申請データとして、旅費データを記憶している。この旅費データ（申請データに相当するため、図中も同じ符号１０６ｄとする）には、図５に示すように、“申請種類”、“伝票番号”、“債務管理部署”、“支払部署”、“金額”などが含まれている。

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

制御部１０２は、情報処理装置１００を統括的に制御するＣＰＵ等である。制御部１０２は、ＯＳ等の制御プログラム・各種の処理手順等を規定したプログラム・所要データなどを格納するための内部メモリを有し、格納されているこれらのプログラムに基づいて種々の情報処理を実行する。ここで、制御部１０２は、機能概念的に、申請情報入力手段としての申請情報入力部１０２ａ、部署抽出手段としての部署抽出部１０２ｂ、出力手段としての出力部１０２ｃ、マスタメンテ部１０２ｄ等を備えている。

申請情報入力部１０２ａは、社員情報マスタ１０６ａにより申請を起票する社員の所属部署を入力し、用途マスタ１０６ｂにより申請に用いる用途を入力する。例えば、申請者である社員が申請処理を行う場合は、入力画面に対してログイン処理が行われる。ログイン処理では、“社員名”や“社員ＩＤ”などと共に、固有の“パスワード”を入力するため、申請情報入力部１０２ａは、入力された“社員名”に基づいて社員情報マスタ１０６ａから“所属部署”を抽出する。また、申請情報入力部１０２ａは、入力画面の“用途”入力欄をクリックするとドロップダウンリストにより使用可能な用途一覧が表示され、その中から申請者が選択することで“用途”情報を入力することができる。

部署抽出部１０２ｂは、申請情報入力部１０２ａによって入力された“所属部署”と“用途”との組み合わせを部署別用途別支払部署マスタ１０６ｃに照合して、“債務管理部署”あるいは“支払部署”を抽出する。例えば、部署抽出部１０２ｂは、図４に示すように、社員Ａが通常業務として出張申請を行う場合、社員Ａの“所属部署”が社員情報マスタ１０６ａにより「静岡店」であり、申請の“用途”が「通常業務」であるので、部署別用途別支払部署マスタ１０６ｃに照合すると、“債務管理部署”が「東京本社」で、“支払部署”が「東京本社」を抽出する。また、部署抽出部１０２ｂは、図４に示すように、社員Ｂが「通常業務」として出張申請を行う場合、社員Ｂの“所属部署”が社員情報マスタ１０６ａにより「滋賀店」であり、申請の“用途”が「通常業務」であるので、部署別用途別支払部署マスタ１０６ｃに照合すると、“債務管理部署”が「大阪本社」で、“支払部署”が「大阪本社」を抽出する。

出力部１０２ｃは、部署抽出部１０２ｂにより抽出された“債務管理部署”あるいは“支払部署”と、“申請種類”や“金額”などを含む申請データを出力する。出力態様としては、モニタ上に表示したり、紙面上にプリントアウトしたり、ファームバンキングデータ（ＦＢデータ）として出力したりする。

マスタメンテ部１０２ｄは、社員情報マスタ１０６ａ、用途マスタ１０６ｂ、および、部署別用途別支払部署マスタ１０６ｃのうち少なくとも１つのマスタ情報の登録や変更を行う。マスタメンテ部１０２ｄは、情報処理装置１００の運用を開始する前に、これらのマスタ情報を登録しておく。

［３．具体例］
本実施形態の具体例について、図３〜図１５を参照して、本実施形態に係る情報処理装置１００の処理の一例について具体的に説明する。図３は、情報処理装置の処理の流れの一例を示すフローチャートである。図４は、本実施形態の記憶部を構成するマスタの具体例を示す図である。図５は、静岡店に所属する社員が出張申請を行う場合の申請処理の一例を示す図である。図６は、滋賀店に所属する社員が出張申請を行う場合の申請処理の一例を示す図である。図７は、静岡店に所属する社員が滋賀店へ応援に行く場合の申請処理の一例を示す図である。図８は、滋賀店に所属する社員が研修に行く場合の申請処理の一例を示す図である。図９は、滋賀店に所属する社員が支給申請を行う場合の一例を示す図である。図１０は、申請し承認された後の処理イメージの一例を示す図である。図１１は、比較例１における申請処理の一例を示す図である。図１２は、比較例１において所属部署と支払部署とを紐付けるマスタの一例を示す図である。図１３は、比較例２における申請処理の一例を示す図である。図１４は、比較例３における申請処理の一例を示す図である。図１５は、比較例１から３の所属部署と用途と支払部署との関係の一例を示す図である。

［比較例と本実施形態との対比］
支払が発生する申請を起票する場合は、どの部署で債務管理を行い、どの部署で支払を行うのかを決定する必要があった。そこで、特定の管理部署で全員分の申請入力を行う方法では、事務負荷が管理部署に集中する。また、申請者自身で入力する方法では、誤った部署を選択すると確認や修正に手間が掛かり、特に、間違った部署から支払が行われると帳簿上の金額と口座の金額に差異が生じて、それを調整するための手間が発生する。このため、特定の人や部署に負荷をかけることなく、適切な債務管理部署や支払部署が自動入力できることが要望されている。以下、比較例１〜３と本実施形態との対比について説明する。

＜比較例１＞
例えば、図１１に示すように、申請者の“所属部署”と、その部署に対応する“支払部署”が登録されたマスタを作成し、図１２に示すように、小売業を行っている企業が日本全国を複数ブロックに分割し、ブロック毎に旗艦店（東京店、大阪店）を配置し、各ブロックに所属する店舗（千葉店−静岡店−名古屋店、あるいは、滋賀店−三重店−福井店）で発生した交通費は旗艦店で一括支払するものとする。この時、申請者の“所属部署”が「静岡店」の場合は、図１１のマスタにより“支払部署”が「東京店」となり、図１２に示すように、“所属部署”と“支払部署”とが一意に決まるため、自動入力することができる。このように、比較例１では、申請者の間違いを防ぎ、申請確認の手間を削減することができる。

＜比較例２＞
ところが、図１３の比較例２では、「静岡店」に所属する社員が「滋賀店」に応援に行く場合であり、そこで発生した交通費は、応援先の「滋賀店」で発生した交通費として扱うのが適切である。しかし、「滋賀店」の“支払部署”は「大阪店」であるので、「静岡店」に所属する社員でも交通費の支払部署は「大阪店」となる。このため、図１１のマスタを用いると、社員の“所属部署”が「静岡店」の場合に、交通費の“支払部署”を「大阪店」とすることはできない。

＜比較例３＞
また、図１４の比較例３において、各店舗の所属社員（千葉店、静岡店、名古屋店、滋賀店、三重店、福井店）を集めて、東京店で研修する場合の研修参加のための交通費は、人事部のある東京店が全参加者に対して一括で支払うことが適切である。この場合も図１１のマスタでは対応することができず、後で管理部門が調整を行う必要があり、依然管理部門の事務負荷が高くならざるを得なかった。

＜本実施形態＞
これに対し、本実施形態で用いられるマスタの例では、図１５に示すように、“所属部署”に加え、費用が何に使われたのかを示す“用途”を組み合わせることで、“支払部署（あるいは、債務管理部署）”を決定するものである。“用途”については、申請者自身で適切に指定できるため、“所属部署”との組み合わせに対応した“支払部署”を紐付けておく。これにより、費用の“用途”と“所属部署”とを指定するだけで、適切な“支払部署”を自動入力することができる。本実施形態では、図１５に示すように、「静岡店」に所属する社員が通常業務の中で交通費が発生した場合、“用途”として「通常業務」が選択される。これを図１５のマスタに照合すると、“支払部署”として「東京店」が抽出され、支払が実行される（比較例１）。また、「静岡店」に所属する社員が「滋賀店」の応援に行くための交通費が発生すると、“用途”として「近畿応援」が選択される。これを図１５のマスタに照合すると、“支払部署”として「大阪店」が抽出され、支払が実行される（比較例２）。さらに、「静岡店」や「滋賀店」に所属する社員を東京に集めて研修を行う交通費が発生すると、“用途”として「研修参加」が選択される。これを図１５のマスタに照合すると、“支払部署”として「東京店」が抽出され、支払が実行される（比較例３）。このように、比較例１〜３のいずれの場合であっても適切な“支払部署”を抽出することができる。

［処理の流れ］
本実施形態に係る情報処理装置１００の処理の流れは、図３に示すように、管理者がマスタメンテ部１０２ｄを用いて記憶部１０６の社員情報マスタ１０６ａ、用途マスタ１０６ｂ、および、部署別用途別支払部署マスタ１０６ｃに対し予め情報を登録するマスタメンテを行う（ステップＳ１）。

続いて、費用の申請を起票する社員は、不図示のログイン画面を使い、自分の“社員名”あるいは“社員ＩＤ”と“パスワード”とを入力してログインする。その際、申請情報入力部１０２ａは、ログイン時に入力された“社員名”を社員情報マスタ１０６ａに照合することで、当該社員の“所属部署”が入力される（ステップＳ２）。

また、申請を行う社員は、ログイン後の申請画面において、申請の“用途”を入力する。その際、申請情報入力部１０２ａは、社員が“用途”入力欄をクリックすると、用途マスタ１０６ｂから“所属部署”で使用可能な用途一覧をドロップダウンリストとして表示し、該当する用途をクリックすることにより“用途”を入力する（ステップＳ３）。なお、使用可能な“用途”が１つしかない場合は、初期表示させ、２つ以上ある場合はドロップダウンリストの中から申請社員が選択するようにしてもよい。

そして、部署抽出部１０２ｂは、申請社員が入力した“所属部署”と“用途”の組み合わせに基づいて、部署別用途別支払部署マスタ１０６ｃに照合し、この組み合わせに合致する「債務管理部署」あるいは「支払部署」を抽出する（ステップＳ４）。例えば、図４の例では、社員Ａの“所属部署”は、「静岡店」であり、出張申請を行う場合の“用途”は、「通常業務」であるので、部署別用途別支払部署マスタ１０６ｃに示すように、“債務管理部署”は「東京本社」で、“支払部署”は「東京本社」となる。また、社員Ｂの“所属部署”は、「滋賀店」であり、出張申請を行う場合の“用途”は、「通常業務」であるので、部署別用途別支払部署マスタ１０６ｃに示すように、“債務管理部署”は「大阪本社」で、“支払部署”は「大阪本社」となる。

その結果、出力部１０２ｃは、これらの入力情報と抽出情報とに基づいて申請データを出力する。図５の例は、出張申請なので申請データとしての旅費データを出力する（ステップＳ５）。ここでは、“申請種類”が「出張申請」で、“伝票番号”が「１」で、“債務管理部署”が「東京本社」で、“支払部署”が「東京本社」で、“金額”が「１１５，０００」の旅費データを出力する。

［具体的な運用例］
本実施形態に係る情報処理装置１００の具体的な運用例について、図４〜図１０を用いて以下説明する。ここでは、社員情報マスタ１０６ａ、用途マスタ１０６ｂ、部署別用途別支払部署マスタ１０６ｃが、図４に示すように、事前にマスタメンテされているものとする。

［静岡店の社員が出張申請を行う場合］
静岡店に所属する社員Ａが出張申請を行う場合は、情報処理装置１００のモニタ１１４上に表示されたログイン画面に“社員名”あるいは“社員ＩＤ”と、“パスワード”とを入力してログインした後、図５の出張申請の画面を表示させる。申請情報入力部１０２ａは、ログイン情報の“社員名”の「社員Ａ」によって社員情報マスタ１０６ａから“所属部署”の「静岡店」が入力される。

続いて、出張申請の画面の“用途”欄をクリックすると、申請情報入力部１０２ａは、社員Ａが使用可能な用途一覧をドロップダウンリストとして表示させ、その中から選択させる。図５の場合は、「静岡店」に所属する社員が同一ブロック内の「東京本社」に「業務指導のため」出張することは、通常業務の範囲内で、使用可能な“用途”は一つしかないため、「通常業務」が初期表示される。

これにより、部署抽出部１０２ｂは、社員Ａの出張申請において入力された“所属部署”が「静岡店」、“用途”が「通常業務」の組み合わせとなるため、図５の部署別用途別支払部署マスタ１０６ｃに基づいて、“債務管理部署”および“支払部署”が「東京本社」に決まる。

これに基づいて、出力部１０２ｃは、図５に示す旅費データを作成して出力し、申請データ１０６ｄに格納する。この旅費データは、“申請種類”が「出張申請」、“伝票番号”が「１」、“債務管理部署”が「東京本社」、“支払部署”が「東京本社」、“金額”が「１１５，０００」となっている。このように、申請者や承認者は、出張申請するに当たって運用上のルールや社内規則等を意識する必要がないことから、申請手続きの仕方がわかり易く、間違え難い項目を選択することで入力ミスを減らし、入力チェックの手間が掛からなくなる。

［滋賀店の社員が出張申請を行う場合］
滋賀店に所属する社員Ｂが出張申請を行う場合は、ログイン処理により、申請情報入力部１０２ａは、図６に示すように、“社員名”に「社員Ｂ」が入力されると、社員情報マスタ１０６ａを参照して、“所属部署”の「滋賀店」が入力される。

続いて、出張申請の画面の“用途”欄をクリックすると、申請情報入力部１０２ａは、社員Ｂが使用可能な用途一覧がドロップダウンリストとして表示される。ここでは、図６の場合、「滋賀店」に所属する社員が同一ブロック内の「大阪市北区中之島１丁目」に「業務会議に参加するため」出張することは、通常業務の範囲内であり、使用可能な“用途”は一つしかないため、「通常業務」が初期表示される。

これにより、部署抽出部１０２ｂは、社員Ｂの出張申請において入力された“所属部署”が「滋賀店」、“用途”が「通常業務」の組み合わせとなるため、図６の部署別用途別支払部署マスタ１０６ｃに基づいて、“債務管理部署”および“支払部署”が「大阪本社」に決まる。

これに基づいて、出力部１０２ｃは、図６に示す旅費データを作成して出力し、申請データ１０６ｄに格納する。この旅費データは、“申請種類”が「出張申請」、“伝票番号”が「２」、“債務管理部署”が「大阪本社」、“支払部署”が「大阪本社」、“金額”が「１０２，０００」となっている。この場合も、申請者や承認者は、出張申請するに当たって運用上のルールや社内規則等を意識する必要がないため、申請手続きの仕方が容易で、間違え難い項目を選択することで入力ミスを減らし、入力チェックの手間が掛からなくなる。

［静岡店の社員が滋賀店へ応援に行く場合］
静岡店に所属する社員Ａが滋賀店へ応援に行く場合は、ログイン処理により、申請情報入力部１０２ａは、図７に示すように、“社員名”に「社員Ａ」が入力されると、社員情報マスタ１０６ａを参照して、“所属部署”の「静岡店」が入力される。

続いて、出張申請の画面の“用途”欄をクリックすると、申請情報入力部１０２ａは、社員Ａが使用可能な用途一覧がドロップダウンリストとして表示される。ここでは、図７の部署別用途別支払部署マスタ１０６ｃの“用途”に記載されているように、社員Ａが使用可能な用途一覧として、「通常業務」、「近畿応援」、「研修参加」が出張申請画面に表示される。ここでは、静岡店の社員Ａが「滋賀店」へ「業務応援のため」応援に行く場合なので、「近畿応援」に該当することが容易に分かり、これを選択する。

これにより、部署抽出部１０２ｂは、社員Ａの出張申請において入力された“所属部署”が「静岡店」、“用途”が「近畿応援」の組み合わせとなるため、図７の部署別用途別支払部署マスタ１０６ｃに基づいて、“債務管理部署”および“支払部署”が「大阪本社」に決まる。

これに基づいて、出力部１０２ｃは、図７に示す旅費データを作成して出力し、申請データ１０６ｄに格納する。この旅費データは、“申請種類”が「出張申請」、“伝票番号”が「３」、“債務管理部署”が「大阪本社」、“支払部署”が「大阪本社」、“金額”が「７５，０００」となっている。このように、業務の内容が複雑な場合でも、“所属部署”と“用途”を組み合わせることで、適切な“債務管理部署”と“支払部署”を決定することができ、申請手続きの仕方も容易となり、入力ミスも少なくなるため、入力チェックの手間が掛からなくなる。

［滋賀店の社員が研修に行く場合］
滋賀店に所属する社員Ｂが研修に行く場合は、ログイン処理により、申請情報入力部１０２ａは、図８に示すように、“社員名”に「社員Ｂ」が入力されると、社員情報マスタ１０６ａを参照して、“所属部署”の「滋賀店」が入力される。

続いて、出張申請の画面の“用途”欄をクリックすると、申請情報入力部１０２ａは、社員Ｂが使用可能な用途一覧がドロップダウンリストとして表示される。ここでは、図８の部署別用途別支払部署マスタ１０６ｃの“用途”に記載されているように、社員Ｂが使用可能な用途一覧として、「通常業務」、「関東応援」、「研修参加」が出張申請画面に表示される。ここでは、滋賀店の社員Ｂが「東京本社」の研修へ参加するために出張する場合なので、「研修参加」に該当することが容易に分かり、これを選択する。

これにより、部署抽出部１０２ｂは、社員Ｂの出張申請において入力された“所属部署”が「滋賀店」、“用途”が「研修参加」の組み合わせとなるため、図８の部署別用途別支払部署マスタ１０６ｃに基づいて、“債務管理部署”および“支払部署”が「東京本社」に決まる。

これに基づいて、出力部１０２ｃは、図８に示す旅費データを作成して出力し、申請データ１０６ｄに格納する。この旅費データは、“申請種類”が「出張申請」、“伝票番号”が「４」、“債務管理部署”が「東京本社」、“支払部署”が「東京本社」、“金額”が「７５，０００」となっている。このように、業務の内容が複雑な場合でも、“所属部署”と“用途”を組み合わせることで、適切な“債務管理部署”と“支払部署”を決定することができ、申請手続きの仕方も容易で、入力ミスも少なくなるため、承認者は“債務管理部署”と“支払部署”を都度確認する手間が省ける。

［滋賀店の社員が支給申請を行う場合］
滋賀店に所属する社員Ｂが支給申請を行う場合は、ログイン処理により、申請情報入力部１０２ａは、図９に示すように、“社員名”に「社員Ｂ」が入力されると、社員情報マスタ１０６ａを参照して、“所属部署”の「滋賀店」が入力される。

続いて、業者払申請の画面の“用途”欄をクリックすると、申請情報入力部１０２ａは、社員Ｂが使用可能な用途一覧がドロップダウンリストとして表示される。ここでは、図９の部署別用途別支払部署マスタ１０６ｃの“用途”に記載されているように、社員Ｂが使用可能な用途として、「消耗品の購入」が出張申請画面に表示される。ここでは、滋賀店の社員Ｂが「○○○○株式会社」へ「プリントカートリッジを購入するため」得意先に行く場合なので、「消耗品の購入」に該当することが容易に分かり、これを選択する。

これにより、部署抽出部１０２ｂは、社員Ｂの業者払申請において入力された“所属部署”が「滋賀店」、“用途”が「消耗品の購入」の組み合わせとなるため、図９の部署別用途別支払部署マスタ１０６ｃに基づいて、“債務管理部署”が「大阪本店」で、“支払部署”が「東京本社」に決まる。

これに基づいて、出力部１０２ｃは、図９に示す旅費データを作成して出力し、申請データ１０６ｄに格納する。この旅費データは、“申請種類”が「業者払申請」、“伝票番号”が「５」、“債務管理部署”が「大阪本社」、“支払部署”が「東京本社」、“金額”が「４５，０００」となっている。このように、業者への支払例では、“所属部署”と“用途”を組み合わせることで、“債務管理部署”は発生事業所の「大阪本社」で行い、“支払部署”は「東京本社」一括で行うことを適切に決定できる。また、同じ日に同一取引先への支払が複数事業所で発生した場合でも、部署別用途別支払部署マスタ１０６ｃを介して“債務管理部署”と“支払部署”とが自動決定され、まとめて処理できるため、処理回数を減らして、手間と手数料を削減することができる。

［その他の運用例の場合］
また、上記例の他、社員が結婚・出産等の各種祝金、志望慶弔金、傷病・災害見舞金等といったような慶弔見舞金を申請する場合に、金額の大小によって支払部署を分けたい場合は、例えば、３万円以下であれば「各事業所」で支払い、３万円を超える場合には「東京本社」で一括支払いするように設定しても良い。

さらに、“交際費”の項目について、「東京本社」で一元管理したい場合は、得意先への祝金や香典は、「東京本社」の一括支払いとし、それ以外の手土産については営業から手持ちで持って行かれる場合は、各事業所で支払うようにしても良い。

また、上記の図５〜図９における“伝票番号”が「１」〜「５」までの申請が承認された後は、申請データ１０６ｄ内に図１０に示す旅費データ１０６ｄが格納されている。東京本社の経理は、この旅費データ１０６ｄの中から“支払部署”が「東京本社」のみの旅費データを抽出し、図１０の右側のように特定することができる。つまり、“伝票番号”が「２」と「３」の旅費データ１０６ｄは、“支払部署”が「大阪本社」になっているものを除外し、「東京本社」のみをまとめて、銀行振込用のＦＢデータ（ファームバンキングデータ）を作成すれば、複数の処理を一括処理できる。なお、ここでは、ＦＢデータの例を用いて説明したが、この例に限定されず、“支払部署”や“債務管理部署”を抽出キーとして旅費データ１０６ｄをまとめることで、処理回数を減らすことができる。

以上述べたように、本実施形態に係る情報処理装置１００は、“所属部署”に費用の“用途”を加味し、“支払部署”あるいは“債務管理部署”を決定する部署別用途別支払部署マスタ１０６ｃを用いたため、業務が複雑で特別なパターンであっても、“支払部署”や“債務管理部署”を適切に特定することができる。このように、“所属部署”に加え正しい費用の“用途”が選択できれば、正しい“支払部署”や“債務管理部署”が自動決まるため、業務担当者の作業効率を従来よりも大幅に向上させることができる。特に、確認者は、入力された“用途”が正しいかどうかを確認するだけで良いため、チェックし易いという利点がある。

また、本実施形態に係る情報処理装置１００は、“所属部署”と“用途”の入力を各申請者自身で行って自動処理されるため、特定の管理部署への負担の集中を防止することができる。

さらに、本実施形態に係る情報処理装置１００は、社内規定が変わった場合でも管理部門がマスタメンテするだけで対応可能となり、申請者は社内規定の変更を意識することなく利用を継続することができる。このように、セキュリティや内部統制を強化して不正を防止することができると共に、それらを維持するための管理コストを削減することができる。

また、本実施形態に係る情報処理装置１００は、申請者が“用途”を入力する際に、自分が使用可能な所属部署に紐付く“用途”しか選択できないため、誤入力を防ぐことができ、運用スキルの高くない現場担当者や末端の申請者による運用にも適合することができ、教育コストを下げることができる。

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

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

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

また、情報処理装置１００に関して、図示の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。

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

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

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

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

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

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

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

本発明は、費用の支払申請を行う全ての業種や業界において適用可能であり、特に、多店舗展開企業における店舗間の旅費に関する債務管理部署や支払部署を決定する仕組みとして有用である。

１００ 情報処理装置
１０２ 制御部
１０２ａ 申請情報入力部
１０２ｂ 部署抽出部
１０２ｃ 出力部
１０２ｄ マスタメンテ部
１０４ 通信インターフェース部
１０６ 記憶部
１０６ａ 社員情報マスタ
１０６ｂ 用途マスタ
１０６ｃ 部署別用途別支払部署マスタ
１０６ｄ 申請データ
１０８ 入出力インターフェース部
１１２ 入力装置（キーボード）
１１４ 出力装置（モニタ）
２００ サーバ
３００ ネットワーク

Claims (6)

1. 記憶部と制御部とを備え、支払が発生する申請を起票する場合に、当該申請に対する債務管理部署あるいは支払部署を設定する情報処理装置であって、
   前記記憶部には、
   前記申請を起票する社員に関する情報とその所属部署とを登録する社員情報マスタと、
   前記申請に用いられる用途のパターンを登録する用途マスタと、
   前記所属部署と前記用途との組み合わせに対し、これと紐付く債務管理部署あるいは支払部署が登録された部署別用途別支払部署マスタと、
   が格納されており、
   前記制御部は、
   前記社員情報マスタにより申請を起票する社員の所属部署を入力し、前記用途マスタにより前記申請に用いる用途を入力する申請情報入力手段と、
   入力された前記所属部署と前記用途との組み合わせに基づいて、前記部署別用途別支払部署マスタの該当する債務管理部署あるいは支払部署を抽出する部署抽出手段と、
   を備えたこと、
   を特徴とする情報処理装置。
2. 前記記憶部には、
   前記部署抽出手段により抽出された債務管理部署あるいは支払部署と、申請の種類や金額とを含む申請に関するデータを記憶する申請データ
   がさらに格納され、
   前記制御部は、
   前記申請データを出力する出力手段
   をさらに備えたこと、
   を特徴とする請求項１に記載の情報処理装置。
3. 前記制御部は、
   前記社員情報マスタ、前記用途マスタ、および、前記部署別用途別支払部署マスタの少なくとも１つのマスタ情報を登録するマスタメンテ手段
   をさらに備えたこと、
   を特徴とする請求項１または２に記載の情報処理装置。
4. 前記申請情報入力手段は、
   前記申請に用いる用途を入力する場合に、前記用途マスタに登録されている用途のパターンを一覧表示し、その中から選択入力させること、
   を特徴とする請求項２または３に記載の情報処理装置。
5. 記憶部と制御部とを備え、支払が発生する申請を起票する場合に、当該申請に対する債務管理部署あるいは支払部署を設定する情報処理装置で実行される情報処理方法であって、
   前記記憶部には、
   前記申請を起票する社員に関する情報とその所属部署とを登録する社員情報マスタと、
   前記申請に用いられる用途のパターンを登録する用途マスタと、
   前記所属部署と前記用途との組み合わせに対し、これと紐付く債務管理部署あるいは支払部署が登録された部署別用途別支払部署マスタと、
   が格納されており、
   前記制御部で実行される、
   前記社員情報マスタにより申請を起票する社員の所属部署を入力し、前記用途マスタにより前記申請に用いる用途を入力する申請情報入力ステップと、
   入力された前記所属部署と前記用途との組み合わせに基づいて、前記部署別用途別支払部署マスタの該当する債務管理部署あるいは支払部署を抽出する部署抽出ステップと、
   を含むこと、
   を特徴とする情報処理方法。
6. 記憶部と制御部とを備え、支払が発生する申請を起票する場合に、当該申請に対する債務管理部署あるいは支払部署を設定する情報処理装置で実行させるための情報処理プログラムであって、
   前記記憶部には、
   前記申請を起票する社員に関する情報とその所属部署とを登録する社員情報マスタと、
   前記申請に用いられる用途のパターンを登録する用途マスタと、
   前記所属部署と前記用途との組み合わせに対し、これと紐付く債務管理部署あるいは支払部署が登録された部署別用途別支払部署マスタと、
   が格納されており、
   前記制御部で実行させるための、
   前記社員情報マスタにより申請を起票する社員の所属部署を入力し、前記用途マスタにより前記申請に用いる用途を入力する申請情報入力ステップと、
   入力された前記所属部署と前記用途との組み合わせに基づいて、前記部署別用途別支払部署マスタの該当する債務管理部署あるいは支払部署を抽出する部署抽出ステップと、
   を含むこと、
   を特徴とする情報処理プログラム。

Images