(57)【要約】      （修正有）【課題】債権月次締処理後も特定期間において締済月に対する入金業務を可能とし、締済期間の債権関連の残高を取引に合わせた更新を可能とする債権管理システムを提供する。【解決手段】入金伝票の日付と金額と請求先が入力されるクライアント１０４と、会計締区分の情報と債権締区分の情報とを年月毎に記憶する締制御テーブルと、年月毎に入金業務可能日を記憶する入金業務カレンダーテーブルとを有するデータベースサーバ１０３と、クライアント１０４から入力された入金伝票の日付を受信し、データベースサーバ１０３へ指示し、入力された入金伝票の日付が債権締区分の情報として締状態を示して会計締区分の情報として未締状態を示すことを判定し、入力された入金伝票の日付が入金業務可能日であることを判定し、入力された入金伝票の金額で残高更新処理を実行するアプリケーションサーバ１０２を有する。【選択図】図１
2016151943.tif 000002
【特許請求の範囲】
【請求項１】
入金伝票の日付と金額と請求先が入力される債権管理システムにおいて、
前記入金伝票の日付と金額と請求先が入力されるクライアントと、
会計締区分の情報と債権締区分の情報とを年月毎に記憶する締制御テーブルと、年月毎に入金業務可能日を記憶する入金業務カレンダーテーブルとを有するデータベースサーバと、
前記クライアントから前記入力された入金伝票の日付を受信し、前記データベースサーバへ指示し、前記入力された入金伝票の日付が前記債権締区分の情報として締状態を示して前記会計締区分の情報として未締状態を示すことを判定し、前記入力された入金伝票の日付が前記入金業務可能日であることを判定し、前記入力された入金伝票の金額で残高更新処理を実行するアプリケーションサーバと
を有することを特徴とする債権管理システム。
【請求項２】
前記アプリケーションサーバは、
前記入力された入金伝票の日付が前記債権締区分の情報として締状態を示して前記会計締区分の情報として未締状態を示すことを判定し、前記入力された入金伝票の日付が前記入金業務可能日であることを判定した後、
更に、前記残高更新処理の実行の確認画面の表示を前記クライアントへ指示し、前記クライアントでの入力に基づき、前記残高更新処理を実行すること
を特徴とする請求項１に記載の債権管理システム。
【請求項３】
前記データベースサーバは、
前月末残高と当月入金決済額と当月末残高とを請求先毎に記憶する当月債権残高テーブルを更に有し、
前記アプリケーションサーバは、
前記残高更新処理として、前記データベースサーバへ指示し、
更に、前記入力された入金伝票の日付が前記債権締区分の情報として未締状態を示すことを判定し、前記入力された入金伝票の金額で前記入力された入金伝票の請求先に対する前記当月入金決済額と前記当月末残高を更新すること
を特徴とする請求項２に記載の債権管理システム。
【請求項４】
前記データベースサーバは、
当月入金決済額と当月末残高とを、年月と請求先毎に、記憶する過去月債権残高テーブルを更に有し、
前記アプリケーションサーバは、
前記残高更新処理として、前記データベースサーバへ指示し、
更に、前記入力された入金伝票の日付が前記債権締区分の情報として締状態を示すことを判定し、前記締制御テーブルの中で前記債権締区分の情報として締状態を示す最後の年月を特定し、前記入力された入金伝票の金額で、前記特定した年月と前記入力された入金伝票の請求先に対する前記当月入金決済額と前記当月末残高とを更新し、前記入力された入金伝票の金額で前記入力された入金伝票の請求先に対する前記前月末残高と前記当月末残高を更新すること
を特徴とする請求項３に記載の債権管理システム。
【請求項５】
前記データベースサーバは、
前月末残高と今回入金決済金額と請求残高とを請求先毎に記憶する請求残高テーブルを更に有し、
前記アプリケーションサーバは、
前記残高更新処理として、前記データベースサーバへ指示し、
更に、前記入力された入金伝票の金額で、前記入力された入金伝票の請求先に対する前記前月末残高と前記今回入金決済金額と前記請求残高を更新すること
を特徴とする請求項４に記載の債権管理システム。
【請求項６】
入金伝票の日付と金額と請求先が入力され、会計締区分の情報と債権締区分の情報とを年月毎に記憶する締制御テーブルと、年月毎に入金業務可能日を記憶する入金業務カレンダーテーブルとを有する債権管理システムの制御方法にであって、
前記入金伝票の日付と金額と請求先が入力され、
前記入力された入金伝票の日付が前記債権締区分の情報として締状態を示して前記会計締区分の情報として未締状態を示すことを判定し、
前記入力された入金伝票の日付が前記入金業務可能日であることを判定し、
前記入力された入金伝票の金額で残高更新処理すること
を特徴とする債権管理システムの制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、債権管理システム及びその制御方法に関するものである。
【背景技術】
【０００２】
請求先の売上情報に紐付く入金予定情報と決済先に対する入金情報、及び決済先と請求先の紐付け情報のマスタを参照することで、請求先の債権消込処理をすることが可能となる。また、月次で債権の締処理を実施し、締済期間に対する請求先への売上計上、債権消込の取引を禁止することで請求先に対する月次債権残高の情報を確定する事ができる。入金業務担当者は月次の締処理までに入金業務を完了させ、請求先の月次債権残高を適切に管理する必要があった。
【０００３】
決済先単位で入金業務を可能とする技術として、例えば特許文献１には、請求先と異なる決済先との対応マスタに登録することを可能とし、請求先と決済先が関連付けられたマスタデータより決済先単位の入金業務を可能とする装置を提供する技術が開示されている。
【０００４】
また、未決済の債権情報を自動消込する技術として、特許文献２には、債権消込対象となる入金金額と請求金額を演算手段により突合し、両金額が一致した場合、またはその金額の差が予め設定された誤差範囲内であれば自動で消込処理がなされる技術が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１２−２３０４４３号公報
【特許文献２】特開２００４−１８５５８８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
債権管理システムでは請求先の債権計上、請求、入金業務を実施し、請求先の債権情報を管理する。債権計上は各営業担当者、請求、入金業務は入金業務担当者というように各業務は別々の担当者により実施される。また、当月取引を凍結するために債権月次締処理を実施し、月次で債権残高を確定させる。そのため、入金業務担当者は取引が凍結となる債権月次締処理までに当月分の入金業務を完了させる必要がある。
【０００７】
一方で、不特定多数のユーザが債権管理業務を実施するので、運用にて各ユーザの取引入力を制御することは困難である。そのため、各ユーザの当月取引入力完了状況に関わらず特定のタイミングで強制的に債権月次締処理を実施する必要がある。
【０００８】
しかしながら、月末入金の請求先が多いこともあり、入金業務が債権月次締処理までに完了しないという課題が発生していた。また、債権月次締処理後は取引の凍結がされており取引の修正が不可となっているため、入金業務のミスオペレーションが発覚した場合には翌月取引での訂正により対応を行うが、このような対応を行った場合、債権システムのデータと実際の取引の状態が乖離してしまうという課題も発生していた。
【０００９】
そこで、本発明は、債権月次締処理後も特定期間において締済月に対する入金業務を可能とし、また締済期間の債権関連の残高を取引に合わせて更新することを目的とする。
【課題を解決するための手段】
【００１０】
本発明に係る代表的な債権管理システムは、入金伝票の日付と金額と請求先が入力される債権管理システムであって、前記入金伝票の日付と金額と請求先が入力されるクライアントと、会計締区分の情報と債権締区分の情報とを年月毎に記憶する締制御テーブルと、年月毎に入金業務可能日を記憶する入金業務カレンダーテーブルとを有するデータベースサーバと、前記クライアントから前記入力された入金伝票の日付を受信し、前記データベースサーバへ指示し、前記入力された入金伝票の日付が前記債権締区分の情報として締状態を示して前記会計締区分の情報として未締状態を示すことを判定し、前記入力された入金伝票の日付が前記入金業務可能日であることを判定し、前記入力された入金伝票の金額で残高更新処理を実行するアプリケーションサーバとを有することを特徴とする。
【発明の効果】
【００１１】
本発明によれば、債権月次締処理後も特定期間において締済月に対する入金業務が可能となり、また締済期間の債権関連の残高を取引に合わせた更新が可能となる。
【図面の簡単な説明】
【００１２】
【図１】債権管理システムの構成の例を示す図である。
【図２】ＷＥＢ兼ＡＰサーバの構成の例を示す図である。
【図３】ＤＢサーバの構成の例を示す図である。
【図４】請求先マスタのデータ構成の例を示す図である。
【図５】締制御テーブルのデータ構成の例を示す図である。
【図６】取引先締制御テーブルのデータ構成の例を示す図である。
【図７】取引先締制御情報テーブルのデータ構成の例を示す図である。
【図８】入金テーブルのデータ構成の例を示す図である。
【図９】売上テーブルのデータ構成の例を示す図である。
【図１０】入金予定テーブルのデータ構成の例を示す図である。
【図１１】当月債権残高テーブルのデータ構成の例を示す図である。
【図１２】過去月債権残高テーブルのデータ構成の例を示す図である。
【図１３】請求残高テーブルのデータ構成の例を示す図である。
【図１４】債権消込テーブルのデータ構成の例を示す図である。
【図１５】入金業務カレンダーテーブルのデータ構成の例を示す図である。
【図１６】クライアントで表示される債権消込処理確認画面の例を示す図である。
【図１７】債権消込入力処理のフローチャートの例を示す図である。
【図１８】債権月次締済月情報内部テーブルのデータ構成の例を示す図である。
【図１９】債権月次未締月情報内部テーブルのデータ構成の例を示す図である。
【図２０】取引入力可能期間判定処理のフローチャートの例を示す図である。
【図２１】前月債権残高情報内部テーブルのデータ構成の例を示す図である。
【図２２】当月債権残高情報内部テーブルのデータ構成の例を示す図である。
【図２３】請求残高情報内部テーブルのデータ構成の例を示す図である。
【図２４】残高更新処理のフローチャートの例を示す図である。
【図２５】残高更新処理によるテーブルの更新の例を示す図である。
【図２６】残高更新処理によるテーブルの更新の例を示す図である。
【図２７】残高更新処理によるテーブルの更新の例を示す図である。
【発明を実施するための形態】
【００１３】
以下、本発明の実施形態について、図面を参照して詳細に説明する。
【００１４】
図１は、債権管理システムの構成の例を示す図である。債権管理システム１００は、ネットワークで複数のコンピュータが接続されたウェブ型のコンピュータシステムであり、ウェブ兼アプリケーション（ＷＥＢ兼ＡＰ）サーバ１０２と、データベース（ＤＢ）サーバ１０３と、複数のクライアント（端末）１０４がネットワーク１０１に接続されて構成されるシステムである。
【００１５】
ＷＥＢ兼ＡＰサーバ１０２は、後で説明する処理を実行するサーバであり、クライアント１０４へウェブを提供することにより、クライアント１０４で入力された情報を受け付けて処理に使用し、処理の結果等をクライアント１０４で表示することが可能である。ＤＢサーバ１０３は、後で説明する情報を例えばリレーショナルデータベース（ＲＤＢ）で管理するサーバである。ＷＥＢ兼ＡＰサーバ１０２からの例えばＳＱＬによる検索指示や更新指示に基づき動作する。尚、図１に示した例では、ＷＥＢ兼ＡＰサーバ１０２とＤＢサーバ１０３はそれぞれ１つずつであるが、これに限定されるものではなく、それぞれが複数あってもよいし、その一部あるいは全てでＷＥＢ兼ＡＰサーバ１０２とＤＢサーバ１０３とが共通のサーバであってもよい。
【００１６】
図２は、ＷＥＢ兼ＡＰサーバ１０２の構成の例を示す図である。ＷＥＢ兼ＡＰサーバ１０２は、記憶部２０１と、コントローラ（制御部）２０２と、メモリ２０３と、通信制御部２０４を具備し、これらはバスで接続されている。記憶部２０１には、プログラムとして、債権消込入力プログラム２１０、取引入力可能期間判定プログラム ２１１と、残高更新プログラム２１２が格納され、内部テーブルとして、債権月次締済月情報内部テーブル２１３と、債権月次未締月情報内部テーブル２１４、前月債権残高情報内部テーブル２１５、当月債権残高情報内部テーブル２１６、請求残高情報内部テーブル２１７が格納されている。記憶部２０１は、ハードディスクドライブ（ＨＤＤ）やソリッドステートドライブ（ＳＤＤ）等であってもよい。
【００１７】
コントローラ２０２は例えばプロセッサである。メモリ２０３には、記憶部２０１に格納されたプログラムや内部テーブルの一部が、必要に応じて格納され、コントローラ２０２により読み書きされる。コントローラ２０２の生成した一時的な情報が格納されてもよい。また、コントローラ２０２が各種プログラムを実行することにより、各種の機能を実現する。通信制御部２０４は、ネットワーク１０１に接続され、クライアント１０４やＤＢサーバ１０３との通信を可能にする。
【００１８】
債権消込入力プログラム２１０は、取引入力可能期間判定プログラム２１１と残高更新プログラム２１２を利用して債権を消込むためのプログラムであり、コントローラ２０２によって実行されることで債権消込入力機能を実現する。取引入力可能期間判定プログラム２１１は、登録する取引の伝票日付が入力可能な期間の範囲内であるか判定するためのプログラムであり、コントローラ２０２によって実行されることで取引入力可能期間判定機能を実現する。残高更新プログラム２１２は、債権月次締済期間へ入力された取引の情報を過去月債権残高、当月債権残高、請求残高へ更新するためのプログラムであり、コントローラ２０２によって実行されることで残高更新機能を実現する。
【００１９】
図３は、ＤＢサーバ１０３の構成の例を示す図である。ＤＢサーバ１０３は、記憶部３０１、コントローラ（制御部）３０２と、メモリ３０３と、通信制御部３０４を具備し、これらはバスで接続されている。記憶部３０１には、請求先マスタ３１０と、締制御テーブル３１１と、取引先締制御テーブル３１２と、取引先締制御情報テーブル３１３と、入金テーブル３１４と、売上テーブル３１５と、入金予定テーブル３１６と、当月債権残高テーブル３１７と、過去月債権残高テーブル３１８と、請求残高テーブル３１９と、債権消込テーブル３２０と、入金業務カレンダーテーブル３２１が格納されている。
【００２０】
コントローラ３０２は例えばプロセッサであり、図示を省略したデータベースのプログラムを実行する。メモリ３０３には、記憶部３０１に格納されたデータの一部が、必要に応じて格納され、コントローラ３０２により読み書きされる。コントローラ３０２の生成した一時的な情報が格納されてもよい。通信制御部３０４は、ネットワーク１０１に接続され、ＷＥＢ兼ＡＰサーバ１０２やクライアント１０４との通信を可能にする。
【００２１】
以下では、ＤＢサーバ１０３の記憶部３０１に格納される各テーブルについて説明する。これらのテーブルのデータは、クライアント１０４から入力されたデータが設定されてもよいし、図示を省略した装置にて予め入力されたデータが設定されてもよい。尚、各テーブルの項目について、その項目の名称から内容が明らかなものは説明を省略する。
【００２２】
図４は、請求先マスタ３１０のデータ構成の例を示す図である。請求先マスタ３１０は、債権管理対象の取引先を一意に識別する請求先コード４０１、及び該当請求先の入金対象となる決済先コード４０２を含むテーブルである。請求先コード４０１のデータと決済先コード４０２のデータとは、同一であっても異なってもよい。
【００２３】
図５は、締制御テーブル３１１のデータ構成の例を示す図である。締制御テーブル３１１は、月毎にシステムの締状態を管理しており、年度５０１と月項番５０２により対象年月を一意に特定可能とし、当月開始日付５０３、当月終了日付５０４、会計締区分５０５、債権締区分５０６を含むテーブルである。月項番５０２は会計期首月を１、期末月を１２として１から１２の値が設定される。当月開始日付５０３は年度５０１と月項番５０２により特定される年月の月初日付が設定される。
【００２４】
当月終了日付５０４は年度５０１と月項番５０２により特定される年月の月末日付が設定される。会計締区分５０５は会計管理システムの締状態を管理するための項目であり、0が未締、1が締済の状態を表す。会計締区分５０５のデータの中で、会計月次締処理時に会計締処理対象月のデータが0から1に更新される。債権締区分５０６は債権管理システムの締状態を管理する項目であり、会計締区分５０５と同様の区分値を保有する。債権締区分５０６のデータの中で、債権月次締処理時に債権月次締処理対象月のデータが0から1に更新される。尚、債権月次締処理が行われた後で会計締処理が行われるため、債権締区分５０６が更新された後で会計締区分５０５が更新される。
【００２５】
図６は、取引先締制御テーブル３１２のデータ構成の例を示す図である。取引先締制御テーブル３１２は、請求先コード６０１をテーブルのキー項目とし、締日６０２へ請求先コード単位に請求先の締日が格納されるテーブルである。尚、請求先がカレンダーの月末である月末締の場合、締日６０２には99が設定され、例えば１月１０日の場合、締日６０２には10が設定される。
【００２６】
図７は、取引先締制御情報テーブル３１３のデータ構成の例を示す図である。取引先締制御情報テーブル３１３は、請求先コード７０１をテーブルのキー項目とし、今回締開始日７０２、今回締終了日７０３、翌回締開始日７０４、翌回締終了日７０５へ請求先コード単位に各データが格納されるテーブルである。今回締開始日７０２、今回締終了日７０３、翌回締開始日７０４、翌回締終了日７０５は請求締処理にて、取引先締制御テーブル３１２のデータを元に更新される。
【００２７】
図８は、入金テーブル３１４のデータ構成の例を示す図である。入金テーブル３１４は入金伝票を一意に識別するための入金伝票番号８０１をテーブルのキー項目とし、金額８０２、消込金額８０３、伝票日付８０４、決済先コード８０５へ各データが格納されるテーブルである。入金テーブル３１４は入金入力、入金振替入力、及びＦＢ（ファームバンキング）自動入金処理によってデータが登録・更新される。また、債権消込処理にて入金伝票と債権情報の引き当て処理を実施した際に、引き当てした金額にて消込金額８０３の金額が更新される。
【００２８】
図９は、売上テーブル３１５のデータ構成の例を示す図である。売上テーブル３１５は売上伝票を一意に識別するための売上伝票番号９０１をテーブルのキー項目とし、金額９０２、消込金額９０３、伝票日付９０４、請求先コード９０５、請求ＩＤ９０６、入金予定ＩＤ９０７へ各データが格納されるテーブルである。請求ＩＤ９０６は請求先毎、請求締日毎に設定される項目である。入金予定ＩＤ９０７は請求先、請求締日、入金予定日毎に設定される項目である。
【００２９】
尚、図９の例では、請求ＩＤ９０６のデータと入金予定ＩＤ９０７のデータが同一となっているが、同一である必要はなく、上で説明した識別が可能であれば異なってもよい。売上テーブル３１５は債権（売上）計上入力によってデータ登録・更新される。また、債権個別消込入力にて売上伝票の消込処理を実施した際に、消込した金額にて消込金額９０３の金額が更新される。
【００３０】
図１０は、入金予定テーブル３１６のデータ構成の例を示す図である。入金予定テーブル３１６は入金予定ＩＤ１００１をテーブルのキー項目とし、請求先の請求締日、入金予定日毎に入金予定データを管理し、請求先コード１００２、入金予定日１００３、入金予定額１００４、消込金額１００５へ各データが格納されるテーブルである。入金予定テーブル３１６は債権（売上）計上入力によってデータが登録・更新される。
【００３１】
例えば、債権（売上）計上入力にて図９に示した売上テーブル３１５の１レコード目の売上伝票番号0000000001の売上伝票を登録した場合、金額９０２が100であるから、入金予定テーブル３１６の1レコード目の入金予定額１００４は100が設定される。その後、債権（売上）計上入力にて図９に示した売上テーブル３１５の２レコード目の売上伝票番号0000000002の売上伝票を登録した場合、金額９０２が300であるから、100に300を加算して、入金予定テーブル３１６の１レコード目の入金予定額１００４は400に設定され、図１０の例のとおりとなる。また、債権消込入力にて入金予定の消込処理を実施した際に、消込した金額にて消込金額１００５の金額を更新する。
【００３２】
図１１は、当月債権残高テーブル３１７のデータ構成の例を示す図である。当月債権残高テーブル３１７は請求先コード１１０１をテーブルのキー項目とし、請求先の当月の債権残高データを管理し、前月末残高１１０２、当月債権計上金額１１０３、当月入金決済金額１１０４、当月末残高１１０５へ各データが格納されるテーブルである。
【００３３】
前月末残高１１０２の金額と当月債権計上額１１０３の金額とを加算し、当月入金決済額１１０４の金額を減算した値が、当月末残高１１０５の金額となる。当月債権残高テーブル３１７は債権月次締処理にて残高データの繰越処理が実施され、データ更新される。また、債権（売上）計上入力、債権消込入力によってデータ更新される。
【００３４】
図１２は、過去月債権残高テーブル３１８のデータ構成の例を示す図である。過去月債権残高テーブル３１８は月毎に請求先の債権残高を管理し、年度１２０１、月項番１２０２、請求先コード１２０３をテーブルのキー項目とし、請求先の当月の債権残高データを管理し、前月末残高１２０４、当月債権計上額１２０５、当月入金決済額１２０６、当月末残高１２０７へ各データが格納されるテーブルである。
【００３５】
例えば、年度１２０１が2013であり月項番１２０２が12のレコードにおいて、前月末残高１２０４の1000と当月債権計上額１２０５の200を加算し、当月入金決済額１２０６の500を減算した値が、当月末残高１２０７の700となる。そして、この700は、年度１２０１が2014であり月項番１２０２が1のレコードの前月末残高１２０４の金額となる。尚、図１２に示した例では、請求先コード１２０３がA002やA003について、月項番１２０２が2などのレコードを省略してある。
【００３６】
過去月債権残高テーブル３１８は債権月次締処理にて残高データの退避処理が実施され、データ更新される。また、後述するＷＥＢ兼ＡＰサーバ１０２の残高更新プログラム２１２の実行によってデータが更新される。
【００３７】
図１３は、請求残高テーブル３１９のデータ構成の例を示す図である。請求残高テーブル３１９は請求ＩＤ１３０１をテーブルのキー項目とし、請求先の請求締日毎に請求残高データを管理し、請求先コード１３０２、請求開始日付１３０３、請求終了日付１３０４、前月末残高１３０５、今回請求金額１３０６、今回入金決済金額１３０７、請求残高１３０８へ各データが格納されるテーブルである。請求残高テーブル３１９は請求締処理にて残高の繰越処理が実施され、データ更新される。
【００３８】
例えば、請求ＩＤ１３０１がA001-2140531のレコードにおいて、前月末残高１３０５の600と今回請求金額１３０６の100とを加算し、今回入金決済金額１３０７の200を減算した値が、請求残高１３０８の500となる。そして、この500は、請求ＩＤ１３０１がA001-20140630のレコードの前月末残高１３０５の金額となる。また、債権（売上）計上入力、債権消込入力によってデータが更新される。
【００３９】
図１４は、債権消込テーブル３２０のデータ構成の例を示す図である。債権消込テーブル３２０は債権消込伝票を一意に識別するための債権消込伝票番号１４０１をテーブルのキー項目とし、入金伝票と入金予定の引き当て情報を管理し、金額１４０２、消込金額１４０３、伝票日付１４０４、入金伝票番号１４０５、入金予定ＩＤ１４０６へ各データが格納されるテーブルである。伝票日付１４０４は債権消込伝票の日付であり、１つの入金伝票に対して複数の債権消込伝票があってもよい。債権消込テーブル３２０は債権消込入力によってデータ登録・更新される。
【００４０】
図１５は、入金業務カレンダーテーブル３２１のデータ構成の例を示す図である。入金業務カレンダーテーブル３２１は年度１５０１、月項番１５０２、入金業務可能日１５０３の情報が格納されるテーブルであり、対象年月毎に複数の入金業務可能日を設定することが可能である。
【００４１】
図１６は債権消込処理を実行するか否かの確認を行うための債権消込処理確認画面の例を示す図である。この債権消込処理確認画面３２２は、クライアント１０４に表示される画面であり、図１７を用いて説明する債権消込入力処理の中で使用される。
【００４２】
図１７は債権消込入力処理のフローチャートの例を示す図である。ユーザがクライアント１０４で消込対象の入金伝票番号を入力すると、ＷＥＢ兼ＡＰサーバ１０２は入力された入金伝票番号を取得してＤＢサーバ１０３へ入金テーブル３１４の検索を指示し、ＤＢサーバ１０３は指示された入金伝票番号をキーとして、入金伝票番号８０１に基づき入金テーブル３１４を検索し、金額８０２、消込金額８０３、伝票日付８０４、決済先コード８０５を取得し、ＷＥＢ兼ＡＰサーバ１０２へ通知する（Ｓ１７０１）。
【００４３】
次に、ユーザがクライアント１０４で請求先コードを入力すると、ＷＥＢ兼ＡＰサーバ１０２は入力された請求先コードを取得してＤＢサーバ１０３へ入金予定テーブル３１６の検索を指示し、ＤＢサーバ１０３は指示された請求先コードをキーとして、請求先コード１００２に基づき入金予定テーブル３１６を検索し、入金予定ＩＤ１００１、入金予定日１００３、入金予定額１００４、消込金額１００５を取得し、ＷＥＢ兼ＡＰサーバ１０２へ通知する（Ｓ１７０２）。
【００４４】
Ｓ１７０２で取得されて通知された入金予定データを、ＷＥＢ兼ＡＰサーバ１０２はクライアント１０４へ通知し、クライアント１０４は通知された入金予定データを表示して入金予定データの中で今回消込対象のデータをユーザに選択させ、選択された入金予定データをクライアント１０４が取得する（Ｓ１７０３）。次に、ユーザが債権消込伝票情報として、金額、伝票日付を入力し、クライアント１０４がそれらの入力された情報を取得する（Ｓ１７０４）。
【００４５】
ユーザがクライアント１０４の図示を省略した登録ボタンを押下すると、クライアント１０４はＷＥＢ兼ＡＰサーバ１０２へＳ１７０３とＳ１７０４で取得した情報とともに登録チェック処理の実行指示を出す（Ｓ１７０５）。そして、ＷＥＢ兼ＡＰサーバ１０２は登録のチェック処理として取引入力可能期間判定プログラム２１１（Ｓ１７０６）を実行する。取引入力可能期間判定プログラム２１１の実行において、Ｓ１７０４で入力された伝票日付が登録可能な日付であるか否かを判定する（Ｓ１７０７）。
【００４６】
Ｓ１７０７にて登録可能な日付と判定された場合、図１６に示した債権消込処理確認画面３２２の表示をＷＥＢ兼ＡＰサーバ１０２はクライアント１０４へ指示し、クライアント１０４は債権消込処理確認画面３２２を表示することにより、ユーザに債権消込処理を実行するか否かの確認を行う（Ｓ１７０８）。債権消込処理確認画面３２２にて、「はい」のボタンが押下されたか否かを判定する（Ｓ１７０９）。ここで、クライアント１０４が判定して判定結果をＷＥＢ兼ＡＰサーバ１０２へ通知してもよいし、クライアント１０４が押下の情報をＷＥＢ兼ＡＰサーバ１０２へ通知してＷＥＢ兼ＡＰサーバ１０２が判定してもよい。
【００４７】
「はい」のボタンが押下されたと判定した場合、ＷＥＢ兼ＡＰサーバ１０２はＳ１７０１で取得した入金伝票番号をキーとして、Ｓ１７０４で取得した金額にて入金伝票テーブル３１４の消込金額８０３を更新する（Ｓ１７１０）。同様に、Ｓ１７０２で取得した入金予定ＩＤをキーとして、Ｓ１７０４で入力された金額にて入金予定テーブル３１６の消込金額１００５を更新する（Ｓ１７１１）。次に、債権消込伝票を一意に識別する債権消込伝票番号を自動採番する（Ｓ１７１２）。
【００４８】
ＷＥＢ兼ＡＰサーバ１０２の指示により、ＤＢサーバ１０３にて、Ｓ１７０１で取得した入金伝票番号、Ｓ１７０２で取得した入金予定ＩＤ、Ｓ１７０４で取得した金額、伝票日付、及びＳ１７１２で採番した債権消込伝票番号が、債権消込テーブル３２０の入金伝票番号１４０５、入金予定ＩＤ１４０６、金額１４０２、伝票日付１４０３の値として登録される（Ｓ１７１３）。尚、債権消込テーブル３２０の消込金額１４０３の初期値は0が設定される。そして、ＷＥＢ兼ＡＰサーバ１０２は残高更新プログラム２１２（Ｓ１７１４）を実行し、債権消込入力処理を終了する。
【００４９】
取引入力可能期間判定プログラム２１１（Ｓ１７０６）の詳細について、図１８、図１９、図２０に基づいて説明する。
【００５０】
図１８は債権月次締済月情報内部テーブル２１３のデータ構成の例を示す図である。債権月次締済月情報内部テーブル２１３は、図２０を用いて後で説明する取引入力可能期間判定処理フローチャートのＳ２００１で取得した結果が格納されるＷＥＢ兼ＡＰサーバ１０２の内部テーブルである。債権月次締済月情報内部テーブル２１３は年度１８０１、月項番１８０２、当月開始日付１８０３、当月終了日付１８０４、債権締区分１８０５の各データが格納される。
【００５１】
図１９は債権月次未締月情報内部テーブル２１４のデータ構成の例を示す図である。債権月次未締月情報内部テーブル２１４は、図２０を用いて後で説明する取引入力可能期間判定処理フローチャートのＳ２００２で取得した結果が格納されるＷＥＢ兼ＡＰサーバ１０２の内部テーブルである。債権月次未締月情報内部テーブル２１４は年度１９０１、月項番１９０２、当月開始日付１９０３、当月終了日付１９０４、会計締区分１９０５の各データが格納される。
【００５２】
図２０に示す取引入力可能期間判定処理のフローチャートの例を用いて、取引入力可能期間プログラム２１１に基づく動作を説明する。
【００５３】
まず、ＷＥＢ兼ＡＰサーバ１０２はＤＢサーバ１０３へ指示し、締制御テーブル３１１より債権締区分５０６が「1」（締済）のレコードの中で、年度５０１と月項番５０２を結合した値が最大値すなわち最後の年月となるレコードを取得し、取得した結果を債権月次締済月情報内部テーブル２１３へ格納する（Ｓ２００１）。例えば、締制御テーブル３１１に図５に示すレコードが格納されている場合、上から３レコード目のデータが取得される。
【００５４】
次に、ＷＥＢ兼ＡＰサーバ１０２はＤＢサーバ１０３へ指示し、締制御テーブル３１１より会計締区分５０５が「0」（未締）のレコードの中で、年度５０１、月項番５０２を結合した値が最小値すなわち最初の年月となるレコードを取得し、取得した結果を債権月次未締月情報内部テーブル２１４へ格納する（Ｓ２００２）。例えば、締制御テーブル３１１に図５に示すレコードが格納されている場合、上から４レコード目のデータが取得される。
【００５５】
ＷＥＢ兼ＡＰサーバ１０２は、Ｓ１７０４で取得した伝票日付が債権月次締済月への伝票登録であるか判定を行う（Ｓ２００３）。Ｓ１７０４で取得した伝票日付がＳ２００１で取得した債権月次締済月情報内部テーブル２１３の当月開始日付１８０３より小さい日付（年月日が前）、且つＳ２００２で取得した債権月次未締月情報内部テーブル２１４の当月開始日付１９０３以上の日付、且つＳ２００２で取得した債権月次未締月情報内部テーブル２１４の当月終了日付１９０４以下の日付であるか判定し、この条件を満たす場合は債権月次締済月への伝票登録とみなす。
【００５６】
この条件を満たさない場合、債権月次締済月への伝票登録でなはいとみなし、エラーなしとして取引入力可能期間判定の処理を終了する。ＷＥＢ兼ＡＰサーバ１０２は、Ｓ２００３で債権月次締済月への伝票登録と判定された場合、Ｓ２００４を実行する直前の日付を処理日付として取得し、処理日付が入金業務可能日であるか判定を行う（Ｓ２００４）。処理日付は債権消込入力処理を実施している日付のことを示し、例えばＷＥＢ兼ＡＰサーバ１０２のコンピュータとしての時計から取得してもよいし、クライアント１０４から設定された日付を取得してもよい。
【００５７】
Ｓ２００４の判定のためにＷＥＢ兼ＡＰサーバ１０２はＤＢサーバ１０３へ指示し、入金業務カレンダーテーブル３２１の年度１５０１の値がＳ２００２で取得した債権月次未締月情報内部テーブル２１４の年度１９０１の値と等しく、且つ月項番１５０２の値がＳ２００２で取得した債権月次未締月情報内部テーブル２１４の月項番１９０２の値と等しく、且つ入金業務可能日１５０３の値が処理日付と等しいレコードを検索する。該当するレコードの検索結果が１件以上取得できた場合、処理日付は入金業務可能日であるとする。該当するレコードの検索結果が取得できなかった場合、処理日付は入金業務可能日ではないとし、エラーありとして取引入力可能期間判定の処理を終了する。
【００５８】
Ｓ２００４で入金業務可能日であると判定された場合、Ｓ１７０４で取得した伝票日付が会計月次締済月への伝票登録であるかの判定を行う（Ｓ２００５）。ＷＥＢ兼ＡＰサーバ１０２はＤＢサーバ１０３へ指示し、締制御テーブル３１１の当月開始日付５０３がＳ１７０４で取得した伝票日付以下の日付、且つ当月終了日付５０４がＳ１７０４で取得した伝票日付以上の日付、且つ会計締区分５０５が「0」（未締）のレコードを検索する。
【００５９】
該当するレコードの検索結果が１件以上取得できた場合、会計月次未締期間への伝票登録とみなし、エラーなしとして取引入力可能期間判定の処理を終了する。また、該当するレコードの検索結果が取得できなかった場合、会計月次未締期間への伝票登録ではないとみなし、エラーありとして取引入力可能期間判定の処理を終了する。
【００６０】
残高更新プログラム２１２（Ｓ１７１４）の詳細について、図２１、図２２、図２３、図２４、図２５、図２６、図２７に基づいて説明する。
【００６１】
図２１は前月債権残高情報内部テーブル２１５のデータ構成の例を示す図である。前月債権残高情報内部テーブル２１５は、図２４を用いて後で説明する残高更新処理フローチャートのＳ２４０６で取得した結果が格納されるＷＥＢ兼ＡＰサーバ１０２の内部テーブルである。前月債権残高情報内部テーブル２１５は年度２１０１、月項番２１０２、請求先コード２１０３、前月末残高２１０４、当月債権計上額２１０５、当月入金決済額２１０６、当月末残高２１０７の各データが格納される。
【００６２】
図２２は当月債権残高情報内部テーブル２１６のデータ構成の例を示す図である。当月債権残高情報内部テーブル２１６は図２４を用いて後で説明する残高更新処理フローチャートのＳ２４０３、及びＳ２４０７で取得した結果が格納されるＷＥＢ兼ＡＰサーバ１０２の内部テーブルである。当月債権残高情報内部テーブル２１６は請求先コード２２０１、前月末残高２２０２、当月債権計上額２２０３、当月入金決済額２２０４、当月末残高２２０５へ各データが格納される。
【００６３】
図２３は請求残高情報内部テーブル２１７のデータ構成の例を示す図である。請求残高情報内部テーブル２１７は図２４を用いて後で説明する残高更新処理フローチャートのＳ２４１０で取得した結果が格納されるＷＥＢ兼ＡＰサーバ１０２の内部テーブルである。請求残高情報内部テーブル２１７は請求ＩＤ２３０１、請求先コード２３０２、請求開始日付２３０３、請求終了日付２３０４、前月末残高２３０５、今回請求金額２３０６、今回入金決済金額２３０７、請求残高２３０８へ各データが格納される。
【００６４】
図２４に示す残高更新処理のフローチャートの例を用いて、残高更新プログラム２１２に基づく動作を説明する。まず、更新時点での債権締期間情報を取得するために、ＷＥＢ兼ＡＰサーバ１０２はＤＢサーバ１０３へ指示し、締制御テーブル３１１の債権締区分５０６が「0」（未締）で年度５０１、月項番５０２を結合した値が最小値となるレコードを取得し、取得した結果を債権月次未締月情報内部テーブル２１４へ格納する（Ｓ２４０１）。例えば、締制御テーブル３１１に図５に示すレコードが格納されている場合、上から４レコード目のデータが取得される。
【００６５】
ＷＥＢ兼ＡＰサーバ１０２は、Ｓ１７０４で取得した伝票日付が債権月次締済月への伝票登録であるか判定を行う（Ｓ２４０２）。Ｓ１７０４で取得した伝票日付がＳ２４０１で取得した債権月次未締月情報内部テーブル２１４の当月開始日付１９０３より小さい日付であるか判定し、条件を満たす場合、締済月への債権残高更新があるとしてＳ２４０５へ処理を進める。これに対し、条件を満たさない場合、締済月への債権残高更新がないとしてＳ２４０３へ処理を進める。
【００６６】
次に、締済月への債権残高更新がない場合の処理について説明する。締済月への債権残高更新がないため、更新対象の債権残高は当月債権残高テーブル３１７のみとなる。まず、更新対象となる当月債権残高を取得するために、ＷＥＢ兼ＡＰサーバ１０２はＤＢサーバ１０３へ指示し、Ｓ１７０２で取得した入金予定ＩＤに紐付く請求項コード（入金予定テーブル３１６において入金予定ＩＤ１００１の値と同じレコードの請求先コード１００２の値）が、請求先コード１１０１の値と等しいレコードを、当月債権残高テーブル３１７から取得し、当月残高情報内部テーブル２１６へ格納する（Ｓ２４０３）。
【００６７】
そして、Ｓ２４０３で取得した結果とＳ１７０４で取得した金額の情報をもとに、当月債権残高テーブル３１７を更新する（Ｓ２４０４）。具体的には、当月債権残高テーブル３１７の請求先コード１１０１の値がＳ２４０３で取得した当月残高情報内部テーブル２１６の請求先コード２２０１の値と等しいレコードを更新対象のレコードとし、ＷＥＢ兼ＡＰサーバ１０２はＤＢサーバ１０３へ指示し、Ｓ２４０３で格納した当月残高情報内部テーブル２１６の当月入金決済額２２０４にＳ１７０４で取得した金額を加算した値にて当月入金決済額１１０４を更新し、Ｓ２４０３で格納した当月残高情報内部テーブル２１６の当月末残高２２０５からＳ１７０４で取得した金額を減算した値にて当月末残高１１０５を更新する。尚、当月残高情報内部テーブル２１６の中で加算と減算をして、その算出結果を当月債権残高テーブル３１７へ格納してもよい。
【００６８】
図２５にＳ２４０３からＳ２４０４の処理による当月債権残高テーブル３１７の更新の例を示す。請求先コードのＡ００１のレコードについて、当月入金決済額１１０４の300を600に更新し、当月末残高１１０５の600を300に更新する。
【００６９】
次に、締済月への債権残高更新がある場合の債権残高更新処理Ｓ２４０５からＳ２４０９の処理について説明する。これらの処理では、締済月への債権残高更新があるため、更新対象の債権残高は過去月債権残高テーブル３１８、当月債権残高テーブル３１７となる。
【００７０】
まず、ＷＥＢ兼ＡＰサーバ１０２はＤＢサーバ１０３へ指示し、更新対象となる前月の債権締期間情報を取得するために、締制御テーブル３１１より債権締区分５０６が「1」（締済）で年度５０１、月項番５０２を結合した値が最大値となるレコードを取得し、取得した結果を債権月次締済月情報内部テーブル２１３へ格納する（Ｓ２４０５）。例えば、締制御テーブル３１１に図５に示すレコードが格納されている場合、上から３レコード目のデータが取得される。
【００７１】
更新対象となる前月債権残高を取得するために、ＷＥＢ兼ＡＰサーバ１０２はＤＢサーバ１０３へ指示し、過去月債権残高テーブル３１８において、請求先コード１２０３の値がＳ１７０２で取得した入金予定ＩＤに紐付く請求先コード（入金予定テーブルの請求先コード１００２）の値と等しく、且つ年度１２０１の値がＳ２４０５で取得した債権月次締済月情報内部テーブル２１３の年度１８０１の値と等しく、且つ月項番１２０２の値がＳ２４０５で取得した債権月次締済月情報内部テーブル２１３の月項番１８０２の値と等しいレコードを取得し、前月残高情報内部テーブル２１５へ格納する（Ｓ２４０６）。
【００７２】
更新対象となる当月債権残高を取得するために、ＷＥＢ兼ＡＰサーバ１０２はＤＢサーバ１０３へ指示し、当月債権残高テーブル３１７において、請求先コード１１０１の値がＳ１７０２で取得した入金予定ＩＤに紐付く請求先コード（入金予定テーブルの請求先コード１００２）の値と等しいレコードを取得し、当月残高情報内部テーブル２１６へ格納する（Ｓ２４０７）。
【００７３】
Ｓ２４０６で格納した結果とＳ１７０４で取得した金額の情報をもとに、過去月債権残高テーブル３１８を更新する（Ｓ２４０８）。具体的には、ＷＥＢ兼ＡＰサーバ１０２はＤＢサーバ１０３へ指示し、過去月債権残高テーブル３１８の請求先コード１２０３の値がＳ２４０５で格納した前月残高情報内部テーブル２１５の請求先コード２１０３の値と等しく、且つ年度１２０１の値がＳ２４０５で格納した前月残高情報内部テーブル２１５の年度２１０１の値と等しく、且つ月項番１２０２の値がＳ２４０５で格納した前月残高情報内部テーブル２１５の月項番２１０２の値と等しいレコードを更新対象のレコードとし、Ｓ２４０６で格納した前月残高情報内部テーブル２１５の当月入金決済額２１０６の値にＳ１７０４で取得した金額を加算した値にて当月入金決済額１２０６を更新し、Ｓ２４０６で格納した前月残高情報内部テーブル２１５の当月末残高２１０７の値からＳ１７０４で取得した金額を減算した値にて当月末残高１２０７を更新する。
【００７４】
Ｓ２４０７で取得した結果とＳ１７０４で取得した金額をもとに、当月債権残高テーブル３１７を更新する（Ｓ２４０９）。具体的には、ＷＥＢ兼ＡＰサーバ１０２はＤＢサーバ１０３へ指示し、当月債権残高テーブル３１７の請求先コード１１０１がＳ２４０７で格納した当月残高情報内部テーブル２１６の請求先コード２２０１と等しいレコードを更新対象のレコードとし、Ｓ２４０７で格納した当月残高情報内部テーブル２１６の前月末残高２２０２からＳ１７０４で取得した金額を減算した値にて前月末残高１１０２を更新し、Ｓ２４０７で格納した当月残高情報内部テーブル２１６の当月末残高２２０５からＳ１７０４で取得した金額を減算した値にて当月末残高１１０５を更新する。
【００７５】
図２６にＳ２４０６からＳ２４０９の処理による過去月債権残高テーブル３１８と当月債権残高テーブル３１７の更新の例を示す。請求先コードがA001の年度が2014で月項番が2のレコードについて、当月入金決済額１２０６の200を500に更新し、当月末残高１２０７の500を200に更新する。また、請求先コードがA001のレコードについて、前月末残高１１０２の500を200に更新し、当月末残高１１０５の600を300に更新する。
【００７６】
次に、更新対象の請求残高を取得する。尚、請求残高は請求先の締日毎に一つのテーブルにデータを保持しているため、前月債権残高の更新有無に関わらず、同じ更新の処理であるＳ２４１０からＳ２４１４にて実現する。ＷＥＢ兼ＡＰサーバ１０２はＤＢサーバ１０３へ指示し、請求先コード１３０２がＳ１７０２で取得した入金予定ＩＤに紐付く請求先コード（入金予定テーブルの請求先コード１００２）と等しく、且つ請求終了日付１３０４がＳ１７０４で取得した伝票日付以上の日付のレコードを請求残高テーブル３１９から取得し、ＷＥＢ兼ＡＰサーバ１０２は取得した情報を請求ＩＤで昇順にソートして、請求残高情報内部テーブル２１７へ格納する（Ｓ２４１０）。
【００７７】
ＷＥＢ兼ＡＰサーバ１０２は、Ｓ２４１０で取得した請求残高情報内部テーブル２１７を1件ずつ読込み（Ｓ２４１１）、Ｓ１７０４で取得した金額をもとに請求残高テーブル３１９を更新する。この請求残高テーブル３１９の更新は、取引日対象残高の更新処理（Ｓ２４１３）と、それ以降の請求日付のレコードの残高繰越の更新処理（Ｓ２４１４）とで異なる。このために、ＷＥＢ兼ＡＰサーバ１０２は、Ｓ２４１１で読込んだ請求残高情報内部テーブル２１７のレコードが１レコード目であるか否かを判定し、１レコード目である場合はＳ２４１３へ遷移し、それ以外の場合Ｓ２４１４へ遷移する（Ｓ２４１２）。
【００７８】
Ｓ２４１３でＷＥＢ兼ＡＰサーバ１０２はＤＢサーバ１０３へ指示し、請求残高テーブル３１９の請求ＩＤ１３０１の値がＳ２４１１で読込んだ請求残高情報内部テーブル２１７の請求ＩＤ２３０１の値と等しいレコードを更新対象のレコードとし、Ｓ２４１１で読込んだ請求残高情報内部テーブル２１７の今回入金決済金額２３０７の値とＳ１７０４で取得した金額を加算した値にて今回入金決済金額１３０７を更新し、Ｓ２４１１で読込んだ請求残高情報内部テーブル２１７の請求残高２３０８の値からＳ１７０４で取得した金額を減算した値にて請求残高１３０８を更新する。
【００７９】
Ｓ２４１４でＷＥＢ兼ＡＰサーバ１０２はＤＢサーバ１０３へ指示し、請求残高テーブル３１９の請求ＩＤ１３０１の値がＳ２４１１で読込んだ請求残高情報内部テーブル２１７の請求ＩＤ２３０１と等しいレコードを更新対象のレコードとし、Ｓ２４１１で読込んだ請求残高情報内部テーブル２１７の前月末残高２３０７の値とＳ１７０４で取得した金額を加算した値にて前月末残高１３０５を更新し、Ｓ２４１１で読込んだ請求残高情報内部テーブル２１７の請求残高２３０８の値からＳ１７０４で取得した金額を減算した値にて請求残高１３０８を更新する。
【００８０】
ＷＥＢ兼ＡＰサーバ１０２は、Ｓ２４１１のループで、全てのレコードの処理が完了したら、残高更新プログラム２１２の処理を終了する。
【００８１】
図２７にＳ２４１０からＳ２４１４の処理による請求残高テーブル３１９の更新の例を示す。請求項ＩＤがA001-20140531のレコードについて、今回入金決済金額１３０７の200を500に更新して、請求残高１３０８の500を200に更新し、請求項ＩＤがA001-20140630の前月末残高１３０５の500を200に更新して、請求残高１３０８の600を300に更新する。
【００８２】
以上で説明したように、債権月次締処理後も会計締区分が未締の期間において、締済月に対する入金業務を可能となり、締済期間の債権関連の残高を取引に合わせた更新が可能となる。また、次の月初めが会計の締めでない場合、前月の処理を持ち越すことができ、翌月に処理を分散できるため、月末入金業務の負荷軽減が可能となる。更に、債権月次締処理後に発覚した入金業務のミスオペレーションの訂正が可能となり、債権システムのデータと実際の取引の状態が乖離する可能性を低減できる。
【符号の説明】
【００８３】
１０１  ネットワーク
１０２  ＷＥＢ兼ＡＰサーバ
１０３  ＤＢサーバ
１０４  クライアント
３１１  締制御テーブル
３１７  当月債権残高テーブル
３１８  過去月債権残高テーブル
３１９  請求残高テーブル
３２１  入金業務カレンダーテーブル
【図１】
2016151943.tif 000003
【図２】
2016151943.tif 000004
【図３】
2016151943.tif 000005
【図４】
2016151943.tif 000006
【図５】
2016151943.tif 000007
【図６】
2016151943.tif 000008
【図７】
2016151943.tif 000009
【図８】
2016151943.tif 000010
【図９】
2016151943.tif 000011
【図１０】
2016151943.tif 000012
【図１１】
2016151943.tif 000013
【図１２】
2016151943.tif 000014
【図１３】
2016151943.tif 000015
【図１４】
2016151943.tif 000016
【図１５】
2016151943.tif 000017
【図１６】
2016151943.tif 000018
【図１７】
2016151943.tif 000019
【図１８】
2016151943.tif 000020
【図１９】
2016151943.tif 000021
【図２０】
2016151943.tif 000022
【図２１】
2016151943.tif 000023
【図２２】
2016151943.tif 000024
【図２３】
2016151943.tif 000025
【図２４】
2016151943.tif 000026
【図２５】
2016151943.tif 000027
【図２６】
2016151943.tif 000028
【図２７】
2016151943.tif 000029