A data processing method and system

Abstract

This invention discloses a data processing method and system. The method includes: establishing a mapping table to store exclusive rules and public rules; exclusive rules apply only to the corresponding supplier, while public rules apply to all suppliers; receiving files uploaded by suppliers, performing matching on the fields to be mapped, prioritizing searching for platform standard data from the exclusive rules, and if no match is found, reverting to the public rules; if still no match is found, marking the process as failed; exporting failed matching data as an error report, receiving corrected and re-uploaded files, generating a new batch number for re-matching, and using database unique constraints to prevent duplicate entries; receiving successfully matched data, performing paginated reading, caching, and deduplication, then calling an external system for verification and order generation; asynchronously executing order publishing, automatically retrying on failures, and recording the status for manual compensation if all attempts fail. This invention solves the problem of interoperability difficulties caused by inconsistent data formats and differences in encoding rules, achieving automated and efficient batch processing of data.

Description

Technical Field

[0001] This invention relates to the field of e-commerce data technology, and more specifically, to a data processing method and system. Background Technology

[0002] In traditional supply chain data exchange, inconsistencies in data formats, coding rules, and classification standards often lead to difficulties in data integration between suppliers and retail platforms. Specifically, different suppliers use different codes for the same brand (e.g., some suppliers call it "Superior Quality" while others call it "SP"); different suppliers use different names for the same season (e.g., "Spring" vs. "Spring"); and different suppliers use different representations for the same size (e.g., "L" vs. "175 / 92A"). These problems prevent retail platforms from directly recognizing and processing the product data uploaded by suppliers.

[0003] Existing solutions typically require manual data matching and correction, which is inefficient and prone to errors. A search revealed the following related solutions: The first solution uses a single global mapping table for data mapping, but this solution cannot handle different suppliers' varying coding preferences for the same entity. When multiple suppliers have different coding habits, a single mapping table cannot simultaneously meet the needs of all suppliers. The second solution generates orders through inventory comparison, but this solution does not disclose the linkage with the master data mapping module, resulting in unstandardized master data during inventory verification, which easily leads to erroneous orders. The third solution provides Excel parsing and verification functions, but does not disclose error mark export and closed-loop retransmission mechanisms, making it difficult for users to locate and correct erroneous data.

[0004] In summary, the existing technology has the following shortcomings: First, there is the issue of inconsistent coding rules, with different suppliers using different codes for the same entity, lacking a two-tier mapping mechanism that simultaneously supports supplier personalization and platform unification; second, there is the issue of field identification and binding, with different suppliers uploading different column names in their Excel files, and existing automated identification methods have low accuracy and cannot be fully controlled by users; third, there is the issue of data verification and closed-loop processing, lacking a complete closed loop of marking, exporting, correcting, and re-uploading when some data mapping fails in batch data; fourth, there is the issue of inventory verification and order generation, as standardized data needs to be compared with platform inventory, and existing solutions do not effectively decouple master data standardization from inventory verification. Summary of the Invention

[0005] This invention provides a data processing method and system to solve the problems in the prior art where data exchange between suppliers is difficult due to inconsistent formats, different encoding rules, and inconsistent classification standards, resulting in low efficiency and error-prone manual matching.

[0006] To achieve the above objectives, the present invention provides a data processing method, comprising: S1, establishing a mapping table, wherein the mapping table stores supplier-specific rules and public rules, used to map supplier raw data to platform standard data, the supplier-specific rules being applicable only to the corresponding supplier, and the public rules being applicable to all suppliers; S2, receiving a file uploaded by the supplier, and performing a matching operation on the fields to be mapped in the file, the matching operation comprising: firstly searching for the corresponding platform standard data in the supplier's supplier-specific rules, if no match is found, then backtracking to search in the public rules, and if still no match is found, then marking the field as a match. S3. Export all failed matching data rows as an error report, receive the file re-uploaded by the user after correction, generate a new batch number, re-execute S2 based on the new batch number, and prevent duplicate entries through database unique constraints; S4. Receive the full inventory data that has passed matching, perform paginated reading, caching and deduplication on the full inventory data, call the external system for verification, and generate an order based on the verification result; S5. Execute the order release to the external SAP system in an asynchronous manner. When the release fails, automatically retry a predetermined number of times. If all retries fail, record the failure status for manual compensation.

[0007] Optionally, before performing the matching operation on the fields to be mapped in the file, the following steps are included: the platform front-end parses the file uploaded by the supplier and reads the supplier header of the file, pops up a header matching window, the window lists the supplier headers and provides a corresponding platform standard header drop-down option for each supplier header, the user manually selects the platform standard header corresponding to each supplier header through the drop-down box, and after confirmation, the platform saves the mapping relationship to the database; when the same supplier uploads again, the platform automatically reads the historically saved mapping relationship; there is a one-to-one correspondence between each supplier header and the platform standard header, and the database unique constraint ensures that there is no duplicate configuration.

[0008] Optionally, the matching operation also includes multi-rule conflict handling: when multiple rules match the same field to be mapped, the rules are selected in the following priority order: first priority, rule type, exclusive rules take precedence over public rules; second priority, matching accuracy, exact matching takes precedence over alias matching, and alias matching takes precedence over fuzzy matching; third priority, creation time, the most recently created rule takes precedence.

[0009] Optionally, the matching failure and re-upload process includes a status transition: four status codes are defined, where 0 indicates a successful match, -1 indicates a matching in progress, -2 indicates a failed match, and -3 indicates that the match has been corrected and is awaiting re-upload; during re-upload, the user can choose to re-upload only the data rows that failed to match or re-upload all of them; the new batch number is formatted as a supplier identifier combined with a timestamp; the database unique constraint is established on the combination of the three fields: supplier identifier, batch number, and data row number.

[0010] Optionally, the process of paginating, caching, and deduplicating the full inventory data includes: paginating the full inventory data according to a preset number of records to obtain paginated data blocks; storing the paginated data blocks in a Redis cache to obtain cached data, wherein the cache validity period is 3 hours; and using a HashSet to deduplicate the style number field in the cached data to obtain a set of unique style numbers.

[0011] On the other hand, the present invention provides a data processing system, comprising: a rule establishment unit for establishing a mapping table, wherein the mapping table stores supplier-specific rules and public rules for mapping supplier raw data to platform standard data, wherein the supplier-specific rules apply only to the corresponding supplier, and the public rules apply to all suppliers; a matching unit for receiving a file uploaded by the supplier and performing a matching operation on the fields to be mapped in the file, wherein the matching operation includes: firstly searching for the corresponding platform standard data in the supplier's supplier-specific rules; if no match is found, then reverting to searching in the public rules; if still no match is found, then marking the field as a failed match; and correcting retransmission orders. The system has several functions: First, it exports all failed matching data rows as an error report, receives the corrected and re-uploaded file from the user, generates a new batch number, re-executes the matching unit based on the new batch number, and prevents duplicate entries through database unique constraints. Second, it receives the full inventory data that has passed matching, performs paginated reading, caching, and deduplication on the full inventory data, calls an external system for verification, and generates orders based on the verification results. Third, it publishes orders to an external SAP system asynchronously. When publishing fails, it automatically retryes a predetermined number of times. If all retries fail, the failure status is recorded for manual compensation.

[0012] Optionally, before performing the matching operation on the fields to be mapped in the file, the following steps are included: the platform front-end parses the file uploaded by the supplier and reads the supplier header of the file, pops up a header matching window, the window lists the supplier headers and provides a corresponding platform standard header drop-down option for each supplier header, the user manually selects the platform standard header corresponding to each supplier header through the drop-down box, and after confirmation, the platform saves the mapping relationship to the database; when the same supplier uploads again, the platform automatically reads the historically saved mapping relationship; there is a one-to-one correspondence between each supplier header and the platform standard header, and the database unique constraint ensures that there is no duplicate configuration.

[0013] Optionally, the matching operation also includes multi-rule conflict handling: when multiple rules match the same field to be mapped, the rules are selected in the following priority order: first priority, rule type, exclusive rules take precedence over public rules; second priority, matching accuracy, exact matching takes precedence over alias matching, and alias matching takes precedence over fuzzy matching; third priority, creation time, the most recently created rule takes precedence.

[0014] Optionally, the matching failure and re-upload process includes a status transition: four status codes are defined, where 0 indicates a successful match, -1 indicates a matching in progress, -2 indicates a failed match, and -3 indicates that the match has been corrected and is awaiting re-upload; during re-upload, the user can choose to re-upload only the data rows that failed to match or re-upload all of them; the new batch number is formatted as a supplier identifier combined with a timestamp; the database unique constraint is established on the combination of the three fields: supplier identifier, batch number, and data row number.

[0015] Optionally, the process of paginating, caching, and deduplicating the full inventory data includes: paginating the full inventory data according to a preset number of records to obtain paginated data blocks; storing the paginated data blocks in a Redis cache to obtain cached data, wherein the cache validity period is 3 hours; and using a HashSet to deduplicate the style number field in the cached data to obtain a set of unique style numbers.

[0016] The beneficial effects of this invention are: This invention provides a data processing method and system. The method establishes a mapping table storing exclusive rules and public rules, employing a two-layer lookup mechanism of exclusive priority and public fallback in matching operations. This solves the problem in existing technologies where a single mapping table cannot accommodate the personalized coding needs of different suppliers, achieving both rule configuration reuse and personalization unification. By manually configuring and saving the correspondence between supplier headers and platform standard headers, it solves the problems of low accuracy and lack of user control in automated field recognition, ensuring the accuracy and traceability of the mapping relationship. By exporting failed matching data rows as error reports and supporting re-uploading after correction, combined with batch numbers and database unique constraints to prevent duplicate entries, a complete closed-loop processing mechanism is formed, solving the problem of ineffective tracking and correction of erroneous data. By paginating, caching, and deduplicating the fully matched inventory data before calling an external system for verification and order generation, it solves the performance bottleneck problems of memory overflow and repeated external interface calls during large-scale data processing. By asynchronously executing order publishing and automatically retrying upon failure, it solves the problem of publishing failures due to temporary faults such as network jitter during external system publishing, ensuring high system availability and eventual data consistency. In summary, this invention, in the context of supplier data interaction, achieves fully automated processing from receiving heterogeneous data from multiple sources to standardizing mapping, from error closed-loop handling to large-scale inventory verification, and from automatic order generation to reliable release, significantly improving data processing efficiency, accuracy, and system stability. Attached Figure Description

[0017] Figure 1 This is a flowchart of a data processing method provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a data processing system provided in an embodiment of the present invention. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0019] Figure 1 This is a flowchart of a data processing method provided in an embodiment of the present invention, such as... Figure 1 As shown, the method includes steps S1 to S5.

[0020] S1. Establish a mapping table, which stores supplier-specific rules and public rules to map supplier raw data to platform standard data. The supplier-specific rules are only applicable to the corresponding supplier, while the public rules are applicable to all suppliers. Specifically, the mapping table is a data structure stored in the database used to store the correspondence between supplier raw data and platform standard data. Each record in the mapping table is a mapping rule. Each mapping rule contains at least three core fields: a supplier identifier field, used to identify which supplier the rule applies to, with the supplier identifier for public rules set to a public identifier; a supplier raw data field, used to store the raw data uploaded by the supplier; and a platform standard data field, used to store the platform standard data obtained after mapping.

[0021] The core technical concept of this step lies in dividing the mapping rules into two levels: dedicated rules and public rules. Dedicated rules are bound to a specific vendor and apply only to that vendor, used to handle the vendor's unique data representation habits; public rules are not bound to any specific vendor but are associated with a common identifier, applicable to all vendors, used to handle common data mapping needs. This two-tiered design satisfies both the need to preserve vendors' personalized data representation habits and enables the reuse of general mapping rules, avoiding the workload of repeatedly configuring the same rules for each vendor.

[0022] Taking the Youpin platform as an example, the platform needs to connect with multiple apparel suppliers for data integration. The platform has defined its own standard data system: in terms of brands, TIANTIAN represents Tiantian brand, SHISHANG represents fashion brand, and BAIDA represents versatile brand; in terms of seasons, SS represents spring / summer and AW represents autumn / winter; in terms of colors, Black represents black, White represents white, Red represents red and Blue represents blue; in terms of sizes, S, M, L, XL, and XXL represent different sizes.

[0023] The platform administrator first configures public rules. The public rules are stored in a mapping table, and the vendor identifier field is set to 0 (public identifier). In terms of brand mapping, the vendor's raw data "Tiantian" is mapped to the platform standard data "TIANTIAN", the vendor's raw data "Shishang" is mapped to "SHISHANG", and the vendor's raw data "Baida" is mapped to "BAIDA". In terms of season mapping, the vendor's raw data "Chunxia" (Spring and Summer) is mapped to "SS", and the vendor's raw data "Qiudong" (Autumn and Winter) is mapped to "AW". In terms of color mapping, the vendor's raw data "Black" is mapped to "Black", and the vendor's raw data "White" is mapped to "White". In terms of size mapping, the vendor's raw data "S" is mapped to "S", "M" to "M", "L" to "L", and "XL" to "XL". These public rules apply to all vendors. When the data uploaded by any vendor contains these raw data, the system will automatically map them to the corresponding platform standard data.

[0024] At the same time, the platform administrator configures exclusive rules for vendors with special data representation habits. Taking vendor S002 (Fashion Pioneer) as an example, this vendor is accustomed to using English abbreviations, for example, using "SF" instead of "Shishang" for the brand. The administrator configures exclusive rules for it, and the vendor identifier field is set to S002. The exclusive rules include: the brand raw data "SF" is mapped to "SHISHANG", the season raw data "SpringSummer" is mapped to "SS", the season raw data "FallWinter" is mapped to "AW", the color raw data "BK" is mapped to "Black", the color raw data "WH" is mapped to "White", the size raw data "LG" is mapped to "L", and the size raw data "MD" is mapped to "M". These exclusive rules only apply to vendor S002, and other vendors will not use these rules.

[0025] Through step S1, the system establishes a complete mapping rule base, which lays a foundation for subsequent data matching operations. The technical advantage of the two-layer rule design is: when a new vendor is added to the platform, if the data representation habit of the vendor is consistent with the public rules, the vendor can be used directly without configuring any exclusive rules; if the vendor has a special data representation habit, only the differentiated exclusive rules need to be configured, and the public part can still be reused. This greatly reduces the workload of rule configuration.

[0026] S2. Receiving a file uploaded by a vendor, and performing a matching operation on the to-be-mapped fields in the file. The matching operation includes: preferentially searching for corresponding platform standard data from the exclusive rules of the vendor, falling back to searching in the public rules if no match is found, and marking the field as matching failed if still no match is found; The core technical concept of this step lies in the "one query, two matches" strategy. When performing a matching operation, the system first queries the database once, based on the current supplier's identifier, to retrieve the supplier's exclusive rules and all public rules, building exclusive mapping tables and public mapping tables in memory respectively. During matching, for each field to be mapped, the system first searches in the exclusive mapping table; if found, it uses it directly; if not found, it backtracks to search in the public mapping table; if still not found, the field is marked as a failed match. This design reduces the operation that originally required multiple database queries to one, significantly reducing database access overhead.

[0027] Taking supplier S001 (TIANTIAN Apparel) as an example, this supplier uploaded an inventory file containing three rows of data. In the first row, the brand is "TIANTIAN," the season is "Spring / Summer," the color is "Black," and the size is "L." Upon receiving this file, the system first queries the supplier's exclusive rules (this supplier did not configure exclusive rules) and all common rules based on the supplier's identifier. After building a mapping table in memory, for the brand field "TIANTIAN," the system first searches in the exclusive mapping table. If not found, it then searches in the common mapping table, where a mapping from "TIANTIAN" to "TIANTIAN" exists, resulting in a successful match. For the season field "Spring / Summer," a mapping from "Spring / Summer" to "SS" exists in the common mapping table, resulting in a successful match. For the color field "Black," a mapping from "Black" to "Black" exists in the common mapping table, resulting in a successful match. For the size field "L," a mapping from "L" to "L" exists in the common mapping table, resulting in a successful match. All fields in this row match successfully.

[0028] Taking supplier S002 (Fashion Pioneer) as an example, this supplier uploaded a file containing five rows of data. In the first row, the brand is "SF", the season is "Spring / Summer", the color is "BK", and the size is "LG". The system retrieves S002's proprietary rules and all common rules. For the brand field "SF", the system first searches the proprietary mapping table and finds a mapping from "SF" to "SHISHANG", resulting in a successful match. For the season field "Spring / Summer", the proprietary mapping table shows a mapping from "Spring / Summer" to "SS", also resulting in a successful match. For the color field "BK", the proprietary mapping table shows a mapping from "BK" to "Black", resulting in a successful match. For the size field "LG", the proprietary mapping table shows a mapping from "LG" to "L", resulting in a successful match. All fields in this row match successfully.

[0029] However, in the second row of data from supplier S002, the color is "WH" and the size is "MD". For the color field "WH", the system first searches in the exclusive mapping table, where there is no mapping for "WH", then falls back to search in the public mapping table, where there is also no mapping for "WH" (the public rules only include the Chinese mappings of "Black" corresponding to "Black" and "White" corresponding to "White"), so the matching fails. For the size field "MD", there is a mapping from "MD" to "M" in the exclusive mapping table, and the matching is successful. The color field of this row of data is marked as a matching failure.

[0030] Taking supplier S003 (Baida Garment) as an example, this supplier uploads a file containing three rows of data. In the first row of data, the brand is "Baida", the listing season is "Spring", the color classification is "Black", and the size is "175 / 92A". For the brand field "Baida", there is a mapping from "Baida" to "BAIDA" in the public mapping table, and the matching is successful. For the season field "Spring", there is no exact match in the public mapping table, and the matching fails. For the color field "Black", there is a mapping from "Black" to "Black" in the public mapping table, and the matching is successful. For the size field "175 / 92A", there is no mapping in the public mapping table, and the matching fails. The season field and the size field of this row of data are marked as matching failures.

[0031] In the third row of data, the brand is "Zapai" and the color classification is "Gray". For the brand field "Zapai", there is no mapping in the public mapping table, and the matching fails. For the color field "Gray", there is no mapping in the public mapping table, and the matching fails. Both the brand field and the color field of this row of data are marked as matching failures.

[0032] In an optional embodiment, before performing the matching operation on the fields to be mapped in the file, the following steps are included: The front end of the platform parses the file uploaded by the supplier and reads the supplier headers of the file, pops up a header matching window, which lists the supplier headers and provides corresponding drop-down options of platform standard headers for each supplier header. The user manually selects the platform standard header corresponding to each supplier header through the drop-down box, and after confirmation, the platform saves the mapping relationship to the database; When the same supplier uploads again, the platform automatically reads the historically saved mapping relationship; There is a one-to-one correspondence between each supplier header and the platform standard header, and no duplicate configuration is ensured through the unique constraint of the database.

[0033] The core technical concept of this optional implementation lies in establishing the header mapping relationship through manual configuration rather than automated recognition. The column names in Excel files from different suppliers vary greatly, making it difficult to guarantee the accuracy of automated recognition. For example, one supplier might use the column name "Item Number," another "Product ID," and still others "Item Code" or "SKU." If automatic recognition is used with regular expressions, matching rules need to be written for each possible column name, but the naming conventions of suppliers are numerous, making it difficult to exhaustively list all possible rules. If column name similarity calculation is used, for example, calculating the string similarity between "Product ID" and the platform's standard header "Item Number," the similarity might be too low due to the semantic differences between "Product" and "Item Number," resulting in incorrect matching. If automatic learning is used with machine learning, a large amount of labeled training data is required, and the model needs to be retrained after a supplier changes the column names. If automatic recommendation is based on historical data, a supplier's unique column name might be incorrectly recommended to another supplier. Therefore, this invention uses a manual configuration method. Although it requires an initial user operation, once configured, it can be reused permanently, and the mapping relationship is entirely controlled by the user, achieving 100% accuracy.

[0034] Taking supplier S003 (Versatile Apparel)'s first upload as an example, the uploaded file has columns named "Product Number," "Brand," "Season of Release," "Color Category," "Size," and "Inventory." After parsing the file, the platform frontend reads the above six supplier headers. Since this supplier has no historical configuration records in the header correspondence table, the system automatically pops up a header matching window. The left side of the window lists the supplier's six headers, and the right side of each header provides a drop-down list with standard header options from the platform, including style number, brand, season, color, size, and inventory quantity. Users manually select the correspondence using the drop-down list: matching "Product Number" with "Style Number," "Brand" with "Brand," "Season of Release" with "Season," "Color Category" with "Color," "Size" with "Size," and "Inventory" with "Inventory Quantity." After user confirmation, the platform saves these six correspondences to the sys_header_correspondence table in the database.

[0035] To illustrate the necessity of manual configuration, let's assume the platform uses an automated identification method to process supplier S003's files. If regular expression identification is used, the platform needs to predefine regular expression rules that might match "product number," such as "^.number | .*code | .*code | ^.encoding". However, while supplier S003's column name is "Product Number," which can be matched, another supplier might use "Item Number," requiring new rules to be added, leading to an ever-expanding and exhaustive rule base. If column name similarity is used, calculating the edit distance between "Product Number" and the platform's standard header "Item Number" reveals significant differences in string length and character representation, potentially resulting in a similarity score below 50% and matching failure. Automatic learning using machine learning requires extensive training with labeled supplier header data, and the model cannot adapt automatically when supplier S003 modifies its column name. Automatic recommendation using historical data risks the platform incorrectly recommending "Product Name" instead of "Product Number" based on other suppliers' historical configurations, leading to data mapping errors. Therefore, this invention employs a manual configuration method, requiring users to personally confirm the platform's standard header corresponding to each supplier header to ensure accurate mapping.

[0036] When supplier S003 uploads the file for the second time, the platform automatically reads the historically saved mapping relationship and directly applies the previous configuration, eliminating the need for the user to repeat the process. At this time, the platform does not make any automated recommendations or modifications to the existing mapping relationship, completely using the user's previous configuration.

[0037] If supplier S003 subsequently modifies the file format, for example, by adding a new column "Tag Price" and renaming "Size" to "Size Specification," the platform, after parsing the file, detects that "Size Specification" exists in the historical mapping (historically, "Size" corresponds to "Size"). However, because the column name has changed, the platform cannot automatically match it, and therefore a header matching window pops up again. In this window, for the five columns "Product Number," "Brand," "Season of Release," "Color Category," and "Inventory," the platform automatically fills in the historical mapping (because the column names haven't changed). For the newly added "Tag Price" and the modified "Size Specification," the platform requires the user to manually configure them. The user maps "Size Specification" to "Size" and "Tag Price" to "Tag Price." After confirmation, the platform saves the updated mapping. The original mapping remains unchanged; only the changed parts are updated.

[0038] Through the above design, the manual configuration method not only ensures the accuracy of the mapping relationship, but also reduces the repetitive operations of users by reusing history. At the same time, it explicitly excludes various automated recognition methods and avoids uncontrollable errors that may be caused by automated recognition.

[0039] In an optional implementation, the matching operation further includes multi-rule conflict handling: When multiple rules match the same field to be mapped, the rules are selected in the following priority order: First priority, rule type: proprietary rules take precedence over public rules; Second priority, matching precision, an exact match takes precedence over an alias match, and an alias match takes precedence over a fuzzy match; Third priority, creation time, the most recently created rule takes precedence.

[0040] The core technical concept of this optional embodiment lies in solving the conflict problem during multi-rule matching. In practical applications, the same original data from the same supplier may match multiple mapping rules at the same time, and the system requires clear priority rules to determine which mapping result to select. The following description uses three conflict scenarios as examples.

[0041] Scenario 1: Rule type conflict.

[0042] Assume that the original brand data of supplier S001 is "Tiantian". The system has two matching rules at the same time: one exclusive rule, with the supplier identifier being S001, which maps "Tiantian" to "TIANTIAN_SPECIAL"; and one public rule, with the supplier identifier being 0, which maps "Tiantian" to "TIANTIAN_COMMON". At this time, both rules can be matched, but the mapping results are different. The system processes according to the first priority: the exclusive rule takes precedence over the public rule, so the mapping result "TIANTIAN_SPECIAL" of the exclusive rule is selected. This embodies the original design intention that the exclusive rule is used to cover the personalized requirements of the supplier.

[0043] Scenario 2: Matching precision conflict.

[0044] Assume that the original color data of supplier S002 is "BK". The system has two public rules at the same time: one exact matching rule, which maps "BK" to "Black"; and one alias matching rule, which maps "BK color" to "Black". At this time, both rules can be matched. Since the first priority cannot make a distinction (both are public rules), the system proceeds to the second priority: exact match takes precedence over alias match, and alias match takes precedence over fuzzy match. The exact matching rule requires that the original data is completely consistent with the supplier original data in the rule, "BK" is exactly the same as "BK", which belongs to an exact match; "BK color" in the alias matching rule is not completely the same as "BK", which belongs to an alias match. Therefore, the system selects the result "Black" of the exact matching rule.

[0045] Scenario 3: Distinction between fuzzy match and alias match.

[0046] Assume supplier S003's original seasonal data is "Spring". The system has no exact match rule, but it does have an alias match rule that maps "Spring" to "SS". Simultaneously, there is a fuzzy match rule; edit distance calculations show that "Spring" has a 75% similarity to "SS" but a 0% similarity to "AW". At this point, the system prioritizes alias match over fuzzy match, therefore selecting the alias match result "SS". If both rules are fuzzy matches and their similarity exceeds the 80% threshold, the rule with the highest similarity is selected; if the similarities are the same, the system proceeds to the third priority level, selecting the rule with the most recent creation time.

[0047] Scenario 4: Time Priority.

[0048] Assume the original size data for supplier S001 is "L". The system has two common rules, both exact matches: one created on January 1, 2024, mapping "L" to "L_STANDARD"; the other created on June 1, 2024, mapping "L" to "L_NEW". At this point, the first two priority levels cannot be distinguished (rule type and matching precision are the same), so the system enters the third priority level, selecting the rule with the most recent creation time, i.e., the rule created on June 1, 2024, with the mapping result being "L_NEW".

[0049] Through the aforementioned three-level priority mechanism, the system can determine a unique and valid mapping result in complex scenarios involving multiple rule matching, ensuring the determinism and consistency of the mapping process.

[0050] S3. Export all data rows that failed to match as an error report, receive the file that the user corrected and re-uploaded, generate a new batch number, re-execute S2 based on the new batch number, and prevent duplicate entries into the database through database unique constraints. The core technical concept of this step lies in establishing a complete closed-loop error handling mechanism. When some rows in the batch data fail to match, the system does not simply display an error message, but exports the failed rows as an editable error report. After the user corrects and re-uploads the data, the system generates a new batch number and reprocesses it. Database unique constraints ensure that even if the same file is uploaded repeatedly, duplicate data will not be generated.

[0051] Taking supplier S002 as an example, in the five rows of data uploaded by this supplier, the second, fourth, and fifth rows had matching failures. The system exported all the data rows with matching failures as an Excel error report, named "Fashion Pioneer_Data Error Information.xlsx". The report includes the original row number, the original data content, and the reason for the failure. The reason for the failure in the second row was "Color WH has no mapping rule" and "Size MD has no mapping rule", the reason for the failure in the fourth row was "Size MD has no mapping rule", and the reason for the failure in the fifth row was "Color WH has no mapping rule".

[0052] After receiving the error report, supplier S002 corrected the original Excel file: changing the Color in the second row from "WH" to "White" and the Size from "MD" to "M"; changing the Size in the fourth row from "MD" to "M"; and changing the Color in the fifth row from "WH" to "White". After the correction, the user re-uploaded the file. Upon receiving the re-uploaded file, the system generated a new batch number and re-executed the matching operation in step S2 based on the new batch number. After the re-matching, all three previously failed rows of data matched successfully. The database uses unique constraints to prevent duplicate entries, ensuring that even if the same file is uploaded multiple times, no duplicate data records are generated.

[0053] Taking supplier S003 as an example, all three rows of data from this supplier showed matching failures. The error report indicated the following reasons for failure: the first row failed because "Size 175 / 92A has no mapping rule," the second row because "Size 180 / 96A has no mapping rule," and the third row because "Brand: Generic, no mapping rule" and "Color: Gray, no mapping rule." Supplier S003 corrected these errors after receiving the report. For the brand issue, the brand "Generic" in the third row was changed to "Versatile," as the public mapping table already has a mapping from "Versatile" to "BAIDA." For the color issue, the color "Gray" in the third row was changed to "Grey," and the platform administrator added a color mapping rule to the public mapping table, mapping "Gray" to "Grey." If Grey is not available in the platform's standard colors, "Gray" or "Grey" can also be mapped to the closest existing color on the platform, such as "Black" or "White," depending on the platform administrator's business needs. Regarding sizing, "175 / 92A" in the first row typically corresponds to platform size L, "180 / 96A" in the second row typically corresponds to platform size XL, and "185 / 100A" in the third row typically corresponds to platform size XXL. Based on the apparel industry's sizing standards, the platform administrator added sizing rules to the public mapping table: mapping "175 / 92A" to "L", "180 / 96A" to "XL", and "185 / 100A" to "XXL". After adding the rules, supplier S003 re-uploaded the file, and all data matched successfully.

[0054] In an optional implementation, the matching failure and re-upload process includes a state transition: Four status codes are defined, where 0 indicates a successful match, -1 indicates a match in progress, -2 indicates a failed match, and -3 indicates that the match has been corrected and needs to be re-uploaded. When re-uploading, users can choose to re-upload only the rows of data that failed to match or re-upload all of them; The new batch number is formatted as supplier identifier combined with timestamp; The database unique constraint is based on a combination of three fields: supplier identifier, batch number, and data row number.

[0055] The core technical concept of this optional implementation lies in tracking the entire lifecycle of data from upload to final processing completion through status codes. Each status code represents the stage of the data, facilitating system recording and user tracking.

[0056] Taking supplier S002 as an example, this supplier uploaded a file containing five rows of data, named "inventory_S002.xlsx". After receiving this file, the system first generates a batch number for this upload. The batch number is formatted as supplier identifier concatenated with a timestamp, where the supplier identifier is S002 and the timestamp is the current system time in milliseconds, assuming it is 17000000000000, then the generated batch number is "S0021700000000000". The system associates and stores this batch number with each row of data.

[0057] The system marks all data rows in this batch with a status code of -1 (matching), indicating that processing is in progress. The system then executes the matching operation in step S2. After matching is complete, all fields in the first and third rows match successfully, and the status code is updated to 0 (match successful); the second, fourth, and fifth rows contain fields that fail to match, and the status code is updated to -2 (match failed). At this point, the database records five rows of data, each containing the supplier identifier S002, batch number S0021700000000000, the corresponding data row number, the original data content, and the status code. The status codes for the first and third rows are 0, while the status codes for the second, fourth, and fifth rows are -2. The records in the latter three rows also include the reason for the failure; for example, the failure reason for the second row is "Color WH has no mapping rule" and "Size MD has no mapping rule".

[0058] After logging into the system, users will see the processing results of this upload on the interface: a total of 5 rows of data, of which 2 rows matched successfully and 3 rows failed to match. Users can click the "Download Error Report" button, and the system will export the data rows with status code -2 as an Excel file. The error report includes the original row number, the original data content, and the reason for the failure, making it easier for users to locate and correct the problem.

[0059] After the user completes the corrections, they can choose to re-upload. If the user selects "Re-upload only the rows that failed to match," then only the corrected file containing the second, fourth, and fifth rows (a total of 3 rows) needs to be uploaded. If the user selects "Re-upload all," then a corrected file containing all five rows of data needs to be uploaded. In this embodiment, the user selects to re-upload only the rows that failed to match, and the uploaded file is named "inventory_S002_corrected.xlsx." The file contains the three corrected rows of data: the Color of the second row is changed to "White," and the Size is changed to "M"; the Size of the fourth row is changed to "M"; and the Color of the fifth row is changed to "White."

[0060] After receiving the re-uploaded file, the system generates a new batch number. The new batch number format is also a supplier identifier followed by a timestamp. Assuming the current time is 1700000001000, the new batch number is "S0021700000001000". The system associates the re-uploaded data rows with the new batch number and marks these rows with a status code of -3 (corrected and awaiting re-upload), indicating that the data has been corrected by the user and is waiting for the system to reprocess it. At this point, three new records are added to the database, corresponding to data row numbers 2, 4, and 5, all with the supplier identifier S002, the batch number S0021700000001000, and a status code of -3.

[0061] The system then re-executes the matching operation in step S2 based on the new batch number. After the re-matching, all three previously failed rows of data are now matched successfully, and the status code is updated from -3 to 0 (match successful). At this point, the status code of these three records in the database becomes 0.

[0062] The database's unique constraint is based on the combination of three fields: supplier identifier, batch number, and row number. This means that even if the same file is uploaded multiple times—for example, if a user accidentally clicks the upload button twice consecutively—the system will not generate duplicate data records. This is because the first upload already inserted a record with supplier identifier S002, batch number of a certain value, and row number 2. The second upload, although with a different batch number, retains the same supplier identifier and row number, and the unique constraint prevents duplicate insertion. Alternatively, the system checks for the existence of records with the same combination before insertion; if a record exists, it updates the existing record rather than creating a new one.

[0063] Through the aforementioned status transition mechanism, the system can clearly track the complete lifecycle of each line of data from upload, matching, failure, correction, re-upload to final successful matching. Users can query the status of the data at any time, which facilitates problem location and process traceability.

[0064] S4. Receive the matched full inventory data, perform paginated reading, caching and deduplication on the full inventory data, call the external system for verification and generate an order based on the verification result; The core technical concept of this step is to control memory usage through paging, support breakpoint resumption through caching, and reduce the number of external system calls through deduplication, thereby supporting efficient processing of large amounts of data.

[0065] Taking supplier S001 as an example, the complete inventory data matched by this supplier consists of 165 lines of warehouse transaction records. In this data, item number K001 appears 100 times due to being stored on different shelves, item number K002 appears 25 times, and item number K003 appears 40 times. When processing these 165 lines of data, the system first reads the data in pages, then stores the paginated data in the cache. If the system crashes during processing, it can recover the data from the cache after restarting, without requiring the user to re-upload.

[0066] The system then deduplicates the data in the cache, extracting all unique item numbers. After deduplication, three unique item numbers are obtained: K001, K002, and K003. Through deduplication, the system reduces the original multiple potential external system calls to three.

[0067] The system verifies three unique style numbers using an external system. For K001, it calls the SKU verification interface of the external SSD system, requesting parameters including brand identifier, supplier identifier, store identifier, and style number. The external SSD system returns standard SKU data for that style number, including style number, color name, size name, current price, and original price. After verifying that both the current price and original price in the returned data are greater than 0, the system stores the SKU information in its cache. The system then calls the inventory query interface of the external SSD system to query the real-time inventory of each SKU, returning normal inventory, defective inventory, and locked inventory.

[0068] The system queries the platform database for the current platform inventory of each style number. Platform inventory data shows: K001 has 50 units, K002 has 100 units, and K003 has 0 units. The system compares the supplier's inventory with the platform inventory: For K001, the supplier's inventory of 100 units is greater than the platform's inventory of 50 units, with a difference of 50 units, so the system generates a purchase order for 50 units; for K002, the supplier's inventory of 50 units is less than the platform's inventory of 100 units, with a difference of -50 units, so the system generates a return order for 50 units; for K003, the supplier's inventory of 200 units is greater than the platform's inventory of 0 units, so a purchase order for 200 units is generated.

[0069] In an optional implementation, the step of paginating, caching, and deduplicating the full inventory data includes: The full inventory data is paginated according to a preset number of records to obtain paginated data blocks; The paginated data block is stored in the Redis cache to obtain cached data, wherein the cache validity period is 3 hours. The HashSet is used to remove duplicate item numbers from the cached data, resulting in a set of unique item numbers.

[0070] This optional implementation further defines the specific implementation methods for pagination, caching, and deduplication. Pagination reads 500 data entries per page, controlling the amount of memory used per read; the Redis cache uses a hash structure for storage, with the row number as the key and a TreeMap of the row's data as the value, supporting fast random access; HashSet deduplication is based on the style number field, with a time complexity of O(n) and a space complexity of O(k), where k is the number of distinct style numbers.

[0071] Taking supplier S001 as an example, the full inventory data matched by this supplier consists of 165 lines of warehouse transaction records. In these data, item number K001 appears 100 times, item number K002 appears 25 times, and item number K003 appears 40 times.

[0072] First, pagination is performed. The system is set to read 500 rows per page. Since the total number of rows (165) is less than 500, the system reads all 165 rows at once as a single page, resulting in a paginated data block. If the total number of rows is 10,000, the system will read the data in 20 pages, with 500 rows per page, processing only one page at a time to avoid loading all the data into memory at once and causing a memory overflow.

[0073] Then, caching is performed. The system stores paginated data blocks in a Redis cache. Redis uses a hash structure for storage, where the key is the data row number (e.g., 1, 2, 3, etc.), and the value is a TreeMap of the data for that row. The TreeMap stores each field of the row in key-value pairs, such as "K001" for the "Style Number" field and "TIANTIAN" for the "Brand" field. The cache is valid for 3 hours, starting from the time the data is stored. Within 3 hours, if the system crashes abnormally during processing, it can read the cached data from Redis after restarting and continue processing without requiring the user to re-upload the file. If more than 3 hours have passed, the cache expires automatically, and the system will prompt the user to re-upload. For example, if the system crashes suddenly while processing row 80, and after restarting it detects that the cached data for that batch still exists in Redis and has not exceeded 3 hours, it will directly continue processing from row 81.

[0074] Finally, deduplication is performed. The system reads all data rows from the Redis cache and extracts the item number field row by row. For each extracted item number, the system converts it to uppercase and adds it to a HashSet. The conversion to uppercase ensures case insensitivity; for example, "k001" and "K001" will be considered the same item number. The HashSet data structure automatically removes duplicates, keeping only one instance of the same item number. After traversing 165 rows of data, the HashSet contains only three elements: K001, K002, and K003. Through deduplication, the system reduces the original 165 calls to the external system to only 3, significantly reducing the call pressure and processing time of the external system.

[0075] To further illustrate the effectiveness of deduplication, suppose supplier S001's inventory data is not 165 rows, but 100,000 rows of warehouse transaction records, containing only 100 distinct style numbers. Without deduplication, the system would need to call an external system to verify each row of data, resulting in 100,000 calls. Assuming each call takes 10 milliseconds, the total time would be approximately 1000 seconds (about 16.7 minutes). After using HashSet for deduplication, the system only calls the external system for the 100 unique style numbers, reducing the total time to approximately 1 second—a 1000-fold speed improvement. Simultaneously, the pressure on the external system is significantly reduced, avoiding interface rate limiting or service circuit breakers caused by numerous duplicate calls.

[0076] Through the combination of pagination, caching, and deduplication mentioned above, the system can stably and efficiently handle large batches of data, ranging from 100,000 to 500,000 rows.

[0077] S5. Orders are published to external SAP systems asynchronously. If the publication fails, the system will automatically retry a predetermined number of times. If all retries fail, the failure status will be recorded for manual compensation.

[0078] The core technical concept of this step is to avoid user interface blocking through asynchronous execution, handle temporary faults such as network jitter through automatic retries, and support manual compensation through failure logging, thereby ensuring high availability and eventual data consistency of the system.

[0079] Taking the purchase order generated by supplier S001 as an example, after the user clicks the "Publish to SAP" button, the system uses the @Async annotation of the Spring framework to asynchronously execute the publishing operation in an independent thread pool. The main thread returns immediately, the user interface is not blocked, and the user can continue to process other work.

[0080] The asynchronous thread first queries the order details, only searching for rows with a matching status of "passed." Then, it establishes a connection with the SAP system via the JCoDestination class, obtaining a JCoFunction object. The thread sets the SAP call parameters, including the purchase order type, company code, purchasing group, purchasing organization, and supplier number. For each order detail row, the thread sets fields such as row item number, brand ID, material number, order quantity, plant, and planned delivery date, and then executes the SAP function call.

[0081] Suppose the first call fails due to network jitter and times out. Since the method uses the `@Retryable` annotation, the maximum number of retries is set to 3, and the system automatically retryes the first time. The second call also times out, and the system automatically retryes the second time. The third call succeeds, and the SAP system returns a processing result with an `EX_TYPE` field value of `S` indicating success, along with the order number generated by the SAP system. After receiving the success result, the thread updates the order status to "Published," saves the order number returned by SAP to the local order record, inserts a success record into the SAP publication record table, and sets the flag to 1.

[0082] Suppose an order generated by another supplier fails to be published three times consecutively, and an exception is still thrown on the third retry. The system inserts a failure record into the SAP publish log table, sets the flag to -1, and records the error message. Users can view the failure record in the backend management interface, troubleshoot the problem based on the error message, and then click the manual republish button to perform compensation processing.

[0083] Thus, the data processing method provided in this embodiment of the invention completes the entire process from mapping table creation, matching operations, error closed-loop handling, order generation to order release. The entire process achieves automated, configurable, and efficient batch processing of data, effectively solving the problems of inconsistent formats, different encoding rules, and inconsistent classification standards in supply chain data interaction.

[0084] Figure 2 This is a schematic diagram of the structure of a data processing system provided in an embodiment of the present invention; as shown below. Figure 2 As shown, the system includes: The rule establishment unit 201 is used to establish a mapping table, which stores supplier-specific rules and public rules, and is used to map supplier raw data to platform standard data. The supplier-specific rules are only applicable to the corresponding supplier, while the public rules are applicable to all suppliers. The matching unit 202 is used to receive the file uploaded by the supplier and perform a matching operation on the field to be mapped in the file. The matching operation includes: firstly searching for the corresponding platform standard data in the supplier's exclusive rules; if no match is found, then falling back to searching in the public rules; if no match is found again, then marking the field as a match failure. The retransmission unit 203 corrects and retransmits all data rows that failed to match as an error report, receives the file that the user corrects and re-uploads, generates a new batch number, re-executes the matching unit based on the new batch number, and prevents duplicate entries into the database through database unique constraints. The order generation unit 204 is used to receive the matched full inventory data, perform paginated reading, caching and deduplication processing on the full inventory data, call the external system for verification, and generate an order based on the verification result; The order publishing unit 205 is used to publish orders to an external SAP system asynchronously. When the publication fails, it automatically retryes a predetermined number of times. If all retries fail, the failure status is recorded for manual compensation.

[0085] In an optional implementation, the following is included before performing the matching operation on the field to be mapped in the file: The platform front-end parses the file uploaded by the supplier and reads the supplier header of the file. A header matching window pops up, which lists the supplier headers and provides a corresponding platform standard header drop-down option for each supplier header. The user can manually select the platform standard header corresponding to each supplier header through the drop-down box. After confirmation, the platform saves the mapping relationship to the database. When the same supplier uploads again, the platform automatically reads the historically saved mapping relationship; There is a one-to-one correspondence between each supplier header and the platform's standard header, and database uniqueness constraints ensure that there are no duplicate configurations.

[0086] In an optional implementation, the matching operation further includes multi-rule conflict handling: When multiple rules match the same field to be mapped, the rules are selected in the following priority order: First priority, rule type: proprietary rules take precedence over public rules; The second priority is matching precision: exact matching takes precedence over alias matching, and alias matching takes precedence over fuzzy matching. The third priority is creation time; the most recently created rule takes precedence.

[0087] In an optional implementation, the matching failure and re-upload process includes a state transition: Four status codes are defined, where 0 indicates a successful match, -1 indicates a match in progress, -2 indicates a failed match, and -3 indicates that the match has been corrected and needs to be re-uploaded. When re-uploading, users can choose to re-upload only the rows of data that failed to match or re-upload all of them; The new batch number is formatted as supplier identifier combined with timestamp; The database unique constraint is based on a combination of three fields: supplier identifier, batch number, and data row number.

[0088] In an optional implementation, the step of paginating, caching, and deduplicating the full inventory data includes: The full inventory data is paginated according to a preset number of records to obtain paginated data blocks; The paginated data block is stored in the Redis cache to obtain cached data, wherein the cache validity period is 3 hours. The HashSet is used to remove duplicate item numbers from the cached data, resulting in a set of unique item numbers.

[0089] The system of the present invention corresponds to the method described above, and the specific implementation of the system will not be repeated here.

[0090] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A data processing method, characterized in that, include: S1. Establish a mapping table, which stores supplier-specific rules and public rules to map supplier raw data to platform standard data. The supplier-specific rules are only applicable to the corresponding supplier, while the public rules are applicable to all suppliers. S2. Receive the file uploaded by the supplier and perform a matching operation on the fields to be mapped in the file. The matching operation includes: firstly searching for the corresponding platform standard data in the supplier's exclusive rules; if no match is found, then falling back to the public rules to search; if still no match is found, then marking the field as a failed match. S3. Export all data rows that failed to match as an error report, receive the file that the user corrected and re-uploaded, generate a new batch number, re-execute S2 based on the new batch number, and prevent duplicate entries into the database through database unique constraints. S4. Receive the matched full inventory data, perform paginated reading, caching and deduplication on the full inventory data, call the external system for verification and generate an order based on the verification result; S5. Orders are published to external SAP systems asynchronously. If the publication fails, the system will automatically retry a predetermined number of times. If all retries fail, the failure status will be recorded for manual compensation.

2. The method according to claim 1, characterized in that, Before performing the matching operation on the fields to be mapped in the file, the following is included: The platform front-end parses the file uploaded by the supplier and reads the supplier header of the file. A header matching window pops up, which lists the supplier headers and provides a corresponding platform standard header drop-down option for each supplier header. The user can manually select the platform standard header corresponding to each supplier header through the drop-down box. After confirmation, the platform saves the mapping relationship to the database. When the same supplier uploads again, the platform automatically reads the historically saved mapping relationship; There is a one-to-one correspondence between each supplier header and the platform's standard header, and database uniqueness constraints ensure that there are no duplicate configurations.

3. The method according to claim 1, characterized in that, The matching operation also includes handling multiple rule conflicts: When multiple rules match the same field to be mapped, the rules are selected in the following priority order: First priority, rule type: proprietary rules take precedence over public rules; The second priority is matching precision: exact matching takes precedence over alias matching, and alias matching takes precedence over fuzzy matching. The third priority is creation time; the most recently created rule takes precedence.

4. The method according to claim 1, characterized in that, The matching failure and re-upload process includes state transitions: Four status codes are defined, where 0 indicates a successful match, -1 indicates a match in progress, -2 indicates a failed match, and -3 indicates that the match has been corrected and needs to be re-uploaded. When re-uploading, users can choose to re-upload only the data rows that failed to match or re-upload all of them; The new batch number is formatted as supplier identifier combined with timestamp; The database unique constraint is based on a combination of three fields: supplier identifier, batch number, and data row number.

5. The method according to claim 1, characterized in that, The process of paginating, caching, and deduplicating the full inventory data includes: The full inventory data is paginated according to a preset number of records to obtain paginated data blocks; The paginated data block is stored in the Redis cache to obtain cached data, wherein the cache validity period is 3 hours. The HashSet is used to remove duplicate item numbers from the cached data, resulting in a set of unique item numbers.

6. A data processing system, characterized in that, include: The rule establishment unit is used to establish a mapping table, which stores supplier-specific rules and public rules to map supplier raw data to platform standard data. The supplier-specific rules are only applicable to the corresponding supplier, while the public rules are applicable to all suppliers. The matching unit is used to receive files uploaded by suppliers and perform matching operations on the fields to be mapped in the files. The matching operation includes: firstly searching for the corresponding platform standard data in the supplier's exclusive rules; if no match is found, then falling back to searching in the public rules; if still no match is found, then marking the field as a match failure. The correction and retransmission unit exports all data rows that failed to match as an error report, receives the file that the user has corrected and re-uploaded, generates a new batch number, re-executes the matching unit based on the new batch number, and prevents duplicate entries into the database through database unique constraints. The order generation unit is used to receive the matched full inventory data, perform paginated reading, caching and deduplication processing on the full inventory data, call the external system for verification, and generate an order based on the verification result; The order publishing unit is used to publish orders to an external SAP system asynchronously. When publishing fails, it automatically retryes a predetermined number of times. If all retries fail, the failure status is recorded for manual compensation.

7. The system according to claim 6, characterized in that, Before performing the matching operation on the fields to be mapped in the file, the following is included: The platform front-end parses the file uploaded by the supplier and reads the supplier header of the file. A header matching window pops up, which lists the supplier headers and provides a corresponding platform standard header drop-down option for each supplier header. The user can manually select the platform standard header corresponding to each supplier header through the drop-down box. After confirmation, the platform saves the mapping relationship to the database. When the same supplier uploads again, the platform automatically reads the historically saved mapping relationship; There is a one-to-one correspondence between each supplier header and the platform's standard header, and database uniqueness constraints ensure that there are no duplicate configurations.

8. The system according to claim 6, characterized in that, The matching operation also includes handling multiple rule conflicts: When multiple rules match the same field to be mapped, the rules are selected in the following priority order: First priority, rule type: proprietary rules take precedence over public rules; The second priority is matching precision: exact matching takes precedence over alias matching, and alias matching takes precedence over fuzzy matching. The third priority is creation time; the most recently created rule takes precedence.

9. The system according to claim 6, characterized in that, The matching failure and re-upload process includes state transitions: Four status codes are defined, where 0 indicates a successful match, -1 indicates a match in progress, -2 indicates a failed match, and -3 indicates that the match has been corrected and needs to be re-uploaded. When re-uploading, users can choose to re-upload only the data rows that failed to match or re-upload all of them; The new batch number is formatted as supplier identifier combined with timestamp; The database unique constraint is based on a combination of three fields: supplier identifier, batch number, and data row number.

10. The system according to claim 6, characterized in that, The process of paginating, caching, and deduplicating the full inventory data includes: The full inventory data is paginated according to a preset number of records to obtain paginated data blocks; The paginated data block is stored in the Redis cache to obtain cached data, wherein the cache validity period is 3 hours. The HashSet is used to remove duplicate item numbers from the cached data, resulting in a set of unique item numbers.

Images