Business support device, business support method, and business support program

Abstract

To reduce workload in unit price confirmation processing, prevent errors, and accelerate accounting treatment.SOLUTION: A business support device performs the steps of: (1) confirming whether sales data contains a unit price determination flag indicating the unit price is undetermined; and (2) displaying a message prompting to modify unit price master to register a determined unit price and a unit price determination flag indicating the unit price is determined and recreate the sales data, and creating an error list for modifying the unit price master, when it is confirmed that the unit price determination flag indicating the undetermined unit price is included in the sales data.SELECTED DRAWING: Figure 5

Description

[Technical Field]

[0001] The present invention relates to a business support device, a business support method, and a business support program. [Background technology]

[0002] Patent Document 1 discloses a retroactive unit price correction system and method that consists of a unit price information management process that sets and manages information related to the unit price of each item, and a unit price information search process that searches for information related to unit prices based on input content (item, supplier) and registers a new invoice. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Laid-Open No. 2014-119821 Summary of the Invention [Problem to be solved by the invention]

[0004] In industries where the unit price of a product is determined late, the unit price determination process is carried out by a person in charge, which results in a heavy workload, a risk of a loss of customer trust due to mistakes, and delays in subsequent accounting processing.

[0005] The present invention has been made in consideration of the above, and aims to provide a business support device, a business support method, and a business support program that reduce the workload of determining unit prices, prevent errors, and speed up accounting processing. [Means for solving the problem]

[0006] In order to solve the above-mentioned problems and achieve the object, the business support device of the present invention is characterized by comprising: a data confirmation unit that confirms whether transaction data including transaction identification information, product identification information or business partner, unit price acquired from a unit price master, and a unit price confirmation flag acquired from the unit price master indicating whether the unit price is confirmed or not confirmed includes a unit price confirmation flag indicating an unconfirmed unit price; and a data processing unit that, when the data confirmation unit confirms that the unit price confirmation flag indicating an unconfirmed unit price is included in the transaction data, displays a message to prompt the user to correct the unit price master to a state in which the confirmed unit price and the unit price confirmation flag indicating the confirmed unit price are registered and recreate the transaction data, and creates correction data to correct the unit price master.

[0007] In addition, the business support device of the present invention may further include a display processing unit that displays the correction data created by the data processing unit in a manner that allows the unit price included in the correction data and the unit price confirmation flag indicating that the unit price has not been confirmed to be changeable; a master update unit that, when the displayed unit price is changed and the displayed unit price confirmation flag is changed to indicate that the unit price has been confirmed, considers the changed unit price to be the confirmed unit price and updates the unit price and unit price confirmation flag included in the displayed correction data to the changed unit price and the changed unit price confirmation flag, respectively, and updates the unit price master using the updated correction data; and a data update unit that updates the unit price and unit price confirmation flag included in the transaction data based on the unit price master after it has been updated by the master update unit.

[0008] In addition, in the business support device of the present invention, the transaction data may be related to sales, the transaction identification information may be sales identification information, the business partner may be a customer, and the unit price set in the unit price master may be a sales unit price.

[0009] In addition, in the business support device of the present invention, the transaction data may be related to purchases, the transaction identification information may be purchase identification information, the trading partner may be a supplier, and the unit price set in the unit price master may be a purchase unit price.

[0010] In addition, the business support method of the present invention includes a data confirmation step in which a data confirmation unit confirms whether a unit price confirmation flag indicating an undetermined unit price is included in transaction data including transaction identification information, product identification information or trading partner, a unit price acquired from a unit price master, and a unit price confirmation flag indicating whether the unit price acquired from the unit price master is confirmed or undetermined; and a data processing step in which, if the data confirmation unit confirms that the unit price confirmation flag indicating an undetermined unit price is included in the transaction data, a data processing unit displays a message to prompt the user to correct the unit price master so that the confirmed unit price and the unit price confirmation flag indicating the confirmed unit price are registered and to recreate the transaction data, and creates correction data for correcting the unit price master.

[0011] In addition, the business support program of the present invention causes a computer to function as a data processing means that executes the following: data confirmation means for confirming whether a unit price confirmation flag indicating an undetermined unit price is included in transaction data including transaction identification information, product identification information or trading partner, a unit price obtained from a unit price master, and a unit price confirmation flag indicating whether the unit price obtained from the unit price master is confirmed or not; when the data confirmation means confirms that the unit price confirmation flag indicating an undetermined unit price is included in the transaction data, displaying a message to prompt the user to correct the unit price master so that the confirmed unit price and the unit price confirmation flag indicating the confirmed unit price are registered and to recreate the transaction data; and creating correction data to correct the unit price master. [Effects of the Invention]

[0012] The present invention reduces the workload of determining unit prices, prevents errors, and speeds up accounting processing. [Brief explanation of the drawings]

[0013] [Figure 1] FIG. 1 is a block diagram showing an example of the configuration of a business support device. [Figure 2] FIG. 2 is a diagram showing an example of a processing flow according to this embodiment. [Figure 3] FIG. 3 is a diagram illustrating an example of the unit price master registration process. [Figure 4] FIG. 4 is a diagram illustrating an example of unit price retroactive processing. [Figure 5] FIG. 5 is a diagram showing an example of the provisional billing process. [Figure 6] FIG. 6 is a diagram showing an example of the unit price master registration process, the unit price retroactive process, and the invoice provisional closing process that are executed again. [Figure 7] FIG. 7 is a diagram showing an outline of the unit sales price retroactive processing. [Figure 8] FIG. 8 is a diagram showing an outline of the purchase price retroactive processing. [Figure 9] FIG. 9 is a diagram illustrating an example of the retroactive sales unit price master. [Figure 10] FIG. 10 is a diagram illustrating an example of the retroactive purchase unit price master. [Figure 11] FIG. 11 is a diagram illustrating an example of the sales data table. [Figure 12] FIG. 12 is a diagram illustrating an example of the purchase data table. [Figure 13] FIG. 13 is a diagram showing an example of the condition specification screen M. [Figure 14] FIG. 14 is a flowchart showing an example of the unit price retroactive processing. [Figure 15] FIG. 15 is a diagram showing an example of condition specification. [Figure 16] FIG. 16 is a diagram illustrating an example of a sales data table. [Figure 17] FIG. 17 is a diagram showing an example of condition specification. [Figure 18] FIG. 18 is a diagram illustrating an example of the purchase data table. DETAILED DESCRIPTION OF THE INVENTION

[0014] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, preferred embodiments of a business support device, a business support method, and a business support program according to the present invention will be described in detail with reference to the accompanying drawings. However, the present invention is not limited to the preferred embodiments.

[0015] [1. Overview] In industries such as the chemical industry where unit prices for futures products are determined late, retroactive unit price calculations are often used to calculate and update sales and purchase prices in one go.The unit price master data (sales unit price master data or purchase unit price master data) used to perform retroactive unit price calculations is manually registered.

[0016] Therefore, for example, if a human error occurs when registering the sales unit price master, it will also affect the retroactive calculation of the unit price (such as missing a retroactive calculation), which can result in a number of problems, such as incorrect billing of customers at different unit prices, a loss of customer trust due to the incorrect billing, an increase in the workload due to dealing with the error, and delays in subsequent billing processes.In addition, in the case of purchases, problems similar to those in the case of sales (such as incorrect payments) can occur.

[0017] Therefore, we focused on the fact that unit price retroactive operation is performed by uploading unit price master data and performing daily unit price retroactive processing. In this embodiment, we have constructed a system in which (1) each of the unit price master data and transaction data (sales data or purchase data) has a unit price confirmation flag (for example, a binary flag that takes 1 when the unit price is confirmed and 0 when the unit price is not confirmed), (2) the unit price confirmation flag of the transaction data is updated at the time of unit price retroactive processing, (3) in the case of sales, at the time of provisional invoice closing processing, and in the case of purchases, at the time of payment method confirmation processing, the status of the unit price confirmation flag is checked to see if there is any data with an unconfirmed unit price (missing retroactive processing), (4) if there is data with an unconfirmed unit price in the transaction data, a list of data with an unconfirmed unit price (error list) is output, and (5) the output list is used to correct the unit price master.

[0018] This reduces the workload of determining unit prices, prevents errors, and speeds up processing.

[0019] [2. Configuration] An example of the configuration of the task assistance device 100 according to this embodiment will be described in detail with reference to Fig. 1 etc. Fig. 1 is a block diagram showing an example of the configuration of the task assistance device 100.

[0020] The business support device 100 is constructed based on a commercially available desktop personal computer. Note that the business support device 100 is not limited to being constructed based on a stationary information processing device such as a desktop personal computer, but may also be constructed based on a portable information processing device such as a commercially available notebook personal computer, a PDA (Personal Digital Assistant), a smartphone, or a tablet personal computer.

[0021] 1, the business assistance device 100 includes a control unit 102, a communication interface unit 104, a storage unit 106, and an input / output interface unit 108. The units included in the business assistance device 100 are connected to each other so as to be able to communicate with each other via any communication path.

[0022] The communication interface unit 104 communicably connects the business assistance 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 other devices via the communication line. Here, the network 300 has a function of connecting the business assistance device 100 and the server 200 so that they can communicate with each other, and is, for example, the Internet or a LAN (Local Area Network). Note that the data stored in the memory unit 106 may be stored in the server 200, for example.

[0023] An input device 112 and an output device 114 are connected to the input / output interface unit 108. The output device 114 may be a monitor (including a home television), a speaker, or a printer. The input device 112 may be a keyboard, a mouse, a microphone, or a monitor that functions as a pointing device in cooperation with a mouse. In the following, the output device 114 may be referred to as the monitor 114, and the input device 112 may be referred to as the keyboard 112 or the mouse 112.

[0024] Various databases, tables, files, etc. are stored in the storage unit 106. Computer programs that work in conjunction with an OS (Operating System) to issue commands to a CPU (Central Processing Unit) to perform various processes are recorded in the storage unit 106. The storage unit 106 can be, for example, a memory device such as a RAM (Random Access Memory) or a ROM (Read Only Memory), a fixed disk device such as a hard disk, a flexible disk, an optical disk, etc.

[0025] The storage unit 106 stores a unit price master 106a, sales data 106b, purchase data 106c, etc. The unit price master 106a is conceptually included in the unit price master of the present invention. The sales data 106b and purchase data 106c are conceptually included in the transaction data of the present invention.

[0026] The unit price master 106a manages both the sales unit price and the purchase unit price, and as shown in FIG. 3, includes the unit price category (for example, category value "1" meaning sales or category value "2" meaning purchase), applicable period (start of period to end of period), customer (supplier in the case of a purchase), delivery destination, product, unit price (sales unit price or purchase unit price), and unit price confirmation flag. The key items are the customer, delivery destination, and product. The unit price confirmation flag is a binary flag that takes "0" indicating that the unit price has not been confirmed, or "1" indicating that the unit price has been confirmed. Here, the unit price master 106a is a single master that manages both the sales unit price and the purchase unit price, but the unit price master 106a may also be composed of two masters that separately manage the sales unit price and the purchase unit price. Specifically, the unit price master 106a may be composed of a sales unit price master constructed based on the retroactive sales unit price master shown in Figure 9, which will be described in [5. Other embodiments of unit price retroactive processing], and capable of storing a unit price determination flag, and a purchase unit price master constructed based on the retroactive purchase unit price master shown in Figure 10, which will be described in [5. Other embodiments of unit price retroactive processing], and capable of storing a unit price determination flag.

[0027] As shown in Fig. 4, the sales data 106b includes the sales number, line number, sales date, customer, delivery destination, product, quantity, sales unit price, sales amount, and unit price confirmation flag. Here, the sales data 106b may be sales data constructed based on the sales data table shown in Fig. 11, which will be explained in [5. Other embodiments of unit price retroactive processing], and which can store the unit price confirmation flag.

[0028] Although not shown, the purchase data 106c includes a purchase number, a line number, a purchase date, a supplier, a delivery destination, a product, a quantity, a purchase unit price, a purchase amount, a unit price determination flag, etc. Here, the purchase data 106c may be purchase data constructed based on the purchase data table shown in Fig. 12, which will be explained in [5. Other embodiments of unit price retroactive processing], and which can store a unit price determination flag.

[0029] 1, the control unit 102 is a CPU or the like that performs overall control of the business support device 100. The control unit 102 has an internal memory for storing control programs such as an OS, programs that define various processing procedures, required data, etc., and executes various information processing operations based on these stored programs.

[0030] The control unit 102 conceptually includes a unit price master registration unit 102a, a unit price retroactive processing unit 102b, a billing settlement processing unit 102c, and a payment method determination processing unit 102d. The billing settlement processing unit 102c and the payment method determination processing unit 102d include a data confirmation unit and a data processing unit according to the present invention. The unit price master registration unit 102a includes a display processing unit and a master update unit according to the present invention. The unit price retroactive processing unit 102b includes a data update unit according to the present invention.

[0031] The unit price master registration unit 102a updates (e.g., registers new data or modifies) the unit price master 106a through operator input and / or the acceptance of an error list. The unit price master registration unit 102a displays an error list (corresponding to the correction data of the present invention) created by the billing settlement processing unit 102c or the payment method determination processing unit 102d, and displays the unit price included in the error list and the unit price determination flag indicating that the unit price has not been determined in a changeable manner. When the displayed unit price is changed and the displayed unit price determination flag is changed to indicate that the unit price has been determined, the unit price master registration unit 102a considers the changed unit price to be the determined unit price, updates the unit price and unit price determination flag included in the displayed error list to the changed unit price and changed unit price determination flag, respectively, and updates the unit price master 106a using the updated error list.

[0032] The unit price retroactive processing unit 102b executes retroactive processing of the sales unit price or purchase unit price by updating the sales data 106b or purchase data 106c via operator input and / or import of the unit price master 106a. The unit price retroactive processing unit 102b updates the sales unit price and unit price confirmation flag included in the sales data 106b or the purchase unit price and unit price confirmation flag included in the purchase data 106c based on the unit price master 106a updated by the unit price master registration unit 102a. Note that the unit price retroactive processing may be implemented based on the contents described in [5. Other Embodiments of Unit Price Retroactive Processing] by assigning a unit price confirmation flag to each of the sales and purchase unit price masters and the sales data and purchase data, or by adding a unit price confirmation flag update process.

[0033] The billing settlement processing unit 102c executes a predetermined billing settlement process (such as provisional settlement processing) based on the sales data 106b. The billing settlement processing unit 102c (1) checks whether the sales data 106b contains a unit price confirmation flag indicating that the unit price has not been confirmed, and (2) if it confirms that the unit price confirmation flag indicating that the unit price has not been confirmed is included in the sales data 106b, it displays a message to prompt the user to correct the unit price master 106a so that the confirmed sales unit price and the unit price confirmation flag indicating that the unit price has been confirmed are registered, and to recreate the sales data 106b, and creates an error list for correcting the unit price master 106a.

[0034] The payment method determination processor 102d executes a predetermined payment method determination process based on the purchase data 106c. The payment method determination processor 102d (1) checks whether the purchase data 106c includes a unit price determination flag indicating that the unit price is not yet determined, and (2) if it confirms that the purchase data 106c includes a unit price determination flag indicating that the unit price is not yet determined, displays a message urging the user to correct the unit price master 106a and recreate the purchase data 106c so that the determined purchase unit price and the unit price determination flag indicating that the unit price is determined are registered, and creates an error list for correcting the unit price master 106a.

[0035] [3. Specific examples of processing] A specific example of a series of processes executed by the business support device 100 for the sales data 106b will be described with reference to Figures 2 to 6. Note that a specific example of a series of processes for the purchase data 106c will not be described here. This is because the sales price retroactive processing described below can be replaced with purchase price retroactive processing, and the invoice provisional closing processing described below can be replaced with payment method confirmation processing.

[0036] [3-1. Processing flow (see Figure 2)] 2 is a diagram showing the flow of a series of processes for the sales data 106b, executed by the business support device 100. In this specific example, it is assumed that the processes proceed in the following order [1] to [5]. [1] Monthly registration of unit price master data by the unit price master data registration unit 102a (see Figure 3) [2] Sales unit price retroactive processing executed by the unit price retroactive processing unit 102b (see FIG. 4) [3] Provisional bill settlement process executed by the bill settlement processing unit 102c (see FIG. 5) [4] Unit price master update process executed by the unit price master registration unit 102a when an error list is output (see FIG. 6) [5] After the error list is output and the unit price master update process is executed, the unit price retroactive processing unit 102b and the billing closing processing unit 102c execute the sales unit price retroactive processing and the billing provisional closing processing again (see Figure 6).

[0037] [3-2. Details of each process (see Figures 3 to 6)] The details of each process shown in FIG. 2 will be described below with reference to FIGS.

[0038] [1] Monthly registration of unit price master data by the unit price master data registration unit 102a (see Figure 3) The person in charge inputs the required information (particularly the sales unit price and the unit price confirmation flag) on ​​the unit price master registration screen (not shown), and the unit price master registration section 102a updates the unit price master 106a. When inputting a confirmed sales unit price, the person in charge inputs the unit price confirmation flag "1" indicating that the unit price is confirmed, and when inputting an unconfirmed sales unit price, the person in charge inputs the unit price confirmation flag "0" indicating that the unit price is unconfirmed. The unit price category "1" is a category value that means sales.

[0039] [2] Sales unit price retroactive processing executed by the unit price retroactive processing unit 102b (see FIG. 4) First, the explanation of this process is based on the premise that the unit price master 106a is as shown in FIG. 3 and the sales data 106b is as shown in the upper part of FIG.

[0040] Based on each unit price record associated with unit price category "1" registered in unit price master 106a, unit price retroactive processing section 102b identifies sales records from sales data 106b that satisfy the conditions that "all key items match those of the unit price record" and "the sales date falls within the period from the start of the period to the end of the period in the unit price record," and updates the identified sales records (especially the sales unit price, sales amount, and unit price confirmation flag) based on the corresponding unit price record. Note that since the unit price confirmation flag included in the third unit price record from the top in unit price master 106a shown in Figure 3 is "0," indicating that the unit price has not been confirmed, the unit price confirmation flag included in the sales record containing sales number "U002" remains "0," indicating that the unit price has not been confirmed, as shown in the bottom part of Figure 4.

[0041] [3] Provisional bill settlement process executed by the bill settlement processing unit 102c (see FIG. 5) First, the explanation of this process is based on the premise that the sales data 106b is as shown in the lower part of FIG.

[0042] While executing the prescribed provisional invoice closing process based on the sales data 106b, the invoice closing processing unit 102c (1) checks whether the sales data 106b contains a unit price confirmation flag of "0", and (2) if it confirms that the unit price confirmation flag "0" is contained in the sales data 106b, it displays a message (for example, a message such as "Data with unconfirmed sales unit prices exists. Please check the error list and register the confirmed unit prices") to encourage the user to correct the unit price master 106a so that the confirmed sales unit price and the unit price confirmation flag of "1" are registered and recreate the sales data 106b, and creates an error list such as that shown in Figure 5 to correct the unit price master 106a. When creating the error list, the format of the error list is the same as that of the unit price master 106a, the unit price category is fixed to "1" indicating sales, the customer, delivery destination, product, unit price and unit price confirmation flag are used as they are in the sales record that contains the unit price confirmation flag "0", and the start and end of the period are the first and last dates of the month to which the sales date of the sales record belongs. The created error list is stored in the memory unit 106. The person in charge sees the displayed error message and realizes that a confirmed unit price needs to be registered.

[0043] [4] Unit price master update process executed by the unit price master registration unit 102a when an error list is output (see FIG. 6) The person in charge activates the unit price master registration unit 102a to register the confirmed unit price and instructs it to accept the error list. The unit price master registration unit 102a refers to the storage unit 106 and executes the acceptance of the error list, and if the error list is accepted, it displays the accepted error list with the unit price and unit price confirmation flag changeable. The person in charge changes the displayed unit price to the confirmed sales unit price and changes the unit price confirmation flag to "1." When the unit price and unit price confirmation flag are changed, the unit price master registration unit 102a regards the changed sales unit price as the confirmed unit price, updates the unit price and unit price confirmation flag included in the error list to the changed unit price and changed unit price confirmation flag, respectively, and updates the unit price master 106a using the updated error list.

[0044] [5] After the error list is output and the unit price master update process is executed, the unit price retroactive processing unit 102b and the billing closing processing unit 102c execute the sales unit price retroactive processing and the billing provisional closing processing again (see Figure 6). First, the explanation of this process is based on the premise that the unit price master 106a is as shown in FIG. 6 and the sales data 106b is as shown in the lower part of FIG.

[0045] Similar to the process described in [2] above, the unit price retroactive processing unit 102b identifies sales records from the sales data 106b that satisfy the conditions that "all key fields match those of the unit price record" and "the sales date falls within the period from the start of the period to the end of the period in the unit price record," based on each unit price record linked to unit price category "1" registered in the unit price master 106a, and updates the identified sales records (especially the sales unit price, sales amount, and unit price confirmation flag) based on the corresponding unit price record. Note that since all unit price confirmation flags included in the unit price master 106a shown in Figure 6 are "1," the unit price confirmation flag included in the sales record containing sales number "U002" is updated to "1," and the unit sales price and sales amount are also updated, as shown in the lower part of Figure 6.

[0046] Similarly to the process described in [3] above, the billing settlement processing unit 102c, while executing the prescribed billing provisional settlement process based on the sales data 106b, (1) checks whether the sales data 106b contains a unit price confirmation flag of "0." (2) If it confirms that the unit price confirmation flag of "0" is included in the sales data 106b, it displays a message (e.g., a message such as "There is data with an unconfirmed sales unit price. Please check the error list and register the confirmed unit price.") to encourage the user to re-create the sales data 106b so that the confirmed sales unit price and the unit price confirmation flag of "1" are registered, and creates an error list such as that shown in Figure 5 to correct the unit price master 106a. In this case, because the billing provisional settlement process is executed based on the sales data 106b shown in the lower part of Figure 6, the process ends without displaying an error message or creating an error list. The person in charge knows that they can proceed to the subsequent invoice issuance process (see Figure 2) when no error message is displayed.

[0047] 4. Effects of this embodiment By providing a unit price confirmation flag to the unit price master 106a, sales data 106b, and purchase data 106d, it is possible to automatically check whether there is data for which the unit price has not been confirmed, thereby reducing the workload, preventing the risk of a decline in customer trust due to human error, and enabling faster billing operations.

[0048] [5. Other embodiments of unit price retroactive processing] Here, another embodiment of the unit price retroactive processing will be described with reference to FIGS.

[0049] Figure 7 shows an overview of the unit sales price retroactive processing. For example, (A1) on the condition specification screen, select the conditions for the sales slip you want to retroactively process, (A2) check whether the target slip has been invoiced, (A3) check whether the target sales slip (details) is in an exclusive state, (A4) if not, place the sales slip (or purchase slip in the case of direct delivery) containing the target detail in an exclusive state as being in unit price retroactive processing execution, (A5) refer to the registered contents of the retroactive sales price master for each target sales detail, (A6) if a matching unit sales price master for retroactive processing exists, use the unit price in the master and recalculate the amount and consumption tax, (A7) overwrite the sales data update operator ID with the unit price retroactive processing execution operator ID, and (A8) release the exclusive state of the target sales slip. Note that in the process of (A2), if the invoice is provisionally closed or confirmed, the slip may be internally excluded from processing to prevent an error from occurring. In addition, in the process of (A3), if there is a voucher in an exclusive state, an error may be generated.In addition, in the process of (A6), the sales history information, receivables information for the billing destination, and collection schedule information for the voucher may also be linked and reconciled as a result of the recalculation.In addition, in the process of (A6), if one detail of a voucher with multiple details is the target of retroactive review, the voucher information may also be reconciled with the content after the amount of that one detail has been changed.

[0050] FIG. 8 is a diagram showing an outline of the purchase price retroactive processing. For example, (B1) on the condition specification screen, select the conditions of the purchase voucher you want to make the retroactive processing target, (B2) check whether the target voucher has been invoiced, (B3) check whether the target purchase voucher (details) is in an exclusive state, (B4) if it is not in an exclusive state, the purchase voucher (sales voucher in the case of direct delivery) containing the detail to be retroactively processed is placed in an exclusive state as unit price retroactive processing is in progress, (B5) for each purchase detail to be retroactively processed, the registered contents of the purchase unit price master for retroactive processing are referenced, (B6) if a corresponding purchase unit price master for retroactive processing exists, the unit price in the master is used to recalculate the amount and consumption tax, (B7) if the direct delivery purchase voucher linked to sales is being retroactively processed, the cost and gross profit amounts in the sales data are also reviewed, (B8) the purchase data update operator ID is overwritten with the unit price retroactive processing execution operator ID, and (B9) the exclusive state of the target purchase voucher is released. In the process of (B2), if the payment is settled and confirmed, the voucher may be internally excluded from processing so that an error does not occur. Also, in the process of (B3), if there is a voucher in an exclusive state, an error may be generated. Furthermore, in the process of (B6), the purchase history information, debt information for the payee, and payment schedule information for the voucher may also be linked and re-examined as a result of the recalculation. Furthermore, in the process of (B6), if one detail of a voucher with multiple details is subject to retroactive processing, the voucher information may also be re-examined with the content after the amount of that one detail has been changed.

[0051] Figure 9 shows an example of a retroactive sales price master. The retroactive sales price master is a table containing data such as sales category, delivery category, customer, delivery destination, product, company warehouse, shipping base, application start date, application end date, and unit sales price. Two sales categories are predefined: "warehouse sales" and "direct delivery sales." Furthermore, three delivery categories are predefined based on the nature of delivery arrangements: "arranged prior to customer," "arranged in-house," and "arranged by supplier." "arranged in-house" refers to a request for delivery arrangements from a "destination where the product will arrive" (e.g., the final delivery destination) beyond the customer in terms of the commercial flow. "arranged in-house" refers to delivery arrangements made by our company itself. "arranged by supplier" refers to cases where the oil wholesaler (usually a manufacturer) requests the specified delivery method when the product is delivered directly.

[0052] Figure 10 is a diagram showing an example of a retroactive purchase unit price master. The retroactive purchase unit price master is a table containing information such as purchase category, delivery arrangement category, supplier code, warehouse (shipping base) code, delivery destination code, product code, application start date, application end date, and purchase unit price. Here, two purchase categories are predefined: "warehouse purchase" and "direct purchase." Furthermore, taking into account the nature of delivery arrangements, three delivery arrangement categories are predefined: "customer prior arrangement," "in-house arrangement," and "supplier arrangement."

[0053] FIG. 11 is a diagram showing an example of a sales data table. The sales data table is a table containing information such as a number for identifying a record, sales establishment, sales number, row number, sales date, sales category, CD (delivery arrangement category code), delivery arrangement category, customer, delivery destination, warehouse (company warehouse), product, warehouse CD (shipping base code), shipping base, closing status, sales price, sales amount, and sales quantity. Here, the shipping base information is obtained from the purchase data table. The sales number is a number for identifying a sales slip. The row number is a number for identifying the details included in the sales slip.

[0054] Figure 12 is a diagram showing an example of a purchase data table. The purchase data table is a table containing information such as a number for identifying a record, supplier establishment, purchase number, line number, purchase date, purchase category, CD (delivery arrangement category code), delivery arrangement category, supplier, warehouse CD (shipping base code), shipping base, warehouse (company warehouse), product, closing status, delivery destination, purchase price, purchase amount, and purchase quantity. Here, the delivery destination information is obtained from the sales data table. The purchase number is a number for identifying a purchase slip. The line number is a number for identifying a statement included in the purchase slip.

[0055] The control unit 102 may further include, in terms of functional concepts, a retroactive data acquisition unit, a retroactive unit price acquisition unit, and a retroactive processing unit.

[0056] The retroactive data acquisition unit acquires sales slip data to be retroactively processed from the sales data table in accordance with specified conditions. The retroactive data acquisition unit also acquires purchase slip data to be retroactively processed from the purchase data table in accordance with specified conditions.

[0057] The retroactive unit price acquisition unit compares the retroactive sales unit price master with the retroactive sales slip data acquired by the retroactive data acquisition unit, and acquires the unit price to be applied to the retroactive sales slip data from the retroactive sales unit price master. Specifically, the retroactive unit price acquisition unit references the retroactive sales unit price master for each piece of retroactive sales slip data (record) acquired by the retroactive data acquisition unit, and acquires the retroactive unit price (net sales unit price) corresponding to each record. The retroactive unit price acquisition unit compares the retroactive purchase unit price master with the retroactive purchase slip data acquired by the retroactive data acquisition unit, and acquires the unit price to be applied to the retroactive purchase slip data from the retroactive purchase unit price master. Specifically, the retroactive unit price acquisition unit references the retroactive purchase unit price master for each piece of retroactive purchase slip data (record) acquired by the retroactive data acquisition unit, and acquires the retroactive unit price (net purchase unit price) corresponding to each record.

[0058] The retroactive processing section recalculates the sales amount included in the retroactive sales slip data based on the unit sales price acquired by the retroactive unit price acquisition section and the quantity included in the retroactive sales slip data, and revises (updates) the unit sales price and sales amount included in the retroactive sales slip data based on the acquired unit sales price and the recalculated sales amount.The retroactive processing section recalculates the purchase amount included in the retroactive purchase slip data based on the unit purchase price acquired by the retroactive unit price acquisition section and the quantity included in the retroactive purchase slip data, and revises (updates) the unit purchase price and purchase amount included in the retroactive purchase slip data based on the acquired unit purchase price and the recalculated purchase amount.

[0059] 13 is a diagram showing an example of a condition specification screen M. The screen shown in FIG. 13 allows the operator to select sales slip data to be retroactively processed in the unit sales price retroactive processing described below. The condition specification screen M includes an area 1 for inputting a range of sales establishments, an area 2 for inputting a range of sales dates, an area 3 for inputting a range of sales categories, an area 4 for inputting a range of delivery arrangement categories, an area 5 for inputting a range of sales representatives, an area 6 for inputting a range of customers, an area 7 for inputting a range of delivery destinations, an area 8 for inputting a range of shipping bases, an area 9 for inputting a range of company warehouses, an area 10 for inputting a range of products, an area 11 for inputting a range of sales numbers, and an area 12 for displaying the progress of processing executed by each processing unit of the control unit 102.

[0060] The condition specification screen for allowing the operator to select purchase slip data to be retroactively processed in the purchase unit price retroactive processing described later may be a screen M shown in FIG. 13 with the following changes and deletions: -Areas 1 to 3, 5, and 11 have been changed to allow the entry of ranges for the purchasing establishment, purchasing date, purchasing category, purchasing person, and purchasing number. - Areas 6 and 9 have been deleted.

[0061] Fig. 14 is a flowchart showing an example of a unit sales price retroactive processing, Fig. 15 is a diagram showing an example of a condition specification, and Fig. 16 is a diagram showing an example of a sales data table.

[0062] [Step S1: Obtaining retrospective data] The retrospective data acquisition unit acquires sales slip data to be retrospectively processed from the sales data table in accordance with the conditions entered on the condition specification screen M. Specifically, if the entered sales category is "warehouse sales," the retrospective data acquisition unit uses the entered sales establishment, sales date, sales category, delivery arrangement category, sales representative, customer, delivery destination, company warehouse, product, and sales number as conditions to narrow down the sales slip data that contains data that matches the conditions. Furthermore, if the entered sales category is "direct delivery sales," the retrospective data acquisition unit uses the entered sales establishment, sales date, sales category, delivery arrangement category, sales representative, customer, delivery destination, shipping base, product, and sales category as conditions to narrow down the sales slip data that contains data that matches the conditions.

[0063] For example, if the conditions shown in Figure 15 are specified on the condition specification screen M, the sales slip data stored in the sales data table, including the data within the bold frame shown in Figure 16, will be selected and acquired. Note that in Figure 16, record No. 4 is the same slip as record No. 3, which is selected as the target for retrospective analysis. However, because the company warehouse data included in record No. 4 differs from the specified data, record No. 4 is not selected as the target for retrospective analysis. In other words, record No. 4 as sales detail data will not be retrospectively processed. However, retrospective analysis will occur for the slip with sales number "A110" that includes this record. Also, in Figure 16, records No. 8 and No. 9 did not have shipping base data registered when the sales were entered, so shipping base data is not registered. Therefore, if a range of shipping bases is specified on the condition specification screen M, these records will not be selected. However, if the range of shipping bases is not entered on the condition specification screen M, data for all shipping bases will be selected unconditionally.

[0064] [Step S2: Obtain retroactive unit price] The retroactive unit price acquisition unit references the retroactive unit sales price master for each piece of sales slip data acquired in step S1 and acquires the retroactive unit price (base sales unit price) applied to the product included in each piece of sales slip data.

[0065] The conditions for obtaining the unit price of sales differ depending on the sales category data included in the sales slip data, as shown below.

[0066] Specifically, when the sales category included in the sales slip data is "warehouse sales," the retroactive unit price acquisition unit acquires a record of the retroactive sales unit price master that meets the conditions that "the sales category, delivery arrangement category, customer, delivery destination, warehouse (company warehouse), and product included in the sales slip data match those included in the retroactive sales unit price master, and the application start date of the retroactive sales unit price master is before the sales date and is the latest date."

[0067] In addition, if the sales category included in the sales slip data is "direct delivery sales," the retroactive unit price acquisition unit acquires records that meet the conditions from the retroactive sales unit price master in the order of (11) and (12) below. (11) Obtain a record of the retroactive sales price master that meets the following conditions: "The sales category, delivery arrangement category, customer, delivery destination, and product included in the sales slip data match those included in the retroactive sales price master, and the warehouse (shipping base) for the retroactive sales price master is not registered, and the application start date for the retroactive sales price master is the latest date and is before the sales date." (12) Obtain a record of the retroactive sales price master that meets the following conditions: "The sales category, delivery arrangement category, customer, delivery destination, product, and warehouse (shipping base) included in the sales slip data match those included in the retroactive sales price master, and the retroactive sales price master application start date is before the sales date and is the latest date."

[0068] [Step S3: Retroactive processing] The retroactive processing unit reconciles (updates) the sales unit price included in the sales slip data with the retroactive unit price (net sales unit price) obtained in step S2, and reconciles the sales amount included in the sales slip data with the product of the retroactive unit price (net sales unit price) obtained in step S2 and the quantity included in the sales slip data, thereby recreating the sales unit price and sales amount data included in the sales slip data (including sales detail data).Here, if the quantity is zero, such sales slip data will not be processed.Furthermore, if the retroactive unit price cannot be obtained in step S2 or if the retroactive unit price obtained in step S2 is zero yen, reconciliation will not be performed.

[0069] Fig. 14 is a flowchart showing an example of a purchase unit price retroactive processing, Fig. 17 is a diagram showing an example of a condition specification, and Fig. 18 is a diagram showing an example of a purchase data table.

[0070] [Step S1: Obtaining retrospective data] The retrospective data acquisition unit acquires purchase slip data to be retrospectively processed from the purchase data table in accordance with the conditions entered on the condition specification screen M. Specifically, when the entered purchase category is "warehouse purchase," the retrospective data acquisition unit uses the entered purchase establishment, purchase date, purchase category, delivery arrangement category, purchaser, supplier, shipping base, product, and purchase number as conditions to narrow down the purchase slip data that contains data that matches the conditions. Furthermore, when the entered purchase category is "direct purchase" and the delivery arrangement category is "supplier-arranged," the retrospective data acquisition unit uses the entered purchase establishment, purchase date, purchase category, delivery arrangement category, purchaser, supplier, shipping base, product, recipient, and purchase number as conditions to narrow down the purchase slip data that contains data that matches the conditions. In addition, if the input purchase category is "direct purchase" and the delivery arrangement category is "in-house arrangement" or "previous arrangement with customer," the retrospective data acquisition unit uses the input purchase establishment, purchase date, purchase category, delivery arrangement category, purchaser, supplier, shipping base, product, and purchase number as conditions to narrow down the purchase invoice data that includes data that matches the conditions.

[0071] For example, if the conditions shown in Figure 17 are specified on the condition specification screen M, the purchase voucher data stored in the purchase data table, including the data in the bold frame shown in Figure 18, will be selected and acquired. Note that in Figure 18, record No. 8 is the same voucher as record No. 7, which is selected as the target for retroactive review. However, because the shipping base data included in record No. 8 differs from the specified data, record No. 8 is not selected as the target for retroactive review. In other words, record No. 8 as purchase detail data will not be retroactively reviewed. However, retroactive review will occur for the voucher with purchase number "S120" that includes this record. Also, in Figure 18, records No. 5 and No. 6 did not have shipping base data registered when the purchase was entered. Furthermore, records No. 12 and No. 13 did not have shipping base data registered when the sales were entered, so shipping base data is not registered. Therefore, if a range of shipping bases is specified on the condition specification screen M, these records will not be selected. However, if the range of shipping bases is not entered on the condition specification screen M, data for all shipping bases will be selected unconditionally. Also, in Figure 18, record No. 19 will not be selected because its closing status data is "Payment closed." On the other hand, record No. 20 will be selected even though its closing status data is "Invoice closed" (i.e., the corresponding sales slip has been invoiced). In other words, if the closing status data included in the purchase data table is "Payment closed," it will be excluded from selection regardless of the conditions specified on the condition specification screen M.

[0072] [Step S2: Obtain retroactive unit price] The retroactive unit price acquisition unit refers to the retroactive purchase unit price master for each purchase slip data acquired in step S1, and acquires the retroactive unit price (purchase unit price) applied to the product included in each purchase slip data.

[0073] The conditions for obtaining the purchase unit price vary depending on the purchase category data and delivery arrangement category data included in the purchase slip data, as shown below.

[0074] Specifically, when the purchase category included in the purchase slip data is "warehouse purchase," the retroactive unit price acquisition unit acquires records that meet the conditions from the retroactive purchase unit price master in the order of (21) and (22) below. (21) Obtain a record of the retroactive purchase unit price master that meets the following conditions: "The purchase category, delivery arrangement category, supplier, and product included in the purchase slip data match those included in the retroactive purchase unit price master, and the retroactive purchase unit price master warehouse (shipping base) is not registered, and the retroactive purchase unit price master application start date is the latest date and is earlier than the purchase date included in the purchase slip data." (22) Obtain a record of the retroactive purchase unit price master that meets the condition that "the purchase category, delivery arrangement category, supplier, product, and warehouse (shipping base) included in the purchase slip data match those included in the retroactive purchase unit price master, and the retroactive purchase unit price master application start date is the latest date and is earlier than the purchase date included in the purchase slip data."

[0075] In addition, if the purchase category included in the purchase slip data is "direct purchase" and the delivery arrangement included in the purchase slip data is "supplier", the retroactive unit price acquisition unit acquires records that meet the conditions from the retroactive purchase unit price master in the order of (31) to (34) below. (31) Obtain a record of the retroactive purchase unit price master that meets the following conditions: "The purchase category, delivery arrangement category, supplier, and product included in the purchase slip data match those included in the retroactive purchase unit price master, and the warehouse (shipping base) in the retroactive purchase unit price master and the delivery destination in the retroactive purchase unit price master are both unregistered, and the application start date in the retroactive purchase unit price master is the latest date and is earlier than the purchase date included in the purchase slip data." (32) Obtain a record of the retroactive purchase unit price master that meets the following conditions: "The purchase category, delivery arrangement category, supplier, product, and warehouse (shipping base) included in the purchase slip data match those included in the retroactive purchase unit price master, and the delivery destination in the retroactive purchase unit price master is not registered, and the application start date in the retroactive purchase unit price master is the latest date and is earlier than the purchase date included in the purchase slip data." (33) Obtain a record of the retroactive purchase unit price master that meets the following conditions: "The purchase category, delivery arrangement category, supplier, product, warehouse (shipping base), and delivery destination included in the purchase slip data match those included in the retroactive purchase unit price master, and the unit price master warehouse (shipping base) is not registered, and the retroactive purchase unit price master application start date is the latest date and is earlier than the purchase date included in the purchase slip data." (34) Obtain a record of the retroactive purchase unit price master that meets the conditions that "the purchase category, delivery arrangement category, supplier, product, warehouse (shipping base), and delivery destination included in the purchase slip data match, and the retroactive purchase unit price master. Application start date is the latest date and is earlier than the purchase date included in the purchase slip data." In other words, since the retroactive purchase unit price master allows delivery destination = "Not registered", first the master with no delivery destination registered is used for matching, and then the slip to be retroactively matched with the master with detailed conditions including the delivery destination set.

[0076] In addition, if the purchase classification included in the purchase slip data is "direct purchase" and the delivery arrangement included in the purchase slip data is "our own company" or "previous customer," the retroactive unit price acquisition unit acquires records that meet the conditions from the retroactive purchase unit price master in the order of (41) and (42) below. (41) Obtain a record of the retroactive purchase unit price master that meets the following conditions: "The purchase category, delivery arrangement category, supplier, product, and warehouse (shipping base) included in the purchase slip data match those included in the retroactive purchase unit price master, and the delivery destination in the retroactive purchase unit price master is not registered, and the application start date in the retroactive purchase unit price master is the latest date and is earlier than the purchase date included in the purchase slip data." (42) Obtain a record of the retroactive purchase unit price master that satisfies the condition that "the purchase category, delivery arrangement category, supplier, product, warehouse (shipping base), and delivery destination included in the purchase slip data match those included in the retroactive purchase unit price master, and the retroactive purchase unit price master application start date is the latest date and is earlier than the purchase date included in the purchase slip data."

[0077] [Step S3: Retroactive processing] The retroactive processing unit reconciles (updates) the purchase price included in the purchase slip data with the retroactive unit price (purchase unit price) obtained in step S2, and reconciles the purchase amount included in the purchase slip data with the product of the retroactive unit price (purchase unit price) obtained in step S2 and the quantity included in the purchase slip data, thereby recreating the purchase price and purchase amount data included in the purchase slip data (including purchase detail data). Here, if the quantity is zero, such purchase slip data is not processed. Also, if the retroactive unit price cannot be obtained in step S2 or the retroactive unit price obtained in step S2 is zero yen, no reconciliation is performed. Also, if the purchase category included in the purchase slip data is "direct purchase," the cost and gross profit items included in the corresponding sales slip data are also updated.

[0078] As explained in detail above, another embodiment of the unit price retroactive processing relates to a retroactive update function for "sales and purchase unit prices" in businesses that handle futures commodities. In business businesses that handle futures commodities, unit prices are finalized (determined) after a certain period of time has passed, but another embodiment of the unit price retroactive processing makes it possible to perform a batch update process on provisionally registered receipt and payment unit prices under certain conditions. Specifically, another embodiment of the unit price retroactive processing makes it possible to (1) update sales unit prices using a retroactive batch update process, (2) update purchase unit prices using a retroactive batch update process, and (3) create conditions for attaching unit prices (retroactive unit price master data).

[0079] Until now, businesses that handle futures-related commodities (for example, energy, sugar, or wheat) have had to update sales slips for a certain period according to certain rules, but there was no processing function that allowed them to update unit prices in bulk according to certain conditions. This meant that past slips had to be manually retrieved and corrected one by one, which was time-consuming. Therefore, in another embodiment of the unit price retroactive processing, by adopting the configuration and processing described above, it has been possible to significantly reduce the amount of work that was previously required.

[0080] [6. 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.

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

[0082] Furthermore, this embodiment can contribute to strengthening control and governance, which can contribute to the achievement of Goal 16 of the SDGs.

[0083] 7. 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.

[0084] 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.

[0085] Furthermore, 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 can be changed as desired unless otherwise specified.

[0086] Furthermore, with regard to the task support device 100, the components shown in the figures are functional concepts, and do not necessarily have to be physically configured as shown in the figures.

[0087] For example, all or any part of the processing functions of the business support device 100, particularly the processing functions performed by the control unit, may be realized by a CPU and a program interpreted and executed by the CPU, or may be realized 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 business support device 100 as needed. That is, a computer program for providing instructions to the CPU in cooperation with the OS and performing various processes is recorded in a storage unit such as a ROM or HDD (Hard Disk Drive). The computer program is executed by being loaded into RAM, and cooperates with the CPU to form the control unit.

[0088] This computer program may be stored in an application program server connected to the business support device 100 via any network, and all or part of it may be downloaded as needed.

[0089] Furthermore, the program for executing the processes described in this embodiment may be stored in a non-transitory computer-readable recording medium or 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.

[0090] Furthermore, a "program" is a data processing method written in any language or description method, regardless of the format, such as source code or binary code. Note that a "program" is not necessarily limited to a single program, but also includes programs that are distributed as multiple modules or libraries, or programs that achieve their functions by working together with other programs, such as an OS. Note that the specific configurations and reading procedures for reading a recording medium in each device shown in the embodiments, as well as the installation procedures after reading, can use well-known configurations and procedures.

[0091] The various databases stored in the memory unit 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 store various programs, tables, databases, and web page files used for various processes and providing websites.

[0092] The business support 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. The business support device 100 may be realized by installing software (including programs, data, etc.) that causes the device to perform the processes described in this embodiment.

[0093] 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 configured by functionally or physically distributing and integrating them in any unit according to various additions or functional loads. In other words, the above-described embodiments can be implemented in any combination, or embodiments can be implemented selectively. [Industrial Applicability]

[0094] The present invention is particularly useful in industries that deal in futures products. [Explanation of symbols]

[0095] 100 Business support equipment 102 Control section 102a Unit Price Master Registration Section 102b Unit price retroactive processing section 102c Claims Processing Department 102d Payment method determination processing section 104 Communication interface unit 106 Storage section 106a Unit Price Master 106b Sales Data 106c Purchase Data 108 Input / Output Interface Section 112 Input Device 114 Output Device 200 servers 300 Network

Claims

1. a data confirmation unit that confirms whether a unit price confirmation flag indicating that the unit price is not yet determined is included in transaction data that includes transaction identification information, product identification information or a customer, a unit price acquired from a unit price master, and a unit price confirmation flag indicating whether the unit price acquired from the unit price master is confirmed or not; a data processing unit that, when the data confirmation unit confirms that the transaction data contains a unit price confirmation flag indicating that the unit price has not been confirmed, displays a message to prompt the user to correct the unit price master and recreate the transaction data so that the confirmed unit price and the unit price confirmation flag indicating that the unit price has been confirmed are registered, and creates correction data for correcting the unit price master; A business support device comprising:

2. a display processing unit that displays the correction data created by the data processing unit in a manner that allows the unit price included in the correction data and a unit price determination flag indicating that the unit price has not been determined to be changeable; a master updating unit that, when the displayed unit price is changed and the displayed unit price confirmation flag is changed to indicate that the unit price has been confirmed, regards the changed unit price as the confirmed unit price, updates the unit price and unit price confirmation flag included in the displayed correction data to the changed unit price and the changed unit price confirmation flag, respectively, and updates the unit price master using the updated correction data; a data updating unit that updates the unit price and the unit price determination flag included in the transaction data based on the unit price master after the master updating unit has updated; The task support device according to claim 1 , further comprising:

3. the transaction data relates to sales; The transaction identification information is sales identification information, The business partner is a customer, The unit price set in the unit price master is the sales unit price, 3. The business support device according to claim 1 or 2,

4. The transaction data relates to purchases, The transaction identification information is purchase identification information, The business partner is a supplier, The unit price set in the unit price master is the purchase price, 3. The business support device according to claim 1 or 2,

5. a data confirmation step in which a data confirmation unit confirms whether transaction data including transaction identification information, product identification information or customer, unit price acquired from the unit price master, and unit price confirmation flag acquired from the unit price master indicating whether the unit price is confirmed or not includes a unit price confirmation flag indicating that the unit price is not confirmed; a data processing step in which, when the data confirmation unit confirms that the transaction data contains a unit price confirmation flag indicating that the unit price has not been confirmed, the data processing unit executes the following data processing steps: displaying a message to prompt the user to correct the unit price master and recreate the transaction data so that the confirmed unit price and the unit price confirmation flag indicating that the unit price has been confirmed are registered; and creating correction data for correcting the unit price master; A business support method having the above.

6. Computer, data confirmation means for confirming whether a unit price determination flag indicating that the unit price is not yet determined is included in transaction data including transaction identification information, product identification information or business partner, unit price acquired from the unit price master, and unit price determination flag indicating whether the unit price is determined or not acquired from the unit price master; a data processing means for, when the data confirmation means confirms that the transaction data contains a unit price confirmation flag indicating that the unit price has not been confirmed, displaying a message to prompt the user to correct the unit price master and recreate the transaction data so that the confirmed unit price and the unit price confirmation flag indicating that the unit price has been confirmed are registered, and creating correction data for correcting the unit price master; A business support program to function as a

Images