JP2016151943A - 債権管理システム及びその制御方法 - Google Patents

債権管理システム及びその制御方法 Download PDF

Info

Publication number
JP2016151943A
JP2016151943A JP2015029770A JP2015029770A JP2016151943A JP 2016151943 A JP2016151943 A JP 2016151943A JP 2015029770 A JP2015029770 A JP 2015029770A JP 2015029770 A JP2015029770 A JP 2015029770A JP 2016151943 A JP2016151943 A JP 2016151943A
Authority
JP
Japan
Prior art keywords
balance
month
date
slip
billing
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.)
Pending
Application number
JP2015029770A
Other languages
English (en)
Inventor
隆行 河地
Takayuki Kawachi
隆行 河地
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
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 Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2015029770A priority Critical patent/JP2016151943A/ja
Publication of JP2016151943A publication Critical patent/JP2016151943A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

【課題】債権月次締処理後も特定期間において締済月に対する入金業務を可能とし、締済期間の債権関連の残高を取引に合わせた更新を可能とする債権管理システムを提供する。【解決手段】入金伝票の日付と金額と請求先が入力されるクライアント104と、会計締区分の情報と債権締区分の情報とを年月毎に記憶する締制御テーブルと、年月毎に入金業務可能日を記憶する入金業務カレンダーテーブルとを有するデータベースサーバ103と、クライアント104から入力された入金伝票の日付を受信し、データベースサーバ103へ指示し、入力された入金伝票の日付が債権締区分の情報として締状態を示して会計締区分の情報として未締状態を示すことを判定し、入力された入金伝票の日付が入金業務可能日であることを判定し、入力された入金伝票の金額で残高更新処理を実行するアプリケーションサーバ102を有する。【選択図】図1

Description

本発明は、債権管理システム及びその制御方法に関するものである。
請求先の売上情報に紐付く入金予定情報と決済先に対する入金情報、及び決済先と請求先の紐付け情報のマスタを参照することで、請求先の債権消込処理をすることが可能となる。また、月次で債権の締処理を実施し、締済期間に対する請求先への売上計上、債権消込の取引を禁止することで請求先に対する月次債権残高の情報を確定する事ができる。入金業務担当者は月次の締処理までに入金業務を完了させ、請求先の月次債権残高を適切に管理する必要があった。
決済先単位で入金業務を可能とする技術として、例えば特許文献1には、請求先と異なる決済先との対応マスタに登録することを可能とし、請求先と決済先が関連付けられたマスタデータより決済先単位の入金業務を可能とする装置を提供する技術が開示されている。
また、未決済の債権情報を自動消込する技術として、特許文献2には、債権消込対象となる入金金額と請求金額を演算手段により突合し、両金額が一致した場合、またはその金額の差が予め設定された誤差範囲内であれば自動で消込処理がなされる技術が開示されている。
特開2012−230443号公報 特開2004−185588号公報
債権管理システムでは請求先の債権計上、請求、入金業務を実施し、請求先の債権情報を管理する。債権計上は各営業担当者、請求、入金業務は入金業務担当者というように各業務は別々の担当者により実施される。また、当月取引を凍結するために債権月次締処理を実施し、月次で債権残高を確定させる。そのため、入金業務担当者は取引が凍結となる債権月次締処理までに当月分の入金業務を完了させる必要がある。
一方で、不特定多数のユーザが債権管理業務を実施するので、運用にて各ユーザの取引入力を制御することは困難である。そのため、各ユーザの当月取引入力完了状況に関わらず特定のタイミングで強制的に債権月次締処理を実施する必要がある。
しかしながら、月末入金の請求先が多いこともあり、入金業務が債権月次締処理までに完了しないという課題が発生していた。また、債権月次締処理後は取引の凍結がされており取引の修正が不可となっているため、入金業務のミスオペレーションが発覚した場合には翌月取引での訂正により対応を行うが、このような対応を行った場合、債権システムのデータと実際の取引の状態が乖離してしまうという課題も発生していた。
そこで、本発明は、債権月次締処理後も特定期間において締済月に対する入金業務を可能とし、また締済期間の債権関連の残高を取引に合わせて更新することを目的とする。
本発明に係る代表的な債権管理システムは、入金伝票の日付と金額と請求先が入力される債権管理システムであって、前記入金伝票の日付と金額と請求先が入力されるクライアントと、会計締区分の情報と債権締区分の情報とを年月毎に記憶する締制御テーブルと、年月毎に入金業務可能日を記憶する入金業務カレンダーテーブルとを有するデータベースサーバと、前記クライアントから前記入力された入金伝票の日付を受信し、前記データベースサーバへ指示し、前記入力された入金伝票の日付が前記債権締区分の情報として締状態を示して前記会計締区分の情報として未締状態を示すことを判定し、前記入力された入金伝票の日付が前記入金業務可能日であることを判定し、前記入力された入金伝票の金額で残高更新処理を実行するアプリケーションサーバとを有することを特徴とする。
本発明によれば、債権月次締処理後も特定期間において締済月に対する入金業務が可能となり、また締済期間の債権関連の残高を取引に合わせた更新が可能となる。
債権管理システムの構成の例を示す図である。 WEB兼APサーバの構成の例を示す図である。 DBサーバの構成の例を示す図である。 請求先マスタのデータ構成の例を示す図である。 締制御テーブルのデータ構成の例を示す図である。 取引先締制御テーブルのデータ構成の例を示す図である。 取引先締制御情報テーブルのデータ構成の例を示す図である。 入金テーブルのデータ構成の例を示す図である。 売上テーブルのデータ構成の例を示す図である。 入金予定テーブルのデータ構成の例を示す図である。 当月債権残高テーブルのデータ構成の例を示す図である。 過去月債権残高テーブルのデータ構成の例を示す図である。 請求残高テーブルのデータ構成の例を示す図である。 債権消込テーブルのデータ構成の例を示す図である。 入金業務カレンダーテーブルのデータ構成の例を示す図である。 クライアントで表示される債権消込処理確認画面の例を示す図である。 債権消込入力処理のフローチャートの例を示す図である。 債権月次締済月情報内部テーブルのデータ構成の例を示す図である。 債権月次未締月情報内部テーブルのデータ構成の例を示す図である。 取引入力可能期間判定処理のフローチャートの例を示す図である。 前月債権残高情報内部テーブルのデータ構成の例を示す図である。 当月債権残高情報内部テーブルのデータ構成の例を示す図である。 請求残高情報内部テーブルのデータ構成の例を示す図である。 残高更新処理のフローチャートの例を示す図である。 残高更新処理によるテーブルの更新の例を示す図である。 残高更新処理によるテーブルの更新の例を示す図である。 残高更新処理によるテーブルの更新の例を示す図である。
以下、本発明の実施形態について、図面を参照して詳細に説明する。
図1は、債権管理システムの構成の例を示す図である。債権管理システム100は、ネットワークで複数のコンピュータが接続されたウェブ型のコンピュータシステムであり、ウェブ兼アプリケーション(WEB兼AP)サーバ102と、データベース(DB)サーバ103と、複数のクライアント(端末)104がネットワーク101に接続されて構成されるシステムである。
WEB兼APサーバ102は、後で説明する処理を実行するサーバであり、クライアント104へウェブを提供することにより、クライアント104で入力された情報を受け付けて処理に使用し、処理の結果等をクライアント104で表示することが可能である。DBサーバ103は、後で説明する情報を例えばリレーショナルデータベース(RDB)で管理するサーバである。WEB兼APサーバ102からの例えばSQLによる検索指示や更新指示に基づき動作する。尚、図1に示した例では、WEB兼APサーバ102とDBサーバ103はそれぞれ1つずつであるが、これに限定されるものではなく、それぞれが複数あってもよいし、その一部あるいは全てでWEB兼APサーバ102とDBサーバ103とが共通のサーバであってもよい。
図2は、WEB兼APサーバ102の構成の例を示す図である。WEB兼APサーバ102は、記憶部201と、コントローラ(制御部)202と、メモリ203と、通信制御部204を具備し、これらはバスで接続されている。記憶部201には、プログラムとして、債権消込入力プログラム210、取引入力可能期間判定プログラム 211と、残高更新プログラム212が格納され、内部テーブルとして、債権月次締済月情報内部テーブル213と、債権月次未締月情報内部テーブル214、前月債権残高情報内部テーブル215、当月債権残高情報内部テーブル216、請求残高情報内部テーブル217が格納されている。記憶部201は、ハードディスクドライブ(HDD)やソリッドステートドライブ(SDD)等であってもよい。
コントローラ202は例えばプロセッサである。メモリ203には、記憶部201に格納されたプログラムや内部テーブルの一部が、必要に応じて格納され、コントローラ202により読み書きされる。コントローラ202の生成した一時的な情報が格納されてもよい。また、コントローラ202が各種プログラムを実行することにより、各種の機能を実現する。通信制御部204は、ネットワーク101に接続され、クライアント104やDBサーバ103との通信を可能にする。
債権消込入力プログラム210は、取引入力可能期間判定プログラム211と残高更新プログラム212を利用して債権を消込むためのプログラムであり、コントローラ202によって実行されることで債権消込入力機能を実現する。取引入力可能期間判定プログラム211は、登録する取引の伝票日付が入力可能な期間の範囲内であるか判定するためのプログラムであり、コントローラ202によって実行されることで取引入力可能期間判定機能を実現する。残高更新プログラム212は、債権月次締済期間へ入力された取引の情報を過去月債権残高、当月債権残高、請求残高へ更新するためのプログラムであり、コントローラ202によって実行されることで残高更新機能を実現する。
図3は、DBサーバ103の構成の例を示す図である。DBサーバ103は、記憶部301、コントローラ(制御部)302と、メモリ303と、通信制御部304を具備し、これらはバスで接続されている。記憶部301には、請求先マスタ310と、締制御テーブル311と、取引先締制御テーブル312と、取引先締制御情報テーブル313と、入金テーブル314と、売上テーブル315と、入金予定テーブル316と、当月債権残高テーブル317と、過去月債権残高テーブル318と、請求残高テーブル319と、債権消込テーブル320と、入金業務カレンダーテーブル321が格納されている。
コントローラ302は例えばプロセッサであり、図示を省略したデータベースのプログラムを実行する。メモリ303には、記憶部301に格納されたデータの一部が、必要に応じて格納され、コントローラ302により読み書きされる。コントローラ302の生成した一時的な情報が格納されてもよい。通信制御部304は、ネットワーク101に接続され、WEB兼APサーバ102やクライアント104との通信を可能にする。
以下では、DBサーバ103の記憶部301に格納される各テーブルについて説明する。これらのテーブルのデータは、クライアント104から入力されたデータが設定されてもよいし、図示を省略した装置にて予め入力されたデータが設定されてもよい。尚、各テーブルの項目について、その項目の名称から内容が明らかなものは説明を省略する。
図4は、請求先マスタ310のデータ構成の例を示す図である。請求先マスタ310は、債権管理対象の取引先を一意に識別する請求先コード401、及び該当請求先の入金対象となる決済先コード402を含むテーブルである。請求先コード401のデータと決済先コード402のデータとは、同一であっても異なってもよい。
図5は、締制御テーブル311のデータ構成の例を示す図である。締制御テーブル311は、月毎にシステムの締状態を管理しており、年度501と月項番502により対象年月を一意に特定可能とし、当月開始日付503、当月終了日付504、会計締区分505、債権締区分506を含むテーブルである。月項番502は会計期首月を1、期末月を12として1から12の値が設定される。当月開始日付503は年度501と月項番502により特定される年月の月初日付が設定される。
当月終了日付504は年度501と月項番502により特定される年月の月末日付が設定される。会計締区分505は会計管理システムの締状態を管理するための項目であり、0が未締、1が締済の状態を表す。会計締区分505のデータの中で、会計月次締処理時に会計締処理対象月のデータが0から1に更新される。債権締区分506は債権管理システムの締状態を管理する項目であり、会計締区分505と同様の区分値を保有する。債権締区分506のデータの中で、債権月次締処理時に債権月次締処理対象月のデータが0から1に更新される。尚、債権月次締処理が行われた後で会計締処理が行われるため、債権締区分506が更新された後で会計締区分505が更新される。
図6は、取引先締制御テーブル312のデータ構成の例を示す図である。取引先締制御テーブル312は、請求先コード601をテーブルのキー項目とし、締日602へ請求先コード単位に請求先の締日が格納されるテーブルである。尚、請求先がカレンダーの月末である月末締の場合、締日602には99が設定され、例えば1月10日の場合、締日602には10が設定される。
図7は、取引先締制御情報テーブル313のデータ構成の例を示す図である。取引先締制御情報テーブル313は、請求先コード701をテーブルのキー項目とし、今回締開始日702、今回締終了日703、翌回締開始日704、翌回締終了日705へ請求先コード単位に各データが格納されるテーブルである。今回締開始日702、今回締終了日703、翌回締開始日704、翌回締終了日705は請求締処理にて、取引先締制御テーブル312のデータを元に更新される。
図8は、入金テーブル314のデータ構成の例を示す図である。入金テーブル314は入金伝票を一意に識別するための入金伝票番号801をテーブルのキー項目とし、金額802、消込金額803、伝票日付804、決済先コード805へ各データが格納されるテーブルである。入金テーブル314は入金入力、入金振替入力、及びFB(ファームバンキング)自動入金処理によってデータが登録・更新される。また、債権消込処理にて入金伝票と債権情報の引き当て処理を実施した際に、引き当てした金額にて消込金額803の金額が更新される。
図9は、売上テーブル315のデータ構成の例を示す図である。売上テーブル315は売上伝票を一意に識別するための売上伝票番号901をテーブルのキー項目とし、金額902、消込金額903、伝票日付904、請求先コード905、請求ID906、入金予定ID907へ各データが格納されるテーブルである。請求ID906は請求先毎、請求締日毎に設定される項目である。入金予定ID907は請求先、請求締日、入金予定日毎に設定される項目である。
尚、図9の例では、請求ID906のデータと入金予定ID907のデータが同一となっているが、同一である必要はなく、上で説明した識別が可能であれば異なってもよい。売上テーブル315は債権(売上)計上入力によってデータ登録・更新される。また、債権個別消込入力にて売上伝票の消込処理を実施した際に、消込した金額にて消込金額903の金額が更新される。
図10は、入金予定テーブル316のデータ構成の例を示す図である。入金予定テーブル316は入金予定ID1001をテーブルのキー項目とし、請求先の請求締日、入金予定日毎に入金予定データを管理し、請求先コード1002、入金予定日1003、入金予定額1004、消込金額1005へ各データが格納されるテーブルである。入金予定テーブル316は債権(売上)計上入力によってデータが登録・更新される。
例えば、債権(売上)計上入力にて図9に示した売上テーブル315の1レコード目の売上伝票番号0000000001の売上伝票を登録した場合、金額902が100であるから、入金予定テーブル316の1レコード目の入金予定額1004は100が設定される。その後、債権(売上)計上入力にて図9に示した売上テーブル315の2レコード目の売上伝票番号0000000002の売上伝票を登録した場合、金額902が300であるから、100に300を加算して、入金予定テーブル316の1レコード目の入金予定額1004は400に設定され、図10の例のとおりとなる。また、債権消込入力にて入金予定の消込処理を実施した際に、消込した金額にて消込金額1005の金額を更新する。
図11は、当月債権残高テーブル317のデータ構成の例を示す図である。当月債権残高テーブル317は請求先コード1101をテーブルのキー項目とし、請求先の当月の債権残高データを管理し、前月末残高1102、当月債権計上金額1103、当月入金決済金額1104、当月末残高1105へ各データが格納されるテーブルである。
前月末残高1102の金額と当月債権計上額1103の金額とを加算し、当月入金決済額1104の金額を減算した値が、当月末残高1105の金額となる。当月債権残高テーブル317は債権月次締処理にて残高データの繰越処理が実施され、データ更新される。また、債権(売上)計上入力、債権消込入力によってデータ更新される。
図12は、過去月債権残高テーブル318のデータ構成の例を示す図である。過去月債権残高テーブル318は月毎に請求先の債権残高を管理し、年度1201、月項番1202、請求先コード1203をテーブルのキー項目とし、請求先の当月の債権残高データを管理し、前月末残高1204、当月債権計上額1205、当月入金決済額1206、当月末残高1207へ各データが格納されるテーブルである。
例えば、年度1201が2013であり月項番1202が12のレコードにおいて、前月末残高1204の1000と当月債権計上額1205の200を加算し、当月入金決済額1206の500を減算した値が、当月末残高1207の700となる。そして、この700は、年度1201が2014であり月項番1202が1のレコードの前月末残高1204の金額となる。尚、図12に示した例では、請求先コード1203がA002やA003について、月項番1202が2などのレコードを省略してある。
過去月債権残高テーブル318は債権月次締処理にて残高データの退避処理が実施され、データ更新される。また、後述するWEB兼APサーバ102の残高更新プログラム212の実行によってデータが更新される。
図13は、請求残高テーブル319のデータ構成の例を示す図である。請求残高テーブル319は請求ID1301をテーブルのキー項目とし、請求先の請求締日毎に請求残高データを管理し、請求先コード1302、請求開始日付1303、請求終了日付1304、前月末残高1305、今回請求金額1306、今回入金決済金額1307、請求残高1308へ各データが格納されるテーブルである。請求残高テーブル319は請求締処理にて残高の繰越処理が実施され、データ更新される。
例えば、請求ID1301がA001-2140531のレコードにおいて、前月末残高1305の600と今回請求金額1306の100とを加算し、今回入金決済金額1307の200を減算した値が、請求残高1308の500となる。そして、この500は、請求ID1301がA001-20140630のレコードの前月末残高1305の金額となる。また、債権(売上)計上入力、債権消込入力によってデータが更新される。
図14は、債権消込テーブル320のデータ構成の例を示す図である。債権消込テーブル320は債権消込伝票を一意に識別するための債権消込伝票番号1401をテーブルのキー項目とし、入金伝票と入金予定の引き当て情報を管理し、金額1402、消込金額1403、伝票日付1404、入金伝票番号1405、入金予定ID1406へ各データが格納されるテーブルである。伝票日付1404は債権消込伝票の日付であり、1つの入金伝票に対して複数の債権消込伝票があってもよい。債権消込テーブル320は債権消込入力によってデータ登録・更新される。
図15は、入金業務カレンダーテーブル321のデータ構成の例を示す図である。入金業務カレンダーテーブル321は年度1501、月項番1502、入金業務可能日1503の情報が格納されるテーブルであり、対象年月毎に複数の入金業務可能日を設定することが可能である。
図16は債権消込処理を実行するか否かの確認を行うための債権消込処理確認画面の例を示す図である。この債権消込処理確認画面322は、クライアント104に表示される画面であり、図17を用いて説明する債権消込入力処理の中で使用される。
図17は債権消込入力処理のフローチャートの例を示す図である。ユーザがクライアント104で消込対象の入金伝票番号を入力すると、WEB兼APサーバ102は入力された入金伝票番号を取得してDBサーバ103へ入金テーブル314の検索を指示し、DBサーバ103は指示された入金伝票番号をキーとして、入金伝票番号801に基づき入金テーブル314を検索し、金額802、消込金額803、伝票日付804、決済先コード805を取得し、WEB兼APサーバ102へ通知する(S1701)。
次に、ユーザがクライアント104で請求先コードを入力すると、WEB兼APサーバ102は入力された請求先コードを取得してDBサーバ103へ入金予定テーブル316の検索を指示し、DBサーバ103は指示された請求先コードをキーとして、請求先コード1002に基づき入金予定テーブル316を検索し、入金予定ID1001、入金予定日1003、入金予定額1004、消込金額1005を取得し、WEB兼APサーバ102へ通知する(S1702)。
S1702で取得されて通知された入金予定データを、WEB兼APサーバ102はクライアント104へ通知し、クライアント104は通知された入金予定データを表示して入金予定データの中で今回消込対象のデータをユーザに選択させ、選択された入金予定データをクライアント104が取得する(S1703)。次に、ユーザが債権消込伝票情報として、金額、伝票日付を入力し、クライアント104がそれらの入力された情報を取得する(S1704)。
ユーザがクライアント104の図示を省略した登録ボタンを押下すると、クライアント104はWEB兼APサーバ102へS1703とS1704で取得した情報とともに登録チェック処理の実行指示を出す(S1705)。そして、WEB兼APサーバ102は登録のチェック処理として取引入力可能期間判定プログラム211(S1706)を実行する。取引入力可能期間判定プログラム211の実行において、S1704で入力された伝票日付が登録可能な日付であるか否かを判定する(S1707)。
S1707にて登録可能な日付と判定された場合、図16に示した債権消込処理確認画面322の表示をWEB兼APサーバ102はクライアント104へ指示し、クライアント104は債権消込処理確認画面322を表示することにより、ユーザに債権消込処理を実行するか否かの確認を行う(S1708)。債権消込処理確認画面322にて、「はい」のボタンが押下されたか否かを判定する(S1709)。ここで、クライアント104が判定して判定結果をWEB兼APサーバ102へ通知してもよいし、クライアント104が押下の情報をWEB兼APサーバ102へ通知してWEB兼APサーバ102が判定してもよい。
「はい」のボタンが押下されたと判定した場合、WEB兼APサーバ102はS1701で取得した入金伝票番号をキーとして、S1704で取得した金額にて入金伝票テーブル314の消込金額803を更新する(S1710)。同様に、S1702で取得した入金予定IDをキーとして、S1704で入力された金額にて入金予定テーブル316の消込金額1005を更新する(S1711)。次に、債権消込伝票を一意に識別する債権消込伝票番号を自動採番する(S1712)。
WEB兼APサーバ102の指示により、DBサーバ103にて、S1701で取得した入金伝票番号、S1702で取得した入金予定ID、S1704で取得した金額、伝票日付、及びS1712で採番した債権消込伝票番号が、債権消込テーブル320の入金伝票番号1405、入金予定ID1406、金額1402、伝票日付1403の値として登録される(S1713)。尚、債権消込テーブル320の消込金額1403の初期値は0が設定される。そして、WEB兼APサーバ102は残高更新プログラム212(S1714)を実行し、債権消込入力処理を終了する。
取引入力可能期間判定プログラム211(S1706)の詳細について、図18、図19、図20に基づいて説明する。
図18は債権月次締済月情報内部テーブル213のデータ構成の例を示す図である。債権月次締済月情報内部テーブル213は、図20を用いて後で説明する取引入力可能期間判定処理フローチャートのS2001で取得した結果が格納されるWEB兼APサーバ102の内部テーブルである。債権月次締済月情報内部テーブル213は年度1801、月項番1802、当月開始日付1803、当月終了日付1804、債権締区分1805の各データが格納される。
図19は債権月次未締月情報内部テーブル214のデータ構成の例を示す図である。債権月次未締月情報内部テーブル214は、図20を用いて後で説明する取引入力可能期間判定処理フローチャートのS2002で取得した結果が格納されるWEB兼APサーバ102の内部テーブルである。債権月次未締月情報内部テーブル214は年度1901、月項番1902、当月開始日付1903、当月終了日付1904、会計締区分1905の各データが格納される。
図20に示す取引入力可能期間判定処理のフローチャートの例を用いて、取引入力可能期間プログラム211に基づく動作を説明する。
まず、WEB兼APサーバ102はDBサーバ103へ指示し、締制御テーブル311より債権締区分506が「1」(締済)のレコードの中で、年度501と月項番502を結合した値が最大値すなわち最後の年月となるレコードを取得し、取得した結果を債権月次締済月情報内部テーブル213へ格納する(S2001)。例えば、締制御テーブル311に図5に示すレコードが格納されている場合、上から3レコード目のデータが取得される。
次に、WEB兼APサーバ102はDBサーバ103へ指示し、締制御テーブル311より会計締区分505が「0」(未締)のレコードの中で、年度501、月項番502を結合した値が最小値すなわち最初の年月となるレコードを取得し、取得した結果を債権月次未締月情報内部テーブル214へ格納する(S2002)。例えば、締制御テーブル311に図5に示すレコードが格納されている場合、上から4レコード目のデータが取得される。
WEB兼APサーバ102は、S1704で取得した伝票日付が債権月次締済月への伝票登録であるか判定を行う(S2003)。S1704で取得した伝票日付がS2001で取得した債権月次締済月情報内部テーブル213の当月開始日付1803より小さい日付(年月日が前)、且つS2002で取得した債権月次未締月情報内部テーブル214の当月開始日付1903以上の日付、且つS2002で取得した債権月次未締月情報内部テーブル214の当月終了日付1904以下の日付であるか判定し、この条件を満たす場合は債権月次締済月への伝票登録とみなす。
この条件を満たさない場合、債権月次締済月への伝票登録でなはいとみなし、エラーなしとして取引入力可能期間判定の処理を終了する。WEB兼APサーバ102は、S2003で債権月次締済月への伝票登録と判定された場合、S2004を実行する直前の日付を処理日付として取得し、処理日付が入金業務可能日であるか判定を行う(S2004)。処理日付は債権消込入力処理を実施している日付のことを示し、例えばWEB兼APサーバ102のコンピュータとしての時計から取得してもよいし、クライアント104から設定された日付を取得してもよい。
S2004の判定のためにWEB兼APサーバ102はDBサーバ103へ指示し、入金業務カレンダーテーブル321の年度1501の値がS2002で取得した債権月次未締月情報内部テーブル214の年度1901の値と等しく、且つ月項番1502の値がS2002で取得した債権月次未締月情報内部テーブル214の月項番1902の値と等しく、且つ入金業務可能日1503の値が処理日付と等しいレコードを検索する。該当するレコードの検索結果が1件以上取得できた場合、処理日付は入金業務可能日であるとする。該当するレコードの検索結果が取得できなかった場合、処理日付は入金業務可能日ではないとし、エラーありとして取引入力可能期間判定の処理を終了する。
S2004で入金業務可能日であると判定された場合、S1704で取得した伝票日付が会計月次締済月への伝票登録であるかの判定を行う(S2005)。WEB兼APサーバ102はDBサーバ103へ指示し、締制御テーブル311の当月開始日付503がS1704で取得した伝票日付以下の日付、且つ当月終了日付504がS1704で取得した伝票日付以上の日付、且つ会計締区分505が「0」(未締)のレコードを検索する。
該当するレコードの検索結果が1件以上取得できた場合、会計月次未締期間への伝票登録とみなし、エラーなしとして取引入力可能期間判定の処理を終了する。また、該当するレコードの検索結果が取得できなかった場合、会計月次未締期間への伝票登録ではないとみなし、エラーありとして取引入力可能期間判定の処理を終了する。
残高更新プログラム212(S1714)の詳細について、図21、図22、図23、図24、図25、図26、図27に基づいて説明する。
図21は前月債権残高情報内部テーブル215のデータ構成の例を示す図である。前月債権残高情報内部テーブル215は、図24を用いて後で説明する残高更新処理フローチャートのS2406で取得した結果が格納されるWEB兼APサーバ102の内部テーブルである。前月債権残高情報内部テーブル215は年度2101、月項番2102、請求先コード2103、前月末残高2104、当月債権計上額2105、当月入金決済額2106、当月末残高2107の各データが格納される。
図22は当月債権残高情報内部テーブル216のデータ構成の例を示す図である。当月債権残高情報内部テーブル216は図24を用いて後で説明する残高更新処理フローチャートのS2403、及びS2407で取得した結果が格納されるWEB兼APサーバ102の内部テーブルである。当月債権残高情報内部テーブル216は請求先コード2201、前月末残高2202、当月債権計上額2203、当月入金決済額2204、当月末残高2205へ各データが格納される。
図23は請求残高情報内部テーブル217のデータ構成の例を示す図である。請求残高情報内部テーブル217は図24を用いて後で説明する残高更新処理フローチャートのS2410で取得した結果が格納されるWEB兼APサーバ102の内部テーブルである。請求残高情報内部テーブル217は請求ID2301、請求先コード2302、請求開始日付2303、請求終了日付2304、前月末残高2305、今回請求金額2306、今回入金決済金額2307、請求残高2308へ各データが格納される。
図24に示す残高更新処理のフローチャートの例を用いて、残高更新プログラム212に基づく動作を説明する。まず、更新時点での債権締期間情報を取得するために、WEB兼APサーバ102はDBサーバ103へ指示し、締制御テーブル311の債権締区分506が「0」(未締)で年度501、月項番502を結合した値が最小値となるレコードを取得し、取得した結果を債権月次未締月情報内部テーブル214へ格納する(S2401)。例えば、締制御テーブル311に図5に示すレコードが格納されている場合、上から4レコード目のデータが取得される。
WEB兼APサーバ102は、S1704で取得した伝票日付が債権月次締済月への伝票登録であるか判定を行う(S2402)。S1704で取得した伝票日付がS2401で取得した債権月次未締月情報内部テーブル214の当月開始日付1903より小さい日付であるか判定し、条件を満たす場合、締済月への債権残高更新があるとしてS2405へ処理を進める。これに対し、条件を満たさない場合、締済月への債権残高更新がないとしてS2403へ処理を進める。
次に、締済月への債権残高更新がない場合の処理について説明する。締済月への債権残高更新がないため、更新対象の債権残高は当月債権残高テーブル317のみとなる。まず、更新対象となる当月債権残高を取得するために、WEB兼APサーバ102はDBサーバ103へ指示し、S1702で取得した入金予定IDに紐付く請求項コード(入金予定テーブル316において入金予定ID1001の値と同じレコードの請求先コード1002の値)が、請求先コード1101の値と等しいレコードを、当月債権残高テーブル317から取得し、当月残高情報内部テーブル216へ格納する(S2403)。
そして、S2403で取得した結果とS1704で取得した金額の情報をもとに、当月債権残高テーブル317を更新する(S2404)。具体的には、当月債権残高テーブル317の請求先コード1101の値がS2403で取得した当月残高情報内部テーブル216の請求先コード2201の値と等しいレコードを更新対象のレコードとし、WEB兼APサーバ102はDBサーバ103へ指示し、S2403で格納した当月残高情報内部テーブル216の当月入金決済額2204にS1704で取得した金額を加算した値にて当月入金決済額1104を更新し、S2403で格納した当月残高情報内部テーブル216の当月末残高2205からS1704で取得した金額を減算した値にて当月末残高1105を更新する。尚、当月残高情報内部テーブル216の中で加算と減算をして、その算出結果を当月債権残高テーブル317へ格納してもよい。
図25にS2403からS2404の処理による当月債権残高テーブル317の更新の例を示す。請求先コードのA001のレコードについて、当月入金決済額1104の300を600に更新し、当月末残高1105の600を300に更新する。
次に、締済月への債権残高更新がある場合の債権残高更新処理S2405からS2409の処理について説明する。これらの処理では、締済月への債権残高更新があるため、更新対象の債権残高は過去月債権残高テーブル318、当月債権残高テーブル317となる。
まず、WEB兼APサーバ102はDBサーバ103へ指示し、更新対象となる前月の債権締期間情報を取得するために、締制御テーブル311より債権締区分506が「1」(締済)で年度501、月項番502を結合した値が最大値となるレコードを取得し、取得した結果を債権月次締済月情報内部テーブル213へ格納する(S2405)。例えば、締制御テーブル311に図5に示すレコードが格納されている場合、上から3レコード目のデータが取得される。
更新対象となる前月債権残高を取得するために、WEB兼APサーバ102はDBサーバ103へ指示し、過去月債権残高テーブル318において、請求先コード1203の値がS1702で取得した入金予定IDに紐付く請求先コード(入金予定テーブルの請求先コード1002)の値と等しく、且つ年度1201の値がS2405で取得した債権月次締済月情報内部テーブル213の年度1801の値と等しく、且つ月項番1202の値がS2405で取得した債権月次締済月情報内部テーブル213の月項番1802の値と等しいレコードを取得し、前月残高情報内部テーブル215へ格納する(S2406)。
更新対象となる当月債権残高を取得するために、WEB兼APサーバ102はDBサーバ103へ指示し、当月債権残高テーブル317において、請求先コード1101の値がS1702で取得した入金予定IDに紐付く請求先コード(入金予定テーブルの請求先コード1002)の値と等しいレコードを取得し、当月残高情報内部テーブル216へ格納する(S2407)。
S2406で格納した結果とS1704で取得した金額の情報をもとに、過去月債権残高テーブル318を更新する(S2408)。具体的には、WEB兼APサーバ102はDBサーバ103へ指示し、過去月債権残高テーブル318の請求先コード1203の値がS2405で格納した前月残高情報内部テーブル215の請求先コード2103の値と等しく、且つ年度1201の値がS2405で格納した前月残高情報内部テーブル215の年度2101の値と等しく、且つ月項番1202の値がS2405で格納した前月残高情報内部テーブル215の月項番2102の値と等しいレコードを更新対象のレコードとし、S2406で格納した前月残高情報内部テーブル215の当月入金決済額2106の値にS1704で取得した金額を加算した値にて当月入金決済額1206を更新し、S2406で格納した前月残高情報内部テーブル215の当月末残高2107の値からS1704で取得した金額を減算した値にて当月末残高1207を更新する。
S2407で取得した結果とS1704で取得した金額をもとに、当月債権残高テーブル317を更新する(S2409)。具体的には、WEB兼APサーバ102はDBサーバ103へ指示し、当月債権残高テーブル317の請求先コード1101がS2407で格納した当月残高情報内部テーブル216の請求先コード2201と等しいレコードを更新対象のレコードとし、S2407で格納した当月残高情報内部テーブル216の前月末残高2202からS1704で取得した金額を減算した値にて前月末残高1102を更新し、S2407で格納した当月残高情報内部テーブル216の当月末残高2205からS1704で取得した金額を減算した値にて当月末残高1105を更新する。
図26にS2406からS2409の処理による過去月債権残高テーブル318と当月債権残高テーブル317の更新の例を示す。請求先コードがA001の年度が2014で月項番が2のレコードについて、当月入金決済額1206の200を500に更新し、当月末残高1207の500を200に更新する。また、請求先コードがA001のレコードについて、前月末残高1102の500を200に更新し、当月末残高1105の600を300に更新する。
次に、更新対象の請求残高を取得する。尚、請求残高は請求先の締日毎に一つのテーブルにデータを保持しているため、前月債権残高の更新有無に関わらず、同じ更新の処理であるS2410からS2414にて実現する。WEB兼APサーバ102はDBサーバ103へ指示し、請求先コード1302がS1702で取得した入金予定IDに紐付く請求先コード(入金予定テーブルの請求先コード1002)と等しく、且つ請求終了日付1304がS1704で取得した伝票日付以上の日付のレコードを請求残高テーブル319から取得し、WEB兼APサーバ102は取得した情報を請求IDで昇順にソートして、請求残高情報内部テーブル217へ格納する(S2410)。
WEB兼APサーバ102は、S2410で取得した請求残高情報内部テーブル217を1件ずつ読込み(S2411)、S1704で取得した金額をもとに請求残高テーブル319を更新する。この請求残高テーブル319の更新は、取引日対象残高の更新処理(S2413)と、それ以降の請求日付のレコードの残高繰越の更新処理(S2414)とで異なる。このために、WEB兼APサーバ102は、S2411で読込んだ請求残高情報内部テーブル217のレコードが1レコード目であるか否かを判定し、1レコード目である場合はS2413へ遷移し、それ以外の場合S2414へ遷移する(S2412)。
S2413でWEB兼APサーバ102はDBサーバ103へ指示し、請求残高テーブル319の請求ID1301の値がS2411で読込んだ請求残高情報内部テーブル217の請求ID2301の値と等しいレコードを更新対象のレコードとし、S2411で読込んだ請求残高情報内部テーブル217の今回入金決済金額2307の値とS1704で取得した金額を加算した値にて今回入金決済金額1307を更新し、S2411で読込んだ請求残高情報内部テーブル217の請求残高2308の値からS1704で取得した金額を減算した値にて請求残高1308を更新する。
S2414でWEB兼APサーバ102はDBサーバ103へ指示し、請求残高テーブル319の請求ID1301の値がS2411で読込んだ請求残高情報内部テーブル217の請求ID2301と等しいレコードを更新対象のレコードとし、S2411で読込んだ請求残高情報内部テーブル217の前月末残高2307の値とS1704で取得した金額を加算した値にて前月末残高1305を更新し、S2411で読込んだ請求残高情報内部テーブル217の請求残高2308の値からS1704で取得した金額を減算した値にて請求残高1308を更新する。
WEB兼APサーバ102は、S2411のループで、全てのレコードの処理が完了したら、残高更新プログラム212の処理を終了する。
図27にS2410からS2414の処理による請求残高テーブル319の更新の例を示す。請求項IDがA001-20140531のレコードについて、今回入金決済金額1307の200を500に更新して、請求残高1308の500を200に更新し、請求項IDがA001-20140630の前月末残高1305の500を200に更新して、請求残高1308の600を300に更新する。
以上で説明したように、債権月次締処理後も会計締区分が未締の期間において、締済月に対する入金業務を可能となり、締済期間の債権関連の残高を取引に合わせた更新が可能となる。また、次の月初めが会計の締めでない場合、前月の処理を持ち越すことができ、翌月に処理を分散できるため、月末入金業務の負荷軽減が可能となる。更に、債権月次締処理後に発覚した入金業務のミスオペレーションの訂正が可能となり、債権システムのデータと実際の取引の状態が乖離する可能性を低減できる。
101 ネットワーク
102 WEB兼APサーバ
103 DBサーバ
104 クライアント
311 締制御テーブル
317 当月債権残高テーブル
318 過去月債権残高テーブル
319 請求残高テーブル
321 入金業務カレンダーテーブル

Claims (6)

  1. 入金伝票の日付と金額と請求先が入力される債権管理システムにおいて、
    前記入金伝票の日付と金額と請求先が入力されるクライアントと、
    会計締区分の情報と債権締区分の情報とを年月毎に記憶する締制御テーブルと、年月毎に入金業務可能日を記憶する入金業務カレンダーテーブルとを有するデータベースサーバと、
    前記クライアントから前記入力された入金伝票の日付を受信し、前記データベースサーバへ指示し、前記入力された入金伝票の日付が前記債権締区分の情報として締状態を示して前記会計締区分の情報として未締状態を示すことを判定し、前記入力された入金伝票の日付が前記入金業務可能日であることを判定し、前記入力された入金伝票の金額で残高更新処理を実行するアプリケーションサーバと
    を有することを特徴とする債権管理システム。
  2. 前記アプリケーションサーバは、
    前記入力された入金伝票の日付が前記債権締区分の情報として締状態を示して前記会計締区分の情報として未締状態を示すことを判定し、前記入力された入金伝票の日付が前記入金業務可能日であることを判定した後、
    更に、前記残高更新処理の実行の確認画面の表示を前記クライアントへ指示し、前記クライアントでの入力に基づき、前記残高更新処理を実行すること
    を特徴とする請求項1に記載の債権管理システム。
  3. 前記データベースサーバは、
    前月末残高と当月入金決済額と当月末残高とを請求先毎に記憶する当月債権残高テーブルを更に有し、
    前記アプリケーションサーバは、
    前記残高更新処理として、前記データベースサーバへ指示し、
    更に、前記入力された入金伝票の日付が前記債権締区分の情報として未締状態を示すことを判定し、前記入力された入金伝票の金額で前記入力された入金伝票の請求先に対する前記当月入金決済額と前記当月末残高を更新すること
    を特徴とする請求項2に記載の債権管理システム。
  4. 前記データベースサーバは、
    当月入金決済額と当月末残高とを、年月と請求先毎に、記憶する過去月債権残高テーブルを更に有し、
    前記アプリケーションサーバは、
    前記残高更新処理として、前記データベースサーバへ指示し、
    更に、前記入力された入金伝票の日付が前記債権締区分の情報として締状態を示すことを判定し、前記締制御テーブルの中で前記債権締区分の情報として締状態を示す最後の年月を特定し、前記入力された入金伝票の金額で、前記特定した年月と前記入力された入金伝票の請求先に対する前記当月入金決済額と前記当月末残高とを更新し、前記入力された入金伝票の金額で前記入力された入金伝票の請求先に対する前記前月末残高と前記当月末残高を更新すること
    を特徴とする請求項3に記載の債権管理システム。
  5. 前記データベースサーバは、
    前月末残高と今回入金決済金額と請求残高とを請求先毎に記憶する請求残高テーブルを更に有し、
    前記アプリケーションサーバは、
    前記残高更新処理として、前記データベースサーバへ指示し、
    更に、前記入力された入金伝票の金額で、前記入力された入金伝票の請求先に対する前記前月末残高と前記今回入金決済金額と前記請求残高を更新すること
    を特徴とする請求項4に記載の債権管理システム。
  6. 入金伝票の日付と金額と請求先が入力され、会計締区分の情報と債権締区分の情報とを年月毎に記憶する締制御テーブルと、年月毎に入金業務可能日を記憶する入金業務カレンダーテーブルとを有する債権管理システムの制御方法にであって、
    前記入金伝票の日付と金額と請求先が入力され、
    前記入力された入金伝票の日付が前記債権締区分の情報として締状態を示して前記会計締区分の情報として未締状態を示すことを判定し、
    前記入力された入金伝票の日付が前記入金業務可能日であることを判定し、
    前記入力された入金伝票の金額で残高更新処理すること
    を特徴とする債権管理システムの制御方法。
JP2015029770A 2015-02-18 2015-02-18 債権管理システム及びその制御方法 Pending JP2016151943A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2015029770A JP2016151943A (ja) 2015-02-18 2015-02-18 債権管理システム及びその制御方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2015029770A JP2016151943A (ja) 2015-02-18 2015-02-18 債権管理システム及びその制御方法

Publications (1)

Publication Number Publication Date
JP2016151943A true JP2016151943A (ja) 2016-08-22

Family

ID=56696587

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015029770A Pending JP2016151943A (ja) 2015-02-18 2015-02-18 債権管理システム及びその制御方法

Country Status (1)

Country Link
JP (1) JP2016151943A (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111192120A (zh) * 2019-12-02 2020-05-22 泰康保险集团股份有限公司 养老社区费用管理方法、系统、设备及存储介质
JP2022020840A (ja) * 2017-12-19 2022-02-01 株式会社オービック 債権遡及修正処理装置、債権遡及修正処理方法および債権遡及修正処理プログラム

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022020840A (ja) * 2017-12-19 2022-02-01 株式会社オービック 債権遡及修正処理装置、債権遡及修正処理方法および債権遡及修正処理プログラム
JP7316342B2 (ja) 2017-12-19 2023-07-27 株式会社オービック 債権遡及修正処理装置、債権遡及修正処理方法および債権遡及修正処理プログラム
CN111192120A (zh) * 2019-12-02 2020-05-22 泰康保险集团股份有限公司 养老社区费用管理方法、系统、设备及存储介质
CN111192120B (zh) * 2019-12-02 2023-09-15 泰康保险集团股份有限公司 养老社区费用管理方法、系统、设备及存储介质

Similar Documents

Publication Publication Date Title
US7945489B2 (en) Flexible cost and revenue allocation for service orders
JP2020509483A (ja) 一時労働者を管理するためのシステムおよびインターフェース
US20240062258A1 (en) Computer storage system and method for a plurality of timekeeping entries
US10204380B1 (en) Categorically inductive taxonomy system, program product and method
JP6596563B1 (ja) 決済装置、決済方法、及びプログラム、並びに決済システム
US8352358B2 (en) Bankruptcy evaluation service and system
JP2014093041A (ja) 遺産管理プログラムおよび遺産管理システム
WO2020121521A1 (ja) 決済管理システムおよび決済管理方法
JP2016151943A (ja) 債権管理システム及びその制御方法
JP2015207142A (ja) 入金処理装置、入金処理方法及び入金処理プログラム
JP6815015B1 (ja) 請求消込方法及び請求消込プログラム
US20120116904A1 (en) Method and system for paying taxes
JP5862144B2 (ja) サーバ装置、およびプログラム
JP4588891B2 (ja) 決済管理システム、決済管理方法、決済管理プログラムを記録した記録媒体及び決済管理プログラム
US20120011039A1 (en) System and method for services management
JP2017151673A (ja) 情報処理装置、制御方法、プログラム
JP6826920B2 (ja) サーバ装置、電子記録債権検索方法、及びプログラム
JP6058620B2 (ja) 融資取引の自動実行システムおよび方法
JP2016053931A (ja) 監査対象特定支援プログラム、監査対象特定支援方法および監査支援装置
JP6394204B2 (ja) 会計データ監査支援プログラム、会計データ監査支援方法および監査支援装置
JP5758948B2 (ja) 電子記録債権の流動化管理システム
JP2006309321A (ja) 入金照合装置、プログラムおよび記録媒体
JP5416852B1 (ja) 法人営業支援システム、法人営業支援方法、及びプログラム
US20120010892A1 (en) System and method for handling complex calculations in social services
JP2014186619A (ja) キャッシュフロー管理システム及びキャッシュフロー管理方法