Settlement method, device and electronic equipment for supply chain logistics

Abstract

This disclosure provides a settlement method, apparatus, and electronic device for supply chain logistics. One specific implementation of the method includes: acquiring a target billing source related to supply chain logistics documents; processing the target billing source based on a first contract model to generate a first billing result, the first contract model including a first set of rules; in response to a first rule in the first set including a target state, storing the first billing result corresponding to the first rule in the target state in a data storage table, the calculation process of the first rule in the target state being performed in a sandbox, the data storage table being isolated from the online data of the supply chain logistics; verifying the first billing result in the data storage table to generate a verification result; and in response to all rules in the first set being online, generating a settlement result for the target billing source based on the first billing result. This provides a way to improve the accuracy of supply chain logistics settlement.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to a settlement method, apparatus and electronic device for supply chain logistics. Background Technology

[0002] With the development of computers, users can use electronic devices to perform various functions. For example, computers can be used to settle (bill) costs in supply chain logistics scenarios, enabling automatic billing in supply chain logistics scenarios.

[0003] In some scenarios, settlement in e-commerce supply chain logistics systems involves multiple roles, including suppliers, logistics service providers, e-commerce platforms, and consumers. Within this complex ecosystem, operations teams face the challenge of integrating multiple scenarios over a period of time. A crucial step in this integration is configuring pricing, including numerous detailed items such as transportation fees, insurance fees, warehousing fees, and value-added service fees. Different entities offer different pricing configurations, making accurate settlement using computer systems a critical issue in such complex scenarios. Summary of the Invention

[0004] This disclosure is provided to briefly introduce the concepts, which will be described in detail in the subsequent Detailed Description section. This disclosure is not intended to identify key or essential features of the claimed technical solution, nor is it intended to limit the scope of the claimed technical solution.

[0005] In a first aspect, embodiments of this disclosure provide a settlement method for supply chain logistics. The method includes: acquiring a target billing source related to supply chain logistics documents; processing the target billing source based on a first contract model to generate a first billing result, the first contract model including a first set of rules; in response to a first rule in the first set including a first rule in a target state, storing the first billing result corresponding to the first rule in the target state in a data storage table, the calculation process of the first rule in the target state being performed in a sandbox, a data storage table being set up for the sandbox, the data storage table being isolated from the online data of the supply chain logistics; verifying the first billing result in the data storage table to generate a verification result; and in response to all rules in the first set being online, generating a settlement result for the target billing source based on the first billing result.

[0006] Secondly, embodiments of this disclosure provide a settlement device for supply chain logistics, comprising: an acquisition unit for acquiring a target billing source related to supply chain logistics documents; a first generation unit for processing the target billing source based on a first contract model to generate a first billing result, wherein the first contract model includes a first rule set; a storage unit for storing the first billing result corresponding to the first rule in the target state in a data storage table in response to a first rule in the first rule set including a target state, wherein the calculation process of the first rule in the target state is performed in a sandbox, and a data storage table is set for the sandbox, the data storage table being isolated from the online data of the supply chain logistics; a second generation unit for verifying the first billing result in the data storage table and generating a verification result; and a third generation unit for generating a settlement result for the target billing source based on the first billing result in response to all rules in the first rule set being online.

[0007] Thirdly, embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement the settlement method for supply chain logistics as described in the first aspect.

[0008] Fourthly, embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon that, when executed by a processor, implements the steps of the settlement method for supply chain logistics as described in the first aspect. Attached Figure Description

[0009] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0010] Figure 1 This is a flowchart of one embodiment of a settlement method for supply chain logistics according to the present disclosure;

[0011] Figure 2 and Figure 3 This is a schematic diagram of an application scenario of the settlement method for supply chain logistics according to this disclosure.

[0012] Figure 4A , Figure 4B and Figure 4C This is a schematic diagram of a pre-run application scenario based on the rules of the settlement method for supply chain logistics disclosed herein;

[0013] Figure 5This is a schematic diagram of a replay application scenario of the settlement method for supply chain logistics according to this disclosure;

[0014] Figure 6 This is a schematic diagram of a settlement device for supply chain logistics according to an embodiment of the present disclosure;

[0015] Figure 7 This is an example of a settlement method for supply chain logistics according to one embodiment of the present disclosure, and an exemplary system architecture in which it can be applied;

[0016] Figure 8 This is a schematic diagram of the basic structure of an electronic device provided according to an embodiment of the present disclosure. Detailed Implementation

[0017] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0018] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0019] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0020] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0021] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0022] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0023] Here, we may provide explanations of terms applicable to one or more embodiments of this disclosure.

[0024] Billing source: The most original documents received, which contain basic data such as basic information about the goods, transportation routes, and charging standards.

[0025] Billing Orders: During the billing process, billing orders play a crucial role in recording the necessary information for order splitting and merging. This includes recording which orders are merged, which are split, and the specific reasons and operational details for each split or merge. For example, if the received document is a warehouse outbound order, and the business has configured billing rules based on the parcel order dimension, then the outbound order needs to be split into parcel order dimensions within the order splitting environment.

[0026] Billing Tasks: After each billing order is matched with the contract fee item, a corresponding task record is generated. These task records detail the billing operations to be performed and related requirements.

[0027] Billing Result: This is the final result generated by the billing engine after each billing task is calculated. It includes detailed information such as the specific cost amount, the charged items, and any discounts or promotions.

[0028] In one or more embodiments of this disclosure, a billing accuracy assurance architecture is proposed. Through pre- and post-event preventative designs, the billing process is ensured to be accurate and error-free, minimizing potential risks and errors.

[0029] In one or more embodiments of this disclosure, the billing process begins with generating a billing source through an acquiring operation. The acquiring process collects relevant business data and transaction information to provide a foundation for subsequent billing. Next, billing rules are initially matched to determine if order splitting is necessary. The main reason for order splitting is that some quotes are configured at the sub-order level. This means that without order splitting, accurate cost calculation may be impossible. After a series of processes, including cleaning and order splitting, a billing statement is generated. Then, the rules are matched again, this time with greater detail and precision. Based on the rule filtering conditions and cost item configurations, billing tasks requiring billing are generated. During this process, the system filters and integrates various data to ensure the accuracy and completeness of the billing tasks. Finally, the billing tasks are matched against the actual rules to calculate the final billing result. This calculation process typically involves complex algorithms and logic to ensure the accuracy and fairness of cost calculation. The billing result is pushed to the settlement stage, and an aggregated bill is generated. The bill clearly displays the details and summary of each cost item, facilitating user viewing and verification.

[0030] In one or more embodiments of this disclosure, a pre-deployment testing scheme based on billing rules (i.e., rule pre-running) is proposed. This scheme comprehensively verifies the effectiveness of rule configurations by cleverly combining real data or simulated data based on rules. Thorough verification testing before deployment avoids the possibility of human configuration errors, significantly improves the accuracy of rule configuration, and lays a solid foundation for subsequent billing work.

[0031] In one or more embodiments of this disclosure, a regression scheme based on historical data playback is proposed. By selecting representative historical data for sampling and deploying the system swimlane environment, and combining the results of the comparison (DIFF) report, the integrity and accuracy of the functions during the system iteration process are comprehensively verified. Furthermore, this scheme will not have any adverse impact on the online environment during implementation, and can effectively evaluate and optimize the new configuration while ensuring the normal operation of the system.

[0032] In one or more embodiments of this disclosure, a post-event remedial measure for billing accuracy is proposed. When the billing rules have been configured incorrectly or the billing factors are uncertain, a recalculation scheme is used to specify newly configured rules or metadata for calculation. With the help of powerful auditing, settlement and reversal capabilities, the data can be corrected in a timely and effective manner.

[0033] In one or more embodiments of this disclosure, a billing contract state machine is proposed (see reference). Figure 2 and Figure 3The billing process can be abstracted into data and rules, where rules refer to the pre-configured billing rules that the business needs to follow. Specifically, data (also known as metadata) contains various information related to billing, such as the length, width, height, and weight of the product, as well as the delivery distance, or the identifier of the business document. This data is the foundation of billing, and its accuracy and completeness directly affect the billing result. Rules, on the other hand, are a series of pre-defined conditions and calculation methods used to determine how to calculate fees based on the data. These rules may cover the entry and filtering conditions for rule calculations, as well as how to match rate cards according to different dimensions during calculation. Calculation methods include, but are not limited to, a fixed-price model, a model that calculates the total price based on unit price and quantity, etc. Different calculation methods are suitable for different business scenarios and needs, and can meet diverse billing requirements. The configuration of rules needs to be based on a certain contract; this rule model can be called a contract model. The establishment and maintenance of the contract model is crucial to ensuring accurate and compliant billing. By configuring rules in accordance with the contract, disputes and conflicts during the billing process can be effectively avoided, ensuring the normal operation of the business. In this scenario design, contracts are defined as the data to be expressed externally. Once defined, these contracts are relatively stable. Instances of these contracts are also defined, constructed using models such as contract versions, billing rules, and rate cards to define the rules governing the contracts. Since the specific instances of contracts can change frequently, the model between these contracts and their versions represents a 1:n relationship, but at any given time, only one effective contract version corresponds to a single contract. After the contracts are defined, business or merchant roles place orders. Ordering is a rule-association process; it establishes order relationships, meaning that subsequent data can be used to determine which rules should be applied for fee calculation.

[0034] In one or more embodiments of this disclosure, a billing document association method is proposed. The synergy between rules and data is crucial in the billing process. For example, when multiple orders need to be billed together, or when a large order needs to be split into multiple smaller orders for separate billing, numerous factors and variables are involved. Based on the current billing process, billing documents can be further subdivided into four key parts: billing source, billing document, billing task, and billing result. Documents should be able to maintain mutual traceability to facilitate data backtracking during the sandbox process.

[0035] In one or more embodiments of this disclosure, a sandbox-based method for ensuring billing accuracy is proposed.

[0036] In one or more embodiments of this disclosure, the billing accuracy sandbox guarantee scheme consists of three parts: billing sandbox pre-run, billing sandbox playback, and billing sandbox recalculation.

[0037] In one or more embodiments of this disclosure, a billing sandbox pre-run is provided: its main function is to comprehensively verify the rules using data before they go live. By simulating actual business processes and data environments, newly formulated billing rules are pre-tested and evaluated. During this process, the logical accuracy of the rules, the integrity of the data, and compatibility with existing systems are carefully checked. Only after data verification is completed and the rules are confirmed to be problem-free will they be officially deployed.

[0038] In one or more embodiments of this disclosure, a method for implementing billing sandbox replay is provided: after the system undergoes an iterative update, rich historical data is used for backtracking. Billing is then re-performed according to the historical rules, and the results are compared in detail with the original billing results. The purpose of this is to verify the completeness and accuracy of the system after iteration, ensuring that the new system changes have not introduced any potential errors or deviations.

[0039] In one or more embodiments of this disclosure, a method for implementing billing sandbox recalculation is provided: this is a last resort when various safeguards fail. By precisely defining the data range requiring recalculation, specific data recalculation or specific rule recalculation is performed. During the recalculation process, the data and rules are reviewed and adjusted again to ensure the accuracy and reliability of the billing results.

[0040] Please refer to Figure 1 This illustrates a flow diagram of one embodiment of a settlement method for supply chain logistics according to this disclosure. Figure 1 The settlement method shown for supply chain logistics includes the following steps:

[0041] Step 101: Obtain the target billing source related to supply chain logistics documents.

[0042] In this embodiment, the entity executing the settlement method for supply chain logistics (e.g., a server and / or terminal device) can obtain the target billing source related to the supply chain logistics documents.

[0043] Optionally, the aforementioned target billing source can be real historical data of supply chain logistics, or simulated data (or constructed data) generated based on historical supply chain logistics documents.

[0044] Step 102: Based on the first contract model, process the target billing source to generate the first billing result.

[0045] Here, the first contract model includes the first set of rules.

[0046] The first set of rules can be understood as... Figure 2The contract version is defined in the first rule set. Modifying a rule in the first rule set updates the rule set. Once the updated rule set is deployed, a new contract version is obtained.

[0047] Therefore, the rule set of the first contract model may be the contract version that has been launched and is in effect, or it may be a rule set that has not been launched. As an example, the process of generating the first billing result by processing the target billing source may include: generating a billing bill based on the billing source; after the billing bill is matched with the contract fee items, it will generate a corresponding specific task record, i.e., a billing task; and the final result generated after the billing task is calculated (which includes detailed information such as the specific fee amount, charging items, and discounts).

[0048] Step 103: In response to the first rule in the first rule set including the target state, the first billing result corresponding to the first rule of the target state is stored in the data storage table.

[0049] Here, the calculation process for the first rule in the target state takes place in a sandbox. A data storage table is set up for the sandbox, and this data storage table is isolated from the online data of the supply chain logistics. The target state can refer to the sandbox state.

[0050] Step 104: Verify the first billing result in the data storage table and generate a verification result.

[0051] As an example, the first billing result can be verified to meet preset conditions to generate a verification result, which may be either verification passed or verification failed.

[0052] Step 105: In response to the fact that all rules in the first rule set are online, generate the settlement result of the target billing source based on the first billing result.

[0053] Here, some or all of the rules in the first rule set can be validated in the sandbox. Once validation is successful, the rules can be brought online. When the first rule set is online, the first billing result, if calculated by the validated first rule, can be used as at least a partial settlement result.

[0054] It should be noted that the settlement method for supply chain logistics provided in this embodiment obtains the target billing source related to the supply chain logistics documents; processes the target billing source based on a first contract model to generate a first billing result, the first contract model including a first set of rules; in response to a first rule in the first set including a target state, the first billing result corresponding to the first rule in the target state is stored in a data storage table, the calculation process of the first rule in the target state is carried out in a sandbox, a data storage table is set for the sandbox, the data storage table is isolated from the online data of the supply chain logistics; the first billing result in the data storage table is verified to generate a verification result. In response to the fact that all rules in the first rule set are in an online state, a settlement result for the target billing source is generated based on the first billing result. Thus, based on sandbox technology, the billing result to be verified can be determined by utilizing the state of the rules and sandbox technology. Furthermore, the billing result can be verified before the settlement result is generated. On the one hand, the first rule in the target state can be verified during the overall calculation using the first contract model. On the other hand, by using the state to distinguish the first rule, the configuration steps for setting the first rule as an online state rule after verification can be reduced, thereby achieving significant improvements in several key aspects such as billing accuracy, timeliness, and operating costs in the supply chain logistics scenario.

[0055] In some embodiments of this disclosure, potential rule configuration errors and risks can be identified in advance through prediction and simulation functions, providing early warnings and corrective suggestions to relevant personnel. This is mainly achieved through rule pre-running and playback. Please refer to... Figure 4A , Figure 4B and Figure 4C Rule pre-running utilizes real-time traffic for rule verification and intercepts billing results (stored in a shadow table, also known as a data storage table). After verification, all billable documents are reviewed and billed normally. For playback, please refer to [link / reference]. Figure 5 By sampling online orders or creating simulated data through feature sampling, billing rules are specified, and the collected results are compared with the expected business results. If the results meet the expectations, the rules are implemented.

[0056] In some embodiments, the first contract model is a non-real-time settlement type.

[0057] In some embodiments, the method further includes: in response to the verification result indicating that the verification has passed, generating a settlement result based on the first billing result, and adjusting the target state rule to an online state.

[0058] In some embodiments, the first contract model is a non-real-time settlement type; and the method further includes: in response to a verification result indicating failure, modifying a first rule for the target state according to rule modification information; and processing the target billing source based on the modified first rule.

[0059] In some embodiments, the first contract model is a real-time settlement type; and step 101 includes: constructing a target billing source based on historical documents of supply chain logistics; and the method further includes: adjusting the first rule of the target state to an online state in response to a verification result indicating that it has passed; modifying the first rule of the target state according to rule modification information in response to a verification result indicating that it has failed; and processing the target billing source based on the modified first rule.

[0060] Pre-running primarily verifies the correctness of rule configurations. Before a rule goes live, its status is set to pre-running (also known as target status, sandbox status, or non-live status). Pre-running rules can be loaded into online billing. The results calculated through pre-running are not immediately pushed to the billing process; they wait on the billing side for result verification.

[0061] Since verification is required after the pre-run, the order volume needs to be controlled. Once the number of orders exceeds the pre-run verification limit, the pre-run rules will no longer generate new billing results. If a calculation error occurs during verification, the pre-run results can be cleared, and the pre-run rules modified. Simultaneously, the documents related to these rules should be traced back. Because rule modifications may involve order splitting, it's necessary to trace back to the billing source, starting from the beginning. Once verification is complete and the pre-run billing results are correct, the rules are put into operation. Simultaneously, the billing source is traced back, and all rule-related data is recalculated to generate results and pushed to settlement.

[0062] A pre-run rule is created to verify the correctness of billing; the rule status is pre-run. Rule verification is performed using a portion of real traffic. The billing engine can load not only already effective billing rules but also rules in the pre-running stage. Furthermore, the results of the pre-run do not proceed to billing; instead, they remain in the billing process and require verification by the business logic.

[0063] You can verify some of the pre-run billing results. If the verification passes, you can either reject the rules and modify them until the pre-run results are confirmed.

[0064] Once verification is complete, the rule goes live, and all documents that should be billed under this rule are traced back to perform formal billing for all documents. The results are then generated and pushed for settlement, and the pre-run process ends.

[0065] The settlement methods include periodic settlement and real-time settlement.

[0066] Periodic settlements have a defined payment period, meaning that specific periodic dates can be agreed upon, such as a fixed date each month or the end of each quarter. At these dates, any outstanding data from prior to that date is settled in a unified manner. The advantage of this model is that it allows for centralized processing of large amounts of data, improving settlement efficiency, and also facilitates financial planning and cash flow management.

[0067] Real-time settlement has a high requirement for real-time performance. That is, once a business transaction is generated, the system immediately processes the billing and settlement, with almost no waiting time. This settlement model is suitable for business scenarios that require high cash flow. It also places higher demands on system performance and stability, requiring strong technical support and efficient operational management to ensure its smooth operation.

[0068] For different settlement scenarios, the corresponding schemes for pre-validation rules in the sandbox are also different.

[0069] Before integrating settlement services, operations personnel first configure the billing contracts to be launched. Each contract has billing rules for different expense items, and sandbox validation can be performed on certain expense item rules. Before launch, the expense item rules are set to sandbox status. When real online data is generated, the data is matched with the corresponding billing contract, and then calculations are performed one by one according to the expense item rules under the document. When a result can be calculated for a certain expense item, a logical check is performed during the persistence of the billing result to verify whether the expense item is in sandbox status. If not, it means that it is a normally launched expense item rule; otherwise, it is a rule in sandbox status, and the result is stored in the data storage table of the sandbox environment during persistence.

[0070] During sandbox calculations, the system counts the documents entering the sandbox. Once a certain number are counted, billing for that sandbox rule is stopped to prevent excessive data from affecting sandbox data verification. Simultaneously, data from the sandbox environment is retrieved through sandbox tasks and exported as a table for verification. If the data meets expectations, the rule is deployed, the status changes from sandbox to deployed, and the corresponding billing source data for that sandbox rule is backtracked. If the data does not meet expectations, the billing rules in the sandbox are modified, and the results in the sandbox environment are cleaned up. Further sandbox verification is performed after subsequent real data is generated until the rules in the entire sandbox meet business expectations.

[0071] Because real-time settlement is highly time-sensitive, it cannot be performed in a sandbox for verification like periodic settlement, where billing is done upfront without posting. This is because time constraints prevent it; as soon as online data is generated, settlement results are produced instantly. Therefore, to ensure the accuracy and reliability of settlement, sandbox verification must be conducted before the actual data is generated.

[0072] The specific method involves conducting data simulations for the upcoming fee item rules, and generating billing invoices using the constructed simulated data. This sandbox process shares some similarities with the pre-running of the aforementioned periodic scenarios. During this process, continuous modifications and verifications are required until the rules to be launched meet the expected results.

[0073] The overall process and approach for pre-running real-time scenarios are largely similar to those for pre-running periodic scenarios. However, there are two key differences: First, real-time scenarios do not use real data as the sandbox data source, but instead use quotations for simulation construction. Second, after verification, there is no need to perform backtracking operations on the data documents because no real business documents meeting the conditions have been generated before going live.

[0074] Playback supports both backtesting by constructing feature datasets from historical real data through sampling, and backtesting by simulating and creating data features to form datasets as required.

[0075] In some embodiments, the method further includes: acquiring replay task information, wherein the replay task information includes replay data range information and replay rule information; generating a first rule for the target state in the first contract model based on the replay rule information; and determining the target billing source based on the replay data range information.

[0076] In some embodiments, determining the target billing source based on the replay data range information includes: in response to the replay data range information indicating historical data of supply chain logistics, using historical data as the target billing source; and the method further includes: obtaining a second billing result, wherein the second billing result is a billing result calculated by the second rule set in the online state; and step 104 includes: comparing the second billing result with a first billing result in the data storage table to generate a first comparison result; generating a verification result based on the first comparison result; wherein the first rule set and the second rule set are the same or different.

[0077] The calculation is performed by sampling feature data online (i.e., the target billing source). At the end, the playback result (i.e., the first billing result) is collected and compared with the historically sent results (i.e., the second billing result obtained based on the second rule set); this is used for technical and testing purposes.

[0078] In the playback verification management system, data is collected from historical real billing data and a feature dataset is constructed by specifying the characteristics of the data (such as business lines, expense items, rules, etc.) and the size of the data (such as coverage based on the quote).

[0079] During the replay process, the feature dataset can be accompanied by specified rules in the request. Specifying rules is the business-side replay objective, aiming to validate rules not yet deployed using historical data. Therefore, the system needs to be specifically informed of the rules to be used for billing during replay. After identification, the data results can be stored in a specific data storage table (i.e., a shadow table). This data storage table maintains a consistent structure with the online table and is used to store and observe stress test data. Finally, the replay results can be compared with historical real results to generate a comparison report. This report can observe differences in the number of data entries after replay, differences in billing amounts, differences in metadata during the billing process, and analyze the coverage of quotes during replay.

[0080] In some embodiments, determining the target billing source based on the playback data range information includes: constructing and generating the target billing source based on historical documents of the supply chain logistics when the playback data range information indicates the construction of data; and the method further includes: processing the target billing source based on a second rule set to generate a third billing result, wherein the second rule set is online; and step 104 includes: comparing the third billing result with the first billing result to generate a second comparison result; and generating a verification result based on the second comparison result.

[0081] The business configures a new quote, but it does not take effect immediately. Feature data is created by parsing rules (i.e., constructing and generating target billing sources). The quote is calculated using both the online quote (i.e., the second set of rules) and the inactive quote (the first set of rules), and the differences between the two are compared.

[0082] In simulated data creation and playback scenarios, since there are no historical results for comparison and verification, but the results should be able to be preset or predicted while simulating data creation, a comparison report can be generated by comparing the data results after simulation creation with the simulation creation results.

[0083] Sandbox replay, as a key testing method, plays a crucial role in the system's iterative update process. Its core elements are mainly reflected in the following aspects:

[0084] After the system completes its iteration, historical data, filtered and organized according to specific conditions, is replayed for regression verification. Regression effectively detects new defects or potential risks that may have been introduced during the iteration process, thereby ensuring the system's stability and reliability.

[0085] Sandbox replay features include the ability to simulate past system operation scenarios and states. By utilizing this historical data for replay, not only can new functions and features of the system be verified, but also comprehensive regression checks can be performed on fixed issues. In this process, it creates a safe and controllable environment for the development team, enabling them to deeply analyze and resolve problems, thereby ensuring the continuous and stable operation of the system and providing users with high-quality service and experience. Simultaneously, sandbox replay can also assist the team in evaluating system performance changes and comparing differences between different versions (i.e., comparing the first billing result and the second billing result), providing strong data support for subsequent optimization and improvement.

[0086] In some embodiments, the method further includes: obtaining recalculation task information, wherein the recalculation task information includes recalculation data range information and recalculation rule information; generating a first rule for the target state in a first rule set according to the recalculation rule information; and determining a target billing source from the billing sources that have generated original settlement results according to the recalculation data range information.

[0087] In some embodiments, the method further includes: in response to a verification result indicating that the verification has passed, reversing and / or supplementing the original settlement result based on the first billing result.

[0088] Reversal and adjustment, borrowed from accounting concepts, describe the handling of abnormal data records in the accounting process. They refer to correcting data by adding new records, rather than directly modifying the metadata. Reversal uses a new record to offset an erroneous record; adjustment uses both the new and original records to correct the result.

[0089] In some embodiments, processing the target billing source to generate a first billing result includes: generating a billing bill corresponding to the billing source; generating a billing task corresponding to the billing bill; and processing the billing task to obtain the billing result.

[0090] As an example, personnel or electronic devices can identify whether there are miscalculations or undercalculations in the billing results. If so, a recalculation task is created, the billing rules are modified, and the documents are recalculated. First, the rules are used to identify which documents require retrospective calculation.

[0091] Electronic devices trace back documents according to rules to complete the billing process, and the billing result is initially held at the billing end for verification by the business side to confirm whether the recalculated result meets expectations. If it does not meet expectations, the recalculation task or rules are modified until they do. The billing process then pushes the result to the settlement, and the settlement process determines whether the billing results need to be merged based on the business scenario.

[0092] There are roughly four scenarios in the specific implementation of recalculation: recalculation with specified rules, recalculation with supplementary rules, recalculation with specified metadata, and periodic recalculation.

[0093] During the recalculation of a specified rule, the rule remains unchanged, so no billing splitting or other actions are required, as all necessary sub-bill information has already been created. Therefore, it is only necessary to create the recalculation billing task for this rule, regenerate the billing results, and simultaneously reverse the original results.

[0094] The supplementary rule recalculation indicates a scenario where rules are missing. After supplementing the rules, the necessary billing invoices will be created. Therefore, the recalculation backtracking process needs to trace back to the billing source. Through the billing source, the execution process is repeated, loading the supplementary rules and creating new billing invoices and billing results. Since this is a recalculation after supplementation, there is no cancellation; only the supplementary billing results need to be generated.

[0095] Specified metadata recalculation, like traditional methods, does not involve changes to rules; it only replaces metadata values. Similarly, a billing task needs to be created, and the record for creating the billing task should include the metadata and values ​​to be replaced. During execution, if the billing engine finds the specified metadata and values, it will replace the original values. The resulting billing statement needs to be overwritten against historical results.

[0096] Periodic recalculation is similar to specified metadata recalculation; both require replacing the original metadata values.

[0097] It should be noted that by offsetting or supplementing, data can be corrected without directly modifying the metadata, but rather by adding new records. This method ensures data integrity and traceability, avoids the confusion and errors that may result from directly modifying the original data, and guarantees the accuracy and reliability of the settlement results.

[0098] In one or more embodiments of this disclosure, sandbox verification needs to ensure the consistency of billing results. To avoid the problem of inconsistent rule snapshots, the rules in the sandbox can be kept consistent with the rule model data in the online system, and can be distinguished only by the state. The different states of the rules are distinguished by the design of the state record. When the sandbox is completed, only the state needs to be changed, and there is no need to reconfigure, thereby ensuring the consistency between the sandbox rules and the online rules.

[0099] Definition and function of a sandbox environment: A sandbox environment is an environment similar to, but isolated from, the online environment. The characteristics of a sandbox environment include: it can be used to verify real functionality without affecting the real online environment.

[0100] Specific implementation method: In actual design, a data storage table (i.e., a shadow table) can be built for the document model. This involves constructing a table model that is highly consistent with the document model in the online environment and physically isolated from it. The advantage of this approach is that the entire execution logic requires no major changes, it can realistically simulate the actual execution logic, and the execution logic only needs to be checked before data persistence.

[0101] During the system execution chain, a sandbox execution decision is made. If sandbox verification is required, the results generated during execution are stored in the corresponding data storage table. This ensures that results are produced while maintaining the normal operation of online logic.

[0102] The construction and use of this sandbox environment provides a safe, reliable and efficient testing platform for the verification of business rules and system iteration, which helps to discover and resolve potential problems in advance and ensure the stability and reliability of the system.

[0103] Further reference Figure 6 As an implementation of the methods shown in the above figures, this disclosure provides an embodiment of a settlement device for supply chain logistics, which is similar to... Figure 1 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0104] like Figure 6 As shown, the settlement device for supply chain logistics in this embodiment includes: an acquisition unit 601, a first generation unit 602, a storage unit 603, a second generation unit 604, and a third generation unit 605. The acquisition unit is used to acquire the target billing source related to the supply chain logistics document; the first generation unit is used to process the target billing source based on a first contract model to generate a first billing result, wherein the first contract model includes a first rule set; the storage unit is used to, in response to a first rule in the first rule set including a target state, store the first billing result corresponding to the first rule in the target state in a data storage table, wherein the calculation process of the first rule in the target state is performed in a sandbox, and a data storage table is set for the sandbox, the data storage table being isolated from the online data of the supply chain logistics; the second generation unit is used to verify the first billing result in the data storage table and generate a verification result; the third generation unit is used to, in response to all rules in the first rule set being online, generate a settlement result for the target billing source based on the first billing result.

[0105] In this embodiment, the specific processing of the acquisition unit 601, the first generation unit 602, the storage unit 603, the second generation unit 604, and the third generation unit 605 of the settlement device for supply chain logistics, and the resulting technical effects, can be found by referring to [reference needed]. Figure 1 The relevant descriptions of steps 101, 102, 103, 104, and 105 in the corresponding embodiments will not be repeated here.

[0106] In some embodiments, the first contract model is a non-real-time settlement type; and the device is further configured to: in response to the verification result indicating that the verification has passed, generate a settlement result based on the first billing result, and adjust the target state rule to an online state.

[0107] In some embodiments, the first contract model is a non-real-time settlement type; and the apparatus is further configured to: in response to a verification result indicating failure, modify a first rule for the target state according to rule modification information; and process the target billing source based on the modified first rule.

[0108] In some embodiments, the first contract model is a real-time settlement type; and the acquisition of the target billing source related to supply chain logistics documents includes: constructing and generating the target billing source based on historical supply chain logistics documents; and the device is further configured to: adjust the first rule of the target state to the online state in response to a verification result indicating that it has passed; modify the first rule of the target state according to rule modification information in response to a verification result indicating that it has failed; and process the target billing source based on the modified first rule.

[0109] In some embodiments, the apparatus is further configured to: acquire replay task information, wherein the replay task information includes replay data range information and replay rule information; generate a first rule for the target state in the first contract model based on the replay rule information; and determine the target billing source based on the replay data range information.

[0110] In some embodiments, determining the target billing source based on the replay data range information includes: in response to the replay data range information indicating historical data of supply chain logistics, using historical data as the target billing source; and the device is further configured to: obtain a second billing result, wherein the second billing result is a billing result calculated by the second rule set in the online state; and verify the first billing result in the data storage table to generate a verification result, including: comparing the second billing result with the first billing result in the data storage table to generate a first comparison result; generating a verification result based on the first comparison result; wherein the first rule set and the second rule set may be the same or different.

[0111] In some embodiments, determining the target billing source based on the playback data range information includes: constructing and generating the target billing source based on historical documents of the supply chain logistics when responding to the playback data range information indicating data construction; and the device is further configured to: process the target billing source based on a second rule set to generate a third billing result, wherein the second rule set is online; and verifying the first billing result in the data storage table to generate a verification result includes: comparing the third billing result with the first billing result to generate a second comparison result; and generating a verification result based on the second comparison result.

[0112] In some embodiments, the apparatus is further configured to: acquire recalculation task information, wherein the recalculation task information includes recalculation data range information and recalculation rule information; generate a first rule for the target state in a first rule set according to the recalculation rule information; and determine a target billing source from the billing sources that have generated original settlement results according to the recalculation data range information.

[0113] In some embodiments, the apparatus is further configured to: in response to a verification result indicating that the verification has passed, to reverse and / or supplement the original settlement result based on the first billing result.

[0114] In some embodiments, processing the target billing source to generate a first billing result includes: generating a billing bill corresponding to the billing source; generating a billing task corresponding to the billing bill; and processing the billing task to obtain the billing result.

[0115] Please refer to Figure 7 , Figure 7 An exemplary system architecture is shown in which a settlement method for supply chain logistics, according to one embodiment of this disclosure, can be applied.

[0116] like Figure 7 As shown, the system architecture may include terminal devices 701, 702, and 703, a network 704, and a server 705. Network 704 serves as the medium for providing a communication link between terminal devices 701, 702, and 703 and server 705. Network 704 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0117] Terminal devices 701, 702, and 703 can interact with server 705 via network 704 to receive or send messages, etc. Various client applications, such as web browsers, search engines, and news apps, can be installed on terminal devices 701, 702, and 703. These client applications can receive user commands and perform corresponding functions, such as adding information to a message based on user instructions.

[0118] Terminal devices 701, 702, and 703 can be either hardware or software. When terminal devices 701, 702, and 703 are hardware, they can be various electronic devices with a display screen and support web browsing, including but not limited to smartphones, tablets, e-book readers, MP3 players (Moving Picture Experts Group Audio Layer III), MP4 players (Moving Picture Experts Group Audio Layer IV), laptops, and desktop computers, etc. When terminal devices 701, 702, and 703 are software, they can be installed in the aforementioned electronic devices. They can be implemented as multiple software programs or software modules (e.g., software programs or software modules used to provide distributed services) or as a single software program or software module. No specific limitations are made here.

[0119] Server 705 can be a server that provides various services, such as receiving information retrieval requests sent by terminal devices 701, 702, and 703, retrieving the corresponding display information according to the information retrieval request through various methods, and sending the relevant data for displaying the information to terminal devices 701, 702, and 703.

[0120] It should be noted that the settlement method for supply chain logistics provided in this embodiment can be executed by a terminal device, and correspondingly, the settlement device for supply chain logistics can be installed in terminal devices 701, 702, and 703. Furthermore, the settlement method for supply chain logistics provided in this embodiment can also be executed by a server 705, and correspondingly, the settlement device for supply chain logistics can be installed in server 705.

[0121] It should be understood that Figure 7 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0122] The following is for reference. Figure 8 It illustrates an electronic device suitable for implementing embodiments of the present disclosure (e.g., Figure 7 The diagram shows the structure of the terminal device or server in this disclosure. The terminal device in this embodiment may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), vehicle terminals (e.g., vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 8The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0123] like Figure 8 As shown, the electronic device may include a processing unit (e.g., a central processing unit, a graphics processor, etc.) 801, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 802 or a program loaded from a storage device 808 into a random access memory (RAM) 803. The RAM 803 also stores various programs and data required for the operation of the electronic device 800. The processing unit 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0124] Typically, the following devices can be connected to I / O interface 805: input devices 806 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 807 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 808 including, for example, magnetic tapes, hard disks, etc.; and communication devices 809. Communication device 809 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 8 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have alternatively.

[0125] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 809, or installed from a storage device 808, or installed from a ROM 802. When the computer program is executed by a processing device 801, it performs the functions defined in the methods of embodiments of this disclosure.

[0126] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0127] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol, such as HTTP (Hypertext Transfer Protocol), and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and end-to-end networks (e.g., ad hoc end-to-end networks), as well as any currently known or future-developed networks.

[0128] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0129] The aforementioned computer-readable medium carries one or more programs. When the electronic device executes the aforementioned one or more programs, the electronic device causes the electronic device to: acquire a target billing source related to supply chain logistics documents; process the target billing source based on a first contract model to generate a first billing result, wherein the first contract model includes a first set of rules; in response to a first rule in the first set including a target state, store the first billing result corresponding to the first rule in the target state in a data storage table, wherein the calculation process of the first rule in the target state is performed in a sandbox, and a data storage table is set up for the sandbox, wherein the data storage table is isolated from the online data of the supply chain logistics; verify the first billing result in the data storage table and generate a verification result; and in response to all rules in the first set being online, generate a settlement result for the target billing source based on the first billing result.

[0130] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0131] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0132] The units described in the embodiments of this disclosure can be implemented in software or in hardware. The name of a unit does not necessarily limit the unit itself; for example, a selection unit can also be described as a "unit for selecting a first type of pixel".

[0133] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0134] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0135] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations 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 disclosed in this disclosure that have similar functions.

[0136] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0137] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A settlement method for supply chain logistics, characterized in that, include: Obtain the target billing source related to supply chain logistics documents; Based on the first contract model, the target billing source is processed to generate the first billing result, wherein the first contract model includes a first set of rules; In response to the first rule set including a first rule of the target state, the first billing result corresponding to the first rule of the target state is stored in the data storage table. The calculation process of the first rule of the target state is carried out in the sandbox. A data storage table is set for the sandbox. The data storage table is isolated from the online data of the supply chain logistics. Verify the first billing result in the data storage table and generate a verification result; In response to the fact that all rules in the first rule set are online, a settlement result for the target billing source is generated based on the first billing result.

2. The method according to claim 1, characterized in that, The first contract model is a non-real-time settlement type; as well as The method further includes: In response to the verification result indicating that the verification has passed, a settlement result is generated based on the first billing result, and the target status rule is adjusted to the online status.

3. The method according to claim 2, characterized in that, The method further includes: In response to a failure in the verification result, the first rule for the target state is modified according to the rule modification information. The target billing source is processed based on the modified first rule.

4. The method according to claim 1, characterized in that, The first contract model is a real-time settlement type; as well as The target billing source for obtaining supply chain logistics documents includes: Based on historical supply chain logistics documents, a target billing source is constructed and generated; and The method further includes: In response to the verification result indicating that the verification is passed, the first rule of the target state is adjusted to the online state; In response to the verification result indicating failure, the first rule for the target state is modified according to the rule modification information; the target billing source is then processed based on the modified first rule.

5. The method according to claim 1, characterized in that, The method further includes: Obtain replay task information, which includes replay data range information and replay rule information; Based on the replay rule information, generate the first rule for the target state in the first contract model; The target billing source is determined based on the playback data range information.

6. The method according to claim 5, characterized in that, The step of determining the target billing source based on the playback data range information includes: In response to the playback data range information indicating historical data of supply chain logistics, historical data is used as the target billing source; and The method further includes: Obtain the second billing result, wherein the second billing result is the billing result calculated by the second rule set in the online state; and The step of verifying the first billing result in the data storage table and generating a verification result includes: The second billing result is compared with the first billing result in the data storage table to generate the first comparison result; Generate verification results based on the first comparison results; The first set of rules may be the same as or different from the second set of rules.

7. The method according to claim 5, characterized in that, The step of determining the target billing source based on the playback data range information includes: In response to the playback data range information indication during data construction, a target billing source is generated based on historical documents from the supply chain logistics; and The method further includes: Based on the second rule set, the target billing source is processed to generate a third billing result, wherein the second rule set is in an online state; and The step of verifying the first billing result in the data storage table and generating a verification result includes: The third billing result is compared with the first billing result to generate a second comparison result; The verification results are generated based on the second comparison results.

8. The method according to claim 1, characterized in that, The method further includes: Obtain recalculation task information, which includes recalculation data range information and recalculation rule information; Based on the recalculation rule information, generate the first rule for the target state in the first rule set; Based on the recalculation data range information, the target billing source is determined from the billing sources that have generated the original settlement results.

9. The method according to claim 8, characterized in that, The method further includes: In response to the verification result indicating that the transaction has passed, the original settlement result is reversed and / or supplemented based on the first billing result.

10. The method according to claim 1, characterized in that, The process of processing the target billing source to generate the first billing result includes: Generate the billing statement corresponding to the billing source; Generate the billing task corresponding to the billing bill; The billing task is processed to obtain the billing result.

11. A settlement device for supply chain logistics, characterized in that, include: The acquisition unit is used to acquire target billing sources related to supply chain logistics documents; The first generation unit is used to process the target billing source based on the first contract model and generate the first billing result, wherein the first contract model includes a first set of rules; A storage unit is used to respond to a first rule in the first rule set that includes a target state, and to store the first billing result corresponding to the first rule in the target state into a data storage table. The calculation process of the first rule in the target state is carried out in a sandbox. A data storage table is set up for the sandbox, and the data storage table is isolated from the online data of the supply chain logistics. The second generation unit is used to verify the first billing result in the data storage table and generate a verification result. The third generation unit is used to generate the settlement result of the target billing source based on the first billing result, in response to the fact that all the rules in the first rule set are online.

12. An electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-10.

13. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-10.

Images