Transaction support device and transaction support method
The transaction support device optimizes price adjustments in supply chains by setting price formulas, registering costs, and determining appropriateness, addressing inefficiencies and risks in undisclosed cost-based negotiations.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- HITACHI LTD
- Filing Date
- 2024-07-30
- Publication Date
- 2026-06-02
AI Technical Summary
Existing price negotiation methods in supply chains lack efficiency and transparency, particularly for resource-based prices, as they rely on undisclosed manufacturing costs, leading to inefficiencies and risks in price adjustments.
A transaction support device and method that enables price formula setting, cost registration, and appropriateness determination, ensuring trade secret protection while optimizing price adjustments between sellers and buyers.
Facilitates efficient and transparent price adjustments by protecting cost data secrecy and validating price calculations, reducing labor and time in negotiations, and ensuring fair pricing.
Smart Images

Figure 0007869269000001 
Figure 0007869269000002 
Figure 0007869269000003
Abstract
Description
Technical Field
[0001] The present invention relates to, for example, a transaction support device and a transaction support method.
Background Art
[0002] In price adjustment in the supply chain, it is common for the seller to negotiate with the buyer with the asking price being based on the undisclosed manufacturing cost plus the desired profit.
[0003] In this case, advantages include a low administrative burden because there is no need to disclose cost details, and the ability to achieve a high profit rate depending on the negotiation. On the other hand, disadvantages include the need to request a price negotiation each time the cost rises sharply, which is time-consuming in terms of preparation and there is a risk that sufficient price transfer cannot be achieved.
[0004] Also, as prices rise, there is a need to review the prices of various items, but price review negotiations are a very large burden for both sellers and buyers. In particular, for resource prices and the prices of materials processed from resources, since the market prices of resources fluctuate sharply, there is already a mechanism for automatically determining prices using a price formula with the market price of resources as a parameter.
[0005] For example, there is a proposal to apply a price formula to a technology for efficiently managing the entire transaction of commercial materials between multiple suppliers and multiple customers (Patent Document 1).
Prior Art Documents
Patent Documents
[0006]
Patent Document 1
Summary of the Invention
Problems to be Solved by the Invention
[0007] Traditionally, it has been possible to introduce price formulas to general-purpose goods (mass-produced goods) that are continuously produced from the perspective of ongoing transactions, but it is unclear whether this would lead to a reduction in labor or efficiency in price negotiations.
[0008] The prices here differ from the upstream resource and material prices in the supply chain. That is, while cost items need to include the supplier's raw material costs, fuel costs, transportation costs, etc., these are essentially the supplier's trade secrets. Therefore, if cost data is not disclosed, it becomes difficult for buyers to calculate prices using price formulas or to check the reasonableness of those prices.
[0009] This invention was made in view of the above background, and aims to provide a transaction support device and transaction support method that can achieve both trade secret protection of cost data and validity checks of price calculations, thereby optimizing and facilitating price adjustments between sellers and buyers. [Means for solving the problem]
[0010] To solve the above-mentioned problems and achieve the above objectives, one embodiment of the present invention is a transaction support device that assists in price adjustment in transactions between a seller terminal and a buyer terminal via a network, comprising: a setting unit for setting a price formula for the transaction; a cost registration unit for registering the costs of the goods handled in the transaction; a product price calculation unit for calculating the transaction amount based on the costs registered in the cost registration unit by referring to the price formula set in the setting unit; and an appropriateness determination unit for comparing the transaction amount calculated by the product price calculation unit with past transaction amounts and determining whether the transaction is appropriate based on the comparison result.
[0011] Another embodiment of the present invention is a transaction support method for a device that assists in price adjustment in transactions between a seller terminal and a buyer terminal via a network, comprising: a setting step of setting a price formula for the transaction and storing it in memory; a cost registration step of registering the cost of the goods to be handled in the transaction after setting the price formula in the setting step; a transaction amount calculation step of calculating the transaction amount based on the cost registered in the cost registration step by referring to the price formula stored in memory; and an appropriateness determination step of comparing the transaction amount calculated in the transaction amount calculation step with past transaction amounts and determining whether the transaction is appropriate based on the comparison result. [Effects of the Invention]
[0012] According to the present invention, it is possible to provide a transaction support device and transaction support method that can achieve both trade secret protection of cost data and validity checks of price calculations, thereby optimizing and facilitating price adjustments between sellers and buyers. [Brief explanation of the drawing]
[0013] [Figure 1] A block diagram showing the functions of a trading support device according to one embodiment of the present invention. [Figure 2] This is a configuration diagram showing the hardware configuration of a trading support device according to one embodiment of the present invention. [Figure 3] This is a flowchart illustrating the consensus-building process for a price formula according to one embodiment of the present invention. [Figure 4] This is a flowchart illustrating the process for determining a price formula according to one embodiment of the present invention. [Figure 5] This is an explanatory diagram showing an example screen for creating a price formula using one embodiment of the present invention. [Figure 6] This is an explanatory diagram showing another example screen for creating a price formula according to one embodiment of the present invention. [Figure 7]An explanatory diagram showing another screen example for creating a price formula according to an embodiment of the present invention. [Figure 8] An explanatory diagram showing another screen example for creating a price formula according to an embodiment of the present invention. [Figure 9] An explanatory diagram showing another screen example for creating a price formula according to an embodiment of the present invention. [Figure 10] A flowchart explaining a process for registering a calculation formula template according to an embodiment of the present invention. [Figure 11] An explanatory diagram showing an example of a registration screen for a calculation formula template according to an embodiment of the present invention. [Figure 12] An explanatory diagram showing another example of a registration screen for a calculation formula template according to an embodiment of the present invention. [Figure 13] An explanatory diagram explaining a storage method between a calculation formula and a cost according to an embodiment of the present invention. [Figure 14] An explanatory diagram explaining a data relationship according to an embodiment of the present invention. [Figure 15] A flowchart explaining a price review process according to an embodiment of the present invention. [Figure 16] A flowchart explaining a cost registration process according to an embodiment of the present invention. [Figure 17] An explanatory diagram showing an example of a screen related to cost registration according to an embodiment of the present invention. [Figure 18] A flowchart explaining a manual price review process according to an embodiment of the present invention. [Figure 19] A flowchart explaining a periodic price review process according to an embodiment of the present invention. [Figure 20] A flowchart explaining a process related to order reception and placement according to an embodiment of the present invention. [Figure 21] A flowchart explaining a process related to price search according to an embodiment of the present invention. [Figure 22]This is an explanatory diagram showing an example screen related to price search according to one embodiment of the present invention. [Figure 23] This is an explanatory diagram illustrating the relationship between the price formula and coefficients according to one embodiment of the present invention. [Figure 24] This is an explanatory diagram illustrating the relationship between product-specific cost items and their amounts in one embodiment of the present invention. [Figure 25] This is an explanatory diagram illustrating the relationship between cost items and amounts by cost data according to one embodiment of the present invention. [Figure 26] This is an explanatory diagram showing an example of a quotation based on one embodiment of the present invention. [Figure 27] This is an explanatory diagram showing another example of a quotation based on one embodiment of the present invention. [Modes for carrying out the invention]
[0014] Embodiments of the present invention will be described below with reference to the drawings. Note that the following description and drawings are merely illustrative examples for explaining the present invention, and have been omitted or simplified as appropriate for clarity of explanation. Furthermore, the present invention can be implemented in various other forms. Also, unless otherwise specified, each component may be singular or plural.
[0015] In the following explanation, identical or similar structures may be denoted by the same symbol, and redundant explanations may be omitted. Also, in the following explanation, various types of information may be described using expressions such as "information" and "table," but these types of information may be represented by data structures other than these. Furthermore, while expressions such as "identification information," "identifier," "name," "ID," and "number" may be used to represent identification information, these can be substituted for each other. In the following explanation, "database" will be abbreviated as "DB" and "table" as "TBL."
[0016] First, the configuration will be explained using Figures 1 and 2. Figure 1 is a block diagram showing the functions of the trading support device according to this embodiment, and Figure 2 is a configuration diagram showing the hardware configuration of the trading support device according to this embodiment.
[0017] In the following explanation, "cost" refers to expenses incurred between the seller and its subcontractors, as well as expenses incurred within the seller. "Price" refers to the cost of goods traded between the seller and the buyer. A "price formula" is a calculation formula associated with a product used to determine its price. A "calculation formula template" is a type or pattern of calculation formula used to generate a price formula.
[0018] The transaction support device (hereinafter referred to as "server") 10 of this embodiment is connected via a network 200 to the seller's terminal (for example, the seller's terminal 40) and the buyer's terminal (for example, the buyer's terminal 60 that executes a transaction with the seller's terminal 40), as shown in Figure 1, for example, and is a mechanism that realizes appropriate price adjustments in transactions at each stage from upstream to downstream in the supply chain.
[0019] As shown in Figure 1, for example, the server 10 is composed of the following functions: an input unit 11, a setting unit 12, a cost registration unit 13, a storage unit 14, a calculation formula template processing unit 19, a transaction history processing unit 20, a product price calculation unit 21, an anomaly detection unit 22, an appropriateness judgment unit 23, and an output unit 24. The storage unit 14 is composed of the following: a cost table 15 for registering (storing) costs, a price formula table 16 for registering (storing) price formulas, a calculation formula template table 17 for registering (storing) calculation formula templates, and a transaction history database 18 for registering (storing) invoices and quotations as transaction history.
[0020] The input unit 11 communicates with external terminals such as the seller terminal 40 and the buyer terminal 60 via the network 200 to input data and other information, and then processes it internally. The setting unit 12 sets the price formula through communication with the seller terminal 40, etc., and registers it in the price formula TBL 16.
[0021] The cost registration unit 13 registers various costs related to the manufacture of goods in the cost table 15 via communication with the seller terminal 40, etc., using invoices or manual operation. The calculation formula template processing unit 19 is responsible for setting up new calculation formula templates and registering them in the calculation formula template table 17 via communication with the seller terminal 40, etc., and for selecting the calculation formula template necessary to determine the price formula for a product from the registered calculation formula templates.
[0022] The transaction history processing unit 20 registers invoices and quotations through communication with the seller terminal 40, etc. The product price calculation unit 21 calculates the price based on the price formula of the product being traded before the order is placed.
[0023] The anomaly detection unit 22 refers to the transaction history DB 18 as material for determining whether the calculated price is appropriate or not, based on whether it is an abnormal value as described later, and determines whether it is inappropriate, i.e., abnormal, by comparing it with past prices of the same product. If the anomaly detection unit 22 detects an anomaly, the appropriateness determination unit 23 outputs the determination result to the output unit 24 and notifies the buyer terminal 60.
[0024] In addition to notifying the detection of the abnormality described above, the output unit 24 is responsible for forming necessary screens and outputting data during procedures conducted through communication with the seller terminal 40 and the buyer terminal 60 according to this embodiment, by referring to the storage unit 14.
[0025] The server 10 of this embodiment is composed of, for example, a CPU 101 that controls the entire device, a memory 103 that stores programs 102 for processing to be executed by the CPU 101 and various data being executed, an operating device 104 equipped with a keyboard and a display device, an external storage device 105 that registers and stores various data in the format of DB, TBL, etc., a communication IF 106 connected to the network 200 and responsible for communication with external devices, and a bus 107 connected to each unit within the device and responsible for communication of data, signals, etc. within the device. The seller terminal 40 and the buyer terminal 60 each have input / output units 41 and 61 that perform screen display and operation input, respectively.
[0026] Next, we will explain the process related to the price formula and calculation formula template using Figures 3 to 14. Figure 3 is a flowchart illustrating the consensus building process for the price formula according to this embodiment, Figure 4 is a flowchart illustrating the process for determining the price formula according to this embodiment, and Figures 5 to 9 are explanatory diagrams showing example screens for creating the price formula according to this embodiment.
[0027] Figure 10 is a flowchart illustrating the process for registering a calculation formula template according to this embodiment, Figure 11 is an explanatory diagram showing an example of the calculation formula template registration screen according to this embodiment, Figure 12 is an explanatory diagram showing another example of the calculation formula template registration screen according to this embodiment, Figure 13 is an explanatory diagram illustrating the storage method between calculation formulas and costs according to this embodiment, and Figure 14 is an explanatory diagram illustrating the data relationships according to this embodiment.
[0028] The procedure for introducing a price formula is carried out, for example, in the process shown in Figure 3. First, the seller terminal 40 determines a draft price formula (step S32), and the seller terminal 40 and the buyer terminal 60 discuss and agree on the draft price formula (step S322).
[0029] Then, when the agreed-upon price formula is registered in the price formula TBL16 of the server 10 by the seller terminal 40 (step S322), the server 10 sends a notification of the registration to the buyer terminal 60, and the price formula is finalized when the buyer terminal 60 performs an approval operation (step S311).
[0030] Details of the registration of the price formula by step S323 described above are shown in Figure 4. The seller terminal 40, which acts as a client to the server 10, first accesses the server 10 (step S411). When the server 10 receives a screen for the procedure to search for a calculation formula template, the screen shown in Figure 5 is displayed on the input / output unit 41 of the seller terminal 40.
[0031] First, as shown in Figure 5, it is necessary to input information about the product for which the price formula will be created. Specifically, the product category and cost items (major category, medium category, minor category, and cost item name) are displayed as dropdown menus for selection.
[0032] As shown in Figure 13(B), each cost item is assigned an ID, and data is linked to it such as a cost item name indicating whether it is a material cost or a labor cost, a major category indicating whether it is a procured item or an added value item, a medium category indicating whether it is available from the general market or is original, and a minor category indicating whether it is a part / component, raw material or assembled / processed product. For example, cost item ID "C3301" is linked to the cost item name "Electronic Parts", major category "Procured Item", medium category "Non-Market Item", and minor category "Parts / Components".
[0033] When the seller terminal 40 inputs the product category and cost items through the seller user's operation (step S4112), the server 10 accepts the input operation, refers to the calculation formula template TBL17, and searches for the corresponding calculation formula template from past registration data (step S432).
[0034] The search results are sent from the server 10 to the seller terminal 40 (step S433) and displayed on the input / output unit 41, for example, as shown in Figure 6 (step S413). In the example in Figure 6, only two calculation formula templates are displayed as search results. Selection is made by checking the box in the "Use" column.
[0035] The calculation formulas shown in the calculation template are used by substituting the costs stored in the cost registration described later. In example No. 1, the calculation formula is parts cost × (1 + commission rate) + assembly labor cost × (1 + profit margin).
[0036] In this way, the seller terminal 40 can select an available calculation formula template (step S414) and then proceed to the procedure for setting the price formula from step S415 onwards. If there is no calculation formula template available, the process proceeds to the flowchart shown in Figure 10.
[0037] When a calculation formula template is selected, as shown in Figure 7, that template becomes a candidate for the price formula, and each coefficient is also displayed. The seller user operating the seller terminal 40 can provisionally register the price formula by operating the "Provisional Registration" button.
[0038] If the "Finish" button is pressed without provisional registration, the registration of the price formula will be terminated as a process. If the "Back" button is pressed, the operation screen will return to the state shown in Figure 6.
[0039] As shown in Figure 7, reference values are provided for each coefficient of commissions and profit margins, indicating that all meet the standard range. Ideally, the price formula should be determined based on the actual cost structure and pricing strategy, determining the "formula" and "coefficients." However, since not all small and medium-sized enterprises can easily create the formula and coefficients, while the final decision rests with the seller, the system may also be designed to provide reference values.
[0040] One method of calculation is to use the least squares method, employing actual past sales prices and corresponding cost data. Alternatively, calculations may be performed using hypothetical cost data and a desired price, similar to a simulation. Furthermore, there may be cases where actual past sales prices and corresponding cost data are unavailable. Therefore, it is possible to utilize the same coefficients within the same calculation formula template, and the mean or median of the same coefficients can also be used. In this case, there is the added convenience of not having to prepare actual past sales prices or cost data.
[0041] The method for setting the standard range shall be to statistically treat the same coefficients in the same calculation formula template. For example, for a certain coefficient, the standard may be considered met if it falls within a range of 30% above or below the median (within 60% of the total).
[0042] To summarize, in step S415, if assistance is needed for each coefficient, the server 10 will be asked to refine the reference values. If the seller terminal 40 does not perform an operation to request assistance (the NO route in step S415), the process ends. On the other hand, if an operation to request assistance is performed (the YES route in step S415), first, the calculation formula template to be used is selected, and the calculation of the coefficients with assistance is performed (step S416).
[0043] In other words, on the screen shown in Figure 6, if the seller user has already considered the coefficients and wants to input them directly, the "Register Coefficient" button is pressed, and the details are omitted. On the other hand, if the seller wants to consider the coefficients with assistance from Server 10, the "Consider Coefficients" button is pressed.
[0044] When the "Coefficient Analysis" button is pressed, the server 10 sends a screen to the seller terminal 40 showing fields for registering the product price and cost data (step S434). On the seller terminal 40, as shown in Figure 9, these registration fields are displayed, and the product price and cost data are entered (step S417). In the example in Figure 9, past transaction dates (year and month), product price, parts / component costs, and assembly labor costs can be entered.
[0045] Once the input is complete, the server 10 calculates the coefficient reference value (step S435) and reads the base range from the calculation formula template TBL17 (step S436). Then, the evaluation result of the coefficient reference value and base range, along with the registration field for the price formula, is sent to the seller terminal 40 (step S437).
[0046] On the seller terminal 40, as shown in Figure 7, the reference values for each coefficient of the commission and profit margin are displayed along with the price formula, and the evaluation result of the reference range (in this case, OK) is also displayed (step S418). If an operation is performed indicating that a review of the reference coefficient values is necessary (YES route in step S419), the process returns to step S416 and the same process is repeated.
[0047] Furthermore, if the registration operation is performed without requiring review (the NO route in step S419), the screen shown in Figure 8 is sent to the seller terminal 40 for confirmation, and the price formula is registered according to the registration instructions (step S420). At that time, the server 10 registers (stores) the price formula in the price formula TBL 16 according to the operation of the seller terminal 40 (step S438).
[0048] Once this registration is complete, a price formula save completion screen is sent from the server 10 to the seller terminal 40 (step S439) and displayed on the input / output unit 41 (step S421). In the case of a termination operation, this process is terminated.
[0049] Here, we will also explain how to register a new calculation formula template. In this case, since a buyer may become a seller at a downstream level (stage) in the supply chain, the client in Figure 10 will perform the same processing not only on the seller terminal 40 but also on the buyer terminal 60.
[0050] In formula template registration, the client accesses the server 10 to initiate the process (step S1111), and the server 10 sends the formula template registration field to the client (step S1121). As shown in Figure 11, the formula template registration screen displays input or drop-down selection items such as product unit price, applicable product category, and cost items (major category, medium category, minor category, cost item name).
[0051] Cost items can be added by operating the add button. Additionally, operating the back button may return to the process shown in Figure 4 and terminate the process, or it may return to step S414.
[0052] When the client completes entering or selecting information in the registration fields and clicks the "Next" button, the completed data is sent to the server 10 (step S1112). The server 10 checks the input content (step S1122), and if there are any errors or omissions, it determines that there is a problem (YES route in step S1123), and the calculation formula template failure screen is sent to the client (step S1125). In this case, the client returns to step S1112, marking the data as unsaved, and the process is repeated.
[0053] On the other hand, if it is determined that there are no problems with the registration (the NO route in step S1123), the new formula template is registered (stored) in the formula template TBL17 (step S1124). In this case, a screen indicating that the formula template has been saved is sent to the client (step S1125), and the client considers the saving complete and the process ends (step S1113).
[0054] When registering the new calculation formula template described above, you may also use the process of uploading pre-prepared files containing product unit prices and cost items by dragging and dropping them, as shown in Figure 12.
[0055] The calculation formula templates to be registered are then registered in the calculation formula template TBL17, as shown in Figure 13(A). That is, each calculation formula is assigned an ID, and the details of the calculation formula and the applicable product categories (assembled products, metal products, etc.) are linked and registered. For example, the calculation formula ID "F1101" is linked to the calculation formula "parts cost × (1 + commission rate) + assembly labor cost × (1 + profit margin)" and the applicable product category "assembled products".
[0056] Furthermore, as shown in Figure 13(C), the formula template TBL17 registers the association between the formula ID and the cost item ID. For example, the formula ID "F1101" is associated with the cost item ID "C3301". When the overall association relationships are organized in this way, the storage unit 14 registers the formula, applicable product category, cost item ID, cost item name, major category, medium category, and minor category, associated with the formula ID, according to the correspondence in Figures 13(A), (B), and (C), as shown in Figure 14.
[0057] Next, we will explain price review using Figures 15 to 19. Figure 15 is a flowchart illustrating the price review process according to this embodiment, Figure 16 is a flowchart illustrating the cost registration process according to this embodiment, Figure 17 is an explanatory diagram showing an example screen related to cost registration according to this embodiment, Figure 18 is a flowchart illustrating the manual price review process according to this embodiment, and Figure 19 is a flowchart illustrating the periodic price review process according to this embodiment.
[0058] Figure 15 assumes a transaction where the client, as a seller, orders raw materials, parts, and components from a secondary subcontractor. Therefore, it is assumed that the seller and the secondary subcontractor exchange cost data either online using terminals (network 200) or offline without using terminals.
[0059] In the case of online transactions, as shown in Figure 15, cost data is submitted to the seller terminal 40 from the secondary subcontractor terminal (step S1521). The seller terminal 40 registers the submitted cost data in the transaction history DB 18 (step S1511) and determines whether a price review is immediately necessary (step S1512).
[0060] If a price review is immediately necessary (YES route in step S1512), the price review calculation is performed manually (step S1513). On the other hand, if a price review calculation is not immediately necessary (NO route in step S1512), the price review calculation is performed periodically by server 10 (step S1531). This periodic review is preferably performed on a monthly, quarterly, first-half / second-half, or annual basis, but is not limited to these.
[0061] The cost registration in step S1511 will be explained in detail in Figure 16. The seller terminal 40 accesses the server 10 for cost registration (step S1611), and the server 10 receives the access, generates a cost data registration screen, and sends it to the seller terminal 40 (step S1621).
[0062] As a result, the cost data registration screen is displayed on the input / output unit 41 of the seller terminal 40, and the input of cost data and the upload of invoices / quotations are performed (step S1612). Figure 17 shows the cost data registration screen. The registration contents are linked to the cost item and include the date the transaction occurred, the amount, the quotation / invoice classification, and the evidence. Except for the evidence, it is also possible to set this information through manual input, but it is possible to input the cost item, transaction date, and amount by uploading an actual quotation or invoice using the reference button.
[0063] Once the settings for the cost data registration screen are completed in step S1612 (by clicking the "Next" button), the cost data is sent to the server 10 and registered (stored) in the transaction history DB 18 (step S1622). Then, the server 10 sends the registration result to the seller terminal 40 (step S1623), and the seller terminal 40 displays the registration result in the input / output unit 41 (step S1613).
[0064] Here, we will explain how to identify anomalies. The anomaly check for product price and cost data is a function to ensure the buyer's confidence and security regarding the price formula, and to detect the possibility of fraud on the seller's side.
[0065] It is necessary to check whether the rate of price increase is statistically unnatural for the products covered by the price formula (= items procured by the buyer) and the items procured from the seller's primary suppliers (= cost data).
[0066] Furthermore, even if the price increase rate is judged to be an outlier based on the following logic, this does not necessarily indicate fraudulent activity by the seller or primary supplier, and appropriate communication from the seller to the buyer is required.
[0067] Therefore, multiple criteria may be set for determining whether a value is an outlier, as follows: (1) When the price increase rate of the procured item falls outside the standard range (e.g., 80% above and below the median) of the frequency distribution of price increase rates for all products. (2) When the price increase rate of the procured goods falls outside the standard range (e.g., 80% above and below the median) of the frequency distribution of price increase rates of similar products. (3) When the price increase rate of the primary procurement item (= cost data) of the procured item falls outside the standard range relative to the frequency distribution of price increase rates for all products. (4) When the price increase rate of the primary procurement item (= cost data) of the procured item falls outside the standard range relative to the frequency distribution of price increase rates of similar products. Of course, all four of the above may be applied, or one of them, or a combination of two or more may be used. In determining abnormal values, the abnormality detection unit 22 and the suitability determination unit 23 function primarily.
[0068] Next, the manual implementation of price revision will be explained using the process shown in Figure 18. The seller terminal 40 accesses the server 10 to implement a manual price revision (step S1821), and the server 10, in response to this access, sends a manual price revision instruction screen to the seller terminal 40 (step S1831).
[0069] On the seller terminal 40, the seller user instructs the price revision calculation to be performed (step S1822), and the server 10 executes the price revision calculation (step S1832). After the calculation is completed, a calculation completion screen is sent from the server 10 to the seller terminal 40 (step S1833), and the calculation completion screen is displayed on the input / output unit 41 on the seller terminal 40 (step S1823).
[0070] Meanwhile, server 10 performs an abnormal value check (step S1834). If it is determined that the value is abnormal (YES route in step S1835), server 10 sends an alert to buyer terminal 60, not seller terminal 40. Buyer terminal 60 receives the alert and displays it in input / output unit 41 (step S1811). At this point, seller terminal 40 cannot obtain the result of whether the price is abnormal or not. If it is determined in step S1835 that the value is not abnormal (NO route in step S1835), the process ends there (step S1835).
[0071] Furthermore, the implementation of periodic price reviews will be explained using the process shown in Figure 19. Figure 19 illustrates the operation of a system in which an auxiliary server has been newly linked to server 10. It goes without saying that the auxiliary server's functions could also be handled by server 10.
[0072] In Figure 19, the auxiliary server responsible for job management functions, etc., monitors the schedule for price review timing (step S1921). When it is determined that the time for price review has arrived (YES route in step S1922), the auxiliary server instructs server 10 to perform the price review calculation (step S1923).
[0073] Server 10 performs a price revision calculation according to the basis (step S1931), and the completion of the calculation is sent from server 10 to the auxiliary server (step S1932).
[0074] Next, the server 10 performs an abnormal value check (step S1933). If it is determined that the price is an abnormal value (YES route in step S1934), the server 10 notifies the buyer terminal 60 of an alert, which the buyer terminal 60 receives and displays on the input / output unit 41 (step S1911). If it is determined in step S1934 that the price is not an abnormal value (NO route in step S1934), the process ends there (step S1934).
[0075] Next, we will explain order placement and acceptance using Figure 20. Figure 20 is a flowchart illustrating the order placement and acceptance process according to this embodiment. In order placement and acceptance between sellers and buyers, first, the buyer terminal 60 accesses the server 10 to confirm the price (step S2011), and then places an order request (step S2012). The seller terminal 40 accepts the order request from the buyer terminal 60 (step S2021).
[0076] Specific examples will be explained using Figures 21 and 22. Figure 21 is a flowchart illustrating the price search process according to this embodiment, and Figure 22 is an explanatory diagram showing an example screen for price search according to this embodiment.
[0077] Regarding step S2011 (Figure 20) described above, the buyer terminal 60 accesses the server 10 for price search (step S2111), and the server 10 sends a price search screen in response to the access (step S2121). The buyer terminal 60 receives the price search screen and displays it in the input / output unit 61, and the buyer inputs the product information they want to search for (step S2112).
[0078] As shown in Figure 22, the price search screen requires the model name of the product to be searched for. If the model name is unknown, the supplier name or product name can be entered. The search is executed by clicking the "Next" button. The price search process ends when the "Back" button is clicked.
[0079] On server 10, a price search is performed on price formula TBL 16 (step S2122), and the search results are sent to buyer terminal 60 as registration results (step S2123). Then, on buyer terminal 60, the registration results are displayed on input / output unit 61 (step S2113).
[0080] Here, Figures 23, 24, and 25 will be used to provide supplementary explanations regarding the storage methods for various types of data. Figure 23 is an explanatory diagram illustrating the relationship between the price formula and coefficients according to this embodiment, Figure 24 is an explanatory diagram illustrating the relationship between cost items and amounts for each product according to this embodiment, and Figure 25 is an explanatory diagram illustrating the relationship between cost items and amounts for each type of cost data according to this embodiment.
[0081] Regarding coefficients, for example, as shown in Figure 23, the price formula TBL16 registers the coefficient name, calculation formula ID, price formula ID, and coefficient value for the commission or profit margin, linked to the coefficient ID. For example, coefficient ID "222" is linked to coefficient name "Commission", calculation formula ID "F1111", price formula ID "A11111", and value "1.12". In the example in Figure 23, the coefficient ID, coefficient name, and calculation formula ID are common, but different values are set for different price formula IDs.
[0082] Furthermore, the checking of outliers in cost data will be explained using Figures 24 and 25. Figure 24 shows the contents of Cost TBL15, where the number of price updates, major category, medium category, minor category, cost item name, and amount are registered and linked to the product ID.
[0083] This compares the historical price of product ID "P1111" with the updated price. The historical price was 1,000 yen, while the updated price is 1,100 yen, a difference of 100 yen. In this case, we can see that the price has increased by 10%.
[0084] Furthermore, we compare the historical price of product ID "P2222" with the price after the price update. The historical price was 50,000 yen, while the updated price is 51,000 yen, a difference of 1,000 yen. In this case, we can see that the price has increased by 2.0%.
[0085] Furthermore, we compare the historical price of product ID "P3333" with the price after the price update. The historical price was 2,580 yen, while the updated price is 2,620 yen, a difference of 40 yen. In this case, we can see that the price has increased by 1.6%.
[0086] Furthermore, we compare the historical price of product ID "P4444" with the price after the price update. The historical price was 7,800 yen, while the updated price is 8,100 yen, a difference of 300 yen. In this case, we can see that the price has increased by 3.8%.
[0087] Furthermore, we compare the historical price of product ID "P5555" with the price after the price update. The historical price was 350 yen, while the updated price is 370 yen, a difference of 20 yen. In this case, we can see that the price has increased by 5.7%.
[0088] Based on the above, when extracting data from the same cost item, the average rate of increase is 4.6%, and the median rate of increase is 3.8%. By using these results as a reference and defining how far the rate of increase should deviate from the standard to be considered an outlier, it becomes possible to achieve appropriate price adjustments.
[0089] Similarly, the example in Figure 25 also allows for checking for anomalies in cost data. In this case, the same cost items would be extracted and the check performed. Figure 25 shows the contents of Cost TBL15, where the number of entries, cost item name, major category, medium category, minor category, and amount are registered and linked to the cost data ID.
[0090] This compares the historical price and the updated price for cost data ID "C1111". The historical price was 1,000 yen, while the updated price is 1,100 yen, a difference of 100 yen. In this case, it can be seen that the price increased by 10%.
[0091] Furthermore, we compare the historical price of product ID "C2222" with the price after the price update. The historical price was 50,000 yen, while the updated price is 51,000 yen, a difference of 1,000 yen. In this case, we can see that the price has increased by 2.0%.
[0092] Furthermore, we compare the historical price of product ID "C3333" with the price after the price update. The historical price was 3,000 yen, while the updated price is 3,100 yen, a difference of 100 yen. In this case, we can see that the price has increased by 3.3%.
[0093] Furthermore, we compare the historical price of product ID "C4444" with the price after the price update. The historical price was 580 yen, while the updated price is 600 yen, a difference of 20 yen. In this case, we can see that the price has increased by 3.4%.
[0094] Furthermore, we compare the historical price of product ID "C5555" with the price after the price update. The historical price was 1,750 yen, while the updated price is 1,820 yen, a difference of 70 yen. In this case, we can see that the price has increased by 4.0%.
[0095] Based on the above, when extracting data from the same cost item, the average rate of increase is 4.6%, and the median rate of increase is 3.4%. By using these results as a reference and defining how far the rate of increase should deviate from the standard to be considered an outlier, it becomes possible to achieve appropriate price adjustments.
[0096] Next, we will explain the quotation using Figures 26 and 27. Figures 26 and 27 are explanatory diagrams showing a quotation according to this embodiment, respectively. As an example, when uploading a quotation, the information that can be registered as costs must be filled in, as shown in Figure 26 or Figure 27.
[0097] As explained above, this embodiment makes it possible to achieve both trade secret protection of cost data and validity checks for price calculations, thereby optimizing and facilitating price adjustments between buyers and sellers. In particular, by using the price formula as a processing algorithm for automatic price revision, it becomes possible to implement new transaction prices by taking market prices of raw materials and parts procurement prices, which are affected by price fluctuations, as inputs.
[0098] Furthermore, at each stage of the supply chain transaction between buyers and sellers, buyers cannot see the transactions with secondary subcontractors on the seller's side. Therefore, by enabling them to detect anomalies in price fluctuations from a third-party perspective, it becomes possible to judge the fairness of the price before placing an order.
[0099] In this case, since the detection results of this anomaly are not notified to the seller, it is expected to have the effect of preventing unfair collusion between the seller and its secondary subcontractors.
[0100] Furthermore, by registering actual costs, such as raw materials, through invoices at each transaction stage from upstream to downstream in the supply chain, it becomes possible to achieve fair transaction prices without significant discrepancies. This can also be said to support the objective reflection of the impact of price fluctuations in prices based on actual costs.
[0101] Furthermore, since a calculation formula template is provided and reflected in the price formula, the creation of price formulas can be carried out easily and efficiently. In particular, when trading mass-produced goods on a continuous basis, the effort of devising a calculation formula from scratch and creating a price formula each time is eliminated, making communication between sellers and buyers more efficient.
[0102] Furthermore, each of the above-mentioned configurations, functional units, processing units, processing means, etc., may be implemented in hardware, in whole or in part, for example, by designing them as integrated circuits. Alternatively, each of the above-mentioned configurations, functions, etc., may be implemented in software by having the processor interpret and execute programs that realize each function. Information such as programs, tables, and files that realize each function can be stored in memory, hard disks, SSDs (Solid State Drives), or other recording devices, or in recording media such as IC cards, SD cards, or DVDs.
[0103] Furthermore, the arrangement of the various functional units, processing units, and databases of the information gathering system 10 described above is merely one example. The arrangement of the various functional units, processing units, and databases can be changed to the optimal arrangement from the perspective of the performance, processing efficiency, and communication efficiency of the hardware and software of these devices.
[0104] Furthermore, the configuration of the database (schema, etc.) that stores the various types of data mentioned above can be flexibly modified from the perspective of efficient resource utilization, improved processing efficiency, improved access efficiency, and improved search efficiency. [Explanation of Symbols]
[0105] 10. Server (Transaction Support Device) 11 Input section 12. Settings section 13. Cost Registration Section 14 Storage section 15 Cost TBL 16 Price Formula TBL 17. Formula Template TBL 18 Transaction History Database 19. Calculation formula template processing unit 20 Transaction History Processing Section 21 Product Price Calculation Section 22 Anomaly detection unit 23 Appropriateness Judgment Department 24 Output section 40 Seller terminals 41 Input / output section 60 Buyer terminals 61 Input / output section 101 CPU 102 Programs 103 memory 104 Operating Devices 105 External storage device 106 Communication IF 107 Bus 200 Networks
Claims
1. A transaction support device that assists in price adjustments in transactions between seller terminals and buyer terminals via a network, A setting unit for setting the price formula for the aforementioned transaction, A cost registration unit for registering the costs of the goods handled in the aforementioned transaction, A product price calculation unit calculates the price of a product by substituting the cost registered in the cost registration unit into the price formula set in the setting unit, An anomaly detection unit compares the price of the product calculated by the product price calculation unit with the price of the same product that was traded in the past, and detects whether the price increase rate is an anomaly that deviates from a predetermined standard range in relation to the distribution based on past transaction prices of the same or similar product. A transaction support device characterized by being equipped with the following features.
2. A transaction support device according to claim 1, characterized in that the setting unit sets the price formula after going through an agreement procedure in which it discusses and reaches an agreement on the price formula with the seller terminal and the buyer terminal via the network.
3. A transaction support device according to claim 1, characterized in that the goods subject to the transaction are mass-produced goods.
4. A transaction support device according to claim 3, characterized in that the setting unit sets the price formula for the mass-produced product.
5. A transaction support device according to claim 1, characterized in that the price adjustment is performed at each transaction stage of the supply chain.
6. A trading support device according to claim 1, characterized in that the setting unit sets a price formula using one or more pre-prepared calculation formula templates.
7. A transaction support device according to claim 6, wherein the product price calculation unit takes into account the cost of manufacturing when calculating the price of the product.
8. A transaction support device according to claim 6, wherein the product price calculation unit uses a weighting coefficient when calculating the price of the product.
9. A trading support device according to claim 1, characterized in that the setting unit assists in setting the price formula by calculating a reference value for a coefficient included in the price formula using a pre-prepared reference range and evaluating whether the coefficient satisfies the reference range.
10. A transaction support device according to claim 1, characterized in that the setting unit sets a price formula on a per-product basis for the transaction.
11. A transaction support method for a device that assists in price adjustments in transactions between seller terminals and buyer terminals via a network, A setting step involves setting the price formula for the aforementioned transaction and storing it in memory, A cost registration step involves registering the cost of the goods handled in the aforementioned transaction in the memory, A product price calculation step calculates the price of a product by substituting the cost registered in the cost registration step into the price formula set in the setting step, An anomaly detection step involves comparing the price of the product calculated in the product price calculation step with the price of the same product that has been traded in the past, and detecting whether the price increase rate is an anomaly that deviates from a predetermined standard range in relation to the distribution based on past transaction prices of the same or similar product. A transaction support method characterized by including the following.