Blockchain-based inventory maintenance method and device

Abstract

The specification discloses a blockchain-based warehouse order maintenance method and device, which are applied to a blockchain system. The method includes: receiving an outbound order query request initiated by an incoming warehouse party, wherein the outbound order query request includes an incoming warehouse party identifier; in response to the outbound order query request, calling the outbound order query logic defined in the smart contract, querying the outbound order authorized to the incoming warehouse party based on the incoming warehouse party identifier, and returning the queried outbound order to the incoming warehouse party; receiving an incoming order storage request initiated by the incoming warehouse party, wherein the incoming order storage request includes a first incoming warehouse order submitted by the incoming warehouse party for the first outbound order; in response to the incoming order storage request, calling the incoming order storage logic defined in the smart contract to store the first incoming warehouse order.

Description

Technical Field

[0001] This specification relates to the field of blockchain technology, and in particular to a blockchain-based inventory list maintenance method and device. Background Art

[0002] From the factory to the sale, goods often go through multiple companies, and go through the warehousing and in-warehouse processes in different companies. Companies usually use warehouse orders to manage the flow of goods. For example, upstream companies carry out warehouse operations for goods and record warehouse outbound orders, and downstream companies carry out warehouse operations for goods and record warehouse inbound orders. How to maintain warehouse orders during the entire flow of goods has become an urgent problem to be solved. Summary of the invention

[0003] In view of this, this specification provides a blockchain-based inventory list maintenance method and device.

[0004] Specifically, this specification is implemented through the following technical solutions:

[0005] A blockchain-based inventory list maintenance method, applied to a blockchain system, includes:

[0006] Receive an outbound order query request initiated by an incoming warehouse party, wherein the outbound order query request includes an incoming warehouse party identifier;

[0007] In response to the outbound order query request, the outbound order query logic defined in the smart contract is called to query the outbound order authorized to the inbound party based on the inbound party identifier, and the queried outbound order is returned to the inbound party;

[0008] receiving a storage request for an incoming order initiated by the incoming party, wherein the storage request for an incoming order includes a first incoming order submitted by the incoming party for a first outgoing order;

[0009] In response to the storage request for the incoming order, the incoming order storage logic defined in the smart contract is called to store the first incoming order.

[0010] Optionally, also include:

[0011] After storing the first incoming order, a receipt reminder is sent to the outgoing party that submitted the first outgoing order.

[0012] Optionally, also include:

[0013] The incoming order storage logic is also used to verify whether the quantity of first incoming objects specified in the first incoming order is less than or equal to the quantity of first outgoing objects specified in the first outgoing order before storing the first incoming order, and to store the first incoming order if the quantity of the first incoming objects is less than or equal to the quantity of the first outgoing objects.

[0014] Optionally, also include:

[0015] Receive a request for querying an incoming order initiated by a warehouse-exporting party, wherein the request for querying the incoming order includes an identifier of the warehouse-exporting party;

[0016] In response to the incoming order query request, the incoming order query logic defined in the smart contract is called to query the incoming order of the outgoing party based on the outgoing party identifier, and the queried incoming order is returned to the outgoing party;

[0017] receiving a storage request for an outbound order initiated by the outbound party, wherein the storage request for an outbound order includes a second outbound order submitted by the outbound party for a second inbound order, wherein the outbound order specifies an authorized downstream inbound party;

[0018] In response to the outbound delivery order storage request, the outbound delivery order storage logic defined in the smart contract is called to store the second outbound delivery order.

[0019] Optionally, the outbound order storage logic is also used to obtain the remaining number of incoming objects corresponding to the second incoming order before storing the second outbound order, verify whether the number of second outbound objects specified in the second outbound order is less than or equal to the remaining number of incoming objects, and store the second outbound order if the number of second outbound objects is less than or equal to the remaining number of incoming objects.

[0020] Optionally, when there are multiple second incoming orders, the outgoing order storage logic is also used to calculate the total number of incoming objects corresponding to multiple second incoming orders before storing the second outgoing order, verify whether the number of second outgoing objects specified in the second outgoing order is less than or equal to the total number of incoming objects, and store the second outgoing order when the number of the second outgoing objects is less than or equal to the total number of incoming objects.

[0021] Optionally, the outbound order query logic queries the outbound order authorized to the inbound party based on the inbound party identifier, including:

[0022] Based on the warehouse entry party identification, query the pending outbound orders authorized to the warehouse entry party;

[0023] The storage logic of the incoming order is also used to update the status of the first outgoing order to completed after storing the first incoming order.

[0024] Optionally, the first incoming order records the order identifier of the first outgoing order, and the method further includes:

[0025] In response to a query request for a target incoming order, the upstream order of the target incoming order is traced back based on the upstream order identifier recorded in the target incoming order.

[0026] A blockchain-based inventory list maintenance device, applied to a blockchain system, comprising:

[0027] A first request receiving unit receives an outbound order query request initiated by an incoming party, wherein the outbound order query request includes an incoming party identifier;

[0028] The outbound order query unit, in response to the outbound order query request, calls the outbound order query logic defined in the smart contract, queries the outbound order authorized to the inbound party based on the inbound party identifier, and returns the queried outbound order to the inbound party;

[0029] A second request receiving unit receives an incoming order storage request initiated by the incoming party, wherein the incoming order storage request includes a first incoming order submitted by the incoming party for the first outgoing order;

[0030] The incoming order storage unit, in response to the incoming order storage request, calls the incoming order storage logic defined in the smart contract to store the first incoming order.

[0031] A blockchain-based inventory list maintenance device, comprising:

[0032] processor;

[0033] memory for storing machine-executable instructions;

[0034] Wherein, by reading and executing the machine executable instructions corresponding to the blockchain-based inventory maintenance logic stored in the memory, the processor is prompted to:

[0035] Receive an outbound order query request initiated by an incoming warehouse party, wherein the outbound order query request includes an incoming warehouse party identifier;

[0036] In response to the outbound order query request, the outbound order query logic defined in the smart contract is called to query the outbound order authorized to the inbound party based on the inbound party identifier, and the queried outbound order is returned to the inbound party;

[0037] receiving a storage request for an incoming order initiated by the incoming party, wherein the storage request for an incoming order includes a first incoming order submitted by the incoming party for a first outgoing order;

[0038] In response to the storage request for the incoming order, the incoming order storage logic defined in the smart contract is called to store the first incoming order.

[0039] By adopting the above implementation mode, after receiving the outbound order query request initiated by the warehouse entry party, the blockchain system can call the outbound order query logic defined in the smart contract to query the outbound order authorized to the warehouse entry party. The warehouse entry party can submit the first inbound order based on the first outbound order, and the blockchain system can further call the inbound order storage logic defined in the smart contract to store the first inbound order. On the one hand, the blockchain system is used to realize the storage of warehouse orders, connect the upstream and downstream warehouse orders, and realize the integrated management of warehouse orders during the circulation of goods. On the other hand, the blockchain system provides warehouse order query and storage services with a high degree of credibility and traceable results, thereby effectively ensuring the security and credibility of warehouse order data. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 This is a system architecture diagram of a blockchain-based inventory list maintenance solution shown in an exemplary embodiment of this specification.

[0041] Figure 2 It is a flowchart of a blockchain-based inventory list maintenance method shown in an exemplary embodiment of this specification.

[0042] Figure 3 It is a hardware structure diagram of an electronic device where a blockchain-based inventory list maintenance device is located, as shown in an exemplary embodiment of this specification.

[0043] Figure 4 It is a block diagram of a blockchain-based inventory list maintenance device shown in an exemplary embodiment of this specification. DETAILED DESCRIPTION

[0044] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The implementations described in the following exemplary embodiments do not represent all implementations consistent with this specification. Instead, they are merely examples of devices and methods consistent with some aspects of this specification as detailed in the appended claims.

[0045] The terms used in this specification are for the purpose of describing specific embodiments only and are not intended to limit this specification. The singular forms "a", "the" and "the" used in this specification and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used herein refers to and includes any or all possible combinations of one or more associated listed items.

[0046] It should be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, this information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of this specification, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0047] This manual provides a blockchain-based inventory maintenance solution, which can realize the storage of goods inventory based on the blockchain system, open up the management of inventory, and ensure data security and reliability.

[0048] The above-mentioned warehouse orders may include outbound warehouse orders and inbound warehouse orders.

[0049] The delivery order may be recorded by the delivery party of the goods, and may specify the downstream inbound party authorized to carry out the inbound operation of the goods. For example, the delivery order may include the delivery order identification (delivery order number, etc.), the delivery party identification, the downstream inbound party identification, the goods identification, the goods quantity, the goods price, etc.

[0050] The inbound order may be recorded by the incoming party of the goods, and may specify the upstream outbound order information. For example, the inbound order may include the inbound order identifier (inbound order number, etc.), the inbound party identifier, the upstream outbound order identifier corresponding to the inbound order, the upstream outbound party identifier of the upstream outbound order corresponding to the inbound order, the goods identifier, the goods quantity, the goods price, etc.

[0051] The above-mentioned outbound and inbound parties can be divided based on the way the enterprise operates the goods, representing the role of the enterprise when operating the goods. For example, the outbound party may refer to the enterprise that ships the goods out of the warehouse, and the inbound party may refer to the enterprise that receives the goods in the warehouse. It is understandable that the same enterprise may be both the outbound party and the inbound party.

[0052] Figure 1 This is a system architecture diagram of a blockchain-based inventory list maintenance solution shown in an exemplary embodiment of this specification.

[0053] Please refer to Figure 1 The system used by the blockchain-based inventory maintenance solution may include an outbound client, an inbound client, and a blockchain system.

[0054] Among them, the above-mentioned shipper client can be an APP, mini program, etc., which can provide the shipper with service entrances such as uploading the shipper's delivery order, and the shipper can upload the delivery order through the service entrance.

[0055] The above-mentioned warehousing party client can also be an APP, mini program, etc., which can provide the warehousing party with service entrances such as uploading of warehousing orders, and the warehousing party can upload the warehousing order through the service entrance.

[0056] Considering that the same enterprise may be involved in both outbound and inbound operations, the outbound client and the inbound client may be the same client, which may provide services such as outbound order upload and inbound order upload at the same time.

[0057] Optionally, the above-mentioned outbound client and the above-mentioned inbound client may also be different clients, for example, corresponding clients may be customized and developed for the outbound party and the inbound party based on roles, etc. This specification does not impose any special restrictions on this.

[0058] The above blockchain system can be used to provide evidence storage services for outbound orders and inbound orders. The above blockchain system can also pre-create smart contracts, which can be used to realize inventory order query, inventory order evidence storage, etc.

[0059] Among them, smart contracts are contracts that can be triggered and executed by transactions on the blockchain. Smart contracts can be defined in the form of code. The deployment method can refer to related technologies, and this manual will not go into details here.

[0060] Optionally, the above-mentioned blockchain system may include a management platform and a blockchain network. The above-mentioned smart contract can be created in the blockchain network. The above-mentioned management platform can be built based on the blockchain network, can monitor contract events, and provide services such as warehousing reminders to the outbound party.

[0061] Figure 2 It is a flowchart of a blockchain-based inventory list maintenance method shown in an exemplary embodiment of this specification.

[0062] Please refer to Figure 2 The blockchain-based inventory list maintenance method can be applied to Figure 1 The blockchain system shown may include the following steps:

[0063] Step 202: receiving a request for querying the outbound order initiated by the incoming party, wherein the request for querying the outbound order includes an identification of the incoming party.

[0064] In this specification, after receiving the goods from the upstream shipping party, the incoming party can perform the warehousing operation, such as putting the goods into the warehouse, and can record the relevant information of the goods in the warehousing order and upload it to the blockchain system for evidence storage.

[0065] When the incoming party uploads the inbound order, it can first send an outbound order query request to the blockchain system based on the incoming party's client. The blockchain system will query the outbound orders issued by each upstream outbound party to itself, and then record and upload the incoming order based on the outbound order.

[0066] The outbound order query request may include the inbound party identification, such as the inbound party's unique ID, the inbound party's name, etc.

[0067] In actual implementation, the warehousing party can select the warehousing button in the warehousing party's client, and the client can then send an outbound order query request to the blockchain system.

[0068] Step 204, in response to the outbound order query request, the outbound order query logic defined in the smart contract is called, the outbound order authorized to the incoming party is queried based on the incoming party identifier, and the queried outbound order is returned to the incoming party.

[0069] Based on the aforementioned step 202, after receiving the outbound order query request, the blockchain system can call the smart contract to query the outbound orders issued to the inbound party.

[0070] For example, the blockchain system can query the outbound delivery order authorized to the incoming warehouse party in the stored outbound delivery order based on the incoming warehouse party's identification, that is, query the outbound delivery order of the goods sent to the incoming warehouse party.

[0071] Step 206: receiving an incoming order storage request initiated by the incoming party, wherein the incoming order storage request includes a first incoming order submitted by the incoming party for the first outgoing order.

[0072] Based on the aforementioned step 204, after receiving the outbound order returned by the blockchain system, the client of the warehouse-entering party can display the outbound order list, and the warehouse-entering party can select the corresponding outbound order (e.g., the first outbound order) based on the actual goods entering the warehouse, and record the information of the goods entering the warehouse based on the first outbound order, that is, fill in the inbound order. For the sake of distinction, this specification may refer to the inbound order filled in for the first outbound order as the first inbound order, and the first inbound order records the order identifier (e.g., order number) of the first outbound order.

[0073] For example, after the warehouse-entering party selects the first outbound order, they can write the name, quantity and other information of the goods to be entered this time. Optionally, the warehouse-entering party's client can also obtain the name and other information of the goods recorded in the first outbound order from the blockchain system, and then display the name of the goods to the warehouse-entering party, who can select it without having to write it manually, which greatly improves the operation experience of the warehouse-entering party.

[0074] After completing the first entry form, the warehousing party can click the upload button to send the entry form storage request to the blockchain system.

[0075] Step 208: In response to the storage request for the incoming order, the incoming order storage logic defined in the smart contract is called to store the first incoming order.

[0076] Based on the aforementioned step 206, after receiving the storage request for the incoming order, the blockchain system can call the smart contract, and the incoming order storage logic defined in the smart contract can realize the storage of the first incoming order.

[0077] The storage logic of the incoming order can store the first incoming order in the contract account.

[0078] In this specification, after receiving the outbound order query request initiated by the incoming party, the blockchain system can call the outbound order query logic defined in the smart contract to query the outbound order authorized to the incoming party. The incoming party can submit the first incoming order based on the first outbound order. The blockchain system can further call the incoming order storage logic defined in the smart contract to store the first incoming order.

[0079] On the one hand, the blockchain system is used to realize the storage of inventory orders, connect the upstream and downstream inventory orders, and realize the integrated management of inventory orders during the circulation of goods.

[0080] On the other hand, the blockchain system provides inventory query and storage services with a high degree of credibility and traceable results, thus effectively ensuring the security and credibility of inventory data.

[0081] Taking rice as an example, the blockchain-based inventory management solution provided in this manual is used to describe in detail the inventory management of the entire process from the rice being shipped from the production enterprise to the circulation to the supermarket.

[0082] In this specification, it is assumed that rice is shipped from a production enterprise, and its circulation process passes through a local centralized warehouse, a warehouse at a sales location, and finally arrives at a supermarket at a sales location.

[0083] 1. Production Enterprises

[0084] In this manual, after the production enterprise produces the rice, it will send the rice to the local centralized warehouse. For example, the Wuchang rice production enterprise sends the Wuchang rice it produces to the Heilongjiang centralized warehouse.

[0085] The production company can store the rice’s delivery note in the blockchain system.

[0086] For example, a production enterprise can edit the delivery time, batch number, quantity, price and other information of the batch of rice in the delivery client, and can also edit the local centralized warehouse as the downstream receiving party of the rice in the delivery order. The local centralized warehouse is the authorized receiving party of the delivery order.

[0087] After the manufacturing company confirms that the editing is complete, the delivery note can be stored in the blockchain system.

[0088] It is worth noting that the production enterprise is the source enterprise of rice circulation, and the outbound order does not have an upstream inbound order. After the production enterprise confirms that the editing is completed, the outbound client can directly send an outbound order storage request to the blockchain system.

[0089] In response to the request to store the delivery order, the blockchain system can call the delivery order storage logic defined in the smart contract to store the delivery order of the batch of rice, for example, storing the delivery order in the contract account. To facilitate subsequent distinction, the delivery order uploaded by the production enterprise can be called delivery order A.

[0090] When storing, the information in the delivery note A can be stored in plain text or in cipher text, and this manual does not impose any special restrictions on this.

[0091] Ideally, the non-sensitive information in the delivery order A can be stored in plain text, such as the delivery order identification, product name, delivery time, etc. The sensitive information in the delivery order A can be stored in cipher text, such as the product price, etc.

[0092] The encryption operation of sensitive information in the delivery order A can be performed by the delivery party that uploads the delivery order. For example, the delivery party client uses the private key of the manufacturer to encrypt the sensitive information in the delivery order A and then sends it to the blockchain system for storage. Of course, the sensitive information can also be encrypted by the delivery order storage logic, for example, the sensitive information is encrypted using the public key of the downstream inbound party.

[0093] In this specification, the delivery order A uploaded by the manufacturing enterprise stored in the blockchain system includes the identification of the local centralized warehouse located downstream thereof, and the subsequent blockchain system can find the delivery order A based on the identification of the local centralized warehouse.

[0094] In this specification, in order to distinguish whether the goods corresponding to each outbound order have been put into storage, when storing outbound order A, the blockchain system may set the status of outbound order A to pending, indicating that the goods corresponding to outbound order A have not yet been put into storage.

[0095] 2. Local centralized warehouse

[0096] After receiving the rice sent to it, the local centralized warehouse can carry out the warehousing operation and edit the warehousing order to store it in the blockchain system.

[0097] For example, the local centralized warehouse can select the warehousing button in the warehousing party's client, and the warehousing party's client then sends an outbound order query request, which carries the local centralized warehouse identifier.

[0098] After receiving the outbound order query request, the blockchain system can query the outbound orders authorized to the local centralized warehouse stored in the blockchain system, that is, query the outbound orders with the local centralized warehouse logo. The blockchain system can return the queried outbound orders to the incoming client, so that the incoming client can display the queried outbound orders to the local centralized warehouse. Among them, if the outbound order has been marked as pending, the blockchain system can query the outbound orders in the pending state authorized to the local centralized warehouse.

[0099] The local centralized warehouse can select the outbound delivery order corresponding to the batch of rice received from the queried outbound delivery order, and then edit the incoming delivery order for the outbound delivery order.

[0100] For example, the blockchain system finds that there are three pending delivery orders authorized to the local centralized warehouse, namely delivery order A, delivery order P, and delivery order Q. The local centralized warehouse selects delivery order A corresponding to this batch of rice from these three delivery orders, and then edits the incoming order for delivery order A. In this example, the incoming order edited for delivery order A is called incoming order B.

[0101] The warehouse entry order B may carry the order number of the warehouse exit order selected by the local centralized warehouse, and the local centralized warehouse may also edit the warehouse entry time, batch number, quantity, price and other information of the batch of rice. After editing, the warehouse entry client may send a request to store the warehouse entry order to the blockchain system, wherein the warehouse entry order generally includes the warehouse entry party identification, such as the local centralized warehouse identification.

[0102] In response to the storage request for the warehouse entry form, the blockchain system may call the warehouse entry form storage logic defined in the smart contract to store the warehouse entry form B for the batch of rice, for example, also storing the warehouse entry form B in the contract account.

[0103] When storing, the information in the incoming order B can also be stored in plain text, or in cipher text, or in a combination of plain text and cipher text. Please refer to the information storage of the outgoing order A mentioned above.

[0104] Optionally, before storing incoming order B uploaded by the local centralized warehouse, incoming order B may be verified.

[0105] For example, check whether the quantity of incoming objects recorded in incoming order B is less than or equal to the quantity of outgoing objects recorded in the selected outgoing order A.

[0106] In this example, both the incoming and outgoing objects are rice. You can check whether the rice quantity recorded in the incoming order B uploaded by the local centralized warehouse is less than or equal to the rice quantity recorded in the outgoing order A uploaded by the production enterprise.

[0107] Normally, the quantity of rice recorded in the incoming order B should be equal to the quantity of rice recorded in the outgoing order A.

[0108] In some cases, due to problems in the transportation process, the amount of rice actually received by the local centralized warehouse may be less than the amount of rice sent by the manufacturer.

[0109] For example, a production enterprise sends out 10,000 kilograms of rice. However, a traffic accident occurs during transportation, resulting in a loss of 1,000 kilograms of rice. The local centralized warehouse actually receives only 9,000 kilograms of rice. The quantity of rice in the incoming warehouse order B uploaded by the local centralized warehouse, 9,000 kilograms, will be less than the quantity of rice in the outgoing warehouse order A uploaded by the production enterprise, 10,000 kilograms.

[0110] When it is verified that the quantity of rice recorded in the incoming order B uploaded by the local centralized warehouse is less than the quantity of rice recorded in the outgoing order A uploaded by the production enterprise, it can be confirmed that the verification has passed, and then the subsequent storage operation of the incoming order B can be executed.

[0111] When verifying that the quantity of rice recorded in the incoming order B uploaded by the local centralized warehouse is greater than the quantity of rice recorded in the outgoing order A uploaded by the production enterprise, it can be confirmed that the verification has failed, and it is very likely that an error occurred during editing at the local centralized warehouse.

[0112] The verification of the number of the above-mentioned objects entering the warehouse can be performed by the smart contract created in the blockchain system before storing the entry order. For example, it can be performed by the entry order storage logic before storing the entry order B, or it can be performed by other logic defined in the smart contract. Of course, the verification of the number of the above-mentioned objects entering the warehouse can also be performed by the management platform or by the entry client, and this specification does not impose any special restrictions on this.

[0113] In actual implementation, the local centralized warehouse can confirm with the production enterprise first, and after both parties confirm, the local centralized warehouse can upload and store the warehouse entry order B. Of course, the local centralized warehouse can also upload and store the warehouse entry order B first, and the production enterprise confirms after receiving the reminder, and this manual does not impose any special restrictions on this.

[0114] In this specification, after the blockchain system completes the storage operation of the incoming order B uploaded by the local centralized warehouse, it can also update the status of the outgoing order A uploaded by the corresponding production enterprise from pending to completed.

[0115] In this specification, after the blockchain system completes the storage operation of the entry order B uploaded by the local centralized warehouse, it can also send a rice entry reminder to the upstream production company.

[0116] The storage reminder can be sent by the management platform in the blockchain system. For example, the storage logic of the smart contract created in the blockchain network can generate a transaction receipt after executing the storage operation of the storage order B, and the transaction receipt contains an event. The management platform can monitor the event published after the smart contract is called, and then learn the execution result of the contract from the data of the event, and when the execution result is that the storage of the storage order B is completed, send the rice storage reminder to the upstream production enterprise, so that the production enterprise can understand the transportation status of the rice.

[0117] After the local centralized warehouse stores the rice, it needs to carry out outbound operations, send the rice to the warehouse at the sales location, and edit the outbound order and store it in the blockchain system.

[0118] For example, the local centralized warehouse can send an incoming order query request based on the outbound client, and the incoming order query request carries the local centralized warehouse identifier.

[0119] After receiving the incoming order query request, the blockchain system can query the incoming orders that have been received by the local centralized warehouse stored in the blockchain system, and return the queried incoming orders to the outgoing client, so that the outgoing client can display the queried incoming orders to the local centralized warehouse.

[0120] Similarly, the status of the incoming order can also be marked. After receiving the incoming order uploaded by the local centralized warehouse, the blockchain system can set the status of the incoming order to pending. After receiving the incoming order query request sent by the local centralized warehouse, the incoming orders in the pending state of the local centralized warehouse can be queried.

[0121] The local centralized warehouse can select the incoming order corresponding to the current batch of rice shipped out from the queried incoming orders, and then edit the outgoing order (hereinafter referred to as outgoing order C) for the incoming order.

[0122] For example, the blockchain system finds that there are two pending incoming orders in the local centralized warehouse, namely incoming order B and incoming order R. The local centralized warehouse selects incoming order B corresponding to this batch of rice from these two incoming orders, and then edits outgoing order C for incoming order B.

[0123] The outbound order C can carry the order number of the inbound order B selected by the local centralized warehouse, and can also specify the downstream inbound party, such as the sales warehouse. The local centralized warehouse can also edit the outbound time, batch number, quantity, price and other information of the rice shipped out. After editing, the outbound party client can send an outbound order storage request to the blockchain system.

[0124] In response to the delivery order storage request, the blockchain system may call the delivery order storage logic defined in the smart contract to store the delivery order C of this batch of rice shipped out, for example, also storing the delivery order C in the contract account.

[0125] Similarly, after storing the outbound order C, the blockchain system can update the status of the corresponding inbound order B from pending to completed.

[0126] Optionally, before storing the outbound delivery order C uploaded by the local centralized warehouse, the outbound delivery order C may be verified.

[0127] For example, check whether the quantity of outgoing objects recorded in outgoing order C is less than or equal to the quantity of incoming objects recorded in the selected incoming order B.

[0128] In this example, the outbound shipment from the local centralized warehouse is also rice. You can check whether the rice quantity recorded in the outbound shipment order C uploaded by the local centralized warehouse is less than or equal to the rice quantity recorded in the inbound shipment order B.

[0129] Generally speaking, the quantity of rice recorded in the outgoing order A can be equal to the quantity of rice recorded in the incoming order B.

[0130] In some cases, the local centralized warehouse may make multiple outbound shipments for a single shipment of rice. In this way, the quantity of rice recorded in the outbound shipment order C is less than the quantity of rice recorded in the inbound shipment order B.

[0131] In this case, the remaining rice quantity corresponding to the incoming order B can be obtained first, and then the quantity of rice shipped out in this outgoing order C can be checked whether it is less than or equal to the remaining rice quantity. If the quantity of rice shipped out is less than or equal to the remaining rice quantity, it is determined that the verification is passed, and then the storage operation of the outgoing order C is executed.

[0132] Among them, the remaining rice quantity corresponding to the incoming order B can be calculated and stored after each outgoing order is stored, so as to be used for subsequent rice outgoing orders.

[0133] Taking the above example, assuming that the amount of rice stored in the local centralized warehouse is 10,000 kilograms, these 10,000 kilograms of rice are shipped out in two batches to different downstream sales warehouses. For example, 8,000 kilograms need to be shipped out to the Hangzhou warehouse first, and the other 2,000 kilograms need to be shipped out to the Beijing warehouse.

[0134] After uploading the storage request for the outbound delivery order of 8,000 kilograms of rice, the local centralized warehouse can verify whether the quantity of rice shipped to Hangzhou (8,000 kilograms) is less than or equal to the quantity of rice received (10,000 kilograms). If the verification is successful, the outbound delivery order can be stored, and the remaining quantity of rice (2,000 kilograms) can be calculated and stored. At this time, there is no need to update the status of the corresponding incoming order.

[0135] When shipping rice to the Beijing warehouse, after the local centralized warehouse uploads a request to store 2,000 kilograms of rice, it can verify whether the quantity of rice shipped to Beijing, 2,000 kilograms, is less than or equal to the remaining quantity of rice, 2,000 kilograms. If the verification is successful, the shipping order can be stored on the one hand, and the remaining quantity of rice can be calculated and stored as 0 on the other hand, and the status of the corresponding incoming order can be updated from pending to completed.

[0136] The above remaining rice quantity can be stored in association with the corresponding warehouse entry order to facilitate searching.

[0137] In some cases, the local centralized warehouse can also carry out a single outbound shipment of rice that has been stored multiple times. In this way, the quantity of rice recorded in the outbound shipment order C is less than or equal to the total quantity of rice recorded in the multiple inbound shipment orders.

[0138] In this case, the total quantity of rice corresponding to multiple incoming orders can be counted first, and then the quantity of rice shipped out in this outgoing order can be checked whether it is less than or equal to the total quantity of rice. If the quantity of rice shipped out is less than or equal to the total quantity of rice, it is determined that the verification is passed, and then the storage operation of the outgoing order is executed.

[0139] Among them, the total quantity of rice corresponding to multiple incoming orders can be calculated after the outgoing party selects the incoming order.

[0140] For example, suppose two incoming orders are selected when the local centralized warehouse ships out. One incoming order ships 10,000 catties of rice, and the other incoming order ships 3,000 catties of rice. The total amount of rice in these two incoming orders is 13,000 catties. If the amount of rice shipped out in the outbound order is less than or equal to 13,000 catties, it can be determined that the verification has passed, and then the outbound order is stored.

[0141] Among them, when the quantity of rice shipped out of the outbound order is equal to the total quantity of rice, 13,000 catties, the status of the two incoming orders can be updated from pending to done. When the quantity of rice shipped out of the outbound order is less than 13,000 catties, the remaining quantity of rice in the two incoming orders can be recorded for subsequent outbound verification, and the order status does not need to be updated.

[0142] The verification of the number of outbound objects can be performed by the smart contract defined in the blockchain system before storing the outbound order. For example, it can be performed by the outbound order storage logic before storing the outbound order C, or by other logic defined in the smart contract. Of course, the verification of the number of outbound objects can also be performed by the management platform, or by the outbound client, and this specification does not impose any special restrictions on this.

[0143] After receiving the rice from the local centralized warehouse, the warehouse at the sales location can perform the warehousing operation, edit the warehousing order D and store it in the blockchain system, and then ship it out to the supermarket at the sales location, and edit the outbound order E and store it in the blockchain system. After receiving the rice from the warehouse at the sales location, the supermarket at the sales location can perform the warehousing operation, and edit the warehousing order F and store it in the blockchain system. The relevant process can refer to the storage process of the inbound and outbound orders of the local centralized warehouse mentioned above, and this manual will not repeat them one by one here.

[0144]

[0145] Table 1

[0146] In the above example of this specification, each rice transfer party can upload the warehouse order shown in Table 1. Among them, each warehouse order records the order number of the upstream warehouse order. When tracing the circulation process of the goods later, it can be traced back to each upstream warehouse order step by step based on the upstream warehouse order number recorded in the target warehouse order.

[0147] For example, the order number of outbound order A is recorded in incoming order B, the order number of incoming order B is recorded in outbound order C, the order number of outbound order C is recorded in incoming order D, the order number of incoming order D is recorded in outbound order E, and the order number of outbound order E is recorded in incoming order F.

[0148] Before selling rice, the supermarket at the place of sale can generate a QR code for rice for traceability. For example, a rice logo code can be randomly generated, and then a traceability QR code can be generated based on the rice logo code. The supermarket at the place of sale can bind the rice logo code to the warehouse entry F. After purchasing rice, the consumer scans the traceability QR code and can find the corresponding warehouse entry F based on the rice logo code carried in the traceability QR code. Then, the outbound order E can be found based on the order number of the outbound order E recorded in the warehouse entry F, and then the warehouse entry D can be found based on the order number of the warehouse entry D recorded in the outbound order E. The warehouse entry C can also be found based on the order number of the outbound order C recorded in the warehouse entry D, and so on, until the outbound order A is found, so as to understand the entire circulation process of rice from the production enterprise.

[0149] Among them, the binding between the rice identification code and the warehouse entry form F can also be stored in the blockchain system, and this manual does not impose any special restrictions on this.

[0150] From the above description, it can be seen that this manual realizes the storage of warehouse orders based on the blockchain system, connects the upstream and downstream warehouse orders, and realizes the integrated management of warehouse orders during the circulation of goods. At the same time, the blockchain system provides warehouse order query and storage services, which are highly reliable and the results can be traced, thereby effectively ensuring the security and reliability of data.

[0151] Corresponding to the aforementioned embodiment of the blockchain-based inventory list maintenance method, this specification also provides an embodiment of the blockchain-based inventory list maintenance device.

[0152] The embodiments of the blockchain-based inventory list maintenance device in this specification can be applied in electronic devices. The device embodiments can be implemented by software, hardware, or a combination of software and hardware. Taking software implementation as an example, as a device in a logical sense, it is formed by the processor of the electronic device in which it is located reading the corresponding computer program instructions in the non-volatile memory into the memory and running them. From the hardware level, if Figure 3 As shown in the figure, it is a hardware structure diagram of the electronic device where the blockchain-based library list maintenance device is located. Figure 3 In addition to the processor, memory, network interface, and non-volatile memory shown, the electronic device in which the device in the embodiment is located may also include other hardware according to the actual function of the electronic device, which will not be described in detail.

[0153] Figure 4 It is a block diagram of a blockchain-based inventory list maintenance device shown in an exemplary embodiment of this specification.

[0154] Please refer to Figure 4 The blockchain-based inventory list maintenance device 300 can be applied in Figure 3 In the electronic device shown, the electronic device may be a node device in a blockchain system, and the device 300 includes:

[0155] The first request receiving unit 301 receives a request for querying an outbound order initiated by an incoming party, wherein the outbound order query request includes an incoming party identifier;

[0156] The outbound order query unit 302, in response to the outbound order query request, calls the outbound order query logic defined in the smart contract, queries the outbound order authorized to the inbound party based on the inbound party identifier, and returns the queried outbound order to the inbound party;

[0157] The second request receiving unit 303 receives an incoming order storage request initiated by the incoming party, wherein the incoming order storage request includes a first incoming order submitted by the incoming party for the first outgoing order;

[0158] The incoming order storage unit 304, in response to the incoming order storage request, calls the incoming order storage logic defined in the smart contract to store the first incoming order.

[0159] Optionally, after storing the first incoming order, the incoming order storage unit 304 sends an incoming reminder to the shipping party that submitted the first outgoing order.

[0160] Optionally, the incoming order storage logic is also used to verify whether the quantity of first incoming objects specified in the first incoming order is less than or equal to the quantity of first outgoing objects specified in the first outgoing order before storing the first incoming order, and to store the first incoming order if the quantity of the first incoming objects is less than or equal to the quantity of the first outgoing objects.

[0161] Optionally, the device 300 further includes:

[0162] The third request receiving unit 305 receives a request for querying an incoming order initiated by the shipping party, wherein the request for querying the incoming order includes an identifier of the shipping party;

[0163] The incoming order query unit 306, in response to the incoming order query request, calls the incoming order query logic defined in the smart contract, queries the incoming orders that have been received by the outgoing party based on the outgoing party identifier, and returns the queried incoming orders to the outgoing party;

[0164] The fourth request receiving unit 307 receives a storage request for an outbound order initiated by the outbound party, wherein the storage request for an outbound order includes a second outbound order submitted by the outbound party for a second inbound order, wherein the outbound order specifies an authorized downstream inbound party;

[0165] The delivery order storage unit 308, in response to the delivery order storage request, calls the delivery order storage logic defined in the smart contract to store the second delivery order.

[0166] Optionally, the outbound order storage logic is also used to obtain the remaining number of incoming objects corresponding to the second incoming order before storing the second outbound order, verify whether the number of second outbound objects specified in the second outbound order is less than or equal to the remaining number of incoming objects, and store the second outbound order if the number of second outbound objects is less than or equal to the remaining number of incoming objects.

[0167] Optionally, when there are multiple second incoming orders, the outgoing order storage logic is also used to calculate the total number of incoming objects corresponding to multiple second incoming orders before storing the second outgoing order, verify whether the number of second outgoing objects specified in the second outgoing order is less than or equal to the total number of incoming objects, and store the second outgoing order when the number of the second outgoing objects is less than or equal to the total number of incoming objects.

[0168] Optionally, the outbound order query logic queries the outbound order authorized to the inbound party based on the inbound party identifier, including:

[0169] Based on the warehouse entry party identification, query the pending outbound orders authorized to the warehouse entry party;

[0170] The storage logic of the incoming order is also used to update the status of the first outgoing order to completed after storing the first incoming order.

[0171] Optionally, the first incoming order records the order ID of the first outgoing order.

[0172] The upstream query unit 309, in response to a query request for a target incoming order, traces the upstream order of the target incoming order based on the upstream order identifier recorded in the target incoming order.

[0173] The implementation process of the functions and effects of each unit in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0174] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can refer to the partial description of the method embodiments. The device embodiments described above are only schematic, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this specification. Ordinary technicians in this field can understand and implement it without paying creative work.

[0175] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer, which may be in the form of a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email transceiver, a game console, a tablet computer, a wearable device or a combination of any of these devices.

[0176] Corresponding to the embodiment of the aforementioned blockchain-based inventory list maintenance method, this specification also provides a blockchain-based inventory list maintenance device, which includes: a processor and a memory for storing machine-executable instructions. The processor and the memory are usually connected to each other via an internal bus. In other possible implementations, the device may also include an external interface to enable communication with other devices or components.

[0177] In this embodiment, by reading and executing the machine executable instructions corresponding to the blockchain-based inventory maintenance logic stored in the memory, the processor is prompted to:

[0178] Receive an outbound order query request initiated by an incoming warehouse party, wherein the outbound order query request includes an incoming warehouse party identifier;

[0179] In response to the outbound order query request, the outbound order query logic defined in the smart contract is called to query the outbound order authorized to the inbound party based on the inbound party identifier, and the queried outbound order is returned to the inbound party;

[0180] receiving a storage request for an incoming order initiated by the incoming party, wherein the storage request for an incoming order includes a first incoming order submitted by the incoming party for a first outgoing order;

[0181] In response to the storage request for the incoming order, the incoming order storage logic defined in the smart contract is called to store the first incoming order.

[0182] Optionally, also include:

[0183] After storing the first incoming order, a receipt reminder is sent to the outgoing party that submitted the first outgoing order.

[0184] Optionally, also include:

[0185] The incoming order storage logic is also used to verify whether the quantity of first incoming objects specified in the first incoming order is less than or equal to the quantity of first outgoing objects specified in the first outgoing order before storing the first incoming order, and to store the first incoming order if the quantity of the first incoming objects is less than or equal to the quantity of the first outgoing objects.

[0186] Optionally, also include:

[0187] Receive a request for querying an incoming order initiated by a warehouse-exporting party, wherein the request for querying the incoming order includes an identifier of the warehouse-exporting party;

[0188] In response to the incoming order query request, the incoming order query logic defined in the smart contract is called to query the incoming order of the outgoing party based on the outgoing party identifier, and the queried incoming order is returned to the outgoing party;

[0189] receiving a storage request for an outbound order initiated by the outbound party, wherein the storage request for an outbound order includes a second outbound order submitted by the outbound party for a second inbound order, wherein the outbound order specifies an authorized downstream inbound party;

[0190] In response to the outbound delivery order storage request, the outbound delivery order storage logic defined in the smart contract is called to store the second outbound delivery order.

[0191] Optionally, the outbound order storage logic is also used to obtain the remaining number of incoming objects corresponding to the second incoming order before storing the second outbound order, verify whether the number of second outbound objects specified in the second outbound order is less than or equal to the remaining number of incoming objects, and store the second outbound order if the number of second outbound objects is less than or equal to the remaining number of incoming objects.

[0192] Optionally, when there are multiple second incoming orders, the outgoing order storage logic is also used to calculate the total number of incoming objects corresponding to multiple second incoming orders before storing the second outgoing order, verify whether the number of second outgoing objects specified in the second outgoing order is less than or equal to the total number of incoming objects, and store the second outgoing order when the number of the second outgoing objects is less than or equal to the total number of incoming objects.

[0193] Optionally, the outbound order query logic queries the outbound order authorized to the inbound party based on the inbound party identifier, including:

[0194] Based on the warehouse entry party identification, query the pending outbound orders authorized to the warehouse entry party;

[0195] The storage logic of the incoming order is also used to update the status of the first outgoing order to completed after storing the first incoming order.

[0196] Optionally, the first incoming order records the order identifier of the first outgoing order, and the method further includes:

[0197] In response to a query request for a target incoming order, the upstream order of the target incoming order is traced back based on the upstream order identifier recorded in the target incoming order.

[0198] Corresponding to the embodiment of the aforementioned blockchain-based inventory list maintenance method, this specification also provides a computer-readable storage medium, on which a computer program is stored, and when the program is executed by a processor, the following steps are implemented:

[0199] Receive an outbound order query request initiated by an incoming warehouse party, wherein the outbound order query request includes an incoming warehouse party identifier;

[0200] In response to the outbound order query request, the outbound order query logic defined in the smart contract is called to query the outbound order authorized to the inbound party based on the inbound party identifier, and the queried outbound order is returned to the inbound party;

[0201] receiving a storage request for an incoming order initiated by the incoming party, wherein the storage request for an incoming order includes a first incoming order submitted by the incoming party for a first outgoing order;

[0202] In response to the storage request for the incoming order, the incoming order storage logic defined in the smart contract is called to store the first incoming order.

[0203] Optionally, also include:

[0204] After storing the first incoming order, a receipt reminder is sent to the outgoing party that submitted the first outgoing order.

[0205] Optionally, also include:

[0206] The incoming order storage logic is also used to verify whether the quantity of first incoming objects specified in the first incoming order is less than or equal to the quantity of first outgoing objects specified in the first outgoing order before storing the first incoming order, and to store the first incoming order if the quantity of the first incoming objects is less than or equal to the quantity of the first outgoing objects.

[0207] Optionally, also include:

[0208] Receive a request for querying an incoming order initiated by a warehouse-exporting party, wherein the request for querying the incoming order includes an identifier of the warehouse-exporting party;

[0209] In response to the incoming order query request, the incoming order query logic defined in the smart contract is called to query the incoming order of the outgoing party based on the outgoing party identifier, and the queried incoming order is returned to the outgoing party;

[0210] receiving a storage request for an outbound order initiated by the outbound party, wherein the storage request for an outbound order includes a second outbound order submitted by the outbound party for a second inbound order, wherein the outbound order specifies an authorized downstream inbound party;

[0211] In response to the outbound delivery order storage request, the outbound delivery order storage logic defined in the smart contract is called to store the second outbound delivery order.

[0212] Optionally, the outbound order storage logic is also used to obtain the remaining number of incoming objects corresponding to the second incoming order before storing the second outbound order, verify whether the number of second outbound objects specified in the second outbound order is less than or equal to the remaining number of incoming objects, and store the second outbound order if the number of second outbound objects is less than or equal to the remaining number of incoming objects.

[0213] Optionally, when there are multiple second incoming orders, the outgoing order storage logic is also used to calculate the total number of incoming objects corresponding to multiple second incoming orders before storing the second outgoing order, verify whether the number of second outgoing objects specified in the second outgoing order is less than or equal to the total number of incoming objects, and store the second outgoing order when the number of the second outgoing objects is less than or equal to the total number of incoming objects.

[0214] Optionally, the outbound order query logic queries the outbound order authorized to the inbound party based on the inbound party identifier, including:

[0215] Based on the warehouse entry party identification, query the pending outbound orders authorized to the warehouse entry party;

[0216] The storage logic of the incoming order is also used to update the status of the first outgoing order to completed after storing the first incoming order.

[0217] Optionally, the first incoming order records the order identifier of the first outgoing order, and the method further includes:

[0218] In response to a query request for a target incoming order, the upstream order of the target incoming order is traced back based on the upstream order identifier recorded in the target incoming order.

[0219] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0220] The above description is only a preferred embodiment of this specification and is not intended to limit this specification. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this specification should be included in the scope of protection of this specification.

Claims

1. A blockchain-based inventory list maintenance method, applied to a blockchain system, comprising: Receive an outbound order query request initiated by an incoming warehouse party, wherein the outbound order query request includes an incoming warehouse party identifier; In response to the outbound order query request, the outbound order query logic defined in the smart contract is called to query the outbound order authorized to the inbound party based on the inbound party identifier, and the queried outbound order is returned to the inbound party; receiving a storage request for an incoming order initiated by the incoming party, wherein the storage request for an incoming order includes a first incoming order submitted by the incoming party for a first outgoing order; In response to the storage request for the incoming order, the incoming order storage logic defined in the smart contract is called to store the first incoming order, and a receipt reminder is sent to the outbound delivery party that submitted the first outbound delivery order.

2. The method according to claim 1, further comprising: The incoming order storage logic is also used to verify whether the quantity of first incoming objects specified in the first incoming order is less than or equal to the quantity of first outgoing objects specified in the first outgoing order before storing the first incoming order, and to store the first incoming order if the quantity of the first incoming objects is less than or equal to the quantity of the first outgoing objects.

3. The method according to claim 1, further comprising: Receive a request for querying an incoming order initiated by a warehouse-exporting party, wherein the request for querying the incoming order includes an identifier of the warehouse-exporting party; In response to the incoming order query request, the incoming order query logic defined in the smart contract is called to query the incoming order of the outgoing party based on the outgoing party identifier, and the queried incoming order is returned to the outgoing party; receiving a storage request for an outbound order initiated by the outbound party, wherein the storage request for an outbound order includes a second outbound order submitted by the outbound party for a second inbound order, wherein the outbound order specifies an authorized downstream inbound party; In response to the outbound delivery order storage request, the outbound delivery order storage logic defined in the smart contract is called to store the second outbound delivery order.

4. The method according to claim 3, The outbound order storage logic is also used to obtain the remaining number of incoming objects corresponding to the second incoming order before storing the second outbound order, verify whether the second outbound object number specified in the second outbound order is less than or equal to the remaining number of incoming objects, and store the second outbound order if the second outbound object number is less than or equal to the remaining number of incoming objects.

5. The method according to claim 3, In the case where the number of the second incoming orders is multiple, the outgoing order storage logic is also used to calculate the total number of incoming objects corresponding to the multiple second incoming orders before storing the second outgoing order, verify whether the number of second outgoing objects specified in the second outgoing order is less than or equal to the total number of incoming objects, and store the second outgoing order if the number of the second outgoing objects is less than or equal to the total number of incoming objects.

6. According to the method of claim 1, the outbound order query logic queries the outbound order authorized to the inbound party based on the inbound party identifier, including: Based on the warehouse entry party identification, query the pending outbound orders authorized to the warehouse entry party; The storage logic of the incoming order is also used to update the status of the first outgoing order to completed after storing the first incoming order.

7. The method according to claim 1, wherein the first warehouse-in document records the warehouse-in document identifier of the first warehouse-out document, and the method further comprises: In response to a query request for a target incoming order, the upstream order of the target incoming order is traced back based on the upstream order identifier recorded in the target incoming order.

8. A blockchain-based inventory list maintenance device, applied to a blockchain system, comprising: A first request receiving unit receives an outbound order query request initiated by an incoming party, wherein the outbound order query request includes an incoming party identifier; The outbound order query unit, in response to the outbound order query request, calls the outbound order query logic defined in the smart contract, queries the outbound order authorized to the inbound party based on the inbound party identifier, and returns the queried outbound order to the inbound party; A second request receiving unit receives an incoming order storage request initiated by the incoming party, wherein the incoming order storage request includes a first incoming order submitted by the incoming party for the first outgoing order; The incoming order storage unit, in response to the incoming order storage request, calls the incoming order storage logic defined in the smart contract, stores the first incoming order, and sends an incoming reminder to the outbound delivery party that submitted the first outbound delivery order.

9. A blockchain-based inventory list maintenance device, comprising: processor; memory for storing machine-executable instructions; Wherein, by reading and executing the machine executable instructions corresponding to the blockchain-based inventory maintenance logic stored in the memory, the processor is prompted to: Receive an outbound order query request initiated by an incoming warehouse party, wherein the outbound order query request includes an incoming warehouse party identifier; In response to the outbound order query request, the outbound order query logic defined in the smart contract is called to query the outbound order authorized to the inbound party based on the inbound party identifier, and the queried outbound order is returned to the inbound party; receiving a storage request for an incoming order initiated by the incoming party, wherein the storage request for an incoming order includes a first incoming order submitted by the incoming party for a first outgoing order; In response to the storage request for the incoming order, the incoming order storage logic defined in the smart contract is called to store the first incoming order, and a receipt reminder is sent to the outbound delivery party that submitted the first outbound delivery order.

Images