An e-commerce after-sales processing method and device based on a two-state ledger

Abstract

The application discloses an e-commerce after-sale processing method and device based on a double-state ledger, and relates to the technical field of e-commerce data processing. The method comprises the following steps: analyzing an after-sale request to determine an after-sale task and binding the after-sale task to a business entity; generating expected state data of the business entity, writing the expected state data into an expected state ledger, and associating a user authorization version identifier; obtaining actual state data from at least two business execution systems, writing the actual state data into independent actual state ledgers; performing double-ledger state alignment based on the business entity and the user authorization version identifier, generating a state difference result, and executing a corresponding processing strategy; re-aligning after re-obtaining actual state data and updating the actual state ledger; and performing cyclic execution until all expected states and actual states reach an agreement and there is no additional actual state, or the method is transferred to manual processing after reaching a preset threshold. The application realizes accurate identification, safe execution and state convergence of a combined after-sale task across systems.

Description

Technical Field

[0001] This invention relates to the field of e-commerce data processing technology, and in particular to an e-commerce after-sales processing method and apparatus based on a dual-state ledger. Background Technology

[0002] In e-commerce platforms, user after-sales requests typically require the collaborative processing of multiple independent business systems. For example, a return and refund request might involve, in sequence, the creation of an after-sales work order, return logistics registration, warehouse receipt confirmation, payment refund, and coupon return. Each business system often employs independent data models, status codes, and asynchronous processing mechanisms, resulting in inconsistent status update times for the same after-sales request across different systems.

[0003] Existing intelligent customer service or after-sales agents typically use natural language processing to identify user intent and invoke interfaces such as order inquiries, refund requests, logistics tracking, or rights return according to preset processes. This type of solution can handle single-step tasks with clear conditions, but it usually relies on the dialogue context, tool call results, or single-process status as the basis for subsequent decisions.

[0004] When a business interface returns a timeout, indicates asynchronous processing, or reports a lost response, the returned content may not accurately reflect the actual business status. For example, a refund interface might return a timeout, even if the payment system has already completed the refund. If the after-sales intelligent agent interprets the timeout as a failure and re-initiates the refund, it could result in duplicate refunds. Conversely, a successful interface return does not necessarily mean that the payment, inventory, or benefits system has completed the final accounting.

[0005] For combined tasks such as "returning goods and refunding coupons," "exchanging goods and reserving inventory," and "canceling orders and restoring points," the existing solution is prone to partial completion. For example, the warehouse may have confirmed receipt and the refund has been completed, but the coupons have not yet been returned; or an exchange order may have been created, but the inventory reservation for the target product has failed. If the system determines whether the overall task is completed based solely on the last API call or dialogue text, it may incorrectly report complete to the user.

[0006] Furthermore, existing compensation mechanisms typically invoke undo actions in reverse order of historical execution. This approach does not adequately consider situations where the user's authorized objectives have changed, some business actions are depended upon by other transactions, certain actions are irreversible, or the current actual state differs from the historical records. This could potentially broaden the scope of compensation and undo correctly completed business states.

[0007] Therefore, there is an urgent need for an e-commerce after-sales processing technology that can separate and record user-authorized targets from the actual state of the business system and drive repair decisions through the difference between the two states. This technology can solve technical problems such as the inability to accurately identify partial completion in cross-system combined after-sales tasks, repeated execution due to interface timeouts, the inability to trace after authorization changes, and expanding the scope of revocation through fixed reverse order compensation. Summary of the Invention

[0008] The e-commerce after-sales processing method and apparatus based on a dual-state ledger provided by this invention aims to enable the after-sales processing process to distinguish between the expected state authorized by the user and the actual state in scenarios of asynchronous collaboration of multiple systems and uncertain interface results, thereby avoiding duplicate refunds, duplicate coupons, cross-entity misoperations, and unnecessary reverse cancellations, and enabling the combined after-sales tasks to ultimately form a verifiable state convergence closed loop.

[0009] One aspect of the present invention provides an e-commerce after-sales processing method based on a dual-state ledger, comprising: Receive and parse after-sales requests, determine at least one after-sales task, and bind the after-sales task to the corresponding business entity; Based on the after-sales task, generate expected status data for the corresponding business entity and write the expected status data into the expected status ledger; wherein, the expected status data is associated with a user authorization version identifier, and the user authorization version identifier is used to verify whether the expected status data belongs to the current valid authorization status; The actual status data of the business entity is obtained from at least two business execution systems, and the actual status data is written into an actual status ledger that is independent of the expected status ledger; wherein the actual status data is associated with the business entity identifier. Based on the business entity identifier and the user authorized version identifier, the expected state ledger and the actual state ledger are aligned to generate a state difference result between the expected state data and the actual state data, and different processing strategies are executed according to the state difference result. The actual state data of the business entity is retrieved from the business execution system, the actual state ledger is updated using the retrieved actual state data, and the expected state ledger and the updated actual state ledger are re-aligned. Repeat the above steps until one of the following conditions is met: All expected state data in the expected state ledger under the current valid authorized state have been matched with actual state data in the actual state ledger, and there is no actual state data in the actual state ledger that is not covered by the expected state data under the current valid authorized state. If, after the number of iterations reaches a preset threshold, there is still a difference between the expected state data and the actual state data, then manual processing is initiated.

[0010] Another aspect of the present invention provides an e-commerce after-sales processing device based on a dual-state ledger, comprising: The receiving and parsing module is used to receive and parse after-sales requests, determine at least one after-sales task, and bind the after-sales task to the corresponding business entity. The expected status generation module is used to generate expected status data for the corresponding business entity based on the after-sales task, and write the expected status data into the expected status ledger; wherein, the expected status data is associated with the user authorization version identifier, and the user authorization version identifier is used to verify whether the expected status data belongs to the current valid authorization status; The actual status acquisition module is used to acquire the actual status data of the business entity from at least two business execution systems, and write the actual status data into an actual status ledger that is independent of the expected status ledger; wherein the actual status data is associated with the business entity identifier. The strategy selection and execution module is used to perform state alignment on the expected state ledger and the actual state ledger based on the business entity identifier and the user authorized version identifier, generate a state difference result between the expected state data and the actual state data, and execute different processing strategies according to the state difference result. The status lookup and ledger update module is used to retrieve the actual status data of the business entity from the business execution system, update the actual status ledger with the retrieved actual status data, and re-align the expected status ledger and the updated actual status ledger. The iterative execution module is used to repeatedly execute the above steps until it terminates when any of the following conditions are met: all expected state data under the current valid authorized state in the expected state ledger has been found to have matching actual state data in the actual state ledger, and there is no actual state data in the actual state ledger that is not covered by the expected state data under the current valid authorized state; after the number of iterations reaches a preset threshold, if there is still a state difference between the expected state data and the actual state data, it will be transferred to manual processing.

[0011] The present invention provides an e-commerce after-sales processing method and apparatus based on a dual-state ledger, which has the following beneficial effects: First, the expected state authorized by the user and the actual state of the business system are stored in separate expected state ledgers and actual state ledgers, respectively. This avoids mistaking natural language inference, tool returns, or historical process states for the actual state confirmed by the business execution system, and solves the problem in the prior art of mixing user authorization goals and actual business system states in recording, making it difficult to distinguish between the state expected by the user and the state currently actually reached by the system.

[0012] Second, by aligning the expected state ledger with the actual state ledger, it is possible to identify various types of differences in combined after-sales tasks, such as incomplete, partially completed, unknown results, unauthorized states, and state conflicts. This reduces the risk of missed executions and erroneous reports and solves the problem that existing solutions are prone to partial completion and inaccurate identification in combined tasks.

[0013] Third, by using a wait-and-recheck strategy and an anti-duplicate execution flag mechanism, the operation result is confirmed by querying the business log or event receipt when the interface times out or the response is lost. This avoids repeated calls to the write operation interface, thereby preventing duplicate refunds, duplicate coupons, and duplicate creation of after-sales orders in the event of interface timeout. This solves the problem in existing technologies where it is difficult to identify the risk of duplicate execution when the tool call return is inconsistent with the actual status confirmed by the business execution system.

[0014] Fourth, by using the minimum compensation strategy, the expected state data under the current valid authorization is used as the benchmark. Compensation operations are only performed on actual states that exceed the benchmark range or have logical contradictions. States that have been correctly completed and still comply with the valid authorization are retained. This reduces the cancellation of irrelevant transactions and solves the problem of expanding the compensation scope and canceling the originally correctly completed states in the existing fixed reverse order compensation method.

[0015] Fifth, by using a closed-loop iterative mechanism to retrieve actual state data from the business execution system after executing the processing strategy, update the actual state ledger, and re-align the state, the combined after-sales tasks form a verifiable state convergence closed loop. This solves the problem in the existing solution that there is no unified actual state review and re-reconciliation mechanism after the compensation or completion actions are executed, and that the final convergence of the system state cannot be guaranteed. Attached Figure Description

[0016] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a schematic diagram of an e-commerce after-sales processing method based on a dual-state ledger, provided in one embodiment of this application. Figure 2 This is a schematic diagram of the structure of an e-commerce after-sales processing device based on a dual-state ledger, provided in one embodiment of this application; Figure 3This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] In this invention, unless otherwise expressly stated, the following terms have the following meanings: After-sales tasks: These refer to business items parsed from user after-sales requests. Each after-sales task corresponds to an independent business operation, such as: executing a refund, returning coupons, creating an exchange order, reserving inventory, etc.

[0019] Business entities: refer to various uniquely identifiable business objects in e-commerce after-sales scenarios, including but not limited to: orders, products, packages, after-sales orders, refund orders, or rights certificates, etc.

[0020] Expected state data: refers to data records that represent the expected business states that a business entity is authorized to achieve. Expected state data includes, but is not limited to: business entity identifier, expected state, and user authorization version identifier.

[0021] Expected State Ledger: Refers to the data set used to store expected state data. It is stored in an append-only manner and does not overwrite historical records.

[0022] Actual status data refers to the status data obtained from the business execution system and confirmed by the internal transactions of that business execution system. Actual status data includes, but is not limited to: source business execution system identifier, business entity identifier, actual status, status version or business flow, and acquisition time.

[0023] Actual state ledger: refers to the data set used to store actual state data, which is independent of the expected state ledger.

[0024] Business execution system: refers to the source system that actually performs e-commerce after-sales related business operations, including but not limited to: order system, payment and refund system, logistics and warehousing system, inventory system and marketing rights system, etc.

[0025] User Authorization Version Identifier: A globally unique identifier used to identify the authorized version to which a user's desired authorized state belongs. An initial version identifier is generated when a user initiates an after-sales request for the first time. A new version identifier is generated when the user modifies or cancels the after-sales request. This identifier is used to aggregate the desired state data under different authorized versions into their respective corresponding versions. This user authorization version identifier can be used to verify whether the desired state data belongs to the currently valid authorized state.

[0026] State alignment: refers to the process of matching and comparing the expected state data in the expected state ledger with the actual state data in the actual state ledger, using the business entity and user authorization version identifier as the matching key.

[0027] State difference results: refers to the type of difference between the expected state data and the actual state data generated after state alignment, including one or more of the following: incomplete, partially completed, unknown result, unauthorized state, and state conflict.

[0028] Forward completion: refers to a processing strategy that executes the unfinished part of the after-sales task when the result of the state difference is incomplete or partially completed, so as to make the actual state data consistent with the expected state data.

[0029] Waiting for re-query: This refers to a processing strategy where, when the result of the status difference is unknown, the write operation interface of the business execution system is prohibited from being called again. Instead, the actual status data is retrieved again by calling the query interface of the business execution system after a preset time to confirm the execution result.

[0030] Minimum compensation: refers to the processing strategy that, when the result of the state difference is an unauthorized state or a state conflict, takes the expected state data under the current valid authorization as the benchmark and only performs revocation, rollback or freeze operations on the actual state that exceeds the benchmark range or has logical contradictions.

[0031] Pending cancellation status: refers to the status corresponding to actual status data that exists in the actual status ledger, exceeds the current effective expected status data benchmark range, or has logical contradictions with other expected status data within the benchmark.

[0032] Write operation interface: refers to the interface provided by the business execution system that, when called, will cause a change in the business status, such as: refund interface, coupon return interface, inventory deduction interface, etc.

[0033] Query interface: refers to the interface provided by the business execution system that only reads status information without causing any changes to the business status, such as status query interface, business flow query interface, etc.

[0034] Anti-duplicate execution identifier: refers to an identifier associated with user identifier, business entity identifier, operation type and user authorization version identifier, used to identify and prevent the same operation from being executed repeatedly.

[0035] See Figure 1 The e-commerce after-sales processing method based on a dual-state ledger provided by this invention includes the following steps: Step S101: Receive and parse the after-sales request, determine at least one after-sales task, and bind the after-sales task to the corresponding business entity.

[0036] The system receives after-sales requests initiated by users. These requests include user identifiers, order identifiers, after-sales type (e.g., return, refund, exchange, replacement, coupon refund, etc.), and related product identifiers and package identifiers. The system performs semantic parsing and intent recognition on the after-sales requests, extracting the after-sales actions and business entity information.

[0037] The system determines at least one after-sales task based on the parsing results. Each after-sales task corresponds to a basic business operation. For example, for an after-sales request of "returning goods and refunding coupons," the system determines three after-sales tasks: a return task, a refund task, and a coupon refund task. For an after-sales request of "exchanging goods and reserving inventory," the system determines two after-sales tasks: an exchange task and an inventory reservation task.

[0038] For each after-sales task, the system binds it to a corresponding business entity. This business entity is the specific business object to which the after-sales task operates. For example, a return task is bound to the return order entity, a refund task is bound to the order's payment record entity, a coupon task is bound to the coupon entity, and an inventory reservation task is bound to the target product entity. By binding after-sales tasks to their corresponding business entities, the scope of each after-sales task is limited, ensuring that subsequent operations only apply to the correct business object.

[0039] Step S102: Generate expected status data for the corresponding business entity based on the after-sales task, and write the expected status data into the expected status ledger; wherein, the expected status data is associated with the user authorization version identifier, and the user authorization version identifier is used to verify whether the expected status data belongs to the current valid authorization status.

[0040] For each after-sales task, the system generates expected state data for the business entity corresponding to that task. This expected state data represents the expected business state that the user has authorized the business entity to achieve. Each piece of expected state data includes at least the following fields: Business Entity Identifier, used to identify the business entity corresponding to the expected state data; Expected State, representing the business state that the user has authorized the business entity to achieve; and User Authorization Version Identifier, used to identify the authorization version to which the expected state data belongs.

[0041] The system writes the desired state data into the desired state ledger in an append-only manner. Appending means the system does not overwrite any historical records; each write adds a new record to the end of the ledger. The technical advantage of this approach is that it preserves a complete authorization history, making the evolution of user authorization goals traceable and providing a data foundation for subsequent authorization version management and auditing.

[0042] When a user initiates an after-sales request for the first time, the system generates a user authorization version identifier (e.g., version number V1) and associates all expected status data generated by this after-sales request with this user authorization version identifier. The user authorization version identifier is used to verify whether each piece of expected status data still falls within the current valid authorization scope during subsequent processing. The system records the user authorization version identifier associated with each piece of expected status data in the expected status ledger, allowing expected statuses of the same business entity under different authorization versions to coexist in the ledger and be distinguished by the user authorization version identifier. This mechanism solves the problem that after a user changes or cancels their authorization midway, the expected status under the old authorization cannot be distinguished from the expected status under the current valid authorization, and expired targets cannot be identified.

[0043] Step S103: Obtain the actual status data of the business entity from at least two business execution systems, and write the actual status data into an actual status ledger that is independent of the expected status ledger; wherein the actual status data is associated with the business entity identifier.

[0044] The system obtains the current actual status data corresponding to the business entity from at least two business execution systems. The business execution system is the source system that actually performs e-commerce after-sales related business operations. The system obtains the actual status data by calling the query interfaces provided by each business execution system, reading business transaction logs, or receiving event receipts.

[0045] The actual state data refers to the state data confirmed by the internal transactions of the business execution system. This means that the actual state data reflects the final state confirmed by the business execution system after completing its internal transaction processing, rather than the synchronous return value or intermediate state of the write operation interface. For example, the actual state data of a payment refund system should be the confirmed state after the payment system completes the refund transaction and updates the database, rather than the instantaneous response returned when the refund interface is called. This feature ensures the reliability and accuracy of the data in the actual state ledger.

[0046] Each piece of actual status data includes at least the following fields: source business execution system identifier, indicating which business execution system the status data comes from; business entity identifier, indicating the business entity corresponding to the status data; actual status, indicating the actual status of the business entity as confirmed by the business execution system; status version or business transaction number, indicating the version number or business transaction number corresponding to the status, used for traceability and verification; and acquisition time, indicating the time when the status data was collected.

[0047] The system writes the actual state data into an actual state ledger that is independent of the expected state ledger. The two ledgers are stored independently, recording the "user's expected state" and the "state actually achieved by the business system," respectively, providing a data foundation for subsequent state reconciliation. The reason for keeping the two ledgers independent is that expected state data and actual state data have different data sources, different update frequencies, and different data semantics. Mixing them would lead to semantic confusion and make it impossible to clearly distinguish between the expected and the actual state.

[0048] Furthermore, the reason for obtaining actual status data from at least two business execution systems is that combined after-sales tasks typically involve multiple sub-operations executed by different business systems. Obtaining status data from only one system cannot fully cover the objectives of all after-sales tasks. For example, the after-sales task of "returning goods, refunding, and returning coupons" involves the logistics and warehousing system (confirming receipt), the payment and refund system (executing the refund), and the marketing benefits system (returning coupons). If the status is only obtained from the payment and refund system, it can only be determined whether the refund has been completed, but not whether the warehouse has received the goods or whether the coupons have been returned, thus making it impossible to determine whether the entire combined after-sales task has been completed.

[0049] Step S104: Based on the business entity identifier and the user authorized version identifier, perform state alignment on the expected state ledger and the actual state ledger, generate a state difference result between the expected state data and the actual state data, and execute different processing strategies according to the state difference result.

[0050] Specifically, the state alignment operation includes: The system standardizes the status codes of different business execution systems. Different business execution systems may use their own independent status coding systems. For example, the order system uses status codes such as "paid," "shipped," and "completed"; the payment and refund system uses status codes such as "refund successful," "refund failed," and "refund in progress"; and the marketing benefits system uses status codes such as "issued," "used," and "expired." These status codes are inconsistent in format and semantics, making direct comparison impossible. The system uses preset status mapping rules to uniformly convert the status codes of each business execution system into a standard internal status code, eliminating reconciliation obstacles caused by inconsistencies in status codes across different systems.

[0051] State mapping rules refer to the set of rules that map the state codes of different business execution systems to the system's internal standard state codes. Each business execution system has its own independent state coding system. For example, the order system's state codes include paid, shipped, and completed; the payment and refund system's state codes include refund successful, refund failed, and refund in progress; and the marketing benefits system's state codes include issued, used, and expired. These state codes are inconsistent in naming format and semantics, making direct comparison impossible. State mapping rules are stored in the system database as pre-configured mapping tables. Each mapping record contains: source system identifier, source state code, source state description, and standard state code. For newly added state codes from source systems, the system maps them to existing standard state codes or creates new standard state codes using a state code matching algorithm. When actual state data is obtained from a business execution system, the system looks up the corresponding standard state code in the mapping table based on the business execution system's identifier and the original state code in the state data. If a matching record is found, the original state code is converted into the corresponding standard state code; if no matching record is found, the system marks the original state code as an unknown state and logs it, waiting for manual configuration of the mapping relationship before performing state alignment.

[0052] Furthermore, using the user-authorized version identifier as a filter, the system extracts expected state data under the current valid authorized state from the expected state ledger. Since the expected state ledger may contain expected state data under multiple authorized versions simultaneously—for example, v1 version expected state data generated from the user's initial request, v2 version expected state data generated after the user's mid-process change request—the system uses the latest user-authorized version identifier as a filter, extracting only expected state data associated with the latest authorized version and excluding expired historical version expected state data to avoid misclassifying expired targets as still-needed targets. Next, using the business entity identifier as a matching key, the extracted expected state data is matched with the actual state data in the actual state ledger. For each extracted expected state data, the system searches the actual state ledger for actual state data with the same business entity identifier as that expected state data. If found, further compare the actual status in the actual status data (which has been converted to the system's internal standard status code) with the expected status in the expected status data (which has also been converted to the system's internal standard status code) to see if they are consistent; if not found, it indicates that the after-sales task corresponding to the expected status data has not been completed or has not yet started.

[0053] Finally, based on the matching and comparison results, the system generates a state difference result between the expected state data and the actual state data.

[0054] Specifically, the state difference results include the following five types: (1) Incomplete If a given expected status data is not found in the actual status ledger, and there are no records indicating that the operation has begun, it is considered incomplete. This means that the after-sales task has not yet started.

[0055] (2) Partially completed For multiple expected status data entries under the same user-authorized version identifier, if a portion of them has corresponding actual status data found in the actual status ledger, while the other portion has not, it is considered partially completed. This means that some sub-task objectives in the combined after-sales task have been completed, while others have not.

[0056] (3) Result unknown For a given expected status data, if the corresponding write operation interface has been called but returned a timeout or lost response, or if the actual status data indicates that the operation is being processed asynchronously, then the result is considered unknown. This means it is impossible to determine whether the operation has been successfully executed.

[0057] (4) Unauthorized status If a record of actual status data in the actual status ledger cannot be found in the expected status data under the currently valid user authorized version identifier, it is determined to be an unauthorized status. This means that the actual status exceeds the scope of the current valid authorization and is a redundant status.

[0058] (5) State conflict For multiple real-state data entries in the real-state ledger, if there are logical contradictions or broken dependencies between them, it is considered a state conflict. For example, a return order may be in the state of "shipped" but the payment system may show "refunded," which is a logical contradiction; another example is a replacement work order that is in the state of "created" but the inventory status is "reservation failed," which breaks the dependency relationship.

[0059] Furthermore, based on the different state differences, the system executes different processing strategies: When the state difference result is incomplete or partially completed, the unfinished portion of the after-sales task is executed to bring the actual state data into alignment with the expected state data. This strategy is called the forward completion strategy. Its technical principle is: as long as the user authorization remains valid and the preconditions for the operation are met, the incomplete authorization operation continues to be executed, gradually converging the actual state towards the expected state. For example, if a refund has been completed but a coupon return has not, only the coupon return operation is executed, and the refund operation is not repeated.

[0060] When the status difference result is unknown, the write operation interface of the business execution system corresponding to the after-sales task is prohibited from being called again. Instead, the actual status data is retrieved again by calling the query interface of the business execution system after a preset time to confirm the execution result. This strategy is called the wait-and-retry strategy. Its technical principle is that calling the write operation interface will produce actual business side effects (such as changes in funds, equity, and inventory). If the write operation interface is called repeatedly when the result is unknown, it may lead to serious business errors such as duplicate refunds or duplicate coupon returns. Therefore, when it is uncertain whether the operation has been successfully executed, the write operation interface is not blindly retried. Instead, the final result of the operation is confirmed by calling the query interface, which has no business side effects. The preset time can be configured according to the average response time and asynchronous processing time of the business system.

[0061] When the state difference result is an unauthorized state or a state conflict, the expected state data associated with the latest user authorization version identifier in the expected state ledger is used as a benchmark. Actual state data exceeding the benchmark range or that logically contradicts other expected state data within the benchmark is identified as a state to be revoked. Revocation, rollback, or freezing operations are then performed on these states. This strategy is called the minimum compensation strategy. Its technical principle is: using the expected state data under the current valid authorization as a benchmark, identify the excess or contradictory parts in the actual state, perform compensation operations only on these excess or contradictory states, and retain the actual states that meet the expected state and are still within the valid authorization range.

[0062] "Exceeding the baseline range" means that the actual state data cannot find a corresponding item in the expected state data under the current valid authorization. "Logical contradiction with other expected state data within the baseline" means that the dependencies between multiple actual state data are broken or there is a logical conflict. In this way, the minimum compensation strategy avoids the problems of expanding the compensation scope and revoking originally correctly completed states, which are present in traditional fixed reverse-order compensation methods.

[0063] Furthermore, different processing strategies can be selected for different after-sales tasks within the same user's after-sales request. For example, a wait-for-re-check strategy can be selected when the refund status is unknown, and a forward completion strategy can be selected when the coupon has not yet been returned. This differentiated strategy selection mechanism allows the system to choose the most appropriate processing method for the specific status of each after-sales task, improving the granularity and efficiency of processing.

[0064] Furthermore, before executing any unfinished portion of the after-sales task, or before performing a cancellation, rollback, or freeze operation, the system performs the following verifications: Verify the latest user license version identifier. If the user license version identifier corresponding to the current operation is not the latest user license version identifier, the current operation shall be prohibited. This verification ensures that the system only performs operations within the currently valid license scope and avoids performing operations under expired old license versions.

[0065] This function verifies whether the business entity bound to the current operation belongs to the scope of business entities bound to the after-sales task. If the business entity bound to the current operation is outside the scope of business entities bound to the after-sales task, the current operation is prohibited from being executed. This verification ensures that the operation only applies to the correct business entity, avoiding erroneous cross-entity operations.

[0066] Verify the prerequisite business constraints for the current operation. If the prerequisite business constraints are not met, the current operation is prohibited from execution. The prerequisite business constraints refer to the business conditions that must be met before the operation can be executed, such as: the goods must be returned to the warehouse before the refund can be executed, or the refund must be completed before the coupon can be issued, etc.

[0067] Verify the anti-duplicate execution flag of the current operation. The anti-duplicate execution flag is associated with the user identifier, business entity identifier, operation type, and user authorization version identifier, and is used to uniquely identify each operation. If the actual status data matches the corresponding expected status data, the current operation with the same anti-duplicate execution flag is prohibited from being executed again. This verification ensures that each operation will not be executed repeatedly after successful execution, thereby avoiding the risk of duplicate refunds, duplicate coupons, and other duplicate executions.

[0068] The user authorization version identifier verification, business entity scope verification, and pre-existing business constraint condition verification mentioned above are used to ensure that the operation is executed at the correct time, within the correct scope, and under the correct conditions. The anti-duplicate execution identifier verification is used to ensure that the operation is not executed repeatedly. The four verifications work together from different dimensions to ensure the security and correctness of the operation execution.

[0069] Step S105: Retrieve the actual state data of the business entity from the business execution system, update the actual state ledger using the re-retrieved actual state data, and re-align the expected state ledger and the updated actual state ledger.

[0070] After executing the processing strategy selected in step S104, or after the preset waiting time for the re-query strategy expires, the system retrieves the actual status data of the business entity from the business execution system. Retrieving the actual status data means confirming whether the operation has truly taken effect through a query interface, business flow, event receipt, or verified business database status, rather than solely relying on the synchronous return value of the write operation interface. The synchronous return value of the write operation interface may be inaccurate due to network timeouts, system anomalies, etc.; the status data obtained through querying is the final status confirmed by the business execution system.

[0071] The system updates the actual status ledger using the newly acquired actual status data. The update method involves appending the newly acquired actual status data as a new record to the actual status ledger, while retaining historical actual status data. This preserves a complete history of actual status evolution, providing data support for auditing and problem investigation.

[0072] The system performs state alignment again on the desired state ledger and the updated actual state ledger. This state alignment operation is the same as the state alignment operation in step S104, and the state difference result is regenerated based on the updated actual state data.

[0073] This step, through a post-execution status review mechanism, ensures that the data in the actual status ledger always reflects the latest real status of the business execution system, providing an accurate data foundation for the next round of decision-making, while avoiding erroneous judgments caused by relying solely on interface return values.

[0074] Step S106: Repeat steps S101 to S105 until any of the following conditions are met, then terminate: Condition 1: All expected state data in the current valid authorized state in the expected state ledger have been matched with actual state data in the actual state ledger, and there is no actual state data in the actual state ledger that is not covered by the expected state data in the current valid authorized state. Condition 2: If, after the number of iterations reaches a preset threshold, there is still a difference between the expected state data and the actual state data, then manual processing will be initiated.

[0075] The system repeatedly executes steps S101 to S105. In each cycle, state alignment and difference identification are re-performed based on the updated actual state ledger, and processing strategies are re-selected and executed based on the new difference results until the termination condition is met.

[0076] Termination Condition 1: This indicates that all expected states have been achieved and there are no redundant actual states. This condition means that for every expected state data entry under the currently valid authorized version in the expected state ledger, a matching actual state data entry can be found in the actual state ledger. That is, the business entity is the same, the state is consistent, and there is no actual state data entry in the actual state ledger that exceeds the range of currently valid expected state data. At this point, the expected state ledger and the actual state ledger are completely consistent in business semantics, and the combined after-sales task has been successfully completed.

[0077] Termination Condition Two: This indicates that the automatic processing flow cannot converge the state within the preset number of loops. The preset threshold is the maximum number of loop executions pre-configured by the system. When the number of loop executions reaches this preset threshold, if a state difference still exists between the expected state data and the actual state data, manual processing is initiated. The preset threshold can be determined based on the average interface response time of the business execution system, the maximum completion time of asynchronous processing, the expected processing time requirements of after-sales tasks, and the system's security protection requirements for unlimited loops.

[0078] Furthermore, the conditions for switching to manual processing include: the existence of irreversible operations (such as those involving physical logistics operations), the existence of high-risk operations (such as large-scale financial transactions), state conflicts that cannot be automatically resolved, or the state differences still not converging after the number of iterations reaches a preset threshold. Switching to manual processing serves as a fallback mechanism to prevent the system from falling into an infinite loop if it cannot converge automatically.

[0079] The method of the present invention will be described in detail below through a specific embodiment.

[0080] A user initiates a "return, refund, and return of order coupon" after-sales request for product P1 in order O1. The system receives the after-sales request, parses the request content, and determines three after-sales tasks: a return task, a refund task, and a coupon return task. The system binds the return task to the return order entity R20260101, the refund task to the payment record entity of order O1, and the coupon return task to the coupon entity C1.

[0081] The system generates a user-authorized version identifier v1 and generates three expected status data entries: The first expected status data corresponds to the return task, the business entity is the return order, and the expected status is "return completed"; The second expected status data corresponds to the refund task, the business entity is the payment record of order O1, and the expected status is "refund completed"; The third expected status data corresponds to the coupon rebate task, the business entity is coupon C1, and the expected status is "coupon has been restored to availability". The system writes these three expected status data into the expected status ledger, all of which are associated with the user-authorized version identifier v1.

[0082] The system retrieves actual status data from the logistics and warehousing system, payment and refund system, and marketing benefits system. The logistics and warehousing system returns the actual status of return order R20260101 as "inbound," the payment and refund system returns the actual status of payment record for order O1 as "pending refund," and the marketing benefits system returns the actual status of coupon C1 as "not restored." The system writes this actual status data into the actual status ledger.

[0083] The system aligns the expected and actual state ledgers based on the business entity identifier and the user authorization version identifier v1. The alignment results show that: the expected state "Return Completed" for return tasks matches the actual state "Inbound," indicating the goal has been achieved; the expected state "Refund Completed" for refund tasks does not match the actual state "Pending Refund," indicating the goal has not been achieved; and the expected state "Coupon Available Again" for coupon rebate tasks does not match the actual state "Not Available Again," indicating the goal has not been achieved. State discrepancies indicate partial completion.

[0084] Based on the differences in the partially completed status results, the system selects a forward completion strategy to execute the incomplete refund and coupon tasks. The system generates an anti-duplicate execution flag K1 for the refund task and calls the write operation interface of the payment and refund system. If the payment and refund interface does not return a result within the specified time, the system records the call status as timed out, but does not immediately consider the refund to have failed, nor does it call the refund interface again. Instead, it marks the refund task as having an unknown result and enters a waiting-for-re-check strategy.

[0085] After waiting for a preset time, the system uses the anti-duplicate execution flag K1 and payment transaction records to query the payment refund system via the query interface. The payment refund system returns the actual status "Refund Completed" via the query interface. The system writes this actual status data to the actual status ledger and re-reconciles the two ledgers. After the re-reconciliation, the refund target has been met, but the coupon return target has not yet been met. Since the refund has been actually completed, the system retains this status and prohibits duplicate refunds; for the coupon return task, the current user's authorized version flag v1 is still valid, and the precondition for the coupon return (refund completed) is met, so the forward completion strategy is selected, and only the write operation interface of the marketing benefits system is called to execute the coupon return.

[0086] After the coupon writing operation interface returns a successful response, the system does not immediately terminate the task. Instead, it queries again through the marketing benefits system's query interface. The query result shows that coupon C1 has been restored to availability, and the system updates the actual status ledger accordingly. The final reconciliation result shows that both the refund target and the coupon return target have been met, and there is no actual status data in the actual status ledger that exceeds the expected range. The system outputs the result "Refund and coupon return have both been completed" to the user and saves the user's authorized version identifier, business transaction log, call history, and reconciliation result.

[0087] As can be seen from the above embodiments, in the case of a refund interface timeout, the present invention avoids repeated calls to the refund write operation interface by using a wait-and-recheck strategy, thereby preventing duplicate refunds; the actual execution result of the refund is confirmed by the post-execution status review mechanism; and by selecting a differentiated strategy, only the unfinished coupon return operation is executed after the refund is completed, thus realizing a complete closed-loop processing of combined after-sales tasks.

[0088] In summary, this invention effectively solves the problem of accurate identification and correct handling when the user-authorized target state is inconsistent with the actual state of the business system in e-commerce combined after-sales tasks spanning multiple business systems, through a dual-ledger architecture where the expected state ledger and the actual state ledger are independent, a strategy selection mechanism based on state differences, and a closed-loop iterative convergence mechanism.

[0089] See Figure 2 Another embodiment of the present invention provides an e-commerce after-sales processing device 200 based on a dual-state ledger, including a receiving and parsing module 201, a desired state generation module 202, an actual state acquisition module 203, a strategy selection and execution module 204, a state lookup and ledger update module 205, and an iterative execution module 206. The e-commerce after-sales processing device 200 based on a dual-state ledger can execute the e-commerce after-sales processing method based on a dual-state ledger in the method embodiment.

[0090] Specifically, the e-commerce after-sales processing device 200 based on a dual-state ledger includes: The receiving and parsing module 201 is used to receive and parse after-sales requests, determine at least one after-sales task, and bind the after-sales task to the corresponding business entity. The expected status generation module 202 is used to generate expected status data of the corresponding business entity according to the after-sales task, and write the expected status data into the expected status ledger; wherein, the expected status data is associated with the user authorization version identifier, and the user authorization version identifier is used to verify whether the expected status data belongs to the current valid authorization status. The actual status acquisition module 203 is used to acquire the actual status data of the business entity from at least two business execution systems, and write the actual status data into an actual status ledger that is independent of the expected status ledger; wherein the actual status data is associated with the business entity identifier; The strategy selection and execution module 204 is used to perform state alignment on the expected state ledger and the actual state ledger based on the business entity identifier and the user authorized version identifier, generate a state difference result between the expected state data and the actual state data, and execute different processing strategies according to the state difference result. The status lookup and ledger update module 205 is used to retrieve the actual status data of the business entity from the business execution system, update the actual status ledger with the retrieved actual status data, and re-align the expected status ledger and the updated actual status ledger. The iterative execution module 206 is used to repeatedly execute the above steps until it terminates when any of the following conditions are met: all expected state data under the current valid authorized state in the expected state ledger has been found to have matching actual state data in the actual state ledger, and there is no actual state data in the actual state ledger that is not covered by the expected state data under the current valid authorized state; after the number of iterations reaches a preset threshold, if there is still a state difference between the expected state data and the actual state data, it will be transferred to manual processing.

[0091] It should be noted that the technical solutions of the e-commerce after-sales processing device 200 based on a dual-state ledger provided in this embodiment, which can be used to execute various method embodiments, are similar in implementation principle and technical effect to the methods, and will not be repeated here.

[0092] Figure 3 This is a schematic diagram of an electronic device 300 provided in another embodiment of the present invention. The electronic device 300 is used to implement the e-commerce after-sales processing method based on a dual-state ledger in the method embodiment. The electronic device 300 in the embodiments of the present invention may include, but is not limited to, smartphones, tablet computers, PCs, laptops, etc. Figure 3 The electronic device 300 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0093] like Figure 3 As shown, the electronic device 300 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes to implement the methods of the embodiments described herein, based on a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing device 301, ROM 302, and RAM 303 are interconnected via a bus 305. An input / output (I / O) interface 304 is also connected to the bus 305.

[0094] Typically, the following devices can be connected to I / O interface 304: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0095] The above description is merely a preferred embodiment of the present invention. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to the specific combination of the above-described technical features, but should also cover other technical solutions formed by any combination of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

Claims

1. A method for e-commerce after-sales processing based on a dual-state ledger, characterized in that, include: Receive and parse after-sales requests, determine at least one after-sales task, and bind the after-sales task to the corresponding business entity; Based on the after-sales task, generate expected status data for the corresponding business entity and write the expected status data into the expected status ledger; wherein, the expected status data is associated with a user authorization version identifier, and the user authorization version identifier is used to verify whether the expected status data belongs to the current valid authorization status; The actual status data of the business entity is obtained from at least two business execution systems, and the actual status data is written into an actual status ledger that is independent of the expected status ledger; wherein the actual status data is associated with the business entity identifier. Based on the business entity identifier and the user authorized version identifier, the expected state ledger and the actual state ledger are aligned to generate a state difference result between the expected state data and the actual state data, and different processing strategies are executed according to the state difference result. The actual state data of the business entity is retrieved from the business execution system, the actual state ledger is updated using the retrieved actual state data, and the expected state ledger and the updated actual state ledger are re-aligned. Repeat the above steps until one of the following conditions is met: All expected state data in the expected state ledger under the current valid authorized state have been matched with actual state data in the actual state ledger, and there is no actual state data in the actual state ledger that is not covered by the expected state data under the current valid authorized state. If, after the number of iterations reaches a preset threshold, there is still a difference between the expected state data and the actual state data, then manual processing is initiated.

2. The e-commerce after-sales processing method based on a dual-state ledger according to claim 1, characterized in that, Also includes: When a user modifies or cancels an after-sales request, a new user authorization version identifier is generated, and the expected status data associated with the old user authorization version identifier is marked as invalid.

3. The e-commerce after-sales processing method based on a dual-state ledger according to claim 1, characterized in that, The step of aligning the expected state ledger and the actual state ledger based on the business entity identifier and the user authorized version identifier includes: The status codes of different business execution systems are standardized to obtain the standard status codes of each business entity; Using the user-authorized version identifier as a filter, extract the expected state data of the current valid authorized state from the expected state ledger; Using the business entity identifier as the matching key, the extracted expected state data is matched with the actual state data in the actual state ledger, and the standard state code of the matched expected state is compared with the standard state code of the actual state.

4. The e-commerce after-sales processing method based on a dual-state ledger according to claim 2, characterized in that, The step of executing different processing strategies based on the state difference results includes: When the status difference result is incomplete or partially completed, the unfinished part of the after-sales task is executed to make the actual status data consistent with the expected status data. When the result of the status difference is unknown, it is prohibited to call the write operation interface of the business execution system corresponding to the after-sales task again. After waiting for a preset time, the actual status data is obtained again by calling the query interface of the business execution system to confirm the execution result. When the state difference result is an unauthorized state or a state conflict, the expected state data associated with the latest user authorization version identifier in the expected state ledger is used as a benchmark. Actual state data that exceeds the benchmark range or that has a logical contradiction with other expected state data within the benchmark is determined as a state to be revoked, and the revocation, rollback or freeze operation is performed on the state to be revoked.

5. The e-commerce after-sales processing method based on a dual-state ledger according to claim 4, characterized in that, When the status difference result is unknown, the business execution system interface corresponding to the after-sales task is not called repeatedly. Instead, the actual status data is retrieved from the business execution system again after a preset time to confirm the execution result. This step specifically includes: When the interface of the business execution system corresponding to the after-sales task returns a timeout, a lost response, or actual status data indicating that the operation is in asynchronous processing, the interface is not called repeatedly, and the execution result is confirmed by querying the business log or event receipt.

6. The e-commerce after-sales processing method based on a dual-state ledger according to claim 4, characterized in that, The steps for performing undo, rollback, or freeze operations on the pending undo state include: Based on the dependencies between the states to be revoked and the reversibility of the business operations corresponding to the states to be revoked, the execution order between the states to be revoked is determined; and according to the execution order, the revocation, rollback or freeze operations are performed on the states to be revoked in sequence.

7. The e-commerce after-sales processing method based on a dual-state ledger according to claim 4, characterized in that, Also includes: Before performing any unfinished portion of the after-sales task, or before performing a cancellation, rollback, or freeze operation, perform the following verification: Verify the latest user authorization version identifier. If the user authorization version identifier corresponding to the current operation is not the latest user authorization version identifier, the current operation shall be prohibited. Verify whether the business entity bound to the current operation belongs to the scope of business entities bound to the after-sales task. If the business entity bound to the current operation exceeds the scope of business entities bound to the after-sales task, the current operation shall be prohibited from being executed. Verify the prerequisite business constraints for the current operation. If the prerequisite business constraints are not met, prohibit the execution of the current operation. Additionally, the anti-repeated execution flag of the current operation is verified. If the actual state data matches the corresponding expected state data, the current operation with the same anti-repeated execution flag is prohibited from being executed again.

8. An e-commerce after-sales processing device based on a dual-state ledger, characterized in that, include: The receiving and parsing module is used to receive and parse after-sales requests, determine at least one after-sales task, and bind the after-sales task to the corresponding business entity. The expected status generation module is used to generate expected status data for the corresponding business entity based on the after-sales task, and write the expected status data into the expected status ledger; wherein, the expected status data is associated with the user authorization version identifier, and the user authorization version identifier is used to verify whether the expected status data belongs to the current valid authorization status; The actual status acquisition module is used to acquire the actual status data of the business entity from at least two business execution systems, and write the actual status data into an actual status ledger that is independent of the expected status ledger; wherein the actual status data is associated with the business entity identifier. The strategy selection and execution module is used to perform state alignment on the expected state ledger and the actual state ledger based on the business entity identifier and the user authorized version identifier, generate a state difference result between the expected state data and the actual state data, and execute different processing strategies according to the state difference result. The status lookup and ledger update module is used to retrieve the actual status data of the business entity from the business execution system, update the actual status ledger with the retrieved actual status data, and re-align the expected status ledger and the updated actual status ledger. The iterative execution module is used to repeatedly execute the above steps until it terminates when any of the following conditions are met: all expected state data under the current valid authorized state in the expected state ledger has been found to have matching actual state data in the actual state ledger, and there is no actual state data in the actual state ledger that is not covered by the expected state data under the current valid authorized state; after the number of iterations reaches a preset threshold, if there is still a state difference between the expected state data and the actual state data, it will be transferred to manual processing.

9. The e-commerce after-sales processing device based on a dual-state ledger according to claim 8, characterized in that, Also includes: The authorized version identifier management module is used to generate a new user authorized version identifier when a user modifies or cancels an after-sales request, and to mark the expected status data associated with the old user authorized version identifier as invalid.

10. The e-commerce after-sales processing device based on a dual-state ledger according to claim 9, characterized in that, The strategy selection and execution module is further used for: When the status difference result is incomplete or partially completed, the unfinished part of the after-sales task is executed to make the actual status data consistent with the expected status data. When the result of the status difference is unknown, it is prohibited to call the write operation interface of the business execution system corresponding to the after-sales task again. After waiting for a preset time, the actual status data is obtained again by calling the query interface of the business execution system to confirm the execution result. When the state difference result is an unauthorized state or a state conflict, the expected state data associated with the latest user authorization version identifier in the expected state ledger is used as a benchmark. Actual state data that exceeds the benchmark range or that has a logical contradiction with other expected state data within the benchmark is determined as a state to be revoked, and the revocation, rollback or freeze operation is performed on the state to be revoked.

Images