Multi-role cooperative receiving and shipping process control system and method and storage medium

Abstract

The application belongs to the technical field of business process management, and discloses a multi-role cooperative receiving and shipping process control system and method and a storage medium. The system comprises a first state machine management module for managing the state of a seller, a second state machine management module for managing the state of a buyer, a state dependency and permission control module for monitoring the states of the two parties in real time and dynamically calculating and locking the operation permissions of the two parties according to a predefined cooperative dependency relationship, and a visual interface rendering module for updating the operation interfaces of the two parties in real time according to the permissions. The method comprises managing the states of the buyer and the seller respectively, dynamically calculating the operation permissions based on the states of the two parties, and rendering the interfaces in real time according to the operation permissions. The application solves the problems of state asynchronization, non-compliance operation and low cooperative efficiency in a multi-role complex process through the cooperation of the two state machines and the dynamic permission binding, and realizes the automation, error-proofing and precise real-time rendering of the interfaces of the business process.

Description

Technical Field

[0001] This invention relates to the field of enterprise business process management technology, and in particular to a multi-role collaborative receiving and shipping process control system, method, and storage medium. Background Technology

[0002] In enterprise supply chain management, especially in bulk commodity trading, project-based procurement, or complex logistics scenarios, the process of receiving and shipping goods typically involves multiple roles (such as sellers / suppliers, buyers / demanders, and carriers) and diverse business models (such as payment before delivery, cash on delivery, and different parties responsible for freight). Such processes are characterized by variable states, complex rules, and high requirements for role coordination.

[0003] Currently, existing technical solutions for managing such processes have the following main drawbacks: 1. Inefficient and centralized state management: Most systems use a single, linear state flow to track orders, such as "Created -> Shipped -> In Transit -> Signed for". This centralized state model cannot accurately reflect the independent business perspectives and progress of both buyers and sellers. For example, the seller arranging a vehicle ("Vehicle found") and whether the buyer is ready to receive the goods ("Waiting for receipt") are two independent but related events, but they cannot be clearly and independently expressed and managed in a single state flow, leading to distorted process tracking.

[0004] 2. Hard-coded collaborative logic, resulting in poor flexibility: Differences in processes under different business models (e.g., in the "payment before delivery" model, buyer payment is a prerequisite for shipment, while in the "buyer pays freight" model, the buyer needs to confirm the waybill) are usually hard-coded into the system logic using numerous if-else conditional statements. When a new business model is added or rules change, the underlying code needs to be modified, leading to extremely poor system maintainability and scalability, and making it prone to introducing errors.

[0005] 3. Disconnect between operational permissions and process status: Existing systems rely heavily on static role-based access control (RBAC) rather than dynamic business context. For example, the buyer's interface may always display the "Confirm Receipt" button regardless of whether the delivery vehicle has arrived. This can lead to invalid or unauthorized operations by users (such as clicking "Pickup Complete" when no vehicle is available). The system lacks effective error prevention mechanisms and heavily relies on human experience and communication to avoid process chaos.

[0006] 4. Status synchronization delays and UI rigidity: Status updates for both buyers and sellers often rely on manual refresh or polling, making real-time synchronization impossible. The user interface (UI) is usually static or semi-static, unable to dynamically hide, disable, or highlight relevant operation controls based on real-time process status, resulting in a poor user experience and low collaboration efficiency.

[0007] A brief introduction to the concept of a Finite State Machine (FSM): A Finite State Machine is a mathematical model used to represent a finite number of states and the transitions and actions between these states. In software engineering, an FSM is a powerful tool for describing the sequence of states an object experiences throughout its lifecycle and how it responds to various external events (such as user actions and system messages) to transition from one state to another. By defining well-defined sets of states, events, and transition rules, it makes complex behavioral logic clear, predictable, and easy to manage. However, traditional FSM applications are mostly single-role, single-threaded process modeling, making them difficult to directly apply to the complex business scenarios described above involving multiple roles, multiple modes, and strong collaboration.

[0008] In summary, existing technologies lack a solution that can establish independent and collaborative state machine models for multiple roles and dynamically and accurately control operation permissions and interface presentation based on real-time status. This leads to technical problems such as low efficiency, error-proneness, and difficulty in collaboration in complex receiving and shipping processes. Summary of the Invention

[0009] The purpose of this invention is to overcome the above-mentioned defects of the prior art and provide a multi-role collaborative receiving and shipping process control system, method and storage medium. By constructing independent but logically collaborative finite state machines for buyers and sellers, and based on the real-time state of the dual state machines, the operation permissions and interface presentation of each role are dynamically calculated and bound through a rule engine, thereby realizing the automation, standardization and error-proof flow of complex business processes, and improving the real-time performance and transparency of multi-party collaboration.

[0010] The present invention adopts the following technical solution: On one hand, the present invention provides a multi-role collaborative receiving and shipping process control system, including: The first state machine management module is used to manage the first business process state set corresponding to the seller role, and drive the flow of the first business process state according to the preset first state transition rules. The second state machine management module is used to manage the set of second business process states corresponding to the buyer role, and drive the flow of the second business process states according to the preset second state transition rules; The state dependency and access control module, which is communicatively connected to both the first state machine management module and the second state machine management module, is configured as follows: Real-time monitoring of the status of the first business process and the status of the second business process; Based on the collaborative dependency relationship between the first business process state and the second business process state, the set of operation permissions provided to the seller role and the buyer role is dynamically determined and locked; wherein, the collaborative dependency relationship defines the constraint on the operation permissions of the other role when the state of either role is a specific value; The visualization interface rendering module, connected to the state dependency and permission control module, is used to render and update the user interface presented to the seller role and the buyer role in real time according to the currently dynamically determined set of operation permissions. The executable operation controls in the user interface are matched with the set of operation permissions.

[0011] In addition to any of the possible implementations described above, an implementation is further provided in which the first business process state set includes a subset of states related to transportation arrangements; the state dependency and access control module is further configured to allow triggering of a state transition event pointing to the pickup completion state only when the first business process state is in the subset of states related to the transportation arrangements.

[0012] In addition to any of the possible implementations described above, an implementation is further provided in which the subset of states related to transportation arrangement includes at least the "vehicle found" state; the state dependency and access control module is configured to: dynamically unlock the receiving-related operation permissions for the buyer role in response to the first business process state transitioning to the "vehicle found" state.

[0013] In addition to any of the possible implementations described above, another implementation is provided in which the subset of states related to the arrangement of transportation vehicles further includes states refined from the "vehicle found" state to characterize the number of transportation vehicles, including "one vehicle" state and "multiple vehicles" state; the state dependency and permission control module is configured to dynamically control the receiving operation permission provided to the buyer role to be "full receipt" or "partial receipt" depending on whether the current state is "one vehicle" or "multiple vehicles".

[0014] In addition to any of the possible implementations described above, another implementation is provided in which the second business process state set includes at least a pending receipt state, a partial receipt state, and a completed state.

[0015] In addition to any of the possible implementations described above, a further implementation is provided in which the system further includes a state synchronization engine, which, based on an event-driven mechanism, triggers the state dependency and permission control module to perform permission recalculation in real time when the state of the first business process or the state of the second business process changes, and triggers the visualization interface rendering module to update the interface.

[0016] In addition to any of the possible implementations described above, another implementation is provided in which the state dependency and access control module is further configured to: select a set of collaborative dependencies between the application and the business mode according to a preset business mode configuration; wherein the business mode includes at least a cash-on-delivery mode and a freight cost difference mode.

[0017] On the other hand, the present invention also provides a multi-role collaborative receiving and shipping process control method, applied to the above-mentioned system, the method comprising: The business process states of the seller and buyer roles are managed separately through independent first and second state machines; Real-time monitoring of the current business process status of both parties' roles; Based on predefined dependency rules that are based on the state collaboration of both parties, the operation permissions of both parties' roles are dynamically calculated and locked. Based on the calculated operation permissions, the user interface presented to both roles is rendered and updated in real time, so that the interface operation controls are precisely matched with the currently available permissions.

[0018] In addition to any of the possible implementations described above, another implementation is provided, which dynamically calculates operation permissions according to predefined dependency rules, including: determining whether the current value of the seller's status meets preset conditions; if not, disabling operation controls related to receipt completion on the buyer's interface.

[0019] On the other hand, the present invention also provides a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the above-described method.

[0020] The beneficial effects of this invention are as follows: 1. It achieves a high degree of automation and standardization of business processes (corresponding to the "state machine collaborative driving" feature): Results: By establishing precise finite state machine models for both buyers and sellers, the system transforms chaotic business processes that rely on manual intervention into standardized processes automatically driven by state transition rules. The system automatically guides the process, reducing human intervention and arbitrariness.

[0021] Corresponding to the features: the first state machine management module and the second state machine management module realize the standardized modeling and automatic flow of their respective processes.

[0022] 2. Provides robust error prevention and compliance protection (corresponding to the feature of "dynamic binding of state dependency and operation permission"): Effect: By dynamically binding operation permissions to real-time, collaborative dual-state machine states, operations that violate business rules are technically prevented. For example, when there is no vehicle physically present, the system logically and graphically prohibits "completing pickup," fundamentally avoiding operational chaos and data inconsistencies.

[0023] Corresponding to the feature: the state dependency and access control module is the core of this effect. It realizes the real-time and accurate tracking of permissions to state by parsing collaborative dependency rules.

[0024] 3. Significantly improves the efficiency and transparency of multi-party collaboration (corresponding to the "real-time status synchronization and visualization" feature): Effect: Changes in the status of both buyers and sellers are synchronized in real time through an event-driven mechanism and immediately reflected in the permissions and display changes on the other party's interface. For example, once the seller has "found a vehicle," the buyer's interface immediately unlocks the "receive goods" related operations. This near-real-time transparent collaboration greatly reduces communication costs and improves overall process efficiency.

[0025] Corresponding to the features: The event-driven architecture and the visual interface rendering module within the system work together to ensure instantaneous linkage between state, permissions, and interface.

[0026] 4. Enhanced system flexibility and configurability (corresponding to the concepts of "multi-mode support" and "rule engine"): Effect: Different business models (such as cash on delivery and different freight payment methods) can be abstracted into different "collaborative dependency rule sets". By switching rule sets through configuration rather than coding, the system can quickly adapt to new business scenarios, greatly improving the system's adaptability and reducing maintenance costs.

[0027] Corresponding to the features: This is thanks to separating business logic from the code and abstracting it into rule configurations that can be handled by the state dependency and permission control modules.

[0028] 5. Improved user experience and interface friendliness: Effect: The dynamically rendered interface ensures that users can only see and operate on the currently allowed steps at any given time. The interface itself is the "operation guide," which is intuitive and clear, reducing the barrier to entry and training costs. Attached Figure Description

[0029] Figure 1 This is a schematic diagram of the system module architecture provided in an embodiment of the present invention.

[0030] Figure 2 This is a schematic diagram illustrating the principle of state machine collaboration and access control between buyers and sellers in one embodiment of the present invention.

[0031] Figure 3This is a flowchart of a receiving and shipping process control method provided in an embodiment of the present invention.

[0032] Figure 4 This is a sequence diagram of the interface states for handling a scenario of receiving goods in batches from multiple vehicles under the "payment upon delivery, freight charge paid by the buyer" mode, according to an embodiment of the present invention. Detailed Implementation

[0033] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to specific embodiments and the accompanying drawings. It should be understood that these descriptions are merely exemplary and not intended to limit the scope of the invention. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concept of the invention.

[0034] The accompanying drawings illustrate a layer structure according to an embodiment of the present invention. These drawings are not to scale, and some details have been enlarged for clarity, and some details may have been omitted. The shapes of the various regions and layers shown in the drawings, as well as their relative sizes and positional relationships, are merely exemplary and may deviate from reality due to manufacturing tolerances or technical limitations. Furthermore, those skilled in the art can design regions / layers with different shapes, sizes, and relative positions as needed.

[0035] Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0036] In the description of this invention, it should be noted that the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0037] Furthermore, the technical features involved in the different embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0038] like Figure 1 As shown in the figure, an embodiment of the present invention provides a multi-role collaborative receiving and shipping process control system, comprising: The first state machine management module manages the set of first business process states corresponding to the seller (supplier) role. This set includes at least the following states: pending pickup, vehicle found, no vehicle, one vehicle, multiple vehicles, partial receipt (meaning the buyer has partially received the goods from the seller's perspective), and completed. This module drives the seller's state transitions according to preset first state transition rules (e.g., the transition event from "pending pickup" to "vehicle found" is "confirm vehicle dispatch").

[0039] The second state machine management module manages the set of second business process states corresponding to the buyer (purchaser) role. This set includes at least the states of pending receipt, partial receipt, and completion. This module drives the buyer's state transitions according to preset second state transition rules.

[0040] State Dependency and Access Control Module: This module communicates with both state machine management modules mentioned above. It serves as the system's "collaborative brain" and is configured as follows: 1. Real-time monitoring: Continuously monitor the current state of the first state machine and the second state machine.

[0041] 2. Rule Parsing and Permission Calculation: Based on a predefined rule base describing the collaborative dependencies between the two state machines, the system dynamically calculates the set of currently available operation permissions for both the buyer and seller. For example, a rule can be defined as: "If the seller's status is not 'Find a vehicle,' 'One vehicle,' or 'Multiple vehicles,' then the buyer's 'Confirm Receipt' operation permission is disabled." This directly implements the business constraint that "the pickup completion cannot be clicked when no vehicle is available."

[0042] 3. Dynamic binding: The calculated set of permissions is locked in real time, serving as the sole basis for controlling user operations.

[0043] Visual Interface Rendering Module: Connected to the State Dependency and Access Control module. This module dynamically renders (generates) and updates the user interface (UI) presented to the seller and buyer based on the real-time received set of operation permissions customized for different roles. For example, when the buyer does not have the "Confirm Receipt" permission, the corresponding button on their interface will be grayed out (disabled) or hidden.

[0044] This invention provides a multi-role collaborative receiving and shipping process control method, applied to the aforementioned system, comprising the following steps: S1: Initialize and run independent state machines for the seller and buyer roles respectively in the system.

[0045] S2: Real-time monitoring of state change events in both parties' state machines.

[0046] S3: When any state changes, recalculate the current operation permissions of both parties' roles according to the preset collaboration dependency rules.

[0047] S4: Based on the calculated new set of permissions, refresh and render the respective front-end interfaces in real time to ensure that the state of the interface controls (available / disabled / hidden) matches the permissions precisely.

[0048] S5: Respond to user actions triggered within the permitted scope (such as the seller clicking "Vehicle dispatched"), drive the corresponding state machine to perform state transitions, and trigger a new round of S2-S4 processes.

[0049] The specific process is as follows: Figure 3 As shown.

[0050] Example 1: System Architecture and Core Collaboration Principles refer to Figure 1 The system is deployed on the server side and includes four core modules: First State Machine Management Module 101: Maintains the seller's state model. For example, define the state set S_seller = {Pending Pickup, Vehicle Found, No Vehicle Available, One Vehicle, Multiple Vehicles, Completed}. Define the events E_seller = {Successful Vehicle Dispatch, Failed Vehicle Dispatch, Vehicle Arrived, Partial Buyer Signature, Full Buyer Signature}. The transition rule is as follows: when in the "Pending Pickup" state, if the "Successful Vehicle Dispatch" event occurs, the system transitions to the "Vehicle Found" state.

[0051] Second state machine management module 102: Maintains the buyer's state model. For example, S_buyer = {pending receipt, partial receipt, completed}. E_buyer = {partial receipt, full receipt}.

[0052] State Dependency and Access Control Module 103: Embedded Rule Engine.

[0053] Visual interface rendering module 104: Receives buyer_perm and seller_perm from module 103 and pushes them to the front end in real time via WebSocket or similar technology. The front end framework (such as Vue, React) updates the DOM accordingly, changes button styles (enables / disables) or shows / hides components.

[0054] Combination Figure 2 The collaborative process is as follows: the seller's operation triggers its state machine transition (A1) -> the state change event is captured by module 103 (A2) -> module 103 recalculates the permissions of both parties according to the new state (A3) -> module 104 sends the new permissions to the front end (A4) -> the buyer's interface is updated in real time (A5), at which point the buyer can proceed with the next compliant operation.

[0055] Example 2: Scenario-based applications under multiple service modes This embodiment details how the system flexibly handles complex scenarios under different business models. The system has multiple pre-set rule templates, which are automatically loaded at the start of the process based on contract or order attributes (such as "payment method" and "freight payer").

[0056] Scenario 1: Standard Process under the "Payment Upon Delivery" Supplier Pays Shipping Fee Model Initial conditions: Order created, status "Payment in Received". Load rule set A, which contains the core rule: "Buyer status must be 'Payment Received', order automatically routed from 'My -- Orders' module to 'My -- Shipments and Receipts' module. Seller status = 'Pending Shipment', Buyer status = 'Pending Receipt'". process: 1. After the buyer completes the payment, they can click "Confirm Payment" on the interface. This action will cause the buyer's state machine to transition to an intermediate state "Payment Received" (this state may not be directly visible to the seller, but it is involved in the rule calculation).

[0057] 2. Module 103 calculates according to rule set A: if the condition is met (buyer status = 'payment received'), the order arrives at the "Receive and Ship" module, unlocking the seller's "Go to Ship" and other operation permissions.

[0058] 3. The seller's interface refreshes, and the "Send Shipment" button becomes available. The seller can then continue with subsequent operations (such as finding a vehicle).

[0059] Results: Technically, it strictly guarantees the ironclad business rule of "payment before delivery" and avoids human error.

[0060] Scenario 2: Multi-vehicle batch pickup under the "buyer pays freight" model (combined with...) Figure 4 ) Initial conditions: The order is in the "buyer pays freight" category, and the large quantity of goods requires multiple truckloads for transportation. Seller status = "Pending shipment", buyer status = "Pending receipt". Load rule set B, which includes the rule: "When the seller status is 'multiple truckloads', the buyer's permissions include 'partial receipt'".

[0061] process: 1. The seller arranges multiple vehicles, advancing the status from "vehicle found" to "multiple vehicles".

[0062] 2. Module 103 calculation: Seller status = 'Multiple vehicles' -> Buyer permissions = {'Partial receipt': Enabled, 'Full receipt': Disabled}.

[0063] 3. Buyer's interface updated: The "Partial Receipt" button is displayed, and the "Full Receipt" button is grayed out.

[0064] 4. First shipment arrives: The buyer performs a "partial receipt" operation, entering the quantity to be received. This operation drives the buyer's state machine to transition to the "partial receipt" state.

[0065] 5. Module 103 calculation: Buyer status = 'Partial receipt' -> Seller permissions may be updated (e.g., unlocking "Enter next vehicle information").

[0066] 6. Last shipment arrives: The buyer performs "Partial Receipt" again. The system determines that the cumulative receipt quantity has reached the total order quantity and automatically (or prompts the buyer to perform an action) changes the buyer's status to "Completed".

[0067] 7. Module 103 Calculation: Buyer Status = 'Completed' -> Unlock Seller's "Process Completed" operation permission.

[0068] Results: It perfectly supports complex scenarios of receiving goods in batches, with a clear process, each operation is traceable, and status, permissions, and interface are perfectly synchronized.

[0069] Scenario 3: Handling abnormal capacity coordination ("no vehicle" status) Scenario: The seller tries to find a car but fails temporarily.

[0070] process: 1. The seller executes the "Failed to dispatch vehicle" operation, and the seller's status changes from "Pending shipment" to "No vehicle".

[0071] 2. Module 103 calculation: Seller status = 'No vehicle' -> Buyer permission = {'Confirm receipt': Disabled}.

[0072] 3. The buyer's interface refreshes in real time, the "Confirm Receipt" button becomes unclickable, and a message may be displayed: "The supplier is coordinating the vehicle, please wait."

[0073] Results: Transparently and promptly communicating any abnormalities in capacity coordination to the buyer avoids unnecessary waiting and blindly chasing orders, thus improving the collaborative experience.

[0074] Example 3: Specific Implementation of Dynamic Interface Rendering The workflow of the visual interface rendering module 104 is as follows: 1. The front-end binds a "permission key" to each key operation control (such as a button or form), such as data-perm-key="confirm_receipt".

[0075] 2. When the front-end receives the permission object {confirm_receipt: false, partial_receipt: true} from the back-end module 103, iterates through the UI elements.

[0076] 3. Locate the button with data-perm-key="confirm_receipt", set its disabled attribute to true, and add the .disabled style class (grayed out).

[0077] 4. Locate the button with data-perm-key="partial_receipt" and set its disabled attribute to false.

[0078] The entire update process is completed in milliseconds, giving users the impression of an instant response.

[0079] This invention solves the problems of asynchronous states, non-compliant operations, and low collaboration efficiency in complex multi-role processes by using dual-state machine collaboration and dynamic permission binding, thereby achieving automated and error-proof workflow of business processes and accurate real-time rendering of the interface.

[0080] The above description of the embodiments is only for the purpose of helping to understand the method and core idea of ​​this application; at the same time, for those skilled in the art, there will be changes in the specific implementation and application scope based on the idea of ​​this application. Therefore, the content of this specification should not be construed as a limitation of this application.

[0081] Certain terms are used in the specification and claims to refer to specific components. Those skilled in the art will understand that hardware manufacturers may use different names to refer to the same component. This specification and claims do not distinguish components based on differences in name, but rather on differences in function. The terms "comprising" and "including" used throughout the specification and claims are open-ended and should be interpreted as "comprising / including but not limited to". "Approximately" means that within an acceptable margin of error, those skilled in the art can solve the technical problem and substantially achieve the technical effect within a certain margin of error. The following descriptions in the specification are preferred embodiments for carrying out this application; however, these descriptions are for the purpose of illustrating the general principles of this application and are not intended to limit the scope of this application. The scope of protection of this application shall be determined by the appended claims.

[0082] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a product or system comprising a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a product or system. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the product or system that includes said element.

[0083] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0084] The foregoing description illustrates and describes several preferred embodiments of this application. However, as previously stated, it should be understood that this application is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. It can be used in various other combinations, modifications, and environments, and can be altered within the scope of the application concept described herein through the foregoing teachings or techniques or knowledge in related fields. Any modifications and variations made by those skilled in the art that do not depart from the spirit and scope of this application should be within the protection scope of the appended claims.

Claims

1. A multi-role collaborative receiving and shipping process control system, characterized in that, include: The first state machine management module is used to manage the first business process state set corresponding to the seller role, and drive the flow of the first business process state according to the preset first state transition rules. The second state machine management module is used to manage the set of second business process states corresponding to the buyer role, and drive the flow of the second business process states according to the preset second state transition rules. The state dependency and access control module, which is communicatively connected to both the first state machine management module and the second state machine management module, is configured as follows: Real-time monitoring of the status of the first business process and the status of the second business process; Based on the collaborative dependency relationship between the first business process state and the second business process state, the set of operation permissions provided to the seller role and the buyer role is dynamically determined and locked; wherein, the collaborative dependency relationship defines the constraint on the operation permissions of the other role when the state of either role is a specific value; The visualization interface rendering module, connected to the state dependency and permission control module, is used to render and update the user interface presented to the seller role and the buyer role in real time according to the currently dynamically determined set of operation permissions. The executable operation controls in the user interface are matched with the set of operation permissions.

2. The multi-role collaborative receiving and shipping process control system as described in claim 1, characterized in that, The first business process state set includes a subset of states related to transportation arrangements; the state dependency and access control module is further configured to allow triggering of a state transition event pointing to the pickup completion state only when the first business process state is in the subset of states related to transportation arrangements.

3. The multi-role collaborative receiving and shipping process control system as described in claim 2, characterized in that, The subset of states related to transportation arrangement includes at least the "vehicle found" state; the state dependency and access control module is configured to dynamically unlock the receiving-related operation permissions for the buyer role in response to the first business process state transitioning to the "vehicle found" state.

4. The multi-role collaborative receiving and shipping process control system as described in claim 3, characterized in that, The subset of states related to transportation vehicle arrangement also includes states that are refined from the "vehicle found" state and used to represent the number of transportation vehicles, including "one vehicle" state and "multiple vehicles" state; the state dependency and permission control module is configured to dynamically control the receiving operation permission provided to the buyer role to be "full receipt" or "partial receipt" depending on whether the current state is "one vehicle" or "multiple vehicles".

5. The multi-role collaborative receiving and shipping process control system as described in claim 1, characterized in that, The second business process status set includes at least the pending receipt status, the partial receipt status, and the completed status.

6. The multi-role collaborative receiving and shipping process control system as described in claim 1, characterized in that, The system also includes a state synchronization engine, which, based on an event-driven mechanism, triggers the state dependency and permission control module to recalculate permissions in real time when the state of the first business process or the state of the second business process changes, and triggers the visualization interface rendering module to update the interface.

7. The multi-role collaborative receiving and shipping process control system as described in claim 1, characterized in that, The state dependency and access control module is further configured to: select a set of collaborative dependencies between the application and the business mode according to a preset business mode configuration; wherein, the business mode includes at least the cash-on-delivery mode and the freight-bearing party difference mode.

8. A method for controlling a multi-role collaborative receiving and shipping process, characterized in that, The method, applied to the system as described in any one of claims 1 to 7, comprises: The business process states of the seller and buyer roles are managed separately through independent first and second state machines; Real-time monitoring of the current business process status of both parties' roles; Based on predefined dependency rules that are based on the state collaboration of both parties, the operation permissions of both parties' roles are dynamically calculated and locked. Based on the calculated operation permissions, the user interface presented to both roles is rendered and updated in real time, so that the interface operation controls are precisely matched with the currently available permissions.

9. The multi-role collaborative receiving and shipping process control method as described in claim 8, characterized in that, Dynamically calculate operation permissions based on predefined dependency rules, including: determining whether the current value of the seller's status meets preset conditions; if not, disabling operation controls related to receiving goods completion on the buyer's interface.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in claim 8 or 9.

Images