A bar code scanning fault-tolerant recognition method and system based on a phased notification mechanism

Abstract

This invention discloses a barcode scanning fault-tolerant identification method and system based on a phased notification mechanism, applied to the WeChat Mini Program runtime environment. The barcode string obtained by scanning undergoes a progressive multi-layer format verification (pure number verification → length verification → country code matching → verification bit calculation), terminating if the previous layer fails. When verification fails, the module-level closure variable retry counter increments: if the maximum threshold is not reached, a progress indicator is displayed via `wx.showToast`, and after a preset delay, `wx.scanCode` is called again to initiate a new scanning operation; if the threshold is reached, a three-step phase switch driven by the UI layer alternation rules of the WeChat Mini Program API is executed: ① resetting the counter, ② `wx.hideToast()` actively closes any potentially still-displayed toasts to avoid rendering conflicts with `wx.showModal`, ③ a confirmation dialog box pops up for the user to choose between using the current result or rescanning. When verification passes or the user selects "use this result," a local product database query is executed, and the result is passed to the calling page via a callback function. This invention also discloses an independent implementation of dual-mode barcode scanning on the cashier page—manual scanning and continuous camera scanning modes employ differentiated "pause → resume" retry strategies. This invention resolves the UI-level conflict between the two system notification APIs in WeChat Mini Programs by mandating the sequential operation of `wx.hideToast()` → `wx.showModal()`, and ensures the correctness of the recursive retry state and the continuity of the retry state across short-lifecycle pages through a module-level closure counter.

Description

Technical Field

[0001] This invention relates to the field of barcode scanning and recognition technology in mobile applications, specifically to a method and system for achieving fault-tolerant recognition and user-friendly error recovery during barcode scanning in the WeChat mini-program operating environment through progressive multi-layer format verification, automatic retry driven by module-level counters, and a Toast to Modal stage switching mechanism. Background Technology

[0002] Barcode scanning presents unique technical challenges in retail checkout scenarios. In retail checkout scenarios, operators use barcode scanners or mobile phone cameras to scan product barcodes to quickly input product information. This scenario presents four core technical difficulties: (1) Unreliable barcode scanning results – inherent limitations of WeChat’s native barcode scanning interface. In actual use, when WeChat mini programs call the `wx.scanCode` system interface to scan barcodes, due to factors such as lighting conditions, camera focusing speed, barcode printing quality, operator hand tremors, and differences in equipment performance, the scanning results may result in character recognition errors (such as "6" being recognized as "8"), barcode truncation (scanning 12 digits instead of 13 digits), or recognition of non-barcode text. WeChat’s native barcode scanning interface `wx.scanCode` does not provide image preprocessing mechanisms (such as binarization, sharpening, and distortion correction), nor does it open access permissions to the underlying camera frames for custom preprocessing, resulting in limited ability to recognize low-contrast barcodes, blurry barcodes, and tilted barcodes. In the WeChat developer community, low barcode recognition accuracy is a common technical problem reported by developers, often attributed to "insufficient lighting, blurry images, damaged barcodes, and lack of custom image preprocessing mechanisms". If the system uses the scan results directly for database queries without performing any format validation, it will result in a large number of invalid queries with "product not found", disrupting the checkout process.

[0003] (2) UI-level conflicts in WeChat Mini Program APIs. In the fault-tolerant handling after barcode verification failure, developers usually need to display prompt information to users. WeChat Mini Programs provide two system-level user notification interfaces: `wx.showToast` (lightweight Toast, disappears automatically, does not block operations) and `wx.showModal` (modal dialog, requires the user to click a button to close). When multiple consecutive scan failures require "first prompting for retry progress, then popping up a confirmation dialog to ask the user if they want to continue", these two interfaces have a conflict in call sequence. If `wx.showModal` is called before the Toast prompt has disappeared automatically, the two may conflict with each other in the UI-level management of the WeChat Mini Program framework: the Toast may cover the Modal, making the button uninterrupted, or the pop-up of the Modal may trigger the Toast to close prematurely, resulting in the loss of progress information. Developers need to implement the correct order switching between the two interfaces—first actively hide the Toast, then pop up the Modal—and cannot simply nest the Modal in the Toast callback.

[0004] (3) State transfer exists between multiple scans. Fault-tolerant retries need to track "how many times is this being retried"—if the counter is stored as a local function variable, each recursive call to `scanBarcode` will generate a new function scope and a new local variable, making it impossible to correctly accumulate the number of times. A state persistence mechanism across recursive calls is needed.

[0005] (4) Industry standards for barcode verification and limitations of existing products. The EAN-13 product barcode follows the international standard ISO / IEC 15420 (equivalent to GB 12904-2008 in China), and its verification bit algorithm has a single-character error detection rate of about 90%. However, misidentification is still possible in actual retail POS applications. Existing retail POS apps (such as Sunmi and Yinbao) usually distribute the logic of format verification, retry control, and UI prompts in the barcode scanning callback functions of each page, resulting in three problems: ① Each page implements the verification and retry logic repeatedly, resulting in code redundancy; ② Each page may use inconsistent retry strategies (such as page A retrying 3 times, page B not retrying); ③ Developers need to manually handle the calling order of Toast and Modal, which is easy to miss the `wx.hideToast()` call and cause UI conflict bugs.

[0006] The key innovation of this invention lies in its approach: instead of simply "validating the format of the scanned results"—which is a conventional practice—it establishes a four-state fault-tolerance mechanism driven by the features of the WeChat Mini Program API, with deterministic state transition rules. Its core components include: mandatory sequential validation (pure numbers must be placed first to avoid NaN), mandatory switching between Toast and Modal (hideToast must precede showModal), and a user override mechanism that is only triggered after all retries have been exhausted. This combination of three points—rather than a single technical feature—constitutes the essence that distinguishes this invention from conventional QR code scanning fault-tolerance solutions. Summary of the Invention

[0007] This invention provides a method for handling barcode scanning errors in the WeChat Mini Program environment through three consecutive steps: progressive verification, automatic retry, and stage switching.

[0008] Step 1: Progressive Multi-Level Verification. The barcode string obtained from scanning is verified in the following order: "Pure Numeric → Length → Country Code → Check Digit". This order is technically necessary: ​​the calculation of the check digit (odd digits × 1 + even digits × 3 sum) assumes all characters are numeric. If the string contains non-numeric characters (such as "A"), then in JavaScript, the result of `"A" × 3` is `NaN` (non-numeric), rendering subsequent summation and modulo operations meaningless. Therefore, "pure numeric verification" must precede "check digit calculation".

[0009] Step Two: Automatic Retry Driven by a Module-Level Counter. When verification fails, the module-level closure variable `_retryCount` increments. If `_retryCount < 3`, "Incorrect format, retry (2 / 3)" is displayed via `wx.showToast`, and the barcode is automatically rescanned. Rescanning is achieved by recursively calling the `scanBarcode` function after `setTimeout(200ms)`. It should be noted that the retry mechanism of this invention is not the general "repeated verification of the same scan result" mode. Each retry involves calling the `wx.scanCode` system interface again to initiate a completely new scanning operation on the same physical barcode. This is because the root cause of the previous scan failure is usually not that the barcode itself is invalid, but that the camera has not finished focusing, the lighting conditions have changed instantaneously, or the barcode has not been fully captured. This is the technical reality revealed by the common understanding that the WeChat native scanning interface is inaccurate. Rescanning utilizes the differences in camera status at different times to improve the success rate of recognition, rather than repeatedly verifying the same poor data.

[0010] Step 3: Toast to Modal stage switching (core mechanism). When the retry counter reaches 3, three strictly sequential operations are executed: ① `_retryCount = 0` (reset the counter); ② `wx.hideToast()` (actively close any Toasts that may still be displayed); ③ `wx.showModal(...)` (pop up a confirmation dialog box).

[0011] Step ③ must be executed after step ②—rather than simply calling Modal directly in the Toast callback or in the timing sequence—because `wx.showToast` and `wx.showModal` share the same UI hierarchy management system in the WeChat Mini Program framework. If Modal is called directly before the 1.5-second display duration of the Toast has ended, a conflict may occur at the rendering level (the Toast overwrites the Modal, or the Modal rendering triggers the Toast to close abnormally, resulting in the user not seeing the complete information). The active call to `wx.hideToast()` ensures that the Toast has been completely removed from the view layer, and the Modal can exclusively occupy the UI hierarchy for normal rendering and receiving user interactions. This forced sequential switching is driven by the technical constraints unique to the WeChat Mini Program environment—in the SPA framework of the Web environment, Toast and Modal are usually managed by the same DOM tree and their hierarchy can be explicitly controlled through z-index, so there is no black-box hierarchy competition problem between native system APIs in WeChat Mini Programs.

[0012] The relationship between the three steps above is as follows: the verification output of step one determines whether step two triggers a retry; the number of retries in step two determines whether step three triggers a stage switch; the switching from `wx.hideToast()` to `wx.showModal()` in step three is a mandatory sequential operation driven by the UI layer alternation rules of the WeChat Mini Program API and cannot be omitted.

[0013] A non-obvious combination of four design dimensions. This invention addresses the barcode scanning error tolerance problem in WeChat Mini Program retail POS scenarios by making specific choices in four relatively independent design dimensions. The combination of these four dimensions is not a permutation that would naturally come to mind for someone skilled in the art when facing the barcode scanning error tolerance problem: Dimension 1 - Verification Order: A progressive verification sequence of "pure numbers → length → country code prefix → check digit" is chosen. Pure number verification must precede check digit calculation because each step of the check digit calculation (odd digits × 1 + even digits × 3 → sum → take the units digit → subtract the units digit from 10 → comparison) assumes that all characters involved in the calculation are valid decimal numbers. If the string contains non-numeric characters, in the weakly typed JavaScript language, arithmetic operations will produce a `NaN` value, rendering all subsequent calculations meaningless. This order is not an aesthetic choice but a mandatory requirement for arithmetic correctness.

[0014] Dimension Two - Storage Location of the Retry Counter: A module-level closure variable (`var _retryCount = 0`, defined in a file-level scope outside the function body) is chosen over a function-local or global variable. This is because retries are implemented by recursively calling `setTimeout`—each recursive call creates a new function execution context and a new local variable scope—if the counter were stored as a local variable, each recursion would see an independent initial value instead of an accumulated value; if a global variable were used, naming conflicts with variables from other modules might occur. Module-level closure variables achieve a unique balance between "sharing across recursive calls" and "scope isolation."

[0015] Furthermore, in multi-page scenarios of mini-programs, the selection of module-level closure variables also involves an additional consideration at the page lifecycle level: the barcode scanning and inventory entry page, the report page, the product list page, and the procurement and purchasing page are all short-lifecycle pages navigated through `wx.navigateTo`—after the user completes the operation and returns via `wx.navigateBack`, the page instance is destroyed. If the retry counter is stored as a page instance variable (`this._retryCount`) in the `this` object of the Page instance, each time the user leaves the barcode scanning page and re-enters, a completely new Page instance and a completely new initial value (0) for the counter will be created, resulting in the loss of continuity of the retry count across pages. However, module-level closure variables are stored in the file-level scope of the module—the `require` mechanism ensures that multiple imports of the same module return the same module closure space—ensuring that the counter remains continuous throughout the module's lifecycle regardless of how the page instance is destroyed and rebuilt. This is the underlying technical reason for the dual-track strategy of "using module variables for the unified solution and instance variables for the independent cashier solution": the cashier is a tabBar page in the WeChat mini program, which persists throughout the entire application session and is not destroyed - its Page instance lifecycle is equal to the application lifecycle - instance variables naturally have cross-operation persistence equivalent to module variables, so the simpler `this._scanRetryCount` solution can be adopted.

[0016] Dimension Three - Two-Phase Mapping of Notification Methods: Select "Retry < 3 times: Toast progress notification; Retry = 3 times: hideToast → showModal for user confirmation." This two-phase mapping is not a simple sequential arrangement of the two notification APIs—Toast is only responsible for progress notification (automatically disappears, non-blocking), while Modal is responsible for obtaining user decision (requiring user click). They serve two fundamentally different interaction purposes. When retries are less than 3, the system still attempts to recover autonomously, and the user only needs to be informed (Toast); when retries are exhausted, the system abandons autonomous recovery and transfers the decision-making power to the user (Modal).

[0017] Dimension Four - User Decision Branch: After retry exhaustion, Modal provides two exit options: "Use this result" and "Rescan." "Use this result" is the key design of this invention—it allows users to override the automatic verification system based on their personal judgment, bypassing all four layers of progressive verification and directly querying the product database with the unverified barcode string as is. The technical premise of this override mechanism is that "retry exhaustion" (not that override is possible at any time), which ensures that the system has exhausted all automatic recovery methods before entering the user's manual judgment stage.

[0018] The combination of the four dimensions mentioned above—"purely numerical mandatory pre-processing" in the verification order dimension, "module-level closure rather than local / global (including dual-track strategy argumentation at the page lifecycle level)" in the storage dimension, "two-stage mapping of Toast progress → Modal decision" in the notification dimension, and "allowing users to cruise only after retries are exhausted" in the decision dimension—is a set of design choices with inherent consistency in the specific scenario of WeChat Mini Program retail POS. While similar approaches can be found in the field for any single dimension (such as the use of module-level variables in other scenarios, or the combination of Toast + Modal in some UI libraries), the specific choice of these four dimensions in the specific problem of "WeChat Mini Program retail POS QR code fault tolerance" is the essence that distinguishes this invention from conventional QR code processing solutions.

[0019] Dimension Five - Independent Implementation of Dual-Mode Scanning at the Cashier. This invention provides an independent parallel implementation scheme for the core, high-frequency operation page of the cashier, in addition to the unified entry function of the tool module. This scheme is designed based on the following system-level considerations that differ from those of the tool module: (a) Dual-mode scanning architecture: The checkout page simultaneously supports manual scanning (calling the `wx.scanCode` system interface) and continuous scanning via camera (using WeChat mini-program). <camera>The `bindscancode` frame callback of the component continuously captures data. The technical significance of continuous scanning mode is that when cashiers are processing payments for multiple customers in succession, they do not need to repeatedly trigger the scanning button—the camera remains on, and the recognition result of each frame is automatically passed to the processing logic by the frame callback, greatly reducing the number of operation steps.

[0020] (b) Differentiated Retry Strategy: In continuous scanning mode, the `setTimeout` → recursive `scanBarcode` solution from the utility module is not used for retries because this solution recursively calls `wx.scanCode` to reopen the system scanning interface—which interrupts the camera frame stream in continuous scanning scenarios. Instead, the solution is: set a scan cooldown flag (`_scanCooldown`) to lock subsequent frame callbacks → display a Toast progress indicator → clear the cooldown flag after `setTimeout` expires → simultaneously set a camera reset flag (`cameraReset`) to trigger the retry. <camera>`Component refresh frame capture. This "pause-resume" retry strategy achieves fault tolerance equivalent to the tool module while keeping the camera on, but avoids repeatedly opening the system's barcode scanning interface—offering significant advantages in user experience and operational efficiency in high-frequency, continuous operation scenarios at the checkout counter.`

[0021] The technical rationale for using a page instance variable (`this._scanRetryCount`) instead of a module-level closure variable in the cashier is as follows: The cashier page is a WeChat Mini Program tabBar page—unlike short-lived pages accessed via `wx.navigateTo`—tabBar pages persist throughout the entire application lifecycle and are not destroyed and recreated with page switching. The lifecycle of its Page instance is equal to the application session lifecycle; therefore, the persistence of the instance variable naturally satisfies the requirement for continuous counting across operation scenarios. In contrast, pages for scanning to enter inventory, reports, product lists, and purchasing are short-lived pages accessed via `wx.navigateTo`, and their instances are destroyed when the page is returned to the previous page. Therefore, it is necessary to rely on module-level variables to handle the destruction and reconstruction of page instances.

[0022] (c) Differentiated Failure Pop-up Solution: When the checkout page runs out of retries, it uses a custom modal dialog box (`retryFailModal`) from the WXML template instead of the `wx.showModal` system interface. The motivation for this choice is that the checkout page's ` <camera>The component is a native component of WeChat Mini Programs, occupying an independent rendering layer. The rendering layer of the `wx.showModal` system interface may cause UI layer conflicts with the rendering layer of the native camera component (the camera component may be blacked out or obscure the Modal button when the system Modal pops up); while the WXML custom dialog box is rendered within the page DOM tree, and its layer relationship with the camera component is explicitly controlled by the arrangement order of DOM nodes in the page WXML and `z-index`, avoiding black-box layer conflicts between the native layer of the system API and the DOM layer.

[0023] The `wx.showModal` solution in the tools module and the WXML custom pop-up solution on the cashier page constitute a dual-track strategy of "system API solution" and "DOM-level controllable solution"—the former is suitable for ordinary QR code scanning pages without full-screen native components, and the latter is suitable for pages with `wx.showModal`. <camera>The native component is used for the checkout page. Both solutions follow the same design principle in the core mechanism of "Toast → Notification Toggle" (first disable lightweight notifications, then display heavyweight notifications), but differentiate their implementation methods based on the page's UI environment. This dual-track strategy allows non-camera pages such as barcode scanning, reports, product lists, and purchasing to use a unified lightweight utility module solution (imported with a single line of code using `require`), while the checkout page can be independently optimized without affecting the simplicity of other pages—forming an overall architectural strategy of "general unification + core scenario specialization".

[0024] The beneficial effects of this invention are as follows: (1) Resolved the UI hierarchy conflict between Toast and Modal in WeChat Mini Programs. By forcibly calling `wx.hideToast()` before `wx.showModal`, it ensures that one notification mechanism completely exits before entering the other, avoiding competition and mutual interference between the two system APIs.

[0025] (2) Correctness of state in recursive retry and persistence across pages. The module-level closure counter ensures the correct transmission of state in the recursive call chain. If local variables are used, a new copy of the variable will be created each time the recursion is performed, and the counter cannot be accumulated. If page instance variables are used, the counter will be reset to zero each time a new instance is created for a short-lifetime page (the page to navigate to via To), and the continuity of retry in cross-page operations will be lost.

[0026] (3) The technical correctness of the verification order. The pure numeric verification first avoids the occurrence of `NaN` due to non-numeric characters participating in arithmetic operations, which would render the verification bit calculation meaningless.

[0027] (4) User experience optimization for continuous scanning scenarios at the cashier. By using a dual-mode scanning architecture and a differentiated "pause → resume" retry strategy, the system avoids interruptions caused by repeatedly opening the system scanning interface in continuous scanning mode while maintaining fault tolerance equivalent to that of the tool module.

[0028] (5) Fidelity of the original data in the user bypass mechanism. When a user bypasses all checks, the barcode string is not modified, truncated or converted in any way, and is entered into the database in its original form to ensure that the query key is consistent with what the user sees. Attached Figure Description

[0029] Figure 1 This is the overall flowchart of the progressive verification → automatic retry → stage switching of the present invention. The bottom of the diagram contains the mapping relationship between the three states (verification / retry / notification) and the four steps (S1 to S4), corresponding to steps S1 to S4 of claim 1.

[0030] Figure 2 This is a sequence diagram of the phase switching mechanism from Toast to HideToast to Modal.

[0031] Figure 3 This is a system module architecture diagram of the present invention (including independent implementation of dual-mode cash register + dual-track strategy annotation + shared layer interaction relationship). Detailed Implementation

[0032] Example 1: Progressive Multi-Level Format Validation Based on barcodeValidator.js, validation is performed in a four-level progressive order: "pure number → length → country code → validation digit"—the process terminates and returns the reason for failure if the previous level fails. The validation logic for each level is as follows: First layer (pure numeric check): Checks if the barcode string consists entirely of numeric characters. This layer must be placed before the check digit calculation—if the string contains non-numeric characters, JavaScript arithmetic operations will produce `NaN`, rendering subsequent check digit calculations meaningless.

[0033] The second layer (length check): checks whether the length of the barcode string is equal to 13 digits.

[0034] The third layer (country code matching): Extract the first 3 digits of the barcode and compare them one by one with the preset table of 47 country / region code prefixes.

[0035] The fourth layer (EAN-13 check digit calculation): Perform a weighted summation on the first 12 digits (odd digits × 1, even digits × 3), take the units digit, subtract the units digit from 10, and compare the result with the last digit of the barcode.

[0036] If the verification passes, a success flag and matching country / region information are returned; if any level fails, a failure flag and corresponding failure reason description are returned.

[0037] Example 2: Automatic Retry and Stage Switching Driven by a Module-Level Counter (scanHelper.js) The core implementation based on scanHelper.js encapsulates the complete four-state machine described in claim 1, allowing the four pages—scanning for inventory, reports, product lists, and purchasing—to uniformly reference it with a single line of code: `require('. / utils / scanHelper').scanBarcode`. Internally, scanHelper.js imports the progressive multi-layered format validation module from embodiment 1 via `const bcValidator = require('. / barcodeValidator')`. Its core state transition skeleton is as follows: Module-level closure variable _retryCount = 0 scanBarcode(callback configuration): Call wx.scanCode() to initiate a QR code scan. After successfully scanning the code: Barcode string → bcValidator.validate() progressive validation ┌─ Verification passed────────────────────────────── │ _retryCount = 0 │ Local product database query → Callback configuration: .onFound / .onNotFound │ ├─ Validation failed ∧ _retryCount < 3 ───────────── │ _retryCount++ | wx.showToast("Retry progress notification") | setTimeout(200ms) → Recursive scanBarcode(callback configuration) │ └─ Validation failed ∧ _retryCount == 3 ───────────── _retryCount = 0 wx.hideToast() wx.showModal("Incorrect barcode format", "Use this result / Rescan") ├ If the user selects "Use this result" → Skip database validation. User selects "Rescan QR code" → Callback configuration: onCancel → Rescan QR code The core mechanism of the above framework is that step ② `wx.hideToast()` must be executed before step ③ `wx.showModal()`. If Modal is called directly during the 1500ms display period of Toast, the UI hierarchy management system of WeChat Mini Program may render the two as overlapping states (Modal is covered by Toast or Toast is abnormally closed by Modal), causing users to be unable to see the complete information or interact with it.

[0038] Furthermore, each recursive retry in state two is not a repeated verification of the same scan result—after `setTimeout` expires, the recursive call to `scanBarcode` will re-execute `wx.scanCode()` to initiate a completely new system scan operation. This design is based on the fact that the most likely reason for the previous scan failure is not that the barcode itself is invalid, but rather a single-scan quality issue caused by insufficient instantaneous lighting, camera focus delay, or the barcode not fully entering the viewfinder—the camera state varies at different times, and re-scanning can utilize this difference to improve the recognition success rate.

[0039] Example 3: Independent implementation of dual-mode barcode scanning at the cashier (cashier / index.js) The checkout page does not reference scanHelper.js, but instead implements an independent parallel solution that is compatible with the checkout's dual-mode scanning architecture: Manual scanning mode – initiates a single scan via the `wx.scanCode` system interface.

[0040] Continuous camera scanning mode – via WeChat mini program <camera>The component's `bindscancode` frame callback continuously captures the scanning results, keeping the camera on and preventing the system's scanning interface from being opened repeatedly.

[0041] Both modes undergo the same protection checks (scanLocked flag to prevent duplicate recognition, and _scanCooldown flag to control the retry interval). After a successful scan, a silent cloud backup (_trySilentBackup) is triggered, and then the barcode string is sent to the unified `handleBarcode` processing function.

[0042] Retry strategy for failed validation (differentiated implementation) – Employing a page instance-level counter `this._scanRetryCount` and a "pause → resume" cooling-off mechanism, its core logic is as follows: The page instance variable this._scanRetryCount handleBarcode(barcode string, scan mode): bcValidator.validate(barcode string) Progressive validation ┌─ Validation failed ∧ _scanRetryCount < 3 ────────── │ _scanRetryCount++ | _scanCooldown = true (locks the scanning channel) | wx.showToast("Retry progress notification") | setTimeout → _scanCooldown = false (unlock) │ ├ Manual Mode → Recall wx.scanCode │ └ Continuous Mode → cameraReset flag triggers camera frame refresh │ └─ Verification failed ∧ _scanRetryCount == 3 ────────── wx.hideToast() Displays a custom WXML pop-up window, retryFailModal (not wx.showModal). The user selects "Use this result" / "Rescan the code" In continuous scanning mode, the above retry strategy uses the `_scanCooldown` flag to lock subsequent frame callbacks → `setTimeout` to clear the flag → `cameraReset` to trigger the flag. <camera>The component refreshes frame capture and implements a "pause-resume" retry waiting mechanism. This mechanism achieves fault tolerance equivalent to the tool module while keeping the camera on, but avoids the operation interruption caused by recursively calling `wx.scanCode` to reopen the system's barcode scanning interface.

[0043] The technical rationale for using the instance variable `this._scanRetryCount` instead of a module-level closure variable on the cashier page is that the cashier is a tabBar page in the WeChat mini program, which persists throughout the entire application session and is not destroyed or recreated—the lifecycle of the Page instance is equal to the lifecycle of the application session, and the persistence of the instance variable naturally meets the retry counting requirements across operations.

[0044] On the checkout page, after each successful scan, the system triggers a silent cloud backup (`_trySilentBackup`), asynchronously uploading the current product data to the cloud backup server. This backup operation uses a fire-and-forget mode (no prompts or interruptions to the checkout process if it fails), and is doubly guaranteed not to be triggered again on the same day through session-level flags and date-level persistent markers. This mechanism creates an automated closed loop for the checkout's scan error tolerance process and data security.

[0045] Example 4: Rapid Filing Component and Heterogeneous Dual-Source Degradation Query This implementation is based on the quick-add custom component, which is encapsulated as a WeChat Mini Program Custom Component. It exposes only two properties, `show` and `barcode`, and outputs results via `triggerEvent`. The calling page only needs to set the properties and listen for the event; it doesn't need to understand the component's internal cloud query, validation, or file writing logic. The core framework is as follows: Component({ properties: { show: Boolean, barcode: String}, observers: { 'show, barcode'(show, barcode): / / Combined listener for two properties When show == true and barcode is not empty, _autoFill(barcode) is triggered. } }) _autoFill (barcode): First-level query ( / product / lookup, exact match for key-value pairs) → Hit: Automatically fill in name and price → No match: Degrade to Level 2 query (cloud barcode query interface, keyword search, heterogeneous data source) → Hit: Automatically fill in name and price → Missed: Leave blank for operators to fill in manually. After saving: Silent reporting (barcode + name → cloud shared database, fire-and-forget) The above implementation requires special attention to three technical features that distinguish it from general SaaS rapid profiling: (a) Data-driven triggering: The component's creation process is not initiated by the calling page explicitly calling a method of the component (such as `this.selectComponent('#quickAdd').lookup(barcode)`), but is triggered in a data-driven manner through property observers. The calling page only needs to execute the single line of data operation `this.setData({show: true, barcode: barcode})`, and the observer automatically detects the combined change of the two properties and initiates subsequent queries. This "data-driven rather than function-driven" triggering mode is unique to WeChat Mini Program Custom Components. In Web SPA frameworks, Vue's `watch` can only listen to changes in a single reactive property, and React's `useEffect` dependency array does not automatically detect the combined condition of "two independent properties becoming valid values ​​at the same time." Neither can achieve the exclusive combination judgment of "triggering only when show and barcode are both valid" without introducing additional scheduling logic.

[0046] (b) Heterogeneous Dual-Source Degradation Instead of Homogeneous Primary / Backup: The data sources for the two-level queries have fundamentally different data organization methods—the first level uses barcodes as exact matching keys (key-value queries) and targets a structured barcode product database; the second level uses keywords as fuzzy matching methods (search engine queries) and targets a third-party cloud-based barcode product database. This differs from the common homogeneous switching of "primary database → backup database" (in homogeneous switching, the two data sources use the same query strategy and the same schema, only the connection address is different)—in the heterogeneous degradation of this invention, the data organization paradigm of the second-level data source is fundamentally different from that of the first level. Degradation is not only URL redirection, but also a paradigm shift in query semantics.

[0047] (c) Silent reporting forms a cross-tenant self-enhancing data loop: After successful saving, the component silently pushes the newly created product information to the cloud-shared database—this request uses a fire-and-forget mode (no prompts or interruptions to the filing process upon failure). Its technical significance lies in the fact that in ordinary SaaS systems, product data for each merchant is strictly isolated (data filed by tenant A is not visible to tenant B), while the silent reporting of this invention breaks down tenant barriers—the filing results of any merchant are automatically converted into cloud data shared by all merchants. Mathematically, N merchants manually filing for the same product will be compressed into 1 filing + N-1 direct hit queries, forming a cross-tenant self-enhancing loop where "the more it's used, the more accurate the query."< / camera> < / camera> < / camera> < / camera> < / camera> < / camera>

Claims

1. A barcode scanning error-tolerant recognition method A barcode scanning error-tolerant recognition method, applied to the WeChat mini-program operating environment, is characterized by comprising: Step S1 (Progressive Verification): Perform progressive multi-level format verification on the barcode string obtained by scanning—in the order of pure number verification, length verification, country code prefix matching, and check digit calculation. If the previous layer of verification fails, the subsequent verification will terminate. If all layers pass, the verification is considered successful. Step S2 (Verification Failure → Automatic Retry): When the verification fails and the current value of the module-level closure variable retry counter is less than the preset maximum retry threshold, the counter is incremented, and a progress prompt containing the current retry count is displayed through the system Toast interface (`wx.showToast`). After a preset delay, the system scanning interface (`wx.scanCode`) is called again to initiate a new scanning operation. Step S3 (Retry Exhaustion → Stage Switching): When the counter reaches the maximum threshold after incrementing, the counter is first reset to zero, then the system Toast hiding interface (`wx.hideToast`) is called, and then the system modal dialog interface (`wx.showModal`) is called to display a confirmation interface containing the barcode content and the reason for the verification failure, and provides two operation options: "Use this result" and "Rescan". Step S4 (Verification Passed / User Overrides → Database Query): When the user selects "Use this result", the local product database query is performed as is using the barcode string that has not undergone the progressive multi-level format verification; when step S1 determines that the verification has passed, the database query is performed using the verified barcode string; the caller page is notified through a preset callback function based on the matching result.

2. The method according to claim 1 Its features are, The progressive multi-level format verification in step S1 is technically necessary—"pure numeric verification" must be placed before "verification bit calculation": each arithmetic operation in the verification bit calculation assumes that all characters involved in the operation are valid decimal numbers. If the string contains non-numeric characters, the arithmetic operation in the weakly typed JavaScript language will produce a `NaN` value (non-numeric), making all subsequent verification bit calculation results meaningless; the maximum retry threshold is 3 times, the preset duration of the Toast notification in step S2 is 1500 milliseconds, and the delay duration of the recursively called `setTimeout` is 200 milliseconds.

3. The method according to claim 1 Its features are, The module-level closure variable retry counter (`_retryCount`) is defined in the module-level scope of the WeChat Mini Program tool module and does not belong to any function or page instance; During the recursive call in step S2, the function is shared by all recursive instances within the same module, ensuring that each recursive call operates on the same memory address when executing `_retryCount++`, thus correctly accumulating the number of retries across recursive calls. Furthermore, the QR code entry page, report page, product list page, and procurement page in the WeChat mini-program are all short-lived pages accessed via `wx.navigateTo` (the page instance is destroyed upon user return). If the counter is stored as a page instance variable (`this._retryCount`), the retry count state will be lost with each page switch and re-entry. However, the module-level closure variable is stored in the module's persistent file scope—multiple pages share the same memory space when obtaining the same module reference multiple times via `require`—ensuring that the counter state remains within the module's lifecycle regardless of page switching, destruction, or reconstruction, achieving continuous tracking of retry states across pages.

4. The method according to claim 1 Its features are, All logic in steps S1 to S4 is encapsulated in a single entry function of the WeChat Mini Program tool module. Each calling page passes differentiated business processing logic through a callback configuration object. This callback configuration object contains four callback functions: `onFound(barcode, product)` – called when the database query matches successfully; `onNotFound(barcode)` – called when the database query does not find a match, and the calling page pops up a quick profile component in this callback for operators to create new products; `onCancel(barcode)` – called when the user selects "re-scan" in the modal dialog box in step S3; and `onError(error)` – called when a system-level error occurs during the scanning interface call. These four callback functions allow the calling page to avoid understanding the internal verification-retry-notification transfer implementation details of the tool module, achieving isolation between the scanning error-tolerance logic and the page's business logic.

5. The method according to claim 1 Its features are, In step S4, when the user selects "Use this result" to perform a database query with the unverified barcode string as is, the original data integrity of the barcode string is preserved—no modifications, truncation, or format conversions are made to the barcode string. The original binary form of the barcode string is used as the exact matching key for the database query, ensuring that the key value used by the database query is completely consistent with the barcode content seen by the user in the modal dialog box in step S3.

6. The method according to claim 1 Its features are, In the cashier page of the WeChat mini-program, the method employs a dual-track strategy implementation independent of the tool module's entry function. This dual-track strategy uses a page instance-level retry counter (`this._scanRetryCount`) and supports dual-mode scanning: manual scanning mode initiates a single scan via the `wx.scanCode` system interface, while continuous scanning mode uses the WeChat mini-program's `...`... <camera> The component's frame callback (`bindscancode`) continuously captures the scanning results without repeatedly opening the system's scanning interface.< / camera> 7. The method according to claim 6 Its features are, In the continuous scanning mode on the cashier page, the retry strategy after verification failure differs from the module-level closure variable recursion scheme of the tool module—it locks subsequent frame callbacks by setting a scan cooldown flag (`_scanCooldown`), displays a Toast progress indicator, clears the cooldown flag upon `setTimeout` expiration, and simultaneously sets a camera reset flag (`cameraReset`) to trigger the retry. <camera>The component recaptures frames to achieve a "pause → resume" retry waiting process; when retries are exhausted, the user notification uses a custom modal dialog box (`retryFailModal`) from the WeChat Mini Program WXML template instead of the `wx.showModal` system interface. This custom dialog box is pre-declared in the page's WXML document object model, and its hierarchical relationship with the native camera component is explicitly controlled by the DOM node arrangement order and `z-index`, avoiding black-box hierarchical conflicts between the system API native layer and the DOM layer.< / camera> 8. A barcode scanning fault-tolerant identification system A barcode scanning error-tolerant recognition system, applied to the WeChat mini-program operating environment, is characterized by: include: The progressive verification module is used to perform four-layer progressive format verification on the barcode string obtained by scanning: pure number verification → length verification → country code prefix matching → verification bit calculation → termination if the previous layer fails. The automatic retry and Toast progress module includes a module-level closure variable retry counter. When the progressive verification module determines that the verification fails and the current value of the counter is less than the preset maximum retry threshold, the counter will increment automatically and the progress prompt will be displayed through `wx.showToast`. After a preset delay, the `wx.scanCode` scanning interface will be called again to initiate a new scanning operation. The phase switching and user decision module executes the following sequential operations when the counter reaches the maximum threshold: counter reset → `wx.hideToast` → `wx.showModal`. Depending on the user's selection in the modal dialog box, the module will either "re-scan" or "user override" (skip all verifications and enter the database query as is with the barcode string). The database query and callback notification module performs a query on the local persistent product data file when the progressive verification passes or the user overruns the system, and notifies the calling page through a preset callback function based on the matching results. The above four modules are encapsulated in a single entry function of the WeChat Mini Program tool module, and each calling page passes differentiated business processing logic through a callback configuration object.

9. A computer-readable storage medium A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the steps of the method according to any one of claims 1 to 7.

10. An electronic device An electronic device includes a processor and a memory, the memory storing a computer program executable on the processor, characterized in that... When the processor executes the program, it implements the steps of the method according to any one of claims 1 to 7.

Images