Commercial transaction status management device, commercial transaction status management method, and commercial transaction status management program

Abstract

To provide a commercial transaction status management device, a commercial transaction status management method, and a commercial transaction status management program that enable confirmation of a commercial transaction status of a customer.SOLUTION: A comparison unit compares, when a transaction date when a commercial transaction is carried out with a customer is input, the transaction date with a last transaction date, which is a previous transaction date stored in a storage unit. An update unit updates, when the comparison unit obtains a comparison result in which the transaction date is a date after the last transaction date, the last transaction date in the storage unit to the transaction date. An output control unit controls an output of the updated last transaction date to an output apparatus. A user can check, on the basis of the last transaction date, a transaction status of a customer.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to a commercial transaction status management device, a commercial transaction status management method, and a commercial transaction status management program. [Background technology]

[0002] The receivables / payables management device disclosed in Patent Document 1 (JP Patent Publication 2017-174389 A) displays the 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 / payables management information including changed data including the establishment data of the changed receivables / payables management establishment and / or the changed department data of the changed receivables / payables management department, as well as the unchangeable data of the 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 / payables management information, and obtains and registers transaction data including the receivables / payables management information and transaction detail data.

[0003] In this way, by setting the receivables / payables management information on the system, even if the receivables / payables management information is changed or added, it can be easily operated and managed. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] JP 2017-174389 A Summary of the Invention [Problem to be solved by the invention]

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

[0006] The present invention has been made in consideration of the above-mentioned problems, and aims to provide a commercial transaction status management device, a commercial transaction status management method, and a commercial transaction status management program that enable confirmation of the status of commercial transactions with trading partners. [Means for solving the problem]

[0007] In order to solve the above-mentioned problems and achieve the object, the business transaction status management device of the present invention has a comparison unit that, when a transaction date on which a business transaction was conducted with a trading partner is input, compares it with the previous transaction date, which is the last 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 a comparison result is obtained from the comparison unit 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.

[0008] In addition, in order to solve the above-mentioned problems and achieve the object, the method for managing business transaction status according to the present invention includes a comparison step in which a comparison unit compares, when a transaction date on which a business transaction was conducted with a trading partner is input, the input transaction date with the last transaction date, which is the previous transaction date stored in the memory unit; an update step in which, when a comparison result is obtained from the comparison unit in which the transaction date is a date after the last transaction date, an update step in which an update unit updates the last transaction date in the memory unit to the transaction date; and an output control step in which an output control unit controls the output of the updated last transaction date to an output device.

[0009] In addition, 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 compares the transaction date when a commercial transaction was conducted with a trading partner, which is the previous transaction date stored in the memory unit, when the transaction date is input, with the last 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 in which 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. Effect of the Invention

[0010] The present invention makes it possible to check the status of commercial transactions with business partners. [Brief description of the drawings]

[0011] [Figure 1] FIG. 1 is a block diagram showing a hardware configuration of a business transaction status management device according to an embodiment. [Diagram 2] FIG. 2 is a diagram illustrating an example of the customer master. [Diagram 3] FIG. 3 is a diagram illustrating an example of the billing destination master. [Figure 4] FIG. 4 is a diagram for explaining an outline of the operation of the business transaction status management device according to the embodiment. [Diagram 5] FIG. 5 is a diagram showing an example of the sales input screen. [Figure 6] FIG. 6 is a diagram illustrating an example of sales data. [Figure 7] FIG. 7 is a diagram for explaining the operation of updating the last transaction date of the billing destination master. [Figure 8] FIG. 8 is a diagram for explaining the operation of specifying the closing sales date. [Figure 9] 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. [Figure 10] FIG. 10 is a diagram showing an example of a collection schedule. [Figure 11] FIG. 11 is a diagram showing an example of sales data and deposit data. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS A commercial transaction status management device according to an embodiment of the present invention will be described in detail below with reference to the accompanying drawings. It should be noted that the present invention is not limited to the following embodiment.

[0013] (Hardware configuration) As shown in FIG. 1, the commercial 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 corresponds to a display unit such as a monitor device (including a home television), a printing device, or a speaker device. The input device 6 may be a keyboard device, a mouse device, a microphone device, or a monitor device that cooperates with a mouse device to realize a pointing device function. The communication interface unit 4 is connected to a network such as a wide area network such as the Internet or a private network such as a LAN (Local Area Network).

[0014] The storage unit 2 may be, for example, a storage device such as a ROM (Read Only Memory), a RAM (Random Access Memory), a HDD (Hard Disk Drive), or an SSD (Solid State Drive). A commercial transaction status management program for managing the commercial transaction status is stored in the storage unit 2. The storage unit 2 also stores a customer master 11, a billing destination master 12, collection schedule data, sales data, and deposit data.

[0015] The customer master 11 is composed of customer codes, customer names, and billing destination codes, as shown in Fig. 2. Customers and billing destinations are associated with each other through the customer master 11. In the example of Fig. 2, the customer code for customer A is "T001", and billing to this customer is performed using the billing destination code of "S001".

[0016] The billing destination master 12 includes the billing destination code, billing destination name, last transaction date, closing date, collection month, and collection date, as shown in Fig. 3. The "last transaction date" is the date on which no commercial transaction was conducted with the customer after the date on which commercial transaction was conducted with the customer.

[0017] 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."

[0018] The example in Figure 3 shows that the final commercial transaction for billing party code "S001" and billing party name "Billing Party 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 Party A" is the "31st (or last day)" of each month, and that the invoice amount can be collected "1" month after this closing date, and that the collection date is the "31st (or last day)" of the month corresponding to the collection month.

[0019] (Functional configuration of the business transaction status management device) Next, the control unit 3 executes the commercial 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.

[0020] The comparison unit 21 compares the date of a transaction with a business partner (customer, billing partner) when the transaction date is entered, for example, when entering an order or sales, with the last transaction date, which is the previous transaction date stored in the memory unit (billing partner master 12).

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

[0022] 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 predetermined 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 refers to the storage unit (billing destination master 12) and generates the closing date belonging to the collection month for collection of the payment on the transaction date as the closing date corresponding to the commercial transaction on the transaction date.

[0023] The scheduled collection date generating unit 25 references the storage unit (billing destination master 12), and generates the scheduled collection date by adding the collection month to the month to which the closing date belongs and adding the collection date. The collection schedule generating unit 26 generates a collection schedule including the scheduled collection date, the last transaction date, the sales amount generated by the business transaction, and the amount received from the business partner against the sales amount. The output control unit (the display control unit 23 as an example) controls the output of the generated collection schedule to an output device (such as a monitor device, a storage device, a speaker device, or a printer).

[0024] Furthermore, when the generated scheduled collection date is a date that does not exist, the scheduled collection date generating unit 25 sets a date that exists in the month to which the generated scheduled collection date belongs as the scheduled collection date.

[0025] (Outline of the operation of the business transaction status management device) Next, when a transaction input such as an order input or a sales input is received, the transaction status management device 1 according to the embodiment updates the last transaction date, which is the closest date to the present among the past dates on which a transaction was performed with a business partner (customer, billing partner) stored in the billing partner master 12, to the input transaction date as shown in Fig. 4. This last transaction date becomes the date that indicates the status of a transaction with a business partner. In other words, if there is a period of time, such as two months or more, during which no transaction was performed between the last transaction date and the current date, it is difficult to say that the transaction status is smooth, and measures such as a credit reinvestigation can be taken.

[0026] Furthermore, the commercial transaction status management device 1 of the embodiment refers to the customer master 11 and the billing destination master 12 based on the input sales data, and generates a collection schedule including the debt 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 debts by referring to the collection schedule. (Last trading date update operation) First, we will explain the operation of updating the last transaction date of the billing destination master 12. This update operation is performed by the control unit 3 of the transaction status management device 1 functioning as the following units based on the transaction status management program stored in the storage unit 2.

[0027] First, when an operator receives an order for a commercial transaction, the operator operates to display an order entry screen via the input device 6 in order to enter the order. Alternatively, when a commercial transaction is carried out, the operator operates to display a sales entry screen via the input device 6 in order to enter sales. The following description will be given taking sales entry as an example.

[0028] When the operator designates the display of the sales input screen, the display control unit 23 displays the sales input screen shown in Fig. 5 via the output device 7. As shown in Fig. 5, the sales input screen includes an order number display field, a business establishment code input field, a sales date input field, a customer code input field, a person in charge input field, a delivery destination input field, and a supplier input field.

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

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

[0031] The example of sales data shown in FIG. 6 is an example of sales data when "direct sales" are made, in which goods are delivered directly from the supplier's warehouse to the customer. For this reason, the sales category is "direct sales". The example in FIG. 6 shows an example in which the sales date is "July 24, 2022", and "2 cases" of "ammonia" with product code "SH01" and "10 cases" of "nitric acid" with product code "SH02" are sold. The example in FIG. 6 shows an example in which the sales price of "ammonia" sold in "2 cases" is "1300 yen", so the sales amount is "2600 yen". The sales price of "nitric acid" sold in "10 cases" is "950 yen", so the sales amount is "9500 yen".

[0032] On the other hand, when a customer code, a sales date, etc. are input via the sales input screen, the comparison unit 21 refers to the customer master 11 shown in Fig. 2 based on the input customer code, and detects the billing code associated with the input customer code. In the example of Fig. 5, since the customer code "T001" was input via the sales input screen, the comparison unit 21 detects the billing code "S001" associated with the customer code "T001" from the customer master 11.

[0033] In addition, the comparison unit 21 refers to the billing master 12 shown in FIG. 3 based on the billing code of "S001" detected from the customer master 11, and detects the last transaction date of "billing destination A" with the billing code of "S001". Then, the detected last transaction date is compared with the sales date (an example of a transaction date) entered via the sales input screen. In the example of FIG. 3 and FIG. 5, the sales date of "billing destination A" entered via the sales input screen is "July 24, 2022", while the last transaction date of "billing destination A" stored in the billing 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.

[0034] 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 of the invoice destination in the invoice destination master 12 to the date of the sales date. In the above example, the sales date of "invoice destination A" is "July 24, 2022", and the last transaction date of the invoice destination master 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 12 to the date of "July 24, 2022", which is the sales date, as shown in FIG. 7. The display control unit 23 displays the invoice destination master 12 including the last transaction date via the output device 7 at a predetermined timing such as a timing specified by the operator.

[0035] 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, such as two months or more, in which no commercial transactions have been conducted between the last transaction date and the current date, it is difficult to say that the commercial transaction status is smooth, so for example, a department that conducts credit investigations, such as a risk assessment department, can take measures such as re-investigating the credit.

[0036] (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 operations that cannot be compensated for by credit checks alone, such as low collection rates despite the fact that the transaction date is recent, from a perspective separate from credit management, even for regular business partners.

[0037] That is, when the sales are entered as described above (or when an order is entered, etc.) (preferably after the last transaction date has been updated), the closing date generation unit 24 refers to 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.

[0038] That is, in the example of Fig. 8, if the sales date is "September 25th", the closing date generation unit 24 obtains the closing date of "the 31st" as the closing date closest to the 25th or later. 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" of "the 31st (last day)".

[0039] Next, the scheduled collection date generating unit 25 refers to 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 a scheduled collection date.

[0040] That is, 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 Fig. 3, the collection month is "1" and the collection date is "31st". Therefore, the scheduled collection date generation unit 25 adds the collection month of "January" to October 2009 to obtain "November 2009" as shown in Fig. 9, and then adds the collection date of "31st" to this "November 2009" to obtain "November 31st, 2009" as the scheduled collection date.

[0041] Here, the last day of November is not the "31st" and is the "30th". In this way, if the generated scheduled collection date is a date that does not exist, "November 30, 2009", which is a date in the month to which the generated scheduled collection date belongs, is generated as the scheduled collection date. This makes it possible to amend the scheduled collection date to the "28th (or 29th: leap year)" even for months that do not have a "31st" as the last day, such as February.

[0042] Next, the collection schedule generating unit 26 refers to the sales data shown in Fig. 11(a) and the deposit data shown in Fig. 11(b) and calculates "deposit amount / sales amount" to calculate the collection rate for that customer and sales. The deposit data is data entered by the operator on a deposit input screen (not shown) and stored in the storage unit 2 by the data generating unit 27. The deposit data and sales data may be obtained from the accounting server device via a network or the like, or may be obtained and used from data stored in an external memory.

[0043] For example, the collection schedule generating unit 26 determines that the sales amount to the billing destination with the billing destination code "S001" in the first record in Fig. 11(a) is "2800 yen," while the amount received from the billing destination with the billing destination code "S001" is "2800 yen" as shown in the first record in Fig. 11(b). In this case, the collection rate is "2800 yen / 2800 yen=100%."

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

[0045] In other words, the billing recipient with the billing code "S001" made a deposit of "2,800 yen" for sales of "2,800 yen," but received "0 yen" for sales of "6,750 yen" and "12,100 yen."

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

[0047] Also, the records on lines 5 to 8 in Figure 11(a) show deposits for sales of "2900 yen", "2900 yen", "7750 yen", and "5600 yen" to the billing destination code "S003", but as shown in Figure 11(b), deposits have been made in the same amount as the sales amount except for the deposit for the sale of "5600 yen". Therefore, the recovery rate for the sale of "5600 yen" is "0%", and the recovery rate for other sales with billing code "S003" is "100%".

[0048] When each recovery rate is calculated in this manner, the collection schedule generating unit 26 generates a collection schedule including the serial number (No), business code, billing code, sales amount, planned collection date, final transaction date, deposit amount, and collection rate as exemplified in Fig. 10 based on the sales data shown in Fig. 11(a), the deposit data shown in Fig. 11(b), the planned collection date generated by the planned collection date generating unit 25, and the calculated collection rate, and stores this collection schedule data in the storage 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.

[0049] For example, in the case of a billing recipient with billing code "S001" in Figure 10, the last 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 been collected. It is possible to examine whether there are any problems with this type of transaction situation based on the collection schedule.

[0050] In addition, in the case of the billing destination with billing code "S002" in Figure 10, the final transaction date of the "6,800 yen" transaction in the record on the fourth line is "April 24, 2022" and the scheduled collection date is "April 30, 2023". Even though the final transaction date for this transaction is about one year before the scheduled collection date, the sales proceeds have not been collected. It is possible to determine whether there are any problems with this type of transaction status and whether the scheduled collection date is correct based on the collection schedule.

[0051] The credit check is performed by the comparison unit 21 calculating the amount using the formula "uncollected receivables amount + backorder amount - order balance - unpaid debt balance" and determining whether or not this calculated amount exceeds the credit amount set by the operator for each business partner in a credit master or the like (not shown).

[0052] Further, as one example, such a credit check is performed when an operator such as a field sales representative records the next commercial transaction by inputting an order or sales amount.

[0053] (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 target 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.

[0054] Specifically, since the "last transaction date" is the date that indicates the status of commercial transactions with the billing party, if there is a period of time, such as two months or more, during which no commercial transactions have been conducted between the last transaction date and the current date, it is difficult to say that the status of commercial transactions is smooth. For this reason, a department that conducts credit investigations, such as the risk assessment department, can take measures such as re-investigating the credit.

[0055] Furthermore, the commercial transaction status management device 1 of the embodiment creates a collection schedule including the scheduled collection date, collection rate, etc., along with the last transaction date, so that it is possible to check the commercial transaction status with a business partner with whom commercial transactions are conducted on a regular basis from a different perspective than the prior credit management. Therefore, it is possible to check the collection status of receivables that cannot be compensated for by credit checks alone, for example, a low collection rate despite a recent sales date. Also, a department that conducts credit investigations, such as a risk screening department, can re-examine credit and review commercial transactions.

[0056] For example, chemical trading companies often use "direct delivery transactions" where products are delivered directly from the supplier's warehouse to the customer. In addition, due to the large volume of transactions and the large number of stakeholders, it is difficult for the accounting department to perform the reconciliation work on its own. It is also difficult for the accounting department to judge the delay in collection based only on the scheduled collection date of the sales that are the source of the receivable.

[0057] However, the commercial transaction status management device 1 of the embodiment can easily identify the billing destination, etc., based on the "last transaction date," so it is possible for the accounting department to perform the reconciliation work on its own. Also, by creating a collection schedule, it is possible for the accounting department to determine whether to delay collection based only on the scheduled collection date of the sales recording that is the source of the receivable.

[0058] Also, in companies where the sales department is in charge of debt collection, the debt collection rate tends to be low. However, the commercial transaction status management device 1 of the embodiment can easily determine the delay in collection by referring to the scheduled collection date in the collection schedule, even in companies where the sales department is in charge of debt collection, and therefore can improve the debt collection rate.

[0059] [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, and can therefore contribute to Goals 8 and 9 of the SDGs.

[0060] Furthermore, this embodiment can contribute to reducing waste and promoting paperless and electronic systems, thereby contributing to the achievement of Goals 12, 13, and 15 of the SDGs.

[0061] Furthermore, this embodiment can contribute to strengthening control and governance, making it possible to contribute to Goal 16 of the SDGs.

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

[0063] For example, among 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.

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

[0065] Moreover, with regard to the business transaction status management device 1, each of the components shown in the figures is merely a functional concept, and does not necessarily have to be physically configured as shown in the figures.

[0066] For example, the processing functions of the commercial transaction status management device 1, particularly the control unit 3 and each processing function performed by the control unit 3, may be realized in whole or in part by a CPU (Central Processing Unit) and a program interpreted and executed by the CPU, or may be realized as hardware using wired logic. The program is recorded in a non-transient 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 commercial transaction status management device 1 as necessary. That is, a storage unit such as a ROM or HDD records a computer program for giving instructions to the CPU in cooperation with the OS and performing various processes. This computer program is executed by being loaded into a RAM, and constitutes the control unit 3 in cooperation with the CPU.

[0067] In addition, the commercial transaction status management program of this commercial transaction status management device 1 may be stored in another server device connected to the commercial transaction status management device 1 via any network, and it is also possible to download all or part of it as necessary.

[0068] The transaction status management program for executing the process described in the present embodiment may be stored in a non-transitory computer-readable recording medium, or may be configured as a program product. Here, the term "recording medium" includes any "portable physical medium" such as a memory card, a Universal Serial Bus (USB) memory, a Secure Digital (SD) card, a flexible disk, a magneto-optical disk, a ROM, an Erasable Programmable Read Only Memory (EPROM), an Electrically Erasable and Programmable Read Only Memory (EEPROM (registered trademark)), a Compact Disk Read Only Memory (CD-ROM), a Magneto-Optical Disk (MO), a Digital Versatile Disk (DVD), and a Blu-ray (registered trademark) Disc.

[0069] Moreover, a "program" is a data processing method written in any language or description method, and may be in any form, such as source code or binary code. Note that a "program" is not necessarily limited to a single configuration, but also includes a distributed configuration as multiple modules or libraries, and a program that achieves its function by working with a separate program, such as an OS. Note that well-known configurations and procedures can be used for the specific configuration 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.

[0070] 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 providing websites.

[0071] The business transaction status management device 1 may be configured as an information processing device such as a known personal computer device or a workstation, or may be configured as an information processing device connected to any peripheral device. The information processing device may be realized by implementing software (including programs or data, etc.) that realizes the processing described in this embodiment.

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

[0073] The present invention can be applied to management of the trading status of various types of businesses, in addition to management of the trading status of chemical trading companies that carry out many direct transactions. [Explanation of symbols]

[0074] 1. Trade status management device 2 Storage section 3. Control Unit 4. Communication Interface Section 5 Input / Output Interface Section 6 Input Devices 7 Output Devices 11 Customer Master 12 Billing Master 21 Comparison section 22 Update section 23 Display control section 24 Closing Date Generation Department 25 Collection Date Generation Unit 26 Collection schedule generation section

Claims

1. a comparison unit for comparing, when a transaction date with a trading partner is input, the input date with a 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 a comparison result indicating that the trading date is a date after the last trading date is obtained from the comparison unit; an output control unit that controls output of the updated last trading date to an output device; A business transaction status management device having the above configuration.

2. 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 a closing date corresponding to the commercial transaction on the transaction date from the closing date belonging to the collection month in which the payment on the transaction date is collected; 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 planned 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; 2. The business transaction status management device according to claim 1,

3. 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; 3. The business transaction status management device according to claim 2, wherein:

4. a comparison step in which the comparison unit compares, when a transaction date on which a business transaction was conducted with a trading partner is input, the input date with a last transaction date which is the previous transaction date stored in the storage unit; an updating step of updating the last trading date in the storage unit to the trading date when a comparison result indicating that the trading date is a date after the last trading date is obtained from the comparison unit; an output control step in which an output control unit controls an output device to output the updated last trading date; A method for managing a business transaction status comprising the steps of:

5. Computer, a comparison unit for comparing, when a transaction date with a trading partner is input, the input date with a 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 a comparison result indicating that the trading date is a date after the last trading date is obtained from the comparison unit; functioning as an output control unit that controls output of the updated final trading date to an output device; A business transaction status management program comprising:

Images