Commercial flow management support method and commercial flow management support device

Abstract

To flexibly respond to various ordering and receiving patterns of a buyer and a supplier, and to support visualization of a business flow in a supply chain.SOLUTION: A business flow management support apparatus 100 is provided with a communication device 105, and an arithmetic device 104 for acquiring information on a mainstream token issued to each order destination with respect to an item at a terminal of an orderer, managing an order receiver as a transfer destination of the mainstream token, acquiring information on a subordinate token issued by the orderer or the order receiver to the Nth subcontractor for item processing, managing each Nth subcontractor as a transfer destination of the subordinate token, and managing information specifying a relation between the subordinate token and the mainstream token.SELECTED DRAWING: Figure 2

Description

[Technical field]

[0001] The present invention relates to a method and an apparatus for supporting commercial distribution management. [Background technology]

[0002] Buyers, who are at the top of the supply chain, are increasingly taking on social responsibility for their entire supply chain, including traceability, compliance, and stable product supply in the event of a large-scale disaster. For this reason, it has been a long-standing challenge for buyers to realize "visualization of commercial flows," which allows them to know their second-tier and subsequent trading partners. Prior art for managing such business operations and transaction flows includes, for example, a method and device for managing the progress of transactions using a computer, and in particular a method for managing the progress of work schedules involving multiple companies based on transaction information transmitted between companies (see Patent Document 1).

[0003] This technology relates to a method for managing the progress of transactions between companies, which is characterized by acquiring transaction information transmitted between companies via a network, developing the transaction information into a schedule including a plurality of work processes across a plurality of companies and planned completion dates, recording an actual performance date in the schedule when a work performance report is acquired for the work process, and, when the actual performance date is delayed from the planned completion date, recording a change date in the schedule to amend the planned completion date of the subsequent work process according to the number of days delayed.

[0004] In addition, regarding the production and distribution of products (especially clothing production) that involve multiple companies and have a multi-stage production and distribution structure, an information sharing system (see Patent Document 2) has also been proposed that enables different companies to share information regarding product production and distribution via communication lines.

[0005] This technology relates to an information sharing system for sharing information regarding product production and distribution between different companies via communication lines in relation to product production and distribution in which multiple companies are involved and which has a multi-stage production and distribution structure, the information sharing system comprising: a database for storing information regarding product production and distribution; a first storage means for storing information regarding product production and distribution input from a company terminal in said database; and a first transmission means for transmitting the information stored in the database to the company terminal in response to a request to view the database from the company terminal. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] Japanese Patent Application Publication No. 11-31179 [Patent Document 2] JP 2002-32434 A Summary of the Invention [Problem to be solved by the invention]

[0007] In order to visualize the supply chain, that is, the ordering relationships from the buyer to the Nth-tier supplier, the general idea is to collect ordering information from the buyer to the Nth-tier supplier and link it together. However, even if such a general method is adopted, there are two issues: First, there is no ID or other information that identifies orders placed to one's own company in the order information of other companies, making it difficult to trace and link the order information and its differentiation.

[0008] Another challenge is that, due to a background specific to the supply chain, when a prospective order is included in the supply chain, the supply chain occurs beyond the supplier without the buyer placing an order to the supplier, making it even more difficult to piece together the order and delivery information starting from the order information from the buyer.

[0009] Therefore, an object of the present invention is to provide a technology that can flexibly accommodate various ordering styles between buyers and suppliers and can support visualization of the flow of commerce in the supply chain. [Means for solving the problem]

[0010] The commercial flow management support method of the present invention that solves the above problem includes a process in which an information processing device acquires information on mainstream tokens issued to each supplier for a specified case on a client's terminal, and manages each contractor who is a supplier indicated by the information as a transfer destination of the mainstream token, a process in which the client or contractor acquires information on tributary tokens issued to Nth-tier subcontractors to process the case, and manages each Nth-tier subcontractor indicated by the information as a transfer destination of the tributary token, and a process in which information defining the relationship between the tributary tokens and the mainstream tokens is managed. When the contractor places a prospective order with the Nth-tier contractor, the above-mentioned processes related to the tributary token, which is a prospective token, are executed; when the Nth-tier contractor delivers the prospective order to the contractor, inventory information of the product manufactured by the contractor through the delivery is linked to the information of the prospective token and stored; at the terminal of the purchaser, information on the order token, which is the main token, issued to the contractor for the case after the prospective order is obtained, and the contractor indicated by the information is managed as the transfer destination of the order token; for the product of the case indicated by the order token, a process of determining whether or not inventory can be allocated based on the inventory information is executed; and if inventory allocation is possible as a result of the determination, information on the allocated inventory and the prospective token is notified to the terminal of the contractor, and the relationship between the order token and the prospective token is saved. It is characterized by: The commercial flow management support device of the present invention includes a communication device for communicating with other terminals, a process for acquiring information on a mainstream token issued to each supplier for a specified case on the purchaser's terminal and managing each supplier indicated by the information as a transfer destination of the mainstream token, a process for acquiring information on a tributary token issued by the purchaser or the supplier to an Nth-tier subcontractor for processing the case and managing each Nth-tier subcontractor indicated by the information as a transfer destination of the tributary token, and a process for managing information defining the relationship between the tributary token and the mainstream token. When the contractor places a prospective order with the Nth subcontractor, the above-mentioned processes related to the tributary token, which is a prospective token, are executed, and when the Nth subcontractor delivers the prospective order to the contractor, inventory information of the product manufactured by the contractor through the delivery is linked to the information of the prospective token and stored; at the terminal of the purchaser, information on the order token, which is the main token, issued to the contractor for the case after the prospective order is obtained, and the contractor indicated by the information is managed as the transfer destination of the order token; for the product of the case indicated by the order token, a process is executed to determine whether or not inventory can be allocated based on the inventory information; and if the result of the determination indicates that inventory can be allocated, information on the allocated inventory and the prospective token is notified to the terminal of the contractor, and the relationship between the order token and the prospective token is saved. and a computing device. Effect of the Invention

[0011] According to the present invention, it is possible to flexibly accommodate various types of order placement and receipt from buyers and suppliers, and to support visualization of the flow of commerce in the supply chain. [Brief description of the drawings]

[0012] [Figure 1] 1 is a diagram illustrating a network configuration including a commercial distribution management support device according to an embodiment of the present invention. [Diagram 2] FIG. 2 is a diagram illustrating an example of a hardware configuration of the commercial distribution management support device according to the present embodiment. [Diagram 3] FIG. 2 is a diagram illustrating an example of a hardware configuration of a buyer terminal according to the present embodiment. [Figure 4] FIG. 2 is a diagram illustrating an example of a hardware configuration of a supplier terminal according to the present embodiment. [Diagram 5] FIG. 2 is a diagram illustrating an example of a configuration of a token DB in the present embodiment. [Figure 6] 13 is a diagram illustrating an example of the configuration of a main tributary token DB in this embodiment. FIG. [Figure 7] FIG. 2 is a diagram illustrating an example of the configuration of a wallet DB in this embodiment. [Figure 8] FIG. 2 is a diagram showing an example of the configuration of a funds transfer DB in this embodiment. [Figure 9] FIG. 2 is a diagram illustrating an example of a configuration of a transaction DB in the present embodiment. [Figure 10] FIG. 2 is a diagram showing an example of the configuration of a CO2 emission DB in the present embodiment. [Figure 11] FIG. 2 is a diagram illustrating an example of the configuration of a quality DB in the present embodiment. [Figure 12] FIG. 2 is a diagram showing an example of the configuration of a logistics DB in the present embodiment. [Figure 13] FIG. 2 is a diagram showing an example of a flow of a commercial distribution management support method in the present embodiment. [Figure 14A] FIG. 2 is a conceptual diagram showing an example of a processing image in the present embodiment. [Figure 14B] FIG. 2 is a conceptual diagram showing an example of a token flow in the present embodiment. [Figure 15] FIG. 11 is a conceptual diagram showing another example of a processing image in the present embodiment. [Figure 16] FIG. 11 is a diagram showing an example of transition of a token DB in this embodiment. [Figure 17] A figure showing an example of transition of a wallet DB in this embodiment. [Figure 18] FIG. 2 is a conceptual diagram showing an example of a processing image in the present embodiment. [Figure 19]FIG. 2 is a conceptual diagram showing an example of a token flow in the present embodiment. [Figure 20] FIG. 2 is a diagram showing an example of a flow of a commercial distribution management support method in the present embodiment. [Figure 21] FIG. 13 is a diagram showing an example of transition of an inventory database in the present embodiment. [Figure 22] FIG. 11 is a diagram showing an example of transition of a token DB in this embodiment. [Figure 23] A figure showing an example of the evolution of a prospect token DB in this embodiment. [Figure 24] FIG. 2 is a diagram showing an example of a correspondence between a token flow and a CO2 emission calculation method in this embodiment. [Diagram 25] FIG. 2 is a diagram showing an example of a flow of a commercial distribution management support method in the present embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] <Network configuration> Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. Fig. 1 is a network configuration diagram including a commercial distribution management support device 100 of this embodiment. The commercial distribution management support device 100 shown in Fig. 1 is a computer that can flexibly handle various types of order placement and receipt by buyers and suppliers and can support visualization of the commercial distribution in the supply chain.

[0014] 1, the commercial distribution management support device 100 of the present embodiment is communicably connected to a buyer terminal 200 and a supplier terminal 250 via a network 1. Therefore, these may be collectively referred to as a commercial distribution management support system 10.

[0015] The commercial distribution management support device 100 of this embodiment can be said to be a service providing device that provides a supply chain platform composed of buyers who operate the above-mentioned buyer terminals 200 and suppliers who operate the supplier terminals 250. Hereinafter, the commercial distribution management support device 100 of this embodiment will be referred to as SCPF (Supply Chain Platform).

[0016] On the other hand, the buyer terminal 200 is a terminal operated by a manufacturer of a certain final product, and is a terminal used by the manufacturer when placing an order for semi-finished products and parts that constitute the final product from a supplier. Specifically, a personal computer, a smartphone, a tablet terminal, etc. can be assumed.

[0017] On the other hand, the supplier terminal 250 is a terminal operated by a supplier who delivers semi-finished products and parts in response to an order from the buyer. The supplier terminal 250 is a terminal used by a supplier's personnel when receiving an order for the semi-finished products and parts from the buyer terminal and taking necessary measures. Specifically, a personal computer, a smartphone, a tablet terminal, etc. can be assumed. <Hardware configuration> The hardware configuration of the SCPF 100 of this embodiment is as shown in Fig. 2. That is, the SCPF 100 comprises a storage device 101, a memory 103, a calculation device 104, and a communication device 105.

[0018] Of these, the storage device 101 is configured with an appropriate non-volatile storage element such as an SSD (Solid State Drive) or a hard disk drive.

[0019] The memory 103 is composed of a volatile storage element such as a RAM.

[0020] The arithmetic unit 104 is a CPU that reads out the program 102 stored in the storage unit 101 into the memory 103 and executes the program, controls the device itself, and performs various types of judgment, calculation, and control processing.

[0021] The communication device 105 is connected to the network 1 to communicate with the buyer terminal 200 and the supplier terminal 201. A network interface card or the like that handles communication processing with terminals 250 and the like is assumed.

[0022] The SCPF 100 may further include an input device that accepts key input or voice input from the user, and an output device such as a display that displays the processed data.

[0023] In addition to the program 102 for implementing the functions required for the commercial flow management support device of this embodiment, at least a token DB 125, a main branch token DB 126, and a wallet DB 127 are stored in the storage device 101. However, details of these databases will be described later.

[0024] 3 shows the hardware configuration of the buyer terminal 200 according to the present embodiment. That is, the buyer terminal 200 includes a storage device 201, a memory 203, a computing device 204, an input device 205, an output device 206, and a communication device 207.

[0025] Of these, the storage device 201 is configured with an appropriate non-volatile storage element such as an SSD (Solid State Drive) or a hard disk drive.

[0026] The memory 203 is composed of a volatile storage element such as a RAM.

[0027] The arithmetic unit 204 is a CPU that reads out the program 202 stored in the storage unit 201 into the memory 203 and executes the program, controls the device itself, and performs various types of judgment, calculation, and control processing.

[0028] The input device 205 is a device such as a keyboard, a mouse, or a microphone that accepts key input or voice input from the user.

[0029] The output device 206 is a device such as a display or a speaker that displays data processed by the arithmetic device 204 .

[0030] The communication device 207 is assumed to be a network interface card or the like that is connected to the network 1 and handles communication processing with the SCPF 100 and the supplier terminal 250, etc.

[0031] In addition to the program 202 for implementing the functions required for the buyer terminal 200 of this embodiment, at least a fund transfer DB 225, a transaction DB 226, a CO2 emission DB 227, a quality DB 228, and a logistics DB 229 are stored in the storage device 201. However, details of these databases will be described later.

[0032] When executing an order process for a supplier (the supplier terminal 250), the buyer terminal 200 issues a mainstream token uniquely linked to the order, and includes at least the identifier of the mainstream token in the order data.

[0033] At this time, the buyer terminal 200 calls the token transfer API for the SCPF 100 to transfer the mainstream token from the purchaser, i.e., the buyer, to the contractor, i.e., the supplier. However, the transfer process is not necessarily limited to using the API, and may be performed by file linkage, for example. Meanwhile, in the SCPF 100, in conjunction with the above-mentioned issuance and transfer, a record of the token registration and transfer will be stored in the token DB 125.

[0034] 4 shows the hardware configuration of the buyer terminal 250 according to the present embodiment. That is, the buyer terminal 250 includes a storage device 251, a memory 253, a computing device 254, an input device 255, an output device 256, and a communication device 257.

[0035] Of these, the storage device 251 is configured with an appropriate non-volatile storage element such as an SSD (Solid State Drive) or a hard disk drive.

[0036] The memory 253 is composed of a volatile storage element such as a RAM.

[0037] The arithmetic unit 254 is a CPU that reads out a program 252 stored in the storage unit 251 into a memory 253 and executes the program, thereby controlling the device itself and carrying out various types of judgment, calculation and control processing.

[0038] The input device 255 is a device such as a keyboard, a mouse, or a microphone that accepts key input or voice input from the user.

[0039] The output device 256 is a device such as a display or a speaker that displays the processed data in the arithmetic device 254 .

[0040] The communication device 257 is assumed to be a network interface card or the like that is connected to the network 1 and handles communication processing with the SCPF 100 and the buyer terminal 200 .

[0041] In addition to a program 252 for implementing functions required for the supplier terminal 250 of this embodiment, at least a fund transfer DB 225, a transaction DB 226, a CO2 emission DB 227, a quality DB 228, and a logistics DB 229 are stored in the storage device 251. However, details of these databases will be described later.

[0042] The supplier terminal 250 reads the identifier for the mainstream token issued by the buyer from the order data received from the buyer terminal 200, and when placing an order with a supplier further downstream in the supply chain from the supplier terminal 250's perspective, includes the identifier in the order data. Similarly to the buyer terminal 200, the supplier terminal 250 also calls the token transfer API to the SCPF 100 each time it performs an order process as an orderer, and transfers the mainstream token. Relocate.

[0043] Furthermore, when there are multiple targets (Nth-order suppliers) for order processing from the supplier terminal 250, the supplier terminal 250 issues an additional tributary token as a new token. When issuing this tributary token, processing such as registration and transfer is also performed in the SCPF 100, and the relationship between the tributary token and the above-mentioned main token is managed in the main tributary token DB 126.

[0044] By performing such an operation, it becomes possible to handle the main token and the tributary token consecutively in the supply chain. Even if a tributary token is added, the identifier of the main token is used as a common key for the subsequent token flows, so that the supplier does not need to be aware of the presence or absence of a tributary, but only needs to be aware of the identifier of the main token. It is also possible to generate further tributary tokens from a tributary token, and in that case, the relationship is also managed in the main tributary token DB 126. <Data structure example> Next, various databases and the like used by the SCPF 100, the buyer terminal 200, and the supplier terminal 250 of this embodiment will be described.

[0045] 5 shows an example of the token DB 125 in this embodiment. As described above, the token DB 125 in this embodiment is a table that stores the registration and transfer history of each of the main and tributary tokens issued by the buyer terminal 200 and the supplier terminal 250.

[0046] This token DB125 is a collection of records that link data such as the token issuer "from" and transfer destination "to" values ​​of the token, and the "step" value of the number of transfers for the token, using, for example, a token ID that uniquely identifies the token as a key.

[0047] 6 shows an example of the configuration of the main tributary token DB 126 in this embodiment. The main tributary token DB 126 in this embodiment is a database that stores information indicating the relationship between the main token issued by the buyer terminal 200 and the tributary token issued by the supplier terminal 250 in response to the main token.

[0048] The main tributary token DB 126 of this embodiment is a collection of records that associate the token ID of a main token, a "step" indicating the number of times a tributary token has been derived from the main token, and the token ID of the tributary token.

[0049] 7 shows an example of the configuration of the wallet DB 127 in this embodiment. The wallet DB 127 in this embodiment is a database that stores information about the owner of each token.

[0050] The wallet DB 127 of this embodiment is a collection of records that associate users such as buyers and suppliers with the token IDs of tokens held by the users.

[0051] Next, a description will be given of the databases held by the buyer terminal 200 and the supplier terminal 250. Fig. 8 is a diagram showing an example of the configuration of the funds transfer DB 225 in this embodiment.

[0052] The fund transfer DB 225 of this embodiment is a database that stores information on fund transfers that occur in transactions involving orders and receipts between buyers and suppliers.

[0053] This funds transfer DB225 is a collection of records in which a funds transfer data ID that uniquely identifies the funds transfer data is used as a key, and values ​​such as "from" which is the source of the funds transfer, "to" which is the destination of the funds transfer, "Amount" which is the amount of the funds transfer, and "Payment date" which is the date of the funds transfer are associated with each other.

[0054] 8 also shows that the funds transfer DB 225 is linked to the corresponding record in the token DB 125 of the SCPF 100 using the "funds transfer data ID" as a key. By managing the token DB 125 in this way so that the token flow is linked to the funds transfer data, the SCPF 100 can track the token flow and understand the associated funds transfer.

[0055] 9 is a diagram showing an example of the configuration of the transaction DB 226 in this embodiment. The transaction DB 226 in this embodiment is a database that stores transaction information associated with orders placed and received by buyers and suppliers.

[0056] This transaction DB226 is a collection of records in which a transaction data ID, which uniquely identifies the transaction data, is used as a key to associate values ​​such as the "from" (the order origin) of the transaction, the "to" (the order destination), the order date, the order amount, the product code of the ordered item, the ordered quantity, and the delivery date.

[0057] In addition, in FIG. 9, it is also shown that such a transaction DB 226 is linked to the corresponding record in the token DB 125 of the SCPF 100 using the “transaction data ID” as a key. In this way, the SCPF 100 manages the token flow in the token DB 125 so as to link it with transaction data, and by tracking the token flow, it becomes possible to grasp the associated transaction details.

[0058] 10 is a diagram showing an example of the configuration of the CO2 emission DB 227 in this embodiment. The CO2 emission DB 227 in this embodiment is a database that stores information on the CO2 emission caused in transactions associated with ordering between buyers and suppliers.

[0059] This CO2 emission DB 227 is a collection of records in which values ​​such as the CO2 emission amount, emission start date, and emission end date are associated with a CO2 emission data ID that uniquely indicates the CO2 emission data as a key.

[0060] 10 also shows that the CO2 emission DB 227 is linked to the corresponding record in the token DB 125 of the SCPF 100 using the "CO2 emission data ID" as a key. In this way, the SCPF 100 manages the token flow to be linked to the CO2 emission data in the token DB 125, and by tracking the token flow, it becomes possible to grasp the associated CO2 emission amount.

[0061] 11 is a diagram showing an example of the configuration of the quality DB 228 in this embodiment. The quality DB 228 in this embodiment is a database that stores quality information of products delivered in transactions associated with orders placed by buyers and suppliers.

[0062] This quality DB 228 is a collection of records in which a quality data ID that uniquely identifies quality data is used as a key, and values ​​such as the quality inspection date, inspected person, inspected item, inspection result, and inspection certificate PDF image are associated with each other.

[0063] 11 also shows that the quality DB 228 is linked to the corresponding record in the token DB 125 of the SCPF 100 using the "quality data ID" as a key. By managing the token DB 125 in this way so that the token flow is linked to the quality data, the SCPF 100 can track the token flow and understand the quality of the deliverables that accompanies it.

[0064] 12 is a diagram showing an example of the configuration of the logistics DB 229 in this embodiment. The logistics DB 229 in this embodiment is a database that stores the logistics history of delivered items in transactions associated with orders placed and received by buyers and suppliers.

[0065] This logistics DB229 is a collection of records in which a logistics data ID that uniquely identifies the logistics data is used as a key, and values ​​such as "from" indicating the sender of the delivery item, "to" indicating the recipient, departure point, destination, and departure date are associated with each other.

[0066] 12 also shows that the quality DB 228 is linked to the corresponding record in the token DB 125 of the SCPF 100 using the "logistics data ID" as a key. By managing the token flow in the token DB 125 in this way so that it is linked to logistics data, the SCPF 100 can track the token flow and therefore understand the logistics status of the delivered goods. <Flow example 1> The actual procedure of the commercial flow management support method in this embodiment will be described below with reference to the drawings. The various operations corresponding to the commercial flow management support method described below are realized by a program that is read into memory or the like and executed by the commercial flow management support device 100. This program is composed of codes for performing the various operations described below.

[0067] Fig. 13 is a diagram showing an example of a flow of a commercial distribution management support method in this embodiment. Fig. 14A is a conceptual diagram showing an example of a processing image in this embodiment, and Fig. 14B is a conceptual diagram showing an example of a token flow in this embodiment.

[0068] Here, the buyer terminal 200 and the supplier terminal 250 issue a main stream token and a tributary token when placing an order, notify the SCPF 100 of their identifiers, and perform the process of transferring the tokens to the supplier.

[0069] In this case, the SCPF 100, for example, acquires information (including token ID: 101) of the mainstream token issued to the ordering supplier Company A for a specific project at the buyer terminal 200 (s1), and registers the ordering supplier Company A indicated by the token in the token DB 125 as the transfer destination of the mainstream token (s2).

[0070] An example of a specific record of such registration is the record "from:Buyer, to:Company A, step:1" for the token ID "101" among the records in the token DB 125 in FIG. 5 (see also FIG. 16).

[0071] In addition, when the above-mentioned supplier Company A places an order with subcontractor Company B, the SCPF 100 acquires information on the mainstream token issued to the order recipient supplier Company B (including token ID: 101) on Company A's supplier terminal 250, and registers the order recipient supplier Company B indicated by the token in the token DB 125 as the transfer destination of the mainstream token (s3).

[0072] An example of a specific record of such registration is the record "from: Company A, to: Company B, step: 2" for the token ID "101" among the records in the token DB 125 in FIG. 5 (see also FIG. 16).

[0073] In addition, if the above-mentioned supplier Company A places an order with another subcontractor, Company C (s4: Yes), the SCPF 100 acquires information on the tributary token issued to the order recipient supplier Company C (including token ID: 102) on Company A's supplier terminal 250 (s5), and registers the order recipient supplier Company C indicated by the token in the token DB 125 as the transfer destination of the tributary token (s6).

[0074] Specific examples of such registered records include the records "from:null, to:Company A, step:0" and "from:Company A, to:Company C, step:1" for token ID "102" in the token DB125 of Figure 5 (see also Figure 16).

[0075] As described above, when a tributary token is issued by branching off from the main token flow at a subcontracting supplier or later, the SCPF 100 receives notification from the supplier terminal 250 and stores information in the main tributary token DB 126 (see Figure 6) regarding the relationship between the source main token and the tributary token that is its branch (s7).

[0076] In addition, if the above-mentioned supplier C places an order with the third-tier subcontractor D (s8: Yes), the SCPF 100 acquires information on the tributary token issued to the ordering supplier D (including token ID: 102) on C's supplier terminal 250, and registers the ordering supplier D indicated by the token in the token DB 125 as the transfer destination of the tributary token.

[0077] An example of a specific record of such registration is the record "from: Company C, to: Company D, step: 2" for token ID "102" among the records in token DB 125 in FIG. 5 (see also FIG. 16).

[0078] In addition, in accordance with the registration of the transfer destination, the SCPF 100 updates the latest information on the holders of the main token and the tributary token in the wallet DB 127. In the above example, as shown in Figure 7, the holders of the main token "101" are Company B, and the holders of the tributary token "102" are Company C (see also Figure 17).

[0079] As described above, if the token flow is the result of tracing the holder of the token, as shown in FIG. 14B, the main token "101" issued by the buyer terminal is transferred to the supplier A, and then transferred to the second-tier supplier B, which is a subcontractor of A. In addition to this single flow of main tokens, when A also places an order with C, A issues a tributary token "102", which is transferred to C. In addition, C transfers the tributary token to D, a third-tier supplier. In other words, the main token "101" eventually reaches B, and the tributary token "102" reaches D.

[0080] Note that instead of the token transfer API, the token transfer may be performed by, for example, file linkage. However, since file linkage is usually a batch process, the token transfer is performed later than the arrival of the order data at the Nth order supplier terminal 250. Therefore, in terms of implementation, it is necessary to be careful that the token may not have been transferred to the Nth order supplier by the time the Nth order supplier terminal 250 calls the token transfer API. <Other similar forms> This is similar to the above example, but explains a form for visualizing commercial flows by linking them with other phenomena such as financial flows. In summary, in the first step, tokens are transferred along the flow of orders to realize supply chain visualization, and in the second step, commercial flows / financial flows are visualized by linking token flow information with transaction (order) data / fund transfer data.

[0081] In this case, the buyer terminal 200 and the supplier terminal 250 call the token transfer API to the SCPF 100 every time they execute an order processing, and transfer the token from the purchaser to the seller. This procedure has already been described above.

[0082] After the token transfer process in the SCPF 100 is completed, the SCPF 100 notifies the supplier terminal 250 of the completion of the token transfer by means of an API, message linkage, etc. Therefore, it is necessary to build a mechanism for each supplier terminal 250 to receive the token transfer completion notification.

[0083] Here, each supplier terminal 250 does not include the token ID of the mainstream token, which is a common key, in the transaction (order) data. The token ID notified from the SCPF 100 to each supplier terminal 250 when the token transfer is completed is the mainstream token ID. Using the mainstream token ID has the advantage that it can be used in conjunction with the above-mentioned method of including the mainstream token ID in the transaction (order) data and sending the data. Note that a tributary token ID may be notified instead of the mainstream token ID, but it cannot be used in conjunction with the above-mentioned method. By adopting such a method, for example, there is no need to change the interface of the existing EDI, making it a useful mechanism in cases where it is difficult to make new changes to the existing system. <Flow example 2> Here, we assume that the first-tier supplier A carries out forecast production, and the buyer and second-tier subcontractors and onwards all carry out made-to-order production (note that forecast production is carried out by second-tier subcontractors and onwards). In addition, the above-mentioned Company A has introduced an inventory management system, and the inventory is managed by the The same products are differentiated by the code and production lot (traceability). (Considering the availability of

[0084] In addition, visualization of the flow of goods and money, including forecast production, is a trigger for the start-up of Company A. This is achieved by connecting the point token flow (1) and the buyer-initiated token flow (2) triggered by the buyer's order in the following way.

[0085] Token flow (1) is created using the processing method described in flow example 1 when Company A places a prospective order. When Company B delivers the goods for the prospective order, Company A performs its own work to complete its own product and registers the stock quantity in its own inventory management system, distinguished by product code and production lot (see Figure 21). At this time, the token ID of the prospective token in token flow (1) ("501" in the example of Figure 18) is also registered.

[0086] The token flow (2) is created in response to an order from the buyer, using the processing method described in flow example 1. Specifically, when an order is placed from the buyer terminal 200 to the supplier terminal 250 of company A, the token ID of the order token ("601" in the example of FIG. 18) is notified, and an API is called to the SCPF 100 to transfer the token having the token ID to company A.

[0087] If the ordered product (e.g., 50 units of A-123 are ordered. The token ID is "601") is a stock production product, the supplier terminal 250 of Company A inquires of the above-mentioned inventory management system whether inventory allocation is possible (i.e., whether the ordered quantity is less than the inventory) (s10).

[0088] As a result, if allocation is possible (s11: Yes), the inventory management system returns the allocated inventory (for example, determining allocation from production lot 10001 using the first-in, first-out method) and the prospective token ID (for example, "501") to Company A's supplier terminal 250 (s12).

[0089] The supplier terminal 250 of company A, which has received the allocation OK result, calls the token flow linking API of the SCPF 100 with the order token ID (601) and the prospect token ID (501) as parameters (s14).

[0090] The SCPF 100 saves the relationship between the two tokens in the prospect token DB (see FIG. 23) (s15). The SCPF 100 confirms from the token DB 125 that the number of steps until Company A possesses the token ID "601" is "1", and records this in the DB.

[0091] In this way, the SCPF 100 manages the prospective token DB separately from the token DB 125 (however, the prospective token DB is not shown). <Calculation of X flow taking into account forecast production> In the case of forecast production, inventory may be allocated from multiple production lots (forecast tokens) for one order. In that case, the CO2 emissions during the manufacturing process (token flow in Figure 24) per order can be calculated by performing the following calculation, as shown in the "Calculation method" in Figure 24 (here, calculation of CO2 emissions is given as an example).

[0092] In this case, the SCPF 100 uses the target mainstream token ID, "611," as a search key to identify all CO2 emission data IDs from the token DB 125 (s20).

[0093] In addition, the SCPF100 performs CO2 emission calculations for all identified CO2 emission data IDs. The CO2 emissions are identified from the emissions DB 227 and totaled (s21).

[0094] Here, the SCPF 100 judges whether the main token has a tributary (s22). If the result of this judgment is that there is no tributary (s22: No), the SCPF 100 transitions the process to s27.

[0095] On the other hand, if the determination result indicates that a tributary exists (s22: Yes), the SCPF 100 uses the target token ID as a search key to identify all tributary token IDs from the tributary token DB 126 (s23).

[0096] Furthermore, the SCPF 100 identifies all CO2 emission data IDs from the token DB 125 using all the target tributary token IDs as a search key (s24).

[0097] Next, the SCPF 100 identifies and sums up the CO2 emission amounts from the CO2 emission DB 227 for all the identified CO2 emission data IDs (s25).

[0098] Here, the SCPF 100 judges whether the main stream token has a tributary (s26). If the result of this judgment is that there is no tributary (s26: No), the SCPF 100 transitions the process to s28. On the other hand, if the result of the judgment is that there is a tributary (s26: Yes), the SCPF 100 returns the process to s22.

[0099] Next, the SCPF 100 judges whether there is a prospective token in the main stream or the tributary token (s27). If the result of this judgment is that there is no prospective token in the main stream or the tributary token (s27: No), the SCPF 100 ends this flow.

[0100] On the other hand, if the result of the above judgment is that there is a prospective token in the main or tributary tokens (s27: Yes), the SCPF100 calculates the CO2 emissions for each production lot (prospective token) for the token ID in question using the same method as described above (s28).

[0101] In addition, the SCPF 100 identifies the ratio between the initial quantity and the allocated quantity of each production lot (projected token) from the transaction DB 226 (or the inventory DB) and the inventory allocation DB, calculates the CO2 emissions of the order token taking into account the ratio (s29), and ends this flow.

[0102] Although the best mode for carrying out the present invention has been specifically described above, the present invention is not limited to this, and various modifications are possible without departing from the spirit and scope of the present invention.

[0103] According to this embodiment, it is possible to flexibly respond to various ordering forms of buyers and suppliers and support visualization of the commercial flow in the supply chain. This makes it possible to achieve the commercial flow visualization desired by buyers, and ultimately to fulfill social responsibilities such as traceability and compliance in the supply chain and stable product supply in the event of a large-scale disaster.

[0104] The description of this specification makes clear at least the following. That is, in the commercial distribution management support device of this embodiment, in the information processing device, when the contractor places a prospective order with the Nth-tier subcontractor, the information processing device executes the above-mentioned processes related to the tributary token, which is a prospective token, and when the Nth-tier subcontractor delivers the product to the contractor for the prospective order, the information processing device associates inventory information of the product manufactured by the contractor with the delivery to the contractor with the prospective token information and stores the information of the prospective token, and at the terminal of the purchaser, information of the order token, which is the main token issued to the contractor for the case after the prospective order, is obtained, and the contractor indicated by the information is managed as a transfer destination of the order token, and the order token is stored. For the product of the project indicated by the command, a determination process is performed as to whether or not inventory can be allocated based on the inventory information, and if the result of the determination is that inventory can be allocated, information on the allocated inventory and the prospect token is notified to the contractor's terminal, and the relationship between the order token and the prospect token is saved.

[0105] This makes it possible to appropriately handle forecast orders, a transaction style unique to supply chains, and to manage and understand the flow of commerce. It also makes it possible to more flexibly handle various types of orders from buyers and suppliers, and to support visualization of the flow of commerce in the supply chain.

[0106] Furthermore, in the commercial flow management support method of this embodiment, the information processing device may hold a token database that manages the contractor as the transfer destination of the mainstream token and each of the Nth-tier subcontractors as the transfer destination of the tributary token, and in the token database, each record indicating the content of the transfer of the mainstream token or the tributary token may be linked to information on the transfer of funds associated with the transfer and managed.

[0107] This makes it possible to manage and understand the flow of funds in the flow of commerce, i.e., the flow of money. Furthermore, it is possible to more flexibly respond to various types of orders from buyers and suppliers, and to support visualization of the flow of commerce in the supply chain.

[0108] Furthermore, in the commercial flow management support method of this embodiment, the information processing device may hold a token database that manages the contractor as the transfer destination of the mainstream token and each of the Nth-tier subcontractors as the transfer destination of the tributary token, and in the token database, each record indicating the content of the transfer of the mainstream token or the tributary token may be linked to information on the transaction content of the transaction accompanying the transfer and managed.

[0109] This makes it possible to manage and understand the transaction details in the supply chain, and also to flexibly accommodate various ordering styles between buyers and suppliers, thereby making it possible to support visualization of the supply chain.

[0110] Furthermore, in the commercial flow management support method of this embodiment, the information processing device may hold a token database that manages the contractor as the transfer destination of the mainstream token and each of the Nth-tier subcontractors as the transfer destination of the tributary token, and in the token database, each record indicating the content of the transfer of the mainstream token or the tributary token may be linked to information on greenhouse gas emissions generated in the transaction accompanying the transfer and managed.

[0111] This makes it possible to manage and understand the flow of greenhouse gas emissions in the supply chain, and also to flexibly accommodate various ordering styles between buyers and suppliers, thereby making it possible to support visualization of the supply chain.

[0112] Furthermore, in the commercial flow management support method of this embodiment, the information processing device may hold a token database that manages the contractor as the transfer destination of the mainstream token and each of the Nth-tier subcontractors as the transfer destination of the tributary token, and in the token database, each record indicating the content of the transfer of the mainstream token or the tributary token may be linked to information on quality data of the deliverables in the transaction accompanying the transfer.

[0113] This makes it possible to manage and grasp the quality of delivered goods in the commercial flow, and also to more flexibly accommodate various ordering styles between buyers and suppliers, thereby supporting visualization of the commercial flow in the supply chain.

[0114] Furthermore, in the commercial distribution management support method of this embodiment, the information processing device may hold a token database that manages the contractor as the transfer destination of the mainstream token and each of the Nth-tier subcontractors as the transfer destination of the tributary token, and in the token database, each record indicating the content of the transfer of the mainstream token or the tributary token may be linked to information on logistics in the transaction accompanying the transfer and managed.

[0115] This makes it possible to manage and understand the distribution of delivered goods in the commercial flow, and also to more flexibly accommodate various ordering styles between buyers and suppliers, thereby making it possible to support visualization of the commercial flow in the supply chain.

[0116] Furthermore, in the commercial distribution management support device of this embodiment, the calculation device executes each of the processes related to the tributary token, which is a prospective token, when the contractor places a prospective order with the Nth-subcontractor, and, in response to the prospective order, when the Nth-subcontractor delivers the product to the contractor, stores inventory information of the product manufactured by the contractor through the delivery in association with information on the prospective token, and at the terminal of the purchaser, acquires information on the order token, which is the mainstream token, issued to the contractor for the project after the prospective order, and manages the contractor indicated by the information as the transfer destination of the order token, and executes a determination process regarding whether or not inventory can be allocated based on the inventory information for the product of the project indicated by the order token, and if the determination results in inventory allocation being possible, notifies the contractor's terminal of the allocated inventory and information on the prospective token, and saves the relationship between the order token and the prospective token.

[0117] Furthermore, in the commercial flow management support device of this embodiment, the calculation device may hold a token database that manages the contractor as the transfer destination of the mainstream token and each of the Nth-tier subcontractors as the transfer destination of the tributary token, and in the token database, each record indicating the content of the transfer of the mainstream token or the tributary token is linked to information on the transfer of funds associated with the transfer.

[0118] Furthermore, in the commercial flow management support device of this embodiment, the calculation device may hold a token database that manages the contractor as the transfer destination of the mainstream token and each of the Nth-tier subcontractors as the transfer destination of the tributary token, and in the token database, each record indicating the content of the transfer of the mainstream token or the tributary token may be linked to information on the transaction content of the transaction accompanying the transfer and managed.

[0119] Furthermore, in the commercial flow management support device of this embodiment, the calculation device may hold a token database that manages the contractor as the transfer destination of the mainstream token and each of the Nth-tier subcontractors as the transfer destination of the tributary token, and in the token database, each record indicating the content of the transfer of the mainstream token or the tributary token may be linked to information on greenhouse gas emissions generated in the transaction accompanying the transfer and managed.

[0120] Furthermore, in the commercial flow management support device of this embodiment, the calculation device may hold a token database that manages the contractor as the transfer destination of the mainstream token and each of the Nth-tier subcontractors as the transfer destination of the tributary token, and in the token database, each record indicating the content of the transfer of the mainstream token or the tributary token may be linked to information on quality data of the deliverables in the transaction accompanying the transfer.

[0121] In addition, in the commercial flow management support device of this embodiment, the calculation device holds a token database that manages the contractor as a transfer destination of the mainstream token and each of the N-th subcontractors as a transfer destination of the tributary token, and in the token database, each record indicating the content of the transfer of the mainstream token or the tributary token contains It may also be that the information on logistics is linked and managed. [Explanation of symbols]

[0122] 1 Network 10. Trade flow management support system 100 SCPF (Commerce Flow Management Support Device) 101 Storage device 102 Programs 103 Memory 104 Arithmetic equipment 105 Communication equipment 125 Token DB 126 Main Branch Token DB 127 Wallet DB 225 Funds Transfer DB 226 Transaction DB 227 CO2 emissions DB 228 Quality DB 229 Logistics DB 200 Buyer terminal 250 Supplier Terminals

Claims

1. An information processing device, A process of acquiring information on the mainstream token issued to each supplier for a specific project on the client's terminal, and managing each supplier indicated by the information as a transfer destination of the mainstream token; A process of acquiring information on a branch token issued by the purchaser or the contractor to an Nth-tier subcontractor for processing the case, and managing each Nth-tier subcontractor indicated by the information as a transfer destination of the branch token; A process of managing information defining a relationship between the tributary token and the mainstream token; When the contractor places a prospective order with the N-th subcontractor, the processing is performed on the tributary token, which is a prospective token; With respect to the prospective order, in association with the delivery from the N-th subcontractor to the contractor, inventory information of the product manufactured by the contractor through the delivery is linked to information on the prospective token and stored; In the terminal of the purchaser, after the prospective order, information on the order token, which is the mainstream token issued to the contractor for the case, is acquired, and the contractor indicated by the information is managed as a transfer destination of the order token; Execute a process of determining whether or not inventory can be allocated based on the inventory information for the product of the job indicated by the order token; If the result of the determination is that inventory can be allocated, information on the allocated inventory and the expected token is notified to the contractor's terminal; storing a relationship between the order token and the prospect token; A method for supporting business flow management.

2. The information processing device, A token database is maintained that manages the contractor as a transfer destination of the mainstream token and each of the N-th subcontractors as a transfer destination of the tributary token, In the token database, each record indicating the content of the transfer of the mainstream token or the tributary token is linked to information on the transfer of funds associated with the transfer, and the record is managed. The method for supporting business flow management according to claim 1 .

3. The information processing device, A token database is maintained that manages the contractor as a transfer destination of the mainstream token and each of the N-th subcontractors as a transfer destination of the tributary token, In the token database, each record indicating the content of the transfer of the mainstream token or the tributary token is associated with information on the transaction content of the transaction associated with the transfer and managed. The method for supporting business flow management according to claim 1 .

4. The information processing device, A token database is maintained that manages the contractor as a transfer destination of the mainstream token and each of the N-th subcontractors as a transfer destination of the tributary token, In the token database, each record indicating the content of the transfer of the mainstream token or the tributary token is linked to information on greenhouse gas emissions generated in the transaction associated with the transfer, and the linked records are managed. The method for supporting business flow management according to claim 1 .

5. The information processing device, A token database is maintained that manages the contractor as a transfer destination of the mainstream token and each of the N-th subcontractors as a transfer destination of the tributary token, In the token database, each record indicating the content of the transfer of the mainstream token or the tributary token is linked to information on quality data of the deliverables in the transaction associated with the transfer, and the records are managed accordingly. The method for supporting business flow management according to claim 1 .

6. The information processing device, A token database is maintained that manages the contractor as a transfer destination of the mainstream token and each of the N-th subcontractors as a transfer destination of the tributary token, In the token database, each record indicating the content of the transfer of the mainstream token or the tributary token is linked to information on logistics in the transaction associated with the transfer and managed. The method for supporting business flow management according to claim 1 .

7. A communication device for communicating with other terminals; a process of acquiring information on a mainstream token issued to each supplier for a specified case on a client's terminal, and managing each supplier indicated by the information as a transfer destination of the mainstream token; a process of acquiring information on a tributary token issued by the client or the contractor to an Nth-tier subcontractor for processing the case, and managing each Nth-tier subcontractor indicated by the information as a transfer destination of the tributary token; a process of managing information defining the relationship between the tributary token and the mainstream token; and, when the contractor places a prospective order with the Nth-tier subcontractor, executing each of the above processes related to the tributary token as a prospective token, and, when the contractor delivers the prospective order from the Nth-tier subcontractor to the contractor, storing inventory information of the product manufactured by the contractor through the delivery in association with the information on the prospective token; a computing device in the terminal of the purchaser that acquires information on the order token, which is the mainstream token issued to the contractor for the case after the prospective order, manages the contractor indicated by the information as a transfer destination of the order token, executes a determination process on whether or not inventory can be allocated for the product of the case indicated by the order token based on the inventory information, and if the result of the determination indicates that inventory can be allocated, notifies the terminal of the contractor of the allocated inventory and information on the prospective token, and saves the relationship between the order token and the prospective token; A commercial flow management support device comprising:

8. The computing device includes: A token database is maintained that manages the contractor as a transfer destination of the mainstream token and each of the N-th subcontractors as a transfer destination of the tributary token, In the token database, each record indicating the content of the transfer of the mainstream token or the tributary token is linked to information on the transfer of funds associated with the transfer, and the record is managed accordingly.

8. The commercial distribution management support device according to claim 7.

9. The computing device includes: A token database is maintained that manages the contractor as a transfer destination of the mainstream token and each of the N-th subcontractors as a transfer destination of the tributary token, In the token database, each record indicating the content of the transfer of the mainstream token or the tributary token is linked to information on the transaction content of the transaction associated with the transfer, and the record is managed.

8. The commercial distribution management support device according to claim 7.

10. The computing device includes: A token database is maintained that manages the contractor as a transfer destination of the mainstream token and each of the N-th subcontractors as a transfer destination of the tributary token, In the token database, each record indicating the content of the transfer of the mainstream token or the tributary token is linked to information on greenhouse gas emissions generated in the transaction associated with the transfer, and the record is managed.

8. The commercial distribution management support device according to claim 7.

11. The computing device includes: A token database is maintained that manages the contractor as a transfer destination of the mainstream token and each of the N-th subcontractors as a transfer destination of the tributary token, In the token database, each record indicating the content of the transfer of the mainstream token or the tributary token is linked to information on quality data of the deliverables in the transaction associated with the transfer, and the records are managed accordingly.

8. The commercial distribution management support device according to claim 7.

12. The computing device includes: A token database is maintained that manages the contractor as a transfer destination of the mainstream token and each of the N-th subcontractors as a transfer destination of the tributary token, In the token database, each record indicating the content of the transfer of the mainstream token or the tributary token is linked to information on logistics in the transaction associated with the transfer, and the records are managed accordingly.

8. The commercial distribution management support device according to claim 7.

Images