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

情報処理装置、情報処理方法および情報処理プログラム Download PDF

Info

Publication number
JP7049943B2
JP7049943B2 JP2018120709A JP2018120709A JP7049943B2 JP 7049943 B2 JP7049943 B2 JP 7049943B2 JP 2018120709 A JP2018120709 A JP 2018120709A JP 2018120709 A JP2018120709 A JP 2018120709A JP 7049943 B2 JP7049943 B2 JP 7049943B2
Authority
JP
Japan
Prior art keywords
department
application
master
payment
employee
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2018120709A
Other languages
English (en)
Other versions
JP2020003914A (ja
Inventor
健 李
太河 佐藤
献 稲垣
剛光 上野
Original Assignee
株式会社オービック
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社オービック filed Critical 株式会社オービック
Priority to JP2018120709A priority Critical patent/JP7049943B2/ja
Publication of JP2020003914A publication Critical patent/JP2020003914A/ja
Application granted granted Critical
Publication of JP7049943B2 publication Critical patent/JP7049943B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Description

本発明は、情報処理装置、情報処理方法および情報処理プログラムに関する。
従来では、支払が発生する申請を行う際に、申請者が債務管理部署あるいは支払部署を選択して入力していた。例えば、非特許文献1には、交通費精算を行う画面上で申請者が支払部署としての負担部署を選択して入力を行う交通費精算システムが開示されている。また、どの部署で債務管理や支払を行うかは、申請者が所属する部署によって自動で決定していた。例えば、非特許文献2には、旅費/交通費申請書において、申請者の名前や所属部署を入力することで、支払部署としての負担部署が自動で決定される差額支給処理システムが開示されている。
しかしながら、上記非特許文献1では、申請者が負担部署を自ら選択して入力していたため、誤った部署を選択する可能性があり、確認や修正の手間が生じるという課題があった。また、上記非特許文献2では、入力された申請者の名前や所属部署に対応した負担部署が登録されたマスタなどを利用することで、入力者の所属部署を費用負担部署として決定していたが、所属部署と費用負担部署とが異なるパターンには対応できないという課題があった。
本発明は、上記に鑑みてなされたものであって、支払が発生する申請を起票する際に、様々な申請パターンに対して正しい債務管理部署や支払部署を設定することができる情報処理装置、情報処理方法および情報処理プログラムを提供することを目的とする。
上述した課題を解決し、目的を達成するために、本発明に係る情報処理装置は、記憶部と制御部とを備え、支払が発生する申請を起票する場合に、当該申請に対する債務管理部署あるいは支払部署を設定する情報処理装置であって、前記記憶部には、前記申請を起票する社員に関する情報とその所属部署とを登録する社員情報マスタと、前記申請に用いられる用途のパターンを登録する用途マスタと、前記所属部署と前記用途との組み合わせに対し、これと紐付く債務管理部署あるいは支払部署が登録された部署別用途別支払部署マスタと、が格納されており、前記制御部は、前記社員情報マスタにより申請を起票する社員の所属部署を入力し、前記用途マスタにより前記申請に用いる用途を入力する申請情報入力手段と、入力された前記所属部署と前記用途との組み合わせに基づいて、前記部署別用途別支払部署マスタの該当する債務管理部署あるいは支払部署を抽出する部署抽出手段と、を備えたこと、を特徴とする。
また、本発明に係る情報処理装置は、前記記憶部には、前記部署抽出手段により抽出された債務管理部署あるいは支払部署と、申請の種類や金額とを含む申請に関するデータを記憶する申請データがさらに格納され、前記制御部は、前記申請データを出力する出力手段をさらに備えたこと、を特徴とする。
また、本発明に係る情報処理装置は、前記制御部は、前記社員情報マスタ、前記用途マスタ、および、前記部署別用途別支払部署マスタの少なくとも1つのマスタ情報を登録するマスタメンテ手段をさらに備えたこと、を特徴とする。
また、本発明に係る情報処理装置は、前記申請情報入力手段は、前記申請に用いる用途を入力する場合に、前記用途マスタに登録されている用途のパターンを一覧表示し、その中から選択入力させること、を特徴とする。
また、本発明に係る情報処理方法は、記憶部と制御部とを備え、支払が発生する申請を起票する場合に、当該申請に対する債務管理部署あるいは支払部署を設定する情報処理装置で実行される情報処理方法であって、前記記憶部には、前記申請を起票する社員に関する情報とその所属部署とを登録する社員情報マスタと、前記申請に用いられる用途のパターンを登録する用途マスタと、前記所属部署と前記用途との組み合わせに対し、これと紐付く債務管理部署あるいは支払部署が登録された部署別用途別支払部署マスタと、が格納されており、前記制御部で実行される、前記社員情報マスタにより申請を起票する社員の所属部署を入力し、前記用途マスタにより前記申請に用いる用途を入力する申請情報入力ステップと、入力された前記所属部署と前記用途との組み合わせに基づいて、前記部署別用途別支払部署マスタの該当する債務管理部署あるいは支払部署を抽出する部署抽出ステップと、を含むこと、を特徴とする。
また、本発明に係る情報処理プログラムは、記憶部と制御部とを備え、支払が発生する申請を起票する場合に、当該申請に対する債務管理部署あるいは支払部署を設定する情報処理装置で実行させるための情報処理プログラムであって、前記記憶部には、前記申請を起票する社員に関する情報とその所属部署とを登録する社員情報マスタと、前記申請に用いられる用途のパターンを登録する用途マスタと、前記所属部署と前記用途との組み合わせに対し、これと紐付く債務管理部署あるいは支払部署が登録された部署別用途別支払部署マスタと、が格納されており、前記制御部で実行させるための、前記社員情報マスタにより申請を起票する社員の所属部署を入力し、前記用途マスタにより前記申請に用いる用途を入力する申請情報入力ステップと、入力された前記所属部署と前記用途との組み合わせに基づいて、前記部署別用途別支払部署マスタの該当する債務管理部署あるいは支払部署を抽出する部署抽出ステップと、を含むこと、を特徴とする。
本発明によれば、支払が発生する申請を起票する際に、様々な申請パターンに対して正しい債務管理部署や支払部署を設定することができるという効果を奏する。
図1は、本実施形態に係る情報処理装置の構成の一例を示すブロック図である。 図2は、記憶部を構成するマスタの内部構造の一例を示す図である。 図3は、情報処理装置の処理の流れの一例を示すフローチャートである。 図4は、本実施形態の記憶部を構成するマスタの具体例を示す図である。 図5は、静岡店に所属する社員が出張申請を行う場合の申請処理の一例を示す図である。 図6は、滋賀店に所属する社員が出張申請を行う場合の申請処理の一例を示す図である。 図7は、静岡店に所属する社員が滋賀店へ応援に行く場合の申請処理の一例を示す図である。 図8は、滋賀店に所属する社員が研修に行く場合の申請処理の一例を示す図である。 図9は、滋賀店に所属する社員が支給申請を行う場合の一例を示す図である。 図10は、申請し承認された後の処理イメージの一例を示す図である。 図11は、比較例1における申請処理の一例を示す図である。 図12は、比較例1において所属部署と支払部署とを紐付けるマスタの一例を示す図である。 図13は、比較例2における申請処理の一例を示す図である。 図14は、比較例3における申請処理の一例を示す図である。 図15は、比較例1から3の所属部署と用途と支払部署との関係の一例を示す図である。
本発明の実施形態を図面に基づいて詳細に説明する。なお、本発明は本実施形態により限定されるものではない。
[1.概要]
従来は、支払の申請者が所属する所属部署によって、どの部署で債務管理や支払を行うかを自動的に決定していた。しかしながら、起票者が同じであっても費用の用途に応じて債務管理部署や支払部署が変わる場合があるため、自動設定で対応することができなかった。
そこで、本実施形態に係る情報処理装置は、申請者の“所属部署”と“用途”との組み合わせにより、債務管理部署や支払部署を自動で入力するようにしたものである。入力が必要な“用途”については、申請者も適切に指定することができるため、“所属部署”と“用途”との組み合わせと紐付けることで、適切な債務管理部署や支払部署を自動で入力することができる。また、申請者の“所属部署”が同じ場合でも、費用の“用途”に応じて債務管理部署や支払部署が変わる場合もあり、これに対応することができる。このように、本実施形態に係る情報処理装置は、費用申請に関する債務管理部署や支払部署を自動で入力することができるため、業務担当者の作業効率を従来よりも大幅に向上させることができる。さらに、本実施形態に係る情報処理装置は、運用スキルの高くない現場担当者(末端の申請者)であっても適切に運用することが可能となる。
[2.構成]
本実施形態に係る情報処理装置の構成の一例について、図1および図2を参照して説明する。図1は、本実施形態に係る情報処理装置の構成の一例を示すブロック図である。図2は、記憶部を構成するマスタの内部構造の一例を示す図である。
情報処理装置100は、市販のデスクトップ型パーソナルコンピュータである。なお、情報処理装置100は、デスクトップ型パーソナルコンピュータのような据置型情報処理装置に限らず、市販されているノート型パーソナルコンピュータ、PDA(Personal Digital Assistants)、スマートフォン、タブレット型パーソナルコンピュータなどの携帯型情報処理装置であってもよい。
情報処理装置100は、制御部102と通信インターフェース部104と記憶部106と入出力インターフェース部108と、を備えている。情報処理装置100が備えている各部は、任意の通信路を介して通信可能に接続されている。
通信インターフェース部104は、ルータ等の通信装置および専用線等の有線又は無線の通信回線を介して、情報処理装置100をネットワーク300に通信可能に接続する。通信インターフェース部104は、他の装置と通信回線を介してデータを通信する機能を有する。ここで、ネットワーク300は、情報処理装置100とサーバ200とを相互に通信可能に接続する機能を有し、例えばインターネットやLAN(Local Area Network)等である。
記憶部106には、各種のデータベース、テーブル、およびファイルなどが格納される。記憶部106には、OS(Operating System)と協働してCPU(Central Processing Unit)に命令を与えて各種処理を行うためのコンピュータプログラムが記録される。記憶部106として、例えば、RAM(Random Access Memory)・ROM(Read Only Memory)等のメモリ装置、ハードディスクのような固定ディスク装置、フレキシブルディスク、および光ディスク等を用いることができる。ここで、記憶部106は、社員情報マスタ106a、用途マスタ106b、部署別用途別支払部署マスタ106c、申請データ106d等を備えている。
社員情報マスタ106aは、支払申請を起票する社員に関する情報とその所属部署とを登録するマスタである。例えば、社員情報マスタ106aは、図2に示すように、主キーとしての“社員名”と、それに紐付く“所属部署”とが登録されている。このため、ログイン処理の際に、“社員名”や“社員ID”などを入力すると、社員情報マスタ106aから“所属部署”が抽出される。
用途マスタ106bは、支払申請に用いられる用途のパターンを登録するマスタである。例えば、用途マスタ106bは、図2に示すように、主キーとして使用可能な“用途名(用途)”のパターンが登録されている。このため、申請者が画面上で“用途名”を入力する際に、登録されている“用途名”のパターンをドロップダウンリストとして表示させ、その中から選択させることにより、運用スキルが高くなくても適切に入力することができる。
部署別用途別支払部署マスタ106cは、“所属部署”と“用途名(用途)”との組み合わせに対し、これと紐付く債務管理部署あるいは支払部署が登録されたマスタである。例えば、部署別用途別支払部署マスタ106cは、図2に示すように、主キーとして“所属部署”と“用途名(用途)”との組み合わせに対応した債務管理部署や支払部署が登録されている。このため、主キーの“所属部署”と“用途名(用途)”とを入力すると、この組み合わせに応じた債務管理部署や支払部署を抽出することができる。
申請データ106dは、部署抽出部102bによって抽出された債務管理部署や支払部署の他、申請の種類や金額などを含む申請に関するデータを記憶している。この申請データ106dには、申請の種類によって色々なデータが記憶される。例えば、本実施形態の申請処理の一例を示す図5では、出張申請に係る申請データとして、旅費データを記憶している。この旅費データ(申請データに相当するため、図中も同じ符号106dとする)には、図5に示すように、“申請種類”、“伝票番号”、“債務管理部署”、“支払部署”、“金額”などが含まれている。
入出力インターフェース部108には、入力装置112および出力装置114が接続されている。出力装置114には、モニタ(家庭用テレビを含む)の他、スピーカやプリンタを用いることができる。入力装置112には、キーボード、マウス、およびマイクの他、マウスと協働してポインティングデバイス機能を実現するモニタを用いることができる。なお、以下では、出力装置114をモニタ114とし、入力装置112をキーボード112またはマウス112として記載する場合がある。
制御部102は、情報処理装置100を統括的に制御するCPU等である。制御部102は、OS等の制御プログラム・各種の処理手順等を規定したプログラム・所要データなどを格納するための内部メモリを有し、格納されているこれらのプログラムに基づいて種々の情報処理を実行する。ここで、制御部102は、機能概念的に、申請情報入力手段としての申請情報入力部102a、部署抽出手段としての部署抽出部102b、出力手段としての出力部102c、マスタメンテ部102d等を備えている。
申請情報入力部102aは、社員情報マスタ106aにより申請を起票する社員の所属部署を入力し、用途マスタ106bにより申請に用いる用途を入力する。例えば、申請者である社員が申請処理を行う場合は、入力画面に対してログイン処理が行われる。ログイン処理では、“社員名”や“社員ID”などと共に、固有の“パスワード”を入力するため、申請情報入力部102aは、入力された“社員名”に基づいて社員情報マスタ106aから“所属部署”を抽出する。また、申請情報入力部102aは、入力画面の“用途”入力欄をクリックするとドロップダウンリストにより使用可能な用途一覧が表示され、その中から申請者が選択することで“用途”情報を入力することができる。
部署抽出部102bは、申請情報入力部102aによって入力された“所属部署”と“用途”との組み合わせを部署別用途別支払部署マスタ106cに照合して、“債務管理部署”あるいは“支払部署”を抽出する。例えば、部署抽出部102bは、図4に示すように、社員Aが通常業務として出張申請を行う場合、社員Aの“所属部署”が社員情報マスタ106aにより「静岡店」であり、申請の“用途”が「通常業務」であるので、部署別用途別支払部署マスタ106cに照合すると、“債務管理部署”が「東京本社」で、“支払部署”が「東京本社」を抽出する。また、部署抽出部102bは、図4に示すように、社員Bが「通常業務」として出張申請を行う場合、社員Bの“所属部署”が社員情報マスタ106aにより「滋賀店」であり、申請の“用途”が「通常業務」であるので、部署別用途別支払部署マスタ106cに照合すると、“債務管理部署”が「大阪本社」で、“支払部署”が「大阪本社」を抽出する。
出力部102cは、部署抽出部102bにより抽出された“債務管理部署”あるいは“支払部署”と、“申請種類”や“金額”などを含む申請データを出力する。出力態様としては、モニタ上に表示したり、紙面上にプリントアウトしたり、ファームバンキングデータ(FBデータ)として出力したりする。
マスタメンテ部102dは、社員情報マスタ106a、用途マスタ106b、および、部署別用途別支払部署マスタ106cのうち少なくとも1つのマスタ情報の登録や変更を行う。マスタメンテ部102dは、情報処理装置100の運用を開始する前に、これらのマスタ情報を登録しておく。
[3.具体例]
本実施形態の具体例について、図3~図15を参照して、本実施形態に係る情報処理装置100の処理の一例について具体的に説明する。図3は、情報処理装置の処理の流れの一例を示すフローチャートである。図4は、本実施形態の記憶部を構成するマスタの具体例を示す図である。図5は、静岡店に所属する社員が出張申請を行う場合の申請処理の一例を示す図である。図6は、滋賀店に所属する社員が出張申請を行う場合の申請処理の一例を示す図である。図7は、静岡店に所属する社員が滋賀店へ応援に行く場合の申請処理の一例を示す図である。図8は、滋賀店に所属する社員が研修に行く場合の申請処理の一例を示す図である。図9は、滋賀店に所属する社員が支給申請を行う場合の一例を示す図である。図10は、申請し承認された後の処理イメージの一例を示す図である。図11は、比較例1における申請処理の一例を示す図である。図12は、比較例1において所属部署と支払部署とを紐付けるマスタの一例を示す図である。図13は、比較例2における申請処理の一例を示す図である。図14は、比較例3における申請処理の一例を示す図である。図15は、比較例1から3の所属部署と用途と支払部署との関係の一例を示す図である。
[比較例と本実施形態との対比]
支払が発生する申請を起票する場合は、どの部署で債務管理を行い、どの部署で支払を行うのかを決定する必要があった。そこで、特定の管理部署で全員分の申請入力を行う方法では、事務負荷が管理部署に集中する。また、申請者自身で入力する方法では、誤った部署を選択すると確認や修正に手間が掛かり、特に、間違った部署から支払が行われると帳簿上の金額と口座の金額に差異が生じて、それを調整するための手間が発生する。このため、特定の人や部署に負荷をかけることなく、適切な債務管理部署や支払部署が自動入力できることが要望されている。以下、比較例1~3と本実施形態との対比について説明する。
<比較例1>
例えば、図11に示すように、申請者の“所属部署”と、その部署に対応する“支払部署”が登録されたマスタを作成し、図12に示すように、小売業を行っている企業が日本全国を複数ブロックに分割し、ブロック毎に旗艦店(東京店、大阪店)を配置し、各ブロックに所属する店舗(千葉店-静岡店-名古屋店、あるいは、滋賀店-三重店-福井店)で発生した交通費は旗艦店で一括支払するものとする。この時、申請者の“所属部署”が「静岡店」の場合は、図11のマスタにより“支払部署”が「東京店」となり、図12に示すように、“所属部署”と“支払部署”とが一意に決まるため、自動入力することができる。このように、比較例1では、申請者の間違いを防ぎ、申請確認の手間を削減することができる。
<比較例2>
ところが、図13の比較例2では、「静岡店」に所属する社員が「滋賀店」に応援に行く場合であり、そこで発生した交通費は、応援先の「滋賀店」で発生した交通費として扱うのが適切である。しかし、「滋賀店」の“支払部署”は「大阪店」であるので、「静岡店」に所属する社員でも交通費の支払部署は「大阪店」となる。このため、図11のマスタを用いると、社員の“所属部署”が「静岡店」の場合に、交通費の“支払部署”を「大阪店」とすることはできない。
<比較例3>
また、図14の比較例3において、各店舗の所属社員(千葉店、静岡店、名古屋店、滋賀店、三重店、福井店)を集めて、東京店で研修する場合の研修参加のための交通費は、人事部のある東京店が全参加者に対して一括で支払うことが適切である。この場合も図11のマスタでは対応することができず、後で管理部門が調整を行う必要があり、依然管理部門の事務負荷が高くならざるを得なかった。
<本実施形態>
これに対し、本実施形態で用いられるマスタの例では、図15に示すように、“所属部署”に加え、費用が何に使われたのかを示す“用途”を組み合わせることで、“支払部署(あるいは、債務管理部署)”を決定するものである。“用途”については、申請者自身で適切に指定できるため、“所属部署”との組み合わせに対応した“支払部署”を紐付けておく。これにより、費用の“用途”と“所属部署”とを指定するだけで、適切な“支払部署”を自動入力することができる。本実施形態では、図15に示すように、「静岡店」に所属する社員が通常業務の中で交通費が発生した場合、“用途”として「通常業務」が選択される。これを図15のマスタに照合すると、“支払部署”として「東京店」が抽出され、支払が実行される(比較例1)。また、「静岡店」に所属する社員が「滋賀店」の応援に行くための交通費が発生すると、“用途”として「近畿応援」が選択される。これを図15のマスタに照合すると、“支払部署”として「大阪店」が抽出され、支払が実行される(比較例2)。さらに、「静岡店」や「滋賀店」に所属する社員を東京に集めて研修を行う交通費が発生すると、“用途”として「研修参加」が選択される。これを図15のマスタに照合すると、“支払部署”として「東京店」が抽出され、支払が実行される(比較例3)。このように、比較例1~3のいずれの場合であっても適切な“支払部署”を抽出することができる。
[処理の流れ]
本実施形態に係る情報処理装置100の処理の流れは、図3に示すように、管理者がマスタメンテ部102dを用いて記憶部106の社員情報マスタ106a、用途マスタ106b、および、部署別用途別支払部署マスタ106cに対し予め情報を登録するマスタメンテを行う(ステップS1)。
続いて、費用の申請を起票する社員は、不図示のログイン画面を使い、自分の“社員名”あるいは“社員ID”と“パスワード”とを入力してログインする。その際、申請情報入力部102aは、ログイン時に入力された“社員名”を社員情報マスタ106aに照合することで、当該社員の“所属部署”が入力される(ステップS2)。
また、申請を行う社員は、ログイン後の申請画面において、申請の“用途”を入力する。その際、申請情報入力部102aは、社員が“用途”入力欄をクリックすると、用途マスタ106bから“所属部署”で使用可能な用途一覧をドロップダウンリストとして表示し、該当する用途をクリックすることにより“用途”を入力する(ステップS3)。なお、使用可能な“用途”が1つしかない場合は、初期表示させ、2つ以上ある場合はドロップダウンリストの中から申請社員が選択するようにしてもよい。
そして、部署抽出部102bは、申請社員が入力した“所属部署”と“用途”の組み合わせに基づいて、部署別用途別支払部署マスタ106cに照合し、この組み合わせに合致する「債務管理部署」あるいは「支払部署」を抽出する(ステップS4)。例えば、図4の例では、社員Aの“所属部署”は、「静岡店」であり、出張申請を行う場合の“用途”は、「通常業務」であるので、部署別用途別支払部署マスタ106cに示すように、“債務管理部署”は「東京本社」で、“支払部署”は「東京本社」となる。また、社員Bの“所属部署”は、「滋賀店」であり、出張申請を行う場合の“用途”は、「通常業務」であるので、部署別用途別支払部署マスタ106cに示すように、“債務管理部署”は「大阪本社」で、“支払部署”は「大阪本社」となる。
その結果、出力部102cは、これらの入力情報と抽出情報とに基づいて申請データを出力する。図5の例は、出張申請なので申請データとしての旅費データを出力する(ステップS5)。ここでは、“申請種類”が「出張申請」で、“伝票番号”が「1」で、“債務管理部署”が「東京本社」で、“支払部署”が「東京本社」で、“金額”が「115,000」の旅費データを出力する。
[具体的な運用例]
本実施形態に係る情報処理装置100の具体的な運用例について、図4~図10を用いて以下説明する。ここでは、社員情報マスタ106a、用途マスタ106b、部署別用途別支払部署マスタ106cが、図4に示すように、事前にマスタメンテされているものとする。
[静岡店の社員が出張申請を行う場合]
静岡店に所属する社員Aが出張申請を行う場合は、情報処理装置100のモニタ114上に表示されたログイン画面に“社員名”あるいは“社員ID”と、“パスワード”とを入力してログインした後、図5の出張申請の画面を表示させる。申請情報入力部102aは、ログイン情報の“社員名”の「社員A」によって社員情報マスタ106aから“所属部署”の「静岡店」が入力される。
続いて、出張申請の画面の“用途”欄をクリックすると、申請情報入力部102aは、社員Aが使用可能な用途一覧をドロップダウンリストとして表示させ、その中から選択させる。図5の場合は、「静岡店」に所属する社員が同一ブロック内の「東京本社」に「業務指導のため」出張することは、通常業務の範囲内で、使用可能な“用途”は一つしかないため、「通常業務」が初期表示される。
これにより、部署抽出部102bは、社員Aの出張申請において入力された“所属部署”が「静岡店」、“用途”が「通常業務」の組み合わせとなるため、図5の部署別用途別支払部署マスタ106cに基づいて、“債務管理部署”および“支払部署”が「東京本社」に決まる。
これに基づいて、出力部102cは、図5に示す旅費データを作成して出力し、申請データ106dに格納する。この旅費データは、“申請種類”が「出張申請」、“伝票番号”が「1」、“債務管理部署”が「東京本社」、“支払部署”が「東京本社」、“金額”が「115,000」となっている。このように、申請者や承認者は、出張申請するに当たって運用上のルールや社内規則等を意識する必要がないことから、申請手続きの仕方がわかり易く、間違え難い項目を選択することで入力ミスを減らし、入力チェックの手間が掛からなくなる。
[滋賀店の社員が出張申請を行う場合]
滋賀店に所属する社員Bが出張申請を行う場合は、ログイン処理により、申請情報入力部102aは、図6に示すように、“社員名”に「社員B」が入力されると、社員情報マスタ106aを参照して、“所属部署”の「滋賀店」が入力される。
続いて、出張申請の画面の“用途”欄をクリックすると、申請情報入力部102aは、社員Bが使用可能な用途一覧がドロップダウンリストとして表示される。ここでは、図6の場合、「滋賀店」に所属する社員が同一ブロック内の「大阪市北区中之島1丁目」に「業務会議に参加するため」出張することは、通常業務の範囲内であり、使用可能な“用途”は一つしかないため、「通常業務」が初期表示される。
これにより、部署抽出部102bは、社員Bの出張申請において入力された“所属部署”が「滋賀店」、“用途”が「通常業務」の組み合わせとなるため、図6の部署別用途別支払部署マスタ106cに基づいて、“債務管理部署”および“支払部署”が「大阪本社」に決まる。
これに基づいて、出力部102cは、図6に示す旅費データを作成して出力し、申請データ106dに格納する。この旅費データは、“申請種類”が「出張申請」、“伝票番号”が「2」、“債務管理部署”が「大阪本社」、“支払部署”が「大阪本社」、“金額”が「102,000」となっている。この場合も、申請者や承認者は、出張申請するに当たって運用上のルールや社内規則等を意識する必要がないため、申請手続きの仕方が容易で、間違え難い項目を選択することで入力ミスを減らし、入力チェックの手間が掛からなくなる。
[静岡店の社員が滋賀店へ応援に行く場合]
静岡店に所属する社員Aが滋賀店へ応援に行く場合は、ログイン処理により、申請情報入力部102aは、図7に示すように、“社員名”に「社員A」が入力されると、社員情報マスタ106aを参照して、“所属部署”の「静岡店」が入力される。
続いて、出張申請の画面の“用途”欄をクリックすると、申請情報入力部102aは、社員Aが使用可能な用途一覧がドロップダウンリストとして表示される。ここでは、図7の部署別用途別支払部署マスタ106cの“用途”に記載されているように、社員Aが使用可能な用途一覧として、「通常業務」、「近畿応援」、「研修参加」が出張申請画面に表示される。ここでは、静岡店の社員Aが「滋賀店」へ「業務応援のため」応援に行く場合なので、「近畿応援」に該当することが容易に分かり、これを選択する。
これにより、部署抽出部102bは、社員Aの出張申請において入力された“所属部署”が「静岡店」、“用途”が「近畿応援」の組み合わせとなるため、図7の部署別用途別支払部署マスタ106cに基づいて、“債務管理部署”および“支払部署”が「大阪本社」に決まる。
これに基づいて、出力部102cは、図7に示す旅費データを作成して出力し、申請データ106dに格納する。この旅費データは、“申請種類”が「出張申請」、“伝票番号”が「3」、“債務管理部署”が「大阪本社」、“支払部署”が「大阪本社」、“金額”が「75,000」となっている。このように、業務の内容が複雑な場合でも、“所属部署”と“用途”を組み合わせることで、適切な“債務管理部署”と“支払部署”を決定することができ、申請手続きの仕方も容易となり、入力ミスも少なくなるため、入力チェックの手間が掛からなくなる。
[滋賀店の社員が研修に行く場合]
滋賀店に所属する社員Bが研修に行く場合は、ログイン処理により、申請情報入力部102aは、図8に示すように、“社員名”に「社員B」が入力されると、社員情報マスタ106aを参照して、“所属部署”の「滋賀店」が入力される。
続いて、出張申請の画面の“用途”欄をクリックすると、申請情報入力部102aは、社員Bが使用可能な用途一覧がドロップダウンリストとして表示される。ここでは、図8の部署別用途別支払部署マスタ106cの“用途”に記載されているように、社員Bが使用可能な用途一覧として、「通常業務」、「関東応援」、「研修参加」が出張申請画面に表示される。ここでは、滋賀店の社員Bが「東京本社」の研修へ参加するために出張する場合なので、「研修参加」に該当することが容易に分かり、これを選択する。
これにより、部署抽出部102bは、社員Bの出張申請において入力された“所属部署”が「滋賀店」、“用途”が「研修参加」の組み合わせとなるため、図8の部署別用途別支払部署マスタ106cに基づいて、“債務管理部署”および“支払部署”が「東京本社」に決まる。
これに基づいて、出力部102cは、図8に示す旅費データを作成して出力し、申請データ106dに格納する。この旅費データは、“申請種類”が「出張申請」、“伝票番号”が「4」、“債務管理部署”が「東京本社」、“支払部署”が「東京本社」、“金額”が「75,000」となっている。このように、業務の内容が複雑な場合でも、“所属部署”と“用途”を組み合わせることで、適切な“債務管理部署”と“支払部署”を決定することができ、申請手続きの仕方も容易で、入力ミスも少なくなるため、承認者は“債務管理部署”と“支払部署”を都度確認する手間が省ける。
[滋賀店の社員が支給申請を行う場合]
滋賀店に所属する社員Bが支給申請を行う場合は、ログイン処理により、申請情報入力部102aは、図9に示すように、“社員名”に「社員B」が入力されると、社員情報マスタ106aを参照して、“所属部署”の「滋賀店」が入力される。
続いて、業者払申請の画面の“用途”欄をクリックすると、申請情報入力部102aは、社員Bが使用可能な用途一覧がドロップダウンリストとして表示される。ここでは、図9の部署別用途別支払部署マスタ106cの“用途”に記載されているように、社員Bが使用可能な用途として、「消耗品の購入」が出張申請画面に表示される。ここでは、滋賀店の社員Bが「○○○○株式会社」へ「プリントカートリッジを購入するため」得意先に行く場合なので、「消耗品の購入」に該当することが容易に分かり、これを選択する。
これにより、部署抽出部102bは、社員Bの業者払申請において入力された“所属部署”が「滋賀店」、“用途”が「消耗品の購入」の組み合わせとなるため、図9の部署別用途別支払部署マスタ106cに基づいて、“債務管理部署”が「大阪本店」で、“支払部署”が「東京本社」に決まる。
これに基づいて、出力部102cは、図9に示す旅費データを作成して出力し、申請データ106dに格納する。この旅費データは、“申請種類”が「業者払申請」、“伝票番号”が「5」、“債務管理部署”が「大阪本社」、“支払部署”が「東京本社」、“金額”が「45,000」となっている。このように、業者への支払例では、“所属部署”と“用途”を組み合わせることで、“債務管理部署”は発生事業所の「大阪本社」で行い、“支払部署”は「東京本社」一括で行うことを適切に決定できる。また、同じ日に同一取引先への支払が複数事業所で発生した場合でも、部署別用途別支払部署マスタ106cを介して“債務管理部署”と“支払部署”とが自動決定され、まとめて処理できるため、処理回数を減らして、手間と手数料を削減することができる。
[その他の運用例の場合]
また、上記例の他、社員が結婚・出産等の各種祝金、志望慶弔金、傷病・災害見舞金等といったような慶弔見舞金を申請する場合に、金額の大小によって支払部署を分けたい場合は、例えば、3万円以下であれば「各事業所」で支払い、3万円を超える場合には「東京本社」で一括支払いするように設定しても良い。
さらに、“交際費”の項目について、「東京本社」で一元管理したい場合は、得意先への祝金や香典は、「東京本社」の一括支払いとし、それ以外の手土産については営業から手持ちで持って行かれる場合は、各事業所で支払うようにしても良い。
また、上記の図5~図9における“伝票番号”が「1」~「5」までの申請が承認された後は、申請データ106d内に図10に示す旅費データ106dが格納されている。東京本社の経理は、この旅費データ106dの中から“支払部署”が「東京本社」のみの旅費データを抽出し、図10の右側のように特定することができる。つまり、“伝票番号”が「2」と「3」の旅費データ106dは、“支払部署”が「大阪本社」になっているものを除外し、「東京本社」のみをまとめて、銀行振込用のFBデータ(ファームバンキングデータ)を作成すれば、複数の処理を一括処理できる。なお、ここでは、FBデータの例を用いて説明したが、この例に限定されず、“支払部署”や“債務管理部署”を抽出キーとして旅費データ106dをまとめることで、処理回数を減らすことができる。
以上述べたように、本実施形態に係る情報処理装置100は、“所属部署”に費用の“用途”を加味し、“支払部署”あるいは“債務管理部署”を決定する部署別用途別支払部署マスタ106cを用いたため、業務が複雑で特別なパターンであっても、“支払部署”や“債務管理部署”を適切に特定することができる。このように、“所属部署”に加え正しい費用の“用途”が選択できれば、正しい“支払部署”や“債務管理部署”が自動決まるため、業務担当者の作業効率を従来よりも大幅に向上させることができる。特に、確認者は、入力された“用途”が正しいかどうかを確認するだけで良いため、チェックし易いという利点がある。
また、本実施形態に係る情報処理装置100は、“所属部署”と“用途”の入力を各申請者自身で行って自動処理されるため、特定の管理部署への負担の集中を防止することができる。
さらに、本実施形態に係る情報処理装置100は、社内規定が変わった場合でも管理部門がマスタメンテするだけで対応可能となり、申請者は社内規定の変更を意識することなく利用を継続することができる。このように、セキュリティや内部統制を強化して不正を防止することができると共に、それらを維持するための管理コストを削減することができる。
また、本実施形態に係る情報処理装置100は、申請者が“用途”を入力する際に、自分が使用可能な所属部署に紐付く“用途”しか選択できないため、誤入力を防ぐことができ、運用スキルの高くない現場担当者や末端の申請者による運用にも適合することができ、教育コストを下げることができる。
[4.他の実施形態]
本発明は、上述した実施形態以外にも、特許請求の範囲に記載した技術的思想の範囲内において種々の異なる実施形態にて実施されてよいものである。
例えば、実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。
また、本明細書中や図面中で示した処理手順、制御手順、具体的名称、各処理の登録データや検索条件等のパラメータを含む情報、画面例、データベース構成については、特記する場合を除いて任意に変更することができる。
また、情報処理装置100に関して、図示の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。
例えば、情報処理装置100が備える処理機能、特に制御部102にて行われる各処理機能については、その全部または任意の一部を、CPUおよび当該CPUにて解釈実行されるプログラムにて実現してもよく、また、ワイヤードロジックによるハードウェアとして実現してもよい。尚、プログラムは、本実施形態で説明した処理を情報処理装置に実行させるためのプログラム化された命令を含む一時的でないコンピュータ読み取り可能な記録媒体に記録されており、必要に応じて情報処理装置100に機械的に読み取られる。すなわち、ROMまたはHDD(Hard Disk Drive)などの記憶部などには、OSと協働してCPUに命令を与え、各種処理を行うためのコンピュータプログラムが記録されている。このコンピュータプログラムは、RAMにロードされることによって実行され、CPUと協働して制御部102を構成する。
また、このコンピュータプログラムは、情報処理装置100に対して任意のネットワークを介して接続されたアプリケーションプログラムサーバに記憶されていてもよく、必要に応じてその全部または一部をダウンロードすることも可能である。
また、本実施形態で説明した処理を実行するためのプログラムを、一時的でないコンピュータ読み取り可能な記録媒体に格納してもよく、また、プログラム製品として構成することもできる。ここで、この「記録媒体」とは、メモリーカード、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に代表される別個のプログラムと協働してその機能を達成するものをも含む。なお、実施形態に示した各装置において記録媒体を読み取るための具体的な構成および読み取り手順ならびに読み取り後のインストール手順等については、周知の構成や手順を用いることができる。
記憶部106に格納される各種のデータベース等は、RAM、ROM等のメモリ装置、ハードディスク等の固定ディスク装置、フレキシブルディスク、および、光ディスク等のストレージ手段であり、各種処理やウェブサイト提供に用いる各種のプログラム、テーブル、データベース、および、ウェブページ用ファイル等を格納する。
また、情報処理装置100は、既知のパーソナルコンピュータまたはワークステーション等の情報処理装置として構成してもよく、また、任意の周辺装置が接続された当該情報処理装置として構成してもよい。また、情報処理装置100は、当該情報処理装置に本実施形態で説明した処理を実現させるソフトウェア(プログラムまたはデータ等を含む)を実装することにより実現してもよい。
さらに、装置の分散・統合の具体的形態は図示するものに限られず、その全部または一部を、各種の付加等に応じてまたは機能付加に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。すなわち、上述した実施形態を任意に組み合わせて実施してもよく、実施形態を選択的に実施してもよい。
本発明は、費用の支払申請を行う全ての業種や業界において適用可能であり、特に、多店舗展開企業における店舗間の旅費に関する債務管理部署や支払部署を決定する仕組みとして有用である。
100 情報処理装置
102 制御部
102a 申請情報入力部
102b 部署抽出部
102c 出力部
102d マスタメンテ部
104 通信インターフェース部
106 記憶部
106a 社員情報マスタ
106b 用途マスタ
106c 部署別用途別支払部署マスタ
106d 申請データ
108 入出力インターフェース部
112 入力装置(キーボード)
114 出力装置(モニタ)
200 サーバ
300 ネットワーク

Claims (6)

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

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2018120709A JP7049943B2 (ja) 2018-06-26 2018-06-26 情報処理装置、情報処理方法および情報処理プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2018120709A JP7049943B2 (ja) 2018-06-26 2018-06-26 情報処理装置、情報処理方法および情報処理プログラム

Publications (2)

Publication Number Publication Date
JP2020003914A JP2020003914A (ja) 2020-01-09
JP7049943B2 true JP7049943B2 (ja) 2022-04-07

Family

ID=69099946

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2018120709A Active JP7049943B2 (ja) 2018-06-26 2018-06-26 情報処理装置、情報処理方法および情報処理プログラム

Country Status (1)

Country Link
JP (1) JP7049943B2 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003296509A (ja) 2002-03-29 2003-10-17 Fuji Electric Co Ltd 申請業務支援システム
JP2006189930A (ja) 2004-12-28 2006-07-20 Canon Marketing Japan Inc 承認業務支援システム、承認業務支援装置及び承認業務支援プログラム
JP2016146017A (ja) 2015-02-06 2016-08-12 沖電気工業株式会社 申請管理装置、申請管理システム、及びプログラム

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4292342B2 (ja) * 2003-07-14 2009-07-08 レーザーテック株式会社 電子承認システムにおける承認ルート決定方法及びプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003296509A (ja) 2002-03-29 2003-10-17 Fuji Electric Co Ltd 申請業務支援システム
JP2006189930A (ja) 2004-12-28 2006-07-20 Canon Marketing Japan Inc 承認業務支援システム、承認業務支援装置及び承認業務支援プログラム
JP2016146017A (ja) 2015-02-06 2016-08-12 沖電気工業株式会社 申請管理装置、申請管理システム、及びプログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
大企業・中堅企業向けエンタープライズワークフロー MAJOR FLOW Z,Cloud Days 2018 ,パナソニック ネットソリューションズ株式会社,2018年05月24日

Also Published As

Publication number Publication date
JP2020003914A (ja) 2020-01-09

Similar Documents

Publication Publication Date Title
CN101425165A (zh) 购买操作系统、购买操作处理方法和购买操作处理程序
JP2021180043A (ja) 電子レシートシステム、決済装置、販促レシートサーバ及び情報処理プログラム
JP2021022405A (ja) 債権債務管理装置、債権債務管理方法、および、債権債務管理プログラム
JP7079673B2 (ja) 費用負担部署設定装置、費用負担部署設定方法および費用負担部署設定プログラム
KR100803942B1 (ko) 회계처리 시스템 및 방법
JP2018041321A (ja) 為替差損益管理装置、為替差損益管理方法、および、為替差損益管理プログラム
JP2006195833A (ja) ワークフローシステム、そのプログラム
JP7049943B2 (ja) 情報処理装置、情報処理方法および情報処理プログラム
JP5862144B2 (ja) サーバ装置、およびプログラム
JP6956838B2 (ja) 本支店仕訳入力装置、本支店仕訳入力方法、及び、本支店仕訳入力プログラム
JP2022104542A (ja) 手数料処理装置、手数料処理方法、及び手数料処理プログラム
JP6608695B2 (ja) 会計帳簿管理装置、会計帳簿管理方法、及び会計帳簿管理プログラム
JP6403360B1 (ja) 財務諸表解釈支援装置、コンピュータプログラム
JP2018116504A (ja) 仕訳作成装置、仕訳作成方法および仕訳作成プログラム
JP2017182787A (ja) 与信枠管理装置、与信枠管理方法、および、与信枠管理プログラム
Hutchinson Self-Service technology and the impact on academic libraries: a perspective piece by an access services specialist
JP2021174075A (ja) 出願データと調査書データのマッチング方法
JP2020095610A (ja) 融資管理装置、融資管理方法、及び融資管理プログラム
JP2016170769A (ja) 仕訳入力補助装置、仕訳入力補助方法および仕訳入力補助プログラム
JP6889209B2 (ja) M&aプラットフォームで用いる照合プログラム
WO2022107191A1 (ja) 与信業務支援方法及び与信業務支援システム
JP6499403B2 (ja) 福利厚生促進装置、福利厚生促進方法、およびプログラム
JP2005242676A (ja) 不動産担保管理システム
JP7042064B2 (ja) 情報処理装置、方法およびプログラム
US20230267518A1 (en) Intelligently managing invoice processing using blockchain and mixed reality applications

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210513

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20220310

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20220315

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220328

R150 Certificate of patent or registration of utility model

Ref document number: 7049943

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150