特開 2017-188081 支払依頼電子承認装置、支払依頼電子承認方法、および、支払依頼電子承認プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】特開2017-188081(P2017-188081A)

(43)【公開日】2017年10月12日

(54)【発明の名称】支払依頼電子承認装置、支払依頼電子承認方法、および、支払依頼電子承認プログラム

(51)【国際特許分類】

   G06Q 10/10 20120101AFI20170919BHJP

【ＦＩ】

   G06Q10/10 310

【審査請求】未請求

【請求項の数】7

【出願形態】ＯＬ

【全頁数】18

(21)【出願番号】特願2017-20602(P2017-20602)

(22)【出願日】2017年2月7日

(31)【優先権主張番号】特願2016-68124(P2016-68124)

(32)【優先日】2016年3月30日

(33)【優先権主張国】JP

(71)【出願人】

【識別番号】398040527

【氏名又は名称】株式会社オービック

(74)【代理人】

【識別番号】110002147

【氏名又は名称】特許業務法人酒井国際特許事務所

(72)【発明者】

【氏名】和田 裕輝

(72)【発明者】

【氏名】岡田 雄

(72)【発明者】

【氏名】川越 俊哉

(72)【発明者】

【氏名】芹澤 邦明

【テーマコード（参考）】

5L049

【Ｆターム（参考）】

5L049AA07

(57)【要約】

【課題】ペーパーレス化や経理部門での支払時管理あるいは確認の省力化、および支払申請や決済の通番管理が可能になる支払依頼電子承認装置、支払依頼電子承認方法、および、支払依頼電子承認プログラムを提供することを課題とする。
【解決手段】営業部門における債務に対して適用する承認パターンを設定承認パターンとして設定し、営業部門における債務の債務支払予定入力があった場合、債務の債務支払予定入力の電子承認の有無を確認し、債務支払予定入力を受け付けるか否かを判定し、債務支払予定入力を受け付けると判定された場合、且つ、債務の営業部門から経理部門への支払依頼入力があった場合、支払依頼入力の電子承認の有無を確認し、支払依頼入力を受け付けるか否かを判定し、支払依頼入力を受け付けると判定された場合、経理部門への支払依頼票の支払依頼データを起票する。
【選択図】図１

【特許請求の範囲】

【請求項1】

記憶部と制御部とを備えた支払依頼電子承認装置であって、
前記記憶部は、
営業部門における債務支払予定入力の電子承認を要するか否かの設定、前記営業部門から経理部門への支払依頼入力の電子承認を要するか否かの設定、および、前記債務支払予定入力の電子承認を前記支払依頼入力の電子承認とみなすか否かの設定を含む複数の承認パターンを記憶するパターン記憶手段、
を備え、
前記制御部は、
前記営業部門における債務に対して適用する前記承認パターンを設定承認パターンとして設定する設定手段と、
前記営業部門における前記債務の債務支払予定入力があった場合、前記設定承認パターンに基づいて、当該債務の債務支払予定入力の電子承認の有無を確認し、当該債務支払予定入力を受け付けるか否かを判定する債務支払予定入力判定手段と、
前記債務支払予定入力判定手段により前記債務支払予定入力を受け付けると判定された場合、且つ、前記債務の前記営業部門から前記経理部門への支払依頼入力があった場合、前記設定承認パターンに基づいて、当該支払依頼入力の電子承認の有無を確認し、当該支払依頼入力を受け付けるか否かを判定する支払依頼入力判定手段と、
前記支払依頼入力判定手段により前記支払依頼入力を受け付けると判定された場合、前記経理部門への支払依頼票の支払依頼データを起票する起票手段と、
を備えたことを特徴とする支払依頼電子承認装置。

【請求項2】

前記制御部は、
所定のまとめ単位毎に複数の前記支払依頼データを抽出し、まとめて支払処理を実行する支払処理実行手段、
を更に備えたことを特徴とする請求項１に記載の支払依頼電子承認装置。

【請求項3】

前記所定のまとめ単位は、
事業所、出金支払先、支払方法、支払予定日、支払依頼番号、支払部門、通貨、部門、および／または、計上伝票番号であることを特徴とする請求項２に記載の支払依頼電子承認装置。

【請求項4】

前記制御部は、
前記債務が経費債務の場合、前記支払依頼データ毎に支払処理を実行する支払処理実行手段、
を更に備えたことを特徴とする請求項１に記載の支払依頼電子承認装置。

【請求項5】

前記債務支払予定入力は、
前記債務の前払依頼であることを特徴とする請求項１から４のいずれか一つに記載の支払依頼電子承認装置。

【請求項6】

記憶部と制御部とを備えた支払依頼電子承認装置に実行させるための支払依頼電子承認方法であって、
前記記憶部は、
営業部門における債務支払予定入力の電子承認を要するか否かの設定、前記営業部門から経理部門への支払依頼入力の電子承認を要するか否かの設定、および、前記債務支払予定入力の電子承認を前記支払依頼入力の電子承認とみなすか否かの設定を含む複数の承認パターンを記憶するパターン記憶手段、
を備え、
前記制御部で実行させる、
前記営業部門における債務に対して適用する前記承認パターンを設定承認パターンとして設定する設定ステップと、
前記営業部門における前記債務の債務支払予定入力があった場合、前記設定承認パターンに基づいて、当該債務の債務支払予定入力の電子承認の有無を確認し、当該債務支払予定入力を受け付けるか否かを判定する債務支払予定入力判定ステップと、
前記債務支払予定入力判定ステップにて前記債務支払予定入力を受け付けると判定された場合、且つ、前記債務の前記営業部門から前記経理部門への支払依頼入力があった場合、前記設定承認パターンに基づいて、当該支払依頼入力の電子承認の有無を確認し、当該支払依頼入力を受け付けるか否かを判定する支払依頼入力判定ステップと、
前記支払依頼入力判定ステップにて前記支払依頼入力を受け付けると判定された場合、前記経理部門への支払依頼票の支払依頼データを起票する起票ステップと、
を含むことを特徴とする支払依頼電子承認方法。

【請求項7】

記憶部と制御部とを備えた支払依頼電子承認装置に実行させるための支払依頼電子承認プログラムであって、
前記記憶部は、
営業部門における債務支払予定入力の電子承認を要するか否かの設定、前記営業部門から経理部門への支払依頼入力の電子承認を要するか否かの設定、および、前記債務支払予定入力の電子承認を前記支払依頼入力の電子承認とみなすか否かの設定を含む複数の承認パターンを記憶するパターン記憶手段、
を備え、
前記制御部において、
前記営業部門における債務に対して適用する前記承認パターンを設定承認パターンとして設定する設定ステップと、
前記営業部門における前記債務の債務支払予定入力があった場合、前記設定承認パターンに基づいて、当該債務の債務支払予定入力の電子承認の有無を確認し、当該債務支払予定入力を受け付けるか否かを判定する債務支払予定入力判定ステップと、
前記債務支払予定入力判定ステップにて前記債務支払予定入力を受け付けると判定された場合、且つ、前記債務の前記営業部門から前記経理部門への支払依頼入力があった場合、前記設定承認パターンに基づいて、当該支払依頼入力の電子承認の有無を確認し、当該支払依頼入力を受け付けるか否かを判定する支払依頼入力判定ステップと、
前記支払依頼入力判定ステップにて前記支払依頼入力を受け付けると判定された場合、前記経理部門への支払依頼票の支払依頼データを起票する起票ステップと、
を実行させるための支払依頼電子承認プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、支払依頼電子承認装置、支払依頼電子承認方法、および、支払依頼電子承認プログラムに関する。

【背景技術】

【0002】

特許文献１によれば、申請者、承認者はシステムへのログイン時に、ユーザＩＤ及びパスワードをクライアント・コンピュータのインターネットブラウザから入力する。サーバ・コンピュータにおいて利用者認証ファイルに登録されているか否かを判定し、登録されている場合のみログインが許可される。ログインと同時に申請者が電子伝票を起票する権限を有しているかを判定し、申請権限を有すると判定されたもののみが申請入力を可能にする。また承認者が承認を行う場合も、ログインと同時に承認権限を有しているか否かの判定を行い、有していると判定され、自身の承認すべき電子伝票がある場合のみ、承認を可能とする電子承認システムが開示されている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特開２００５−１２８９８６号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

しかしながら、特許文献１は、支払依頼に対して電子承認機能を設けたり、支払方法確定処理をいくつかのパターンに切り換えたりすることができないという課題があった。

【0005】

本発明は、上記問題点に鑑みてなされたものであって、ペーパーレス化や経理部門での支払時管理あるいは確認の省力化、および支払申請や決済の通番管理が可能になる支払依頼電子承認装置、支払依頼電子承認方法、および、支払依頼電子承認プログラムを提供することを目的とする。

【課題を解決するための手段】

【0006】

上述した課題を解決し、目的を達成するために、本発明に係る支払依頼電子承認装置は、記憶部と制御部とを備えた支払依頼電子承認装置であって、前記記憶部は、営業部門における債務支払予定入力の電子承認を要するか否かの設定、前記営業部門から経理部門への支払依頼入力の電子承認を要するか否かの設定、および、前記債務支払予定入力の電子承認を前記支払依頼入力の電子承認とみなすか否かの設定を含む複数の承認パターンを記憶するパターン記憶手段、を備え、前記制御部は、前記営業部門における債務に対して適用する前記承認パターンを設定承認パターンとして設定する設定手段と、前記営業部門における前記債務の債務支払予定入力があった場合、前記設定承認パターンに基づいて、当該債務の債務支払予定入力の電子承認の有無を確認し、当該債務支払予定入力を受け付けるか否かを判定する債務支払予定入力判定手段と、前記債務支払予定入力判定手段により前記債務支払予定入力を受け付けると判定された場合、且つ、前記債務の前記営業部門から前記経理部門への支払依頼入力があった場合、前記設定承認パターンに基づいて、当該支払依頼入力の電子承認の有無を確認し、当該支払依頼入力を受け付けるか否かを判定する支払依頼入力判定手段と、前記支払依頼入力判定手段により前記支払依頼入力を受け付けると判定された場合、前記経理部門への支払依頼票の支払依頼データを起票する起票手段と、を備えたことを特徴とする。

【0007】

また、本発明に係る支払依頼電子承認装置は、前記制御部は、所定のまとめ単位毎に複数の前記支払依頼データを抽出し、まとめて支払処理を実行する支払処理実行手段、を更に備えたことを特徴とする。

【0008】

また、本発明に係る支払依頼電子承認装置は、前記所定のまとめ単位は、事業所、出金支払先、支払方法、支払予定日、支払依頼番号、支払部門、通貨、部門、および／または、計上伝票番号であることを特徴とする。

【0009】

また、本発明に係る支払依頼電子承認装置は、前記制御部は、前記債務が経費債務の場合、前記支払依頼データ毎に支払処理を実行する支払処理実行手段、を更に備えたことを特徴とする。

【0010】

また、本発明に係る支払依頼電子承認装置は、前記債務支払予定入力は、前記債務の前払依頼であることを特徴とする。

【0011】

また、本発明に係る支払依頼電子承認方法は、記憶部と制御部とを備えた支払依頼電子承認装置に実行させるための支払依頼電子承認方法であって、前記記憶部は、営業部門における債務支払予定入力の電子承認を要するか否かの設定、前記営業部門から経理部門への支払依頼入力の電子承認を要するか否かの設定、および、前記債務支払予定入力の電子承認を前記支払依頼入力の電子承認とみなすか否かの設定を含む複数の承認パターンを記憶するパターン記憶手段、を備え、前記制御部で実行させる、前記営業部門における債務に対して適用する前記承認パターンを設定承認パターンとして設定する設定ステップと、前記営業部門における前記債務の債務支払予定入力があった場合、前記設定承認パターンに基づいて、当該債務の債務支払予定入力の電子承認の有無を確認し、当該債務支払予定入力を受け付けるか否かを判定する債務支払予定入力判定ステップと、前記債務支払予定入力判定ステップにて前記債務支払予定入力を受け付けると判定された場合、且つ、前記債務の前記営業部門から前記経理部門への支払依頼入力があった場合、前記設定承認パターンに基づいて、当該支払依頼入力の電子承認の有無を確認し、当該支払依頼入力を受け付けるか否かを判定する支払依頼入力判定ステップと、前記支払依頼入力判定ステップにて前記支払依頼入力を受け付けると判定された場合、前記経理部門への支払依頼票の支払依頼データを起票する起票ステップと、を含むことを特徴とする。

【0012】

また、本発明に係る支払依頼電子承認プログラムは、記憶部と制御部とを備えた支払依頼電子承認装置に実行させるための支払依頼電子承認プログラムであって、前記記憶部は、営業部門における債務支払予定入力の電子承認を要するか否かの設定、前記営業部門から経理部門への支払依頼入力の電子承認を要するか否かの設定、および、前記債務支払予定入力の電子承認を前記支払依頼入力の電子承認とみなすか否かの設定を含む複数の承認パターンを記憶するパターン記憶手段、を備え、前記制御部において、前記営業部門における債務に対して適用する前記承認パターンを設定承認パターンとして設定する設定ステップと、前記営業部門における前記債務の債務支払予定入力があった場合、前記設定承認パターンに基づいて、当該債務の債務支払予定入力の電子承認の有無を確認し、当該債務支払予定入力を受け付けるか否かを判定する債務支払予定入力判定ステップと、前記債務支払予定入力判定ステップにて前記債務支払予定入力を受け付けると判定された場合、且つ、前記債務の前記営業部門から前記経理部門への支払依頼入力があった場合、前記設定承認パターンに基づいて、当該支払依頼入力の電子承認の有無を確認し、当該支払依頼入力を受け付けるか否かを判定する支払依頼入力判定ステップと、前記支払依頼入力判定ステップにて前記支払依頼入力を受け付けると判定された場合、前記経理部門への支払依頼票の支払依頼データを起票する起票ステップと、を実行させることを特徴とする。

【発明の効果】

【0013】

本発明によれば、ペーパーレス化や経理部門での支払時管理あるいは確認の省力化、および支払申請や決済の通番管理が可能になるという効果を奏する。

【図面の簡単な説明】

【0014】

【図1】図１は、支払依頼電子承認装置の構成の一例を示すブロック図である。

【図2】図２は、本実施形態における支払依頼電子承認装置の処理の一例を示すフローチャートである。

【図3】図３は、支払依頼電子承認装置を含むシステムの全体構成の一例を示す図である。

【図4】図４は、本実施形態におけるパターンテーブルの一例を示す図である。

【図5】図５は、支払依頼入力画面の一例を示す図である。

【図6】図６は、支払依頼明細入力画面の一例を示す図である。

【図7】図７は、振込情報画面の一例を示す図である。

【図8】図８は、伝票内訳画面の一例を示す図である。

【図9】図９は、支払依頼入力の転送表の一例を示す図である。

【図10】図１０は、支払方法確定処理画面の一例とその画面項目一覧を示す図である。

【図11】図１１は、支払方法確定処理のまとめ単位切替と事業所部門別債務残高管理の一例を示す図である。

【図12】図１２は、支払方法確定処理のまとめ単位切替と事業所部門別債務残高管理の一例を示す図である。

【発明を実施するための形態】

【0015】

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

【0016】

［１．概要］
まず、従来から、債務の計上内容（勘定科目等）のチェックのための電子承認機能は存在していたが、商品仕入・経費支払それぞれの業務特性に対応した支払依頼業務の電子承認はできなかった。

【0017】

そこで、本実施形態においては、営業部門から経理部門への支払依頼の電子承認を汎用的に制御することを可能としている。具体的に、本実施形態においては、他の業務と共通の電子承認機能により、承認有無・承認ルートを事前に設定してもよい。また、本実施形態においては、１支払先に対する複数債務をまとめて支払うケースが予想される商品仕入・諸掛等の債務について、債務計上後、支払依頼入力（債務まとめ処理）にて電子承認を起票してもよい。ここで、商品仕入においては、債務まとめ処理を経て電子承認としてもよい。また、本実施形態においては、都度の債務発生ごとに支払依頼するケースが予想される経費債務について、債務計上と合わせて支払依頼扱いとし、電子承認を起票してもよい。また、本実施形態においては、任意の承認ルートを通った後、経理部門にて承認を行ってもよい。これにより、本実施形態においては、ペーパーレス化、経理部門での支払時管理・確認の省力化、および、支払申請・決済の通番管理を可能としている。

【0018】

［２．構成］
本実施形態に係る支払依頼電子承認装置の構成の一例について、図１を参照して説明する。図１は、支払依頼電子承認装置の構成の一例を示すブロック図である。

【0019】

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

【0020】

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

【0021】

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

【0022】

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

【0023】

パターンテーブル１０６ａは、営業部門における債務支払予定入力の電子承認を要するか否かの設定、営業部門から経理部門への支払依頼入力の電子承認を要するか否かの設定、および、債務支払予定入力の電子承認を支払依頼入力の電子承認とみなすか否かの設定を含む複数の承認パターンを記憶する。

【0024】

債務データファイル１０６ｂは、債務の債務データを記憶する。ここで、債務は、営業部門における債務であってもよい。また、債務データは、債務支払予定を含んでいてもよい。また、債務は、経費、品代、および／または、諸掛等であってもよい。

【0025】

支払依頼ファイル１０６ｃは、支払依頼表の支払依頼表データを記憶する。ここで、支払依頼表データは、電子承認が付されていてもよい。また、支払依頼表は、（会社内の営業部門等から）経理部門への支払依頼表であってもよい。

【0026】

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

【0027】

制御部１０２は、支払依頼電子承認装置１００を統括的に制御するＣＰＵ等である。制御部１０２は、ＯＳ等の制御プログラム・各種の処理手順等を規定したプログラム・所要データなどを格納するための内部メモリを有し、格納されているこれらのプログラムに基づいて種々の情報処理を実行する。制御部１０２は、機能概念的に、設定部１０２ａと、債務支払予定入力判定部１０２ｂと、支払依頼入力判定部１０２ｃと、起票部１０２ｄと、支払処理実行部１０２ｅとを備えている。

【0028】

設定部１０２ａは、営業部門における債務に対して適用する承認パターンを設定承認パターンとして設定する。ここで、設定部１０２ａは、パターンテーブル１０６ａに記憶された承認パターンを用いて、営業部門における債務に対して適用する承認パターンを設定承認パターンとして設定してもよい。

【0029】

債務支払予定入力判定部１０２ｂは、営業部門における債務の債務支払予定入力があった場合、設定承認パターンに基づいて、当該債務の債務支払予定入力の電子承認の有無を確認し、当該債務支払予定入力を受け付けるか否かを判定する。ここで、債務支払予定入力判定部１０２ｂは、営業部門における債務の債務データを債務データファイル１０６ｂに格納（登録）してもよい。また、債務支払予定入力は、債務の前払依頼であってもよい。

【0030】

支払依頼入力判定部１０２ｃは、債務支払予定入力判定部１０２ｂにより債務支払予定入力を受け付けると判定された場合、且つ、債務の営業部門から経理部門への支払依頼入力があった場合、設定承認パターンに基づいて、当該支払依頼入力の電子承認の有無を確認し、当該支払依頼入力を受け付けるか否かを判定する。

【0031】

起票部１０２ｄは、支払依頼入力判定部１０２ｃにより支払依頼入力を受け付けると判定された場合、経理部門への支払依頼票の支払依頼データを起票する。ここで、起票部１０２ｄは、支払依頼データを支払依頼ファイル１０６ｃに格納（登録）してもよい。

【0032】

支払処理実行部１０２ｅは、支払依頼データの支払処理を実行する。ここで、支払処理実行部１０２ｅは、所定のまとめ単位毎に複数の前記支払依頼データを抽出し、まとめて支払処理を実行してもよい。ここで、所定のまとめ単位は、事業所、出金支払先、支払方法、支払予定日、支払依頼番号、支払部門、通貨、部門、および／または、計上伝票番号であってもよい。また、支払処理実行部１０２ｅは、債務が経費債務の場合、支払依頼データ毎に支払処理を実行してもよい。

【0033】

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

【0034】

［支払依頼電子承認処理］
ここで、図２を参照して、本実施形態における支払依頼電子承認処理の一例について説明する。図２は、本実施形態における支払依頼電子承認装置１００の処理の一例を示すフローチャートである。

【0035】

図２に示すように、設定部１０２ａは、パターンテーブル１０６ａに記憶された承認パターンを用いて、会社の営業部門における債務に対して適用する承認パターンを設定承認パターンとして設定する（ステップＳＡ−１）。

【0036】

そして、債務支払予定入力判定部１０２ｂは、ユーザにより入力装置１１２を介して営業部門における債務の債務支払予定入力があった場合、設定承認パターンに基づいて、当該債務の債務支払予定入力の電子承認の有無を確認し、当該債務支払予定入力を受け付けるか否かを判定する（ステップＳＡ−２）。

【0037】

そして、債務支払予定入力判定部１０２ｂは、債務支払予定入力を受け付けないと判定した場合（ステップＳＡ−２：Ｎｏ）、処理を終了する。

【0038】

一方、債務支払予定入力判定部１０２ｂは、債務支払予定入力を受け付けると判定した場合（ステップＳＡ−２：Ｙｅｓ）、営業部門における債務の債務データを債務データファイル１０６ｂに登録し、処理をステップＳＡ−３に移行させる。

【0039】

そして、支払依頼入力判定部１０２ｃは、ユーザにより入力装置１１２を介して債務の営業部門から経理部門への支払依頼入力があった場合、設定承認パターンに基づいて、当該支払依頼入力の電子承認の有無を確認し、当該支払依頼入力を受け付けるか否かを判定する（ステップＳＡ−３）。

【0040】

そして、支払依頼入力判定部１０２ｃは、支払依頼入力を受け付けないと判定した場合（ステップＳＡ−３：Ｎｏ）、処理を終了する。

【0041】

一方、支払依頼入力判定部１０２ｃは、支払依頼入力を受け付けると判定した場合（ステップＳＡ−３：Ｙｅｓ）、処理をステップＳＡ−４に移行させる。

【0042】

そして、起票部１０２ｄは、営業部門から経理部門への支払依頼票の支払依頼データを起票し、支払依頼データを支払依頼ファイル１０６ｃに登録する（ステップＳＡ−４）。ここで、支払依頼入力の電子承認が付与されて最終承認された支払依頼データは、支払依頼ファイル１０６ｃから削除禁止としてもよい。

【0043】

そして、支払処理実行部１０２ｅは、起票部１０２ｄにより起票された支払依頼票の債務が経費債務であるか否かを判定する（ステップＳＡ−５）。

【0044】

そして、支払処理実行部１０２ｅは、支払依頼票の債務が経費債務ではないと判定した場合（ステップＳＡ−５：Ｎｏ）、処理をステップＳＡ−６に移行させる。

【0045】

そして、支払処理実行部１０２ｅは、所定のまとめ単位毎に、支払依頼ファイル１０６ｃに記憶された複数の前記支払依頼データを抽出し、まとめて支払処理を実行し（ステップＳＡ−６）、処理を終了する。

【0046】

一方、支払処理実行部１０２ｅは、支払依頼票の債務が経費債務であると判定した場合（ステップＳＡ−５：Ｙｅｓ）、処理をステップＳＡ−７に移行させる。

【0047】

そして、支払処理実行部１０２ｅは、支払依頼ファイル１０６ｃに記憶された支払依頼データ毎に支払処理を実行し（ステップＳＡ−７）、処理を終了する。

【0048】

ここで、図３を参照して、本実施形態に係る支払依頼電子承認装置１００の処理内容を説明する。図３は、支払依頼電子承認装置１００を含むシステムの全体構成の一例を示す図である。

【0049】

本実施形態においては、図３に示すように、営業部門の担当範囲として、図の左端の仕入取込処理、仕入入力、仕入諸掛入力、輸出諸掛入力、経費支払予定入力、経費支払予定取込処理、旅費経費・業者払い申請など諸々の債務発生項目から債務が発生すると、これらに対して支払依頼をかけてもよい。

【0050】

ここで、支払依頼の流れは、今回はこれだけのものを支払って下さいというまとめ処理を行い、それをまとめたものが支払依頼票であり、これを回覧書類として回すことになる。支払依頼票を紙で回覧すると、図３に示す経理部門では、社員数が多く、日に何通も支払依頼票を出す場合は、非常に多くの紙が必要になる上、押印やストックするスペースを考えると、非常に効率が悪かった。

【0051】

そこで、本実施形態においては、図３に示すように、支払依頼票の標準機能である紙承認に対して、電子承認機能を設けるようにしてもよい。また、本実施形態においては、図３に示すように、支払方法確定処理機能を追加してもよい。すなわち、本実施形態においては、最終の決済を月末一括で行うのか、それとも後で電子承認をした各管理番号を抽出して支払に回すのかという、決済時における経理部門側の業務処理にまとめ単位というものがあって、このまとめ単位による支払方法確定も「現状」と「追加」との切り替えができるようにしてもよい。

【0052】

ここで、電子承認機能自体は、一般的な各債務の計上毎の伝票内容が正しいか否かを確認し（会計帳簿にその伝票内容を記帳して良いかを上長が確認し）、電子承認するものについては既に存在する（例えば、図３の営業部門における経費支払・業者払い自体の承認と、支払依頼の承認など）。しかしながら、本実施形態における電子承認機能は、これとは異なり、支払依頼の入力に対する電子承認機能であって、これまでにない機能である。すなわち、本実施形態においては、債務が計上されたものを決済に回すところに電子承認を組み合わせることで、個別の決済処理をサポートすることができる。

【0053】

また、この支払依頼の電子承認というのは、支払依頼自体が債務の各計上データが種々あって、例えば、「仕入」または「諸掛」については、日々発生するとまず計上し、その後日を改めて支払依頼をするという２ステップ処理を行うことが多いが、「経費」などは即日計上して見返すことなく電子承認に回す１ステップ処理で行うなど、計上データ（業務）の種類に応じてステップの切り替えを行う必要があるという特殊性がある。例えば、「経費」の支払依頼データ作成のチェックＯＮの場合は、支払依頼の承認が終わったら、支払依頼の承認も完了とすることで、１ステップ処理扱いになる。

【0054】

ここで、図４を参照して、本実施形態におけるパターンテーブル１０６ａの一例について説明する。図４は、本実施形態におけるパターンテーブル１０６ａの一例を示す図である。

【0055】

図４に示すように、本実施形態におけるパターンテーブル１０６ａは、チェックＯＮとチェックＯＦＦとの設定に応じて、１ステップ処理か２ステップ処理かをパターン分けした承認パターンを記憶していてもよい。本実施形態において、この経費支払予定入力で経費計上してそれを支払依頼する場合は、図４のパターンを用いて処理してもよい。また、図４のパターンテーブル１０６ａでは、３つの条件（チェックＯＮ／ＯＦＦ、経費支払予定入力承認設定、および、支払依頼入力承認設定）の組み合わせにより、８つのパターンに分けられ、条件にあった動作が行われるように設定されている。

【0056】

図３に戻り、本実施形態においては、支払方法確定処理の後の、支払通知・金種別支払予定では、例えば、実際の業務であれば、「経費」または「単純な債務」だけでなく、「前払い」についても、支払依頼の電子承認の対象としてもよい。このため、本実施形態においては、実際の物の代金ではなくて、先にいくら前払いをして欲しいという承認が行われた後に管理番号が付いて、その後、前払い決済され、その後、銀行に振り込まれる、または、決済（為替）レートの確定がされてもよい。それにより、本実施形態においては、この後で、前払いしたものを依頼番号でもって払っておいたけれども、後でそれを呼び出して、物の代金に当てるという流れ（すなわち、前払い）のケースに対応可能である。このように、本実施形態において、管理番号で管理をするのは、まとめ単位における支払依頼番号で管理するのと同様である。すなわち、本実施形態においては、前払いしておいたものを、このタイミングで承認されたということができるようにしてもよい。

【0057】

また、図５から図９を参照して、本実施形態における支払依頼入力の一例について説明する。図５は、支払依頼入力画面の一例を示す図である。図６は、支払依頼明細入力画面の一例を示す図である。図７は、振込情報画面の一例を示す図である。図８は、伝票内訳画面の一例を示す図である。図９は、支払依頼入力の転送表の一例を示す図である。

【0058】

図５に示すように、本実施形態における支払依頼入力画面においては、都度支払先の承認済み仕入データに対して、支払対象とする為の支払依頼データを作成し、支払依頼番号を採番することができる。また、本実施形態における支払依頼入力画面においては、複数の仕入伝票に対して支払依頼をまとめる事ができる。また、本実施形態における支払依頼入力画面においては、支払先マスタの設定（支払予定日算出区分）により、支払依頼を使用しつつ、締支払の設定値で支払予定日の算出を行うことができる。また、本実施形態における支払依頼入力画面においては、支払依頼単位で金種別支払予定金額を算出してもよい。また、本実施形態における支払依頼入力画面においては、支払依頼の単位で源泉税預り金を再計算してもよい。また、本実施形態における支払依頼入力画面においては、「合計額入力区分」がある場合、支払先からの請求書に記載された金額を入力して自動充当してもよい。また、本実施形態における支払依頼入力画面においては、「合計額入力区分」がない場合、自社の支払予定を任意に指定し、積み上げで支払依頼額を決定してもよい。

【0059】

また、図６に示すように、本実施形態における支払依頼明細入力画面においては、明細項目として、データ区分、コード、名称、伝票番号、仕入先、伝票日付、支払予定日、納品書番号、伝票金額、支払済額、支払予定額、および、今回依頼額等を含んでいてもよい。また、図７に示すように、本実施形態における振込情報画面においては、通常支払先の場合、表示のみ実行し、諸口支払先の場合、ユーザに入力装置１１２を介して入力可能としてもよい。また、図８に示すように、本実施形態における伝票内訳画面において、「今回支払依頼額」には、明細情報に表示されている金額の合計でなく、明細ごとの依頼額の合計が表示されてもよい。これにより、本実施形態における伝票内訳画面においては、明細内で一部依頼時に明細の金額合計と不一致になるが、明細単位の依頼時は常に一致する。

【0060】

また、図９の支払依頼入力の転送表に示すように、画面遷移が制御されてもよい。ここで、本実施形態においては、伝票単位の場合、明細選択表示画面の表示のみ行ってもよい。また、本実施形態の支払依頼画面においては、各支払依頼明細がダブルクリックされ、明細が入力された場合、支払依頼明細入力画面を表示してもよい。また、本実施形態の支払依頼画面においては、詳細ボタンが選択された場合、明細選択表示画面を表示してもよい。また、本実施形態においては、通常、支払依頼画面（明細）に入力された金額を、明細選択表示画面に自動セットしてもよい。また、本実施形態においては、前払の場合、明細選択表示画面に紐づく明細のみ表示してもよい。

【0061】

また、図１０から図１２を参照して、本実施形態における支払方法確定処理の一例について説明する。図１０は、支払方法確定処理画面の処理詳細の一例を示す図である。図１１および図１２は、支払方法確定処理のまとめ単位切替と事業所部門別債務残高管理の一例を示す図である。

【0062】

図１０に示すように、本実施形態における支払方法確定処理画面（条件指定画面）においては、支払予定データを支払予定日または出金支払先で集計して支払通知ファイルを作成できる。また、本実施形態における支払方法確定処理画面においては、対象となる支払予定を再集計して金種別支払予定を作成できる。また、本実施形態における支払方法確定処理画面においては、消費税算出区分＝締時一括の支払先に関して、税率別消費税差額を算出することができる。また、本実施形態における本支払方法確定処理は、金種別支払予定が支払済になるまでの間、解除、および／または、再実行可能であってもよい。

【0063】

また、図１１には、支払先マスタに設定した支払予定日をまとめ単位とする支払方法確定処理、および、事業所部門別債務残高管理処理について示している。一方、図１２には、支払先マスタに設定した支払依頼番号をまとめ単位とする支払方法確定処理、および、事業所部門別債務残高管理処理について示している。そして、本実施形態においては、このような支払方法確定処理のまとめ単位切替を行うことで、支払先および支払区分の支払通知および支払単位を変更することができる。

【0064】

なお、本実施形態において、支払まとめ単位を「出金支払先単位」と「支払依頼番号単位」とで切り替えた際に、Ｍ支払先の支払区分が１（都度支払）だった場合のＦ支払通知、および、Ｄ支払の作成単位が変わる。また、本実施形態においては、支払方法変更入力がされた場合、Ｆ支払通知が再作成されてもよい。また、本実施形態においては、Ｆ支払通知、Ｆ金種別支払予定、Ｄ支払ヘッダ、Ｄ支払明細、および、Ｄ支払消込ヘッダには、支払依頼番号を保持していなくてもよい。また、本実施形態においては、Ｄ支払予定には、支払依頼番号および支払通知番号を保持していてもよい。Ｄ支払消込明細に、支払依頼番号を保持していてもよい。また、本実施形態においては、Ｆ支払通知に保持された支払依頼番号を取得してもよく、必要な場合にＤ支払予定経由で支払依頼番号を取得してもよい。

【0065】

このように、本実施形態においては、営業部門から経理部門への支払依頼の電子承認を制御可能とすることによって、支払依頼票のペーパーレス化や経理部門での支払時における管理や確認の省力化を図ることができると共に、支払申請や決済の通番管理が可能となる。

【0066】

なお、一般的に、貿易取引においては、支払先に対して品代および／または諸掛ともに、個別請求書により請求されるケースが多く、外貨決済の場合、請求ごとに決済レートが異なるため、特に、前払いの場合、先方請求単位（＝支払依頼単位）で決済データを管理する必要があるため、多数の伝票について経理部門がまとめて内容確認を行うことが難しく、電子承認により個別確認を行う必要がある。また、一般的に、輸入取引においては、輸入ユーザンス（本邦ローン）が発生する場合、国内の取引銀行に荷為替手形を差し入れて支払猶予を受け、輸入先に対する買掛債務が取引銀行に対する未払債務に振り替えられる。

【0067】

そこで、本実施形態においては、支払依頼の電子承認を可能としている。すなわち、本実施形態においては、支払依頼ファイルに案件Ｇｕｉｄ、および、承認状態区分を設け、新規申請種別にてＦｘ標準の電子承認可能とし、承認証憑は、支払依頼票とし、締支払の際の支払締日更新処理によって登録される支払依頼は、電子承認対象外としている。また、本実施形態においては、経費支払予定入力で経費計上してそれを支払依頼する場合、予め設定された承認パターンに基づいて、支払依頼を処理してもよい。

【0068】

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

【0069】

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

【0070】

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

【0071】

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

【0072】

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

【0073】

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

【0074】

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

【0075】

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

【0076】

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

【0077】

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

【0078】

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

【産業上の利用可能性】

【0079】

本発明は、特に、海外からの輸入業務の取引割合の多い企業などにおいて有用である。

【符号の説明】

【0080】

１００ 支払依頼電子承認装置
１０２ 制御部
１０２ａ 設定部
１０２ｂ 債務支払予定入力判定部
１０２ｃ 支払依頼入力判定部
１０２ｄ 起票部
１０２ｅ 支払処理実行部
１０４ 通信インターフェース部
１０６ 記憶部
１０６ａ パターンテーブル
１０６ｂ 債務データファイル
１０６ｃ 支払依頼ファイル
１０８ 入出力インターフェース部
１１２ 入力装置
１１４ 出力装置
２００ サーバ
３００ ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】