本発明の実施形態を図面に基づいて詳細に説明する。なお、本発明は本実施形態により限定されるものではない。
[1.概要]
従来、システム上に前受金残高として登録する場合、入金時に予め「前受入金」としてデータ投入を実施する例が一般的である。しかしながら、実際の入金業務においては前受分だけが単独で支払われるとは限らず、通常の債権が存在する場合は合算されて支払われる。その際に前受入金予定の確認や振分といった経理処理は非常に煩雑なものとなる。
そこで、本実施の形態では、入金結果に対して売掛金と突合する業務(入金消込)はどの場合においても実施されることに着目した。本実施の形態では、前受予定(前請求)に対して通常債権と同様に入金消込が実施される事で、前受金管理の対象とするように前受金への振替及び残高管理を行う仕組みを構築している。
他方、工事など費用発生から売上計上に至るまでに長期間を要したり、あるいは高額な費用負担が発生するような業界・業態において、役務を提供するための資金が問題となる。その為に「着手金」「中間金」といった名目で前請求を行い、前受金(以下工事業の場合は未成工事受入金)として管理を行う。特定役務(プロジェクト)に対する前受金はその役務に対して計上される売上高に対して充当したいというニーズもあれば、不特定の役務に対して自由に充当したいというニーズもある。
どちらかの方法に対して対応したケースはあったとしても、複合業態や取引慣例上このニーズが企業内に混在してしまう場合があった。例えばプロジェクトに対する前受金であっても、複数プロジェクトが同時進行している請求先などにおいては、複数プロジェクト分の合算金額で前受金が入金され、売上計上が早いものから順に充当していくような取引習慣であったり、請求先によっては予算の都合上期末にある程度前払いをして留保しておきたいといったこともある。
そこで、本実施の形態では、プロジェクト単位での前受金管理及び売上高への充当と、請求先単位での前受金管理と充当のどちらのケースにも対応させつつ、自由充当させてよい前受金はプロジェクトの売上高に対しても充当させる事を可能とした。
具体的には、本実施の形態では、(1)前受請求に対する入金消込(仮受金等の充当)において、前受金の発生管理を行い、(2)売上時、売上高に対して充当可能とする前受残高の集計方法を変動させ、適切な充当振当を可能としている。
[2.構成]
本実施形態に係る前受金管理装置の構成の一例について、図1を参照して説明する。図1は、前受金管理装置の構成の一例を示すブロック図である。
前受金管理装置100は、例えば、市販のデスクトップ型パーソナルコンピュータである。なお、前受金管理装置100は、デスクトップ型パーソナルコンピュータのような据置型情報処理装置に限らず、市販されているノート型パーソナルコンピュータ、PDA(Personal Digital Assistants)、スマートフォン、タブレット型パーソナルコンピュータなどの携帯型情報処理装置であってもよい。
前受金管理装置100は、制御部102と通信インターフェース部104と記憶部106と入出力インターフェース部108と、を備えている。前受金管理装置100が備えている各部は、任意の通信路を介して通信可能に接続されている。
通信インターフェース部104は、ルータ等の通信装置及び専用線等の有線又は無線の通信回線を介して、前受金管理装置100をネットワーク300に通信可能に接続する。通信インターフェース部104は、他の装置と通信回線を介してデータを通信する機能を有する。ここで、ネットワーク300は、前受金管理装置100とサーバ200とを相互に通信可能に接続する機能を有し、例えばインターネットやLAN(Local Area Network)等である。
入出力インターフェース部108には、入力装置112及び出力装置114が接続されている。出力装置114には、モニタ(家庭用テレビを含む)の他、スピーカやプリンタを用いることができる。入力装置112には、キーボード、マウス、及びマイクの他、マウスと協働してポインティングデバイス機能を実現するモニタを用いることができる。なお、以下では、出力装置114をモニタ114または画面114とし、入力装置112をキーボード112またはマウス112として記載する場合がある。
記憶部106には、OS(Operating System)と協働してCPU(Central Processing Unit)に命令を与えて各種処理を行うためのコンピュータプログラムが記録される。記憶部106として、例えば、RAM(Random Access Memory)・ROM(Read Only Memory)等のメモリ装置、ハードディスクのような固定ディスク装置、フレキシブルディスク、及び光ディスク等を用いることができる。
記憶部106には、科目区分マスタ106a、取引区分マスタ106b、費目マスタ106c、請求先マスタ106d、データファイル106e等が格納される。図2は、科目区分マスタ106aの構成例を示す図である。図3は、取引区分マスタ106bの構成例を示す図である。図4は、費目マスタ106cの構成例を示す図である。図5は、請求先マスタ106dの構成例を示す図である。これらの科目区分マスタ106a、取引区分マスタ106b、費目マスタ106c、及び請求先マスタ106dは、制御部102が入力画面を表示する場合に参照され、オペレータが入力した項目に対応する項目が読み出されて表示される。
科目区分マスタ106aは、図2に示すように、科目区分と科目分類のデータを関連づけて登録するテーブル等で構成することができる。科目区分マスタ106aは、科目区分をキーとして科目分類が読み出されて各種画面に表示される。
取引区分マスタ106bは、図3に示すように、伝票種別、取引区分、借方勘定科目、及び貸方勘定科目のデータを関連づけて登録するテーブル等で構成することができる。
費目マスタ106cは、図4に示すように、費目CD、費目名、及び前受科目区分のデータを関連づけて登録するテーブル等で構成することができる。
請求先マスタ106dは、店舗コード、店舗名、回収月、及び回収日のデータを関連づけて登録したテーブル等で構成することができる。
データファイル106eは、請求データ、回収予定データ、入金データ、入金消込データ、前受明細データ、売上データ、及び受注データ等の各種データを格納するためのものである。
請求データは、伝票番号、伝票種、取引区分、行番号、部門、請求先、請求金額、プロジェクトNOを含んでいてもよい。回収予定データは、回収SEQ、伝票種、取引区分、伝票番号、行番号、部門、請求先、費目、請求番号、回収予定金額、消込済金額、消込完了、債権科目区分、プロジェクトNO、売上時前振当FLGのデータを含んでいてもよい。
入金データは、入金番号、行番号、入金日、部門、請求先、取引区分、入金金額、消込済金額、消込完了、前受相殺入金番号・連番のデータを含んでいてもよい。入金消込データは、入金消込番号、行番号、入金消込日、回収SEQ、今回消込金額、入金番号を含んでいてもよい。
前受明細データは、入金番号、前受入金連番、請求先、債権科目区分、プロジェクトNO、前受金額、前受振当済金額、振当完了のデータを含んでいてもよい。売上データは、売上番号、行、売上日、部門、請求先、商品、売上数、売上金額、債権科目区分、プロジェクトNOを含んでいてもよい。受注データは、受注番号、行、受注日、部門、請求先、商品、売上数、売上金額、債権科目区分、プロジェクトNOのデータを含んでいてもよい。
制御部102は、前受金管理装置100を統括的に制御するCPU等である。制御部102は、OS等の制御プログラム・各種の処理手順等を規定したプログラム・所要データなどを格納するための内部メモリを有し、格納されているこれらのプログラムに基づいて種々の情報処理を実行する。制御部102は、機能概念的に、入金消込処理部102aと、前受明細作成部102bと、前受金売上振当部102cと、マスタメンテ部102fと、を備えている。
入金消込処理部102aは、入金金額と前請求に係る請求の回収予定額との消込を行う。前請求に係る請求は、プロジェクトに紐付く前請求と、プロジェクトに紐付かない前請求を含むことにしてもよい。
前受明細作成部102bは、消込後、前請求に係る請求の前受明細を作成して、前受明細をデータファイル106eに格納する。
前受金売上振当部102cは、売上に対して前受明細のうち振当可能なものを振り当てる。前受金売上振当部102cは、前受明細のうち、売上の請求先と一致し、かつ、売上がプロジェクトに紐付くものである場合は、プロジェクトが同一又はプロジェクトに紐付かないのもので未振当のものを振り当て、売上がプロジェクトに紐付かないものである場合は、プロジェクトに紐付かないのもので未振当のものを振り当てることにしてもよい。
マスタメンテ部102dは、オペレータの指示に応じてマスタメンテ画面(不図示)をモニタ114に表示し、当該マスタメンテ画面上でのオペレータの操作に応じて、科目区分マスタ106a、取引区分マスタ106b、費目マスタ106c、及び請求先マスタ106dのデータの入力・変更・追加等の編集を行う。
[3.処理の具体例]
図1〜図19を参照して、本実施の形態における前受金管理装置100の制御部102の処理の具体例を説明する。まず、図1及び図6を参照して、本実施の形態における前受金管理装置100の制御部102の処理の要部を説明する。図6は、本実施の形態における前受金管理装置100の制御部102の処理の要部を説明するためのフローチャートである。
入金消込処理部102aは、入金消込処理を実行する(ステップS1)。入金消込処理では、入金金額と前請求に係る請求の回収予定額との消込を行う。前請求に係る請求は、プロジェクトに紐付く前請求と、プロジェクトに紐付かない前請求を含むことにしてもよい。
前受明細作成部102bは、前受明細作成処理を実行する(ステップS2)。前受明細作成処理では、消込後、前請求に係る請求の前受明細を作成して、作成した前受明細をデータファイル106eに格納する。
前受金売上振当部102cは、前受金売上振当処理を実行する(ステップS3)。前受金売上振当処理では、売上に対して前受明細のうち振当可能なものを振り当てる。前受金売上振当処理では、さらに、前受明細のうち、売上の請求先と一致し、かつ、売上がプロジェクトに紐付くものである場合は、プロジェクトが同一又はプロジェクトに紐付かないのもので未振当のものを振り当て、売上がプロジェクトに紐付かないものである場合は、プロジェクトに紐付かないのもので未振当のものを振り当てることにしてもよい。
図7〜図19を参照して、本実施の形態における前受金管理装置100の制御部102の処理の具体例を説明する。
図7〜図9は、プロジェクトに紐付く案件の前受金発生までを説明するための図である。
図7において、PJ情報基本入力により、プロジェクト基本情報データを入力してデータファイル106fに登録する。図7(A)は、プロジェクト基本情報データの一例を示す図である。図7(A)に示すプロジェクト基本情報データの例では、1行目が、プロジェクト名「新工事 B地区、空調工事」、請求先「SEI001:□△工業」となっている。2行目は、プロジェクトNO「PJ0002」、プロジェクト名「京橋〇×ビル 電設工事」、請求先「SEI002:〇△不動産」となっている。3行目は、プロジェクトNO「PJ0003」、プロジェクト名「日本橋◇◇ビル エアコン交換工事」、請求先「SEI002:〇△不動産」となっている。
以下では、プロジェクトNO「PJ0001」と「PJ0002」について、前受金を発生させる場合について説明する。
つぎに、請求入力では、図7(B)に示す請求情報入力画面で請求データ及び回収予定データを登録可能となっている。図7(B)に示す請求入力画面では、ヘッダーと請求明細が表示される。ヘッダーには、請求番号、請求日、部門、請求先、請求区分、プロジェクトNO、回収予定日の項目が表示される。請求番号は登録時に自動採番される。請求明細には、費目・商品、請求金額、債権科目区分の項目が表示される。費目CDを入力すると、費目マスタ106cから費目名と債権科目区分が読み出されて表示される。図7(B)に示す請求入力画面の例では、請求区分「2:前請求」とプロジェクトNO「PJ0001」が入力されている。
図7(B)の請求入力画面での入力操作により、例えば、図7(C)及び図7(D)に示す請求データ及び回収予定データが作成される。
図7(C)に示す請求データの例では、1行目が、伝票番号「SE001」、伝票種「請求」、取引区分「前請求」、行番号「1」、請求日「2018/04/01」、部門「BMN001:営業1部」、請求先「SEI001:□△工業」、請求金額「¥2,000,000」、プロジェクトNO「PJ0001」となっている。2行目は、伝票番号「SE002」、伝票種「請求」、取引区分「前請求」、行番号「1」、請求日「2018/04/01」、部門「BMN001:営業1部」、請求先「SEI002:〇△不動産」、請求金額「¥1,000,000」、プロジェクトNO「PJ0002」となっている。
図7(D)に示す回収予定データの例では、1行目は、回収SEQ「SQ01」、伝票種「請求」取引区分「前請求」、伝票番号「SE0001」、行番号「1」、回収予定日「2018/04/10」、部門「BMN001:営業1部」、請求先「SEI001:□△工業」、費目「HM001:着手金」、請求番号「SE0001」、回収予定金額「2,000,000」、消込済金額「0」、消込完了「未」、債権科目区分「未成工事受入金」、プロジェクトNO「PJ0001」、売上時前振当FLG「0」となっている。2行目は、回収SEQ「SQ02」、伝票種「請求」、取引区分「前請求」、伝票番号「SE0002」、行番号「1」、回収予定日「2018/04/08」、部門「BMN001:営業1部」、請求先「SEI002:〇△不動産」、費目「HM002:中間金」、請求番号「SE0002」、回収予定金額「¥1,000,000」、消込済金額「0」、消込完了「未」、債権科目区分「未成工事受入金」、プロジェクトNO「PJ0002」、売上時前振当FLG「0」となっている。この発生仕訳は、図7(E)に示すようになる。
入金入力によって、入金データを登録する。回収予定に対する消込によって、前受残高(前受明細データ)が作成される。
図7(F)に示す入金データの例では、1行目が、入金番号「NY0001」、行番号「1」、入金日「2018/4/10」、部門「BMN001:営業1部」、請求先「SEI001:□△工業」、取引区分「振込」、入金金額「¥2,000,000」、消込済金額「0」、消込完了「未」、前受相殺入金番号・連番「 」となっている。2行目は、入金番号「NY0002」、行番号「1」、入金日「2018/4/08」、部門「BMN001:営業1部」、請求先「SEI002:〇△不動産」、取引区分「振込」、入金金額「¥1,000,000」、消込済金額「0」、消込完了「未」、前受相殺入金番号・連番「 」となっている。
つぎに、入金消込が行われる。図8(A)は、入金消込画面の一例を示す図である。入金伝票部には、入金消込画面で指定される請求先の消込未完了(消込完了=未)を対象に入金データを抽出してセットされる。消込原資とする行を選択後、今回消込原資を入金額−消込済金額≧0になる範囲内で指定する(入金額−消込済金額が初期表示)。
消込候補には、入金消込画面で指定される請求先の消込未完了(消込完了=未)を対象に、回収予定データが抽出されてセットされる。
消込対象とする行を選択後、今回消込額を回収予定金額−消込済金額≧0になる範囲内で指定する(回収予定金額−消込済金額が初期表示)。今回の例は、入金全額を消込原資とし、回収予定に対する未消込全額を消し込んだものとする。入金消込番号は登録時に採番する。
入金消込画面で登録が行われると、図8(B)に示すような入金消込データが作成される。図8(B)に示す入金消込データの例では、入金消込番号「NY0001」、行番号「1」、入金消込日「2018/4/10」、回収SEQ「SQ01」、今回消込金額「¥2,000,000」、入金番号「NY0001」となっている。この発生仕訳は、借方が仮受金「¥2,000,000」、貸方が未成工事受入金「¥2,000,000」のようになる。
図8(D)に示すように、回収予定データの消込済金額は、入金消込に処理された消込金額「¥2,000,000」に更新され、「消込完了」の有無が「済」に更新される。
また、図8(E)に示すように、入金データの「消込済金額」が「¥2,000,000」に更新され、消込完了の有無が「済」に更新される。
消込候補の中から今回消込対象とした取引区分が「前請求」に該当する場合、さらに追加で前受明細データを生成する。前受明細データは、入金消込画面の画面情報、入金消込データ、回収予定データ、及び入金データの更新結果を用いて生成する。
図8(F)は、前受明細データの一例を示す図である。図8(F)に示す前受明細データの例では、入金番号「NY0001、前受入金連番「1」、請求先「SEI001:□△工業」、債権科目区分「未完成工事受入金」、プロジェクトNO「PJ0001」、前受金額「¥2,000,000」、前受振当済金額「0」、振当完了「未」となっている。
「前受金額」は、入金消込データの今回消込金額が設定される。「前受入金連番」は、1入金に対して複数の前請求に消込が行われた場合、SEQが加算されて明細が増えていく。今回は、消込対象が1件のみのため、1行しか生成されない。
図9は、プロジェクトPJ002の前受請求に対しても同様に処理した場合の例を説明するための図である。
図9(A)に示す入金消込画面では、請求先がSE0002:〇△不動産となっており、伝票部には、請求先「SE0002:〇△不動産」の消込未完了(消込完了=未)の入金データが抽出されてセットされる。同図に示す例では、入金番号「NY0002」の入金データがセットされる。また、消込候補は、請求先「SE0002:〇△不動産」の消込未完了(消込完了=未)の伝票番号「SE0002」の回収予定データが抽出されてセットされる。
入金消込画面で登録が行われると、図9(B)に示すような入金消込データが作成される。図9(B)に示す入金消込データの例では、入金消込番号「NY0001」、行番号「1」、入金消込日「2018/4/10」、回収SEQ「SQ01」、今回消込金額「¥1,000,000」、入金番号「NY0001」となっている。この発生仕訳は、図9(C)に示すように、借方が仮受金「¥1,000,000」、貸方が未成工事受入金「¥1,000,000」のようになる。
図9(D)に示すように、回収予定データの消込済金額は、入金消込処理された消込金額「¥1,000,000」に更新され、「消込完了」の有無が「済」に更新される。
また、図9(E)に示すように、入金データの「消込済金額」が「¥1,000,000」に更新され、消込完了の有無が「済」に更新される。
さらに、図9(F)に示すような前受明細データが作成される。同図において、入金番号「NY0002、前受入金連番「1」、請求先「SEI002:〇△不動産」、債権科目区分「未完成工事受入金」、プロジェクトNO「PJ0002」、前受金額「1000,000」、前受振当済金額「0」、振当完了「未」となっている。当時点での最終的な前受明細データのサマリーは図9(J)に示すようになる。
図10〜図12を参照して、プロジェクトに紐付かない前請求+前月の通常請求に対する入金が一度に発生した場合の前受金発生までを説明する。図10〜図12は、プロジェクトに紐付かない前請求+前月の通常請求に対する入金が一度に発生した場合の前受金発生までを説明するための図である。
図10(A)は、売上データの一例を示しており、図10(A)に示す売上データの例では、売上番号「UR0000」、行「1」、売上日「2018/3/13」、部門「BMN001:営業1部」、請求先「SEI001:□△工業」、商品「FN0001:キャスターファン」、売上数「2」、売上金額「¥400,000」、債権科目区分「売掛金」、プロジェクトNO「 」となっている。
図10(B)に示す回収予定データの例では、回収SEQ「SQ00」、伝票種「売上」、取引区分「通常売上」、伝票番号「UR0000」、行番号「1」、回収予定日「2018/04/13」、部門「BMN001:営業1部」、請求先「SEI001:□△工業」、費目「 」、請求番号「 」、回収予定金額「¥400,000」、消込済金額「0」、消込完了「未」、債権科目区分「売掛金」、プロジェクトNO「ブランク」、売上時前振当FLG「0」となっている。
となっている。
図10(C)に示す請求入力画面において、通常の請求であるので、請求区分「1:通常請求」、プロジェクトに紐付いた案件ではないので、プロジェクトNOはブランクとする。
請求入力画面での入力操作(登録)により、例えば、図10(D)に示す請求データが作成されると共に、図10(B)の回収予定データの「請求番号」が図10(E)に示すように更新される。
図10(D)に示す請求データの例では、伝票番号「SE000」、伝票種「請求」、取引区分「通常請求」、行番号「1」、請求日「2018/03/15」、部門「BMN001:営業1部」、請求先「SEI001:□△工業」、請求金額「¥400,000」、プロジェクトNO「 」となっている。
また、図10(E)に示すように、図10(B)の回収予定データの「請求番号」が、「SE0001」に更新される。
図11及び図12を参照して、請求先より50万の前払希望を受けたが、20万円を消耗品売上に充てるために前受で処理をし、残額をいずれかの工事売上に充当しようとした場合について説明する。
図11(A)に示す請求入力画面において、請求金額「¥500,000」を、「¥200,000」と「¥300,000」に分け、債権科目区分を「前受金」と、「未成工事受入金」とした。
請求入力画面での入力操作により、例えば、図11(B)及び図11(C)に示すように、請求データ及び回収予定データに、2行目と3行目のデータが追加される。図11(B)に示す請求データは、2行目は、伝票番号「SE0003」、伝票種「請求」、取引区分「前請求」、行番号「1」、請求日「2018/04/01」、部門「BMN001:営業1部」、請求先「SEI001:□△工業」、請求金額「¥200,000」、プロジェクトNO「 」となっている。3行目は、伝票番号「SE0003」、伝票種「請求」、取引区分「前請求」、行番号「2」、請求日「2018/04/01」、部門「BMN001:営業1部」、請求先「SEI001:□△工業」、請求金額「¥300,000」、プロジェクトNO「 」が追加される。
図11(C)に示す回収予定データでは、2行目は、回収SEQ「SQ03」、伝票種「請求」、取引区分「前請求」、伝票番号「SE0003」、行番号「1」、回収予定日「2018/04/13」、部門「BMN001:営業1部」、請求先「SEI001:□△工業」、費目「HM003:前払要望分」、請求番号「SE0003」、回収予定金額「¥200,000」、消込済金額「0」、消込完了「未」、債権科目区分「前受金」、プロジェクトNO「ブランク」、売上時前振当FLG「0」が追加される。
3行目は、回収SEQ「SQ04」、伝票種「請求」、取引区分「前請求」、伝票番号「SE0003」、行番号「2」、回収予定日「2018/04/13」、部門「BMN001:営業1部」、請求先「SEI001:□△工業」、費目「HM003:前払要望分」、請求番号「SE0003」、回収予定金額「¥30,000」、消込済金額「0」、消込完了「未」、債権科目区分「未成工事受入金」、プロジェクトNO「ブランク」、売上時前振当FLG「0」となっている。この場合の発生仕訳は、図11(D)に示すようになる。
つぎに、入金入力にて入金データを登録する。3/15付けで請求していた¥400,000と合算して「¥900,000」が振り込まれた。図11(E)に示す入金データでは、入金番号「NY0003」、行番号「1」、入金日「2018/4/13」、部門「BMN001:営業1部」、請求先「SEI001:□△工業」、取引区分「振込」、入金金額「900,000」、消込済金額「0」、消込完了「未」、前受相殺入金番号・連番「 」となっている。入金入力にて入金データを登録し、前受請求分の回収予定に対する消込によって、前受残高(前受明細データ)が作成される。
図12(A)に示す入金消込画面では、請求先がSEI001:□△工業となっており、伝票部には、請求先「SEI001:□△工業」の消込未完了(消込完了=未)の入金データが抽出されてセットされる。同図に示す例では、入金番号「NY0003」の入金データがセットされる。また、消込候補は、回収予定データから請求先「SEI001:□△工業」の消込未完了(消込完了=未)の伝票番号「SE003」、「SE003」、「SE000」のデータが抽出されてセットされる。
入金消込画面で登録が行われると、図12(B)に示すような入金消込データが作成される。図12(B)に示す入金消込データの例では、1行目が、入金消込番号「NK0003」、行番号「1」、入金消込日「2018/4/13」、回収SEQ「SQ03」、今回消込金額「¥2,000,000」、入金番号「NY0003」となっている。2行目は、入金消込番号「NK0003」、行番号「2」、入金消込日「2018/4/13」、回収SEQ「SQ04」、今回消込金額「¥300,000」、入金番号「NY0003」となっている。3行目は、入金消込番号「NK0003」、行番号「3」、入金消込日「2018/4/13」、回収SEQ「SQ00」、今回消込金額「¥400,000」、入金番号「NY0003」となっている。この発生仕訳は、図12(C)に示すようになる。
図12(D)に示すように、回収予定データの消込済金額は、入金消込で処理された消込金額「¥400,000」、「¥200,000」、「¥300,000」に更新され、「消込完了」の有無が「済」に更新される。
また、図12(E)に示すように、入金データの「消込済金額」が「¥900,000」に更新され、消込完了の有無が「済」に更新される。
消込候補の中から今回消込対象とした取引区分が「前請求」に該当する場合、さらに追加で前受明細データを生成する。入金消込画面の情報、入金消込データ、回収予定データ及び入金データの更新結果を用いて生成する。
図12(F)に示すような前受明細データが作成される。図12(F)に示す前受明細データの例では、1行目が、入金番号「NY0003」、前受入金連番「1」、請求先「SEI001:□△工業」、債権科目区分「前受金」、プロジェクトNO「ブランク」、前受金額「¥200,000」、前受振当済金額「0」、振当完了「未」となっている。2行目が、入金番号「NY0003」、前受入金連番「2」、請求先「SEI001:□△工業」、債権科目区分「未成工事受入金」、プロジェクトNO「ブランク」、前受金額「300,000」、前受振当済金額「0」、振当完了「未」となっている。
図13は、受注データ(売上入力画面説明用)を説明するための図である。図13(A)は、受注データの一例を示す図である。図13(A)に示す受注データは、1行目が、受注番号「JC0001」、行「1」、受注日「2018/03/01」、部門「BMN001:営業1部」、請求先「SEI001:□△工業」、商品「IS0001:設備工事一式」、売上数「1」、売上金額「¥7,000,000」、債権科目区分「完成工事未収入金」、プロジェクトNO「PJ0001」となっている。2行目が、受注番号「JC0002」、行「1」、受注日「2018/03/01」、部門「BMN001:営業1部」、請求先「SEI002:〇△不動産」、商品「IS0001:設備工事一式」、売上数「1」、売上金額「¥5,000,000」、債権科目区分「完成工事未収入金」、プロジェクトNO「PJ0003」となっている。3行目が、受注番号「JC0003」、行「1」、受注日「2018/03/01」、部門「BMN001:営業1部」、請求先「SEI001:□△工業」、商品「AC002:X社製エアコン」、売上数「3」、売上金額「¥200,000」、債権科目区分「売掛金」、プロジェクトNO「 」となっている。
図13(B)は、売上入力画面を示しており、受注NO「JC0001」の受注データが読み出されて表示されている。前受振当ボタンを押すと、当該売上に対して充当可能な前受金残高がある場合に使用可能となる。
図14は、前受金の振当を説明するための図である。図15は、前受金の振当により生成・更新されるデータを説明するための図である。
図14(A)は、前受明細データのサマリーである。前受明細データのうち、下記条件に合致するデータが存在するか否かを判断し、該当する前受明細データを前受振当画面に表示する。
(1)画面請求先と一致する。
(2)画面のプロジェクトNOがブランクでない場合は、プロジェクトNOが一致する。
(3)前受明細のプロジェクトNOがブランクである。
(4)振当完了が「未」である。
図14(A)に示す例では、1行目が請求先とプロジェクトが一致し、振当未であるので、該当する。2行目は、請求先が不一致であるので該当しない。3行目は、請求先が一致し、プロジェクトがブランクで、振当未であるので該当する。4行目は、請求先が一致し、プロジェクトがブランクで、振当未であるので該当する。
図14(B)は、前受振当画面の一例を示す図である。前受振当画面は、ヘッダー部が請求先、伝票金額、前受振当金額となっており、明細部が入金番号、前受入金連番、債権科目区分、プロジェクトNO、前受金額、前受振当済金額、今回振当金額、今回振当後残額となっている。
前受金額は、前受明細データにより表示する。前受振当済金額は、前受明細データの前受振当済金額より表示する。修正登録時は、修正前の今回振当金額(後述の回収予定:消込金額)を控除する。今回振当金額は、オペレータが入力する。今回振当残額が0以上の範囲で変更可能である。今回振当後残額は、今回振当金額の入力都度計算して表示する。前受金額−前受振当済金額−今回振当金額とする。
同図に示す例では、請求先が「SEI001:□△工業」となっており、図14(A)は、前受明細データの1,3,4行目のデータが抽出されて表示されている。振当可能な¥2,500,000のうち、プロジェクトが一致するもの及びプロジェクトがブランクかつ債権科目区分が「未成工事受入金」の計「¥2,300,000」を全額充当し、売上登録を行う。
売上登録を行うと、図15(B)に示すような回収予定データ作成される。回収予定データは、売上金額に対して前受金を一部充当したため、振当残用の明細と振当済の明細とで便宜上分割する。後者は消込済、売上時前受振当FLGを「1」にセットする。売上入力修正時の前受振当画面の「前受振当済額」は、同一伝票番号の当該FLGが「1」の回収予定SEQより、後述の入金消込データ、今回消込金額を入金番号単位で集計して表示させる。
図15(B)に示す回収予定データは、1行目が、回収SEQ「SQ05」、伝票種「売上」、取引区分「前工事売上」、伝票番号「UR0001」、行番号「1」、回収予定日「2018/05/31」、部門「BMN001:営業1部」、請求先「SEI001:□△工業」、費目「 」、請求番号「 」、回収予定金額「¥4,700,000(=¥7,000,000−¥2,300,000)」、消込済金額「0」、消込完了「未」、債権科目区分「完成工事未収入金」、プロジェクトNO「PJ0001」、売上時前振当FLG「0」となる。2行目は、回収SEQ「SQ05」、伝票種「売上」、取引区分「前工事売上」、伝票番号「UR0001」、行番号「1」、回収予定日「2018/05/31」、部門「BMN001:営業1部」、請求先「SEI001:□△工業」、費目「 」、請求番号「 」、回収予定金額「2,300,000」、消込済金額「2,300,000」、消込完了「未」、債権科目区分「完成工事未収入金」、プロジェクトNO「PJ0001」、売上時前振当FLG「1」となる。
また、図15(C)に示すようなダミーの入金データを作成する。1行目は、入金番号「NY0004」、行番号「1」、入金日「2018/4/20」、部門「BMN001:営業1部」、請求先「SEI001:□△工業」、取引区分「前受相殺」、入金金額「¥2,000,000」、消込済金額「¥2,000,000」、消込完了「済」、前受相殺入金番号「NY0001」、前受相殺入金連番「1」となる。2行目は、入金番号「NY0004」、行番号「2」、入金日「2018/4/20」、部門「BMN001:営業1部」、請求先「SEI001:□△工業」、取引区分「前受相殺」、入金金額「¥300,000」、消込済金額「¥300,000」、消込完了「済」、前受相殺入金番号「NY0003」、前受相殺入金連番「2」となる。
また、図15(D)に示すような入金消込データを作成する。図15(C)に示す入金消込データは、入金消込番号「NK0004」、行番号「1」、入金消込日「2018/4/20」、回収SEQ「SQ06」、今回消込金額「¥2,300,000」、入金番号「NY0004」となっている。
前受明細データは、図15(E)に示すように更新される。1行目の前受振当済金額「¥2,000,000」、振当完了「済」、4行目の前受振当済金額「¥300,000」、振当完了「済」に更新される。
前受振当によって、「前受相殺」という仮想取引区分でダミーの入金を発生させ、これに対して入金消込を実施したデータを作成する。仮想金種の入金からは仕訳を発生させない。図15(F)、(G)は仕訳を示している。
図16は、残額の請求を説明するための図である。図16(A)、(B)は、図15(A)、(B)と同様である。
一般的な仕組みのように売上データから請求額を算定(¥7,000,000)すると、前受金を充当した分までが金額として含まれる。要求要否及び請求有無を回収予定上で管理し、請求額は回収予定額より算出する。要件要否の条件は、回収予定データの請求番号がブランク(まだ請求されていない)であること、回収予定データの消込完了=未(債権消込がされていない)ことである。ここでは、回収予定SQ=SQ05のみが対象となる。複数回収予定が対象となった場合、回収予定額のサマリーが対象となる。
図16(C)は、請求書データのイメージである。同図に示す例では、請求番号「SE0004」、請求日「2018/04/20」、請求先「□△工業様(SEI001)、今回請求額「¥4,700,000」、営業担当「営業1部(BMN001)」となっている。
図17〜図19は、プロジェクトに紐付いていない案件の前受金を説明するための図である。以下では、本項以前の振当を実施していない前提で説明する。
図17(A)に示す売上入力画面では、受注NO「JC0003」が入力されて、図13(A)の3行目の受注データが読み出されて表示されている。請求先「SEI001 □△工業」、売上金額「¥200,000」、債権科目区分「売掛金」となっている。
前受振当ボタンを押すと、図17(C)に示すような前受振当画面が表示される。図17(C)の前受振当画面には、図17(B)の前受明細データのうち、請求先が一致し、プロジェクトがブランクで、未振当の3行と、4行のデータが抽出されて表示される。他プロジェクトの前受金は振当対象として抽出されない。債権科目区分「前受金」の明細を充当対象として、売上金額に対して、全額充当を実施する。同図に示す例では、1行目の今回振当金額に伝票金額の満額の「¥200,000」を充当している。
図18は、生成データを示している。図18(B)に示すような回収予定データが作成され、回収予定額「¥200,000」、消込済金額「¥200,000」、消込完了「済」、売上時前受振当FLG「1」となっている。先の例では、売上金額に対して充当残が発生したため、回収予定が分割されたが、今回は全額充当されたため消込完了の1行だけが作成される。
図18(C)に示すようなダミーの入金データが作成される。また、図18(C)に示すような入金消込データが作成される。さらに、前受明細データが図18(E)に示すように更新される。
図19は、売上計上を説明するための図である。図19に示す売上入力画面において、
当該売上に対して充当可能な前受金残高がないため、使用することができない。
以上説明したように、本実施の形態によれば、入金金額と前請求に係る請求の回収予定額との消込を行う入金消込処理部102aと、消込後、前請求に係る請求の前受明細を作成する前受明細作成部102bと、売上に対して前受明細のうち振当可能なものを振り当てる前受金売上振当部102cとを備えているので、前受金の管理を容易にすると共に、売上に対する充当の自由度を向上させることが可能となる。
[4.他の実施形態]
本発明は、上述した実施の形態以外にも、特許請求の範囲に記載した技術的思想の範囲内において種々の異なる実施形態にて実施されてよいものである。
例えば、実施の形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。
また、本明細書中や図面中で示した処理手順、制御手順、具体的名称、各処理の登録データや検索条件等のパラメータを含む情報、画面例、データベース構成については、特記する場合を除いて任意に変更することができる。
また、前受金管理装置100に関して、図示の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。
例えば、前受金管理装置100が備える処理機能、特に制御部102にて行われる各処理機能については、その全部または任意の一部を、CPUおよび当該CPUにて解釈実行されるプログラムにて実現してもよく、また、ワイヤードロジックによるハードウェアとして実現してもよい。尚、プログラムは、本実施形態で説明した処理を情報処理装置に実行させるためのプログラム化された命令を含む一時的でないコンピュータ読み取り可能な記録媒体に記録されており、必要に応じて前受金管理装置100に機械的に読み取られる。すなわち、ROMまたはHDD(Hard Disk Drive)などの記憶部などには、OSと協働してCPUに命令を与え、各種処理を行うためのコンピュータプログラムが記録されている。このコンピュータプログラムは、RAMにロードされることによって実行され、CPUと協働して制御部を構成する。
また、このコンピュータプログラムは、前受金管理装置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は、当該装置に本実施形態で説明した処理を実現させるソフトウェア(プログラムまたはデータ等を含む)を実装することにより実現してもよい。
更に、装置の分散・統合の具体的形態は図示するものに限られず、その全部または一部を、各種の付加等に応じてまたは機能負荷に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。すなわち、上述した実施形態を任意に組み合わせて実施してもよく、実施形態を選択的に実施してもよい。