Medical instrument assembling and supplying chain method, system and electronic equipment based on supply and demand coordination and double-mode inventory management and medium

Abstract

The application provides a medical instrument distribution supply chain method, system, electronic device and medium based on supply and demand coordination and double-mode inventory management. The source end shortage object is locked based on the source identification in the replenishment request data, the state attribute of the source end shortage object is updated to enter the exclusive stage; the over-authorization check is performed on the target node set associated with the replenishment request data; when the check is passed, the source end shortage object in the exclusive stage is grouped according to the aggregate code of the target node set, and the bidirectional mapping distribution document containing the flow node is generated; the local detail data is constructed by analyzing the flow node of the bidirectional mapping distribution document, and the remote data object of the external collaborative node is pulled; the feature fingerprint is obtained by splicing the built-in field of the remote data object, and the local detail data is retrieved; when the corresponding remote data object is not detected in the remote full set view formed based on the remote data object and the local detail data exists, the local detail data is deleted to perform incremental update.

Description

Technical Field

[0001] This application relates to the fields of computer software and supply chain management technology, and more specifically, to a medical device distribution supply chain method, system, electronic device and medium based on supply and demand coordination and bimodal inventory management. Background Technology

[0002] With the promotion of the centralized distribution model for medical devices, centralized distribution platforms need to efficiently connect hospitals and upstream suppliers, placing higher demands on the automatic replenishment and circulation of medical devices, batch-level inventory tracking, and dynamic financial reconciliation. Medical device centralized distribution supply chain management needs to balance the accuracy of data synchronization between heterogeneous systems across different domains, the security of inventory adjustments under high-concurrency scenarios, and the ability to track supply and demand across the entire supply chain to ensure the efficient and compliant operation of the medical device supply chain.

[0003] Existing medical device distribution supply chain processing solutions typically employ a centralized, one-way status polling and overwrite storage architecture. A central service gateway centrally acquires inventory and order data from each terminal to generate distribution instructions. This solution first establishes a centralized data synchronization task, collecting current inventory and change parameters from each business node through a periodic polling mechanism. Subsequently, the central server queues and overwrites the returned data, generating local one-way distribution or reconciliation vouchers. Finally, based on these local documents, corresponding confirmation feedback instructions are sent to each terminal system.

[0004] However, this centralized, one-way overlay update scheme has significant technical flaws. Because medical device distribution involves complex supply and demand nodes and massive concurrent orders, centralized status polling is prone to data corruption and status conflicts during multi-source concurrent replenishment, resulting in insufficient exclusivity and authorization compliance in the distribution process. Simultaneously, the one-way queue overlay model lacks bidirectional mapping and fine-grained consistency verification for data flow across heterogeneous systems. It cannot accurately clean up corrupted data when faced with remote data withdrawal or time differences, and the overall overlay-based inventory modification method is highly susceptible to inaccurate inventory balances under high concurrency, making it difficult to meet the requirements for precise supply and demand coordination and high consistency management of dual-modality inventory in medical device distribution. Summary of the Invention

[0005] This application provides a medical device distribution supply chain method, system, electronic device, and medium based on supply and demand coordination and bimodal inventory management, so as to at least alleviate the above-mentioned technical problems.

[0006] A medical device distribution supply chain approach based on supply and demand coordination and bimodal inventory management includes: Based on the source identifier in the replenishment request data, the source-end out-of-stock object is locked. Then, optimistic locking is used to update the status attribute of the source-end out-of-stock object so that it enters the exclusive stage. Here, the source identifier is used to characterize the trigger source type corresponding to the replenishment request data, and the source-end out-of-stock object is used to characterize the data object to be replenished corresponding to the replenishment request data in the local storage pool. An unauthorized access check is performed on the target node set associated with the replenishment request data using a constraint list, wherein the target node set is used to represent the pending delivery node pointed to by the replenishment request data, and the constraint list is used to limit the execution permissions of the nodes corresponding to the target node set; When the verification is successful, the source-end out-of-stock objects in the exclusive stage are grouped according to the aggregation code of the target node set, and a two-way mapping distribution document containing transfer nodes is generated. The aggregation code is used to represent the aggregation relationship between different target nodes in the target node set, and the transfer node is used to represent the sending end node and receiving end node of the source-end out-of-stock object in the two-way mapping distribution document. The local detailed data is constructed by parsing the circulation node of the bidirectional mapping order, and then the remote data object of the external collaborative node is pulled. The local detailed data is used to record the order details of the circulation node in the local system, and the external collaborative node is used to provide the remote data object for collaborative verification with the local detailed data. The feature fingerprint is obtained by concatenating the built-in fields of the remote data object, and the feature fingerprint is used to retrieve the local detailed data. The feature fingerprint is used to establish a consistent retrieval relationship between the remote data object and the local detailed data. If no remote data object corresponding to the local detailed data is detected in the remote full set view formed based on the remote data object, and the local detailed data exists, the local detailed data is deleted, the change value in the discarded record formed by deleting the local detailed data is extracted, and the bimodal inventory data record is incrementally updated based on the change value through the database row locking mechanism. The discarded record is used to record the inventory occupancy change content corresponding to the deletion of the local detailed data, and the bimodal inventory data record is used to simultaneously record the local inventory status and collaborative inventory status in the medical device distribution supply chain.

[0007] Optionally, locking the source-end inventory object based on the source identifier in the replenishment request data, and then using optimistic locking to update the status attributes of the source-end inventory object to make it enter the exclusive phase includes: Extract the numerical attribute carried by the source identifier, wherein the numerical attribute is used to indicate the trigger source type corresponding to the replenishment request data; When the numerical attribute indicates a passively triggered event, a unique tracking code is generated based on the replenishment request data. The passively triggered event is used to characterize a source-end inventory object locking scenario triggered by an external replenishment demand, and the unique tracking code is used to locate the source-end inventory object in the local storage pool. The source of the out-of-stock item is located in the local storage pool using the unique tracking code. The optimistic locking is used to verify the current version number of the source-end overdue object. Then, when the current version number meets the preset inference conditions, the status attribute is modified to prevent other processes from concurrently overwriting the source-end overdue object, thus causing it to enter the exclusive phase. The current version number is used to represent the current data version of the source-end overdue object in the local storage pool, and the preset inference conditions are used to determine whether the current version number allows the status attribute to be updated.

[0008] Optionally, after extracting the numerical attributes carried by the source identifier, the method further includes: When the numerical attribute indicates an active triggering event, the locking operation for the source-end out-of-stock object is bypassed to determine the data object to be allocated. The active triggering event is used to characterize the scenario of generating new reserve records with replenishment requirements actively generated by the local system. A new reserve record is generated based on the replenishment request data, wherein the new reserve record is used to represent the pending delivery data object generated under the active triggering event; The newly added reserve record is bound to the target node set, and the newly added reserve record is used as a pre-input source for generating the bidirectional mapping distribution document, so as to realize the unified convergence of data flow in multi-source triggering scenarios. The pre-input source is used to participate in the generation of the bidirectional mapping distribution document together with the source-end inventory object in the exclusive stage.

[0009] Optionally, performing an over-authority check on the target node set associated with the replenishment request data using the constraint list includes: The target node set is sent to the independent verification node via a remote procedure call protocol, wherein the remote procedure call protocol is used to transmit the target node set between the local system and the independent verification node, and the independent verification node is used to verify the frozen status of the nodes corresponding to the target node set; Receive node freeze status feedback returned by the independent verification node, wherein the node freeze status feedback is used to characterize whether the target node set is in a frozen state; When the node freeze status feedback indicates that it is not frozen, capture the operation credential data in the current session environment, wherein the operation credential data is used to characterize the operation identity and operation permissions of the person who initiated the replenishment request data in the current session environment; The operation voucher data is injected into the constraint list as input to perform local permission probing. When a whitelist record is matched, it is confirmed that the target node set has legitimate execution permissions to isolate unauthorized requests from illegal nodes. The whitelist record belongs to the constraint list, and the legitimate execution permissions are used to indicate that the target node set can participate in the generation of the bidirectional mapping order.

[0010] Optionally, grouping the source-end inventory backlog objects in the exclusive stage according to the aggregation code of the target node set, and generating a bidirectional mapping dispatch document containing transfer nodes includes: The source-end overstock object in the exclusive phase is converted into streaming data containing the aggregate code, wherein the streaming data is used to carry the source-end overstock object and the aggregate code corresponding to the source-end overstock object; The streaming data is aggregated according to the aggregation code to obtain multiple independent data groups, wherein the data groups are used to represent the streaming data sets that have the same or related aggregation codes; The system requests the missing master data attributes of each data group from an external master data source via a remote call protocol. The external master data source is used to provide the master data attributes required for the data group to generate the bidirectional mapping order. The master data attributes are used to fill in the missing node basic attributes and material basic attributes in the data group. The master data attributes are filled into the corresponding data groups, and then the bidirectional mapping order containing mutually mapped sender primary keys and receiver primary keys is constructed to maintain data traceability between heterogeneous systems. The sender primary key is used to identify the sender node in the flow node, and the receiver primary key is used to identify the receiver node in the flow node.

[0011] Optionally, the remote data objects retrieved from external collaboration nodes include: Read the preset system configuration file and extract the list of external collaborative nodes that are in the enabled state. The system configuration file is used to record the enabled state and data open interface address of the external collaborative nodes, and the list of external collaborative nodes is used to limit the external collaborative nodes that need to pull the remote data object. The list of external collaborative nodes is truncated using a preset slicing length to generate multiple data slices with a specified length, wherein the preset slicing length is used to limit the number of external collaborative nodes contained in each data slice; Independent execution threads are allocated to the plurality of data shards with a specified length, wherein the execution threads are used to concurrently access the external cooperating nodes in the corresponding data shards; The execution thread concurrently calls the data access interface of the external collaborative node to receive the remote data object formatted as a key-value pair structure. The data access interface is used to output the remote data object, and the key-value pair structure is used to carry the built-in fields of the remote data object.

[0012] Optionally, a feature fingerprint is obtained by concatenating the built-in fields of the remote data object, and the local detailed data is retrieved using the feature fingerprint, including: Extract the requester field, target field, order number field, suffix field, and line indicator field from the remote data object, wherein the requester field, target field, order number field, suffix field, and line indicator field are collectively used as the built-in fields for generating the feature fingerprint; The requester field, the target field, the order number field, the suffix field, and the line indicator field are concatenated according to a preset sorting rule to generate the feature fingerprint with a unique identifier. The preset sorting rule is used to limit the order of the requester field, the target field, the order number field, the suffix field, and the line indicator field in the string concatenation process. The local cache space is used to perform a lookup operation using the feature fingerprint to locate the local detailed data with consistent characteristics. The local cache space is used to store the local detailed data constructed by the flow nodes of the bidirectional mapping order. The consistent characteristics are used to characterize that the local detailed data and the remote data object have the same feature fingerprint.

[0013] Optionally, when no remote data object corresponding to the local detailed data is detected in the remote full set view formed based on the remote data object, and the local detailed data exists, deleting the local detailed data includes: Based on the remote data objects returned by the external collaborative nodes, a remote full set view is constructed for the remote data objects, wherein the remote full set view is used to summarize the remote data objects returned by different external collaborative nodes; Extract the identity identifier of the local detailed data, and use the identity identifier to perform an existence detection in the remote full set view. The identity identifier is derived from the field combination in the local detailed data that corresponds to the feature fingerprint. The existence detection is used to determine whether there is a remote data object in the remote full set view that corresponds to the local detailed data. When the existence probe returns a no-hit result, a withdrawal trigger instruction is generated for the local detailed data. The no-hit result is used to indicate that there is no remote data object corresponding to the local detailed data in the remote full set view. The withdrawal trigger instruction is used to trigger the deletion process of the local detailed data. In response to the withdrawal trigger command, the occupancy constraint attribute associated with the local detailed data is modified. Subsequently, the local detailed data is physically erased at the database level to clean up the time difference dirty data generated between heterogeneous systems. The occupancy constraint attribute is used to characterize the inventory occupancy relationship between the local detailed data and the bimodal inventory data record, and the time difference dirty data is used to characterize the inconsistent data between the local detailed data and the remote data object caused by the synchronization time difference.

[0014] Optionally, extracting the changed values ​​from the discarded records formed by deleting the local detailed data, and performing incremental updates on the bimodal inventory data records based on the changed values ​​using the database row-level locking mechanism includes: Construct a structured query statement containing independent write instructions and superimposed calculation instructions, wherein the structured query statement is used to complete the retrospective writing of the discarded records and the incremental update of the bimodal inventory data records in the same database execution context; Execute the independent write instruction to write the change value into an independent operation flow table to generate a traceability log. The independent write instruction is used to write the change value in the discarded record into the operation flow table. The operation flow table is used to record the inventory change process caused by the deletion of the local detailed data. The traceability log is used to trace the source of the change value. Executing the overlay calculation instruction triggers the database row locking mechanism to perform an exclusive lock on the bimodal inventory data record. Subsequently, the change value is directly added to the balance field of the bimodal inventory data record in the internal calculation domain of the structured query statement. The overlay calculation instruction is used to update the bimodal inventory data record based on the change value, and the balance field is used to record the inventory balance result in the bimodal inventory data record.

[0015] A medical device distribution supply chain system based on supply and demand coordination and bimodal inventory management, the system comprising: The exclusive phase entry module is used to lock the source-end out-of-stock object based on the source identifier in the replenishment request data, and then use optimistic locking to update the status attribute of the source-end out-of-stock object to make it enter the exclusive phase. The source identifier is used to represent the trigger source type corresponding to the replenishment request data, and the source-end out-of-stock object is used to represent the data object to be replenished corresponding to the replenishment request data in the local storage pool. The unauthorized access verification module is used to perform unauthorized access verification on the target node set associated with the replenishment request data using a constraint list, wherein the target node set is used to represent the pending delivery node pointed to by the replenishment request data, and the constraint list is used to limit the execution permissions of the nodes corresponding to the target node set; The bidirectional mapping order generation module is used to group the source-end overdue goods objects in the exclusive stage according to the aggregation code of the target node set when the verification is passed, and generate a bidirectional mapping order containing transfer nodes. The aggregation code is used to represent the aggregation relationship between different target nodes in the target node set, and the transfer node is used to represent the sending node and receiving node of the source-end overdue goods object in the bidirectional mapping order. The collaborative data retrieval module is used to parse the flow node of the bidirectional mapping order to construct local detailed data, and then retrieve the remote data object of the external collaborative node. The local detailed data is used to record the order details of the flow node in the local system, and the external collaborative node is used to provide the remote data object for collaborative verification with the local detailed data. A consistency retrieval module is used to concatenate the built-in fields of the remote data object to obtain a feature fingerprint, and use the feature fingerprint to retrieve the local detailed data. The feature fingerprint is used to establish a consistency retrieval relationship between the remote data object and the local detailed data. The inventory incremental update module is used to delete the local detailed data when no remote data object corresponding to the local detailed data is detected in the remote full set view formed based on the remote data object, and the local detailed data exists. It then extracts the change value from the discarded record formed by deleting the local detailed data and performs an incremental update on the bimodal inventory data record based on the change value using a database row-locking mechanism. The discarded record records the inventory occupancy change corresponding to the deletion of the local detailed data, and the bimodal inventory data record simultaneously records the local inventory status and collaborative inventory status in the medical device distribution supply chain.

[0016] Optionally, the exclusive phase entry module includes: A numerical attribute extraction unit is used to extract the numerical attributes carried by the source identifier, wherein the numerical attributes are used to indicate the trigger source type corresponding to the replenishment request data; A unique tracking code generation unit is used to generate a unique tracking code based on the replenishment request data when the numerical attribute indicates a passively triggered event, wherein the passively triggered event is used to characterize a source-end inventory object locking scenario triggered by an external replenishment demand, and the unique tracking code is used to locate the source-end inventory object in the local storage pool. A source-end overdue goods object location unit is used to locate the source-end overdue goods object in the local storage pool using the unique tracking code; The status attribute update unit is used to verify the current version number of the source-end overdue object using the optimistic locking. Then, when the current version number meets the preset inference conditions, the status attribute is modified to prevent other processes from concurrently overwriting the source-end overdue object, thus causing it to enter the exclusive phase. The current version number is used to represent the current data version of the source-end overdue object in the local storage pool, and the preset inference conditions are used to determine whether the current version number allows the status attribute to be updated.

[0017] Optionally, the system further includes an active triggering processing module, which includes: The data object to be allocated is determined by bypassing the locking operation on the source-end out-of-stock object when the numerical attribute indicates an active triggering event. The active triggering event is used to characterize the scenario of generating a new reserve record with replenishment demand actively generated by the local system. A new reserve record generation unit is used to generate a new reserve record based on the replenishment request data, wherein the new reserve record is used to represent the pending delivery data object generated under the active triggering event; The pre-input source binding unit is used to bind the newly added reserve record to the target node set, and use the newly added reserve record as the pre-input source for generating the bidirectional mapping distribution document, so as to realize the unified convergence of data flow in multi-source triggering scenarios. The pre-input source is used to participate in the generation of the bidirectional mapping distribution document together with the source-end overdue object in the exclusive stage.

[0018] Optionally, the unauthorized access verification module includes: A target node set sending unit is used to send the target node set to an independent verification node via a remote call protocol, wherein the remote call protocol is used to transmit the target node set between the local system and the independent verification node, and the independent verification node is used to verify the frozen status of the nodes corresponding to the target node set; A node frozen state feedback receiving unit is used to receive node frozen state feedback returned by the independent verification node, wherein the node frozen state feedback is used to characterize whether the target node set is in a frozen state. The operation credential data capture unit is used to capture operation credential data in the current session environment when the node freeze status feedback indicates that it is not frozen. The operation credential data is used to characterize the operation identity and operation permissions of the person who initiated the replenishment request data in the current session environment. The local permission exploration unit is used to inject the operation voucher data as input conditions into the constraint list to perform local permission exploration. When a whitelist record is hit, it confirms that the target node set has legitimate execution permissions to isolate unauthorized requests from illegal nodes. The whitelist record belongs to the constraint list, and the legitimate execution permissions are used to indicate that the target node set can participate in the generation of the bidirectional mapping order.

[0019] Optionally, the two-way mapping order generation module includes: A streaming data conversion unit is used to convert the source-end overstock object in the exclusive stage into streaming data containing the aggregate code, wherein the streaming data is used to carry the source-end overstock object and the aggregate code corresponding to the source-end overstock object; A data grouping generation unit is used to perform aggregation processing on the streaming data according to the aggregation code to obtain multiple independent data groups, wherein the data groups are used to represent the streaming data set having the same or related aggregation codes; The master data attribute request unit is used to request the missing master data attributes of each data group from an external master data source through a remote call protocol. The external master data source is used to provide the master data attributes required for the data group to generate the bidirectional mapping packing document. The master data attributes are used to fill in the missing node basic attributes and material basic attributes in the data group. A bidirectional mapping order construction unit is used to fill the master data attributes into the corresponding data groups, and then construct the bidirectional mapping order containing mutually mapped sender primary keys and receiver primary keys to maintain data traceability between heterogeneous systems. The sender primary key is used to identify the sender node in the flow node, and the receiver primary key is used to identify the receiver node in the flow node.

[0020] Optionally, the collaborative data retrieval module includes: The external collaboration node list extraction unit is used to read a preset system configuration file and extract a list of external collaboration nodes that are in the enabled state. The system configuration file is used to record the enabled state and data open interface address of the external collaboration nodes, and the external collaboration node list is used to limit the external collaboration nodes that need to pull the remote data object. A data sharding generation unit is used to perform sharding and truncation on the list of external collaborative nodes using a preset sharding length to generate multiple data shards with a specified length, wherein the preset sharding length is used to limit the number of external collaborative nodes contained in each data shard; An execution thread allocation unit is used to allocate independent execution threads to the plurality of data shards with a specified length, wherein the execution threads are used to concurrently access the external cooperating nodes in the corresponding data shards; The remote data object receiving unit is used to drive the execution thread to concurrently call the data opening interface of the external collaborative node to receive the remote data object formatted as a key-value pair structure. The data opening interface is used to output the remote data object, and the key-value pair structure is used to carry the built-in fields of the remote data object.

[0021] Optionally, the consistency retrieval module includes: The built-in field extraction unit is used to extract the requester field, target field, order number field, suffix field and line indicator field from the remote data object, wherein the requester field, target field, order number field, suffix field and line indicator field together serve as the built-in fields for generating the feature fingerprint; The feature fingerprint generation unit is used to perform string concatenation processing on the requester field, the target field, the order number field, the suffix field, and the line indicator field according to a preset sorting rule to generate the feature fingerprint with a unique identifier. The preset sorting rule is used to limit the order of the requester field, the target field, the order number field, the suffix field, and the line indicator field in the string concatenation processing. A local detail data location unit is used to perform a lookup operation in a local cache space using the feature fingerprint to locate the local detail data with consistent characteristics. The local cache space is used to store the local detail data constructed by the flow nodes of the bidirectional mapping loading document. The consistent characteristics are used to characterize that the local detail data and the remote data object have the same feature fingerprint.

[0022] Optionally, the inventory incremental update module includes: The remote full set view construction unit is used to construct a remote full set view for the remote data object based on the remote data object returned by the external collaborative node, wherein the remote full set view is used to summarize the remote data objects returned by different external collaborative nodes; An existence detection unit is used to extract the identity identifier of the local detailed data and perform an existence detection in the remote full set view using the identity identifier. The identity identifier is derived from the field combination in the local detailed data that corresponds to the feature fingerprint. The existence detection is used to determine whether there is a remote data object in the remote full set view that corresponds to the local detailed data. A withdrawal trigger instruction generation unit is used to generate a withdrawal trigger instruction for the local detailed data when the existence probe returns a miss result, wherein the miss result is used to indicate that there is no remote data object corresponding to the local detailed data in the remote full set view, and the withdrawal trigger instruction is used to trigger the deletion process of the local detailed data; The local detail data physical erasure unit is used to respond to the withdrawal trigger command, modify the occupancy constraint attribute associated with the local detail data, and then physically erase the local detail data at the database level to clean up the time difference dirty data generated between heterogeneous systems. The occupancy constraint attribute is used to characterize the inventory occupancy relationship between the local detail data and the bimodal inventory data record, and the time difference dirty data is used to characterize the inconsistent data between the local detail data and the remote data object caused by the synchronization time difference.

[0023] Optionally, the inventory incremental update module includes: The structured query statement construction unit is used to construct a structured query statement containing independent write instructions and superimposed calculation instructions, wherein the structured query statement is used to complete the retrospective writing of the discarded records and the incremental update of the bimodal inventory data records in the same database execution context; The traceability log generation unit is used to execute the independent write instruction to write the change value into an independent operation flow table to generate a traceability log. The independent write instruction is used to write the change value in the discarded record into the operation flow table. The operation flow table is used to record the inventory change process caused by the deletion of the local detailed data. The traceability log is used to trace the source of the change value. The inventory balance field update unit is used to execute the overlay calculation instruction, trigger the database row locking mechanism to perform exclusive locking on the bimodal inventory data record, and then directly add the change value to the inventory balance field of the bimodal inventory data record in the internal calculation domain of the structured query statement. The overlay calculation instruction is used to update the bimodal inventory data record based on the change value, and the inventory balance field is used to record the inventory balance result in the bimodal inventory data record.

[0024] An electronic device includes a processor and a memory, the memory storing a computer program, wherein when the processor runs the computer program, it performs the steps of a medical device distribution supply chain method based on supply and demand coordination and bimodal inventory management.

[0025] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of a medical device distribution supply chain method based on supply and demand coordination and bimodal inventory management.

[0026] The technical advantages of the technical solution provided in this application are: To address the technical shortcomings of existing centralized unidirectional update schemes, such as the susceptibility to dirty writes and state conflicts caused by concurrent replenishment, the lack of bidirectional mapping and fine-grained consistency verification, and the tendency for inventory modifications to be inaccurate, this application presents a medical device distribution supply chain method, system, electronic device, and medium based on supply-demand collaboration and bimodal inventory management. This method identifies the source-end out-of-stock object based on the source identifier in the replenishment request data, then uses optimistic locking to update the state attributes of the source-end out-of-stock object to put it into an exclusive phase. Finally, it uses a constraint list to perform unauthorized verification on the target node set associated with the replenishment request data. This solves the problems of lack of exclusivity and authorization compliance in traditional schemes when multiple sources are replenished concurrently. Compared to the traditional passive polling mode lacking locking and risk control, this scheme can accurately control concurrent requests, avoid dirty writes, and achieve permission isolation at the source of distribution, thus significantly improving the security and independence of distribution task allocation.

[0027] Upon successful verification, the source-end out-of-stock objects in the exclusive stage are grouped according to the aggregation code of the target node set, generating a bidirectional mapping allocation document containing transfer nodes. The transfer nodes in the bidirectional mapping allocation document are parsed to construct local detailed data. Subsequently, remote data objects from external collaborative nodes are retrieved, and the built-in fields of the remote data objects are concatenated to obtain a feature fingerprint. The feature fingerprint is then used to retrieve the local detailed data, solving the problem that the traditional unidirectional queue mode cannot finely track the data status of heterogeneous systems. Compared to unidirectional data overwrite storage, the introduction of bidirectional mapping and feature fingerprints establishes a strong one-to-one association between local and remote documents, significantly enhancing the granularity of data verification and the consistency of status tracking between cross-domain heterogeneous systems.

[0028] Finally, when no remote data object corresponding to the local detailed data is detected in the remote full set view formed based on the remote data object, and the local detailed data exists, the local detailed data is deleted. The changed values ​​in the discarded records formed by deleting the local detailed data are extracted, and incremental updates are performed on the bimodal inventory data records based on these changed values ​​using a database row-locking mechanism. This solves the problem of dirty data residue and inventory inaccuracy caused by traditional global overwrite inventory modifications in high-concurrency and remote order cancellation scenarios. Compared to ordinary global overwrite modification logic, this application cleverly uses existence detection to accurately identify withdrawn data caused by time differences and performs atomic incremental inventory updates based on a row-locking mechanism, effectively cleaning up invalid local occupancy, thereby ensuring high accuracy and reliability of inventory balances and actual supply and demand flows under high concurrency. Attached Figure Description

[0029] Figure 1 This application provides an embodiment of a medical device distribution supply chain scenario based on supply and demand coordination and bimodal inventory management. Figure 2 This application provides an embodiment of a medical device distribution supply chain method based on supply and demand coordination and bimodal inventory management. Figure 3 This application provides an embodiment of a medical device distribution supply chain system based on supply and demand coordination and bimodal inventory management. Figure 4 This is an electronic device according to an embodiment of the present application.

[0030] Figure 5 This is a computer-readable storage medium according to an embodiment of the present application. Detailed Implementation

[0031] like Figure 1 The image shows a medical device distribution supply chain scenario based on supply and demand coordination and bimodal inventory management, as described in an embodiment of this application. Figure 2 The image shows an embodiment of a medical device distribution supply chain method based on supply and demand coordination and bimodal inventory management, which includes the following steps: Based on the source identifier in the replenishment request data, the source-end out-of-stock object is locked. Then, optimistic locking is used to update the status attribute of the source-end out-of-stock object so that it enters the exclusive stage. Here, the source identifier is used to characterize the trigger source type corresponding to the replenishment request data, and the source-end out-of-stock object is used to characterize the data object to be replenished corresponding to the replenishment request data in the local storage pool. An unauthorized access check is performed on the target node set associated with the replenishment request data using a constraint list, wherein the target node set is used to represent the pending delivery node pointed to by the replenishment request data, and the constraint list is used to limit the execution permissions of the nodes corresponding to the target node set; When the verification is successful, the source-end out-of-stock objects in the exclusive stage are grouped according to the aggregation code of the target node set, and a two-way mapping distribution document containing transfer nodes is generated. The aggregation code is used to represent the aggregation relationship between different target nodes in the target node set, and the transfer node is used to represent the sending end node and receiving end node of the source-end out-of-stock object in the two-way mapping distribution document. The local detailed data is constructed by parsing the circulation node of the bidirectional mapping order, and then the remote data object of the external collaborative node is pulled. The local detailed data is used to record the order details of the circulation node in the local system, and the external collaborative node is used to provide the remote data object for collaborative verification with the local detailed data. The feature fingerprint is obtained by concatenating the built-in fields of the remote data object, and the feature fingerprint is used to retrieve the local detailed data. The feature fingerprint is used to establish a consistent retrieval relationship between the remote data object and the local detailed data. If no remote data object corresponding to the local detailed data is detected in the remote full set view formed based on the remote data object, and the local detailed data exists, the local detailed data is deleted, the change value in the discarded record formed by deleting the local detailed data is extracted, and the bimodal inventory data record is incrementally updated based on the change value through the database row locking mechanism. The discarded record is used to record the inventory occupancy change content corresponding to the deletion of the local detailed data, and the bimodal inventory data record is used to simultaneously record the local inventory status and collaborative inventory status in the medical device distribution supply chain.

[0032] Optionally, locking the source-end inventory object based on the source identifier in the replenishment request data, and then using optimistic locking to update the status attributes of the source-end inventory object to make it enter the exclusive phase includes: Extract the numerical attribute carried by the source identifier, wherein the numerical attribute is used to indicate the trigger source type corresponding to the replenishment request data; When the numerical attribute indicates a passively triggered event, a unique tracking code is generated based on the replenishment request data. The passively triggered event is used to characterize a source-end inventory object locking scenario triggered by an external replenishment demand, and the unique tracking code is used to locate the source-end inventory object in the local storage pool. The source of the out-of-stock item is located in the local storage pool using the unique tracking code. The optimistic locking is used to verify the current version number of the source-end overdue object. Then, when the current version number meets the preset inference conditions, the status attribute is modified to prevent other processes from concurrently overwriting the source-end overdue object, thus causing it to enter the exclusive phase. The current version number is used to represent the current data version of the source-end overdue object in the local storage pool, and the preset inference conditions are used to determine whether the current version number allows the status attribute to be updated.

[0033] Preferably, the specific implementation process of step "extracting the numerical attributes carried by the source identifier" is as follows: Before the replenishment request data enters the replenishment flow processing, the source identifier is first read from the request body field area, request header field area, and current session environment field area of ​​the replenishment request data, and the read source identifier is written into the source resolution record. The source resolution record does not simply store a field value, but simultaneously stores the field source path, field original value, field encoding type, and field reception time of the source identifier, so that subsequent numerical attribute extraction can point back to the field source path of the replenishment request data. Subsequently, the source resolution record is processed for field alignment according to the pre-configured source field mapping relationship. The source field mapping relationship is used to limit the field name, field level, and encoding method used by different access terminals when carrying the source identifier in the replenishment request data. For example, the hospital-side overstock replenishment entry can carry the source type field in the request body field area, and the platform proactive replenishment entry can carry the source type field in the current session environment field area. The source field mapping relationship can configure passively triggered events as passively triggered encoding values ​​(e.g., 1) and proactively triggered events as proactively triggered encoding values ​​(e.g., 2). After field alignment is completed, the original field values ​​in the source resolution record are filtered for null values, characters are despaced, full-width and half-width characters are converted, and numerical characters are validated to form a coding verification result. When the coding verification result indicates that the original field value can be parsed into a source type code, the source type code is rewritten into the numerical attribute, and the numerical attribute is backfilled into the source resolution record. The technical essence of the numerical attribute is a trigger source diversion mark formed before the replenishment request data enters the source-end inventory object locking process. It does not participate in inventory quantity calculation, but is used to select whether to perform subsequent locking processing on the source-end inventory object, or to bypass the locking processing on the source-end inventory object to generate a new reserve record. Thus, the source resolution record serves as the basis for source judgment in subsequent processing, and the numerical attribute serves as a specific judgment field in the source resolution record to participate in the diversion judgment of passively triggered events and actively triggered events. This avoids confusing the hospital-end inventory replenishment entry and the platform's active inventory preparation entry into the same data entry, reducing the risk of mis-locking or missed locking of source-end inventory objects due to entry type confusion from the source.

[0034] Preferably, in the specific technical implementation of the step "generating a unique tracking code based on the replenishment request data when the numerical attribute indicates a passively triggered event", the consistency comparison between the numerical attribute and the passively triggered code value in the mapping relationship of the source field is first performed to form a source code comparison result; when the source code comparison result indicates that the numerical attribute corresponds to the hospital-side out-of-stock replenishment entry, the replenishment request data is classified into the passively triggered event. The technical essence of the passively triggered event is that the external replenishment demand has already formed an out-of-stock record in the preceding link. The current replenishment request data no longer generates a new pending order data object, but needs to return to the local storage pool to find the existing source-side out-of-stock object and perform state occupancy processing on the source-side out-of-stock object; therefore, the difference between the passively triggered event and the active triggered event is not in the page entry name, but in whether the replenishment request data already has a source-side out-of-stock object that can be pointed back to. To ensure stable tracking of the source-end inventory shortage, the hospital site code, demand order detail identifier, medical device product code, batch number expiration date associated field, replenishment request generation time field, and source identifier are first extracted from the replenishment request data. These fields are then standardized according to a pre-configured field order to form a source element fragment. This source element fragment carries the source fields required to generate a unique tracking code. Field standardization includes removing invalid separator characters, standardizing date and time expressions, standardizing the case sensitivity of the medical device product code, and adding placeholders to default fields. The standardized source element fragment is then entered into the tracking code generation record. The tracking code generation record then uses a universal unique identifier generation method to discretize and encode the source element fragment, forming the unique tracking code. The technical essence of the unique tracking code is to compress the source information scattered across different fields in the replenishment request data into a searchable object location key. This unique tracking code does not represent the medical device itself, nor does it replace the source-end out-of-stock object. Instead, it serves as a location medium between the replenishment request data and the source-end out-of-stock object, participating in local storage pool retrieval. Since the unique tracking code is generated from source-end element fragments under passive triggering events, it can retain the combination relationship between the hospital-end out-of-stock replenishment entry, the demand order detail identifier, and the medical device product code in a searchable code. When subsequently using the unique tracking code to locate the source-end out-of-stock object, it can reduce the risk of order mix-ups caused by relying solely on a single product field and provide traceable source evidence before the source-end out-of-stock object enters the exclusive stage.

[0035] Preferably, the specific implementation process of step "locating the source-end out-of-stock object in the local storage pool using the unique tracking code" is as follows: After the unique tracking code is formed, it is first matched with a pre-established tracking code index record in the local storage pool. The tracking code index record is generated synchronously when historical out-of-stock records are written to the local storage pool. The tracking code index record at least stores the unique tracking code, the primary key of the out-of-stock record, the demand order detail identifier, the medical device product code, the batch number expiration date association field, and the current version number. The existence of the tracking code index record allows the local storage pool to avoid traversing all out-of-stock records, and instead use the unique tracking code as the entry point to read the candidate object location corresponding to the replenishment request data. Subsequently, the object location candidate record is read according to the tracking code index record, and the demand order detail identifier, medical device product code, and batch number expiration date association field in the object location candidate record are compared with the demand order detail identifier, medical device product code, and batch number expiration date association field in the replenishment request data for secondary consistency comparison. The secondary consistency comparison is used to exclude tracking code index record mishitting caused by historical data migration, cache delay, or duplicate submission. After the second consistency check passes, the primary key of the outstanding inventory record corresponding to the candidate record for object location is used as the basis for locating the source-end outstanding inventory object, and the source-end outstanding inventory object is read from the local storage pool accordingly. When reading the source-end outstanding inventory object, the status attribute, current version number, occupied quantity field, pending replenishment quantity field, and target node set association field of the source-end outstanding inventory object are read simultaneously to form a location verification record. The location verification record is used to inherit the location result of the unique tracking code and associate the status attribute, current version number, occupied quantity field, pending replenishment quantity field, and target node set association field of the source-end outstanding inventory object with subsequent optimistic locking verification; among them, the occupied quantity field is used in the location verification record to represent the quantity of the source-end outstanding inventory object that has been occupied by historical allocation flow, the pending replenishment quantity field is used in the location verification record to represent the quantity of the source-end outstanding inventory object that still needs to enter the bidirectional mapping allocation document generation process, and the target node set association field is used in the location verification record to represent the node source of the source-end outstanding inventory object participating in the target node set over-authority verification in the subsequent target node set verification. If the location verification record shows that the source-end out-of-stock object is in a state that can no longer be processed, then the exclusive phase of processing for that source-end out-of-stock object is stopped, and the location verification record is retained as the basis for intercepting duplicate requests. Through the above processing, the function of the unique tracking code in the local storage pool is not simply to query the identifier, but to first drive the tracking code index record to be hit, then to verify the fields of the object location candidate record, and finally to form a location verification record that can enter optimistic locking verification. This allows the location, status reading, and version reading of the source-end out-of-stock object to be completed in the same technical link, reducing the mismatch of source-end out-of-stock objects caused by improper cache hits under high-concurrency replenishment requests.

[0036] Preferably, in the specific technical implementation of the step "verifying the current version number of the source-end indebted object using the optimistic lock", the current version number is incremented by the source-end indebted object each time it completes a persistent state update in the local storage pool. The current version number and the state attribute of the source-end indebted object are stored in the same data record, so that the current version number can reflect the data version of the source-end indebted object after the most recent state update. The technical essence of optimistic locking is to determine whether the source-end indebted object has been updated by other processes after the self-location verification record is formed, without pre-occupying the database exclusive lock, by comparing version conditions. Optimistic locking is not a separate permission judgment, nor is it a simple timestamp judgment. Instead, it writes the unique tracking code, the indebted record primary key, the current version number, and the state attribute to be updated into the conditional update statement, so that the conditional update statement is only allowed to modify the state attribute if the current version number in the local storage pool is still equal to the current version number in the location verification record. In practice, the current version number is first read from the location verification record and written to the version verification record. Then, the real-time version number of the source-end out-of-stock object in the local storage pool is read, and a version consistency comparison is performed between the real-time version number and the current version number in the version verification record to generate a version consistency comparison result. If the version consistency comparison result indicates that the real-time version number has changed, it means that the source-end out-of-stock object has been occupied or updated by other processes after being located. In this case, the status attribute is not modified, and the version consistency comparison result is written back to the version verification record so that subsequent replenishment request data can re-execute source resolution and unique tracking code location. If the version consistency comparison result indicates that the real-time version number has not changed, the version verification record is submitted to the status attribute update processing. Through this optimistic locking verification method, the source-end out-of-stock object under passively triggered events does not need to occupy a database exclusive lock for a long time during the reading phase. Instead, version condition verification is performed before the status attribute is actually modified. This reduces blocking when multiple replenishment request data reads the same source-end out-of-stock object simultaneously, and prevents source-end out-of-stock objects that have already undergone version changes from being overwritten by old replenishment request data.

[0037] Preferably, the specific implementation process of the step "when the current version number meets the preset inference conditions, modify the status attribute to prevent other processes from concurrently overwriting the source-end out-of-stock object and causing it to enter the exclusive stage" is as follows: The preset inference conditions are configured as a combination of executable version conditions and executable status conditions before the replenishment flow processing begins. The executable version conditions are used to determine whether the current version number in the version verification record is consistent with the real-time version number in the local storage pool. The executable status conditions are used to determine whether the status attribute of the source-end out-of-stock object is still in the pending state that allows it to enter the exclusive stage. The technical essence of the preset inference conditions is to combine the two judgment criteria of unchanged version and available status into a status transition admission condition, rather than determining whether the source-end out-of-stock object enters the exclusive stage solely based on the arrival order of replenishment request data. In specific implementation, the version consistency comparison result in the version verification record is read first, and the status attribute in the location verification record is read; then, the version consistency comparison result and the status attribute are written into the status transition verification record respectively, and the status transition verification record makes an admission judgment based on the preset inference conditions. If the state transition verification record indicates that the current version number meets the executable version condition and the state attribute meets the executable state condition, then the state attribute of the source-end indebted object is changed from the pending state to the exclusive stage state. In the same state attribute modification process, the current version number is incremented to form a state transition record. The reason for modifying the state attribute is that the source-end indebted object will subsequently enter the target node set over-authority verification, aggregation coding grouping, and bidirectional mapping order generation process. If the source-end indebted object remains in the repeatedly readable pending state, multiple replenishment request data will repeatedly generate bidirectional mapping order documents around the same source-end indebted object, thus causing a misalignment in the mapping relationship between subsequent local detailed data and remote data objects. After the state transition record is formed, it continues to participate in the subsequent target node set over-authority verification, carrying the unique tracking code, current version number, and state attribute. This ensures that the state attribute modification is not an isolated data marker change, but rather serves as a prerequisite for the source-end indebted object to enter the subsequent order allocation flow. The exclusive phase does not simply mark the source-end backlog object as processed; rather, it transforms the source-end backlog object from a pending state where it can be read simultaneously by multiple replenishment request data to a state that can only be continued by replenishment request data that has been verified through the current version number. After the status attribute is modified to the exclusive phase state, the local storage pool establishes an exclusive status transition record for the source-end backlog object. The exclusive status transition record includes a unique tracking code, the status attributes before the status transition, the status attributes after the status transition, the incremented current version number, the request session identifier of the replenishment request data, and the target node set association field.When other processes use the same unique tracking code to locate the source-end overstock object again, they will read the exclusive stage status in the exclusive state transition record and return a judgment result that updates are not allowed at the executable state condition of the preset inference conditions. At the same time, the old current version label held by other processes cannot be verified by optimistic locking, so parallel overwriting of the source-end overstock object is not possible. The reason for preventing parallel overwriting is that once the source-end overstock object enters the aggregation coding grouping and bidirectional mapping order generation process, the replenishment quantity field, target node set association field, and subsequent flow nodes of the source-end overstock object will be used together to construct the bidirectional mapping order. If other processes overwrite the status attribute or replenishment quantity field of the source-end overstock object during this period, it will destroy the positioning relationship between the unique tracking code and the source-end overstock object, and it will also make it difficult for subsequent local detailed data to establish a stable and consistent retrieval relationship with the remote data object. By coordinating the state occupancy interval, exclusive state transition record, and optimistic locking verification during the exclusive phase, the source-end inventory object completes traceable occupancy limitation before entering the bidirectional mapping order generation process. Subsequent target node set over-authority verification, aggregation coding grouping, and local detailed data construction all revolve around the occupied source-end inventory object, thereby reducing the technical risk of the same source-end inventory object being repeatedly split, repeatedly occupied, or repeatedly written in high-concurrency replenishment scenarios.

[0038] Optionally, after extracting the numerical attributes carried by the source identifier, the method further includes: When the numerical attribute indicates an active triggering event, the locking operation for the source-end out-of-stock object is bypassed to determine the data object to be allocated. The active triggering event is used to characterize the scenario of generating new reserve records with replenishment requirements actively generated by the local system. A new reserve record is generated based on the replenishment request data, wherein the new reserve record is used to represent the pending delivery data object generated under the active triggering event; The newly added reserve record is bound to the target node set, and the newly added reserve record is used as a pre-input source for generating the bidirectional mapping distribution document, so as to realize the unified convergence of data flow in multi-source triggering scenarios. The pre-input source is used to participate in the generation of the bidirectional mapping distribution document together with the source-end inventory object in the exclusive stage.

[0039] Preferably, the specific implementation process of step "bypassing the locking operation for the source-end inventory object to determine the data object to be allocated when the numerical attribute indicates an active triggering event" is as follows: After obtaining the numerical attribute from the source parsing record, the consistency of the numerical attribute and the active triggering code value in the source field mapping relationship is first compared to form an active triggering identification result; when the active triggering identification result indicates that the replenishment request data originates from the active replenishment entry, the replenishment request data is written into the active triggering diversion record. The active triggering diversion record is used to carry the replenishment request data, source identifier, numerical attribute, active triggering identification result, and target node set association field. The formation of the active triggering diversion record distinguishes active triggering events from passive triggering events at the data entry point. The technical essence of the active triggering event is that the data processing environment corresponding to the local storage pool actively initiates a new allocation data formation process based on inventory replenishment needs. When the replenishment request data enters the allocation data formation process corresponding to the active triggering event, there is no source-end inventory object already written to the local storage pool. Therefore, the active triggering event does not need to look up the source-end inventory object through a unique tracking code, nor does it need to use optimistic locking to modify the status attribute of the source-end inventory object. To bypass the locking operation targeting the source-end out-of-stock objects, after the active triggering diversion record is formed, a lock skip flag is directly written into the active triggering diversion record, and a correspondence is established between the lock skip flag and the replenishment request data, numerical attributes, and active triggering identification results. The lock skip flag does not skip all pre-verification, but only blocks four processing steps related to the occupation of existing source-end out-of-stock objects: unique tracking code generation, source-end out-of-stock object location, current version number verification, and status attribute modification. The lock skip flag still retains the entry point for the replenishment request data to enter the target node set for unauthorized verification, aggregation code grouping, and bidirectional mapping of the distribution document generation process. Subsequently, based on the replenishment request data in the active triggering diversion record, the medical device product code, target node set, requested quantity field, hospital site code, and aggregation code are read to form candidate records of data objects to be distributed. These candidate records of data objects to be distributed are used to undertake the formation process of data objects to be distributed under the active triggering event and provide field sources in the subsequent generation process of new reserve records.By locking the connection between the skip marker and the candidate record of the pending order data object, the replenishment request data under the active triggering event will not occupy the non-existent source-end inventory object, nor will it mistakenly trigger the exclusive stage processing under the passive triggering event. At the same time, the candidate record of the pending order data object continues to carry the target node set and aggregation code, so that the pending order data object can enter the subsequent bidirectional mapping order document generation process with the same bidirectional mapping order document as the source-end inventory object in the exclusive stage. Thus, even if the active stock preparation entry and the inventory replenishment entry are from different front-end sources, they can still form a unified front-end data carrying standard before the bidirectional mapping order document generation process. The front-end data carrying standard continues to serve as the input basis for the generation process of new reserve records.

[0040] Preferably, in the specific technical implementation of the step "generating new reserve records based on the replenishment request data", the replenishment request data and candidate records of pending distribution data objects in the proactively triggered distribution record are first read. Then, the medical device product code, target node set, request quantity field, hospital site code, and aggregation code in the candidate records of pending distribution data objects are checked for field integrity to form a proactive replenishment field verification record. The proactive replenishment field verification record is used to determine whether the replenishment request data has the basic fields required to generate new reserve records. Specifically, the medical device product code is used to identify the medical device object that needs to enter the distribution flow; the target node set is used to limit the subsequent pending distribution nodes; the request quantity field is used to carry the replenishment quantity requirement under the proactively triggered event; the hospital site code is used to limit the proactively triggered event to the corresponding distribution site range; and the aggregation code is used for subsequent grouping and generation of bidirectional mapping distribution documents. After the proactive inventory preparation field verification record is formed, field normalization processing is performed on the candidate records of the data objects to be prepared for distribution based on the proactive inventory preparation field verification record. Field normalization processing includes unifying the coding caliber of medical device product codes, unifying the quantity unit of the request quantity field, unifying the site caliber of hospital site codes, and correcting null value placeholders in the aggregate code, so as to form a proactive inventory preparation standardized record. The proactive inventory preparation standardized record continues to participate in the new reserve record generation process to avoid the same proactive triggering event being split into different data groups by subsequent aggregate coding grouping processing due to inconsistent field calibers. Subsequently, a new reserve record primary key is generated based on the proactive inventory preparation standardized record, and the new reserve record primary key, replenishment request data, medical device product code, target node set, request quantity field, hospital site code, aggregate code, proactive trigger identification result, and lock skip flag are written into the new reserve record. The technical essence of the newly added reserve record is that it is a data carrier record for available goods generated under an actively triggered event. It does not originate from the state transition of historical backlog records, but rather from the field normalization processing result of replenishment request data under the active stock preparation entry point. Therefore, the newly added reserve record can represent the data object to be picked up generated under the actively triggered event and replace the source backlog object in the subsequent two-way mapping order generation process. To connect with the subsequent purchase-side replenishment order entry processing, the newly added reserve record also retains the source correspondence between the primary key of the newly added reserve record and the actively prepared normalized record, enabling the newly added reserve record to be converted into the basic fields required for purchase-side replenishment order entry processing. To connect with the subsequent delivery-side order generation processing, the newly added reserve record also retains the target node set and aggregation code, enabling the newly added reserve record to participate in the data grouping before the delivery-side order generation processing according to the aggregation code.Through the above generation method, the newly added reserve record is neither a simple copy of the replenishment request data nor a replacement and renaming of the source-end out-of-stock object. Instead, it transforms the replenishment request data under the actively triggered event into a data carrier record with allocation fields, node fields, and grouping fields. Among them, the allocation field comes from the medical device product code and the requested quantity field, the node field comes from the target node set and the hospital site code, and the grouping field comes from the aggregation code. The allocation field, node field, and grouping field are all included in the newly added reserve record so that the newly added reserve record can maintain a consistent data processing entry with the source-end out-of-stock object in the exclusive stage in the subsequent processing link. The data processing entry continues to be used for the construction and processing of the front-end input source.

[0041] Preferably, the specific implementation process of the step "binding the newly added reserve record to the target node set and using the newly added reserve record as a pre-input source for generating the bidirectional mapping distribution document" is as follows: After the newly added reserve record is generated, the target node set, aggregation code, medical device commodity code, request quantity field, and hospital site code in the newly added reserve record are read first, and the target node set is written into the target node set association field of the newly added reserve record to form a newly added reserve node binding record. The newly added reserve node binding record is used to carry the binding relationship between the newly added reserve record and the target node set. The target node set association field is used to point back to the distribution node to be executed pointed to by the newly added reserve record in the subsequent unauthorized verification process. Subsequently, the node code and node execution permission field in the target node set are read according to the newly added reserve node binding record, and the node code and node execution permission field are written into the node description record to be verified. The node description record to be verified continues to enter the unauthorized verification process corresponding to the constraint list. After the unauthorized verification is passed, the newly added reserve node binding record is rewritten as a pre-input source. The technical essence of the aforementioned front-end input source is a unified input carrier form before the bidirectional mapping of the packing order generation process. It can carry both newly added reserve records under actively triggered events and source-end inventory backlog objects in the exclusive stage under passively triggered events. This allows data in multi-source triggering scenarios to no longer use the source entry as the basis for subsequent order allocation, but rather the target node set and aggregation code as the common grouping basis. In specific implementation, the newly added reserve records and source-end inventory backlog objects in the exclusive stage in the front-end input source are first converted into streaming data containing aggregation codes. Then, the streaming data is aggregated according to the aggregation codes to form data groups facing the same target node set. Subsequently, the missing master data attributes of the data groups are requested from the external master data source through a remote call protocol, and the master data attributes are filled into the corresponding data groups, thereby constructing the bidirectional mapping of the packing order. The technical essence of the bidirectional mapping order document is that it simultaneously stores the correspondence between the purchasing replenishment order and the distribution order in the same order flow. The sending primary key identifies the sending node in the flow, and the receiving primary key identifies the receiving node. The mapping relationship between the sending and receiving primary keys allows the purchasing replenishment order and the distribution order to mutually refer back in subsequent local detailed data construction, remote data object verification, and feature fingerprint retrieval. The bidirectional mapping order document uses a two-way mapping relationship because after a new reserve record enters the bidirectional mapping order document through the upstream input source, it can not only be traced from the purchasing replenishment order to the distribution order, but also vice versa. This bidirectional mapping relationship differs from unidirectional flow records that only generate one endpoint from the other.By binding new reserve records to the target node set and using them as a source of input, new reserve records under proactively triggered events can participate in the generation of bidirectional mapping order documents together with the source-end inventory objects in the exclusive stage under passively triggered events. This ensures that subsequent local detailed data construction, remote data object retrieval, and dual-modal inventory data record updates all follow the same order flow path, reducing data fragmentation caused by the proactive stocking entry and inventory replenishment entry forming independent document paths.

[0042] Optionally, performing an over-authority check on the target node set associated with the replenishment request data using the constraint list includes: The target node set is sent to the independent verification node via a remote procedure call protocol, wherein the remote procedure call protocol is used to transmit the target node set between the local system and the independent verification node, and the independent verification node is used to verify the frozen status of the nodes corresponding to the target node set; Receive node freeze status feedback returned by the independent verification node, wherein the node freeze status feedback is used to characterize whether the target node set is in a frozen state; When the node freeze status feedback indicates that it is not frozen, capture the operation credential data in the current session environment, wherein the operation credential data is used to characterize the operation identity and operation permissions of the person who initiated the replenishment request data in the current session environment; The operation voucher data is injected into the constraint list as input to perform local permission probing. When a whitelist record is matched, it is confirmed that the target node set has legitimate execution permissions to isolate unauthorized requests from illegal nodes. The whitelist record belongs to the constraint list, and the legitimate execution permissions are used to indicate that the target node set can participate in the generation of the bidirectional mapping order.

[0043] Preferably, the specific implementation process of the step "sending the target node set to the independent verification node via the remote call protocol" is as follows: After the replenishment request data completes source diversion and forms a target node set, the node code, node type field, aggregation code, hospital site code, and request session identifier corresponding to the replenishment request data in the target node set are read first, and the node code, node type field, aggregation code, hospital site code, and request session identifier are written into the node freeze verification request record. The node freeze verification request record is used to carry the verification fields that need to be transmitted by the remote call protocol. The node code in the node freeze verification request record is used to identify the distribution node to be executed, the node type field is used to distinguish the receiving node and the sending node in the target node set, the aggregation code is used to keep multiple distribution nodes to be executed under the same distribution flow within the same grouping caliber, the hospital site code is used to limit the distribution site range corresponding to the target node set, and the request session identifier is used to indicate the source of this replenishment request data in the current session environment. Subsequently, the node freeze verification request record undergoes field serialization processing to form a node freeze verification message. This field serialization processing does not alter the technical meaning of the node freeze verification request record; rather, it converts the record into a key-value pair structure readable by the independent verification node according to a preset field arrangement order and field type constraints. The technical essence of the remote call protocol is a structured communication constraint used between the local data processing environment and the independent verification node to transmit the node freeze verification message. This constraint includes a call address field, a call method field, a message header field, a message body field, a request time field, a retry count field, and a return result field. The call address field is used to locate the data access address of the independent verification node; the call method field specifies the node freeze status verification process; the message header field carries the request session identifier; the message body field carries the node freeze verification message; the request time field records the sending time of the node freeze verification message; the retry count field limits the number of times the node freeze verification message can be resent in case of transmission errors; and the return result field receives subsequent node freeze status feedback. After the remote call protocol is constructed, the node freeze verification message is written into the message body field, and the message body field is combined with the message header field to form a node freeze verification call record. The node freeze verification call record is sent to the independent verification node via the remote call protocol, enabling the independent verification node to verify the node freeze status of the target node set based solely on the node freeze verification message without directly reading all replenishment request data in the local storage pool. Through the above processing, the target node set completes cross-node status verification preparation in the form of a node freeze verification message before entering the bidirectional mapping order generation process. This ensures that the subsequent order allocation flow does not rely solely on the one-way judgment of the local data processing environment, but rather proceeds to the next processing stage only after the node freeze status of the target node set has been verified by the independent verification node.

[0044] Preferably, in the specific technical implementation of the step "receiving the node freeze status feedback returned by the independent verification node", after receiving the node freeze verification call record, the independent verification node first parses the message header field and message body field in the node freeze verification call record to obtain the request session identifier, node code, node type field, aggregation code, and hospital site code, and writes the request session identifier, node code, node type field, aggregation code, and hospital site code into the node freeze status query record. The node freeze status query record is used to establish a query relationship between the target node set and the node freeze status registration data on the independent verification node side. The node freeze status registration data is used to store whether the node to be dispatched is in a frozen state, the start time of the frozen state, the end time of the frozen state, and the source field of the frozen state. Subsequently, the independent verification node performs node freeze status retrieval processing in the node freeze status registration data based on the node code and hospital site code in the node freeze status query record to form a node freeze status retrieval result. If the node freeze status retrieval result indicates that at least one pending distribution node in the target node set has active freeze status registration data, the corresponding node code, freeze status flag, and freeze status source field are written into the node freeze status feedback. If the node freeze status retrieval result indicates that none of the pending distribution nodes in the target node set have active freeze status registration data, the corresponding node code and unfrozen status flag are written into the node freeze status feedback. The technical essence of the node freeze status feedback is that the independent verification node generates structured status feedback data based on the node freeze verification message. It is not a simple pass or fail prompt, but rather provides a freeze status flag for each pending distribution node on a target node set basis, enabling the local data processing environment to match the node freeze status feedback with the node codes in the target node set item by item. After the node freeze status feedback is generated, the independent verification node writes the node freeze status feedback into the return result field of the remote call protocol and sends the return result field back to the local data processing environment. Upon receiving the return result field, the local data processing environment deserializes the node freeze status feedback to form a node freeze status reception record. This node freeze status reception record continues to participate in subsequent unfrozen condition determination processing. The node code in the node freeze status reception record maintains a one-to-one correspondence with the node code in the target node set. The freeze status flag in the node freeze status reception record indicates whether the target node set has the prerequisite state to enter the operation voucher data capture processing. Through the connection between the node freeze status feedback and the node freeze status reception record, the local data processing environment can incorporate the freeze status verification result of the independent verification node into the subsequent unauthorized verification chain, avoiding the continued generation of bidirectional mapping distribution documents when there are frozen distribution nodes awaiting execution in the target node set.

[0045] Preferably, the specific implementation process of step "capturing operation credential data in the current session environment when the node freeze status feedback indicates that it is not frozen" is as follows: After the node freeze status receiving record is formed, the freeze status flag in the node freeze status receiving record is first read, and the freeze status flag is compared with the pre-configured unfrozen status value to form an unfrozen determination record. The unfrozen determination record is used to receive the node freeze status feedback returned by the independent verification node and to determine whether the target node set can enter the operation credential data capture processing; when the unfrozen determination record indicates that all the pending delivery nodes in the target node set are in an unfrozen state, the session identifier, operator identity identifier, role and permission field, hospital site code, supplier code list, and request time field in the current session environment are read, and the session identifier, operator identity identifier, role and permission field, hospital site code, supplier code list, and request time field are written into the operation credential collection record. The operation credential collection record carries the original fields that characterize the operation identity and permissions in the current session environment. The session identifier refers to the session channel corresponding to the current replenishment request data, the operator identity identifier identifies the operator initiating the replenishment request data, the role and permission field carries the allowed node permission range in the current session environment, the hospital site code limits the distribution site range corresponding to the replenishment request data, the supplier code list carries the supplier codes involved in the target node set, and the request time field records the time when the replenishment request data enters the unauthorized access verification process. Subsequently, the operation credential collection record undergoes field credibility verification, including session identifier validity verification, consistency verification between the operator identity identifier and the role and permission field, range correspondence verification between the hospital site code and the supplier code list, and timeliness verification of the request time field, to form operation credential data. The technical essence of this operation credential data is the permission input data extracted from the current session environment and verified for field credibility. It is used to limit the range of target nodes that the replenishment request data can access during subsequent local permission exploration processing. There is a sequential relationship between the operation voucher data and the node freeze status feedback: operation voucher data is only captured when the node freeze status feedback indicates that the target node set is not frozen; after the operation voucher data is formed, it is matched with the constraint list, so that the unauthorized access verification includes both the freeze status verification of the target node set and the permission field verification of the current session environment. Through the above processing, not being frozen does not mean having legal execution permissions; not being frozen only indicates that the pending order picking node is not restricted from access by the independent verification node. The operation voucher data is then used to further determine whether the replenishment request data has the necessary permissions to process the order picking flow of the target node set.

[0046] Preferably, in the specific technical implementation of the step "injecting the operation voucher data as input condition into the constraint list to perform local permission exploration", the operation terminal identity identifier, role permission field, hospital site code, and supplier code list in the operation voucher data are read first, and the whitelist record, node permission boundary record, site node correspondence record, and preset permission caliber record in the constraint list are read to form a permission exploration input record. The permission exploration input record is used to receive the operation voucher data and the constraint list. Among them, the whitelist record is used to store the node code combination that is allowed to participate in the two-way mapping order document generation process; the node permission boundary record is used to store the executable range between the role permission field and the target node set; the site node correspondence record is used to store the correspondence between the hospital site code and the supplier code list; and the preset permission caliber record is used to store the site range matching result, node code matching result, permission range matching result, and the matching conditions that need to be met for the whitelist hit judgment. Injecting operational voucher data into the constraint list as input does not involve simply writing the operational voucher data into the constraint list to generate a new one. Instead, it uses the operator's identity identifier, role and permission fields, hospital site code, and supplier code list from the operational voucher data as search criteria to perform hierarchical matching processing on whitelist records, node permission boundary records, site node corresponding records, and preset permission caliber records in the constraint list. The hierarchical matching process first filters the candidate node range corresponding to the hospital site code in the site node corresponding record based on the hospital site code to form a site range matching result; then, it performs node code matching in the site range matching result based on the supplier code list to form a node code matching result; next, it performs permission range matching in the node permission boundary record based on the operator's identity identifier and role and permission fields to form a permission range matching result; finally, the node code matching result and the permission range matching result are jointly imported into the whitelist record, and a whitelist hit judgment is performed based on the preset permission caliber record to form a local permission exploration result. The local permission exploration result is used to determine whether the target node set can participate in the generation of bidirectional mapping delivery documents. The reason for local permission probing is that node freeze status feedback can only indicate whether the target node set is frozen, not whether the current session environment has permission to access the target node set. Local permission probing between operation credential data and the constraint list can combine and verify the operation identity, operation permissions, hospital site scope, and supplier node scope within the current session environment. Through the above layered matching process, the target node set will only be written into the legitimate execution permission confirmation record when the site scope matching result, node code matching result, permission scope matching result, and whitelist hit judgment all meet the preset permission criteria. The legitimate execution permission confirmation record continues to participate in the bidirectional mapping of the loading order generation process, thus providing traceable permission verification evidence for the target node set before it enters the loading flow.

[0047] Preferably, the specific implementation process of the step "confirming that the target node set has legitimate execution permissions when a whitelist record is hit, so as to isolate unauthorized requests from illegal nodes" is as follows: After the local permission exploration result is formed, the whitelist hit judgment result in the local permission exploration result is read first, and the whitelist hit judgment result is matched item by item with the node code in the target node set to form a node permission correspondence record. The node permission correspondence record is used to save the whitelist hit status corresponding to each pending allocation node. The whitelist hit status in the node permission correspondence record is used to determine whether the pending allocation nodes in the target node set can enter the bidirectional mapping allocation document generation process. When the node permission correspondence record indicates that all pending allocation nodes in the target node set have hit the whitelist record, the target node set, operation voucher data, node freeze status feedback, local permission exploration result, and preset permission caliber record are jointly written into the legitimate execution permission confirmation record. The technical essence of the legitimate execution permission confirmation record is the permission access data formed before the target node set enters the bidirectional mapping order generation process. The legitimate execution permission confirmation record not only records that the target node set possesses legitimate execution permissions, but also records the combined judgment of legitimate execution permissions derived from node freeze status feedback, local permission exploration results, and preset permission caliber records. After the legitimate execution permission confirmation record is formed, the target node set continues to participate in the aggregation coding grouping process. Source-end inventory shortage objects or newly added reserve records in the exclusive stage are converted into streaming data according to aggregation coding, and bidirectional mapping order documents are generated within the target node set defined by the legitimate execution permission confirmation record. If the node permission corresponding record indicates that any pending ordering node in the target node set does not match a whitelist record, the node code, operation voucher data, and replenishment request data of the node that did not match the whitelist record are written into the unauthorized request isolation record, and the unauthorized request isolation record prevents the pending ordering node from entering the aggregation coding grouping process. The unauthorized request isolation record is used to isolate unauthorized requests from illegal nodes. The technical essence of these unauthorized requests lies in the lack of a whitelist-required permission mapping between the current session environment corresponding to the operation voucher data and the pending allocation nodes in the target node set. If unauthorized requests from illegal nodes are not isolated, unauthorized pending allocation nodes will enter the bidirectional mapping allocation document generation process, further affecting local detailed data construction, remote data object verification, and subsequent updates to bimodal inventory data records. Through the diversion processing between node permission mapping records, legitimate execution permission confirmation records, and unauthorized request isolation records, the target node set only participates in the bidirectional mapping allocation document generation if it is not frozen and matches the whitelist record. Pending allocation nodes that do not match the whitelist record are intercepted in the unauthorized verification stage, thus ensuring that replenishment request data undergoes dual limitation of node freezing status and session permission boundaries before entering the allocation flow chain.

[0048] Optionally, grouping the source-end inventory backlog objects in the exclusive stage according to the aggregation code of the target node set, and generating a bidirectional mapping dispatch document containing transfer nodes includes: The source-end overstock object in the exclusive phase is converted into streaming data containing the aggregate code, wherein the streaming data is used to carry the source-end overstock object and the aggregate code corresponding to the source-end overstock object; The streaming data is aggregated according to the aggregation code to obtain multiple independent data groups, wherein the data groups are used to represent the streaming data sets that have the same or related aggregation codes; The system requests the missing master data attributes of each data group from an external master data source via a remote call protocol. The external master data source is used to provide the master data attributes required for the data group to generate the bidirectional mapping order. The master data attributes are used to fill in the missing node basic attributes and material basic attributes in the data group. The master data attributes are filled into the corresponding data groups, and then the bidirectional mapping order containing mutually mapped sender primary keys and receiver primary keys is constructed to maintain data traceability between heterogeneous systems. The sender primary key is used to identify the sender node in the flow node, and the receiver primary key is used to identify the receiver node in the flow node.

[0049] Preferably, the specific implementation process of the step "converting the source-end inventory object in the exclusive stage into streaming data containing the aggregation code" is as follows: After the source-end inventory object has completed the status attribute update through the optimistic lock and entered the exclusive stage, the object primary key, current version number, source identifier, hospital demand source field, material identifier field, requested quantity field, node identifier field corresponding to the target node set, and supplier replenishment order number field directly related to the replenishment flow in the source-end inventory object are read first, and the supplier replenishment order number field is used as the source field of the aggregation code. The aggregation code is not a regular classification label, but a computer-recognizable code used to group multiple source-end out-of-stock objects that need to be sent to the same supplier or the same distribution path in the same hospital-end replenishment request. In the medical device centralized distribution scenario, the aggregation code can originate from the supplier replenishment order number field, or from a combination code formed by the supplier node identifier and the hospital-end demand source field according to a preset field order. Its technical essence is to enable the subsequent distribution document generation process to generate documents according to the data flow path rather than according to individual out-of-stock records one by one. Subsequently, field normalization processing is performed on the source-end out-of-stock objects, writing the object primary key, current version number, source identifier, hospital-end demand source field, material identifier field, requested quantity field, node identifier field corresponding to the target node set, and the aggregation code into the streaming data carrier record, and configuring an exclusive status flag in the streaming data carrier record. The exclusive status flag originates from the status attribute of the source-end overstock object. It is used to filter out source-end overstock objects that have not completed exclusive control when performing aggregation processing on the streaming data according to the aggregation code, preventing unlocked source-end overstock objects from being mixed into the bidirectional mapping dispatching documents. Next, the streaming data records undergo sequential encapsulation processing, ensuring that each stream data record contains a data source field corresponding one-to-one with the source-end overstock object and a data aggregation field corresponding one-to-one with the aggregation code. The data source field is used to point back to the source-end overstock object in subsequent data groups, and the data aggregation field is used to carry the aggregation code in subsequent data groups, thereby forming streaming data that can be directly read by subsequent group processing. The technical essence of the streaming data is the intermediate transmission form of the source-end inventory object in the exclusive stage before the generation of the packing document. It does not change the meaning of the inventory occupancy of the source-end inventory object, but transforms the source-end inventory object from a static record form in the local storage pool into a data form that can continuously enter the group processing according to the aggregation code, thereby establishing a traceable correspondence between the source-end inventory object, the target node set, and the aggregation code in the streaming data.

[0050] Preferably, in the specific technical implementation of the step "perform aggregation processing on the streaming data according to the aggregation code to obtain multiple independent data groups", the aggregation code, exclusive status flag, node identifier field corresponding to the target node set, and material identifier field are read for each piece of streaming data, and status filtering processing is performed on the exclusive status flag to remove the streaming data that is not in the exclusive stage. After completing the state filtering process, the retained streaming data is written to the corresponding data group carrying record according to the aggregation code. When two streaming data carry the same aggregation code, the two streaming data are written to the same data group carrying record. When two streaming data carry different aggregation codes but the aggregation codes are configured as the same flow path on the same supplier side in the pre-configured association code table, the two streaming data are written to the same data group carrying record. The association code table is pre-configured based on the correspondence between the supplier node identifier, the hospital demand source field, and the supplier replenishment order number field. The association code table is used to provide a basis for the aggregation of data group carrying records when the aggregation codes are not completely the same but correspond to the same distribution flow path. When the aggregation codes are neither the same nor have an association code relationship, the corresponding streaming data are written to different data group carrying records. The data group is not a simple data list, but a structured intermediate object used to carry multiple stream data under the same distribution flow path. The data group includes a group header field area, a group detail field area, and a group verification field area. The group header field area records the aggregation code, the sender candidate node identifier, the receiver candidate node identifier, and the group generation time field. The group detail field area stores the material identifier field, the requested quantity field, the hospital demand source field, and the object primary key in each stream data. The group verification field area stores the current version number and the exclusive status flag, so as to re-verify whether the source-end inventory object is still in the exclusive stage before the data group enters the master data attribute completion stage. Through the above aggregation process, the data group concentrates the hospital demand, supplier flow path, and material demand information that were originally scattered in multiple source-end inventory objects into a single data group. This allows subsequent requests for master data attributes to avoid accessing each source-end inventory object individually, and instead determine the node basic attributes and material basic attributes that need to be completed at once, using the data group as a unit.The technical essence of the data grouping is thus embodied in the path-level data buffer object before the bidirectional mapping order is generated. The path-level data buffer object is composed of the group header field area, the group detail field area, and the group verification field area. Technically, the data grouping inherits the exclusive state of the streaming data and the aggregation relationship of the aggregation code, and provides a stable data boundary for the subsequent construction of the sending end primary key and the receiving end primary key, avoiding the fragmentation of multiple back-to-the-end records of the same supplier into document fragments that cannot be traced back to each other.

[0051] Preferably, the specific implementation process of the step "requesting the missing master data attributes of each data group from the external master data source via the remote call protocol" is as follows: After the data group is formed, the group header field area and group detail field area in the data group are read first to obtain the aggregation code, the sending candidate node identifier, the receiving candidate node identifier, the material identifier field, and the institute's demand source field; then, the external master data source is determined according to the preset master data access configuration record. The master data access configuration record includes a master data category field, a data open interface address field, an enable status field, a node attribute field mapping relationship, and a material attribute field mapping relationship; the master data access configuration record is pre-written into the configuration storage area by the data open interface address field, node attribute field mapping relationship, and material attribute field mapping relationship corresponding to the external master data source, and the currently callable external master data source is limited by the enable status field; when the enable status field is enabled, and the node attribute field mapping relationship covers the sending candidate node identifier and the receiving candidate node identifier in the data group, the data source pointed to by the corresponding data open interface address field is determined as the external master data source. The external master data source is essentially a stable data source for storing supplier, hospital, and material basic information. This external master data source does not participate in incremental updates of the inventory balance field, but instead provides the master data attributes required for generating the bidirectional mapping distribution documents. Subsequently, missing data detection processing is performed on the data groups. This missing data detection process reads the sender candidate node identifier and receiver candidate node identifier from the group header field area, and reads the material identifier field from the group detail field area. When a data group lacks a supplier code, account identifier, hospital node code, material code, material specification field, unit of measurement field, or batch number / expiration date associated field, the missing field is written to the master data attribute request list. The node basic attributes describe the identifiable data identity of the sender and receiver nodes across heterogeneous systems. These node basic attributes include at least the supplier code, account identifier, hospital node code, and node open interface address. The material basic attributes describe the identifiable data identity of medical device materials during distribution. These material basic attributes include at least the material code, material specification field, unit of measurement field, and batch number / expiration date associated field. After determining the master data attribute request list, a master data attribute request message is constructed according to the remote call protocol. The master data attribute request message includes the aggregation code, the sender candidate node identifier, the receiver candidate node identifier, the material identifier field, the institute-end demand source field, and the master data attribute request list. Then, the master data attribute request message is sent to the data open interface address corresponding to the data open interface address field of the external master data source, and the master data attribute return message returned by the external master data source is received.The master data attributes in the master data attribute return message correspond item by item to the master data attribute request list, thereby enabling the missing node basic attributes and material basic attributes in the data group to be located, requested, and backfilled, instead of relying on overwrite saving or subsequent supplementation. After this processing, the data group has the node data identity and material data identity required to generate the bidirectional mapping distribution document. The node data identity is provided by the node basic attributes, and the material data identity is provided by the material basic attributes, so that the bidirectional mapping distribution document can maintain the same traceable relationship of distribution flow data among the hospital, the supplier, and external collaborative nodes.

[0052] Preferably, the specific implementation process of the step "filling the master data attributes into the corresponding data group, and then constructing the bidirectional mapped loading document containing mutually mapped sending primary keys and receiving primary keys" is as follows: After receiving the master data attribute return message, first read the aggregation code, sending candidate node identifier, receiving candidate node identifier, material identifier field, node basic attribute, and material basic attribute in the master data attribute return message, and use the aggregation code, sending candidate node identifier, receiving candidate node identifier, and material identifier field to perform a corresponding lookup in multiple data groups to determine the data group corresponding to the master data attribute return message. After determining the corresponding data group, the node basic attributes are filled into the group header field area of ​​the data group, and the material basic attributes are filled into the group detail field area of ​​the data group. The node basic attributes, after entering the group header field area, are used to define the node data identity of the sending and receiving nodes in the circulation nodes across heterogeneous systems. The material basic attributes, after entering the group detail field area, are used to define the material data identity of the medical device material corresponding to the circulation node in subsequent local detail data construction and remote data object verification. After filling is completed, primary key construction processing is performed on the data group. The primary key construction processing reads the supplier code, account identifier, hospital node code, material code, hospital demand source field, object primary key, and group generation time field from the data group, and forms the sending primary key and receiving primary key according to a preset field order. The technical essence of the sending-end primary key is a composite data identifier that uniquely locates the sending-end node and sending-end details within the sending-end data domain. The sending-end primary key is formed by at least the association of supplier code, account identifier, material code, and object primary key. Similarly, the technical essence of the receiving-end primary key is a composite data identifier that uniquely locates the receiving-end node and receiving-end details within the receiving-end data domain. The receiving-end primary key is formed by at least the association of hospital-end node code, hospital-end demand source field, material code, and object primary key. Subsequently, the sending-end primary key is written into the field position corresponding to the sending-end node in the data group, and the receiving-end primary key is also written into the field position corresponding to the receiving node in the data group. Then, the bidirectional mapping distribution document is constructed based on the sending-end primary key and the receiving-end primary key. The bidirectional mapping order document includes a purchase-side replenishment order field area and a delivery-side order document field area. The purchase-side replenishment order field area records the sending-side primary key, supplier code, account identifier, material code, and requested quantity field. The delivery-side order document field area records the receiving-side primary key, hospital-side node code, hospital-side demand source field, material code, and requested quantity field. A primary key mapping field is configured between the purchase-side replenishment order field area and the delivery-side order document field area.The primary key mapping field establishes a one-to-one correspondence between the sending end primary key and the receiving end primary key, enabling the same flow node to be traced back from the sending end node to the receiving end node, and vice versa. Therefore, the bidirectional mapping order is not a typical unidirectional order record, but a data flow voucher that continuously organizes the exclusive status, aggregation code, node basic attributes, material basic attributes, sending end primary key, and receiving end primary key within the data group. This data flow voucher is carried by the bidirectional mapping order and provides field sources for subsequent parsing of the flow nodes to construct the local detailed data. It also provides a traceable data foundation for subsequent consistency retrieval and dirty data cleaning using remote data objects.

[0053] Optionally, the remote data objects retrieved from external collaboration nodes include: Read the preset system configuration file and extract the list of external collaborative nodes that are in the enabled state. The system configuration file is used to record the enabled state and data open interface address of the external collaborative nodes, and the list of external collaborative nodes is used to limit the external collaborative nodes that need to pull the remote data object. The list of external collaborative nodes is truncated using a preset slicing length to generate multiple data slices with a specified length, wherein the preset slicing length is used to limit the number of external collaborative nodes contained in each data slice; Independent execution threads are allocated to the plurality of data shards with a specified length, wherein the execution threads are used to concurrently access the external cooperating nodes in the corresponding data shards; The execution thread concurrently calls the data access interface of the external collaborative node to receive the remote data object formatted as a key-value pair structure. The data access interface is used to output the remote data object, and the key-value pair structure is used to carry the built-in fields of the remote data object.

[0054] Preferably, the specific implementation process of the step "reading the preset system configuration file and extracting the list of external collaborative nodes in the enabled state" is as follows: Before pulling the remote data object, a system configuration file corresponding to the external collaborative node is first established, and node configuration details are pre-written into the system configuration file. The node configuration details include the external collaborative node identifier, enabled state, data open interface address, remote data object category field, interface access credential index, interface return field mapping relationship, and the most recent configuration update time field. The node configuration details are used to enable the external collaborative node to be accessed directly from the system configuration file when pulling the remote data object, instead of temporarily piecing together the external collaborative node during the pulling process of the remote data object. The technical essence of the system configuration file is a structured and fixed configuration data carrier that maps the access scope, data open interface address, and interface return field mapping relationship of the external collaborative nodes. When the system configuration file is pre-configured, the supplier-side collaborative data source, upstream resource plan data source, or pending matching detailed data source connected to the institute are respectively formed into node configuration detail records, and these node configuration detail records are stored in the configuration storage area. Each supplier-side collaborative data source, upstream resource plan data source, or pending matching detailed data source is written into the node configuration detail record through its corresponding external collaborative node identifier, enabling the external collaborative node identifier to point back to the corresponding external collaborative node during the subsequent retrieval of the remote data object. In the configuration storage area, each node configuration detail record establishes a one-to-one correspondence between the external collaborative node identifier and the data open interface address, and the enabled status limits whether the external collaborative node participates in the current remote data object retrieval process. When reading the system configuration file, all node configuration details are first obtained from the configuration storage area. Then, the activation status of each node configuration details record is filtered. Node configuration details records whose activation status is indicated as accessible are written into the external collaborative node candidate list, while node configuration details records whose activation status is indicated as inaccessible are excluded from the external collaborative node candidate list.The technical essence of the "enabled state" is a status field used to control the boundary of external data access. This enabled state is not a business-level availability assessment, but rather a data switch used by the computer before executing the remote data object retrieval process to determine whether the corresponding external collaborative node should be included in the external collaborative node candidate list. In a medical device distribution scenario, when a supplier-side collaborative data source has not yet opened the source of the detailed data to be matched, or when the data open interface address corresponding to an upstream resource plan data source is under maintenance configuration, the enabled state can exclude the corresponding external collaborative node from the current remote data object retrieval process, thereby preventing invalid remote data objects from being mixed into the subsequent remote full set view. Subsequently, an address integrity check is performed on the external collaborative node candidate list, reading the data open interface address, the interface access credential index, and the interface return field mapping relationship to verify that each external collaborative node in the external collaborative node candidate list possesses the data open interface address, interface access credential index, and interface return field mapping relationship. The technical essence of the data open interface address is the network access entry point used by the external collaborative node when outputting the remote data object. This address is used to locate the output position of purchase requisition data, accounts payable data, purchase receipt data, or pending matching detail data during subsequent concurrent access. The interface access credential index is used to obtain the access authentication field when constructing the remote data object retrieval request. The interface return field mapping relationship is used to identify the built-in fields of the remote data object when receiving key-value pair structures. After the address integrity check, the retained external collaborative node candidate list is written into the external collaborative node list. This external collaborative node list thus limits the access scope for retrieving the remote data object and provides a stable data source for subsequent fragmentation and truncation according to the preset segmentation length.

[0055] Preferably, in the specific technical implementation of the step "perform fragmentation and truncation of the external collaborative node list using a preset fragmentation length to generate multiple data fragments with a specified length", the external collaborative node identifier, data open interface address, interface access credential index, and remote data object category field corresponding to each external collaborative node in the external collaborative node list are first read, and a sequence of nodes to be fragmented is formed according to the stable sorting result of the external collaborative node identifiers. The sequence of nodes to be fragmented originates from the external collaborative node list, and the sequence of nodes to be fragmented is used to maintain the access order of the external collaborative nodes during the fragmentation and truncation process, so that the same external collaborative node can fall into a stable data fragment range in different execution rounds. Subsequently, a preset sharding length is read. This preset sharding length is pre-written into the sharding control configuration record in the system configuration file. The sharding control configuration record includes a sharding length field, a concurrent access limit field, an interface timeout control field, and a failure retry count control field. The sharding length field limits the number of external collaborative nodes contained in each data shard. The concurrent access limit field limits the number of data shards that enter the access state at the same time. The interface timeout control field limits the time range for a single external collaborative node to wait for a remote response. The failure retry count control field controls the number of repeated accesses when an external collaborative node experiences an access failure. The technical essence of the preset sharding length is a boundary parameter for batch access control of the external collaborative node list. The preset sharding length is not used to change the content of the remote data object, but rather to split a large number of external collaborative nodes into multiple data shards with relatively stable access granularity, so that when allocating execution threads for the data shards, all external collaborative nodes will not be pushed into the same execution thread at once. When performing the sharding, the continuously arranged external collaborative nodes are read from the beginning of the node sequence to be sharded, and the first data shard is formed according to the preset sharding length. When the number of nodes in the first data shard reaches the limit of the preset sharding length, the reading continues from the next external collaborative node in the node sequence to be sharded that has not yet entered a data shard, so as to form subsequent data shards. When the number of remaining external collaborative nodes in the node sequence to be sharded is less than the preset sharding length, the remaining external collaborative nodes are written into the last data shard.The essence of the sharding technique is to perform continuous interval partitioning on the external collaborative node list, resulting in multiple data shards of a specified length. Each data shard includes a shard sequence number field, a shard node detail field, a shard access status field, and a shard retry status field. The shard node detail field stores the external collaborative node identifier, the data open interface address, the interface access credential index, and the remote data object category field. The shard access status field records whether the data shard has entered the access state during subsequent concurrent accesses. The shard retry status field records the re-access status of the data shard after an access failure. Through sharding, the external collaborative node list is converted into multiple independently schedulable data shards. These independently schedulable data shards are further used as allocation objects for execution threads, enabling the retrieval process of the remote data object to enter the concurrent access phase in stable batches of the data shards, rather than waiting for access sequentially as a single long list of external collaborative nodes. Since the data shard inherits the external collaborative node identifier, the data open interface address, the interface access credential index, and the remote data object category field from the external collaborative node list, the data shard, after being subsequently allocated to the execution thread, can directly provide the access entry point, access authentication source, and remote data object category source required for the remote data object retrieval request.

[0056] Preferably, the specific implementation process of step "allocating independent execution threads to the multiple data shards with specified lengths" is as follows: After the multiple data shards are formed, the shard sequence number field, shard node details field, shard access status field, and shard retry status field of each data shard are read first. Data shards that have not yet entered the access state are then filtered according to the shard access status field to form a queue of data shards to be accessed. The queue of data shards to be accessed originates from the multiple data shards and is used to ensure that subsequent execution threads only receive data shards that have not yet been accessed, avoiding duplicate allocation of data shards that have already entered the access state. Subsequently, an execution thread allocation record is generated according to the concurrent access limit field in the shard control configuration record. The execution thread allocation record includes an execution thread identifier, a shard sequence number field, an execution start time field, an execution status field, an access completion flag field, and an exception return record field. The technical essence of the execution thread is an independent access task channel configured for a data shard. The execution thread does not modify the content of the external cooperating nodes in the data shard; instead, it reads the shard node detail field in the data shard and accesses the corresponding external cooperating node according to the data open interface address recorded in the shard node detail field. When allocating independent execution threads to multiple data shards of a specified length, a binding relationship is established between one execution thread and one data shard, and this binding relationship is written into the execution thread allocation record. When the number of data shards in the queue of data shards to be accessed is greater than the number of execution threads that can be allocated in the same round, the execution thread is allocated to the data shard in the previous round first, and after the execution thread in the previous round completes its access, the execution thread is allocated to the subsequent data shards. The independent execution threads are manifested in that different execution threads separately store the execution thread allocation record, the interface access credential index, the shard access status field, and the exception return record field, and do not share the access status of a single external cooperating node or a single remote data object receiving buffer. Through the aforementioned binding relationship, the execution thread can concurrently access the external collaborative nodes in the corresponding data shard. The technical essence of this concurrent access is that multiple execution threads read the data open interface addresses in different data shards within the same access cycle and send remote data object retrieval requests to the corresponding external collaborative nodes. Since the number of external collaborative nodes is limited by the preset sharding length, the execution thread only processes the corresponding data shard during access. The number and range of remote data object retrieval requests are limited by the shard node detail field of the data shard.Therefore, a one-to-one or round-robin technical relationship is formed between the execution thread, the data shards, and the external collaborative nodes. This allows purchase requisition data, accounts payable data, purchase receipt data, and matching detail data to enter the subsequent receiving and processing process according to the granularity of the data shards. It also enables the subsequent construction of the remote full set view to trace the access source of each remote data object based on the shard sequence number field. The access source is jointly represented by the execution thread identifier, the shard sequence number field, and the external collaborative node identifier. After being written into the remote data object receiving buffer, the access source continues to participate in the source association processing between the remote data object and the remote full set view.

[0057] Preferably, the specific implementation process of the step "driving the execution thread to concurrently call the data open interface of the external collaborative node and receive the remote data object formatted as a key-value pair structure" is as follows: After the execution thread is bound to the data shard, the execution thread first reads the shard node detail field in the corresponding data shard to obtain the external collaborative node identifier, data open interface address, interface access credential index, and remote data object category field for each external collaborative node; then, it obtains the access authentication field according to the interface access credential index, and writes the external collaborative node identifier, the remote data object category field, the access authentication field, and the current synchronization time range field into the remote data object retrieval request. The access authentication field originates from the interface access credential index and is used to identify the source of the current access when calling the data open interface. The remote data object retrieval request is used to declare to the external collaborative node the range of purchase application data, accounts payable data, purchase receipt data, or pending matching detail data that needs to be read this time. The current synchronization time range field originates from the synchronization time stamp saved after the previous round of remote data object retrieval is completed. The synchronization time stamp is generated after the previous round of remote data objects are written into the remote data object receiving buffer. The current synchronization time range field is used to limit the remote data objects output by the data open interface that are related to the current allocation flow verification. Next, the execution thread calls the data opening interface of the external collaborative node based on the data opening interface address, and sends the remote data object retrieval request to the data opening interface. The technical essence of the data opening interface is that the external collaborative node provides a controlled output entry point for the remote data object to the local machine. The data opening interface reads the corresponding purchase requisition data, accounts payable data, purchase receipt data, or matching details data according to the category field of the remote data object, and converts the read data into a key-value pair structure before returning it. The technical essence of the key-value pair structure is a data carrier format that establishes a correspondence between field names and field contents. The key-value pair structure is used to carry the built-in fields of the remote data object. The built-in fields include at least a requester field, a target field, a document number field, a suffix field, a line indicator field, a material code field, a quantity field, a batch number field, an expiration date field, and a data source field. The requester field, the target field, the document number field, the suffix field, and the line indicator field are subsequently used to generate the feature fingerprint. The material code field, the quantity field, the batch number field, and the expiration date field are subsequently used for field-level verification with the local detailed data. The data source field is subsequently used to point back the remote data object to the corresponding external collaborative node.Upon receiving the key-value pair structure, the execution thread first performs a field integrity check on the key-value pair structure. The field integrity check reads the requester field, the target field, the order number field, the suffix field, and the line indicator field, and determines whether the requester field, the target field, the order number field, the suffix field, and the line indicator field all exist. When the key-value pair structure passes the field integrity check, the key-value pair structure is written into the remote data object receiving buffer, and the execution thread identifier, the shard sequence number field, and the external cooperating node identifier are associated and written into the remote data object receiving buffer to form the remote data object. The remote data object thus carries data content, access source, and shard source. The data content originates from the key-value pair structure, the access source originates from the execution thread identifier and the external collaborative node identifier, and the shard source originates from the shard sequence number field. The data content, access source, and shard source jointly participate in the subsequent construction of the remote full set view, enabling the unified reading of data from different external collaborative nodes according to the same key-value pair structure when forming the remote full set view based on the remote data object. This also provides a directly accessible field foundation for subsequently concatenating the built-in fields of the remote data object to obtain the feature fingerprint.

[0058] Optionally, a feature fingerprint is obtained by concatenating the built-in fields of the remote data object, and the local detailed data is retrieved using the feature fingerprint, including: Extract the requester field, target field, order number field, suffix field, and line indicator field from the remote data object, wherein the requester field, target field, order number field, suffix field, and line indicator field are collectively used as the built-in fields for generating the feature fingerprint; The requester field, the target field, the order number field, the suffix field, and the line indicator field are concatenated according to a preset sorting rule to generate the feature fingerprint with a unique identifier. The preset sorting rule is used to limit the order of the requester field, the target field, the order number field, the suffix field, and the line indicator field in the string concatenation process. The local cache space is used to perform a lookup operation using the feature fingerprint to locate the local detailed data with consistent characteristics. The local cache space is used to store the local detailed data constructed by the flow nodes of the bidirectional mapping order. The consistent characteristics are used to characterize that the local detailed data and the remote data object have the same feature fingerprint.

[0059] Preferably, the specific implementation process of the step "extracting the requester field, target field, order number field, suffix field, and line indicator field from the remote data object" is as follows: After the remote data object has been returned by the external collaborative node through the data open interface and written into the remote data object receiving buffer, the key-value pair structure of the remote data object is first read, and the requester field, target field, order number field, suffix field, and line indicator field are located according to the field names in the key-value pair structure. The technical essence of the requester field is the request-side node identifier of the remote data object on the external collaborative node side. The request-side node identifier is used to distinguish which request-side node the same purchase application data, accounts payable data, purchase receipt data, or pending matching detail data originates from; the technical essence of the target field is the receiving-side node identifier of the remote data object on the external collaborative node side. The receiving-side node identifier is used to distinguish which receiving-side node the data under the same order number field points to. Since procurement application data, accounts payable data, procurement receipt data, or matching details data in medical device distribution scenarios will flow multiple times between the hospital, the supplier, and external collaborative nodes, the order number field alone cannot distinguish between different requesting nodes and different receiving nodes. Therefore, it is necessary to extract both the requesting party field and the target party field to enable the remote data object to establish a node correspondence with the sending and receiving nodes in the subsequent local details data. The technical essence of the order number field is the document backbone field corresponding to the remote data object on the external collaboration node side. The order number field is used to carry the document backbone field to which the purchase requisition data, accounts payable data, purchase receipt data, or detailed data to be matched belong. The technical essence of the suffix field is the document branch field attached to the order number field. The suffix field is used to distinguish different document branch fields under the same order number field due to splitting, backhauling, or multiple rounds of collaboration. The technical essence of the row indicator field is the detailed row position field of the remote data object under the same order number field and the same suffix field. The row indicator field is used to distinguish different medical device material details within the same document branch field. After extracting the requester field, the target field, the order number field, the suffix field, and the row indicator field, field null value checks and field format normalization processing are performed on the requester field, the target field, the order number field, the suffix field, and the row indicator field respectively to form a fingerprint candidate field group.The fingerprint candidate field group originates from the built-in fields of the remote data object and serves as the direct field source for generating the feature fingerprint in subsequent string concatenation processing. The field null value check is used to exclude remote data objects lacking the requester field, the target field, the order number field, the suffix field, or the line indicator field. The field format standardization process is used to unify the character encoding and field boundary standards of each field in the fingerprint candidate field group, thereby avoiding confusion of multiple lines of details caused by relying solely on a single order number field to locate the remote data object.

[0060] Preferably, in the specific implementation of the step "performing string concatenation processing on the requester field, the target field, the order number field, the suffix field, and the line indicator field according to a preset sorting rule to generate the feature fingerprint with a unique identifier", a pre-configured fingerprint field order record is first read. This fingerprint field order record includes the order positions of the requester field, the target field, the order number field, the suffix field, and the line indicator field. This fingerprint field order record is used to fix the arrangement order of the requester field, the target field, the order number field, the suffix field, and the line indicator field in the string concatenation processing. The technical essence of the preset sorting rule is a field arrangement constraint used to eliminate ambiguity in field concatenation. The preset sorting rule does not change the field content of the requester field, the target field, the order number field, the suffix field, and the line indicator field, but rather ensures that different remote data objects use the same field order when generating the feature fingerprint. The preset sorting rules are arranged according to the technical level of remote document positioning during configuration. First, the requester field, used to define the requesting node identifier, is arranged; then, the target field, used to define the receiving node identifier, is arranged; next, the document number field, used to define the document trunk field, is arranged; then, the suffix field, used to define the document branch field, is arranged; and finally, the row indicator field, used to define the detail row position field, is arranged. The reason for this arrangement is that the requesting node identifier and the receiving node identifier are used to first determine the heterogeneous node flow range of the remote data object; the document trunk field and the document branch field are used to further determine the document range to which the remote data object belongs; and the detail row position field is used to finally determine the medical device material detail position corresponding to the remote data object. This arrangement order, from heterogeneous node flow range to document range and then to medical device material detail position, is consistent with the subsequent search path for retrieving the local detail data using the feature fingerprint. When performing the string concatenation process, the fingerprint candidate field group is first read, and the requester field, the target field, the order number field, the suffix field, and the line indicator field in the fingerprint candidate field group are processed to perform field format normalization to remove invalid whitespace before and after the field content and unify the character encoding of the field content; then, the requester field, the target field, the order number field, the suffix field, and the line indicator field are read sequentially according to the preset sorting rules, and a preset separator is written between adjacent field contents to avoid boundary ambiguity after the beginning and end of two field contents are joined.The preset separator identifier is pre-written into the fingerprint field sequence record and participates in the string concatenation process together with the preset sorting rule, so that the arrangement order of the field content and the boundary between adjacent field content have a reproducible concatenation interface. After the string concatenation process is completed, the concatenated fingerprint string is used as the feature fingerprint. The feature fingerprint is jointly characterized by the requester field, the target field, the order number field, the suffix field, and the row indicator field. The feature fingerprint is used as the index value for the consistency retrieval relationship when retrieving the local detailed data in the future. Since the feature fingerprint simultaneously contains the requester node identifier, the receiver node identifier, the document trunk field, the document branch field, and the detailed row position field, the feature fingerprint can convert the purchase application data, accounts payable data, purchase receipt data, or unmatched detailed data from the external collaborative node side into a comparable string identifier, so that a stable correspondence between the remote data object and the local detailed data is formed.

[0061] Preferably, the specific implementation process of the step "using the feature fingerprint to perform a lookup operation in the local cache space to locate the local detailed data with consistent characteristics" is as follows: After generating the feature fingerprint, the local detailed index record in the local cache space is read first. The local detailed index record is synchronously formed when the local detailed data is constructed by the flow node of the bidirectional mapping distribution document. The technical essence of the local detailed data is the distribution detail content formed by the flow node on the local side. The local detailed data at least carries the sending node, receiving node, local document backbone field, local document branch field, local detail line position field, local medical device material field, and local quantity field. The sending node and the receiving node originate from the flow node in the bidirectional mapping distribution document. The local document backbone field, local document branch field, and local detail line position field originate from the local detail construction process corresponding to the bidirectional mapping distribution document. The local medical device material field and the local quantity field are used for subsequent field-level verification with the material code field and quantity field in the remote data object. The technical essence of the local cache space is a temporary retrieval space used to store the local detailed data and the local detailed index records. The local cache space does not replace the local detailed data in the database, but rather provides a lookup entry point with low access overhead when performing consistency retrieval between the remote data object and the local detailed data. When constructing the local detailed index records, the following fields are first read from the local detailed data: the local requester field corresponding to the requester field, the local target field corresponding to the target field, the local order number field corresponding to the order number field, the local suffix field corresponding to the suffix field, and the local line indicator field corresponding to the line indicator field. Specifically, the local requester field corresponds to the sending node, the local target field corresponds to the receiving node, the local order number field corresponds to the local document trunk field, the local suffix field corresponds to the local document branch field, and the local line indicator field corresponds to the local detailed line position field. Subsequently, string concatenation processing is performed on the local requester field, the local destination field, the local order number field, the local suffix field, and the local line indicator field according to the same preset sorting rule to form a local detail feature fingerprint. The local detail feature fingerprint and the local detail data identifier of the local detail data are then written into the local detail index record. When performing a search operation in the local cache space using the feature fingerprint, the feature fingerprint is used as the search key to search for the existence of the same local detail feature fingerprint in the local detail index record. When the same local detail feature fingerprint is found, the local detail data identifier is read, and the corresponding local detail data is located based on the local detail data identifier.The reason for using the feature fingerprint to perform the search operation is that the feature fingerprint combines multiple built-in fields into a stable index value, so that the remote data object does not need to scan all the local detail data field by field, but can directly locate the candidate local detail data through the local detail index record; at the same time, the field source of the feature fingerprint corresponds one-to-one with the field source of the local detail feature fingerprint, so that the search process between the remote data object and the local detail data can be carried out around the same field scope, reducing the false association caused by differences in field naming or duplicate order numbers.

[0062] Preferably, the specific implementation process of step "the consistency feature is used to characterize that the local detailed data and the remote data object have the same feature fingerprint" is as follows: After locating the candidate local detailed data through the feature fingerprint, the requester field, the target field, the order number field, the suffix field, and the line indicator field in the remote data object are read first. Then, the local requester field corresponding to the requester field, the local target field corresponding to the target field, the local order number field corresponding to the order number field, the local suffix field corresponding to the suffix field, and the local line indicator field corresponding to the line indicator field in the candidate local detailed data are read. Subsequently, the requester field, the target field, the order number field, the suffix field, and the line indicator field are concatenated according to the preset sorting rule to form the feature fingerprint again. The local requester field, the local target field, the local order number field, the local suffix field, and the local line indicator field are concatenated according to the same preset sorting rule to form the local detailed feature fingerprint again. An equality check is performed between the feature fingerprint and the local detail feature fingerprint. When the feature fingerprint and the local detail feature fingerprint are identical, the candidate local detail data is marked as having a consistency feature. The technical essence of this consistency feature is not a direct judgment of whether the quantities of medical device materials are the same, nor is it an evaluation of the completeness of the remote data object's content. Rather, it characterizes the field-level correspondence between the remote data object and the local detail data in the request-side node identifier, the receiving-side node identifier, the document backbone field, the document branch field, and the detail row position field, indicating that they belong to the same distribution flow detail. The reason for requiring the local detailed data and the remote data object to have the same feature fingerprint is that when performing an existence probe in the remote full view, it is necessary to first confirm whether the remote data object and the local detailed data point to the same distribution flow detail, and then determine whether the local detailed data has a corresponding remote data. If the same feature fingerprint is missing as a consistency retrieval relationship, remote withdrawals, document branch changes, or multiple rows of medical device material details under the same order number field are easily misjudged as the same data. After forming the local detailed data with consistency features, the local detailed data identifier, the feature fingerprint, the local detailed feature fingerprint, the data source field of the remote data object, and the consistency feature marker are written into the consistency retrieval record. The consistency feature marker comes from the equality judgment result of the feature fingerprint and the local detailed feature fingerprint, and the consistency feature marker is used to identify that the local detailed data and the remote data object have formed the consistency retrieval relationship in the subsequent existence probe.The consistency retrieval record originates from the equality judgment result between the feature fingerprint and the local detail feature fingerprint. The consistency retrieval record is used to provide a traceable matching basis when constructing the remote full set view and performing the existence detection. This enables the field-level correspondence between the remote data object and the local detail data to be traced back along the consistency retrieval record when deleting the local detail data, forming the discarded record, and updating the bimodal inventory data record based on the change value.

[0063] Optionally, when no remote data object corresponding to the local detailed data is detected in the remote full set view formed based on the remote data object, and the local detailed data exists, deleting the local detailed data includes: Based on the remote data objects returned by the external collaborative nodes, a remote full set view is constructed for the remote data objects, wherein the remote full set view is used to summarize the remote data objects returned by different external collaborative nodes; Extract the identity identifier of the local detailed data, and use the identity identifier to perform an existence detection in the remote full set view. The identity identifier is derived from the field combination in the local detailed data that corresponds to the feature fingerprint. The existence detection is used to determine whether there is a remote data object in the remote full set view that corresponds to the local detailed data. When the existence probe returns a no-hit result, a withdrawal trigger instruction is generated for the local detailed data. The no-hit result is used to indicate that there is no remote data object corresponding to the local detailed data in the remote full set view. The withdrawal trigger instruction is used to trigger the deletion process of the local detailed data. In response to the withdrawal trigger command, the occupancy constraint attribute associated with the local detailed data is modified. Subsequently, the local detailed data is physically erased at the database level to clean up the time difference dirty data generated between heterogeneous systems. The occupancy constraint attribute is used to characterize the inventory occupancy relationship between the local detailed data and the bimodal inventory data record, and the time difference dirty data is used to characterize the inconsistent data between the local detailed data and the remote data object caused by the synchronization time difference.

[0064] Preferably, the specific implementation process of the step "constructing a remote full set view for the remote data object based on the remote data object returned by the external collaborative node" is as follows: After the execution thread writes the remote data object into the remote data object receiving buffer, the execution thread identifier, shard number field, external collaborative node identifier, data source field, key-value pair structure, and built-in fields associated and saved in the remote data object receiving buffer are read first, and a unified field caliber processing is performed on the remote data objects returned by different external collaborative nodes to form a remote full set view carrying record. The unified field caliber processing does not change the substantive content of the remote data object. Instead, based on the field names in the key-value pair structure, it writes the requester field, the target field, the order number field, the suffix field, the line indicator field, the material code field, the quantity field, the batch number field, the expiration date field, and the data source field into the corresponding field positions in the remote full set view carrying record. This allows purchase requisition data, accounts payable data, purchase receipt data, or pending matching detail data from different external collaborative nodes to participate in subsequent existence detection according to the same field reading caliber. Subsequently, source partitioning encapsulation processing is performed on the remote full set view carrying record. Remote data objects corresponding to the same external collaborative node identifier are written into the same source partition, and remote data objects corresponding to different external collaborative node identifiers are written into different source partitions. The source partition is used to retain the access source relationship between the remote data object and the external collaborative node. This access source relationship is used to indicate the return source of the remote data object in the subsequent existence detection record. After completing the source partition encapsulation process, the requester field, target field, order number field, suffix field, and row indicator field of each remote data object are read. String concatenation is then performed according to the pre-configured preset sorting rules to form the remote full set view index field, which is then written into the remote full set view carrying record. The remote full set view index field is used for subsequent item-by-item matching with the identity identifier. The remote full set view index field and the identity identifier are generated using the same field combination and the same preset sorting rules, enabling the remote full set view to participate in subsequent existence detection with a unified index caliber. The technical essence of the remote full set view is a unified retrieval view across external collaborative nodes established for the remote data object. The remote full set view is not a new order document, nor does it change the original field meaning of the remote data object. Instead, it collects and encapsulates the remote data objects returned by different external collaborative nodes according to a unified field standard, access source relationship, and remote full set view index field, so that it can be determined in the same remote full set view whether the local detailed data still has the corresponding remote data object.In medical device distribution scenarios, there are situations where purchase application data, accounts payable data, purchase receipt data, or pending matching detail data are withdrawn from external collaborative nodes, but the local side still retains the local detail data. The remote full set view can form a searchable data judgment basis for all the remote data objects that are actually returned. The data judgment basis is used to determine whether the local detail data has lost the corresponding remote data object when identifying dirty data due to time difference in the subsequent process.

[0065] Preferably, in the specific technical implementation of the step "extracting the identity identifier of the local detailed data and performing an existence detection in the remote full set view using the identity identifier", the local detailed data that is still in a valid occupied state in the local cache space or database is first read, and the field combination corresponding to the feature fingerprint is extracted from the local detailed data. The field combination includes a local requester field corresponding to the requester field, a local target field corresponding to the target field, a local order number field corresponding to the order number field, a local suffix field corresponding to the suffix field, and a local line indicator field corresponding to the line indicator field; wherein, the local requester field is used to correspond to the sending node, the local target field is used to correspond to the receiving node, the local order number field is used to correspond to the local document trunk field, the local suffix field is used to correspond to the local document branch field, and the local line indicator field is used to correspond to the local detailed line position field. After extracting the field combination, the field combination undergoes field format normalization processing with the same caliber as the feature fingerprint. Then, according to the preset sorting rules, string concatenation processing is performed on the local requester field, the local target field, the local order number field, the local suffix field, and the local line indicator field to form the identity identifier of the local detailed data. The technical essence of this identity identifier is a composite retrieval identifier used by the local detailed data on the local side to participate in remote existence determination. This identity identifier does not regenerate the local detailed data; rather, it converts the field combination in the local detailed data corresponding to the feature fingerprint into a field combination identifier that can be compared with the index field of the remote full set view. Subsequently, an existence probe is performed in the remote full-set view using the identity identifier. The existence probe first reads the remote full-set view index field from the remote full-set view's carrying record, and then performs a match between the identity identifier and each of the remote full-set view index fields. When a remote full-set view index field identical to the identity identifier exists, a hit result is generated, and the hit remote data object, the external collaborative node identifier, and the data source field are written to the existence probe record. When no remote full-set view index field identical to the identity identifier exists, a miss result is generated, and the identity identifier, the local detailed data identifier, the existence probe time field, and the probe source field are written to the existence probe record. The existence probe record originates from the match results between the identity identifier and the remote full-set view index fields. When generating a hit result, the existence probe record is used to retain the access source relationship of the remote data object; when generating a miss result, the existence probe record is used to provide a basis for judging the subsequent generation of a retraction trigger command.The reason for performing existence detection through the identity identifier is that whether the local detailed data needs to be deleted cannot be determined solely based on the existence of the local record. Instead, it is necessary to determine whether the remote data object corresponding to the local detailed data still exists in the current remote full view. The identity identifier unifies the sending node, receiving node, local document trunk field, local document branch field, and local detailed row position field of the local detailed data into a searchable data identifier, enabling the existence detection to identify from the remote full view whether the local detailed data has lost its remote correspondence.

[0066] Preferably, the specific implementation process of step "generating a withdrawal trigger instruction for the local detailed data when the existence probe returns a miss result" is as follows: After writing the miss result into the existence probe record, first read the identity identifier, local detailed data identifier, existence probe time field, and probe source field corresponding to the miss result, and then read the corresponding local detailed data according to the local detailed data identifier. After reading the local detailed data, further read the occupancy constraint attribute, data generation source field, last remote matching time field, and local detailed status field in the local detailed data to form a withdrawal judgment input record. The withdrawal judgment input record comes from the miss result and the local detailed data. The withdrawal judgment input record is used to retain the judgment basis before generating the withdrawal trigger instruction, avoiding direct entry into deletion processing based on only one missing field. Subsequently, withdrawal condition determination processing is performed on the withdrawal determination input record. When the miss result indicates that there is no index field in the remote full set view that is the same as the identity identifier, and the local detail status field still indicates that the local detail data exists, and the occupancy constraint attribute still indicates that the local detail data has an inventory occupancy relationship with the bimodal inventory data record, the local detail data is determined to be local detail data to be withdrawn. The technical essence of the local detail data to be withdrawn is that it is still retained on the local side, but the corresponding remote data object's allocation details no longer exist in the current remote full set view. In the medical device distribution scenario, the local detail data to be withdrawn corresponds to the purchase application data, accounts payable data, purchase receipt data, or pending matching detail data on the external collaborative node side, which has been withdrawn, reversed, or is no longer returned, while the local side still has an occupancy record. After the local detailed data to be withdrawn is generated, a withdrawal trigger instruction is generated for the local detailed data. The withdrawal trigger instruction includes a local detailed data identifier, an identity identifier, a miss result, a withdrawal judgment input record, an occupancy constraint attribute, an instruction generation time field, and a subsequent deletion processing flag. The technical essence of the withdrawal trigger instruction is to convert the miss result of the existence probe into executable local cleansing control information. The withdrawal trigger instruction does not directly change the bimodal inventory data record, but triggers subsequent modifications to the occupancy constraint attribute of the local detailed data, database-level physical erasure, and the formation of discarded records. The subsequent deletion processing flag originates from the withdrawal condition judgment process and is used to indicate that the local detailed data needs to undergo database-level physical erasure processing when responding to the withdrawal trigger instruction.By setting the withdrawal trigger command, a traceable command association can be established between the existence detection and deletion process. This allows subsequent deletion of local detailed data to trace back the judgment basis of the miss result, the identity identifier, and the remote full set view along the withdrawal trigger command, thereby avoiding the deletion of local detailed data without a basis in the scenario of heterogeneous data synchronization time difference.

[0067] Preferably, in the specific technical implementation of the step "responding to the withdrawal trigger instruction, modifying the occupancy constraint attribute associated with the local detailed data, and then physically erasing the local detailed data at the database level to clean up the dirty data generated by the time difference between heterogeneous systems", the local detailed data identifier, identity identifier, miss result, withdrawal judgment input record, and occupancy constraint attribute in the withdrawal trigger instruction are read first, and the corresponding local detailed data is locked based on the local detailed data identifier. After locking the local detailed data, the occupancy constraint attribute in the local detailed data is read, and the occupancy constraint attribute is modified from the occupancy valid state to the occupancy withdrawal state, forming an occupancy withdrawal record. The technical essence of the occupancy constraint attribute is the inventory occupancy relationship field between the local detailed data and the bimodal inventory data record. The occupancy constraint attribute characterizes whether the local detailed data still participates in the calculation of local and collaborative inventory status occupancy in the bimodal inventory data record. When the occupancy constraint attribute is still in an effective occupancy state, the local detailed data continues to affect the inventory occupancy content of the bimodal inventory data record. When the occupancy constraint attribute is modified to an occupancy withdrawal state, the local detailed data is no longer a valid source for subsequent inventory occupancy calculations. Subsequently, after the occupancy withdrawal record is formed, a database-level physical erasure process is performed on the local detailed data. This physical erasure process locates the data row containing the local detailed data based on its identifier and deletes the data row containing the local detailed data. Simultaneously, the requester field, target field, order number field, suffix field, row indicator field, material code field, quantity field, batch number field, expiration date field, identity identifier, and occupancy withdrawal record of the deleted local detailed data are written into a discard record. The discarded records originate from the deleted local detailed data and the occupancy withdrawal records. These discarded records are used to provide information on inventory occupancy changes when extracting change values ​​later. The determination process for time-difference dirty data uses the miss results, the remote full set view, and the local detailed data as judgment criteria simultaneously: when the remote full set view does not have an index field with the same identity identifier, but the local detailed data still exists on the local side, and the occupancy constraint attribute of the local detailed data still indicates an inventory occupancy relationship with the bimodal inventory data record, the local detailed data is determined to be time-difference dirty data. The technical essence of time-difference dirty data is that the external collaborative node no longer returns the corresponding remote data object, but the local side still retains and continues to occupy the historical residual data of the bimodal inventory data record; if the historical residual data is not deleted, the local inventory status and collaborative inventory status in the bimodal inventory data record will continue to be affected by the local detailed data that has lost its remote correspondence.By first modifying the occupancy constraint attribute in response to the withdrawal trigger instruction, then physically erasing the local detailed data at the database level, and writing the deletion source into the discard record, it is possible to trace the cause of the time difference dirty data when performing incremental updates on the bimodal inventory data record based on the change value in the discard record.

[0068] Optionally, extracting the changed values ​​from the discarded records formed by deleting the local detailed data, and performing incremental updates on the bimodal inventory data records based on the changed values ​​using the database row-level locking mechanism includes: Construct a structured query statement containing independent write instructions and superimposed calculation instructions, wherein the structured query statement is used to complete the retrospective writing of the discarded records and the incremental update of the bimodal inventory data records in the same database execution context; Execute the independent write instruction to write the change value into an independent operation flow table to generate a traceability log. The independent write instruction is used to write the change value in the discarded record into the operation flow table. The operation flow table is used to record the inventory change process caused by the deletion of the local detailed data. The traceability log is used to trace the source of the change value. Executing the overlay calculation instruction triggers the database row locking mechanism to perform an exclusive lock on the bimodal inventory data record. Subsequently, the change value is directly added to the balance field of the bimodal inventory data record in the internal calculation domain of the structured query statement. The overlay calculation instruction is used to update the bimodal inventory data record based on the change value, and the balance field is used to record the inventory balance result in the bimodal inventory data record.

[0069] Preferably, the specific implementation process of step "constructing a structured query statement containing independent write instructions and superimposed calculation instructions" is as follows: After the discarded record has been formed by deleting the local detailed data, first read the local detailed data identifier, identity identifier, occupancy withdrawal record, material code field, quantity field, batch number field, expiration date field, requester field, target field, data source field, and deletion time field from the discarded record, and extract the change value based on the quantity field in the discarded record and the occupancy withdrawal record. The technical essence of the change value is the quantity change data that needs to be released from the inventory occupancy relationship after the local detailed data is deleted. The change value is not a recalculated inventory balance result, but rather the inventory occupancy change content read from the discarded record; the change value will subsequently be entered into the operation log table and the bimodal inventory data record respectively, so that the traceability log and the inventory balance result adopt the same quantity source. Subsequently, an inventory location condition record is constructed based on the material code field, batch number field, expiration date field, requester field, target field, data source field, and deletion time field in the discarded record. This inventory location condition record is used to locate the data rows in the bimodal inventory data record that need to be updated. Specifically, the material code field forms the material dimension in the inventory location condition record; the batch number and expiration date fields form the batch number-expiration date inventory dimension; the requester and target field form the hospital-side node dimension and supplier node dimension; the deletion time field forms the business month-year inventory dimension; and the data source field makes the inventory location condition record point back to the data source of the discarded record. The inventory location condition record combines the business month-year inventory dimension, batch number-expiration date inventory dimension, hospital-side node dimension, supplier node dimension, and material dimension required for both local and collaborative inventory statuses within the same location condition, enabling the bimodal inventory data record to simultaneously reflect both local and collaborative inventory occupancy and release. After the inventory location condition record is generated, a structured query statement is constructed based on the discarded record, the change value, and the inventory location condition record. The structured query statement includes independent write instructions and overlay calculation instructions. The technical essence of the independent write instruction is an insert-type data write instruction for the operation log. The independent write instruction is used to write the local detailed data identifier, identity identifier, occupancy withdrawal record, change value, material code field, batch number field, expiration date field, and data source field from the discarded record into the operation log, so that the source of the change value can be traced back through the traceability log.The technical essence of the overlay calculation instruction is an incremental data update instruction for the bimodal inventory data record. This instruction locks the data row to be updated based on the inventory location condition record and accumulates the change value to the balance field within the internal calculation domain of the structured query statement. The data row to be updated originates from the location result of the bimodal inventory data record by the inventory location condition record, and is subsequently exclusively locked by the database row locking mechanism. The structured query statement places the independent write instruction and the overlay calculation instruction in the same database execution context, ensuring that the retrospective write of the discarded record and the incremental update of the bimodal inventory data record are executed around the same change value. This differs from the previous approach of first querying the inventory balance result, then calculating on the application side, and finally overwriting and saving, thereby reducing the probability of intermediate state inconsistencies when deleting local detailed data during high concurrency.

[0070] Preferably, in the specific technical implementation of the step "execute the independent write instruction to write the changed value into an independent operation flow table to generate a traceability log", after the structured query statement enters the same database execution context, the independent write instruction is executed first, and the local detailed data identifier, identity identifier, withdrawal trigger instruction, occupation withdrawal record, changed value, material code field, quantity field, batch number field, expiration date field, requester field, target field, data source field, and deletion time field in the discarded record are read according to the independent write instruction. Subsequently, the above fields are written into the operation flow table according to the preset operation flow table field criteria to form a traceability log. The operation flow table field criteria are pre-configured in the table structure of the operation flow table. The operation flow table field criteria are used to limit the field position corresponding to the field in the discarded record when it enters the operation flow table, so that the traceability log can carry the source content of the discarded record according to the fixed field position. The technical essence of the operation log is an inventory change process record table independent of the bimodal inventory data record. The operation log does not carry inventory balance results, but rather the inventory change process caused by the deletion of local detailed data. The reason for separating the operation log from the bimodal inventory data record is that the bimodal inventory data record stores the local inventory status and the collaborative inventory status, while the operation log stores the source of the change value formed after each deletion of local detailed data, allowing subsequent lookup of the discarded record corresponding to the change value along the traceability log. The technical essence of the traceability log is a structured record in the operation log corresponding to a single traceable write of a discarded record. The traceability log includes a traceability log identifier, discarded record identifier, local detailed data identifier, identity identifier, withdrawal trigger instruction identifier, occupied withdrawal record identifier, change value, material code field, batch number field, expiration date field, and deletion time field. The traceability log identifier is used to distinguish different traceability logs; the discarded record identifier is used to refer back to the discarded record; the withdrawal trigger instruction identifier is used to refer back to the withdrawal trigger instruction that triggered the deletion of the local detailed data; the occupancy withdrawal record identifier is used to refer back to the basis for modifying the occupancy constraint attribute from an occupancy valid state to an occupancy withdrawal state; and the change value is used for subsequent source verification with the incremental update content in the overlay calculation instruction. When executing the independent write instruction, the change value is not written to the balance field of the bimodal inventory data record, but is first written to the change value field of the operation flow table to form a traceable data source record; subsequently, the traceability log identifier is retained in the same database execution context and serves as a traceability association field when the overlay calculation instruction is executed subsequently.By executing the independent write instruction first, the change value has a traceable source path before entering the incremental update of the bimodal inventory data record. Even if it is necessary to check the change of a certain inventory balance result later, it is possible to return to the discard record, the occupancy withdrawal record and the withdrawal trigger instruction through the traceability log, so that there is a continuous data connection between the local detailed data deletion process and the incremental update of the bimodal inventory data record.

[0071] Preferably, the specific implementation process of step "execute the overlay calculation instruction and trigger the database row locking mechanism to perform exclusive locking on the bimodal inventory data record" is as follows: After the independent write instruction completes the writing of the traceability log, the overlay calculation instruction continues to be executed in the same database execution context, and the overlay calculation instruction reads the inventory location condition record, the change value, and the traceability log identifier. The overlay calculation instruction locates the data row to be updated in the bimodal inventory data record that matches the material code field, batch number field, expiration date field, requester field, target field, and business month-year inventory dimension according to the inventory location condition record, and triggers the database row locking mechanism to perform exclusive locking on the located data row to be updated. The technical essence of the database row locking mechanism is a concurrent access control mechanism applied by the database to the updated data row when executing an update-type structured query statement. The database row locking mechanism is not a separately configured data object, but a data row-level mutual exclusion control triggered by the database execution context when the overlay calculation instruction hits the data row to be updated in the bimodal inventory data record. The essence of the exclusive locking technique is to prevent other concurrent overlay calculation instructions from simultaneously updating the same data row before the overlay calculation instruction is completed. This exclusive locking does not lock all bimodal inventory data records, but rather locks the data rows that match the inventory positioning condition record. This allows data rows corresponding to different medical device materials, different batch number fields, different expiration date fields, or different business month / year inventory dimensions to still participate in their respective incremental updates. The database row locking mechanism is needed because in scenarios such as month-end inventory checks, large-scale remote data withdrawal, or concurrent data transmission from multiple suppliers for medical device distribution, multiple discarded records may simultaneously point to the same bimodal inventory data record. If a processing method of first reading the inventory level field, then accumulating the change value during the application-side calculation process, and finally overwriting and saving is adopted, different concurrent execution processes are prone to reading the same old inventory level field and overwriting each other's update results with their own calculation results. After the overlay calculation instruction triggers the database row locking mechanism, the changed value participates in the incremental update of the balance field while the data row to be updated is exclusively locked. This allows multiple changed values ​​on the same data row to be updated to enter the balance field sequentially according to the database execution order. The traceability log identifier is retained in the overlay calculation instruction to associate the exclusive locking of the data row to be updated and subsequent balance field updates with the traceability log, thereby enabling incremental inventory updates during the execution of the database row locking mechanism to be traced back to the inventory occupancy changes in the discarded records.

[0072] Preferably, in the specific technical implementation of the step "directly adding the change value to the balance field of the bimodal inventory data record within the internal calculation domain of the structured query statement", after the database row locking mechanism has completed the exclusive locking of the data row to be updated in the bimodal inventory data record, the overlay calculation instruction reads the balance field in the data row to be updated, and performs an overlay calculation on the current field value of the balance field and the change value within the internal calculation domain of the structured query statement to form the inventory balance result. The technical essence of the internal calculation domain of the structured query statement is the execution area where the database performs field-level calculations on the updated field when executing the overlay calculation instruction. The internal calculation domain of the structured query statement is located within the database execution context, and its calculation objects are the balance field, which has been exclusively locked by the database row locking mechanism, and the change value from the discarded record. The change value is directly accumulated to the inventory balance field within the internal calculation domain of the structured query statement. This does not bypass the traceability log or skip the discarded records. Instead, after the traceability log has been written to the operation log table, the same change value is used to update the bimodal inventory data record. The reason for using direct accumulation here is that the change value has already been extracted from the discarded records and recorded by the traceability log. Its quantity meaning already corresponds to the inventory occupancy change content released by the deletion of local detailed data, eliminating the need to reread the inventory balance result during the application-side calculation process and then overwrite it. After completing the accumulation process, the inventory balance result is written back to the inventory balance field, and the traceability log identifier is written to the most recent change source field of the bimodal inventory data record, so that the change in the inventory balance field can point back to the traceability log. The most recent change source field originates from the traceability log identifier and is used to retrieve the traceability log corresponding to the most recent incremental update of the inventory balance field when querying the bimodal inventory data record in subsequent queries. The technical essence of the balance field is that it is a field used to store the inventory balance result in the dual-modal inventory data record. The balance field participates in the balance expression of both local inventory status and collaborative inventory status. When the local detailed data is determined to be dirty data due to time difference and is deleted, the balance field needs to be incrementally updated according to the change value to eliminate the residual impact of the local detailed data that has lost its remote correspondence on the inventory occupancy content.By performing the accumulation of the changed value and the balance field within the internal calculation domain of the structured query statement, the retrospective writing of the discarded record, the exclusive locking of the database row locking mechanism, and the incremental update of the balance field can be completed continuously within the same database execution context. Compared to the method of reading the balance field, having the application-side calculation process calculate it, and then overwriting it back, the above processing reduces the probability of old value overwriting during concurrent processes and ensures that the bimodal inventory data record maintains a consistent data update relationship with the deleted local detailed data in both the local inventory status and collaborative inventory status dimensions.

[0073] like Figure 3 As shown in the figure, this is an embodiment of a medical device distribution supply chain system based on supply and demand coordination and bimodal inventory management. The system includes: The exclusive phase entry module is used to lock the source-end out-of-stock object based on the source identifier in the replenishment request data, and then use optimistic locking to update the status attribute of the source-end out-of-stock object to make it enter the exclusive phase. The source identifier is used to represent the trigger source type corresponding to the replenishment request data, and the source-end out-of-stock object is used to represent the data object to be replenished corresponding to the replenishment request data in the local storage pool. The unauthorized access verification module is used to perform unauthorized access verification on the target node set associated with the replenishment request data using a constraint list, wherein the target node set is used to represent the pending delivery node pointed to by the replenishment request data, and the constraint list is used to limit the execution permissions of the nodes corresponding to the target node set; The bidirectional mapping order generation module is used to group the source-end overdue goods objects in the exclusive stage according to the aggregation code of the target node set when the verification is passed, and generate a bidirectional mapping order containing transfer nodes. The aggregation code is used to represent the aggregation relationship between different target nodes in the target node set, and the transfer node is used to represent the sending node and receiving node of the source-end overdue goods object in the bidirectional mapping order. The collaborative data retrieval module is used to parse the flow node of the bidirectional mapping order to construct local detailed data, and then retrieve the remote data object of the external collaborative node. The local detailed data is used to record the order details of the flow node in the local system, and the external collaborative node is used to provide the remote data object for collaborative verification with the local detailed data. A consistency retrieval module is used to concatenate the built-in fields of the remote data object to obtain a feature fingerprint, and use the feature fingerprint to retrieve the local detailed data. The feature fingerprint is used to establish a consistency retrieval relationship between the remote data object and the local detailed data. The inventory incremental update module is used to delete the local detailed data when no remote data object corresponding to the local detailed data is detected in the remote full set view formed based on the remote data object, and the local detailed data exists. It then extracts the change value from the discarded record formed by deleting the local detailed data and performs an incremental update on the bimodal inventory data record based on the change value using a database row-locking mechanism. The discarded record records the inventory occupancy change corresponding to the deletion of the local detailed data, and the bimodal inventory data record simultaneously records the local inventory status and collaborative inventory status in the medical device distribution supply chain.

[0074] Optionally, the exclusive phase entry module includes: A numerical attribute extraction unit is used to extract the numerical attributes carried by the source identifier, wherein the numerical attributes are used to indicate the trigger source type corresponding to the replenishment request data; A unique tracking code generation unit is used to generate a unique tracking code based on the replenishment request data when the numerical attribute indicates a passively triggered event, wherein the passively triggered event is used to characterize a source-end inventory object locking scenario triggered by an external replenishment demand, and the unique tracking code is used to locate the source-end inventory object in the local storage pool. A source-end overdue goods object location unit is used to locate the source-end overdue goods object in the local storage pool using the unique tracking code; The status attribute update unit is used to verify the current version number of the source-end overdue object using the optimistic locking. Then, when the current version number meets the preset inference conditions, the status attribute is modified to prevent other processes from concurrently overwriting the source-end overdue object, thus causing it to enter the exclusive phase. The current version number is used to represent the current data version of the source-end overdue object in the local storage pool, and the preset inference conditions are used to determine whether the current version number allows the status attribute to be updated.

[0075] Optionally, the system further includes an active triggering processing module, which includes: The data object to be allocated is determined by bypassing the locking operation on the source-end out-of-stock object when the numerical attribute indicates an active triggering event. The active triggering event is used to characterize the scenario of generating a new reserve record with replenishment demand actively generated by the local system. A new reserve record generation unit is used to generate a new reserve record based on the replenishment request data, wherein the new reserve record is used to represent the pending delivery data object generated under the active triggering event; The pre-input source binding unit is used to bind the newly added reserve record to the target node set, and use the newly added reserve record as the pre-input source for generating the bidirectional mapping distribution document, so as to realize the unified convergence of data flow in multi-source triggering scenarios. The pre-input source is used to participate in the generation of the bidirectional mapping distribution document together with the source-end overdue object in the exclusive stage.

[0076] Optionally, the unauthorized access verification module includes: A target node set sending unit is used to send the target node set to an independent verification node via a remote call protocol, wherein the remote call protocol is used to transmit the target node set between the local system and the independent verification node, and the independent verification node is used to verify the frozen status of the nodes corresponding to the target node set; A node frozen state feedback receiving unit is used to receive node frozen state feedback returned by the independent verification node, wherein the node frozen state feedback is used to characterize whether the target node set is in a frozen state. The operation credential data capture unit is used to capture operation credential data in the current session environment when the node freeze status feedback indicates that it is not frozen. The operation credential data is used to characterize the operation identity and operation permissions of the person who initiated the replenishment request data in the current session environment. The local permission exploration unit is used to inject the operation voucher data as input conditions into the constraint list to perform local permission exploration. When a whitelist record is hit, it confirms that the target node set has legitimate execution permissions to isolate unauthorized requests from illegal nodes. The whitelist record belongs to the constraint list, and the legitimate execution permissions are used to indicate that the target node set can participate in the generation of the bidirectional mapping order.

[0077] Optionally, the two-way mapping order generation module includes: A streaming data conversion unit is used to convert the source-end overstock object in the exclusive stage into streaming data containing the aggregate code, wherein the streaming data is used to carry the source-end overstock object and the aggregate code corresponding to the source-end overstock object; A data grouping generation unit is used to perform aggregation processing on the streaming data according to the aggregation code to obtain multiple independent data groups, wherein the data groups are used to represent the streaming data set having the same or related aggregation codes; The master data attribute request unit is used to request the missing master data attributes of each data group from an external master data source through a remote call protocol. The external master data source is used to provide the master data attributes required for the data group to generate the bidirectional mapping packing document. The master data attributes are used to fill in the missing node basic attributes and material basic attributes in the data group. A bidirectional mapping order construction unit is used to fill the master data attributes into the corresponding data groups, and then construct the bidirectional mapping order containing mutually mapped sender primary keys and receiver primary keys to maintain data traceability between heterogeneous systems. The sender primary key is used to identify the sender node in the flow node, and the receiver primary key is used to identify the receiver node in the flow node.

[0078] Optionally, the collaborative data retrieval module includes: The external collaboration node list extraction unit is used to read a preset system configuration file and extract a list of external collaboration nodes that are in the enabled state. The system configuration file is used to record the enabled state and data open interface address of the external collaboration nodes, and the external collaboration node list is used to limit the external collaboration nodes that need to pull the remote data object. A data sharding generation unit is used to perform sharding and truncation on the list of external collaborative nodes using a preset sharding length to generate multiple data shards with a specified length, wherein the preset sharding length is used to limit the number of external collaborative nodes contained in each data shard; An execution thread allocation unit is used to allocate independent execution threads to the plurality of data shards with a specified length, wherein the execution threads are used to concurrently access the external cooperating nodes in the corresponding data shards; The remote data object receiving unit is used to drive the execution thread to concurrently call the data opening interface of the external collaborative node to receive the remote data object formatted as a key-value pair structure. The data opening interface is used to output the remote data object, and the key-value pair structure is used to carry the built-in fields of the remote data object.

[0079] Optionally, the consistency retrieval module includes: The built-in field extraction unit is used to extract the requester field, target field, order number field, suffix field and line indicator field from the remote data object, wherein the requester field, target field, order number field, suffix field and line indicator field together serve as the built-in fields for generating the feature fingerprint; The feature fingerprint generation unit is used to perform string concatenation processing on the requester field, the target field, the order number field, the suffix field, and the line indicator field according to a preset sorting rule to generate the feature fingerprint with a unique identifier. The preset sorting rule is used to limit the order of the requester field, the target field, the order number field, the suffix field, and the line indicator field in the string concatenation processing. A local detail data location unit is used to perform a lookup operation in a local cache space using the feature fingerprint to locate the local detail data with consistent characteristics. The local cache space is used to store the local detail data constructed by the flow nodes of the bidirectional mapping loading document. The consistent characteristics are used to characterize that the local detail data and the remote data object have the same feature fingerprint.

[0080] Optionally, the inventory incremental update module includes: The remote full set view construction unit is used to construct a remote full set view for the remote data object based on the remote data object returned by the external collaborative node, wherein the remote full set view is used to summarize the remote data objects returned by different external collaborative nodes; An existence detection unit is used to extract the identity identifier of the local detailed data and perform an existence detection in the remote full set view using the identity identifier. The identity identifier is derived from the field combination in the local detailed data that corresponds to the feature fingerprint. The existence detection is used to determine whether there is a remote data object in the remote full set view that corresponds to the local detailed data. A withdrawal trigger instruction generation unit is used to generate a withdrawal trigger instruction for the local detailed data when the existence probe returns a miss result, wherein the miss result is used to indicate that there is no remote data object corresponding to the local detailed data in the remote full set view, and the withdrawal trigger instruction is used to trigger the deletion process of the local detailed data; The local detail data physical erasure unit is used to respond to the withdrawal trigger command, modify the occupancy constraint attribute associated with the local detail data, and then physically erase the local detail data at the database level to clean up the time difference dirty data generated between heterogeneous systems. The occupancy constraint attribute is used to characterize the inventory occupancy relationship between the local detail data and the bimodal inventory data record, and the time difference dirty data is used to characterize the inconsistent data between the local detail data and the remote data object caused by the synchronization time difference.

[0081] Optionally, the inventory incremental update module includes: The structured query statement construction unit is used to construct a structured query statement containing independent write instructions and superimposed calculation instructions, wherein the structured query statement is used to complete the retrospective writing of the discarded records and the incremental update of the bimodal inventory data records in the same database execution context; The traceability log generation unit is used to execute the independent write instruction to write the change value into an independent operation flow table to generate a traceability log. The independent write instruction is used to write the change value in the discarded record into the operation flow table. The operation flow table is used to record the inventory change process caused by the deletion of the local detailed data. The traceability log is used to trace the source of the change value. The inventory balance field update unit is used to execute the overlay calculation instruction, trigger the database row locking mechanism to perform exclusive locking on the bimodal inventory data record, and then directly add the change value to the inventory balance field of the bimodal inventory data record in the internal calculation domain of the structured query statement. The overlay calculation instruction is used to update the bimodal inventory data record based on the change value, and the inventory balance field is used to record the inventory balance result in the bimodal inventory data record.

[0082] like Figure 4 As shown, an electronic device according to an embodiment of this application is provided. The electronic device includes a processor and a memory. The memory stores a computer program. When the processor runs the computer program, it performs the steps of a medical device distribution supply chain method based on supply and demand coordination and bimodal inventory management.

[0083] like Figure 5 As shown, this is an embodiment of a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the steps of a medical device distribution supply chain method based on supply and demand coordination and bimodal inventory management.

[0084] The above Figures 3-5 For an exemplary description, please refer to the above. Figure 1 This will not be elaborated upon here.

Claims

1. A medical device distribution supply chain method based on supply and demand coordination and bimodal inventory management, comprising: Based on the source identifier in the replenishment request data, the source-end out-of-stock object is identified, and then optimistic locking is used to update the status attribute of the source-end out-of-stock object to make it enter the exclusive phase. The constraint list is used to perform an over-authority check on the target node set associated with the replenishment request data. When the check passes, the source-end out-of-stock objects in the exclusive stage are grouped according to the aggregation code of the target node set, and a bidirectional mapping packing document containing the transfer nodes is generated. The local detailed data is constructed by parsing the flow nodes of the bidirectional mapping order, and then the remote data object of the external collaborative node is pulled. The built-in fields of the remote data object are concatenated to obtain the feature fingerprint, and the local detailed data is retrieved using the feature fingerprint. If no remote data object corresponding to the local detailed data is detected in the remote full set view formed based on the remote data object, and the local detailed data exists, the local detailed data is deleted, the change value in the discarded record formed by deleting the local detailed data is extracted, and the bimodal inventory data record is incrementally updated based on the change value through the database row locking mechanism.

2. The method according to claim 1, wherein, Based on the source identifier in the replenishment request data, the source-end inventory object is identified. Then, optimistic locking is used to update the status attributes of the source-end inventory object to bring it into the exclusive phase, including: Extract the numerical attribute carried by the source identifier, wherein the numerical attribute is used to indicate the trigger source type corresponding to the replenishment request data; When the numerical attribute indicates a passively triggered event, a unique tracking code is generated based on the replenishment request data. The passively triggered event is used to characterize a source-end inventory object locking scenario triggered by an external replenishment demand, and the unique tracking code is used to locate the source-end inventory object in the local storage pool. The source of the out-of-stock item is located in the local storage pool using the unique tracking code. The optimistic locking is used to verify the current version number of the source-end overdue object. Then, when the current version number meets the preset inference conditions, the status attribute is modified to prevent other processes from concurrently overwriting the source-end overdue object, thus causing it to enter the exclusive phase. The current version number is used to represent the current data version of the source-end overdue object in the local storage pool, and the preset inference conditions are used to determine whether the current version number allows the status attribute to be updated.

3. The method according to claim 2, wherein, After extracting the numerical attributes carried by the source identifier, the method further includes: When the numerical attribute indicates an active triggering event, the locking operation for the source-end out-of-stock object is bypassed to determine the data object to be allocated. The active triggering event is used to characterize the scenario of generating new reserve records with replenishment requirements actively generated by the local system. A new reserve record is generated based on the replenishment request data, wherein the new reserve record is used to represent the pending delivery data object generated under the active triggering event; The newly added reserve record is bound to the target node set, and the newly added reserve record is used as a pre-input source for generating the bidirectional mapping distribution document, so as to realize the unified convergence of data flow in multi-source triggering scenarios. The pre-input source is used to participate in the generation of the bidirectional mapping distribution document together with the source-end inventory object in the exclusive stage.

4. The method according to claim 1, wherein, Performing unauthorized access checks on the target node set associated with the replenishment request data using a constraint list includes: The target node set is sent to the independent verification node via a remote procedure call protocol, wherein the remote procedure call protocol is used to transmit the target node set between the local system and the independent verification node, and the independent verification node is used to verify the frozen status of the nodes corresponding to the target node set; Receive node freeze status feedback returned by the independent verification node, wherein the node freeze status feedback is used to characterize whether the target node set is in a frozen state; When the node freeze status feedback indicates that it is not frozen, capture the operation credential data in the current session environment, wherein the operation credential data is used to characterize the operation identity and operation permissions of the person who initiated the replenishment request data in the current session environment; The operation voucher data is injected into the constraint list as input to perform local permission probing. When a whitelist record is matched, it is confirmed that the target node set has legitimate execution permissions to isolate unauthorized requests from illegal nodes. The whitelist record belongs to the constraint list, and the legitimate execution permissions are used to indicate that the target node set can participate in the generation of the bidirectional mapping order.

5. The method according to claim 1, wherein, Grouping the source-end out-of-stock objects in the exclusive stage according to the aggregation code of the target node set, and generating a bidirectional mapping packing document containing transfer nodes includes: The source-end overstock object in the exclusive phase is converted into streaming data containing the aggregate code, wherein the streaming data is used to carry the source-end overstock object and the aggregate code corresponding to the source-end overstock object; The streaming data is aggregated according to the aggregation code to obtain multiple independent data groups, wherein the data groups are used to represent the streaming data sets that have the same or related aggregation codes; The system requests the missing master data attributes of each data group from an external master data source via a remote call protocol. The external master data source is used to provide the master data attributes required for the data group to generate the bidirectional mapping order. The master data attributes are used to fill in the missing node basic attributes and material basic attributes in the data group. The master data attributes are filled into the corresponding data groups, and then the bidirectional mapping order containing mutually mapped sender primary keys and receiver primary keys is constructed to maintain data traceability between heterogeneous systems. The sender primary key is used to identify the sender node in the flow node, and the receiver primary key is used to identify the receiver node in the flow node.

6. The method according to claim 1, wherein, Retrieving remote data objects from external collaboration nodes includes: Read the preset system configuration file and extract the list of external collaborative nodes that are in the enabled state. The system configuration file is used to record the enabled state and data open interface address of the external collaborative nodes, and the list of external collaborative nodes is used to limit the external collaborative nodes that need to pull the remote data object. The list of external collaborative nodes is truncated using a preset slicing length to generate multiple data slices with a specified length, wherein the preset slicing length is used to limit the number of external collaborative nodes contained in each data slice; Independent execution threads are allocated to the plurality of data shards with a specified length, wherein the execution threads are used to concurrently access the external cooperating nodes in the corresponding data shards; The execution thread concurrently calls the data access interface of the external collaborative node to receive the remote data object formatted as a key-value pair structure. The data access interface is used to output the remote data object, and the key-value pair structure is used to carry the built-in fields of the remote data object.

7. The method according to claim 1, wherein, By concatenating the built-in fields of the remote data object to obtain a feature fingerprint, and using the feature fingerprint to retrieve the local detailed data, the following steps are taken: Extract the requester field, target field, order number field, suffix field, and line indicator field from the remote data object, wherein the requester field, target field, order number field, suffix field, and line indicator field are collectively used as the built-in fields for generating the feature fingerprint; The requester field, the target field, the order number field, the suffix field, and the line indicator field are concatenated according to a preset sorting rule to generate the feature fingerprint with a unique identifier. The preset sorting rule is used to limit the order of the requester field, the target field, the order number field, the suffix field, and the line indicator field in the string concatenation process. The local cache space is used to perform a lookup operation using the feature fingerprint to locate the local detailed data with consistent characteristics. The local cache space is used to store the local detailed data constructed by the flow nodes of the bidirectional mapping order. The consistent characteristics are used to characterize that the local detailed data and the remote data object have the same feature fingerprint.

8. A medical device distribution supply chain system based on supply and demand coordination and bimodal inventory management, characterized in that, The system includes: The exclusive phase entry module is used to lock the source-end out-of-stock object based on the source identifier in the replenishment request data, and then use optimistic locking to update the status attribute of the source-end out-of-stock object to make it enter the exclusive phase. The source identifier is used to represent the trigger source type corresponding to the replenishment request data, and the source-end out-of-stock object is used to represent the data object to be replenished corresponding to the replenishment request data in the local storage pool. The unauthorized access verification module is used to perform unauthorized access verification on the target node set associated with the replenishment request data using a constraint list, wherein the target node set is used to represent the pending delivery node pointed to by the replenishment request data, and the constraint list is used to limit the execution permissions of the nodes corresponding to the target node set; The bidirectional mapping order generation module is used to group the source-end overdue goods objects in the exclusive stage according to the aggregation code of the target node set when the verification is passed, and generate a bidirectional mapping order containing transfer nodes. The aggregation code is used to represent the aggregation relationship between different target nodes in the target node set, and the transfer node is used to represent the sending node and receiving node of the source-end overdue goods object in the bidirectional mapping order. The collaborative data retrieval module is used to parse the flow node of the bidirectional mapping order to construct local detailed data, and then retrieve the remote data object of the external collaborative node. The local detailed data is used to record the order details of the flow node in the local system, and the external collaborative node is used to provide the remote data object for collaborative verification with the local detailed data. A consistency retrieval module is used to concatenate the built-in fields of the remote data object to obtain a feature fingerprint, and use the feature fingerprint to retrieve the local detailed data. The feature fingerprint is used to establish a consistency retrieval relationship between the remote data object and the local detailed data. The inventory incremental update module is used to delete the local detailed data when no remote data object corresponding to the local detailed data is detected in the remote full set view formed based on the remote data object, and the local detailed data exists. It then extracts the change value from the discarded record formed by deleting the local detailed data and performs an incremental update on the bimodal inventory data record based on the change value using a database row-locking mechanism. The discarded record records the inventory occupancy change corresponding to the deletion of the local detailed data, and the bimodal inventory data record simultaneously records the local inventory status and collaborative inventory status in the medical device distribution supply chain.

9. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing a computer program, and the processor, when running the computer program, performs the steps of the medical device distribution supply chain method based on supply and demand coordination and bimodal inventory management as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the medical device distribution supply chain method based on supply and demand coordination and bimodal inventory management as described in any one of claims 1 to 7.

Images