JP2022174284A - Prepayment management device, prepayment management method, and prepayment management program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a prepayment management device, a prepayment management method, and a prepayment management program that can facilitate management for prepayment and improve degree of freedom of appropriation for sales.

SOLUTION: A prepayment management device includes: payment deletion means for deleting a payment amount and an expected recovery amount of a claim related to previous bills; prepayment receipt detail preparation means for preparing, after the deletion, prepayment details of the claim related to the previous bills; and prepayment sales allocation means for allocating allocatable items out of the prepayment details to sales.

SELECTED DRAWING: Figure 1

COPYRIGHT: (C)2023,JPO&INPIT

Description

The present invention relates to an advance payment management device, an advance payment management method, and an advance payment management program.

Conventionally, funds for providing services have been a problem in industries and business categories where it takes a long time to record sales, such as construction work, or where high costs are incurred. For that reason, pre-billings have been made under the pretext of "start-up money" and "intermediate money", and have been managed as advance payments.

When registering the balance of advance receipts on the system, it is common to input data in advance as "advance receipts" at the time of payment. However, in the actual deposit operation, only the prepaid amount is not necessarily paid separately, and if there are ordinary claims, they are paid together. At that time, the accounting process such as confirmation and apportionment of the advance payment schedule was very complicated.

JP 2017-182767 A

The present invention has been made in view of the above, and provides an advance payment management device, an advance payment management method, and an advance payment management program capable of facilitating the management of advance payments and improving the degree of freedom in appropriating sales. intended to

In order to solve the above-described problems and achieve the object, the present invention provides an advance payment management apparatus having a control unit, wherein the control unit is configured to cancel the amount of money received and the expected collection amount of the previous claim. payment reconciliation means for performing reconciliation; after reconciliation, pre-receipt detail creation means for creating pre-receipt detail of billing related to said pre-billing; and an advance receipt sales appropriation means.

Further, according to a preferred aspect of the present invention, the claims related to the previous claims may include a previous claim linked to the project and a previous claim not linked to the project.

Further, according to a preferred aspect of the present invention, if the advance receipt sales appropriation means matches the billing destination of the sales in the advance receipt details and the sales are linked to a project, the project are the same or are not linked to a project and are not allocated, and if the sales are not linked to a project, it is possible to allocate unallocated sales that are not linked to a project. .

Further, in order to solve the above-described problems and achieve the object, the present invention provides an advance receipt management method executed by an information processing apparatus having a control unit, wherein A payment reconciliation step of reconciling the bill related to the previous bill with the expected collection amount; and an advance receipt sales allocation step for allocating those that can be allocated among the advance receipt details.

Further, in order to solve the above-described problems and achieve the object, the present invention provides an advance payment management program to be executed by an information processing apparatus having a control unit, wherein a payment reconciliation step of reconciling the billing with the expected collection amount of the billing; and an advance receipt sales allocation step for allocating items that can be allocated among the details, and an advance receipt management program for executing an advance receipt sales allocation step.

ADVANTAGE OF THE INVENTION According to this invention, while facilitating management of an advance receipt, it becomes possible to improve the flexibility of the allocation with respect to sales.

FIG. 1 is a block diagram showing an example of the configuration of an advance payment management device according to this embodiment. FIG. 2 is a diagram showing a configuration example of the subject classification master. FIG. 3 is a diagram showing a configuration example of a transaction classification master. FIG. 4 is a diagram showing a configuration example of an expense item master. FIG. 5 is a diagram showing a configuration example of a billing destination master. FIG. 6 is a flow chart for explaining the main part of the processing of the advance receipt management device according to the present embodiment. FIG. 7 is a diagram for explaining up to the generation of an advance payment for an item linked to a project. FIG. 8 is a diagram for explaining up to the generation of an advance payment for an item linked to a project. FIG. 9 is a diagram for explaining up to the generation of an advance payment for an item linked to a project. FIG. 10 is a diagram for explaining up to the generation of an advance payment when payment for advance billing not tied to a project + normal billing for the previous month occurs at once. FIG. 11 is a diagram for explaining up to the generation of the advance payment when the payment for the previous billing not linked to the project + the normal billing for the previous month occurs at once. FIG. 12 is a diagram for explaining up to the generation of an advance payment when payment for advance billing not tied to a project + normal billing for the previous month occurs at once. FIG. 13 is a diagram for explaining order data (for explaining the sales input screen). FIG. 14 is a diagram for explaining the allocation of advance receipts. FIG. 15 is a diagram for explaining data generated and updated by allocating advance receipts. FIG. 16 is a diagram for explaining billing of the balance. FIG. 17 is a diagram for explaining an advance payment for an item that is not linked to a project. FIG. 18 is a diagram for explaining an advance payment for an item that is not linked to a project. FIG. 19 is a diagram for explaining an advance payment for an item that is not linked to a project.

An embodiment of the present invention will be described in detail based on the drawings. In addition, this invention is not limited by this embodiment.

[1. Overview]
Conventionally, when registering the balance of advance receipts on a system, it is common to input data in advance as "advance receipts" at the time of payment. However, in the actual deposit operation, only the prepaid amount is not necessarily paid separately, and if there are ordinary claims, they are paid together. At that time, the accounting process such as confirmation of the pre-received payment schedule and apportionment becomes very complicated.

Therefore, in the present embodiment, attention is paid to the fact that the operation (payment reconciliation) of matching the payment results with accounts receivable is carried out in any case. In this embodiment, by performing payment reconciliation for advance receipt schedule (advance billing) in the same way as ordinary receivables, a mechanism is provided for transfer to advance receipts and balance management so that they are subject to advance receipt management. building.

On the other hand, in industries and business categories in which it takes a long time from the occurrence of construction costs to the recording of sales, or in which high costs are incurred, funding for providing services becomes a problem. For that reason, advance billing is done under the name of "start money" and "intermediate money", and managed as advance money (hereinafter in the case of construction projects, unfinished construction receipt money). There are needs to allocate advances for specific services (projects) to the sales recorded for the services, and there are also needs to allocate them freely to unspecified services.

Even if there were cases in which either method was supported, there were cases where this need was mixed within the company due to complex business conditions and trade customs. For example, even if it is an advance payment for a project, in a billing destination where multiple projects are in progress at the same time, the advance payment will be received with the total amount for the multiple projects, and the business practice will be applied in order from the earliest sales recorded. Or, depending on the billing destination, there may be times when you want to reserve a certain amount of advance payment at the end of the first half for budget reasons.

Therefore, in the present embodiment, advances received can be managed and allocated to sales on a project-by-project basis, and advances received can be managed and allocated on a billing-to basis. It is now possible to allocate the funds to sales.

Specifically, in the present embodiment, (1) payment reconciliation (appropriation of temporary receipts, etc.) for advance receipt requests is performed, and (2) at the time of sales, allocation to sales is performed. It is possible to change the calculation method of the balance of advance receipts to enable appropriate appropriation.

[2. Constitution]
An example of the configuration of the advance receipt management device according to the present embodiment will be described with reference to FIG. FIG. 1 is a block diagram showing an example of the configuration of an advance receipt management device.

The advance receipt management device 100 is, for example, a commercially available desktop personal computer. Note that the advance receipt management device 100 is not limited to a stationary information processing device such as a desktop personal computer, and may be a portable type such as a commercially available notebook personal computer, PDA (Personal Digital Assistants), a smart phone, or a tablet personal computer. It may be an information processing device.

The advance receipt management device 100 includes a control section 102 , a communication interface section 104 , a storage section 106 and an input/output interface section 108 . Each unit included in the advance payment management device 100 is communicably connected via an arbitrary communication path.

The communication interface unit 104 communicably connects the advance receipt management device 100 to the network 300 via a communication device such as a router and a wired or wireless communication line such as a dedicated line. The communication interface unit 104 has a function of communicating data with another device via a communication line. Here, the network 300 has a function of connecting the advance receipt management apparatus 100 and the server 200 so as to be able to communicate with each other, and is, for example, the Internet or a LAN (Local Area Network).

An input device 112 and an output device 114 are connected to the input/output interface unit 108 . The output device 114 can be a monitor (including a home television), a speaker, or a printer. The input device 112 can be a keyboard, a mouse, a microphone, or a monitor that realizes a pointing device function in cooperation with a mouse. Note that, hereinafter, the output device 114 may be referred to as the monitor 114 or the screen 114, and the input device 112 may be referred to as the keyboard 112 or the mouse 112. FIG.

The storage unit 106 stores a computer program for performing various processes by giving commands to a CPU (Central Processing Unit) in cooperation with an OS (Operating System). As the storage unit 106, for example, memory devices such as RAM (Random Access Memory) and ROM (Read Only Memory), fixed disk devices such as hard disks, flexible disks, and optical disks can be used.

The storage unit 106 stores an item classification master 106a, a transaction classification master 106b, an expense item master 106c, a billing destination master 106d, a data file 106e, and the like. FIG. 2 is a diagram showing a configuration example of the subject classification master 106a. FIG. 3 is a diagram showing a configuration example of the transaction classification master 106b. FIG. 4 is a diagram showing a configuration example of the expense item master 106c. FIG. 5 is a diagram showing a configuration example of the billing destination master 106d. These item classification master 106a, transaction classification master 106b, expense item master 106c, and billing destination master 106d are referred to when the control unit 102 displays the input screen, and the items corresponding to the items input by the operator are read out. displayed.

As shown in FIG. 2, the subject division master 106a can be composed of a table or the like for registering data on subject divisions and subject classifications in association with each other. From the subject classification master 106a, the subject classification is read out using the subject classification as a key and displayed on various screens.

As shown in FIG. 3, the transaction classification master 106b can be composed of a table or the like for registering data on slip types, transaction classifications, debit account items, and credit account items in association with each other.

The expense item master 106c, as shown in FIG. 4, can be composed of a table or the like in which the data of the expense item CD, the expense item name, and the previously received item category are associated and registered.

The billing destination master 106d can be composed of a table or the like in which store code, store name, collection month, and collection date data are associated and registered.

The data file 106e is for storing various data such as billing data, collection schedule data, deposit data, deposit reconciliation data, advance receipt detail data, sales data, and order receipt data.

Billing data may include slip number, slip type, transaction classification, line number, department, billing destination, billing amount, and project number. Collection schedule data includes collection SEQ, slip type, transaction classification, slip number, line number, department, billing destination, expense item, billing number, planned collection amount, applied amount, application completion, receivables category, project No., It may contain data of pre-allocation FLG at the time of sales.

Receipt data may include receipt number, line number, receipt date, department, billing party, transaction classification, receipt amount, applied amount, application completion, advance offset receipt number/serial number data. The deposit application data may include a deposit application number, a line number, a deposit application date, a collection SEQ, an amount applied this time, and a deposit number.

The pre-received detailed data may include deposit number, pre-received serial number, billing destination, receivables category, project No., pre-received amount, pre-appropriated amount, and appropriation completion data. The sales data may include sales number, line, sales date, department, billing address, product, sales quantity, sales amount, receivables category, and project number. The order data may include order number, line, date of order, department, billing address, product, number of sales, amount of sales, credit category, and project number.

The control unit 102 is a CPU or the like that controls the advance payment management device 100 in a centralized manner. The control unit 102 has an internal memory for storing a control program such as an OS, a program defining various processing procedures, required data, and the like, and performs various information processing based on these stored programs. Run. The control unit 102 functionally and conceptually includes a deposit reconciliation processing unit 102a, an advance receipt details creation unit 102b, an advance receipt sales allocation unit 102c, and a master maintenance unit 102d.

The deposit reconciliation processing unit 102a reconciles the amount of money received and the expected collection amount of the previous bill. The billing related to the pre-billing may include the pre-billing associated with the project and the pre-billing not associated with the project.

After reconciliation, the pre-receipt detail preparation unit 102b prepares the pre-receipt detail of the billing related to the pre-billing, and stores the pre-receipt detail in the data file 106e.

The advance receipt sales allocation unit 102c allocates the advance receipt details that can be allocated to the sales. The advance receipt sales allocation unit 102c, among the advance receipt details, if the sales billing destination matches the sales and the sales are linked to the project, the sales are the same project or are not linked to the project and are not allocated. If the sales are not tied to the project, the unallocated sales that are not tied to the project may be allocated.

The master maintenance unit 102d displays a master maintenance screen (not shown) on the monitor 114 according to an operator's instruction, and according to the operator's operation on the master maintenance screen, the item classification master 106a, the transaction classification master 106b, Editing such as input, change, addition, etc. of the data of the expense item master 106c and billing destination master 106d is performed.

[3. Specific example of processing]
A specific example of the processing of the control unit 102 of the advance payment management apparatus 100 according to the present embodiment will be described with reference to FIGS. 1 to 19. FIG. First, with reference to FIGS. 1 and 6, the main part of the processing of the control unit 102 of the advance receipt management apparatus 100 according to the present embodiment will be described. FIG. 6 is a flowchart for explaining the main part of the processing of the control unit 102 of the advance receipt management apparatus 100 according to the present embodiment.

The deposit reconciliation processing unit 102a executes a receipt reconciliation process (step S1). In the deposit reconciliation process, reconciliation is performed between the received amount and the scheduled collection amount of the previous bill. The billing related to the pre-billing may include the pre-billing associated with the project and the pre-billing not associated with the project.

The pre-order receipt creation unit 102b executes pre-order receipt creation processing (step S2). In the pre-receipt detail preparation process, after reconciliation, the pre-receipt detail of the billing related to the pre-billing is prepared and the prepared pre-receipt detail is stored in the data file 106e.

The advance receipt sales allocation unit 102c executes advance receipt sales allocation processing (step S3). In the advance receipt sales allocation processing, the advance receipt details that can be allocated are allocated to the sales. In advance receipt sales allocation processing, if the details of the advance receipt match the sales billing destination and the sales are linked to the project, the project is the same or not linked to the project. If the sales are not tied to the project, the unallocated sales that are not tied to the project may be allocated.

A specific example of the processing of the control unit 102 of the advance payment management apparatus 100 according to the present embodiment will be described with reference to FIGS. 7 to 19. FIG.

7 to 9 are diagrams for explaining up to the generation of the advance payment for the item linked to the project.

In FIG. 7, project basic information data is entered and registered in the data file 106f by PJ information basic input. FIG. 7A is a diagram showing an example of project basic information data. In the example of the project basic information data shown in FIG. 7A, the first line has the project number "PJ0001", the project name "new construction B area air conditioning construction", and the billing destination "SEI001: □△ industry". . The second line has the project number "PJ0002", the project name "Kyobashi 〇× building electrical installation work", and the billing destination "SEI002: 〇△ real estate". The third line has the project number "PJ0003", the project name "Nihonbashi ◇◇ building air conditioner replacement work", and the billing destination "SEI003: 〇△ real estate".

In the following, the case of generating an advance payment for project numbers "PJ0001" and "PJ0002" will be described.

Next, in billing input, billing data and collection schedule data can be registered on the billing information input screen shown in FIG. 7(B). The billing input screen shown in FIG. 7B displays a header and billing details. In the header, items such as billing number, billing date, department, billing destination, billing category, project number, and scheduled collection date are displayed. A claim number is automatically assigned at the time of registration. Items such as expense item/goods, invoiced amount, and claim category are displayed in the billing details. When the expense item CD is entered, the expense item name and credit item category are read out from the expense item master 106c and displayed. In the example of the billing input screen shown in FIG. 7B, the billing category "2: pre-billing" and the project number "PJ0001" are entered.

For example, billing data and collection schedule data shown in FIGS. 7(C) and 7(D) are created by the input operation on the billing input screen of FIG. 7(B).

In the example of billing data shown in FIG. 7(C), the first line is slip number "SE0001", slip type "claim", transaction classification "pre-billing", line number "1", billing date "2018/04/ 01", department "BMN001: Sales Department 1", billing destination "SEI001: □△ industry", billing amount "¥2,000,000", project No. "PJ0001". The second line is slip number "SE0002", slip type "billing", transaction type "pre-billing", line number "1", billing date "2018/04/01", department "BMN001: Sales Division 1", billing The destination is “SEI002: ◯△ real estate”, the billed amount is “¥1,000,000”, and the project number is “PJ0002”.

In the example of collection schedule data shown in FIG. Scheduled date "2018/04/10", department "BMN001: Sales Department 1", billing address "SEI001: △ Industry", expense item "HM001: deposit", billing number "SE0001", scheduled collection amount "2,000" , 000", the applied amount of "0", the applied amount of "unfinished", the receivables category of "uncompleted construction receipt", the project number of "PJ0001", and the pre-allocation FLG at the time of sales of "0". The second line is collection SEQ "SQ02", slip type "billing", transaction classification "pre-billing", slip number "SE0002", line number "1", scheduled collection date "2018/04/08", department "BMN001" : Sales Department 1”, billing destination “SEI002: 〇△ real estate”, expense item “HM002: intermediate money”, invoice number “SE0002”, expected collection amount “¥1,000,000”, applied amount “0”, Completion of reconciliation is "unfinished", receivables category is "uncompleted construction receipt", project number is "PJ0002", and pre-allocation FLG at the time of sales is "0". This generated journal is as shown in FIG. 7(E).

Register deposit data by deposit input. An advance receipt balance (advance receipt detail data) is created by reconciliation to the collection schedule.

In the example of deposit data shown in FIG. 7(F), the first line is deposit number "NY0001", line number "1", deposit date "2018/4/10", department "BMN001: Sales Department 1", billing Destination "SEI001: □△ industry", transaction type "transfer", deposit amount "¥2,000,000", applied amount "0", application completed "not yet", advance offset payment number/serial number " ”. The second line is the deposit number "NY0002", the line number "1", the deposit date "2018/4/08", the department "BMN001: Sales Department 1", the billing destination "SEI002: ○△ real estate", the transaction classification "transfer , payment amount ``¥1,000,000'', applied amount ``0'', payment completed ``not yet'', prepaid offset payment number/serial number `` ''.

Next, payment reconciliation is performed. FIG. 8A is a diagram showing an example of a deposit reconciliation screen. Receipt data is extracted and set in the receipt slip part for unfinished reconciliation (completion of reconciliation=not completed) of the billing destination specified on the reconciliation screen. After selecting the line to be used as the source of funds to be applied, specify the source of funds to be applied this time within the range of deposit amount-applied amount≧0 (initial display of deposit amount-applied amount).

In the reconciliation candidate, the collection schedule data is extracted and set for the non-completion of reconciliation (completion of reconciliation=not completed) of the billing party specified on the reconciliation screen.

After selecting the line to be reconciled, specify the amount to be reconciled this time within the range of expected collection amount - applied amount ≥ 0 (anticipated collection amount - applied amount is displayed by default). In this example, it is assumed that the total amount of received money is used as the source of funds to be applied, and the total amount of unapplied funds for the collection schedule is applied. A deposit reconciliation number is assigned at the time of registration.

When registration is performed on the deposit reconciliation screen, deposit reconciliation data as shown in FIG. 8(B) is created. In the example of deposit application data shown in FIG. 8(B), the deposit application number “NY0001”, line number “1”, payment application date The amount is “¥2,000,000” and the deposit number is “NY0001”. In this generated journal entry, the debit side is the provisional receipt "¥2,000,000" and the credit side is "¥2,000,000" for the uncompleted construction work receipt.

As shown in FIG. 8(D), the applied amount in the scheduled collection data is updated to the applied amount "¥2,000,000" processed for deposit application, and the presence or absence of "apply completed" is confirmed. It will be updated to "done".

Also, as shown in FIG. 8(E), the "applied amount" of the deposit data is updated to "¥2,000,000", and the presence/absence of payment completion is updated to "completed".

If the transaction classification targeted for reconciliation this time among the reconciliation candidates corresponds to "advance billing", additional pre-received detail data is generated. The advance receipt detail data is generated using the screen information of the payment reconciliation screen, the reconciliation data, the collection schedule data, and the updated result of the payment data.

FIG. 8F is a diagram showing an example of pre-received detailed data. In the example of advance receipt detail data shown in FIG. The project number is “PJ0001”, the amount of advance received is “¥2,000,000”, the amount of advance payment is “0”, and the amount of payment is “unfinished”.

The "advance receipt amount" is set with the amount applied this time in the deposit reconciliation data. In the "advance receipt serial number", when one payment is reconciled to multiple pre-billings, the SEQ is added and the details increase. This time, only one line is generated because there is only one reconciliation target.

FIG. 9 is a diagram for explaining an example of a case in which advance billing for project PJ002 is similarly processed.

In the payment reconciliation screen shown in FIG. 9(A), the billing destination is SE0002: ○△ real estate, and in the slip part, reconciliation of the billing destination "SE0002: ○△ real estate" has not been completed (reconciliation completed = (un)deposited data is extracted and set. In the example shown in the figure, deposit data for deposit number "NY0002" is set. In addition, as the reconciliation candidate, collection schedule data of slip number "SE0002" for which reconciliation is not completed (completion of reconciliation=not completed) of billing destination "SE0002: ◯△ real estate" is extracted and set.

When registration is performed on the deposit reconciliation screen, deposit reconciliation data as shown in FIG. 9(B) is created. In the example of deposit reconciliation data shown in FIG. 9(B), the reconciliation number "NY0001", the line number "1", the reconciliation date "2018/4/10", the collection SEQ "SQ01", the current reconciliation The amount is “¥1,000,000” and the deposit number is “NY0001”. As shown in FIG. 9(C), this generated journal has a debit of temporary receipt of "¥1,000,000" and a credit of uncompleted work receipt of "¥1,000,000".

As shown in FIG. 9(D), the applied amount in the scheduled collection data is updated to the applied amount "¥1,000,000" for which payment application processing has been performed, and the presence or absence of "application completed" is set to " completed”.

Also, as shown in FIG. 9E, the "applied amount" of the deposit data is updated to "¥1,000,000", and the presence/absence of payment completion is updated to "completed".

Further, pre-receipt detail data as shown in FIG. 9(F) is created. In the same figure, the receipt number "NY0002, the advance receipt serial number "1", the billing destination "SEI002: 〇△ real estate", the receivables category "uncompleted construction receipt", the project No. "PJ0002", the advance receipt amount "1000, 000”, the pre-received allocated amount “0”, and the allocation completed “not yet”. A summary of the final pre-received detailed data at that time is shown in FIG. 9(G).

With reference to FIGS. 10 to 12, a description will be given of up to the occurrence of an advance payment in the case where payment for advance billing not tied to a project + normal billing for the previous month occurs at once. FIGS. 10 to 12 are diagrams for explaining up to the generation of the advance payment when the payment for the previous billing not linked to the project + the normal billing for the previous month occurs at once.

FIG. 10A shows an example of sales data. In the example of sales data shown in FIG. 10A, sales number "UR0000", row "1", sales date Department "BMN001: Sales Department 1", Invoicing Party "SEI001: □△ Industry", Product "FN0001: Caster Fan", Number of Sales "2", Amount of Sales "¥400,000", Receivables Classification "Accounts Receivable", Project NO " ".

In the example of scheduled collection data shown in FIG. 10B, collection SEQ “SQ00”, slip type “sales”, transaction classification “normal sales”, slip number “UR0000”, line number “1”, scheduled collection date “2018” /04/13", department "BMN001: Sales Department 1", billing address "SEI001: □△ industry", expense item " ", billing number " ", expected collection amount "¥400,000", applied amount "0" , reconciliation completion "unfinished", receivables category "accounts receivable", project No. "blank", pre-allocation FLG at the time of sale "0".

In the billing input screen shown in FIG. 10(C), the billing category is "1: normal billing" because it is a normal billing, and the project number is blank because it is not linked to a project.

By input operation (registration) on the billing input screen, for example, the billing data shown in FIG. Updated as shown.

In the example of billing data shown in FIG. 10(D), slip number "SE0000", slip type "billing", transaction classification "normal billing", line number "1", billing date "2018/03/15", department " BMN001: Sales Department 1”, billing destination “SEI001: □△ industry”, billing amount “¥400,000”, project No. “ ”.

Also, as shown in FIG. 10(E), the "billing number" of the collection schedule data in FIG. 10(B) is updated to "SE0001".

With reference to Figures 11 and 12, an advance payment request of 500,000 yen was received from the billing party. Describe what you are trying to do.

On the billing input screen shown in FIG. 11(A), the billing amount "¥500,000" is divided into "¥200,000" and "¥300,000", and the credit item classification is "advance receipt" and "uncompleted construction work". Received money."

By performing an input operation on the billing input screen, the data in the second and third rows are added to the billing data and collection schedule data, for example, as shown in FIGS. 11B and 11C. In the billing data shown in FIG. 11B, the second line is slip number "SE0003", slip type "billing", transaction classification "pre-billing", line number "1", billing date "2018/04/01". , department “BMN001: Sales Department 1”, billing destination “SEI001: □△ industry”, billing amount “¥200,000”, project No. “ ”. The third line is slip number "SE0003", slip type "claim", transaction type "pre-billing", line number "2", billing date "2018/04/01", department "BMN001: Sales Division 1", billing The destination "SEI001: □△ industry", the billing amount "¥300,000", and the project number " " are added.

In the scheduled recovery data shown in FIG. Date ``2018/04/13'', department ``BMN001: Sales Department 1'', billing address ``SEI001: △ Industry'', expense item ``HM003: requested advance payment'', invoice number ``SE0003'', expected collection amount ``¥200, 000", applied amount "0", applied amount "unfinished", receivables item category "advance received", project No. "blank", advance allocation FLG "0" at the time of sale are added.

The third line is collection SEQ "SQ04", slip type "billing", transaction classification "pre-billing", slip number "SE0003", line number "2", scheduled collection date "2018/04/13", department "BMN001". : Sales Department 1", billing address "SEI001: □△ industry", expense item "HM003: requested advance payment", billing number "SE0003", expected collection amount "¥300,000", applied amount "0", consumption The credit item classification is "uncompleted construction receipt", the project number is "blank", and the pre-allocation FLG at the time of sales is "0". The generated journal entries in this case are as shown in FIG. 11(D).

Next, the payment data is registered in the payment input. "¥900,000" was transferred together with the ¥400,000 billed on 3/15. In the deposit data shown in FIG. 11(E), deposit number “NY0003”, line number “1”, deposit date “2018/4/13”, department “BMN001: Sales Department 1”, billing destination “SEI001: □△ Industry , transaction classification "transfer", deposit amount "900,000", reconciled amount "0", reconciliation completed "unfinished", advance offset receipt number/serial number "0". The deposit data is registered in the deposit input, and the pre-received balance (pre-received detail data) is created by reconciling the collection schedule of the pre-received bill.

In the payment reconciliation screen shown in FIG. 12(A), the billing destination is SEI001: □△ industry, and in the slip part, the reconciliation of the billing destination "SEI001: □△ industry" is not completed (reconciliation completed = (un)deposited data is extracted and set. In the example shown in the figure, deposit data for deposit number "NY0003" is set. In addition, as the reconciliation candidates, data of slip numbers "SE0003", "SE0003", and "SE0000" for which reconciliation has not been completed (reconciliation completed = not completed) for the billing destination "SEI001: □△ industry" is extracted from the scheduled collection data. set.

When registration is performed on the deposit reconciliation screen, deposit reconciliation data as shown in FIG. 12(B) is created. In the example of deposit application data shown in FIG. 12(B), the first line is the deposit application number "NK0003", the line number "1", the payment application date "2018/4/13", and the collection SEQ "SQ03". ”, the amount applied this time “¥200,000”, and the deposit number “NY0003”. The second line is the deposit application number "NK0003", line number "2", deposit application date "2018/4/13", collection SEQ "SQ04", current application amount "¥300,000", deposit number It is "NY0003". The third line is the deposit application number "NK0003", the line number "3", the deposit application date "2018/4/13", the collection SEQ "SQ00", the amount applied this time "¥400,000", and the deposit number. It is "NY0003". This generated journal is as shown in FIG. 12(C).

As shown in FIG. 12(D), the reconciled amounts in the scheduled collection data are the reconciled amounts "¥400,000", "¥200,000", and "¥300,000" processed in the deposit reconciliation. , and the presence or absence of "reconciliation completed" is updated to "completed".

Also, as shown in FIG. 12(E), the "applied amount" of the deposit data is updated to "¥900,000", and the presence/absence of payment completion is updated to "completed".

If the transaction classification targeted for reconciliation this time among the reconciliation candidates corresponds to "advance billing", additional pre-received detail data is generated. It is generated using the information on the payment reconciliation screen, the reconciliation data, the collection schedule data, and the updated results of the payment data.

Advance receipt detail data as shown in FIG. 12(F) is created. In the example of advance receipt detail data shown in FIG. , Project No. "Blank", Advance Received Amount "¥200,000", Advance Received Allocation Amount "0", Allocation Completed "Unfinished". The second line is the deposit number "NY0003", the advance receipt serial number "2", the billing destination "SEI001: □△ industry", the receivables category "uncompleted construction receipt", the project number "blank", and the amount of advance receipt "300". , 000”, the pre-received allocated amount is “0”, and the allocation is completed “not yet”.

FIG. 13 is a diagram for explaining order data (for explaining the sales input screen). FIG. 13A is a diagram showing an example of order data. In the order data shown in FIG. 13A, the first line is order number "JC0001", line "1", order date "2018/03/01", department "BMN001: Sales Department 1", billing address "SEI001". : △ Industry", Product "IS0001: Equipment construction set", Number of sales "1", Amount of sales "¥7,000,000", Receivables category "Receivables from completed construction", Project No. "PJ0001" there is The second line is order number "JC0002", line "1", order date "2018/03/01", department "BMN001: Sales Department 1", billing destination "SEI002: ○△ real estate", product "IS0001: equipment" A complete set of construction work", the number of sales of "1", the amount of sales of "¥5,000,000", the credit item category of "accrued income from completed construction work", and the project number of "PJ0003". The third line is order number "JC0003", line "1", order date "2018/04/01", department "BMN001: Sales Department 1", billing destination "SEI001: □△ industry", product "AC002: X". company's air conditioner", the number of sales of "3", the amount of sales of "¥200,000", the credit item category of "accounts receivable", and the project number of " ".

FIG. 13B shows the sales input screen, and the order data of order No. "JC0001" is read and displayed. When you press the advance payment allocation button, it becomes available if there is an advance payment balance that can be allocated to the sales.

FIG. 14 is a diagram for explaining the allocation of advance receipts. FIG. 15 is a diagram for explaining data generated and updated by allocating advance receipts.

FIG. 14A is a summary of advance receipt detail data. It is determined whether or not there is any data that meets the following conditions among the detailed data received in advance, and the corresponding detailed data received in advance is displayed on the pre-received allocation screen.
(1) Matches screen billing address.
(2) If the project number on the screen is not blank, the project numbers match.
(3) The project number of the advance receipt details is blank.
(4) Allocation completion is "unfinished".

In the example shown in FIG. 14(A), the billing destination and the project match in the first line, and are unallocated, so this applies. The second line does not correspond because the billing destinations do not match. The third line is applicable because the billing destination is the same, the project is blank, and it is unallocated. The fourth line is applicable because the billing destination is the same, the project is blank, and it is unallocated.

FIG. 14B is a diagram showing an example of the pre-received hit screen. In the prepayment screen, the header part is the billing destination, slip amount, and prepayment amount, and the detail part is the receipt number, prepayment sequence number, credit item classification, project No., prepayment amount, and prepayment payment completed. The amount, the amount allocated this time, and the balance after this allocation.

The amount of money received in advance is indicated by the detail data of the advance receipt. The amount paid in advance is displayed from the amount paid in advance in the detailed data of advance receipts. At the time of correction registration, the amount allocated this time before correction (scheduled collection: amount to be applied, which will be described later) will be deducted. The operator inputs the allocation amount this time. The current apportionment balance can be changed within a range of 0 or more. The balance after this allocation is calculated and displayed each time the amount of this allocation is entered. Amount of advance received - Amount of advance receipt allocated - Amount of current allocation.

In the example shown in FIG. 14, the billing destination is "SEI001: □△ industry", and FIG. there is Out of the 2,500,000 yen that can be allocated, the total amount of '2,300,000 yen' that matches the project, the project is blank, and the receivables category is 'uncompleted construction receipts' will be allotted and registered as sales. I do.

When the sales are registered, collection schedule data as shown in FIG. 15(B) is created. The scheduled collection data is divided into the details of the remaining allocation and the details of the allocation for the sake of convenience, because the advance received was partially applied to the sales amount. The latter sets the cleared, advance receipt at the time of sale FLG to "1". "Prepaid payment amount" on the prepayment payment screen at the time of sales entry correction is the payment application data described later, and the amount to be applied this time from the collection schedule SEQ with the same FLG of the same slip number as "1". to aggregate and display.

In the scheduled collection data shown in FIG. Scheduled date "2018/05/31", department "BMN001: Sales Department 1", billing address "SEI001: △ Industry", expense item " ", billing number " ", expected collection amount "¥4,700,000 (= ¥7,000,000-¥2,300,000)”, Applied Amount “0”, Applied “Unfinished”, Receivables Category “Accrued Income from Completed Construction”, Project No. “PJ0001”, Before Sales Allocation FLG becomes "0". The second line contains collection SEQ "SQ06", slip type "sales", transaction type "pre-construction sales", slip number "UR0001", line number "1", scheduled collection date "2018/05/31", department " BMN001: Sales Department 1”, billing address “SEI001: □△ industry”, expense item “ ”, billing number “ ”, expected collection amount “2,300,000”, applied amount “2,300,000”, consumption "Done", receivables category "accrued income from completed construction", project No. "PJ0001", and pre-allocation FLG "1" at the time of sales.

Also, dummy deposit data as shown in FIG. 15(C) is created. The first line is the deposit number "NY0004", the line number "1", the deposit date "2018/4/20", the department "BMN001: Sales Department 1", the billing destination "SEI001: □△ industry", the transaction classification "previous Received Offset", Deposit Amount "¥2,000,000", Applied Amount "¥2,000,000", Applied "Done", Advance Received Offset Receipt Number "NY0001", Advance Received Offset Receipt Serial Number becomes "1". The second line is the deposit number "NY0004", the line number "2", the deposit date "2018/4/20", the department "BMN001: Sales Department 1", the billing destination "SEI001: □△ industry", the transaction classification "previous Received Offset", Deposit Amount "¥300,000", Applied Amount "¥300,000", Applied Completion "Done", Advance Received Offset Receipt Number "NY0003", Advance Received Offset Receipt Serial Number "2" Become.

Also, deposit reconciliation data as shown in FIG. 15(D) is created. The deposit application data shown in FIG. 15(D) includes the deposit application number "NK0004", the line number "1", the payment application date "2018/4/20", the collection SEQ "SQ06", and the current application amount " ¥2,300,000” and the deposit number “NY0004”.

The pre-received detailed data is updated as shown in FIG. 15(E). The first line has been updated to "¥2,000,000" and the allocation has been completed. be.

Dummy deposits are generated in the virtual transaction classification of "offset of advance receipts" by prepayment, and data is created by reconciling the deposits. Journal entries are not generated from deposits of virtual denominations. FIGS. 15F and 15G show journal entries.

FIG. 16 is a diagram for explaining billing of the balance. FIGS. 16A and 16B are the same as FIGS. 15A and 15B.

If the billing amount (¥7,000,000) is calculated from the sales data as in a general system, the amount up to the advance received is included in the amount. Whether or not a request is required and whether or not a claim is made are managed on the collection schedule, and the billed amount is calculated from the scheduled collection amount. The requirements are that the billing number of the scheduled collection data is blank (not billed yet), and that the reconciliation of the scheduled collection data is not complete (receivables have not been reconciled). Here, only the collection scheduled SQ=SQ05 is targeted. If multiple scheduled collections are covered, a summary of the scheduled collection amount will be covered.

FIG. 16C is an image of invoice data. In the example shown in the figure, the billing number is "SE0004", the billing date is "2018/04/20", the billing destination is "□△ Industry (SEI001)", the current billing amount is "¥4,700,000", and the sales representative is "Sales 1 copy (BMN001)".

FIGS. 17 to 19 are diagrams for explaining advance payments for cases that are not linked to projects. The following explanation is based on the premise that the allocation before this section has not been carried out.

On the sales input screen shown in FIG. 17A, the order number "JC0003" is entered, and the order data on the third line in FIG. 13A is read and displayed. The billing destination is "SEI001 □△ industry", the sales amount is "¥200,000", and the credit item classification is "accounts receivable".

When the pre-received allocation button is pressed, a pre-received allocation screen as shown in FIG. 17(C) is displayed. On the pre-receipt allocation screen in FIG. 17(C), out of the pre-receipt detail data in FIG. extracted and displayed. Advances received for other projects are not extracted as allocation targets. The sales amount will be fully allocated to the details of the receivables category "Advance received". In the example shown in the figure, the full amount of the slip amount "¥200,000" is appropriated to the current allotted amount on the first line.

FIG. 18 shows the generated data. The scheduled collection data as shown in FIG. 18(B) is created, and the scheduled collection amount "¥200,000", the applied amount "¥200,000", the applied amount "completed", and the prepayment FLG at the time of sale. It is "1". In the previous example, the collection schedule was divided because there was an unallocated amount for the sales amount.

Dummy deposit data as shown in FIG. 18(C) is created. In addition, deposit reconciliation data as shown in FIG. 18(C) is created. Further, the pre-received detailed data is updated as shown in FIG. 18(E).

FIG. 19 is a diagram for explaining sales recording. On the sales input screen shown in FIG. 19,
It cannot be used because there is no advance payment balance that can be appropriated to the sales.

As described above, according to the present embodiment, the deposit reconciliation processing unit 102a reconciles the amount of money received and the expected collection amount of the previous bill, and after the reconciliation, the The advance receipt details creating unit 102b for creating the advance receipt details and the advance receipt sales allocation unit 102c for allocating the advance receipt details that can be allocated to the sales are provided, thereby facilitating the management of the advance receipt. At the same time, it is possible to improve the degree of freedom in appropriating sales.

[4. Other embodiments]
The present invention may be implemented in various different embodiments other than the embodiments described above within the scope of the technical idea described in the claims.

For example, among the processes described in the embodiments, all or part of the processes described as being automatically performed can be manually performed, or the processes described as being performed manually can be performed manually. All or part of this can also be done automatically by known methods.

In addition, unless otherwise specified, the processing procedures, control procedures, specific names, information including parameters such as registration data and search conditions for each process, screen examples, and database configurations shown in this specification and drawings can be changed arbitrarily.

Further, with respect to the advance receipt management device 100, each illustrated component is functionally conceptual, and does not necessarily need to be physically configured as illustrated.

For example, the processing functions of the advance receipt management device 100, particularly the processing functions performed by the control unit 102, are implemented in whole or in part by a CPU and a program interpreted and executed by the CPU. Alternatively, it may be implemented as hardware using wired logic. The program is recorded on a non-temporary computer-readable recording medium containing programmed instructions for causing the information processing device to execute the processing described in the present embodiment, and the advance receipt management device is recorded as necessary. 100 mechanically read. That is, a storage unit such as a ROM or HDD (Hard Disk Drive) stores a computer program for giving instructions to the CPU in cooperation with the OS to perform various processes. This computer program is executed by being loaded into the RAM and constitutes a control section in cooperation with the CPU.

Further, this computer program may be stored in an application program server connected to the advance receipt management device 100 via any network, and all or part of it can be downloaded as necessary. be.

Also, the program for executing the processing described in this embodiment may be stored in a non-temporary computer-readable recording medium, or may be configured as a program product. Here, the term "recording medium" refers to memory cards, USB (Universal Serial Bus) memories, SD (Secure Digital) cards, flexible disks, magneto-optical disks, ROMs, EPROMs (Erasable Programmable Read Only Memory), EEPROMs (registered Trademark) (Electrically Erasable and Programmable Read Only Memory), CD-ROM (Compact Disk Read Only Memory), MO (Magneto-Optical disk), DVD (Digital Versatile Disk), and Disc (Registered trademark) such as Blu- shall include any "portable physical medium".

A "program" is a data processing method written in any language or writing method, regardless of the format such as source code or binary code. In addition, the "program" is not necessarily limited to a single configuration, but is distributed as multiple modules or libraries, or cooperates with a separate program represented by the OS to achieve its function. Including things. It should be noted that well-known configurations and procedures can be used for the specific configuration and reading procedure for reading the recording medium in each device shown in the embodiments, the installation procedure after reading, and the like.

The various databases and the like stored in the storage unit 106 are storage means such as memory devices such as RAM and ROM, fixed disk devices such as hard disks, flexible disks, and optical disks, and are used for various processes and website provision. programs, tables, databases, and files for web pages.

Further, the advance receipt management device 100 may be configured as an information processing device such as a known personal computer or workstation, or may be configured as the information processing device to which any peripheral device is connected. Further, the advance receipt management device 100 may be realized by installing software (including programs, data, etc.) for realizing the processing described in the present embodiment in the device.

Furthermore, the specific forms of distribution and integration of devices are not limited to those shown in the figures, and all or part of them can be functionally or physically arranged in arbitrary units according to various additions or functional loads. It can be distributed and integrated. In other words, the embodiments described above may be arbitrarily combined and implemented, or the embodiments may be implemented selectively.

100 Advance receipt management device 102 Control unit 102a Receipt reconciliation processing unit 102b Advance receipt details creation unit 102c Advance receipt sales allocation unit 102d Master maintenance unit 104 Communication interface unit 106 Storage unit 106a Item classification master 106b Transaction classification master 106c Expense item master 106d Billing destination Master 108 Input/output interface unit 112 Input device 114 Output device 200 Server 300 Network

Claims (1)

An advance receipt management device comprising a control unit,
The control unit
a payment reconciliation means for reconciling the amount of money received and the expected collection amount of the claim related to the previous claim;
pre-receipt details creating means for creating pre-receipt details of the claim related to the previous claim after reconciliation;
advance receipt sales allocation means for allocating the allocable items among the advance receipt details to the sales;
An advance receipt management device comprising:

Images