JP2023163781A - Business flow management support method and business flow management support apparatus - Google Patents

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

The present invention relates to a commercial distribution management support method and a commercial distribution management support device.

Buyers, who stand at the top of the supply chain, have increasing social responsibility regarding their entire supply chain, including traceability, compliance, and stable product supply in the event of a large-scale disaster. For this reason, the realization of ``visualization of commercial flow'' that allows buyers to know their secondary and subsequent business partners has been a long-standing challenge.
Conventional techniques for managing the flow of such operations and transactions include, for example, methods and devices for managing the progress of transactions using computers, and in particular work schedules involving multiple companies based on transaction information transmitted between companies. A method for managing progress (see Patent Document 1) has been proposed.

This technology acquires transaction information transmitted between companies via a network, develops a schedule containing multiple work processes and expected completion dates for multiple companies based on the transaction information, and When a work performance report is obtained, the actual date is recorded in the schedule, and when the actual date is later than the scheduled completion date, a change date is set in the schedule to correct the scheduled completion date of the subsequent work process according to the number of days delayed. The present invention relates to a method for managing the progress of transactions between companies, which is characterized by recording.

It also relates to the production and distribution of products (particularly clothing product production) that involves multiple companies and has a multi-stage production and distribution structure. An information sharing system (see Patent Document 2) has also been proposed for sharing information related to the Internet.

This technology is used to share information on product production and distribution between different companies via communication lines, with multiple companies involved and a multi-stage production and distribution structure. An information sharing system comprising: a database for storing information related to product production and distribution; a first storage means for storing information related to product production and distribution inputted from a company terminal in the database; The information sharing system is characterized in that it includes a first transmitting means that transmits information stored in the database to the company terminal in response to a request to view the database.

Japanese Patent Application Publication No. 11-31179 Japanese Patent Application Publication No. 2002-32434

In order to visualize the commercial flow, that is, the ordering relationship from the buyer to the Nth-tier supplier, a general idea is to collect ordering information from the buyer to the Nth-tier supplier and string it together.
However, even if such a general method is adopted, there are the following two problems. One problem is that order information for other companies does not include IDs that identify order information for one company, and it is difficult to trace order information and its differentiation.

Another issue is that, as a background specific to the supply chain, if a prospective order is included in the relevant commercial flow, the commercial flow after the supplier occurs without an order being placed from the buyer to the supplier. It becomes even more difficult to piece together information on orders and orders based on information.

SUMMARY OF THE INVENTION Therefore, an object of the present invention is to provide a technology that can flexibly respond to various ordering forms of buyers and suppliers and can support visualization of commercial flow in the supply chain.

In the commercial distribution management support method of the present invention that solves the above-mentioned problems, an information processing device acquires information on mainstream tokens issued to each supplier regarding a predetermined project on an orderer's terminal, and each order indicated by the information The process of managing the previous contractor as the transfer destination of the main token, and the acquisition of information on the tributary token issued by the orderer or contractor to the Nth subcontractor for processing the project, and A process of managing each Nth subcontractor indicated by the information as a transfer destination of the tributary token, and a process of managing information specifying the relationship between the tributary token and the main token. do.
In addition, the commercial distribution management support device of the present invention acquires information on main tokens issued to each supplier regarding a predetermined project at the communication device that communicates with other terminals and the orderer's terminal, and obtains each information indicated by the information. A process of managing the contractor who is the order destination as the transfer destination of the main token, and acquiring information on the tributary token issued by the orderer or the contractor to the Nth subcontractor for processing the project, a computing device that executes a process of managing each Nth subcontractor indicated by the information as a transfer destination of the tributary token, and a process of managing information specifying the relationship between the tributary token and the main token; It is characterized by containing.

According to the present invention, it is possible to flexibly respond to various ordering forms of buyers and suppliers, and to support visualization of commercial flow in the supply chain.

FIG. 1 is a network configuration diagram including a commercial distribution management support device according to the present embodiment. It is a diagram showing an example of the hardware configuration of the commercial distribution management support device of the present embodiment. It is a diagram showing an example of the hardware configuration of a buyer terminal according to the present embodiment. It is a diagram showing an example of the hardware configuration of a supplier terminal according to the present embodiment. It is a figure showing an example of composition of token DB in this embodiment. It is a diagram showing an example of the configuration of a main tributary token DB in this embodiment. It is a figure showing an example of composition of wallet DB in this embodiment. It is a figure showing an example of composition of fund transfer DB in this embodiment. It is a figure showing an example of composition of transaction DB in this embodiment. It is a figure showing an example of composition of CO2 emissions amount DB in this embodiment. It is a figure showing an example of composition of quality DB in this embodiment. It is a diagram showing an example of the configuration of a logistics DB in this embodiment. It is a figure showing an example of a flow of a commercial circulation management support method in this embodiment. FIG. 2 is a conceptual diagram showing an example of a processing image in this embodiment. It is a conceptual diagram showing an example of token flow in this embodiment. FIG. 7 is a conceptual diagram showing another example of a processing image in this embodiment. It is a diagram showing an example of the transition of the token DB in this embodiment. It is a diagram showing an example of the transition of the wallet DB in this embodiment. FIG. 2 is a conceptual diagram showing an example of a processing image in this embodiment. It is a conceptual diagram showing an example of token flow in this embodiment. It is a figure showing an example of a flow of a commercial circulation management support method in this embodiment. It is a diagram showing an example of changes in the inventory database in this embodiment. It is a diagram showing an example of the transition of the token DB in this embodiment. It is a diagram showing an example of the transition of the prospective token DB in this embodiment. FIG. 2 is a diagram illustrating an example of correspondence between token flow and CO2 emissions calculation method in the present embodiment. It is a figure showing an example of a flow of a commercial circulation management support method in this embodiment.

<Network configuration>
Embodiments of the present invention will be described in detail below 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 flow management support device 100 shown in FIG. 1 is a computer that can flexibly respond to various ordering forms of buyers and suppliers and can support visualization of commercial flow in the supply chain.

As shown in FIG. 1, the commercial distribution management support device 100 of this embodiment is communicably connected to a buyer terminal 200, a supplier terminal 250, etc. via a network 1. Therefore, these may be collectively referred to as the commercial distribution management support system 10.

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 buyer terminal 200 described above and suppliers who operate the supplier terminal 250. Hereinafter, the commercial distribution management support device 100 in this embodiment will be referred to as SCPF (Supply Chain Platform).

On the other hand, the buyer terminal 200 is a terminal operated by a manufacturer or the like of a certain final product, and is used by a person in charge of the same when ordering semi-finished products or parts that constitute the final product from a supplier. Specifically, a personal computer, a smartphone, a tablet terminal, etc. can be assumed.

On the other hand, the supplier terminal 250 is a terminal operated by a supplier that accepts orders from the buyers and delivers semi-finished products and parts. The supplier terminal 250 is a terminal used by a person in charge of the supplier to receive an order for the semi-finished product or parts from the buyer terminal and take necessary action. Specifically, a personal computer, a smartphone, a tablet terminal, etc. can be assumed.
<Hardware configuration>
Further, the hardware configuration of the SCPF 100 of this embodiment is shown in FIG. 2 as follows. That is, the SCPF 100 includes a storage device 101, a memory 103, an arithmetic device 104, and a communication device 105.

Among these, the storage device 101 is configured with an appropriate nonvolatile storage element such as an SSD (Solid State Drive) or a hard disk drive.

Furthermore, the memory 103 is composed of a volatile storage element such as a RAM.

Further, the arithmetic device 104 is a CPU that reads the program 102 held in the storage device 101 into the memory 103 and executes it, performs overall control of the device itself, and performs various judgments, calculations, and control processing.

Furthermore, the communication device 105 is assumed to be a network interface card or the like that connects to the network 1 and handles communication processing with the buyer terminal 200, supplier terminal 250, and the like.

Note that the SCPF 100 may further include an input device that accepts key inputs and voice inputs from the user, and an output device such as a display that displays processed data.

In addition, in the storage device 101, in addition to the program 102 for implementing the functions necessary for the commercial distribution 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. . However, details regarding these databases will be described later.

Further, the hardware configuration of the buyer terminal 200 of this embodiment is shown in FIG. 3 as follows. That is, it includes a buyer terminal 200, a storage device 201, a memory 203, a calculation device 204, an input device 205, an output device 206, and a communication device 207.

Among these, the storage device 201 is configured with an appropriate nonvolatile storage element such as an SSD (Solid State Drive) or a hard disk drive.

Furthermore, the memory 203 is composed of a volatile storage element such as a RAM.

Further, the arithmetic device 204 is a CPU that reads out and executes the program 202 held in the storage device 201 into the memory 203, performs overall control of the device itself, and performs various judgments, calculations, and control processing.

The input device 205 is a device such as a keyboard, mouse, or microphone that receives key input and voice input from the user.

Further, the output device 206 is a device such as a display or a speaker that displays processing data in the arithmetic device 204.

Furthermore, the communication device 207 is assumed to be a network interface card or the like that connects to the network 1 and handles communication processing with the SCPF 100, the supplier terminal 250, and the like.

In addition to the program 202 for implementing the functions necessary for the buyer terminal 200 of this embodiment, the storage device 201 includes a funds transfer DB 225, a transaction DB 226, a CO2 emissions DB 227, a quality DB 228, and a logistics DB 229. At least remembered. However, details regarding these databases will be described later.

Note that when the buyer terminal 200 executes order processing for (the supplier terminal 250 of) the supplier, it issues a mainstream token that is uniquely linked to the order, and includes at least its identifier in the order data.

At this time, the buyer terminal 200 calls the token transfer API to the SCPF 100 to transfer the main token from the orderer, ie, the buyer, to the orderer, ie, the supplier. However, the transfer process is not necessarily limited to using an API, and for example, transfer may be performed by file linkage. On the other hand, the SCPF 100 stores token registration and transfer records in the token DB 125 in conjunction with the above-described issuance and transfer.

Further, the hardware configuration of the buyer terminal 250 of this embodiment is shown in FIG. 4 as follows. That is, it includes a buyer terminal 250, a storage device 251, a memory 253, a calculation device 254, an input device 255, an output device 256, and a communication device 257.

Among these, the storage device 251 is composed of an appropriate nonvolatile storage element such as an SSD (Solid State Drive) or a hard disk drive.

Furthermore, the memory 253 is composed of a volatile storage element such as a RAM.

Further, the arithmetic device 254 is a CPU that reads out and executes the program 252 held in the storage device 251 into the memory 253, performs overall control of the device itself, and performs various judgments, calculations, and control processing.

The input device 255 is a device such as a keyboard, mouse, or microphone that receives key input and voice input from the user.

Further, the output device 256 is a device such as a display or a speaker that displays processing data in the arithmetic device 254.

Furthermore, the communication device 257 is assumed to be a network interface card or the like that connects to the network 1 and handles communication processing with the SCPF 100 and the buyer terminal 200.

Furthermore, in the storage device 251, in addition to a program 252 for implementing functions necessary for the supplier terminal 250 of this embodiment, a funds transfer DB 225, a transaction DB 226, a CO2 emissions DB 227, a quality DB 228, and a logistics DB 229 are stored. At least remembered. However, details regarding these databases will be described later.

Note that the supplier terminal 250 reads the identifier related to the main 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 on the supply chain from its own perspective, the supplier terminal 250 uses the identifier in the order data. include. Similarly to the buyer terminal 200, the supplier terminal 250 also calls the token transfer APII to the SCPF 100 and transfers the main token every time it becomes an orderer and executes order processing.

Further, when there are multiple targets (Nth order suppliers) for order processing from the supplier terminal 250, the supplier terminal 250 additionally issues a tributary token as a new token. When issuing this tributary token, processing such as registration and transfer is executed 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.

By carrying out such operations, it will be possible to handle main tokens and tributary tokens consecutively in the supply chain. In addition, even if a tributary token is added, by using the identifier of the main token as a common key for subsequent token flow, the supplier does not have to be aware of the presence or absence of tributaries, but only the identifier of the main token. Just leave it there. Note that it is also possible to generate further tributary tokens from the tributary tokens, 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, the supplier terminal 250, etc. of this embodiment will be explained.

FIG. 5 shows an example of the token DB 125 in this embodiment. As described above, the token DB 125 of 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, supplier terminal 250, and the like.

This token DB 125 stores, for example, the values of the issuer of the token "from", the transfer destination "to", and the number of transfers "step" of the token, using the token ID that uniquely identifies the token as a key. It is a collection of records that link data.

Further, FIG. 6 shows a configuration example of the main tributary token DB 126 in this embodiment. The main tributary token DB 126 of 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.

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 a tributary token. There is.

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

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

Next, the databases held by the buyer terminal 200, supplier terminal 250, etc. will be explained. FIG. 8 is a diagram showing a configuration example of the funds transfer DB 225 in this embodiment.

The funds transfer DB 225 of this embodiment is a database that stores information on funds transfers that occur in transactions associated with orders placed by buyers and suppliers.

This funds transfer DB 225 uses the funds transfer data ID that uniquely indicates the funds transfer data as a key, "from" which is the source of the funds transfer, "to" which is the destination of the funds transfer, and "Amamount" which is the amount of funds transferred. It is a collection of records that are associated with values such as "," and "payment date," which is the date of funds transfer.

Note that FIG. 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. In this way, the SCPF 100 manages the token flow in the token DB 125 so as to link it with the fund transfer data, and by tracking the token flow, it is also possible to understand the accompanying fund transfer.

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

This transaction DB 226 uses the transaction data ID that uniquely indicates the transaction data as a key, and stores the transaction's order source "from", order destination "to", order date, order amount, product code of the ordered product, order It is a collection of records that are associated with values such as quantity and delivery date.

Note that FIG. 9 also shows that the 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 the transaction data, and by tracking the flow of tokens, it is also possible to grasp the details of the accompanying transactions.

FIG. 10 is a diagram showing a configuration example of the CO2 emission amount DB 227 in this embodiment. The CO2 emissions DB 227 of this embodiment is a database that stores information on CO2 emissions generated in transactions associated with orders received and placed by buyers and suppliers.

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

Note that FIG. 10 also shows that the CO2 emissions DB 227 is linked to the corresponding record in the token DB 125 of the SCPF 100 using the "CO2 emissions 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 the CO2 emission data, and by tracking the token flow, it is also possible to understand the accompanying CO2 emissions.

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

This quality DB 228 is a collection of records in which values such as quality inspection date, inspection target person, target item, inspection result, and inspection certificate PDF image are associated with a quality data ID that uniquely indicates quality data as a key. .

Note that FIG. 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. In this way, the SCPF 100 manages the token flow in the token DB 125 so as to link it with the quality data, and by tracking the token flow, it is also possible to grasp the accompanying quality of the delivered product.

FIG. 12 is a diagram showing an example of the configuration of the logistics DB 229 in this embodiment. The logistics DB 229 of this embodiment is a database that stores the logistics history of delivered goods in transactions accompanying orders received and placed by buyers and suppliers.

This logistics DB 229 uses a logistics data ID that uniquely indicates logistics data as a key, and associates values such as "from", which is the sender of the delivered item, "to", which is the destination of the delivery, the place of departure, the destination, and the date of departure. It is a collection of records.

Note that FIG. 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. In this way, the SCPF 100 manages the token flow in the token DB 125 so as to link it with the physical distribution data, thereby tracking the flow of tokens, thereby making it possible to grasp the accompanying physical distribution status of the delivered items.
<Flow example 1>
Hereinafter, the actual procedure of the commercial flow management support method in this embodiment will be explained based on the drawings. Various operations corresponding to the commercial distribution management support method described below are realized by a program that is read into a memory or the like and executed by the commercial distribution management support device 100. This program is composed of codes for performing various operations described below.

FIG. 13 is a diagram showing a flow example of the commercial distribution management support method in this embodiment. Further, 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 token flow in this embodiment.

Here, it is assumed that the buyer terminal 200 and the supplier terminal 250 issue a main token or a tributary token when placing an order, notify the SCPF 100 of the identifier, and process the token transfer to the ordering party.

In this case, the SCPF 100, for example, acquires information (including token ID: 101) on the main token issued to company A, the supplier, regarding a predetermined project at the buyer terminal 200 (s1), and determines whether the token is The supplier company A, which is the order destination, is registered in the token DB 125 as the transfer destination of the main token (s2).

As a specific example of such a registration record, among the records in the token DB 125 in FIG. 5, the record "from: Buyer, to: Company A, step: 1" related to token ID "101" corresponds ( (See also 16).

In addition, when the above-mentioned supplier Company A places an order to the secondary contractor Company B, the SCPF 100 uses the supplier terminal 250 of Company A to send the information ( (including token ID: 101), and registers company B, the supplier indicated by the token, as the transfer destination of the main token in the token DB 125 (s3).

As a specific example of such a registration record, among the records in the token DB 125 in FIG. 5, the record "from: Company A, to: Company B, step: 2" regarding token ID "101" corresponds to ( (See also Figure 16).

In addition, when the above-mentioned supplier Company A places an order to another subcontractor Company C (s4: Yes), the SCPF 100 sends an order to the supplier Company C, which is the order destination, on the supplier terminal 250 of Company A. Obtain information on the issued tributary token (including token ID: 102) (s5), and register company C, the supplier indicated by the token, as the transfer destination of the tributary token in the token DB 125 (s6) .

Examples of specific records of such registration include, among the records in the token DB 125 in FIG. 5, a record of "from: null, to: Company A, step: 0" related to token ID "102" and a record of "from: The record "Company A, to: Company C, step: 1" corresponds to the record (see also FIG. 16).

As mentioned above, when a tributary token is issued by a sub-contractor supplier or later, branching off from the main flow of tokens, the SCPF 100 receives a notification from the supplier terminal 250 and issues the main flow of the main token. Information regarding the relationship between the branch token and the branch token is stored in the main branch token DB 126 (see FIG. 6) (s7).

In addition, when the above-mentioned supplier Company C places an order to the tertiary contractor Company D (s8: Yes), the SCPF 100 is issued to the supplier Company D, which is the order destination, at the supplier terminal 250 of Company C. Information on the tributary token (including token ID: 102) is acquired, and company D, the supplier indicated by the token, is registered in the token DB 125 as the transfer destination of the tributary token.

As a specific example of such a registration record, among the records in the token DB 125 in FIG. 5, the record "from: Company C, to: Company D, step: 2" regarding token ID "102" corresponds to ( (See also Figure 16).

In addition, the SCPF 100 shall update the latest information on the holders of the main token and the tributary token in the wallet DB 127 along with the above-mentioned transfer destination registration. In the above example, as illustrated in FIG. 7, the main token "101" is handled by company B, and the tributary token "102" is handled by company C (see also FIG. 17).

As mentioned above, if the token holder is traced and the token flow is assumed, as shown in FIG. 14B, the main token "101" issued by the buyer terminal is transferred to company A, which is the supplier, and then The work will be transferred to Company B, which is a subcontractor of Company A. In addition to this flow of main tokens, when Company A also places an order with Company C, Company A issues a tributary token "102", which is transferred to Company C. Additionally, Company C transfers the tributary token to Company D, which is a tertiary supplier. In other words, the main token "101" has finally reached Company B, and the tributary token "102" has reached Company D.

Note that instead of using the token transfer API, the token transfer may be performed by linking using files, for example. However, since file linkage is usually a batch process, the token transfer will be performed later than the order data arrives at the Nth 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 supplier by the time the Nth supplier terminal 250 calls the token transfer API.
<Other similar forms>
Although similar to the above example, we will explain a case where commercial flow is visualized by linking it with other events such as money flow. The overview is that the first step is to transition tokens along the order flow to visualize the supply chain, and the second step is to link token flow information with transaction (order) data/fund transfer data to improve commercial efficiency. Realize flow/financial flow visualization.

In this case, each time the buyer terminal 200 and the supplier terminal 250 execute order processing, they call the token transfer API to the SCPF 100 to transfer the token from the orderer to the order receiver. This procedure has already been described above.

After the token transfer processing in the SCPF 100 is completed, the SCPF 100 notifies the supplier terminal 250 of the completion of the token transfer using an API, message linkage, or other means. Therefore, it is necessary for each supplier terminal 250 to construct a mechanism to receive notification of completion of token transfer.

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 upon completion of the token transfer is the main token ID. The use of the mainstream token ID has the advantage that it can be used in combination with the above-mentioned method of including the mainstream token ID in the transaction (order) data and transmitting the data. Note that a tributary token ID may be notified instead of the main token ID, but this cannot be used in combination with the above method. By adopting such a method, for example, there is no need to change the existing EDI interface, and it becomes a useful mechanism in cases where it is difficult to make new changes to the existing system.
<Flow example 2>
Here, we assume a situation in which the primary contractor, supplier A, carries out make-to-stock production, and all buyers and sub-contractors are made-to-order. I do not care). It is assumed that the above-mentioned company A has introduced an inventory management system, and the inventory is differentiated by product code and production lot even if they are the same product (traceability is taken into account).

In addition, the visualization of commercial flow/financial flow including make-to-stock production can be divided into two types: the token flow originating from Company A, which is triggered by make-to-stock production (1), and the token flow originating from buyers, which is triggered by buyer orders (2). This can be achieved by connecting in the following way.

Token flow (1) is created using the processing method described in flow example 1 at the time when company A places a prospective order. When Company B makes a delivery in response to a prospective order, Company A carries out its own work to complete its own product, and registers the number of items in stock in its own inventory management system, differentiated by product code and manufacturing lot. (See Figure 21). At this time, the token ID ("501" in the example of FIG. 18) of the prospective token in token flow (1) is also registered.

Token flow (2) is created using the processing method described in flow example 1, triggered by an order from a buyer. 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 to the SCPF 100. Call the API to transfer the token with ID to Company A.

If the ordered product (for example, 50 pieces of A-123 ordered. Token ID is "601") is a make-to-order product, Company A's supplier terminal 250 sends the inventory allocation to the above-mentioned inventory management system. It is inquired whether it is possible (that is, the number of orders < inventory) (s10).

As a result, when the reservation is possible (s11: Yes), the inventory management system stores the reserved inventory (for example, determines reservation from production lot 10001 using the first-in, first-out method) and the expected token ID (for example, "501"). ) is returned to the supplier terminal 250 of company A (s12).

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

The SCPF 100 stores the relationship between the two tokens in the prospective token DB (see FIG. 23) (s15). The SCPF 100 confirms from the token DB 125 that the number of steps until Company A owns the token ID "601" is "1" and records it in the DB.

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).
<X-style calculation considering estimated production>
In the case of make-to-stock production, inventory may be allocated from multiple manufacturing lots (prospective tokens) for one order. In that case, by performing the following calculation, it is possible to calculate CO2 emissions in the manufacturing process for each order (token flow in Figure 24) as shown in the "Calculation method" in Figure 24 (here, CO2 emissions (The calculation of quantity is given as an example).

In this case, the SCPF 100 specifies all CO2 emissions data IDs from the token DB 125 using the target mainstream token ID "611" as a search key (s20).

In addition, the SCPF 100 stores CO2 emissions data for all specified CO2 emissions data IDs.
The CO2 emissions are specified from the emissions DB 227 and summed (s21).

Here, the SCPF 100 determines whether the main token has a tributary (s22). As a result of this determination, if there is no tributary (s22: No), the SCPF 100 shifts the process to s27.

On the other hand, as a result of the determination, if a tributary exists (s22: Yes), the SCPF 100 identifies all tributary token IDs from the main tributary token DB 126 using the target token ID as a search key (s23).

Further, the SCPF 100 specifies all CO2 emissions data IDs from the token DB 125 using all target tributary token IDs as search keys (s24).

Subsequently, the SCPF 100 specifies and totals the CO2 emissions from the CO2 emissions DB 227 for all the specified CO2 emissions data IDs (s25).

Here, the SCPF 100 determines whether the main token has a tributary (s26). As a result of this determination, if there is no tributary (s26: No), the SCPF 100 shifts the process to s28. On the other hand, if the result of the determination is that a tributary exists (s26: Yes), the SCPF 100 returns the process to s22.

Subsequently, the SCPF 100 determines whether there is a potential token among the main or tributary tokens (s27). As a result of this determination, if there is no expected token among the main stream or tributary tokens (s27: No), the SCPF 100 ends this flow.

On the other hand, as a result of the above judgment, if there is a prospective token in the main stream or tributary token (s27: Yes), the SCPF 100 calculates the CO2 emissions of each manufacturing lot (prospective token) for the relevant token ID using the same method as above. is calculated (s28).

In addition, the SCPF 100 specifies the ratio between the initial amount and the number of reservations for each manufacturing lot (prospective token) from the transaction DB 226 (or inventory DB) and inventory reservation DB, and calculates the CO2 emissions of the order token by taking the ratio into account. (s29), this flow ends.

Although the best mode for carrying out the present invention has been specifically described above, the present invention is not limited thereto and can be modified in various ways without departing from the gist thereof.

According to this embodiment, it is possible to flexibly respond to various ordering forms of buyers and suppliers, and to support visualization of commercial flow in the supply chain. This makes it possible to achieve the visualization of commercial flows that buyers have desired, and also 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.

The description of this specification clarifies at least the following. That is, in the commercial distribution management support device of the present embodiment, the information processing device executes each of the above-mentioned processes regarding the tributary token, which is a prospective token, when the order recipient places a prospective order with the Nth subcontractor. Then, in response to the prospective order, in conjunction with the delivery from the Nth subcontractor to the contractor, the inventory information of the product manufactured by the contractor through the delivery is linked to the information of the prospective token. After the prospective order is placed, information on the order token, which is the main token issued to the order recipient regarding the item, is acquired on the orderer's terminal, and the order recipient indicated by the information is identified as the order token. For the product of the case indicated by the order token, the product is managed as a transfer destination, and a process is executed to determine whether or not inventory can be allocated based on the inventory information.If the result of the determination is that inventory can be allocated, the allocated inventory and the Information on the prospective token may be notified to the terminal of the order taker, and the relationship between the order token and the prospective token may be saved.

According to this, it is possible to accurately deal with the transaction form unique to the supply chain, such as prospective ordering, and to manage and understand the commercial flow. Furthermore, it becomes possible to more flexibly respond to various ordering forms from buyers and suppliers, and to support visualization of commercial flow in the supply chain.

Further, in the commercial flow management support method of the present embodiment, the information processing device manages a token database that manages the order taker as a transfer destination of the main token and each of the Nth subcontractors as a transfer destination of the tributary token. may be maintained, and in the token database, each record indicating the details of the transfer of the main token or the tributary token may be managed by being associated with information on the transfer of funds associated with the transfer.

According to this, it becomes possible to manage and understand the flow of funds transfer in commercial distribution, that is, the flow of money. Furthermore, it becomes possible to more flexibly respond to various ordering forms from buyers and suppliers, and to support visualization of commercial flow in the supply chain.

Further, in the commercial flow management support method of the present embodiment, the information processing device manages a token database that manages the order taker as a transfer destination of the main token and each of the Nth subcontractors as a transfer destination of the tributary token. In the token database, each record indicating the details of the transfer of the main token or the tributary token may be managed by linking information on the transaction details of the transaction associated with the transfer.

According to this, it is also possible to manage and understand the details of transactions in the commercial flow. Furthermore, it becomes possible to more flexibly respond to various ordering forms from buyers and suppliers, and to support visualization of commercial flow in the supply chain.

Further, in the commercial flow management support method of the present embodiment, the information processing device manages a token database that manages the order taker as a transfer destination of the main token and each of the Nth subcontractors as a transfer destination of the tributary token. In the token database, each record indicating the details of the transfer of the main token or the tributary token may be managed by linking information on greenhouse gas emissions generated by transactions associated with the transfer. .

According to this, it becomes possible to manage and understand the flow of greenhouse gas emissions in commercial distribution. Furthermore, it becomes possible to more flexibly respond to various ordering forms from buyers and suppliers, and to support visualization of commercial flow in the supply chain.

Further, in the commercial flow management support method of the present embodiment, the information processing device manages a token database that manages the order taker as a transfer destination of the main token and each of the Nth subcontractors as a transfer destination of the tributary token. may be maintained, and in the token database, each record indicating the details of the transfer of the main token or the tributary token may be managed by linking information on the quality data of the deliverables in the transaction associated with the transfer. .

According to this, it is also possible to manage and understand the quality of delivered goods in the commercial distribution. Furthermore, it becomes possible to more flexibly respond to various ordering forms from buyers and suppliers, and to support visualization of commercial flow in the supply chain.

Further, in the commercial flow management support method of the present embodiment, the information processing device manages a token database that manages the order taker as a transfer destination of the main token and each of the Nth subcontractors as a transfer destination of the tributary token. may be maintained, and in the token database, each record indicating the details of the transfer of the main token or the tributary token may be managed by linking information on logistics in transactions associated with the transfer.

According to this, it is also possible to manage and understand the logistics of delivered goods in commercial distribution. Furthermore, it becomes possible to more flexibly respond to various ordering forms from buyers and suppliers, and to support visualization of commercial flow in the supply chain.

Furthermore, in the commercial distribution management support device of the present embodiment, the computing device executes each of the processes regarding the tributary token, which is a prospective token, when the order recipient places a prospective order with the Nth subcontractor. , in response to the prospective order, storage of inventory information of products manufactured by the contractor through the delivery from the N-th subcontractor to the contractor in association with the information of the prospective token; Then, on the orderer's terminal, after the prospective order is placed, information on the order token, which is the main token issued to the orderer regarding the item, is obtained, and the orderer indicated by the information is transferred to the order token. For the product of the case indicated by the order token, a process is performed to determine 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, the allocated inventory and the forecast are The token information may be notified to the order taker's terminal, and the relationship between the order acceptance token and the prospective token may be saved.

Further, in the commercial distribution management support device of the present embodiment, the computing device has a token database that manages the order taker as the transfer destination of the main token and each of the Nth subcontractors as the transfer destination of the tributary token. In the token database, each record indicating the details of the transfer of the main token or the tributary token may be managed by linking information on the transfer of funds associated with the transfer.

Further, in the commercial distribution management support device of the present embodiment, the computing device has a token database that manages the order taker as the transfer destination of the main token and each of the Nth subcontractors as the transfer destination of the tributary token. In the token database, each record indicating the details of the transfer of the main token or the tributary token may be managed by linking information on the transaction details of the transaction associated with the transfer.

Further, in the commercial distribution management support device of the present embodiment, the computing device has a token database that manages the order taker as the transfer destination of the main token and each of the Nth subcontractors as the transfer destination of the tributary token. In the token database, each record indicating the details of the transfer of the main token or the tributary token is managed by linking information on greenhouse gas emissions generated by transactions associated with the transfer. Good too.

Further, in the commercial distribution management support device of the present embodiment, the computing device has a token database that manages the order taker as the transfer destination of the main token and each of the Nth subcontractors as the transfer destination of the tributary token. In the token database, each record indicating the details of the transfer of the main token or the tributary token is managed by linking information on the quality data of the deliverables in the transaction associated with the transfer. Good too.

Further, in the commercial distribution management support device of the present embodiment, the computing device has a token database that manages the order taker as the transfer destination of the main token and each of the Nth subcontractors as the transfer destination of the tributary token. In the token database, each record indicating the details of the transfer of the main token or the tributary token may be managed by linking information on logistics in transactions associated with the transfer.

1 Network 10 Commercial distribution management support system 100 SCPF (Commercial distribution management support device)
101 Storage device 102 Program 103 Memory 104 Arithmetic device 105 Communication device 125 Token DB
126 Main tributary 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 terminal

Claims (14)

The information processing device
A process of acquiring information on the main tokens issued to each supplier regarding a predetermined project on the orderer's terminal, and managing each order recipient indicated by the information as the transfer destination of the main token;
Obtain the information of the tributary token issued by the orderer or the contractor to the Nth subcontractor to process the matter, and select each Nth subcontractor indicated by the information as the transfer destination of the tributary token. Processing to manage,
a process for managing information specifying a relationship between the tributary token and the main token;
A commercial distribution management support method characterized by carrying out the following. In the information processing device,
As the order taker makes a prospective order to the Nth subcontractor, executing each of the processes regarding the tributary token, which is a prospective token;
In response to the prospective order, when the N-th subcontractor makes a delivery to the ordering party, the inventory information of the product manufactured by the ordering party as a result of the delivery is stored in association with the information of the prospective token. ,
On the terminal of the orderer, after the prospective order is placed, information on the order token, which is the main token issued to the orderer regarding the item, is obtained, and the orderer indicated by the information is the transfer destination of the order token. manage,
Executing a determination process as to whether or not inventory can be allocated based on the inventory information for the product of the item indicated by the order token;
As a result of the determination, if the inventory can be allocated, the information on the allocated inventory and the prospective token is notified to the order taker's terminal;
storing the relationship between the order token and the prospective token;
2. The commercial distribution management support method according to claim 1. The information processing device
maintains a token database that manages the contractor as a transfer destination of the main token and each of the Nth subcontractors as a transfer destination of the tributary token;
In the token database, each record indicating the details of the transfer of the main token or the tributary token is managed by linking information on the transfer of funds associated with the transfer;
2. The commercial distribution management support method according to claim 1. The information processing device
maintains a token database that manages the contractor as a transfer destination of the main token and each of the Nth subcontractors as a transfer destination of the tributary token;
In the token database, each record indicating the content of the transfer of the main token or the tributary token is managed by linking information on the transaction content of the transaction associated with the transfer;
2. The commercial distribution management support method according to claim 1. The information processing device
maintains a token database that manages the contractor as a transfer destination of the main token and each of the Nth subcontractors as a transfer destination of the tributary token;
In the token database, each record indicating the content of the transfer of the main token or the tributary token is managed by linking information on greenhouse gas emissions generated by transactions associated with the transfer;
2. The commercial distribution management support method according to claim 1. The information processing device
maintains a token database that manages the contractor as a transfer destination of the main token and each of the Nth subcontractors as a transfer destination of the tributary token;
In the token database, each record indicating the details of the transfer of the main token or the tributary token is managed by linking information on quality data of products delivered in transactions associated with the transfer;
2. The commercial distribution management support method according to claim 1. The information processing device
maintains a token database that manages the contractor as a transfer destination of the main token and each of the Nth subcontractors as a transfer destination of the tributary token;
In the token database, each record indicating the details of the transfer of the main token or the tributary token is managed by linking information on logistics in transactions associated with the transfer;
2. The commercial distribution management support method according to claim 1. A communication device that communicates with other terminals,
A process of acquiring information on the main token issued to each supplier for a predetermined project on the orderer's terminal, and managing each orderee indicated by the information as the transfer destination of the main token, and the orderer. Or a process of acquiring information on tributary tokens issued by the contractor to the Nth subcontractors for processing the project, and managing each Nth subcontractor indicated by the information as the transfer destination of the tributary tokens. and a computing device that executes processing for managing information that defines the relationship between the tributary token and the main token;
A commercial distribution management support device comprising: The arithmetic device is
As the order taker makes a prospective order to the Nth subcontractor, executing each of the processes regarding the tributary token, which is a prospective token;
In response to the prospective order, when the N-th subcontractor makes a delivery to the ordering party, the inventory information of the product manufactured by the ordering party as a result of the delivery is stored in association with the information of the prospective token. ,
On the terminal of the orderer, after the prospective order is placed, information on the order token, which is the main token issued to the orderer regarding the item, is obtained, and the orderer indicated by the information is the transfer destination of the order token. manage,
Executing a determination process as to whether or not inventory can be allocated based on the inventory information for the product of the item indicated by the order token;
As a result of the determination, if the inventory can be allocated, the information on the allocated inventory and the prospective token is notified to the order taker's terminal;
storing the relationship between the order token and the prospective token;
9. The commercial distribution management support device according to claim 8. The arithmetic device is
maintains a token database that manages the contractor as a transfer destination of the main token and each of the Nth subcontractors as a transfer destination of the tributary token;
In the token database, each record indicating the details of the transfer of the main token or the tributary token is managed by linking information on the transfer of funds associated with the transfer;
9. The commercial distribution management support device according to claim 8. The arithmetic device is
maintains a token database that manages the contractor as a transfer destination of the main token and each of the Nth subcontractors as a transfer destination of the tributary token;
In the token database, each record indicating the content of the transfer of the main token or the tributary token is managed by linking information on the transaction content of the transaction associated with the transfer;
9. The commercial distribution management support device according to claim 8. The arithmetic device is
maintains a token database that manages the contractor as a transfer destination of the main token and each of the Nth subcontractors as a transfer destination of the tributary token;
In the token database, each record indicating the details of the transfer of the main token or the tributary token is managed by linking information on greenhouse gas emissions generated by transactions associated with the transfer;
9. The commercial distribution management support device according to claim 8. The arithmetic device is
maintains a token database that manages the contractor as a transfer destination of the main token and each of the Nth subcontractors as a transfer destination of the tributary token;
In the token database, each record indicating the details of the transfer of the main token or the tributary token is managed by linking information on quality data of products delivered in transactions associated with the transfer;
9. The commercial distribution management support device according to claim 8. The arithmetic device is
maintains a token database that manages the contractor as a transfer destination of the main token and each of the Nth subcontractors as a transfer destination of the tributary token;
In the token database, each record indicating the details of the transfer of the main token or the tributary token is managed by linking information on logistics in transactions associated with the transfer;
9. The commercial distribution management support device according to claim 8.

Images