A cross-market demand transfer method, device and equipment

Abstract

The application discloses a cross-market demand transfer method, device and equipment, checks and screens out a legal draft of a transferor, creates a to-be-received confirmation transfer order after ISCM callback creation after market level lock verification; if a receiver refuses, the transfer order is cancelled, and if the receiver accepts, a receiver order is generated through a document level lock and SAP exception exemption, and the transfer order is written back; according to a deposit configuration, the flow is divided: the deposit path pushes a deposit order, if not paid, it is rolled back in both directions, if successful, it triggers allocation; the OA path pushes an effective period, if not passed, it is rolled back, if passed, it is checked for overdue, if overdue, it is intercepted, cancelled and rolled back, otherwise, the receiver order is synchronized to trigger allocation; after ISCM completes callback, the state is pre-verified and the transaction boundary is verified, the transfer order and the receiver order are verified message by message, and after passing, the quantity, state and push update are completed. The application can solve the technical problems of lack of asynchronous callback management, inability to automatically roll back, parallel logic confusion, inability to cope with differentiated deposit policies and lack of flexibility of exception rules.

Description

Technical Field

[0001] This application relates to the field of retail ordering systems, and more particularly to a method, apparatus, and equipment for cross-market demand transfer. Background Technology

[0002] In the global retail system, there is often a structural imbalance between inventory and demand across different markets: some markets have excess purchases or slow-moving inventory of a particular product, while other markets have a demand gap for the same product. Demand transfer transactions are used to transfer purchases or inventory demand from the transferring market to the receiving market, thereby allocating product resources between different markets. A complete demand transfer involves multiple external systems, including the transferor, the receiving party, inventory allocation, restricted allocation control, approval, and settlement, and goes through several orderly stages, such as initiation, waiting for receipt, approval or deposit, completion of allocation, and cancellation due to abnormalities.

[0003] Traditional cross-inventory transfer systems typically design the transfer process as a three-stage linear structure of "submit-wait-complete," relying on operations personnel to manually track the execution status of each transfer. Approval conclusions are often manually entered into the system, lacking automated callback mechanisms. While this approach works in scenarios with a single system and unidirectional flow, its limitations become increasingly apparent in complex business scenarios like demand transfers that span multiple systems and stages, where the timing of external callbacks is uncontrollable. It struggles to support precise control over the entire lifecycle status and maintain consistent data across systems.

[0004] In summary, current cross-inventory transfer systems still have significant shortcomings. First, when handling multiple asynchronous events such as creation, cancellation, and completion callbacks from the inventory transfer system and approval callbacks from the approval system, the lack of a unified state routing and idempotent control mechanism can easily lead to out-of-order callbacks or duplicate processing, resulting in duplicate quantity accumulation. Second, when approval is rejected or transfer is cancelled, the system only updates the document status and does not automatically restore the quantities of transferred and received orders, causing permanent discrepancies in inventory data between the transferor and receiver markets. Third, when overdue returns and approval processes proceed in parallel, the logic becomes confused. Transfer orders that have been returned due to overdue periods may be incorrectly marked as valid by subsequent approval signals, resulting in unexecuted transfers. Fourth, facing differentiated deposit policies, a dynamic selection between the approval path and the deposit payment path is required after acceptance confirmation, which traditional hard-coded solutions cannot flexibly adapt to. Fifth, the rigid rejection strategy for prohibited goods cannot handle compliant businesses that have passed all audits but are temporarily prohibited from distribution only due to specific certification requirements. Sixth, in high-concurrency scenarios, the same batch of drafts may be submitted repeatedly, and the same transfer order may be received concurrently, resulting in data errors caused by the duplicate accumulation of order quantities. Summary of the Invention

[0005] This application provides a method, apparatus, and equipment for cross-market demand transfer, which addresses the technical problems of existing technologies, such as the lack of unified management for multi-path asynchronous callbacks, the inability to automatically roll back in case of allocation anomalies, chaotic parallel logic, inability to cope with differentiated deposit policies, and the lack of flexibility in SAP's disallowance rules, resulting in poor efficiency and effectiveness in actual cross-market demand transfer.

[0006] In view of this, the first aspect of this application provides a method for cross-market demand transfer, comprising:

[0007] The legitimate draft is selected from the initial Excel draft imported by the transferor through a serial fault-tolerant verification chain. The submission status of the legitimate draft is verified by adding a market-level lock. If it passes, the ISCM is called to process the application and the EOS is called back to create a transfer order and the status is set to pending acceptance confirmation. If the call to the ISCM fails, the entire process is rolled back.

[0008] If the recipient's status is set to "reject acceptance", the ISCM is notified to cancel the transfer order. If the recipient's status is set to "accept transfer", a recipient order is generated through document-level locking and SAP disallowed exemption verification mechanism, and the corresponding order number is written back to the transfer order.

[0009] If the deposit payment process is enabled based on the deposit configuration of the recipient, SAP will be pushed to create a deposit order and execute the deposit payment. If the payment is unsuccessful, the status will be set to deposit unpaid, triggering a two-way rollback. If the payment is successful, ISCM transfer will be triggered.

[0010] If the OA approval process is enabled based on the deposit configuration, an OA document containing the approval validity period is pushed. If the OA fails the callback, a two-way rollback is triggered. If the OA passes the callback, it is checked whether the transfer order is overdue. If it is overdue, the callback is blocked, the transfer order is canceled, and a two-way rollback is triggered. If it is not overdue, the recipient's order is synchronized, and an ISCM transfer is triggered.

[0011] If the ISCM transfer is triggered, after the ISCM completes the callback to EOS, based on the state pre-verification mechanism and transaction boundaries, message-by-message information verification is performed according to the transfer order, the recipient order, and the SKU. If the verification passes, quantity synchronization, state synchronization, and push update are performed.

[0012] Preferably, the step involves filtering out legitimate drafts from the initial Excel drafts imported by the transferor using a serial fault-tolerant verification chain, verifying the submission status of the legitimate drafts by adding a market-level lock, and if successful, calling ISCM to process the application and calling back EOS, creating a transfer order, and setting the status to pending acceptance confirmation. If the call to ISCM fails, the entire process is rolled back, including:

[0013] The initial Excel draft imported by the transferor is subjected to basic non-empty verification, receiver inventory organization verification, prohibition of self-transfer of the same inventory verification, transfer type quantity verification, SAP disallowed exemption verification and real-time specification verification through a serial fault-tolerant verification chain. The draft that passes the verification is selected as the legal draft.

[0014] The transferor adds a market-level lock to the valid draft based on the transferor's market code. If the locking fails, an exception message is returned. If the locking succeeds, the ISCM interface is called to submit a transfer application.

[0015] After the ISCM receives and processes the transfer request, it calls the EOS interface callback to create a transfer order and sets the status to pending confirmation.

[0016] If the ISCM call fails, a full rollback operation is triggered.

[0017] Preferably, if the recipient's status is set to "reject acceptance," the ISCM is notified to cancel the transfer order; if the recipient's status is set to "accept transfer," a recipient order is generated through document-level locking and the SAP disallowed exemption verification mechanism, and the corresponding order number is written back to the transfer order, including:

[0018] S1: If the recipient refuses to accept, the status is set to "reject" and the transfer order is cancelled by notifying the ISCM via an MQ message;

[0019] S2; If the recipient confirms receipt, the status is set to "receive transfer", and the concurrency of the transfer order is verified by adding a document-level lock. If the verification is successful, proceed to S3.

[0020] S3: Use the SAP disallowed-distribution exemption verification mechanism to verify the current status, overall disallowed-distribution status, and line-by-line disallowed-distribution status of the transfer order, and generate the receiving order;

[0021] S4: Write back the order number corresponding to the recipient's order to the transfer order.

[0022] Preferably, if the OA approval process is activated based on the deposit configuration, an OA document containing the approval validity period is pushed. If the OA fails the callback, a two-way rollback is triggered. If the OA passes the callback, it is checked whether the transfer order is overdue. If overdue, the callback is blocked, the transfer order is canceled, and a two-way rollback is triggered. If not overdue, the recipient's order is synchronized, and an ISCM transfer is triggered, including:

[0023] If the OA approval process is determined to be enabled based on the deposit configuration, an OA document containing the approval validity period will be pushed, and a callback will be awaited.

[0024] If the callback result is that the OA fails, a two-way rollback is triggered.

[0025] If the callback result is OA approved, then check whether the transfer order is in the business overdue cancellation state. If so, then intercept the callback EOS, cancel the transfer order, and trigger a two-way rollback.

[0026] If the business is not overdue, calculate and verify the return date, set the status to approved, synchronize the recipient's order, and trigger ISCM transfer.

[0027] Preferably, if the ISCM transfer is triggered, after the ISCM completes the callback to EOS, based on the state pre-verification mechanism and transaction boundaries, message-by-message information verification is performed according to the transfer order, the recipient order, and the SKU. If the verification passes, quantity synchronization, state synchronization, and push update are performed, including:

[0028] If the ISCM transfer is triggered, the order transfer is executed through the ISCM, and then the EOS interface is called to implement the ISCM completion callback;

[0029] Based on the transfer order, the recipient's order, and the SKU location transfer order details;

[0030] Based on the state pre-verification mechanism and transaction boundary, the transfer order details are verified message by message according to the information verification rules.

[0031] If the verification passes, the number of orders for the transferor and the number of orders for the recipient will be updated based on the actual transfer volume.

[0032] Set the status of the transfer order to ISCM completion callback;

[0033] Push SAP updates market orders and push ISCM internal updates order information.

[0034] Preferably, if the ISCM transfer is triggered, an ISCM completion callback is executed based on a state pre-verification mechanism and transaction boundaries. Furthermore, a message-by-message preset information existence verification is performed based on the transfer order, the recipient order, and the SKU. If the verification passes, quantity synchronization, state synchronization, and push updates are performed. Prior to this, the process also includes:

[0035] If the bidirectional rollback is triggered, the order quantities for the transferor and the recipient will be restored respectively, a change record will be generated, and SAP will be pushed to release the quota.

[0036] A second aspect of this application provides a cross-market demand transfer device, comprising:

[0037] The order generation unit is used to filter out the legal drafts from the initial Excel drafts imported by the transferor through a serial fault-tolerant verification chain, and verify the submission status of the legal drafts by adding a market-level lock. If the submission is successful, the ISCM is called to process the application and the EOS is called back to create a transfer order and the status is set to pending acceptance confirmation. If the ISCM call fails, the entire process is rolled back.

[0038] The order confirmation unit is used to notify the ISCM to cancel the transfer order if the recipient's status is set to "reject acceptance" and if the recipient's status is set to "accept transfer", to generate a recipient order through document-level locking and SAP disallowed exemption verification mechanism and write the corresponding order number back to the transfer order.

[0039] The deposit payment unit is used to push SAP to create a deposit order and execute the deposit payment if the deposit payment process is determined to be enabled based on the deposit configuration of the recipient. If the payment is unsuccessful, the status is set to deposit unpaid, triggering a two-way rollback. If the payment is successful, ISCM transfer is triggered.

[0040] The OA approval unit is used to push an OA document containing the approval validity period if the OA approval process is determined to be enabled based on the deposit configuration. If the OA fails the callback, a two-way rollback is triggered. If the OA passes the callback, the transfer order is checked for overdue. If it is overdue, the callback is intercepted, the transfer order is canceled, and a two-way rollback is triggered. If it is not overdue, the recipient's order is synchronized, and an ISCM transfer is triggered.

[0041] The callback verification unit is used to perform message-by-message information verification based on the transfer order, the recipient order, and the SKU after the ISCM completes the callback EOS if the ISCM transfer is triggered. If the verification passes, quantity synchronization, status synchronization, and push update are performed.

[0042] Preferably, the order generation unit is specifically used for:

[0043] The initial Excel draft imported by the transferor is subjected to basic non-empty verification, receiver inventory organization verification, prohibition of self-transfer of the same inventory verification, transfer type quantity verification, SAP disallowed exemption verification and real-time specification verification through a serial fault-tolerant verification chain. The draft that passes the verification is selected as the legal draft.

[0044] The transferor adds a market-level lock to the valid draft based on the transferor's market code. If the locking fails, an exception message is returned. If the locking succeeds, the ISCM interface is called to submit a transfer application.

[0045] After the ISCM receives and processes the transfer request, it calls the EOS interface callback to create a transfer order and sets the status to pending confirmation.

[0046] If the ISCM call fails, a full rollback operation is triggered.

[0047] Preferably, the order confirmation unit is specifically used for:

[0048] S1: If the recipient refuses to accept, the status is set to "reject" and the transfer order is cancelled by notifying the ISCM via an MQ message;

[0049] S2; If the recipient confirms receipt, the status is set to "receive transfer", and the concurrency of the transfer order is verified by adding a document-level lock. If the verification is successful, proceed to S3.

[0050] S3: Use the SAP disallowed-distribution exemption verification mechanism to verify the current status, overall disallowed-distribution status, and line-by-line disallowed-distribution status of the transfer order, and generate the receiving order;

[0051] S4: Write back the order number corresponding to the recipient's order to the transfer order.

[0052] A third aspect of this application provides a cross-market demand transfer device, the device comprising a processor and a memory;

[0053] The memory is used to store program code and transmit the program code to the processor;

[0054] The processor is used to execute the cross-market demand transfer method described in the first aspect according to the instructions in the program code.

[0055] As can be seen from the above technical solutions, the embodiments of this application have the following advantages:

[0056] This application provides a method for cross-market demand transfer, including: filtering out valid drafts from the initial Excel drafts imported by the transferor through a serial fault-tolerant verification chain; verifying the submission status of valid drafts by adding a market-level lock; if successful, calling ISCM to process the application and calling back EOS, creating a transfer order, and setting the status to pending acceptance confirmation; if the ISCM call fails, rolling back the entire process; if the recipient's status is set to reject acceptance, notifying ISCM to cancel the transfer order; if the recipient's status is set to accept transfer, generating a recipient order through document-level locks and SAP's disallowed exemption verification mechanism, and writing the corresponding order number back to the transfer order; if the deposit payment process is determined to be enabled based on the recipient's deposit configuration, pushing SAP to create a deposit order for execution. If the deposit payment fails, the status will be set to "Deposit Unpaid," triggering a two-way rollback. If the payment is successful, an ISCM transfer will be triggered. If the OA approval process is enabled based on the deposit configuration, an OA document containing the approval validity period will be pushed. If the OA fails the callback, a two-way rollback will be triggered. If the OA passes the callback, the transfer order will be checked for expiration. If it is expiration, the callback will be intercepted, the transfer order will be canceled, and a two-way rollback will be triggered. If it is not expiration, the receiving order will be synchronized, triggering an ISCM transfer. If an ISCM transfer is triggered, after the ISCM completes the callback to EOS, based on the status pre-verification mechanism and transaction boundaries, message-by-message information verification will be performed according to the transfer order, receiving order, and SKU. If the verification passes, quantity synchronization, status synchronization, and push updates will be performed.

[0057] The cross-market demand transfer method provided in this application employs a serial fault-tolerant verification chain to validate the initial Excel draft, followed by market-level lock verification of the submission status. Fault-tolerant verification intercepts illegal data, while market-level locks ensure that drafts from the same market are not submitted concurrently. Furthermore, a complete rollback occurs upon ISCM failure, guaranteeing consistency between local and external systems and overcoming concurrency conflicts. Upon recipient confirmation, a document-level lock prevents concurrent receipt of the same transfer order. The recipient's order is only generated after verification using SAP's exclusion exemption mechanism. This approach eliminates duplicate receipts and enables flexible and compliant control through the exclusion exemption mechanism. The order number write-back operation establishes a link between the transfer order and the recipient's order, providing a data foundation for subsequent rollbacks. Moreover, it allows for two paths—deposit payment or OA approval—based on the recipient's deposit configuration, accommodating differentiated deposit policies. Additionally, in cases of unpaid deposits or OA failures, a unified two-way rollback can be triggered to accurately restore the quantities of both the transferor's and recipient's orders, eliminating inventory discrepancies between the two markets. Furthermore, when the OA system initiates a callback, it first checks if the transfer order is overdue. If overdue, the callback is blocked, the transfer order is canceled, and a two-way rollback is triggered. This process avoids returned orders being incorrectly marked as valid by late approvals, overcoming the chaotic logic of handling exceptions involving conflicts between overdue and approval processes. In addition, after completing the callback, the ISCM performs message-by-message verification based on pre-verification of status and transaction boundaries, categorized by transfer order, recipient order, and SKU. Pre-verification of status intercepts duplicate callbacks, and transaction boundaries ensure atomic processing. After successful verification, quantity synchronization, status synchronization, and push updates are uniformly completed, ultimately ensuring the transfer order is archived and that the data from both parties matches the physical transfer. The entire process achieves coordinated management of multi-path asynchronous callbacks from ISCM, OA, and SAP, addressing issues of out-of-order and duplicate callbacks. Therefore, this application solves the technical problems of existing technologies, such as the lack of unified management for multi-path asynchronous callbacks, the inability to automatically roll back in case of transfer anomalies, chaotic parallel logic, inability to handle differentiated deposit policies, and the lack of flexibility in SAP's disallowed allocation rules, resulting in poor efficiency and effectiveness in actual cross-market demand transfers. Attached Figure Description

[0058] Figure 1 A flowchart illustrating a cross-market demand transfer method provided for an embodiment of this application;

[0059] Figure 2 A schematic diagram of a cross-market demand transfer device provided in this application embodiment;

[0060] Figure 3 An example diagram illustrating the overall judgment process for cross-market demand transfer provided in this application embodiment. Detailed Implementation

[0061] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0062] This application relates to the field of supply chain management and ordering systems for global retail enterprises, particularly to the fully automated orchestration of cross-market commodity demand transfers, multi-path external system callback processing, and data consistency assurance in abnormal scenarios.

[0063] Terminology Explanation:

[0064] Demand Transfer: In the global retail system, this is a business activity in which one market (the transferor) transfers its demand for goods in bulk or inventory to another market (the receiving party) to allocate goods resources between different markets.

[0065] New Transfer Type: An enumeration that distinguishes transfer transactions: 10 = Futures Non-Customized In-Stock Transfer, 20 = Futures Non-Customized In-Stock Transfer, 30 = Futures Customized In-Stock Transfer, 40 = Global Supply Customized In-Stock Transfer, 50 = Global Supply Non-Customized In-Stock Transfer, 60 = Futures Customized In-Stock Transfer, 70 = Futures Shared Non-Customized In-Stock Transfer.

[0066] SAP Status: The availability status of a product in the target market, synchronized from the SAP system. 0 indicates normal availability, while non-zero indicates that the product is prohibited from being delivered.

[0067] Certification_allow: An exemption mechanism for SAP-restricted products. When a product meets all four criteria of copyright, quality, operation, and category, the certification gate is triggered, and a whitelist record exists, it is allowed to bypass SAP's restrictions for transfer.

[0068] OA Approval System: An internal workflow approval platform for enterprises. After receiving confirmation, EOS pushes the transfer order to OA for approval by operations / category personnel. The OA approval result is fed back to the ordering system EOS through a callback interface.

[0069] ISCM (Inventory Collaboration Management System): An external system responsible for the actual execution of cross-market inventory transfers. EOS submits transfer requests to ISCM, and after processing, ISCM notifies the ordering system of the application result, transfer completion result, or cancellation result via callback.

[0070] Distributed Lock Handler: A distributed mutex lock implemented based on Redis, used to prevent concurrent duplicate operations of transfer commit and receive confirmation.

[0071] • Deposit Configuration (McDepositConfig): Configures whether deposit payment is enabled by country code, which affects subsequent process branches after confirmation of receipt.

[0072] Rollback: After a transfer is rejected / cancelled, the system automatically restores the atomic operations of the transferor and receiver order quantities.

[0073] For easier understanding, please refer to Figure 1 An embodiment of a cross-market demand transfer method provided in this application includes:

[0074] Step 101: Select a valid draft from the initial Excel draft imported by the transferor through a serial fault-tolerant verification chain. Verify the submission status of the valid draft by adding a market-level lock. If it passes, call ISCM to process the application and call back EOS, create a transfer order, and set the status to pending acceptance confirmation. If the call to ISCM fails, roll back the entire process.

[0075] Further, step 101 includes:

[0076] The initial Excel draft imported by the transferor is subjected to basic non-empty verification, receiver inventory organization verification, prohibition of self-transfer of the same inventory verification, transfer type quantity verification, SAP disallowed exemption verification and real-time specification verification through a serial fault-tolerant verification chain. The draft that passes the verification is selected as the legal draft.

[0077] Based on the transferor's market code being a valid draft, a market-level lock is added. If the locking fails, an exception message is returned. If the locking succeeds, the ISCM interface is called to submit a transfer application.

[0078] After ISCM receives and processes the transfer request, it calls the EOS interface callback to create a transfer order and sets the status to pending confirmation.

[0079] If the ISCM call fails, a full rollback operation is triggered.

[0080] It should be noted that, to facilitate the execution of the method in this embodiment within the system, this embodiment designs a state machine covering the entire lifecycle of demand transfer, with a total of 11 states. Specifically, these include: **Pending Recipient Confirmation (Status Code 10):** Triggered by the ISCM callback `dealIscmData`, the transfer order is formally created, awaiting the recipient's market action; **Recipient Rejection (Status Code 20):** The recipient actively rejects the transfer; **Recipient Confirmation (Status Code 30):** The recipient confirms acceptance of the order, triggering the generation of a recipient order and pushing it to the ISCM; **Approval in Progress (Status Code 31):** After the recipient confirms acceptance but does not initiate the deposit payment process, OA approval is successfully pushed, awaiting OA callback; **Deposit Not Paid or Deposit Payment Cancelled (Status Code 40):** When the deposit payment path is enabled, the recipient fails to complete the process within the specified time. For deposit payments, the system automatically cancels the deposit payment; for approval failure status, status code 50, the OA callback returns approval rejection, indicating that the OA was not approved, or the ISCM actively canceled the application, in which case reqType ≠ 1; for overdue status, status code 60, the ISCM cancellation callback is in progress, in which case reqType = 1, indicating that the overdue application will be automatically returned after the deadline of the 25th of each month; for approved status, status code 70, the OA callback returns approval, indicating that the OA was approved, and the return date needs to be updated synchronously; for completed order transfer status 71, the callback is completed after the ISCM execution, transferType = 1; for completed transfer status 72, the callback is completed after the ISCM execution, transferType = 2; for ISCM completion callback status 80, the ISCM execution completion callback was successfully processed, and the transfer order is finally archived.

[0081] The transferor can import the initial Excel draft through the import port of the ordering system EOS, and then perform a legality check on the initial Excel draft through a serial fault-tolerant verification chain. The draft that passes the check is a legal draft. The serial fault-tolerant verification chain includes, but is not limited to, multiple verification processes such as basic non-empty verification, receiver inventory organization verification, prohibition of self-transfer of the same inventory verification, transfer type quantity verification, SAP disallowed exemption verification, and real-time specification verification.

[0082] The basic non-empty verification ensures consistency across the transferring market, including verifying that transferType, SKUCode, and recipient market code are not empty, and that the quantity field format is valid. Recipient inventory organization verification queries the recipient market's inventory organization, automatically assigning values ​​for single organizations and verifying the validity of values ​​for multiple organizations. The prohibition of self-transfer within the same inventory is designed for self-transfers between organizations within the same market, preventing data loops caused by such transfers. Transfer type quantity verification ensures that the transferred goods are entered in the required format. SAP disallowed / exempted verification includes both SAP disallowed / exempted mechanisms and certification gate-specific exemption mechanisms, prohibiting the transfer of certain goods, except for those on the certification gate-specific exemption whitelist. Real-time specification verification comprehensively considers transfer type, packaging specifications of both parties, and cross-warehouse flags when configuring the shipping method, preventing invalid data from entering the application process at the source.

[0083] The market code generated based on the operating mechanism of the market where the transferor is located can add a market-level lock to a valid draft, which is a two-granularity distributed lock. If locking fails, i.e., in a non-blocking state, verification fails, and an exception message of "duplicate transfer application" should be returned immediately without waiting or retrying. This is considered an ISCM call failure, and a complete rollback is sufficient. Locking verification can prevent valid operations from being submitted repeatedly.

[0084] If the ISCM is successfully invoked through the ISCM interface, and the ISCM successfully receives and processes the transfer request, the EOS interface callback of the ordering system can be invoked. After receiving the callback, EOS creates a transfer order and sets the status of the transfer order to status 10, pending confirmation from the recipient.

[0085] Step 102: If the recipient's status is set to "reject acceptance", then notify ISCM to cancel the transfer order. If the recipient's status is set to "accept transfer", then generate a recipient order through document-level locking and SAP disallowed exemption verification mechanism, and write the corresponding order number back to the transfer order.

[0086] Further, step 102 includes:

[0087] S1: If the recipient refuses to accept, the status is set to "reject" and the transfer order is cancelled by notifying the ISCM via MQ message;

[0088] S2; If the recipient confirms receipt, the status is set to "received transfer", and the concurrency of the transfer order is verified by adding a document-level lock. If the verification is successful, proceed to S3.

[0089] S3: Use the SAP disallowed-distribution exemption verification mechanism to verify the current status of the transfer order, the overall disallowed-distribution status, and the line-by-line disallowed-distribution status, and generate the receiving order;

[0090] S4: Write the order number corresponding to the recipient's order back to the transfer order.

[0091] It should be noted that the transfer order generated by the transferor is in status 10, which is pending confirmation from the receiver. If the receiver refuses to accept, the transfer order status is set to rejection status 20. Then, the ISCM is notified via MQ message to cancel the transfer order already generated by the transferor, which is now in the receiver rejection status. This does not trigger a two-way rollback because the receiver has not yet generated the relevant order; it is merely changing the status of the transfer order.

[0092] If the recipient acknowledges acceptance, the transfer order status is set to Confirmed Acceptance Status 30. A document-level lock can be added to verify if multiple transfer orders are being received concurrently, preventing the same transfer order from being received by multiple recipients and avoiding duplicate order counts. The next transfer order operation will only be triggered after the verification passes. The document-level lock provides finer granularity compared to the market-level lock during the application submission process.

[0093] The transfer order that passes the verification needs to undergo multiple verifications based on the SAP disallowed exemption verification mechanism. Specifically, the current status of the transfer order, the disallowed status of the entire order, and the disallowed status of each line are verified. Once all verifications pass, the receiving order can be generated. By writing back the order number corresponding to the receiving order to the transfer order, the receiving order and the transfer order can be associated, which facilitates the association and analysis.

[0094] Specifically, status verification checks whether the transfer order is currently in a pending confirmation state through a query; if so, the verification passes. The entire order is rejected if any smallest stock keeping unit (SKU) is found to be a restricted item or on the restricted list. Row-by-row restricted status verification includes maintaining and verifying the shipment information of the transfer order. If the verification fails, it does not proceed to subsequent verifications; if it passes, from the recipient's perspective, the SAP restricted status mechanism and the authentication gate exemption mechanism are executed again, forming double protection with the initiation. After all SKUs are verified, errors are accumulated and returned uniformly, and a rollback operation is performed, disallowing partial acceptance. If all verifications pass, a recipient market order is generated, which includes an order line, a market order, and a summary order. The recipient order's order number is written back to the transfer order, and then the recipient market order number is pushed to ISCM for confirmation, with the status set to 30, indicating confirmed acceptance.

[0095] The SAP disallowed exemption verification mechanism in this embodiment is an SAP disallowed and authentication gate special exemption mechanism. This mechanism can be used in the EOS application initiation import, draft editing and acceptance confirmation stages, forming a double or even multiple protection throughout the process. For SAP disallowed products, the transfer is refused; however, if the product passes the copyright, quality, operation and category verification at the same time, it is specially allowed to pass as a special exemption whitelist. This allows compliant products to be transferred normally, which is more flexible and better meets the needs of market goods dispatch.

[0096] Step 103: If the deposit payment process is enabled based on the deposit configuration of the recipient, SAP will be pushed to create a deposit order and execute the deposit payment. If the payment is unsuccessful, the status will be set to deposit unpaid, triggering a two-way rollback. If the payment is successful, ISCM transfer will be triggered.

[0097] After generating the receiving order, the subsequent transfer processing begins. Here, different processing flows can be selected based on the different deposit configuration rules in the market, specifically including the deposit payment process and the OA approval process. Let's first analyze the deposit payment process. At this point, SAP can be pushed to create a deposit order. The closed loop is driven by SAP deposit callbacks. If the deposit has already been paid, it is routed according to the transfer type, such as shared type or transfer within the same market, and then enters the approval status, triggering ISCM to allocate the actual goods. If the deposit has not been successfully paid, it is generally due to payment overdue resulting in deposit payment cancellation. In this case, the status can be set to 40. If the deposit payment is not completed, the transfer operation needs to be cancelled, triggering a two-way rollback for both parties.

[0098] Step 104: If the OA approval process is enabled based on the deposit configuration, an OA document containing the approval validity period will be pushed. If the OA fails the callback, a two-way rollback will be triggered. If the OA passes the callback, the transfer order will be checked for overdue status. If overdue, the callback will be intercepted, the transfer order will be canceled, and a two-way rollback will be triggered. If not overdue, the receiving party's order will be synchronized, and an ISCM transfer will be triggered.

[0099] Further, step 104 includes:

[0100] If the OA approval process is enabled based on the deposit configuration, an OA message containing the approval validity period will be pushed, and a callback will be waited for.

[0101] If the callback result is that the OA fails, a two-way rollback is triggered.

[0102] If the callback result is OA approved, then check whether the transfer order is in the business overdue cancellation state. If so, then intercept the callback EOS, cancel the transfer order, and trigger a two-way rollback.

[0103] If the business is not overdue, calculate and verify the return date, set the status to approved, synchronize the receiving party's order, and trigger ISCM transfer.

[0104] It should be noted that if the deposit configuration based on the market determines to enable the OA approval process, the system will enter the approval process (state 31). This means that an OA document containing the approval validity period will be pushed and the system will enter the state of awaiting the approval result. The approval validity period stipulates that the OA document is only valid if it is called back within a limited time. Otherwise, it is considered to be overdue, and the callback result is considered to be that the OA document is not approved, the transfer is terminated, and a two-way rollback is triggered. At this time, the status is set to approval failure (state 50). If the OA document is called back within the approval validity period and the callback result is that the OA document is approved, it is necessary to further verify whether the transfer order is in the overdue cancellation state (state 60). If so, it is necessary to intercept the OA document approval callback (EOS), cancel the transfer order, and trigger a two-way rollback. If the OA document is called back within the approval validity period and the callback result is that the OA document is not approved, the status can be directly set to approval time change (state 50).

[0105] In this embodiment, the approval validity period is the OA (Office Automation) approval time limit, which can be set according to actual conditions. For example, it can be calculated as 7 days from the current date; if this time is exceeded, the OA approval will not pass. The "overdue" status of a business order cancellation refers to the business deadline, such as the 25th of the current month. Verifying the overdue cancellation status is to prevent the ISCM (Independent Software Management System) from calling back the overdue cancellation request first, while a late OA approval is also called back, leading to the system incorrectly restoring the order to a valid state. This operation intercepts late OA requests via callback and cancels the transfer order according to the overdue cancellation standard, ensuring a clear logical connection in the operating mechanism and preventing operational errors. Furthermore, if the status is overdue cancellation, an ISCM cancellation notification needs to be pushed again after the rollback operation; for normal cancellation, the ISCM actively cancels the order, and a duplicate push is not required.

[0106] If all verifications pass without delay, and an OA approval callback is received, the return date is calculated and verified, the status is set to Approved 70, the readiness date of the receiving order is synchronized, and an ISCM transfer is triggered via MQ message. Specifically, the receiving order can query its order line and summary order, calculate and verify the return date based on this, comprehensively consider the transferor's order information in the transfer order, update the transfer order status to 70, set the approval time and product readiness date, and synchronize the relevant information of the receiving party; then, an Approved message is sent to SICM via MQ message to trigger product transfer.

[0107] It can be observed that regardless of whether the approval failure status is 50 or the overdue cancellation status is 60, the transfer operation needs to be cancelled and a two-way rollback needs to be performed. This ensures that the order quantity of both the transferor and the receiver is rolled back to the state before the transfer transaction. In other words, the data rollback process after the transfer failure ensures that the order quantity in each system is not affected by the transfer failure, thus maintaining the accuracy and stability of the order quantity in the system.

[0108] Step 105: If an ISCM transfer is triggered, after the ISCM completes the callback to EOS, based on the state pre-verification mechanism and transaction boundaries, message-by-message information verification is performed according to the transfer order, the recipient order, and the SKU. If the verification passes, quantity synchronization, state synchronization, and push update are performed.

[0109] Further, step 105 includes:

[0110] If an ISCM transfer is triggered, the order transfer will be executed through ISCM, and then the EOS interface will be called to implement the ISCM completion callback.

[0111] Based on the transfer order, the recipient's order, and the SKU location transfer order details;

[0112] Based on the state pre-verification mechanism and transaction boundaries, the transfer order details are verified message by message according to the information verification rules.

[0113] If the verification passes, the number of orders for the transferor and the number of orders for the recipient will be updated based on the actual transfer volume.

[0114] Set the status of the transfer order to ISCM completion callback;

[0115] Push SAP updates market orders and push ISCM internal updates order information.

[0116] It should be noted that approval status 70 triggers ISCM to execute the transfer of goods orders, realizing the transfer of goods according to the relevant order information of the recipient and the transferor; after the transfer of goods is completed, the EOS interface is called to realize the ISCM callback. Then, based on the transfer order and the recipient's order, multiple existence checks and status checks are independently performed on each SKU message. Specifically, a unique transfer order detail can be located by the order number of the transfer order, the summary order number in the recipient's order, and the SKU. Then, the information of the transfer order detail is checked message by message. The verification process must meet the requirements of the status pre-verification mechanism and transaction boundary. That is, before the operation, it is necessary to check whether the current status is a non-prohibited transfer ISCM completion callback status. If so, it can be executed. If not, that is, the ISCM completion callback completes the prohibited transfer, the quantity accumulation caused by repeated ISCM callbacks is intercepted to achieve idempotent protection and ensure that only documents in the expected status are processed, and other statuses are rejected.

[0117] The verification operations based on information verification rules include: verification of the existence of transfer orders to prevent ghost orders; verification of completed transfers to prevent duplicate orders from accumulating; verification of the existence of the recipient's aggregated orders to ensure that the recipient's orders have been correctly created; verification of the existence of the transferor's orders to ensure the integrity of the transferor's inventory data; verification of the existence of the recipient's order lines to ensure that the recipient's order lines have been generated; and verification of the existence of product information to ensure that the basic product information is the basis for calculation.

[0118] If all verifications pass, the transferor and receiver order quantities can be updated based on the actual transfer volume from ISCM. For transferor order quantities, the successfully transferred quantities are accumulated, the in-transit transfer quantities are cleared, and the current quantities are replenished. For receiver order quantities, the receiving quantities are reduced, the current demand is increased, and the quantities are allocated to the corresponding purchase plan quantities or inventory lock quantities according to the order / inventory type. The order data from both the transfer and receiving markets must be consistent with the ISCM physical transfer results. In addition, the transfer status must be set to ISCM completed callback status 80, and the summary table must be archived synchronously. SAP updates market orders are pushed externally, and ISCM updates internal orders are pushed. For the overall cross-market demand transfer process, please refer to [link to relevant documentation]. Figure 3 .

[0119] Furthermore, step 105, preceding the following, also includes:

[0120] If a two-way rollback is triggered, the order quantities for both the transferor and the recipient will be restored, change records will be generated, and SAP will be pushed to release the quota.

[0121] The triggered bidirectional rollback operation is a data restoration operation triggered by abnormal termination of the transfer. This operation is triggered in cases of deposit payment failure, approval failure, and overdue cancellation of business. The actual system uses the `status` parameter value to precisely determine whether to rollback; if so, the bidirectional rollback operation is executed atomically. For the recipient, the rollback restores the recipient's order quantity, generates a cancellation transfer change record, pushes SAP to release the quota, and triggers an internal ISCM order update notification for cancellation. For the transferor, the rollback restores the transferor's order quantity, generates a cancellation transfer change record, and pushes SAP to release the quota. Understandably, after a bidirectional rollback in the overdue cancellation state, an ISCM cancellation notification needs to be pushed again to ensure that the order quantities for both parties are accurately restored.

[0122] The cross-market demand transfer method provided in this application employs a serial fault-tolerant verification chain to validate the initial Excel draft, and then uses a market-level lock to verify the submission status. Fault-tolerant verification can intercept illegal data, while the market-level lock ensures that drafts from the same market are not submitted concurrently and repeatedly. Furthermore, if the ISCM call fails, the entire process is rolled back, guaranteeing consistency between the local and external systems and overcoming concurrency conflicts. Upon recipient confirmation, a document-level lock prevents the same transfer order from being received concurrently. Only after verification by the SAP exclusion exemption mechanism is the recipient's order generated. This operation not only eliminates duplicate receipts but also enables flexible and compliant control through the exclusion verification mechanism. The order number write-back operation establishes a link between the transfer order and the recipient's order, providing a data foundation for subsequent rollbacks. Moreover, it allows for two paths—deposit payment or OA approval—based on the recipient's deposit configuration, adapting to differentiated deposit policies. Additionally, in abnormal situations such as unpaid deposits or OA failures, a unified two-way rollback can be triggered to accurately restore the quantities of the transferor and recipient's orders, eliminating inventory discrepancies between the two markets. Furthermore, when the OA system initiates a callback, it first checks if the transfer order is overdue. If overdue, the callback is blocked, the transfer order is canceled, and a two-way rollback is triggered. This process avoids returned orders being incorrectly marked as valid by late approvals, overcoming the problem of chaotic exception handling logic caused by conflicts between overdue and approval processes. In addition, after completing the callback, the ISCM performs message-by-message verification based on pre-state verification and transaction boundaries, according to the transfer order, recipient order, and SKU. Pre-state verification intercepts duplicate callbacks, and transaction boundaries ensure atomic processing. After successful verification, quantity synchronization, status synchronization, and push updates are uniformly completed, ultimately ensuring the transfer order is archived and the data of both parties is consistent with the physical transfer. The entire process achieves coordinated management of multi-path asynchronous callbacks from ISCM, OA, and SAP, addressing issues of out-of-order and duplicate callbacks. Therefore, the embodiments of this application can solve the technical problems of existing technologies lacking unified management for multi-path asynchronous callbacks, failing to achieve automatic rollback in case of transfer anomalies, exhibiting chaotic parallel logic, being unable to handle differentiated deposit policies, and having inflexible SAP disallowed rules, resulting in poor efficiency and effectiveness in actual cross-market demand transfers.

[0123] For easier understanding, please refer to Figure 2 This application provides an embodiment of a cross-market demand transfer device, comprising:

[0124] The order generation unit 201 is used to filter out the legal draft from the initial draft of Excel imported by the transferor through a serial fault-tolerant verification chain, and verify the submission status of the legal draft by adding a market-level lock. If it passes, the ISCM is called to process the application and the EOS is called back to create a transfer order and the status is set to pending acceptance confirmation. If the ISCM call fails, the whole process is rolled back.

[0125] The order confirmation unit 202 is used to notify ISCM to cancel the transfer order if the recipient's status is set to "reject acceptance" and if the recipient's status is set to "accept transfer", it generates a recipient order through document-level locking and SAP disallowed exemption verification mechanism and writes the corresponding order number back to the transfer order.

[0126] The deposit payment unit 203 is used to push SAP to create a deposit order and execute the deposit payment if the deposit payment process is determined to be enabled based on the deposit configuration of the recipient. If the payment is not successful, the status is set to deposit not paid, triggering a two-way rollback. If the payment is successful, the ISCM transfer is triggered.

[0127] OA approval unit 204 is used to push an OA document containing the approval validity period if the OA approval process is determined to be enabled based on the deposit configuration. If the OA fails the callback, a two-way rollback is triggered. If the OA passes the callback, the transfer order is checked for overdue. If it is overdue, the callback is blocked, the transfer order is canceled, and a two-way rollback is triggered. If it is not overdue, the receiving order is synchronized and the ISCM transfer is triggered.

[0128] Callback verification unit 205 is used to perform message-by-message information verification based on the transfer order, recipient order and SKU after the ISCM completes the callback EOS if an ISCM transfer is triggered. If the verification passes, quantity synchronization, status synchronization and push update are performed.

[0129] Furthermore, the order generation unit 201 is specifically used for:

[0130] The initial Excel draft imported by the transferor is subjected to basic non-empty verification, receiver inventory organization verification, prohibition of self-transfer of the same inventory verification, transfer type quantity verification, SAP disallowed exemption verification and real-time specification verification through a serial fault-tolerant verification chain. The draft that passes the verification is selected as the legal draft.

[0131] Based on the transferor's market code being a valid draft, a market-level lock is added. If the locking fails, an exception message is returned. If the locking succeeds, the ISCM interface is called to submit a transfer application.

[0132] After ISCM receives and processes the transfer request, it calls the EOS interface callback to create a transfer order and sets the status to pending confirmation.

[0133] If the ISCM call fails, a full rollback operation is triggered.

[0134] Furthermore, the order confirmation unit 202 is specifically used for:

[0135] S1: If the recipient refuses to accept, the status is set to "reject" and the transfer order is cancelled by notifying the ISCM via MQ message;

[0136] S2; If the recipient confirms receipt, the status is set to "received transfer", and the concurrency of the transfer order is verified by adding a document-level lock. If the verification is successful, proceed to S3.

[0137] S3: Use the SAP disallowed-distribution exemption verification mechanism to verify the current status of the transfer order, the overall disallowed-distribution status, and the line-by-line disallowed-distribution status, and generate the receiving order;

[0138] S4: Write the order number corresponding to the recipient's order back to the transfer order.

[0139] This application also provides a cross-market demand transfer device, which includes a processor and a memory;

[0140] The memory is used to store program code and transfer the program code to the processor;

[0141] The processor is used to execute the cross-market demand transfer method in the above method embodiments according to the instructions in the program code.

[0142] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0143] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0144] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0145] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions for executing all or part of the steps of the methods described in the various embodiments of this application through a computer device (which may be a personal computer, server, or network device, etc.). The aforementioned storage medium includes: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0146] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for transferring demand across markets, characterized in that, include: The legitimate draft is selected from the initial Excel draft imported by the transferor through a serial fault-tolerant verification chain. The submission status of the legitimate draft is verified by adding a market-level lock. If it passes, the ISCM is called to process the application and the EOS is called back to create a transfer order and the status is set to pending acceptance confirmation. If the call to the ISCM fails, the entire process is rolled back. If the recipient's status is set to "reject acceptance", the ISCM is notified to cancel the transfer order. If the recipient's status is set to "accept transfer", a recipient order is generated through document-level locking and SAP disallowed exemption verification mechanism, and the corresponding order number is written back to the transfer order. If the deposit payment process is enabled based on the deposit configuration of the recipient, SAP will be pushed to create a deposit order and execute the deposit payment. If the payment is unsuccessful, the status will be set to deposit unpaid, triggering a two-way rollback. If the payment is successful, ISCM transfer will be triggered. If the OA approval process is enabled based on the deposit configuration, an OA document containing the approval validity period is pushed. If the OA fails the callback, a two-way rollback is triggered. If the OA passes the callback, it is checked whether the transfer order is overdue. If it is overdue, the callback is blocked, the transfer order is canceled, and a two-way rollback is triggered. If it is not overdue, the recipient's order is synchronized, and an ISCM transfer is triggered. If the ISCM transfer is triggered, after the ISCM completes the callback to EOS, based on the state pre-verification mechanism and transaction boundaries, message-by-message information verification is performed according to the transfer order, the recipient order, and the SKU. If the verification passes, quantity synchronization, state synchronization, and push update are performed.

2. The cross-market demand transfer method according to claim 1, characterized in that, The process involves filtering out legitimate drafts from the initial Excel drafts imported by the transferor using a serial fault-tolerant verification chain, verifying the submission status of the legitimate drafts by adding a market-level lock, and if successful, invoking ISCM to process the application and calling back EOS, creating a transfer order, and setting the status to pending acceptance confirmation. If the ISCM call fails, the entire process is rolled back, including: The initial Excel draft imported by the transferor is subjected to basic non-empty verification, receiver inventory organization verification, prohibition of self-transfer of the same inventory verification, transfer type quantity verification, SAP disallowed exemption verification and real-time specification verification through a serial fault-tolerant verification chain. The draft that passes the verification is selected as the legal draft. The transferor adds a market-level lock to the valid draft based on the transferor's market code. If the locking fails, an exception message is returned. If the locking succeeds, the ISCM interface is called to submit a transfer application. After the ISCM receives and processes the transfer request, it calls the EOS interface callback to create a transfer order and sets the status to pending confirmation. If the ISCM call fails, a full rollback operation is triggered.

3. The cross-market demand transfer method according to claim 1, characterized in that, If the recipient's status is set to "reject acceptance," the ISCM is notified to cancel the transfer order. If the recipient's status is set to "accept transfer," a recipient order is generated using document-level locking and the SAP disallowed waiver verification mechanism, and the corresponding order number is written back to the transfer order, including: S1: If the recipient refuses to accept, the status is set to "reject" and the transfer order is cancelled by notifying the ISCM via an MQ message; S2; If the recipient confirms receipt, the status is set to "receive transfer", and the concurrency of the transfer order is verified by adding a document-level lock. If the verification is successful, proceed to S3. S3: Use the SAP disallowed-distribution exemption verification mechanism to verify the current status, overall disallowed-distribution status, and line-by-line disallowed-distribution status of the transfer order, and generate the receiving order; S4: Write back the order number corresponding to the recipient's order to the transfer order.

4. The cross-market demand transfer method according to claim 1, characterized in that, If the OA approval process is activated based on the deposit configuration, an OA document containing the approval validity period is pushed. If the OA fails the callback, a two-way rollback is triggered. If the OA passes the callback, it is checked whether the transfer order is overdue. If overdue, the callback is blocked, the transfer order is canceled, and a two-way rollback is triggered. If not overdue, the recipient's order is synchronized, and an ISCM transfer is triggered, including: If the OA approval process is determined to be enabled based on the deposit configuration, an OA document containing the approval validity period will be pushed, and a callback will be awaited. If the callback result is that the OA fails, a two-way rollback is triggered. If the callback result is OA approved, then check whether the transfer order is in the business overdue cancellation state. If so, then intercept the callback EOS, cancel the transfer order, and trigger a two-way rollback. If the business is not overdue, calculate and verify the return date, set the status to approved, synchronize the recipient's order, and trigger ISCM transfer.

5. The cross-market demand transfer method according to claim 1, characterized in that, If the ISCM transfer is triggered, after the ISCM completes the callback to EOS, based on the state pre-verification mechanism and transaction boundaries, message-by-message information verification is performed according to the transfer order, the recipient order, and the SKU. If the verification passes, quantity synchronization, state synchronization, and push updates are performed, including: If the ISCM transfer is triggered, the order transfer is executed through the ISCM, and then the EOS interface is called to implement the ISCM completion callback; Based on the transfer order, the recipient's order, and the SKU location transfer order details; Based on the state pre-verification mechanism and transaction boundary, the transfer order details are verified message by message according to the information verification rules. If the verification passes, the number of orders for the transferor and the number of orders for the recipient will be updated based on the actual transfer volume. Set the status of the transfer order to ISCM completion callback; Push SAP updates market orders and push ISCM internal updates order information.

6. The cross-market demand transfer method according to claim 1, characterized in that, If the ISCM transfer is triggered, the ISCM completion callback is executed based on the state pre-verification mechanism and transaction boundary, and a message-by-message preset information existence verification is performed according to the transfer order, the recipient order, and the SKU. If the verification passes, quantity synchronization, state synchronization, and push update are performed. Prior to this, the process also includes: If the bidirectional rollback is triggered, the order quantities for the transferor and the recipient will be restored respectively, a change record will be generated, and SAP will be pushed to release the quota.

7. A device for transferring demand across markets, characterized in that, include: The order generation unit is used to filter out the legal drafts from the initial Excel drafts imported by the transferor through a serial fault-tolerant verification chain, and verify the submission status of the legal drafts by adding a market-level lock. If the submission is successful, the ISCM is called to process the application and the EOS is called back to create a transfer order and the status is set to pending acceptance confirmation. If the ISCM call fails, the entire process is rolled back. The order confirmation unit is used to notify the ISCM to cancel the transfer order if the recipient's status is set to "reject acceptance" and if the recipient's status is set to "accept transfer", to generate a recipient order through document-level locking and SAP disallowed exemption verification mechanism and write the corresponding order number back to the transfer order. The deposit payment unit is used to push SAP to create a deposit order and execute the deposit payment if the deposit payment process is determined to be enabled based on the deposit configuration of the recipient. If the payment is unsuccessful, the status is set to deposit unpaid, triggering a two-way rollback. If the payment is successful, ISCM transfer is triggered. The OA approval unit is used to push an OA document containing the approval validity period if the OA approval process is determined to be enabled based on the deposit configuration. If the OA fails the callback, a two-way rollback is triggered. If the OA passes the callback, the transfer order is checked for overdue. If it is overdue, the callback is intercepted, the transfer order is canceled, and a two-way rollback is triggered. If it is not overdue, the recipient's order is synchronized, and an ISCM transfer is triggered. The callback verification unit is used to perform message-by-message information verification based on the transfer order, the recipient order, and the SKU after the ISCM completes the callback EOS if the ISCM transfer is triggered. If the verification passes, quantity synchronization, status synchronization, and push update are performed.

8. The cross-market demand transfer device according to claim 7, characterized in that, The order generation unit is specifically used for: The initial Excel draft imported by the transferor is subjected to basic non-empty verification, receiver inventory organization verification, prohibition of self-transfer of the same inventory verification, transfer type quantity verification, SAP disallowed exemption verification and real-time specification verification through a serial fault-tolerant verification chain. The draft that passes the verification is selected as the legal draft. The transferor adds a market-level lock to the valid draft based on the transferor's market code. If the locking fails, an exception message is returned. If the locking succeeds, the ISCM interface is called to submit a transfer application. After the ISCM receives and processes the transfer request, it calls the EOS interface callback to create a transfer order and sets the status to pending confirmation. If the ISCM call fails, a full rollback operation is triggered.

9. The cross-market demand transfer device according to claim 7, characterized in that, The order confirmation unit is specifically used for: S1: If the recipient refuses to accept, the status is set to "reject" and the transfer order is cancelled by notifying the ISCM via an MQ message; S2; If the recipient confirms receipt, the status is set to "receive transfer", and the concurrency of the transfer order is verified by adding a document-level lock. If the verification is successful, proceed to S3. S3: Use the SAP disallowed-distribution exemption verification mechanism to verify the current status, overall disallowed-distribution status, and line-by-line disallowed-distribution status of the transfer order, and generate the receiving order; S4: Write back the order number corresponding to the recipient's order to the transfer order.

10. A device for transferring demand across markets, characterized in that, The device includes a processor and a memory; The memory is used to store program code and transmit the program code to the processor; The processor is configured to execute the cross-market demand transfer method according to any one of claims 1-6, based on instructions in the program code.

Images