A supermarket member hierarchical marketing triggering method based on cash register bill data

Abstract

This invention relates to the field of point-of-sale transaction technology, and more particularly to a method for triggering tiered marketing for supermarket members based on cashier bill data. The method associates successfully paid bills with pending event records in the same settlement transaction, and dispatches settlement bill events after the transaction is committed. A single iteration of the bill's product data forms bill features, and the incremental bill transaction is overlaid onto the member window status snapshot to generate tiered input states. Tiered configurations are matched to form target tiered results, and action mapping configurations are queried to generate outreach action instructions. Delivery control results are generated based on the action idempotency key, cashier terminal outreach count, and delivery deadline, executing front-end delivery, silent degradation, repetition suppression, or termination processing, and updating outreach audit records and member window states. This invention ensures consistency between duplicate or delayed settlement bill events, action delivery states, and member window states, improving the continuity of event processing and state consistency.

Description

Technical Field

[0001] This invention relates to the field of commercial data processing and point-of-sale transaction processing technology, and in particular to a method for triggering tiered marketing for supermarket members based on cashier bill data. Background Technology

[0002] In the field of commercial data processing and point-of-sale transaction processing technology, existing solutions for supermarket membership marketing typically involve the POS terminal generating a settlement bill and writing the bill identifier, member association identifier, product details, payment status, and settlement time into a transaction database. The membership system reads the member's historical transaction records at a preset period and generates member tags or membership levels based on the number of transactions, consumption amount, most recent transaction time, and product category. The marketing system then generates coupons, points, product recommendations, or page prompts based on the member tags, membership levels, or preset marketing conditions, and delivers the corresponding information through the POS terminal, member account, or mobile terminal.

[0003] Existing solutions often employ periodic member status calculations or independent triggering processes after payment completion. When the member status calculation time differs from the current settlement bill generation time, the current bill's product data typically only enters the member status in a subsequent statistical period. If all historical transaction details of a member are directly queried after payment, multiple data reads and aggregations need to be performed after the settlement bill event arrives. When the settlement bill event is transmitted asynchronously, it may also enter subsequent processing stages multiple times due to dispatch failures, compensation re-delivery, or duplicate delivery, resulting in repeated execution of the same outreach action or repeated updates of the member status for the same bill.

[0004] In scenarios where multiple transactions are completed consecutively at a POS terminal, existing solutions typically use the number of times a member receives a transaction or the number of marketing activities as the basis for limiting reach, rarely considering the POS terminal's front-end reach status within a preset time range. When a bill settlement event is delayed, the original payment completion interaction page may have already ended, but subsequent processing still follows the original actions. At the same time, when multiple POS terminals continuously process different bill settlements for the same member, inconsistencies may occur between the member status read results and the subsequent write results, leading to a lack of continuity between hierarchical input status, actual delivery status, and member status records.

[0005] For the joint processing of settlement bill events, current bill transaction increments, member window status snapshots, and the delivery status and version of reach actions, existing technologies still have shortcomings in terms of processing coordination regarding the current bill's participation in this member stratification, action control for duplicate events, selection of delivery methods for delayed events, and consistent updates to member status. Therefore, it is necessary to address the issue of maintaining consistency between stratified input formation, reach action control, and member status version updates in situations involving duplicate and delayed settlement bill events and continuous transactions at the POS terminal, focusing on the continuous processing of supermarket checkout bill events. Summary of the Invention

[0006] To address the aforementioned technical problems, this invention provides a method for triggering tiered marketing for supermarket members based on cashier bill data, comprising:

[0007] S100: Obtain the settlement bill for successful payment, and associate the settlement bill with the pending event in the same settlement transaction according to the bill identifier; after the settlement transaction is submitted, asynchronously dispatch the settlement bill event including the bill identifier, member association identifier, cashier terminal identifier, current bill product data and settlement timestamp;

[0008] S200: Traverse the current bill product data once to generate current bill features; obtain member window status snapshot and status version, and overlay the current bill transaction increment onto the member window status snapshot to generate layered input status;

[0009] S300: Match the layered input state with the layered configuration to determine the target layered result; query the action mapping configuration based on the target layered result to generate a reach action instruction including action type, delivery deadline, and degradation method;

[0010] S400: Generate an action idempotent key based on the bill identifier, member association identifier, and action type; based on the action idempotent key and the POS terminal reach count, compare the current time with the delivery deadline to generate a delivery control result, and perform front-end delivery, silent degradation, repetition suppression, or termination processing; associate the delivery control result with the status version to generate a reach audit record, and update the member window status and status version when the event processing status is not completed.

[0011] Furthermore, the pending event record and the settlement bill are written in the same settlement transaction; the pending event record includes an event identifier, a bill identifier, an event processing status, a number of retries, and a data summary of the current bill's product data; after the same settlement transaction is submitted, the event processing status is updated from pending to dispatched; after the asynchronous dispatch fails, the event processing status is updated to processing failed.

[0012] Furthermore, based on the event processing status, pending event records that are either awaiting dispatch or have failed to be processed are filtered, and compensation re-dispatch is performed based on the number of retries; the settlement bill event includes a transaction type and an original bill identifier; when the transaction type is a normal sales transaction, a refund transaction, a canceled transaction, a reversal transaction, or a test transaction, the corresponding event processing status is bound to it respectively; the refund transaction, the canceled transaction, and the reversal transaction are associated with the original bill identifier.

[0013] Further, the single traversal includes: sequentially reading the product code, category code, product quantity, product amount, and discount data from the current bill product data; accumulating the number of product items and net amount during the same traversal, and writing the category code into the product category code set; generating a net amount status based on the net amount, generating a category status based on the product category code set, and generating a settlement period status based on the settlement timestamp; and writing the number of product items, the net amount status, the category status, and the settlement period status into the current bill features.

[0014] Furthermore, the member window status snapshot includes the number of transactions, cumulative amount, average amount, recent transaction time, cumulative category status, and status version within the preset transaction window; the current bill transaction increment includes the transaction number increment, net amount increment, settlement timestamp, and category status increment; the current bill transaction increment is superimposed on the member window status snapshot to generate corrected transaction number, corrected cumulative amount, corrected average amount, corrected recent transaction time, and corrected cumulative category status, and the generated results are written to the hierarchical input status.

[0015] Furthermore, when updating the member window status, the currently saved status version of the member window status is obtained, and the currently saved status version is compared with the status version corresponding to the member window status snapshot; if the comparison is consistent, the member window status is updated based on the current bill transaction increment and the status version is updated; if the comparison is inconsistent, the member window status snapshot is re-obtained, the current bill transaction increment is superimposed on the re-obtained member window status snapshot, and the hierarchical input status is updated.

[0016] Furthermore, the hierarchical configuration includes multiple hierarchical conditions, priorities, mutual exclusion relationships, and hierarchical configuration versions; the hierarchical input state is matched with the multiple hierarchical conditions respectively to generate multiple candidate hierarchical results; the target hierarchical result is determined from the multiple candidate hierarchical results according to the priorities and the mutual exclusion relationships, and the hierarchical configuration version is bound to the target hierarchical result.

[0017] Furthermore, the action mapping configuration includes action type, delivery channel, action priority, validity period, degradation method, and action mapping configuration version; the action mapping configuration is queried according to the target layering result to determine the action type, delivery channel, action priority, validity period, and degradation method; the settlement timestamp is added to the validity period to generate the delivery deadline; and the action mapping configuration version is written into the reach action instruction.

[0018] Furthermore, when the member association identifier exists, the member association identifier is used as the normalized member key; when the member association identifier does not exist, the bill identifier is used as the normalized member key; the action idempotent key is generated based on the bill identifier, the normalized member key, the action type, and the action mapping configuration version; the reach audit record is queried based on the action idempotent key; when a reach audit record with an actual delivery status of successful delivery is found, a delivery control result for duplicate suppression is generated.

[0019] Further, the system acquires the terminal reach count within a preset counting window, compares the terminal reach count with a terminal reach count threshold, and compares the current time with the delivery deadline. When the terminal reach count is lower than the terminal reach count threshold and the current time has not exceeded the delivery deadline, the front-end delivery is executed. When the terminal reach count reaches the terminal reach count threshold or the current time exceeds the delivery deadline, a silent task is generated or termination is executed according to the degradation method. When the event handling status is "processing complete," the member window status, the status version, and the terminal reach count are not updated.

[0020] The key innovations of this invention include:

[0021] (1) Write the settlement bill that has been successfully paid and the event record to be dispatched in the same settlement transaction according to the bill identifier, and dispatch the settlement bill event asynchronously after the settlement transaction is submitted; if the dispatch fails, perform compensation re-dispatch according to the event processing status and retry count in the event record to be dispatched, forming an event processing link in which the persistent status of the settlement bill and the event dispatch status are mutually related.

[0022] (2) Perform a single traversal on the current bill product data to form the current bill features; obtain a member window status snapshot with a status version according to the member association identifier, overlay the current bill transaction increment onto the member window status snapshot to form a hierarchical input status for this hierarchical configuration matching, and pass the current bill transaction increment and the status version to the member window status update stage.

[0023] (3) Generate a reach action instruction including action type, delivery deadline and degradation method according to the target layering result and action mapping configuration; generate an action idempotent key according to the bill identifier, member association identifier and action type, and generate the delivery control result corresponding to front-end delivery, silent degradation, repetition suppression or termination processing by combining the POS terminal reach count and the comparison result between the current time and the delivery deadline; write the delivery control result and status version into the reach audit record, and control the update of member window status and status version according to the event processing status.

[0024] The following are its main beneficial effects:

[0025] (1) To address the issue that the corresponding events may fail to be dispatched or arrive late after the settlement bill is persisted, the settlement bill and the event record to be dispatched are written together in the same settlement transaction, and asynchronous dispatch is performed after the transaction is committed, so that the bill persistence result and the event processing status remain consistent; if the dispatch fails, the settlement bill event can be restored based on the event record to be dispatched, without having to re-execute the payment transaction of the settlement bill.

[0026] (2) To address the issue that the current bill cannot be promptly entered into the current member tier and the complete historical transaction details of the member can be read in real time, the current bill features are formed by traversing the current bill product data in a single pass, and the transaction increment of the current bill is superimposed on the member window status snapshot, so that the current bill enters the current tier input state; the status version enters the subsequent update process with the transaction increment of the current bill, so that when the versions are inconsistent, the member window status snapshot can be re-obtained and the corresponding update can be performed.

[0027] (3) To address the issues of repeated delivery and delayed delivery of settlement bill events, as well as the easy repeated updates of touch actions and member status during continuous transactions at the POS terminal, actions that have been successfully delivered are identified by action idempotency keys, actions that are still within the delivery deadline are distinguished from late actions by delivery deadlines, and the front-end delivery path is controlled by the POS terminal touch count. When the event processing status has been completed, the member window status, status version, and POS terminal touch count are no longer updated, so that the actual delivery status of the touch action corresponds to the member window status update record. Attached Figure Description

[0028] Figure 1 A flowchart illustrating a supermarket membership tiered marketing triggering method based on cashier bill data, provided as an embodiment of this application;

[0029] Figure 2 This is a structural block diagram of a supermarket membership tiered marketing triggering method based on cashier bill data, provided in an embodiment of this application. Detailed Implementation

[0030] Example 1: Refer to Figure 1 This is a flowchart illustrating a supermarket membership tiered marketing triggering method based on cashier bill data, provided by an embodiment of the present invention. The process may include at least steps S100-S400:

[0031] S100: Obtain the settlement bill for successful payment, and associate the settlement bill with the pending event in the same settlement transaction according to the bill identifier; after the settlement transaction is submitted, asynchronously dispatch the settlement bill event including the bill identifier, member association identifier, cashier terminal identifier, current bill product data and settlement timestamp;

[0032] S200: Traverse the current bill product data once to generate current bill features; obtain member window status snapshot and status version, and overlay the current bill transaction increment onto the member window status snapshot to generate layered input status;

[0033] S300: Match the layered input state with the layered configuration to determine the target layered result; query the action mapping configuration based on the target layered result to generate a reach action instruction including action type, delivery deadline, and degradation method;

[0034] S400: Generate an action idempotent key based on the bill identifier, member association identifier, and action type; based on the action idempotent key and the POS terminal reach count, compare the current time with the delivery deadline to generate a delivery control result, and perform front-end delivery, silent degradation, repetition suppression, or termination processing; associate the delivery control result with the status version to generate a reach audit record, and update the member window status and status version when the event processing status is not completed.

[0035] S100. Obtain the settlement bill for successful payment, and write the settlement bill and the pending event record in the same settlement transaction according to the bill identifier; after the settlement transaction is submitted, asynchronously dispatch the settlement bill event including the bill identifier, member association identifier, cashier terminal identifier, current bill product data and settlement timestamp.

[0036] This step is executed by the POS bill persistence component and the settlement event generation unit. The POS bill persistence component runs on a manual POS terminal, a self-service POS terminal, or a store server connected to multiple POS terminals, and receives payment result callbacks and product pricing results in the current settlement session. The settlement event generation unit accesses the same bill storage area and event record storage area as the POS bill persistence component, and initiates this step when the payment status is updated from pending payment to payment successful. The payment result callback includes a payment transaction identifier, payment status, payment completion time, and bill identifier; the current settlement session includes a member association identifier, POS terminal identifier, current bill product data, transaction type, and settlement timestamp.

[0037] The settlement bill is a transaction data object that has completed product pricing and includes a bill identifier, current bill product data, net amount, payment status, and settlement timestamp. The current bill product data is organized by product item, with each product item including product code, category code, product quantity, product amount, and discount data. The transaction types include normal sales, refund transactions, cancellation transactions, reversal transactions, and test transactions. For normal sales, the original bill identifier is the same as the bill identifier. For refund transactions, cancellation transactions, and reversal transactions, the original bill identifier is written with the bill identifier corresponding to the refunded, cancelled, or reversed settlement bill. For test transactions, the transaction type is bound to the test status, and subsequent steps generate termination processing or only generate an audit record based on the test status.

[0038] The pending event record is a data record formed by writing an event identifier, a bill identifier, an event processing status, a retry count, and a data summary of the current bill's product data into the same settlement transaction corresponding to the settlement bill. Specifically, after the cashier bill persistence component starts a settlement transaction, it first writes the settlement bill with a payment success status into the bill storage area; the settlement event formation unit generates the pending event record within the settlement transaction using the bill identifier as the associated field; the event processing status in the pending event record is initially set to pending dispatch, and the retry count is initially set to 0. The data summary of the current bill's product data can be obtained by concatenating the product code, category code, product quantity, product amount, and discount data in the order of product items, and then performing a summary calculation on the concatenation result; the data summary participates in subsequent event content verification but does not replace the current bill's product data.

[0039] When both the settlement bill and the pending event record are written, the POS bill persistence component submits the settlement transaction. If any write operation returns to a failure state, the POS bill persistence component rolls back the settlement transaction, and neither the settlement bill nor the pending event record enters the submitted state. After the settlement transaction is submitted, the settlement event generation unit obtains the bill identifier based on the pending event record and reads the member association identifier, POS terminal identifier, current bill product data, transaction type, payment status, original bill identifier, and settlement timestamp from the submitted settlement bill. The settlement event generation unit binds the read results with the event identifier and encapsulates them to form the settlement bill event.

[0040] The asynchronous dispatch refers to the process whereby, after the settlement transaction is submitted, the settlement event forming unit sends the settlement bill event to the bill feature forming unit. The dispatch result of the settlement bill event does not participate in the submission of the settlement transaction. Upon successful dispatch, the settlement event forming unit updates the event processing status in the pending event record from pending dispatch to dispatched and writes the dispatch time. Upon failure, the event processing status is updated to processing failed, the retry count is incremented by 1, and the event identifier, bill identifier, and data digest are retained. In one embodiment, the asynchronous dispatch is executed via an in-process publish-subscribe method; in another embodiment, the pending event record is stored in a local message table, and the store server filters and sends the pending records according to a preset reading cycle.

[0041] For pending event records that are in a state of pending dispatch or processing failure, the settlement event generation unit performs compensatory re-dispatch based on the event processing status and the number of retries. Specifically, the settlement event generation unit reads the corresponding settlement bill according to the bill identifier, recalculates the data summary of the current bill's product data, and compares the recalculated data summary with the data summary in the pending event record. If the comparison matches, the settlement bill event is repackaged according to the settlement bill and asynchronous dispatch is performed. If the comparison does not match, the event processing status is kept as processing failure, and a bill content inconsistency marker is recorded. Compensatory re-dispatch does not rewrite the settlement bill and does not add new pending event records with the same bill identifier and event type.

[0042] In a store implementation scenario, the self-service checkout terminal completes the pricing of goods for bill B202606150001, and the payment platform returns a payment success status. The bill includes a member association identifier M00821, a checkout terminal identifier T03, 5 product items, and a settlement timestamp of June 15, 2026, at 14:32:10. The checkout bill persistence component writes the settlement bill and the pending event record corresponding to event identifier E202606150001 into the same settlement transaction. After the transaction is committed, the settlement event formation unit encapsulates and dispatches the settlement bill event. When the initial dispatch returns a failure status, the event processing status is written as "processing failed," and the retry count is written as 1. During compensation re-dispatch, the settlement bill is reread using the bill identifier, and after the data digest is compared and found to be consistent, it is dispatched again. After successful dispatch, the event processing status is updated to "dispatched."

[0043] The settlement bill event generated in this step includes an event identifier, a bill identifier, a member association identifier, a POS terminal identifier, a transaction type, a payment status, an original bill identifier, current bill product data, and a settlement timestamp. The event identifier and bill identifier are used for idempotency verification and reach auditing records in subsequent actions. The member association identifier is used by S200 to obtain a snapshot of the member window status. The current bill product data and the settlement timestamp are used by S200 to generate current bill features. The POS terminal identifier is used by S400 to obtain the POS terminal reach count. Event records pending dispatch generated from the same settlement transaction are retained in the event record storage area, and the event processing status is updated based on the actual execution status after subsequent steps are completed.

[0044] S200. Traverse the current bill product data once to generate current bill features; obtain member window status snapshot and status version, and overlay the current bill transaction increment onto the member window status snapshot to generate layered input status.

[0045] This step is performed by the bill feature formation unit and the window status processing unit. The bill feature formation unit receives the settlement bill event dispatched by S100 and parses the event identifier, bill identifier, member association identifier, current bill product data, and settlement timestamp. The window status processing unit accesses the member window status storage area based on the member association identifier and obtains the member window status snapshot and status version bound to the member association identifier. When the event processing status of the settlement bill event is dispatched, the bill feature formation unit starts reading the current bill product data. If the event content does not match the data summary, the current bill feature generation is not performed, and the event processing status is updated to processing failure.

[0046] The single traversal refers to reading each product item in the current bill's product data sequentially, accumulating the number of product items, net amount, and category status during the same traversal, without repeatedly reading all product items for different current bill features. Specifically, the bill feature forming unit sets an initial value for the number of product items, an initial value for the net amount, and a set of product category codes; after reading a product item, the quantity of the corresponding product is written into the product item count accumulation process, the product amount calculated from the discount data is written into the net amount accumulation process, and the category code is written into the product category code set; after reading all product items, the number of product items, net amount, and product category code set are formed.

[0047] In one implementation, the number of product items is accumulated based on the number of product detail rows; in another implementation, the number of product items is accumulated based on the sum of the quantities of each product item. The accumulation method is defined by the corresponding field definition in the hierarchical configuration, and the same method is maintained within the same hierarchical configuration version. The net amount is obtained by summing the product amount of each product item after subtracting the discount amount recorded in the discount data. When the settlement bill already contains the confirmed net amount, the bill feature forming unit compares the net amount calculated by product item with the net amount in the settlement bill. If they match, the net amount in the settlement bill is used; if they do not match, an amount discrepancy flag is written, and the event processing status is updated to processing failure or transferred to manual review.

[0048] The net amount status is obtained by matching the net amount with the amount range configuration; the amount range configuration includes multiple consecutive or non-overlapping amount ranges, and each amount range is bound to a net amount status. The category status is obtained by matching the product category code set with the category set referenced by the hierarchical configuration; when there is a category code in the product category code set that is the same as the category set, the corresponding category hit status is written; when the hierarchical configuration uses category counting, the bill feature forming unit synchronously accumulates the number of products corresponding to each category code during a single traversal. The settlement period status is obtained by matching the settlement timestamp with the period configuration; the period configuration includes multiple time start points and time end points, and each time range is bound to a settlement period status.

[0049] When the category code in a product item is empty, the bill feature generation unit retains the product code and product quantity, and writes a category code missing marker into the current bill feature; the category code missing marker is not considered a category mismatch status. The bill feature generation unit can query the product data storage area to obtain the category code based on the product code; if the query is successful, the category code is added and the product category code set is updated; if the query fails, the category code missing marker is retained. When the current bill product data is empty, the number of product items is 0, or the payment status is not successful, the bill feature generation unit stops generating the current bill feature corresponding to a normal sale and updates the event handling status to processing failure or termination of processing.

[0050] The member window status snapshot is an aggregated member transaction status formed within a preset transaction window, including the number of transactions, cumulative amount, average amount, most recent transaction time, cumulative category status, and status version. The preset transaction window is defined by window configuration; in one embodiment, the preset transaction window is the most recent N completed normal sales transactions, where N is a pre-configured positive integer; in another embodiment, the preset transaction window is a preset time range prior to the current settlement timestamp. The member window status storage area saves the member window status according to the member association identifier; when the window status processing unit reads the member window status, it simultaneously obtains the currently saved status version and writes the status version into the processing context of this event.

[0051] When the member association identifier exists but there is no corresponding record in the member window status storage area, the window status processing unit generates an initial member window status snapshot. In this initial member window status snapshot, the number of transactions and the cumulative amount are set to 0, the average amount is set to 0, the most recent transaction time is set to null, the cumulative category status is set to an empty set, and the status version is set to the initial version. When the member association identifier does not exist, the window status processing unit does not establish a cross-bill member window status, uses the bill identifier as the index for this settlement bill event, and generates a hierarchical input status that only contains the current bill transaction increment. The bill identifier is used as a normalized member key in S400 to participate in the generation of the action idempotent key.

[0052] The current bill transaction increment includes transaction count increment, net amount increment, settlement timestamp, and category status increment. For normal sales, the transaction count increment is set to 1, the net amount increment is set to the current bill net amount, the settlement timestamp is used as a candidate value for the most recent transaction time, and the category status increment is formed by the current bill product category code set. The window status processing unit overlays the current bill transaction increment onto the member window status snapshot to generate corrected transaction count, corrected cumulative amount, corrected average amount, corrected most recent transaction time, and corrected cumulative category status. The corrected transaction count is the sum of the original transaction count and the transaction count increment; the corrected cumulative amount is the sum of the original cumulative amount and the net amount increment; the corrected average amount is the corrected cumulative amount divided by the corrected transaction count; the corrected most recent transaction time is set to the current settlement timestamp; and the corrected cumulative category status is obtained by merging the original cumulative category status and the category status increment according to the category code.

[0053] In the implementation where the preset transaction window uses the most recent N transactions, when the original number of transactions has reached N, the member window status simultaneously saves the amount value and category status corresponding to the earliest transaction within the window. Before adding the current bill transaction increment, the earliest transaction amount is first deducted from the accumulated amount value, and the category count corresponding to the earliest transaction is deducted from the accumulated category status, and then the current bill transaction increment is added. In the implementation where the preset transaction window uses a time range, the window status processing unit first removes the accumulated transaction items whose settlement timestamp is earlier than the window start point, and then adds the current bill transaction increment. Transaction details within the window can be saved in the transaction window record bound to the member's associated identifier, and the member window status snapshot saves the aggregated value calculated from the transaction window record.

[0054] For refund, cancellation, and reversal transactions, the window status processing unit queries the original settlement bill and its window status update records based on the original bill identifier. When the original settlement bill has already been written to the member window status, a reverse transaction increment is generated according to the number of transactions, net amount, and category status in the original settlement bill, and the reverse transaction increment is written to the hierarchical input status. When the original settlement bill has not yet been written to the member window status, no reverse transaction increment is generated, and a flag indicating that the original bill has not been updated is written to the event processing context. Test transactions are not superimposed on the member window status snapshot, and their current bill characteristics can be retained in the access audit records.

[0055] In a manual checkout scenario, the settlement bill event includes 5 product items, totaling 7 product items based on quantity, with a net amount of 236.50 yuan. The product category code set includes fresh produce, dairy products, and daily necessities. The settlement timestamp falls within the time range of 2 PM to 5 PM. Based on this, the bill feature generation unit generates the product item count (7), net amount status (A3), category status (C2), and settlement time period status (T2). The member window status snapshot saves the transaction count (4), cumulative amount (720.00 yuan), average amount (180.00 yuan), and status version (V12). After overlaying the current bill transaction increment, it generates the corrected transaction count (5), corrected cumulative amount (956.50 yuan), corrected average amount (191.30 yuan), corrected most recent transaction time, and corrected cumulative category status.

[0056] This step outputs the current bill features and hierarchical input status. The current bill features include the number of items, net amount status, category status, settlement period status, and feature status markers formed when fields are missing. The hierarchical input status includes the current bill features, corrected transaction count, corrected cumulative amount, corrected average amount, corrected most recent transaction time, corrected cumulative category status, and the status version read this time. The hierarchical input status and settlement timestamp are invoked by S300. The current bill transaction increment and status version are retained in the event processing context and invoked when S400 generates the audit record and updates the member window status.

[0057] In one specific embodiment: In S200, the current bill product data is traversed once to generate the current bill features; a member window status snapshot and status version are obtained, and the current bill transaction increment is superimposed on the member window status snapshot to generate a layered input status.

[0058] This step is performed by the bill feature formation unit and the window status processing unit. The bill feature formation unit receives the settlement bill event dispatched by S100, and parses the event identifier, bill identifier, member association identifier, current bill product data, and settlement timestamp. The window status processing unit accesses the member window status storage area based on the member association identifier and obtains the member window status snapshot and status version bound to the member association identifier. When the event processing status of the settlement bill event is dispatched, the bill feature formation unit starts reading the current bill product data; if the event content does not match the data summary, the current bill feature generation is not performed, and the event processing status is updated to processing failure. The single traversal refers to reading each product item in the order of the product items in the current bill product data, and accumulating the number of product items, net amount, and category status during the same traversal, without repeatedly reading all product items for different current bill features. Specifically, the bill feature forming unit sets an initial value for the number of product items, an initial value for the net amount, and a set of product category codes. After reading a product item, the quantity of the corresponding product is written into the product item count accumulation process, the net amount calculated from the product amount and discount data is written into the net amount accumulation process, and the category code is written into the set of product category codes. To solve the problem of quantitatively representing both the net amount and the category code set in a single traversal, formula ① is introduced. This formula transforms the original product item data into a set of net amount and category codes that can be used for subsequent hierarchical matching:

[0059]

[0060]

[0061] in, Net amount: This is the sum of the total price of all items minus the discount amount.

[0062] The total number of product items in the current bill (based on the number of detailed rows) is taken from the number of records in the product data of the current bill;

[0063] Product item index, value Superscripts are used to distinguish different product items;

[0064] : No. The product amount is extracted from the "Product Amount" field in the current bill product data;

[0065] : No. The discount amount corresponding to each product is obtained by parsing the "Discount Data" field in the current bill's product data;

[0066] The product category code set is formed by taking the union of the category codes of all product items;

[0067] : No. The category code of each product is taken from the "Category Code" field in the current bill product data;

[0068] : Set union operator.

[0069] Data source mapping: Extract the product amount for each item from the current bill product data. Discount Amount and category codes The cumulative net amount is obtained Merging category codes yields .

[0070] Net amount generated by formula ① and category code set Formulas ② and ③ will be used directly. After completing a single traversal, the bill feature forming unit further matches the net amount with the amount range configuration to generate a net amount status. For this purpose, Formula ② is used, which discretizes the continuous net amount into predefined net amount status labels:

[0071]

[0072] in, : Net amount status, the value is taken from the set of status labels bound in the amount range configuration (such as "A1" "A2");

[0073] : Amount range index, value ;

[0074] The total number of ranges in the amount range configuration;

[0075] : Indicator function, takes the value 1 when the condition in parentheses is true, otherwise takes the value 0;

[0076] : The net amount as defined in Formula ①;

[0077] : No. A number of amount intervals are defined by the configuration of the amount intervals, and each interval is either a left-closed and right-open or a closed interval.

[0078] : Belongs to the category of symbols;

[0079] Returns the unique interval index that makes the indicator function value 1. The operation.

[0080] Data source mapping: Read each range based on the amount range configuration. And its bound status label, obtained from formula ① Perform inclusion matching with each interval, and output the corresponding status label after a unique interval is matched.

[0081] Formula ② As part of the current bill feature, it will be referenced in the context of formula ④. Next, the bill feature forming unit will determine the product category code set based on this. The category status is generated by matching the category set referenced in the hierarchical configuration. Formula ③ is used to achieve set matching and count aggregation:

[0082]

[0083]

[0084] in, Category status, which is a boolean value or an enumeration value when the hit flag method is used in the hierarchical configuration;

[0085] The number of category collections referenced in the hierarchical configuration;

[0086] Category collection index, value ;

[0087] The logical AND operator performs a conjunction of multiple Boolean values.

[0088] Indicator function, defined as in formula ②;

[0089] The same set of category codes as defined in formula ①;

[0090] : Set intersection operator;

[0091] : No. The referenced category set is defined by the "Category Set" field in the hierarchical configuration and contains multiple category codes;

[0092] : Not equal to symbol;

[0093] : Empty set symbol;

[0094] : Category counting vector, used only when category counting is used in hierarchical configuration, its elements are the frequency of occurrence of each category code;

[0095] The total number of product items as defined in formula ①;

[0096] The same as the product item index defined in formula ①;

[0097] : Same category code as defined in formula ①;

[0098] : No. Each category code, among which , The total number of codes for all possible product categories;

[0099] : Transpose symbol, converts a row vector into a column vector.

[0100] Data source mapping: read from the aforementioned hierarchical configuration From formula ①, we get and each item Calculate the intersection and frequency.

[0101] Formula ③ generated and This will be used as part of the current bill feature and for updating the category cumulative status in formula ④. This step then outputs the number of product items in the current bill feature (obtained through iteration and cumulatively, denoted as...). (dimensionless) and net amount status Category Status The above fields, along with the status of settlement periods that have not yet been completed (to be generated by formula ⑤), and the settlement timestamp and product category code set, are also included. Together, they are used as intermediate products and called by the subsequent processing links of this step and the hierarchical input status of S300.

[0102] Continuing from the net amount obtained by formula ① above Category code set And the net amount status obtained from formulas ② and ③ and category status The window state processing unit accesses the member window state storage area based on the member association identifier to obtain a member window state snapshot and state version. The member window state snapshot is a member transaction aggregation state formed within a preset transaction window, including the number of transactions. Cumulative Amount Average amount Recent trading time Product category cumulative status and status version To address the issue of how to instantly overlay the current transaction increment onto the window state snapshot to form the current layered input when the current bill arrives, while preserving the original state version for subsequent optimistic locking updates, formula ④ is introduced. This formula uses a state-space update method to describe the transition process of the window state from the old snapshot to the corrected snapshot:

[0103]

[0104] in, The number of transactions in the original member window status snapshot is read from the member window status storage area;

[0105] Correct the number of transactions;

[0106] : Increment of the number of transactions in the current bill. It is 1 for normal sales and is generated by this step based on the transaction type.

[0107] The original cumulative amount is read from the member window status storage area;

[0108] Corrected cumulative amount;

[0109] The net increase is directly taken from formula ①. ;

[0110] : Adjust the average amount;

[0111] : Current settlement timestamp, taken from the settlement bill event;

[0112] : Correct the most recent transaction time;

[0113] : The cumulative status of the original product category, which records the cumulative number of transactions for each product category code in vector form;

[0114] Correct the cumulative status of product categories;

[0115] Vector element-wise addition operator;

[0116] Category status increment, taken from formula ③ vector;

[0117] The same category counting vector as defined in formula ③.

[0118] Data source mapping: read from the member window state storage area. Extracted from the settlement bill event From formula ①, we get From formula ③, we get Transaction type determination .

[0119] Formula ④ gives the corrected state This constitutes the core part of the hierarchical input state.

[0120] Simultaneously, the window status processing unit matches the settlement timestamp with the time period configuration to generate the settlement time period status, using formula ⑤:

[0121]

[0122] in, : Settlement period status, the value is taken from the period label (such as "T1" "T2") bound in the period configuration;

[0123] : A time-segment matching function that maps the input timestamp to the corresponding time-segment status;

[0124] : The current settlement timestamp as defined in formula ④;

[0125] Time interval index, value ;

[0126] The total number of time periods in the time period configuration;

[0127] Indicator function, defined as in formula ②;

[0128] : Belongs to the category of symbols;

[0129] : No. The time range of each time period is defined by the start and end times in the time period configuration;

[0130] Returns the unique time period index that makes the indicator function value 1. The operation;

[0131] Data source mapping: Read each time period configuration and its associated time period status, will Matched with.

[0132] Output of Formula ⑤ Compared with the previously obtained number of items Net Amount Status Category Status Together, these elements form the complete current bill characteristics. This step then outputs the hierarchical input status, including the current bill characteristics (number of items). Net Amount Status Category Status Status during settlement period ) and the number of corrected transactions obtained from formula ④ Correction amount cumulative value Corrected average amount Correct the most recent transaction time Correcting the cumulative status of product categories It also includes the state version corresponding to the member window state snapshot read this time. .

[0133] The above-mentioned hierarchical input status and the settlement timestamp Called by the layered result generation unit of S300; the current bill transaction increment ( ) and status version It is retained in the event handling context and invoked when S400 generates an access audit log and updates the member window state.

[0134] For refund transactions, cancellation transactions, and reversal transactions, the window status processing unit queries the original settlement bill and its window status update record based on the original bill identifier; when the original settlement bill has been written into the member window status, it is necessary to generate a reverse transaction increment to undo the impact of the original bill on the window status.

[0135] Formula 6 is introduced, which constructs the reverse update quantity using the incremental information of the original bill:

[0136]

[0137] in, Increase in the number of reverse transactions;

[0138] The transaction increment corresponding to the original settlement bill (1 for normal sales) is read from the window status update record of the original settlement bill or determined according to the transaction type of the original bill.

[0139] : Reverse net increase in amount;

[0140] The net amount of the original settlement statement is taken from the net amount field of the original settlement statement.

[0141] : Inverse category counting increment vector;

[0142] The category count vector of the original settlement bill is calculated from the product items of the original bill using formula ③.

[0143] Data source mapping: The original bill is retrieved by querying the member window status storage area or accessing the audit records using the original bill identifier. , , The negative value is then written to the hierarchical input status. When the original settlement bill has not yet been written to the member window status, no reverse transaction increment is generated, and a flag indicating the original bill has not been updated is written to the event handling context. Test transactions are not overlaid on the member window status snapshot; their current bill characteristics can be retained in the access audit log.

[0144] The reverse increment is written to the hierarchical input state, allowing S400 to perform a deduction operation when updating the member window state. The final output of this step is: the current bill features (number of items, net amount status, category status, settlement period status, and feature status markers when fields are missing), the hierarchical input state (including corrected transaction count, corrected cumulative amount, corrected average amount, corrected most recent transaction time, corrected cumulative category status, and status version), and the current bill transaction increment and status version retained in the event processing context. The hierarchical input state and settlement timestamp in the above output are directly called by S300; the current bill transaction increment and status version are used by the delivery control unit and status write-back unit of S400 to generate access audit records and conditionally update the member window state.

[0145] The technical effects of this section are as follows: By extracting the net amount and category code set simultaneously in a single traversal, and using the state space equation to instantly overlay the current bill increment onto the window snapshot, the decoupling of bill feature generation and window state pre-update is achieved; the reverse increment mechanism ensures the revocability of the window state for abnormal transactions, and the transmission of state versions provides a basis for subsequent concurrency control.

[0146] S300: Match the layered input state with the layered configuration to determine the target layered result; query the action mapping configuration based on the target layered result to generate a reach action instruction including action type, delivery deadline, and degradation method.

[0147] This step is executed by the layered result generation unit and the action instruction generation unit. The layered result generation unit receives the layered input status, settlement timestamp, and status version generated in S200, and obtains the layered configuration from the configuration storage area. The action instruction generation unit receives the target layered result and obtains the action mapping configuration from the configuration storage area. The configuration storage area saves configuration records according to the store identifier, configuration version, and configuration effective time range. When the settlement bill event does not carry a store identifier, the configuration record is queried using the store identifier bound to the POS terminal identifier.

[0148] The tiered configuration includes multiple tiering conditions, priorities, mutual exclusion relationships, and tiering configuration versions. Each tiering condition includes a condition identifier, input fields, comparison methods, condition values, and candidate tiering labels. The input fields are selected from the tiering input states: net amount status, category status, settlement period status, corrected transaction count, corrected average amount, corrected most recent transaction time, and corrected cumulative category status. The comparison methods include interval matching, numerical comparison, set matching, and time interval matching. Priorities are represented by numerical or ordinal fields. Mutual exclusion relationships are used to mark candidate tiering labels that cannot simultaneously serve as target tiering results. The tiering configuration version is bound to the configuration effective time range.

[0149] The tiered result generation unit filters tiered configurations from the configuration storage area based on the settlement timestamp, ensuring that the effective time range of the configuration covers the settlement timestamp. When multiple valid configuration versions exist, the tiered configuration version with the closest effective time start and not later than the settlement timestamp is selected. The tiered result generation unit sequentially reads multiple tiered conditions in the tiered configuration and matches the input field specified by each tiered condition with the condition value according to a comparison method. When a match is found, a candidate tiered result is generated, including a condition identifier, candidate tiered label, priority, mutual exclusion relationship, and tiered configuration version. When a match is not found, no candidate tiered result is generated for that condition.

[0150] In one implementation, a candidate stratification label is generated by one stratification condition; in another implementation, a candidate stratification label corresponds to multiple stratification conditions, and a corresponding candidate stratification result is generated only when all multiple stratification conditions are met. For example, a candidate stratification label corresponds to three conditions: the number of corrected transactions is not less than a preset number, the average corrected amount belongs to a preset amount range, and the current bill category status matches a specified category set. The stratification result generation unit obtains the matching results of the three conditions respectively, and generates the candidate stratification result when all three matching results are met. The field values ​​and condition identifiers used in the condition matching process are written into the candidate stratification result for storage in the audit log.

[0151] When multiple candidate layering results are generated, the layering result generation unit first divides the multiple candidate layering results into multiple mutually exclusive groups according to mutual exclusion relationships; within the same mutually exclusive group, the candidate layering result with the highest priority is selected according to priority order; when there is an overlay relationship between different mutually exclusive groups, the overlay order recorded in the layering configuration is used for selection; after the selection is completed, the corresponding candidate layering label is written as the target layering result, and the layering configuration version is bound to the target layering result. When no layering condition is met, a default target layering result is generated in one implementation; in another implementation, a target layering result without action is generated, and the action instruction generation unit forms the trigger action instruction corresponding to the termination processing.

[0152] The action mapping configuration includes target hierarchical tags, action types, delivery channels, action priorities, validity periods, degradation methods, and action mapping configuration versions. The action instruction generation unit uses the target hierarchical tags in the target hierarchical results as query conditions to retrieve action records from the action mapping configuration whose configuration effective time range covers the settlement timestamp. When multiple action records exist, the unit filters for the action record with the highest priority based on action priority, or generates multiple reach action instructions according to the execution order of multiple actions recorded in the action mapping configuration. One reach action instruction corresponds to one action type; multiple action types form multiple action idempotent keys, and delivery control is executed separately in S400.

[0153] The action type is used to mark front-end prompt data, rights writing requests, print data, or silent tasks; the delivery channel is used to mark payment completion interaction pages, member accounts, card wallets, or receipt printing components; the validity period is the length of action delivery time calculated from the settlement timestamp; the degradation method is the silent task or termination processing method adopted when the front-end delivery conditions are not met. The action instruction generation unit adds the settlement timestamp to the validity period to generate the delivery deadline; when the validity period is in seconds, the validity period is converted to the corresponding number of seconds and added to the settlement timestamp; when the validity period is in minutes, the validity period is converted to the corresponding number of minutes and the time calculation is performed.

[0154] The action instruction generation unit writes the action type, delivery channel, action priority, delivery deadline, degradation method, action mapping configuration version, target hierarchical result, bill identifier, member association identifier, and POS terminal identifier into the reach action instruction. The bill identifier, member association identifier, action type, and action mapping configuration version in the reach action instruction are used by S400 to generate the action idempotent key; the POS terminal identifier is used by S400 to obtain the POS terminal reach count; the delivery deadline is used by S400 to compare with the current time; and the degradation method is used by S400 to generate a silent task or terminate the process when the terminal reach count reaches a threshold or the current time exceeds the delivery deadline.

[0155] When a tiered configuration version does not exist, has been discontinued, or its field structure is inconsistent with the tiered input status, the tiered result generation unit does not use the tiered configuration. In one implementation, the most recent tiered configuration version that is still valid is queried according to the settlement timestamp. In another implementation, a configuration unavailable flag is generated, and a target tiered result without action is formed. When there is no action record corresponding to the target tiered result in the action mapping configuration, the action instruction generation unit generates a reach action instruction with an empty action type and a termination processing method. When the delivery channel is in a deactivated state, a reach action instruction of the silent task type is generated according to the degradation method in the action mapping configuration.

[0156] In a self-service checkout scenario, the layered input status generated by S200 includes corrected transaction count 5, corrected average amount 191.30 yuan, category status C2, and settlement period status T2. The layered result generation unit matches the above fields with multiple layered conditions in the layered configuration version R18 to generate candidate layered result L2 and candidate layered result L4. L2 has a higher priority than L4, and the two belong to the same mutually exclusive group. The layered result generation unit writes L2 as the target layered result. The action instruction generation unit queries the action mapping configuration version A09 to obtain the action record with the action type being front-end prompt data, the delivery channel being the payment completion interaction page, the validity period being 30 seconds, and the degradation method being a silent task. The settlement timestamp is 14:32:10, and the generated delivery deadline is 14:32:40.

[0157] This step outputs the target stratification result and the outreach action instruction. The target stratification result includes the target stratification tag, stratification configuration version, candidate stratification result identifier, and adopted priority. The outreach action instruction includes the action type, delivery channel, action priority, delivery deadline, degradation method, and action mapping configuration version. S400 receives the outreach action instruction and invokes the action type, bill identifier, member association identifier, POS terminal identifier, delivery deadline, and degradation method. The stratification configuration version and action mapping configuration version are written together with the status version when S400 generates the outreach audit record.

[0158] S400: Generate an action idempotent key based on the bill identifier, member association identifier, and action type; based on the action idempotent key and the POS terminal reach count, compare the current time with the delivery deadline to generate a delivery control result, and perform front-end delivery, silent degradation, repetition suppression, or termination processing; associate the delivery control result with the status version to generate a reach audit record, and update the member window status and status version when the event processing status is not completed.

[0159] This step is executed by the delivery control unit and the status write-back unit. The delivery control unit receives the target hierarchical result and outreach action instruction generated in S300, and obtains the event identifier, bill identifier, member association identifier, POS terminal identifier, and event processing status generated in S100. It also obtains the current bill characteristics, current bill transaction increment, and status version retained in S200. The status write-back unit accesses the outreach audit record storage area, member window status storage area, terminal outreach count storage area, and event record storage area. This step starts after the outreach action instruction is generated. If the action type is empty or the event processing status has already been written as completed, the delivery control unit does not enter the normal front-end delivery branch.

[0160] When a member association identifier exists, the delivery control unit uses the member association identifier as the normalized member key; when the member association identifier does not exist, the bill identifier is used as the normalized member key. The normalized member key is a technical feature that selects either the member association identifier or the bill identifier as a unified index based on the existence of the member association identifier. The delivery control unit generates an action idempotent key according to a fixed join order of bill identifier, normalized member key, action type, and action mapping configuration version. In one embodiment, a summary calculation is performed on the fixed join result, and the resulting string is used as the action idempotent key; in another embodiment, a composite index composed of multiple fields is directly used as the action idempotent key.

[0161] The delivery control unit queries the reach audit record storage area based on the action idempotent key. If a reach audit record with a successful delivery status is found, a delivery control result for duplicate suppression is generated, and the target hierarchical result, action mapping configuration version, and actual delivery status are read from the existing reach audit record; this branch does not execute the foreground delivery, rights write request, or print action again. If a reach audit record with a failed delivery status is found, the delivery control unit reads the status field indicating whether re-delivery is allowed based on the action type and degradation method in the reach action instruction; if re-delivery is allowed, time comparison and circuit breaker verification continue; if re-delivery is not allowed, a delivery control result for termination processing is generated. If no reach audit record with the same action idempotent key is found, a reach audit record with a pending delivery status is created.

[0162] The POS terminal reach count is the number of successful front-end deliveries bound to the POS terminal identifier and a preset count window. The delivery control unit obtains the start and end points of the current preset count window and the POS terminal reach count based on the POS terminal identifier, and compares the POS terminal reach count with a terminal reach count threshold. In one embodiment, the preset count window is a calendar day; in another embodiment, the preset count window is a rolling time range before the settlement timestamp; in yet another embodiment, the preset count window is a preset number of settlement bills continuously completed by the same POS terminal. Rights write requests and silent tasks are not included in the POS terminal reach count corresponding to the payment completion interaction page; after the front-end notification data is actually successfully delivered, the POS terminal reach count is incremented by 1.

[0163] The delivery control unit reads the current time and compares it with the delivery deadline in the reach action instruction. If the current time does not exceed the delivery deadline, the POS terminal reach count is below the terminal reach count threshold, and no successful delivery audit record is found, a delivery control result allowing front-end delivery is generated. If the current time exceeds the delivery deadline, an event timeout delivery control result is generated. If the POS terminal reach count reaches the terminal reach count threshold, a terminal circuit breaker delivery control result is generated. If the corresponding successful delivery record for the action idempotent key already exists, a duplicate suppression delivery control result is generated. The delivery control result contains the control result type, action type, delivery channel, delivery deadline, terminal reach count, terminal reach count threshold, and action idempotent key.

[0164] For delivery control results that allow front-end delivery, the delivery control unit sends front-end prompt data to the POS terminal according to the delivery channel in the reach action instruction. The front-end prompt data includes the bill identifier, action type, prompt content identifier, delivery deadline, and page display status. After receiving the front-end prompt data, the POS terminal loads a non-blocking interactive area in the payment completion interaction page corresponding to the bill identifier. The display status of the non-blocking interactive area is not written into the payment status field and is not a prerequisite for the bill completion status. When the POS terminal returns to a page loading success status, the delivery control unit updates the actual delivery status to delivery success and increments the POS terminal reach count. When the returned page is closed, the page identifier does not match, or the loading failed status, the process is either silently downgraded or terminated according to the downgrade method.

[0165] When the action type is a benefit write request, the delivery control unit encapsulates the member association identifier, bill identifier, action type, action mapping configuration version, and benefit content identifier into a benefit write request and sends it to the write interface corresponding to the member account or card package. When the write interface returns a success status, the actual delivery status is updated to delivery success; when it returns a failure status, a silent task is generated or a delivery failure status is written according to the degradation method. When the action type is print data, the delivery control unit sends the bill identifier, action content identifier, and print status to the receipt printing component; after the printing component returns a completion status, the actual delivery status is written. Each action type uses its own action idempotent key to record the delivery status.

[0166] For delivery control results of terminal circuit breaker failure or event timeout, the delivery control unit reads the degradation mode from the reach action instruction. When the degradation mode is a silent task, a silent task is generated including an event identifier, bill identifier, normalized member key, action type, action mapping configuration version, generation time, and task status, and written to the task storage area; the silent task does not send front-end prompt data to the current payment completion interaction page. When the degradation mode is termination processing, the actual delivery status is written as undelivered, and the termination reason is written in the reach audit record. If the current time exceeds the delivery deadline, the original front-end prompt data is not resent to the payment completion interaction page.

[0167] For settlement billing events resulting from compensation reinvestment, the delivery control unit still uses the original settlement timestamp to calculate the delivery deadline, and does not replace the settlement timestamp with the compensation reinvestment time. When compensation reinvestment occurs, if the current time has not exceeded the delivery deadline and other delivery conditions are met, delivery is executed according to the touch action instruction; if the current time has exceeded the delivery deadline, a silent task is generated in a downgraded manner or termination processing is executed. Therefore, the effective time of the compensation reinvestment record and the current payment completion interaction page are compared using the same delivery deadline.

[0168] The status write-back unit associates event identifiers, bill identifiers, member association identifiers, POS terminal identifiers, current bill characteristics, status version, target hierarchical result, hierarchical configuration version, reach action instruction, action mapping configuration version, action idempotent key, delivery control result, and actual delivery status to generate a reach audit record. The reach audit record may also include the failure reason, silent task identifier, foreground page return status, and recording time; the current bill characteristics can be written using field values ​​or data digests. The status version in the reach audit record is the status version synchronously obtained when S200 obtains the member window status snapshot; the updated status version is added to the reach audit record after the member window status is written.

[0169] Before updating the member window status, the status write-back unit reads the event processing status from the event record storage area. If the event processing status is "processed complete," the status write-back unit does not update the member window status, status version, or POS terminal reach count, and returns the existing reach audit record. If the event processing status is not "processed complete," the status write-back unit reads the currently saved status version of the member window status and compares it with the status version obtained by S200. If the comparison matches, the current bill transaction increment retained by S200 is written to the member window status, and the status version is updated to the next version. If the comparison does not match, a new member window status snapshot is acquired, the current bill transaction increment is overlaid onto the newly acquired member window status snapshot, the hierarchical input status is updated, and the new status version is written to the member window status.

[0170] In one implementation, when the state version comparison is inconsistent, only the member window state and the hierarchical input state in the reach audit record are updated according to the current bill transaction increment, without re-executing the completed front-end delivery; in another implementation, when the actual delivery state has not yet entered the delivery success state, the updated hierarchical input state is returned to S300, the hierarchical configuration is re-matched, and a reach action instruction is generated. In the latter implementation, the pending delivery record corresponding to the original action idempotent key is updated to the terminated state, and the new reach action instruction generates a new action idempotent key according to the new action mapping configuration version.

[0171] For refund, cancellation, and reversal transactions, the status write-back unit queries the reach audit record and member window status update record corresponding to the original settlement bill based on the original bill identifier. When the current bill transaction increment corresponding to the original settlement bill has been written to the member window status, the status write-back unit writes the reverse transaction increment formed by S200 and updates the status version. When the silent task corresponding to the original settlement bill is still in the pending execution state, the task status of the silent task is updated to terminated. When the original action has been successfully delivered, the corresponding rights status update record is generated according to the refund processing record in the action mapping configuration. Test transactions do not update the member window status and POS terminal reach count; they only generate reach audit records marked as test transactions.

[0172] In a normal delivery scenario, no successful delivery record was found when the action idempotent key was used. The reach count of the POS terminal T03 within the current preset counting window is 12, the terminal reach count threshold is 20, the current time is 14:32:18, and the delivery deadline is 14:32:40. The delivery control unit generates a delivery control result that allows front-end delivery and sends front-end prompt data to the payment completion interaction page. After the POS terminal returns a successful loading status, the actual delivery status is updated to successful delivery, and the terminal reach count is updated to 13. The status write-back unit generates a reach audit record, writes the current bill transaction increment into the member window status, and updates the status version from V12 to V13.

[0173] In a recurring event scenario, the same bill event arrives again due to compensation re-delivery. The delivery control unit generates the same idempotent key for the same action based on the same bill identifier, normalized member key, action type, and action mapping configuration version. After querying the reach audit record with the actual delivery status as successful, it generates a delivery control result for repetition suppression. Since the event processing status is already completed, the status write-back unit does not repeatedly send front-end prompt data, update the member window status repeatedly, update the status version repeatedly, or increase the POS terminal reach count.

[0174] In a late event scenario, the billing event is resubmitted 60 seconds after the settlement timestamp due to a store server interruption, and the validity period in the reach action instruction is 30 seconds. The delivery control unit compares the current time with the delivery deadline and generates a delivery control result for the event timeout. When the degradation method is a silent task, the delivery control unit generates a silent task and writes it to the task storage area, without sending front-end prompt data to the original payment completion interaction page. The status write-back unit writes the event timeout, silent task identifier, and actual delivery status to the reach audit record, and updates the member window status and status version if the event processing status is not completed.

[0175] In a terminal circuit breaker scenario, the POS terminal reach count reaches the terminal reach count threshold, but the current time has not exceeded the delivery deadline. The delivery control unit generates a terminal circuit breaker delivery control result and generates a silent task corresponding to the rights write request according to the degradation method. The silent task enters the task storage area, and the current payment completion interaction page does not load the front-end prompt data. The front-end action is not successfully delivered, and the POS terminal reach count remains at its original value. The status write-back unit writes the terminal circuit breaker status and the silent task identifier into the reach audit record.

[0176] This step ultimately generates the delivery control result, actual delivery status, reach audit record, updated member window status, updated status version, updated POS terminal reach count, and updated event handling status. The updated member window status is read by the window status processing unit as a new member window status snapshot when the next billing event enters S200; the updated status version participates in the next status version comparison; the action idempotency key and actual delivery status in the reach audit record are used for subsequent recurring event queries; the event handling status is updated to indicate that after processing, subsequent arrivals of the same event will not repeat the member window status update and front-end delivery.

[0177] In one specific embodiment, in S400, an action idempotent key is generated based on the bill identifier, member association identifier, and action type; based on the action idempotent key and the POS terminal reach count, the current time is compared with the delivery deadline to generate a delivery control result, and front-end delivery, silent degradation, repetition suppression, or termination processing is executed; the delivery control result and the status version are associated to generate a reach audit record, and the member window status and status version are updated when the event processing status is not completed.

[0178] This step is executed by the delivery control unit and the status write-back unit. The delivery control unit receives the target hierarchical result and reach action instruction formed in S300, and obtains the event identifier, bill identifier, member association identifier, cashier terminal identifier, and event processing status formed in S100, while also obtaining the current bill characteristics, current bill transaction increment, and status version retained in S200. The status write-back unit accesses the reach audit record storage area, member window status storage area, terminal reach count storage area, and event record storage area. This step is initiated after the reach action instruction is generated. When the member association identifier exists, the delivery control unit uses the member association identifier as the normalized member key; when the member association identifier does not exist, the bill identifier is used as the normalized member key. The delivery control unit generates the action idempotent key according to a fixed connection order of bill identifier, normalized member key, action type, and action mapping configuration version. To solve the problem of how to combine the above multiple fields into a unique and reproducible idempotent identifier, formula ⑦ is introduced. This formula connects the four fields in a fixed order and performs a summary calculation to obtain the action idempotent key:

[0179]

[0180] in, Action idempotent key, used to uniquely identify an instance of a specific action;

[0181] Digest functions (such as SHA-256) map an input string to a fixed-length output string;

[0182] : Bill identifier, taken from the bill identifier field in the S100 settlement bill event;

[0183] The string concatenation operator combines the strings on both sides into a new string in sequence.

[0184] Normalized member key: If the member association identifier exists, take the member association identifier; otherwise, take the bill identifier. This is taken from the normalization result of this step.

[0185] Action type, taken from the action type field in the reach action instruction generated by S300 (such as "front-end prompt data", "rights write request", "print data").

[0186] : Action mapping configuration version, taken from the action mapping configuration version in the touch action command generated by S300.

[0187] Data source mapping: Extract the bill identifier from the S100 billing event. ; This is obtained from the normalization logic in this step. The action type is extracted from the S300's touch action command. Action mapping configuration version Connect the four components and input them into the summary function. .

[0188] Formula ⑦ output This serves as the primary key for subsequent queries to access the audit record storage area. The delivery control unit uses the aforementioned action idempotent key. The query reaches the audit record storage area to obtain the actual delivery status. To address the issue of how to quickly determine whether an action has taken effect when duplicate events or actions exist, formula ⑧ is introduced. This function returns a duplicate suppression flag based on the query results:

[0189]

[0190] in, : Repetition suppression flag, with a value of 0 or 1. 1 indicates that the idempotent key for the same action has been successfully delivered;

[0191] : Indicator function that returns 1 if the condition in parentheses is true, otherwise returns 0;

[0192] Existential quantifier, indicating that the audit record storage area has been reached. There is a record in it, named ;

[0193] : Access the audit record storage area and data source;

[0194] : Separator, read as "makes", used to separate existential quantifiers and conditional expressions;

[0195] :Record The action idempotent key field;

[0196] : The action idempotency key defined in formula ⑦;

[0197] Logical AND operator;

[0198] :Record The actual delivery status field in the data;

[0199] : A string constant indicating that the actual delivery status is successful.

[0200] Data source mapping: Based on the access audit record storage area... Index query, read the status field of the matching record.

[0201] Formula ⑧ It directly participates in the generation of subsequent delivery control results. The output product of this section is the action idempotent key. and repetition suppression markers And the existing reach audit records found (if they exist). and The second part of this step (Formulas 9 and 10) is used as input to comprehensively determine the delivery control results.

[0202] Following the action idempotency key obtained from formula ⑦ above The repetition suppression flag obtained from Formula ⑧ The delivery control unit simultaneously acquires the POS terminal reach count and the current time, and compares them with the delivery deadline. The POS terminal reach count is the number of successful front-end deliveries bound to the POS terminal identifier and a preset counting window. To address how to quantify the terminal tripping condition and the event timeout condition, formula ⑨ is introduced, which calculates the terminal tripping flag and the event timeout flag respectively:

[0203]

[0204] in, Terminal circuit breaker flag, with a value of 0 or 1. 1 indicates that the number of times the POS terminal has been reached or exceeded the threshold.

[0205] Indicator functions;

[0206] The POS terminal reach count is determined by the delivery control unit, which reads the number of successful front-end deliveries within the current preset count window from the terminal reach count storage area based on the POS terminal identifier.

[0207] The terminal reach counting threshold is preset by the system configuration;

[0208] Event timeout flag, with a value of 0 or 1, where 1 indicates that the current time has exceeded the delivery deadline;

[0209] The current time is obtained by reading the system clock from the delivery control unit;

[0210] : Delivery deadline, taken from the delivery deadline in the reach action instruction generated by S300.

[0211] Data source mapping: Read from the POS terminal identifier by accessing the count storage area via the terminal. Read by system configuration Obtained from the system clock Extracted from the S300's touch action command. .

[0212] Formula 9 outputs two flags and , and the output of formula ⑧ These together constitute three independent decision conditions. To address how to combine these three conditions into a unique delivery control outcome type, formula ⑩ is introduced. This formula uses priority decision logic (similar to priority encoding in a finite state machine) to generate the final control outcome:

[0213]

[0214] in, : Delivery control result type, with values ​​being an enumerated string, including "Duplicate Suppression", "Event Timeout", "Terminal Circuit Breaker", and "Allow Foreground Delivery";

[0215] : A string constant indicating that duplicate deliveries are suppressed because the action has already taken effect;

[0216] : A string constant indicating that the timeout occurred due to exceeding the delivery deadline;

[0217] : A string constant indicating that the circuit breaker is triggered because the number of touches to the POS terminal has reached the threshold;

[0218] : A string constant indicating that foreground delivery is allowed;

[0219] : The keyword for conditional branching, which introduces the first condition;

[0220] : The same repeat suppression flag defined in Formula ⑧;

[0221] : Keyword for conditional branching, guiding subsequent conditions;

[0222] : Same as the event timeout flag defined in formula ⑨;

[0223] The terminal circuit breaker flag is defined in formula ⑨.

[0224] : Default branch keyword, indicating that execution will only proceed if none of the above conditions are met.

[0225] Data source mapping: Directly use formula ⑧ Formula 9 and .

[0226] Formula 10 output As the core type of delivery control outcome, the delivery control unit then controls the outcome type, action type, delivery channel, delivery deadline, terminal reach count, terminal reach count threshold, and action idempotency key. Write the delivery control result data structure. For The delivery control unit sends front-end prompt data to the POS terminal according to the delivery channel in the touch action instruction; after the POS terminal loads the non-blocking interactive area on the payment completion page and returns to the loading success status, the delivery control unit updates the actual delivery status to delivery success and increments the POS terminal touch count (i.e., ...). ).for or The delivery control unit reads the degradation mode from the trigger action command. If the degradation mode is a silent task, a silent task is generated and written to the task storage area; if the degradation mode is termination processing, the actual delivery status is written as undelivered. No delivery action is performed.

[0227] The output of this section is the delivery control result. And based on the actual delivery status obtained after its execution (denoted as...) The values ​​are "delivery successful", "delivery failed", "not delivered", "silent task generated", etc., and the updated POS terminal reach count (incremented if a delivery was successful). The above outputs are used by the status write-back unit in the third part of this step (Formulas 11 and 12).

[0228] Following the action idempotency key obtained from the first part above The delivery control results obtained in Part Two and actual delivery status The status write-back unit needs to generate an access audit log and update the member window status while the event processing status is incomplete. To address how to ensure that updates to the member window status do not lose modifications from other transactions in a concurrent environment, formula ⑪ is introduced. This formula describes the conditional update rules based on the status version (optimistic locking mechanism):

[0229]

[0230] in, : A boolean flag indicating whether to allow updating the member window status, with a value of 0 or 1;

[0231] Indicator functions;

[0232] The current status version stored in the member window status storage area is retrieved by the status write-back unit before the update.

[0233] The state version obtained synchronously when S200 acquires a snapshot of the member window's state is retained in the event handling context;

[0234] Logical AND operator;

[0235] : Event handling status, with values ​​being an enumerated string (such as "processing completed", "pending processing", etc.), taken from the record corresponding to the current bill event in the event record storage area;

[0236] : A string constant indicating that the event handling status is complete.

[0237] Data source mapping: Read from the member window state storage area Read from the event handling context Read from the event log storage area .

[0238] Simple numerical example: Let , , ,but ;like and Inconsistent, or ,but .when At that time, the status write-back unit will retain the current billing transaction increments (including those retained by S200) Write the member window status and update the status version to the next version (e.g.) ).

[0239] when and When a version conflict occurs, the status write-back unit re-acquires the member window status snapshot, re-overlays the current bill transaction increment, and writes the member window status based on the re-acquired status version (without re-executing completed delivery actions). For refund, cancellation, and reversal transactions, it is necessary to handle reverse transaction increments, introducing formula ⑫, which expresses the reverse increment as a negative update vector:

[0240]

[0241] in, The reverse transaction incremental triplet is used to reverse the impact of the original bill on the member window status and contains three components.

[0242] : Symbol for constructing ordered triples;

[0243] The transaction count increment of the original bill is taken from the window status update record of the original settlement bill retrieved by S200 based on the original bill identifier;

[0244] The net amount increment of the original bill is taken from the net amount field of the original settlement bill.

[0245] The category count increment vector of the original invoice is taken from the original invoice and calculated using formula ③ of S200. .

[0246] Data source mapping: The member window status storage area is queried from the original bill identifier or the audit record is accessed to obtain... , , When the value is negative, it forms a reverse increment.

[0247] Simple numerical example: Let's say the original bill , Yuan, Then the reverse increment .

[0248] The status write-back unit will This is overlaid on the member window status to achieve status rollback. For test transactions, the member window status and POS terminal reach count are not updated; only a reach audit record marked as a test transaction is generated.

[0249] The status write-back unit will include event identifier, bill identifier, member association identifier, POS terminal identifier, current bill characteristics, status version, target hierarchical result, hierarchical configuration version, reach action instruction, action mapping configuration version, and action idempotency key. Delivery control results Actual delivery status The failure reason, silent task identifier, and other related information are written to the access audit record storage area. At the same time, the status write-back unit updates the event processing status in the event record storage area to "processing completed".

[0250] The final output of this step is: Delivery Control Results. Actual delivery status The system includes: access audit records, updated member window status, updated status version, updated POS terminal access count, and updated event processing status. The updated member window status is read by the window status processing unit as a new member window status snapshot when the next billing event enters S200; the updated status version participates in the next status version comparison; the action idempotency key and actual delivery status in the access audit records are used for subsequent recurring event queries; the event processing status is updated to indicate that after processing is complete, subsequent arrivals of the same event will not repeat the member window status update and front-end delivery.

[0251] This technical effect is achieved by using action idempotency keys and repetition suppression flags to implement one-time action-level control; using terminal circuit breaker flags and event timeout flags to limit the front-end delivery frequency and page timeout window of shared POS devices; and using state version condition update rules to ensure eventual consistency of member window state in a concurrent environment. A reverse incremental mechanism allows abnormal transactions to correctly roll back the stacked state. Compared to existing technologies, this step integrates idempotency, circuit breaking, timeout, and optimistic locking into the same delivery control chain, and the judgment conditions are combined according to a fixed priority, avoiding the problem that scattered deduplication and rate limiting measures cannot handle the conflict between asynchronous compensation re-delivery and page timeout.

[0252] Example 2: Figure 2 This diagram illustrates a structural block diagram of a supermarket membership tiered marketing triggering method based on cashier bill data, according to an embodiment of the present invention. Figure 2 As shown, the structure may include:

[0253] Settlement event generation module 01 is used to obtain settlement invoices with successful payments, associate the settlement invoices and pending event records in the same settlement transaction by invoice identifier, and asynchronously dispatch settlement invoice events including invoice identifier, member association identifier, cashier terminal identifier, current invoice product data, and settlement timestamp after the settlement transaction is submitted. Specifically, the settlement event generation module receives settlement invoices with a payment status of successful payment, reads the invoice identifier, member association identifier, cashier terminal identifier, current invoice product data, and settlement timestamp from the settlement invoice, and writes the settlement invoice and the pending event record in the same settlement transaction using the invoice identifier as the association field. The event log includes an event identifier, a bill identifier, an event processing status, a retry count, and a data summary of the current bill's product data. After the same settlement transaction is submitted, the settlement event generation module updates the event processing status from pending dispatch to dispatched and encapsulates it to form the settlement bill event. When asynchronous dispatch fails, the event processing status is updated to processing failure, and compensation re-dispatch is performed based on the event processing status and the retry count. The settlement event generation module provides the settlement bill event to the bill feature generation module, with the current bill's product data and the settlement timestamp serving as inputs for generating the current bill feature, and the member association identifier serving as input for querying the member window status snapshot.

[0254] The bill feature generation module 02, connected to the settlement event generation module, is used to generate current bill features by performing a single traversal of the current bill product data based on the settlement bill event. Specifically, the bill feature generation module receives the settlement bill event output by the settlement event generation module, reads the product code, category code, product quantity, product amount, and discount data from the current bill product data; performs a single traversal according to the recording order of product items, accumulates the number of product items and net amount during the same traversal, and writes the category code into the product category code set; matches the net amount with the corresponding amount range to generate a net amount status; and generates a status based on the product category. The code set is matched with the category conditions in the hierarchical configuration to generate a category status; the settlement time period status is generated by matching the settlement timestamp with the corresponding time period range; the number of product items, the net amount status, the category status, and the settlement time period status are written into the current bill feature; when the current bill product data is empty or the product amount and the discount data cannot form a net amount, the event handling status is updated to processing failure, and the output of the current bill feature to subsequent modules is stopped; the bill feature forming module provides the current bill feature to the window status processing module, and simultaneously provides the member association identifier and the settlement timestamp.

[0255] The window state processing module 03, connected to the bill feature forming module, is used to obtain a member window state snapshot and state version based on the member association identifier, and to overlay the current bill transaction increment onto the member window state snapshot to generate a layered input state. Specifically, the window state processing module receives the current bill features output by the bill feature forming module, and reads the number of transactions, cumulative amount, average amount, recent transaction time, category cumulative status, and state version within a preset transaction window based on the member association identifier to form the member window state snapshot. The current bill transaction increment includes the transaction number increment, net amount increment, settlement timestamp, and category status increment. The transaction number increment is overlaid onto the transaction number, and the net amount increment is overlaid onto the... The cumulative amount is calculated, and a corrected average amount is generated based on the superimposed transaction count and cumulative amount. The settlement timestamp is written as the corrected most recent transaction time. The category status increment and the category cumulative status are merged according to the category code to generate a corrected category cumulative status. The corrected transaction count, corrected cumulative amount, corrected average amount, corrected most recent transaction time, corrected category cumulative status, current bill characteristics, and status version are written into the hierarchical input status. When the member window status snapshot does not exist, an initial member window status snapshot is formed with the transaction count and cumulative amount value being zero. The window status processing module provides the hierarchical input status to the hierarchical result generation module and retains the current bill transaction increment and the status version for the status write-back module to call.

[0256] The layered result generation module 04, connected to the window state processing module, is used to match the layered input state with the layered configuration to generate a target layered result. Specifically, the layered result generation module receives the layered input state output by the window state processing module, reads multiple layered conditions, priorities, mutual exclusion relationships, and layered configuration versions in the layered configuration, and matches the net amount status, category status, settlement period status, corrected transaction count, corrected average amount, corrected recent transaction time, and corrected category cumulative status in the layered input state with the corresponding layered conditions. When the layered conditions match, a candidate layered result including candidate layered tags, priorities, mutual exclusion relationships, and layered configuration versions is generated. When multiple candidate layered results are formed, the candidate layered results corresponding to the same mutual exclusion relationship are filtered according to the priorities, and the candidate layered result with the highest priority is written as the target layered result. When no candidate layered result is formed, the target layered result is generated according to the default layered conditions in the layered configuration, or a target layered result that does not correspond to the action type is generated. The layered result generation module provides the target layered result and the layered configuration version to the action instruction generation module, and the target layered result serves as the query condition for the action mapping configuration.

[0257] Action instruction generation module 05, connected to the hierarchical result generation module, is used to query action mapping configurations based on the target hierarchical result and generate outreach action instructions including action type, delivery deadline, and degradation method. Specifically, the action instruction generation module receives the target hierarchical result output by the hierarchical result generation module and queries action mapping configurations including action type, delivery channel, action priority, validity period, degradation method, and action mapping configuration version based on the target hierarchical result. When multiple action mapping configurations corresponding to the target hierarchical result exist, the action mapping configurations are filtered according to the action priority. The settlement timestamp in the settlement bill event is read, and the settlement timestamp is compared with the validity period. The following parameters are added together to generate the delivery deadline: the action type, delivery channel, action priority, delivery deadline, degradation method, and action mapping configuration version are written into the outreach action instruction, and the bill identifier, member association identifier, and POS terminal identifier are associated with the outreach action instruction; if no action mapping configuration corresponding to the target hierarchical result is found, the degradation method is written as termination processing, and a corresponding outreach action instruction is generated; the action instruction generation module provides the outreach action instruction to the delivery control module, the action type participates in action idempotency key generation, the delivery deadline participates in time comparison, and the degradation method participates in silent degradation or termination processing.

[0258] Delivery control module 06, connected to the action instruction generation module, is used to generate an action idempotent key based on the bill identifier, the member association identifier, and the action type. Based on the action idempotent key and the POS terminal reach count, it compares the current time with the delivery deadline to generate a delivery control result, and performs front-end delivery, silent degradation, repetition suppression, or termination processing according to the delivery control result. Specifically, the delivery control module receives the reach action instruction output by the action instruction generation module and reads the bill identifier, the member association identifier, the POS terminal identifier, the action type, the delivery deadline, the degradation method, and the action mapping configuration version. When the member association identifier exists, it is used as the normalized member key; when the member association identifier does not exist, the bill identifier is used as the normalized member key. It generates an action idempotent key based on the bill identifier, the normalized member key, the action type, and the action mapping configuration version. The action idempotency key is used to query the reach audit record. When a reach audit record with a successful delivery status is found, a delivery control result for duplicate suppression is generated. If no reach audit record with a successful delivery status is found, the reach count of the POS terminal within a preset counting window is obtained, and the reach count is compared with a terminal reach count threshold, and the current time is compared with the delivery deadline. When the reach count is lower than the terminal reach count threshold and the current time has not exceeded the delivery deadline, a delivery control result for front-end delivery is generated. When the reach count reaches the terminal reach count threshold or the current time exceeds the delivery deadline, a delivery control result for silent degradation or termination processing is generated according to the degradation method. The delivery control module provides the delivery control result, the action idempotency key, and the actual delivery status to the status write-back module.

[0259] The status write-back module 07, connected to the delivery control module, is used to associate the delivery control result with the status version, generate a reach audit record, and update the member window status and the status version when the event processing status is incomplete. Specifically, the status write-back module receives the delivery control result, action idempotent key, and actual delivery status output by the delivery control module, and calls the event identifier, bill identifier, member association identifier, and cashier terminal identifier in the settlement bill event; calls the current bill feature generated by the bill feature formation module; calls the target layering result and layering configuration version generated by the layering result generation module; calls the reach action instruction and action mapping configuration version generated by the action instruction generation module; and calls the current bill transaction increment and status version retained by the window status processing module; associates and writes the event identifier, bill identifier, current bill feature, target layering result, reach action instruction, action idempotent key, delivery control result, actual delivery status, and status version into the reach audit record; and reads the event to be dispatched. The event processing status is recorded as follows: when the event processing status is completed, the member window status and status version are not updated; when the event processing status is incomplete, the currently saved status version is compared with the status version corresponding to the member window status snapshot; if the comparison matches, the member window status is updated based on the current bill transaction increment, and the status version is also updated; if the comparison does not match, the member window status snapshot is re-acquired, the current bill transaction increment is superimposed on the re-acquired member window status snapshot, and the member window status is updated according to the re-acquired status version; after the member window status is updated, the event processing status is updated to completed, and the updated member window status and status version are provided to the window status processing module as the member window status snapshot and status version corresponding to subsequent settlement bill events.

Claims

1. A method for triggering tiered marketing for supermarket members based on cashier bill data, characterized in that, include: S100: Obtain the settlement bill for successful payment, and associate the settlement bill with the pending event in the same settlement transaction according to the bill identifier; after the settlement transaction is submitted, asynchronously dispatch the settlement bill event including the bill identifier, member association identifier, cashier terminal identifier, current bill product data and settlement timestamp; S200. Perform a single traversal of the current bill's product data to generate the current bill's features; Obtain a snapshot of the member window status and status version, and overlay the current bill transaction increment onto the member window status snapshot to generate a layered input status. S300: Match the layered input state with the layered configuration to determine the target layered result; Based on the target hierarchical results, query the action mapping configuration and generate a reach action instruction including action type, delivery deadline, and degradation method; S400: Generate an action idempotent key based on the bill identifier, member association identifier, and action type; based on the action idempotent key and the POS terminal reach count, compare the current time with the delivery deadline to generate a delivery control result, and perform front-end delivery, silent degradation, repetition suppression, or termination processing; associate the delivery control result with the status version to generate a reach audit record, and update the member window status and status version when the event processing status is not completed.

2. The method according to claim 1, characterized in that, The pending event record and the settlement bill are written in the same settlement transaction; the pending event record includes an event identifier, a bill identifier, an event processing status, a number of retries, and a data summary of the current bill's product data; after the same settlement transaction is submitted, the event processing status is updated from pending to dispatched; after the asynchronous dispatch fails, the event processing status is updated to processing failed.

3. The method according to claim 2, characterized in that, Based on the event processing status, filter the pending event records that are either awaiting dispatch or have failed to process, and perform compensation re-dispatch based on the number of retries; the settlement bill event includes the transaction type and the original bill identifier; When the transaction type is a normal sale, refund transaction, cancellation transaction, reversal transaction, or test transaction, the corresponding event handling status is bound to it respectively; the refund transaction, the cancellation transaction, and the reversal transaction are associated with the original bill identifier.

4. The method according to claim 1, characterized in that, The single traversal This includes: sequentially reading the product code, category code, product quantity, product amount, and discount data from the current bill's product data; During the same traversal process, the number of product items and net amount are accumulated, and the category code is written into the product category code set; a net amount status is generated based on the net amount, a category status is generated based on the product category code set, and a settlement period status is generated based on the settlement timestamp; The number of product items, the net amount status, the category status, and the settlement period status are written into the current bill feature.

5. The method according to claim 4, characterized in that, The member window status snapshot includes the number of transactions, cumulative amount, average amount, most recent transaction time, cumulative category status, and status version within the preset transaction window; the current bill transaction increment includes the transaction number increment, net amount increment, settlement timestamp, and category status increment; The current bill transaction increment is overlaid onto the member window status snapshot to generate corrected transaction count, corrected cumulative amount, corrected average amount, corrected recent transaction time, and corrected cumulative category status, and the generated results are written to the hierarchical input status.

6. The method according to claim 5, characterized in that, When updating the member window status, the currently saved status version of the member window status is obtained, and the currently saved status version is compared with the status version corresponding to the member window status snapshot. If the comparison is consistent, the member window status is updated based on the current bill transaction increment and the status version is updated. If the comparison is inconsistent, the member window status snapshot is re-obtained, the current bill transaction increment is superimposed on the re-obtained member window status snapshot, and the hierarchical input status is updated.

7. The method according to claim 1, characterized in that, The hierarchical configuration includes multiple hierarchical conditions, priorities, mutual exclusion relationships, and hierarchical configuration versions; the hierarchical input state is matched with the multiple hierarchical conditions to generate multiple candidate hierarchical results; the target hierarchical result is determined from the multiple candidate hierarchical results according to the priorities and mutual exclusion relationships, and the hierarchical configuration version is bound to the target hierarchical result.

8. The method according to claim 7, characterized in that, The action mapping configuration includes action type, delivery channel, action priority, validity period, degradation method, and action mapping configuration version; the action mapping configuration is queried based on the target layering result to determine the action type, delivery channel, action priority, validity period, and degradation method; The settlement timestamp is added to the validity period to generate the delivery deadline; Write the action mapping configuration version into the touch action instruction.

9. The method according to claim 8, characterized in that, When the member association identifier exists, the member association identifier is used as the normalized member key; when the member association identifier does not exist, the bill identifier is used as the normalized member key. The action idempotency key is generated based on the bill identifier, the normalized member key, the action type, and the action mapping configuration version; the reach audit record is queried based on the action idempotency key; when a reach audit record with an actual delivery status of successful delivery is found, a delivery control result for duplicate suppression is generated.

10. The method according to claim 9, characterized in that, The system acquires the terminal reach count of the POS terminal within a preset counting window, compares the terminal reach count with a terminal reach count threshold, and compares the current time with the delivery deadline. When the terminal reach count is lower than the terminal reach count threshold and the current time has not exceeded the delivery deadline, the system executes the front-end delivery. When the terminal reach count reaches the terminal reach count threshold or the current time exceeds the delivery deadline, the system generates a silent task or performs termination processing according to the degradation method. When the event processing status is "processing complete," the system does not update the member window status, the status version, or the terminal reach count.

Images