JP7783219B2 - Commercial transaction status management device, commercial transaction status management method, and commercial transaction status management program - Google Patents

Description

The present invention relates to a commercial transaction status management device, a commercial transaction status management method, and a commercial transaction status management program.

The receivables and payables management device disclosed in Patent Document 1 (JP 2017-174389 A) displays the business establishment data and department data included in the basic information corresponding to the customer data selected by the user in a changeable manner. When the user changes this basic information, the device obtains receivables and payables management information including the changed business establishment data of the receivables and payables management business and/or the changed department data of the receivables and payables management department, as well as the unchanged basic information. The device then controls the user to input transaction detail data including the amount, transaction date, and transaction method corresponding to the receivables and payables management information, and obtains and registers the transaction data including the receivables and payables management information and transaction detail data.

In this way, by setting up receivables and payables management information on the system, operations and management can be easily carried out even if receivables and payables management information is changed or added.

JP 2017-174389 A

There is a need for the development of a device that can check the status of commercial transactions with business partners.

The present invention was made in consideration of the above-mentioned problems, and aims to provide a business transaction status management device, a business transaction status management method, and a business transaction status management program that enable confirmation of the status of business transactions with trading partners.

In order to solve the above-mentioned problems and achieve the object, the commercial transaction status management device of the present invention has a comparison unit that, when a transaction date of a commercial transaction with a business partner is input, compares it with the last transaction date, which is the previous transaction date stored in the memory unit; an update unit that updates the last transaction date in the memory unit to the transaction date when the comparison unit obtains a comparison result that the transaction date is a date after the last transaction date; and an output control unit that controls the output of the updated last transaction date to an output device , and the memory unit stores, in addition to the last transaction date, the closing date, which is the last day of each predetermined accounting period determined by the business partner, the collection month, which is the number of months required from the closing date to payment, which is determined by the business partner, and The payment system further comprises a closing date generation unit that stores the collection date, which is the date on which payment is made in the collection month, and refers to the memory unit to generate a closing date belonging to the collection month for collecting payment on the transaction date as the closing date corresponding to the commercial transaction on the transaction date; a scheduled collection date generation unit that refers to the memory unit to add the collection month to the month to which the closing date belongs and add the collection date to generate a scheduled collection date, which is a date; and a collection schedule generation unit that generates a collection schedule including the scheduled collection date, the final transaction date, the sales amount generated by the commercial transaction, and the amount received from the business partner in relation to the sales amount, and the output control unit controls the output of the generated collection schedule to an output device.

In order to solve the above-mentioned problems and achieve the object, a commercial transaction status management method performed by a commercial transaction status management device according to the present invention includes a comparison step in which a comparison unit, when inputting a transaction date on which a commercial transaction was conducted with a business partner, compares the input transaction date with a last transaction date, which is the previous transaction date, stored in a storage unit; an update step in which an update unit, when obtaining a comparison result from the comparison unit that indicates that the transaction date is a date after the last transaction date, updates the last transaction date in the storage unit to the transaction date; and an output control step in which an output control unit controls output of the updated last transaction date to an output device, wherein the storage unit stores, in addition to the last transaction date, a closing date, which is the last day of each predetermined accounting period determined by the business partner, a collection month, which is the number of months required from the closing date to payment, which is determined by the business partner, and The payment system further includes a closing date generating step in which a collection date, which is the date on which payment is made in the collection month, is stored in the storage unit, and the closing date generating unit refers to the storage unit and generates a closing date belonging to the collection month for collecting payment on the transaction day as the closing date corresponding to the commercial transaction on the transaction day; a scheduled collection date generating step in which the planned collection date generating unit refers to the storage unit and adds the collection month to the month to which the closing date belongs and the collection date to generate a scheduled collection date, which is a date; and a collection schedule generating step in which the collection schedule generating unit generates a collection schedule including the scheduled collection date, the final transaction date, the sales amount generated by the commercial transaction, and the amount received from the business partner in relation to the sales amount, and the output control step controls output of the generated collection schedule to an output device.

In order to solve the above-mentioned problems and achieve the object, the commercial transaction status management program of the present invention causes a computer to function as a comparison unit that, when a transaction date of a commercial transaction with a business partner is input, compares the input date with the last transaction date stored in the storage unit, which is the previous transaction date; an update unit that, when a comparison result indicating that the transaction date is a date after the last transaction date is obtained from the comparison unit, updates the last transaction date stored in the storage unit to the transaction date; and an output control unit that controls output of the updated last transaction date to an output device, and the storage unit stores, in addition to the last transaction date, a closing date that is the last day of each predetermined accounting period determined by the business partner, and a collection month that is the number of months required from the closing date to payment, which is determined by the business partner. The computer further functions as a closing date generation unit that refers to the memory unit and generates a closing date belonging to the collection month for collecting payment on the transaction day as the closing date corresponding to the commercial transaction on the transaction day, a scheduled collection date generation unit that refers to the memory unit and adds the collection month to the month to which the closing date belongs and the collection date to generate a scheduled collection date, which is a date, and a collection schedule generation unit that generates a collection schedule including the scheduled collection date, the final transaction date, the sales amount generated by the commercial transaction, and the amount received from the business partner in relation to the sales amount, and the output control unit controls the output of the generated collection schedule to an output device.

The present invention allows you to check the status of commercial transactions with business partners.

FIG. 1 is a block diagram showing the hardware configuration of a business transaction status management device according to an embodiment of the present invention. FIG. 2 is a diagram illustrating an example of the customer master. FIG. 3 is a diagram showing an example of the billing destination master. FIG. 4 is a diagram for explaining an outline of the operation of the commercial transaction status management device according to the embodiment. FIG. 5 is a diagram showing an example of a sales input screen. FIG. 6 is a diagram showing an example of sales data. FIG. 7 is a diagram for explaining the operation of updating the last transaction date of the billing destination master. FIG. 8 is a diagram for explaining the operation of specifying the closing sales date. FIG. 9 is a diagram for explaining an operation of resetting the scheduled collection date to a date that exists in the scheduled collection month when the identified scheduled collection date does not exist in the scheduled collection month. FIG. 10 is a diagram showing an example of a collection schedule. FIG. 11 is a diagram showing an example of sales data and deposit data.

The following describes in detail a commercial transaction status management device according to an embodiment of the present invention, with reference to the accompanying drawings. Note that the present invention is not limited to the following embodiment.

(Hardware configuration)
As shown in FIG. 1 , the transaction status management device 1 of the embodiment includes a storage unit 2, a control unit 3, a communication interface unit 4, and an input/output interface unit 5. An input device 6 and an output device 7 are connected to the input/output interface unit 5. The output device 7 may be a display unit such as a monitor device (including a home television), a printer, or a speaker device. The input device 6 may be a keyboard device, a mouse device, a microphone device, or a monitor device that functions as a pointing device in cooperation with a mouse device. The communication interface unit 4 is connected to a network, such as a wide area network like the Internet or a private network like a local area network (LAN).

The memory unit 2 can be, for example, a storage device such as ROM (Read Only Memory), RAM (Random Access Memory), HDD (Hard Disk Drive), or SSD (Solid State Drive). The memory unit 2 stores a transaction status management program for managing transaction status. The memory unit 2 also stores a customer master data 11, a billing destination master data 12, collection schedule data, sales data, and deposit data.

As shown in Figure 2, the customer master 11 contains customer codes, customer names, and billing destination codes. This customer master 11 associates customers with billing destinations. In the example of Figure 2, the customer code for customer A is "T001," and billing for this customer is performed using the billing destination code "S001."

As shown in Figure 3, the billing destination master 12 is composed of the billing destination code, billing destination name, last transaction date, closing date, collection month, and collection date. The "last transaction date" indicates the last date on which a transaction with the customer was conducted, and indicates that no other transactions have been conducted since that date.

The "closing date" is the last day of each specified accounting period for that customer. The "collection month" is the number of months from the "closing date" to payment. In other words, the "collection month" is the month in which a date after the "closing date" falls, and is the number of months until the month in which the amount invoiced to that customer can be collected. The "collection date" is the date on which payment is made in the "collection month."

The example in Figure 3 shows that the final transaction for the billing code "S001" and billing name "Billing A" is "April 20, 2022," as indicated by the "Last Transaction Date." The example in Figure 3 also shows that the closing date for "Billing A" is the "31st (or last day)" of each month, and that the invoice amount can be collected "1" month after this closing date, with the collection date being the "31st (or last day)" of the month corresponding to the collection month.

(Functional configuration of the commercial transaction status management device)
Next, the control unit 3 executes the transaction status management program stored in the memory unit 2, and thereby functions as a comparison unit 21, an update unit 22, a display control unit 23 (an example of an output control unit), a closing date generation unit 24, a scheduled collection date generation unit 25, and a collection schedule generation unit 26, as shown in FIG. 1.

When the transaction date of a business transaction with a business partner (customer, billing partner) is entered, for example, during order entry or sales entry, the comparison unit 21 compares it with the last transaction date, which is the previous transaction date stored in the memory unit (billing partner master 12).

When the comparison unit obtains a comparison result in which the transaction date is a date after the last transaction date, the update unit 22 updates the last transaction date in the memory unit (billing destination master 12) to the input transaction date. The output control unit (for example, the display control unit 23) controls the output of the updated last transaction date to an output device (such as a monitor, memory device, speaker, or printer).

In addition to the last transaction date, the storage unit (billing destination master 12) also stores the closing date, which is the last day of each specified accounting period determined by the business partner, the collection month, which is the number of months required from the closing date determined by the business partner to payment, and the collection date, which is the date on which payment is made in the collection month. The closing date generation unit 24 references the storage unit (billing destination master 12) and generates the closing date belonging to the collection month for collection of payment for the transaction date as the closing date corresponding to the commercial transaction on the transaction date.

The planned collection date generation unit 25 references the memory unit (billing destination master 12) and generates the planned collection date by adding the collection month to the month to which the closing date belongs and the collection date. The collection schedule generation unit 26 generates a collection schedule that includes the planned collection date, the last transaction date, the sales amount generated by the commercial transaction, and the amount received from the business partner in relation to the sales amount. The output control unit (for example, the display control unit 23) controls the output of the generated collection schedule to an output device (such as a monitor, storage device, speaker, or printer).

In addition, if the generated scheduled collection date is a date that does not exist, the scheduled collection date generation unit 25 sets the scheduled collection date to a date that exists in the month to which the generated scheduled collection date belongs.

(Outline of operation of the commercial transaction status management device)
Next, when a transaction input such as an order entry or sales entry is received, the transaction status management device 1 according to the embodiment updates the most recent transaction date, which is the most recent date from among the past dates on which a transaction with a business partner (customer, billing partner) was performed and stored in the billing partner master 12, to the input transaction date, as shown in Figure 4. This most recent transaction date is a date that indicates the transaction status with the business partner. In other words, if there is a period of time, such as two months or more, between the most recent transaction date and the current date, it is difficult to say that the transaction status is smooth, and measures such as a credit re-investigation can be taken.

Furthermore, the commercial transaction status management device 1 of the embodiment references the customer master 11 and the billing destination master 12 based on the input sales data, and generates a collection schedule including a receivables collection schedule for the customer. The "scheduled collection date" calculated based on the billing destination master 12 is input to this collection schedule. This makes it possible to check the collection schedule for uncollected receivables by referring to the collection schedule.
(Last trading day update operation)
First, we will explain the operation of updating the last transaction date of the billing destination master data 12. This update operation is performed by the control unit 3 of the transaction status management device 1, which functions as the following units based on the transaction status management program stored in the storage unit 2.

First, when an operator receives an order for a commercial transaction, the operator operates the input device 6 to select the display of the order entry screen in order to enter the order. Alternatively, when a commercial transaction is completed, the operator operates the input device 6 to select the display of the sales entry screen in order to enter the sales. The following explanation will use sales entry as an example.

When the operator specifies that the sales input screen be displayed, the display control unit 23 displays the sales input screen shown in Figure 5 via the output device 7. As shown in Figure 5, the sales input screen includes a display field for the order number, an input field for the business code, an input field for the sales date, an input field for the customer code, an input field for the person in charge, an input field for the delivery destination, and an input field for the supplier.

The sales input screen also has input fields for the purchase date, billing code, expected collection date, sales currency, sales rate, purchase currency, and purchase rate. The sales input screen also has input fields for details of the sold items, such as the order type, product name, quantity, and unit price.

Based on the input content on the sales input screen, the data generation unit 27 generates sales data including the sales number, line number, sales category, business establishment code, sales date, person in charge code, customer code, billing destination code, delivery destination code, supplier code, product name, quantity (sales quantity), unit sales price, and amount (sales amount), as shown in Figure 6, and stores the data in the memory unit 2.

The example sales data shown in Figure 6 is an example of sales data for "direct sales," in which goods are delivered directly from a supplier's warehouse to a customer. For this reason, the sales category is "direct sales." The example in Figure 6 shows an example where the sales date is "July 24, 2022," and two cases of ammonia with product code "SH01" and ten cases of nitric acid with product code "SH02" were sold. The example in Figure 6 also shows an example where the sales price for two cases of ammonia was 1,300 yen, resulting in a sales amount of 2,600 yen. The sales price for ten cases of nitric acid was 950 yen, resulting in a sales amount of 9,500 yen.

On the other hand, when a customer code, sales date, etc. are entered via the sales input screen, the comparison unit 21 references the customer master 11 shown in Figure 2 based on the entered customer code and detects the billing code associated with the entered customer code. In the example of Figure 5, because the customer code "T001" was entered via the sales input screen, the comparison unit 21 detects the billing code "S001" from the customer master 11, which is associated with the customer code "T001".

The comparison unit 21 also references the billing destination master 12 shown in Figure 3 based on the billing destination code "S001" detected from the customer master 11, and detects the last transaction date for "billing destination A" with the billing destination code "S001." The comparison unit 21 then compares the detected last transaction date with the sales date (an example of a transaction date) entered via the sales input screen. In the examples of Figures 3 and 5, the sales date for "billing destination A" entered via the sales input screen is "July 24, 2022," while the last transaction date for "billing destination A" stored in the billing destination master 12 is "April 20, 2022." Therefore, the comparison unit 21 outputs a comparison result in which the sales date is a date after the last transaction date.

When the comparison unit 21 obtains a comparison result in which the sales date is a date after the last transaction date, the update unit 22 updates the last transaction date for that invoice destination in the invoice destination master data 12 to the date of the sales date. In the above example, the sales date for "invoice destination A" is "July 24, 2022," and the last transaction date in the invoice destination master data 12 is "April 20, 2022." Therefore, the comparison unit 21 obtains a comparison result in which the sales date is a date after the last transaction date, and the update unit 22 updates the last transaction date of "April 20, 2022" in the invoice destination master data 12 to the sales date of "July 24, 2022," as shown in FIG. 7. The display control unit 23 displays the invoice destination master data 12, including the last transaction date, via the output device 7 at a predetermined timing, such as a timing specified by the operator.

This last transaction date is the date that indicates the status of commercial transactions with the billing party. In other words, if there is a period of time between the last transaction date and the current date in which no commercial transactions have taken place, such as two months or more, it is difficult to say that the commercial transaction status is smooth, and a department that conducts credit investigations, such as the Risk Assessment Department, can take measures such as conducting a credit re-investigation.

(Generation of collection schedule)
Next, by creating a collection schedule that includes the planned collection date, collection rate, etc. along with the final transaction date, it becomes possible to check collection work that cannot be covered by credit checks alone, even for regular business partners, from a perspective separate from credit management, such as when the collection rate is low despite the transaction date being recent.

That is, when entering sales (or orders, etc.) as described above (preferably after the last transaction date has been updated), the closing date generation unit 24 references the sales date entered on the sales input screen (see Figures 5 and 6) and the "closing date," "collection month," and "collection date" in the billing master 12 shown in Figure 3, and generates a closing date corresponding to the sales date, as shown in Figure 8.

That is, if the sales date is "September 25th" as in the example of Figure 8, the closing date generation unit 24 obtains the closing date of "the 31st" as the closest closing date after the 25th. However, since this closing date of "the 31st" belongs to the month before the "collection month," the closing date generation unit 24 detects the closing dates of "the 10th" and "the 20th" of the following month as closing dates after the 31st, and generates "October 20th (2009)," which is the closing date closest to the "collection date," "the 31st (last day)."

Next, the planned collection date generation unit 25 references the billing destination master 12, adds the collection month to the month to which the closing date generated as described above belongs, and adds the collection date to this added date to generate the planned collection date.

In other words, in the above example, for a sales date of "September 25th," the closing date generated by the closing date generation unit 24 is "October 20th, 2009." As stored in the billing destination master 12 shown in Figure 3, the collection month is "1" and the collection date is "31st." Therefore, as shown in Figure 9, the scheduled collection date generation unit 25 adds the collection month of "January" to October 2009 to obtain "November 2009," and then adds the collection date of "31st" to this "November 2009" to obtain "November 31st, 2009."

Here, the last day of November is not the 31st, but the 30th. In this way, if the generated scheduled collection date does not exist, the scheduled collection date is generated as "November 30th, 2009", which is a date in the month to which the generated scheduled collection date belongs. This means that even for months such as February, which do not have a "31st" as their last day, the scheduled collection date can be corrected to the 28th (or 29th: leap year) and generated.

Next, the collection schedule generation unit 26 references the sales data shown in Figure 11(a) and the deposit data shown in Figure 11(b) and calculates the "deposit amount/sales amount" to calculate the collection rate for that customer and sales. The deposit data is entered by the operator using a deposit input screen (not shown) and is stored in the memory unit 2 by the data generation unit 27. Note that the deposit data and sales data may be obtained from the accounting server device via a network, etc., or may be obtained and used from data stored in external memory.

For example, the collection schedule generation unit 26 determines that the sales amount to the billing recipient with billing code "S001" in the first record in Figure 11(a) is "2,800 yen," while the amount received from the billing recipient with billing code "S001" is "2,800 yen," as shown in the first record in Figure 11(b). In this case, the collection rate is "2,800 yen / 2,800 yen = 100%."

However, as shown in Figure 11(a), there are sales amounts of "6,750 yen" and "12,100 yen" other than "2,800 yen" for the billing recipient with billing code "S001." However, as shown in Figure 11(b), no deposits have been made for these sales. In this case, the recovery rates are "0 yen (= amount received) / 6,750 yen" and "0 yen (= amount received) / 12,100 yen," and the recovery rates for each are "0%."

In other words, the billing recipient with billing code "S001" deposited "2,800 yen" for sales of "2,800 yen," but deposited "0 yen" for sales of "6,750 yen" and "12,100 yen."

On the other hand, the record on line 4 of Figure 11(a) shows a deposit for sales of "6,800 yen" to a billing recipient with billing code "S002", but as shown in Figure 11(b), the deposit is in a state of "0 yen". Therefore, the result is "0 yen (= deposit amount) / 6,800 yen", and in this case too the recovery rate is "0%".

Furthermore, the records on lines 5 to 8 of Figure 11(a) show deposits for sales of "2,900 yen," "2,900 yen," "7,750 yen," and "5,600 yen" to the billing recipient with billing code "S003." However, as shown in Figure 11(b), deposits of the same amount as the sales amount have been made for all sales except for the deposit for the "5,600 yen" sale. Therefore, the recovery rate for the "5,600 yen" sale is "0%," and the recovery rate for all other sales for billing recipient code "S003" is "100%."

After calculating each recovery rate in this manner, the recovery schedule generation unit 26 generates a recovery schedule including the serial number (No.), business code, billing code, sales amount, planned recovery date, final transaction date, deposit amount, and recovery rate, as illustrated in FIG. 10, based on the sales data shown in FIG. 11(a), the deposit data shown in FIG. 11(b), the planned recovery date generated by the planned recovery date generation unit 25, and the calculated recovery rate, and stores this recovery schedule data in the memory unit 2. The display control unit 23 displays this collection schedule via the output device 7 at a predetermined timing, such as a timing specified by the operator.

For example, in the case of a billing recipient with billing code "S001" in Figure 10, the final transaction date for the transaction of "12,100 yen" in the record on the third line is "July 24, 2022," and the scheduled collection date is "August 31, 2022." Even though this transaction is a recent transaction, the sales amount of "6,700 yen" in the record on the second line has not yet been collected. The collection schedule can be used to examine whether there are any problems with this transaction situation.

Furthermore, for the billing recipient with billing code "S002" in Figure 10, the final transaction date for the "6,800 yen" transaction in the record on line 4 is "April 24, 2022," and the scheduled collection date is "April 30, 2023." Even though the final transaction date for this transaction was approximately one year before the scheduled collection date, the sales proceeds remain uncollected. It is possible to determine whether there are any problems with this transaction status, and whether the scheduled collection date is correct, based on the collection schedule.

The credit check is performed by the comparison unit 21, which calculates the amount using the formula "uncollected receivables amount + backorder amount - order backorder amount - outstanding unpaid debt amount" and determines whether this calculated amount exceeds the credit amount set by the operator for each customer in a credit master (not shown) or other data.

In addition, as one example, such a credit check is performed when an operator such as a field sales representative records the next commercial transaction by entering an order or sales amount.

(Effects of the embodiment)
As is clear from the above explanation, the commercial transaction status management device 1 of the embodiment stores the "last transaction date" in the billing destination master 12 and updates the "last transaction date" for the billing destination of the transaction when entering a transaction, such as when entering an order or sales. This makes it possible to check billing destinations with uncollected receivables by focusing on the last transaction date. It also prevents the inconvenience of overlooking the collection status for each commercial transaction.

Specifically, since the "last transaction date" indicates the status of commercial transactions with the billing party, if there is a period of time between the last transaction date and the current date in which no commercial transactions have taken place, such as two months or more, it is difficult to say that the commercial transaction status is smooth. For this reason, a department that conducts credit investigations, such as the Risk Assessment Department, can take measures such as conducting a credit re-investigation.

In addition, the commercial transaction status management device 1 of the embodiment creates a collection schedule that includes the last transaction date, the planned collection date, the collection rate, etc., making it possible to check the status of commercial transactions with business partners with whom you regularly conduct business from a perspective different from prior credit management. This makes it possible to check the collection status of receivables that cannot be fully addressed by credit checks alone, such as when the collection rate is low despite the sales date being recent. Furthermore, a department that conducts credit investigations, such as the risk screening department, can re-examine credit and review commercial transactions, etc.

For example, chemical trading companies often engage in "direct delivery" transactions, where products are delivered directly from the supplier's warehouse to the customer. Furthermore, due to the large volume of transactions and the large number of stakeholders, it is difficult for the accounting department to handle receivable write-off work alone. It is also difficult for the accounting department to determine whether collection is delayed based solely on the planned collection date for the sales account that is the source of the receivable.

However, the commercial transaction status management device 1 of this embodiment can easily identify billing recipients, etc., based on the "last transaction date," allowing the accounting department to perform reconciliation work on its own. Furthermore, by creating a collection schedule, the accounting department can determine whether to delay collection based solely on the scheduled collection date for the sales account that is the source of the receivable.

Furthermore, companies where the sales department handles debt collection tend to have low debt collection rates. However, the commercial transaction status management device 1 of this embodiment allows companies where the sales department handles debt collection to easily determine collection delays by referring to the scheduled collection date on the collection schedule, thereby improving debt collection rates.

[Contribution to the United Nations-led Sustainable Development Goals (SDGs)]
This embodiment can contribute to improving business efficiency and promoting appropriate management decisions by companies, thereby contributing to the achievement of SDGs Goals 8 and 9.

Furthermore, this embodiment can contribute to reducing waste and promoting paperless and electronic systems, thereby contributing to SDGs Goals 12, 13, and 15.

Furthermore, this embodiment can contribute to strengthening control and governance, thereby contributing to Goal 16 of the SDGs.

Other Embodiments
The present invention may be implemented in various different embodiments other than those described above within the scope of the technical concept set forth in the claims.

For example, of the processes described in the embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using known methods.

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

Furthermore, with regard to the transaction status management device 1, the components shown in the figure are functional concepts and do not necessarily have to be physically configured as shown.

For example, all or any part of the processing functions of the transaction status management device 1, particularly the control unit 3 and the processing functions performed by the control unit 3, may be implemented by a CPU (Central Processing Unit) and a program interpreted and executed by the CPU, or may be implemented as hardware using wired logic. The program is recorded on a non-transitory computer-readable recording medium containing programmed instructions for causing the information processing device to execute the processes described in this embodiment, and is mechanically read by the transaction status management device 1 as needed. In other words, a storage unit such as a ROM or HDD stores a computer program that works in conjunction with the OS to issue commands to the CPU and perform various processes. This computer program is executed by being loaded into RAM, and works in conjunction with the CPU to form the control unit 3.

In addition, the commercial transaction status management program of this commercial transaction status management device 1 may be stored on another server device connected to the commercial transaction status management device 1 via any network, and all or part of it may be downloaded as needed.

The transaction status management program for executing the processing described in this embodiment may be stored on a non-transitory computer-readable recording medium or configured as a program product. Here, "recording medium" includes any portable physical medium, such as a memory card, USB (Universal Serial Bus) memory, SD (Secure Digital) card, flexible disk, magneto-optical disk, 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), and Blu-ray (registered trademark) Disc.

A "program" is a data processing method written in any language or description method, and may be in any format, such as source code or binary code. It should be noted that a "program" is not necessarily limited to a single structure, but also includes a distributed structure consisting of multiple modules or libraries, or a structure that achieves its function by working in conjunction with a separate program, such as an OS. The specific structure and reading procedure for reading a recording medium in the commercial transaction status management device 1 shown in the embodiment, as well as the installation procedure after reading, can use well-known structures and procedures.

The memory unit 2 is a storage means such as a memory device such as RAM or ROM, a fixed disk device such as a hard disk, a flexible disk, or an optical disk, and stores various programs, tables, databases, and web page files used for various processes and website provision.

The transaction status management device 1 may also be configured as an information processing device such as a known personal computer or workstation, or may be configured as an information processing device to which any peripheral device is connected. The information processing device may also be implemented by installing software (including programs or data, etc.) that realizes the processing described in this embodiment.

Furthermore, the specific form of distribution and integration of the devices is not limited to that shown in the figures, and all or part of them can be functionally or physically distributed and integrated in any unit depending on various additions or functional loads. In other words, the above-mentioned embodiments may be implemented in any combination, or embodiments may be implemented selectively.

This invention can be applied to managing the trading status of chemical trading companies, which often conduct direct sales, as well as a variety of other industries.

REFERENCE SIGNS LIST 1 Commercial transaction status management device 2 Storage unit 3 Control unit 4 Communication interface unit 5 Input/output interface unit 6 Input device 7 Output device 11 Customer master 12 Billing destination master 21 Comparison unit 22 Update unit 23 Display control unit 24 Closing date generation unit 25 Planned collection date generation unit 26 Collection schedule generation unit

Claims (4)

a comparison unit that compares, when a transaction date with a business partner is input, the input date with the last transaction date, which is the previous transaction date stored in the storage unit;
an update unit that updates the last trading date in the storage unit to the trading date when the comparison unit obtains a comparison result indicating that the trading date is a date after the last trading date;
an output control unit that controls output of the updated last trading date to an output device;
The storage unit stores, in addition to the final transaction date, a closing date which is the last day of each predetermined accounting period determined by the business partner, a collection month which is the number of months required from the closing date to payment determined by the business partner, and a collection date which is the date on which payment is made in the collection month,
a closing date generating unit that references the storage unit and generates the closing date belonging to the collection month in which the payment on the transaction date is collected as the closing date corresponding to the commercial transaction on the transaction date;
a scheduled collection date generating unit that references the storage unit, adds the collection month to the month to which the closing date belongs, and adds the collection date to generate a scheduled collection date, which is a date;
a collection schedule generating unit that generates a collection schedule including the scheduled collection date, the final transaction date, the sales amount generated by the commercial transaction, and the amount of receipts from the business partner relative to the sales amount,
the output control unit controls output of the generated collection schedule to the output device;
A business transaction status management device comprising : When the generated scheduled collection date is a date that does not exist, the scheduled collection date generation unit sets a date in a month to which the generated scheduled collection date belongs as the scheduled collection date;
2. The business transaction status management device according to claim 1, wherein: a comparison step in which the comparison unit compares, when the transaction date of a business transaction with a trading partner is input, the input date with the last transaction date, which is the previous transaction date stored in the storage unit;
an updating step in which, when a comparison result indicating that the trading date is a date after the last trading date is obtained from the comparison unit, the updating unit updates the last trading date in the storage unit to the trading date;
an output control step in which an output control unit controls an output of the updated last trading date to an output device;
The storage unit stores, in addition to the final transaction date, a closing date which is the last day of each predetermined accounting period determined by the business partner, a collection month which is the number of months required from the closing date to payment determined by the business partner, and a collection date which is the date on which payment is made in the collection month,
a closing date generation step in which a closing date generation unit references the storage unit and generates the closing date belonging to the collection month in which the payment for the transaction date is collected as the closing date corresponding to the commercial transaction for the transaction date;
a scheduled collection date generation step in which a scheduled collection date generation unit references the storage unit, adds the collection month to the month to which the closing date belongs, and adds the collection date to generate a scheduled collection date, which is a date;
a collection schedule generating step in which a collection schedule generating unit generates a collection schedule including the scheduled collection date, the final transaction date, the sales amount generated by the commercial transaction, and the amount of receipts from the business partner relative to the sales amount,
In the output control step, the generated collection schedule is output to the output device.
A commercial transaction status management method performed by a commercial transaction status management device. Computer,
a comparison unit that compares, when a transaction date with a business partner is input, the input date with the last transaction date, which is the previous transaction date stored in the storage unit;
an update unit that updates the last trading date in the storage unit to the trading date when the comparison unit obtains a comparison result indicating that the trading date is a date after the last trading date;
functioning as an output control unit that controls output of the updated last trading date to an output device;
The storage unit stores, in addition to the final transaction date, a closing date which is the last day of each predetermined accounting period determined by the business partner, a collection month which is the number of months required from the closing date to payment determined by the business partner, and a collection date which is the date on which payment is made in the collection month,
a closing date generating unit that references the storage unit and generates the closing date belonging to the collection month in which the payment on the transaction date is collected as the closing date corresponding to the commercial transaction on the transaction date;
a scheduled collection date generating unit that references the storage unit, adds the collection month to the month to which the closing date belongs, and adds the collection date to generate a scheduled collection date, which is a date;
causing the computer to further function as a collection schedule generating unit that generates a collection schedule including the scheduled collection date, the final transaction date, the sales amount generated by the commercial transaction, and the amount of receipts from the business partner relative to the sales amount;
the output control unit controls output of the generated collection schedule to the output device;
A business transaction status management program characterized by: