Form file processing method, electronic equipment, storage medium and program product

Abstract

The invention provides a form file processing method, electronic equipment, a readable storage medium and a computer program product. The method comprises the following steps: acquiring a table file which is provided by a user and contains cell data, and a first table template which contains a standard table header; identifying at least one category field corresponding to a primary header line of the form file, and constructing a category field set; determining a corresponding secondary header array based on the category field set; combining the secondary header array and the first table template to obtain a second table template; and importing the cell data in the table file into the second table template according to the corresponding relationship between the table file and the second table template.

Description

Technical Field

[0001] This disclosure relates to the fields of computer technology, and more particularly to a method for processing spreadsheet files, electronic devices, storage media, and program products. Background Technology

[0002] In existing technologies, merchants typically rely on online spreadsheets for data processing when managing their products. When merchants and suppliers, or different departments within a merchant organization, need to publish, edit, or add products to their stores, offline Excel spreadsheets are commonly used to transfer product information, which is then aggregated and processed uniformly. This method relies on manual aggregation and processing of product data provided by suppliers.

[0003] However, the existing processing method has significant technical problems. Due to the diversity of different suppliers and brand categories, the headers of the offline Excel spreadsheets provided by suppliers are often inconsistent with the standardized headers of the online spreadsheets. This necessitates manual decomposition and mapping of fields based on experience, a time-consuming, labor-intensive process prone to errors. Furthermore, when the operation involves product information from multiple categories, the headers of different online spreadsheets for each category need to be rendered sequentially, resulting in a complex and lengthy workflow that impacts overall efficiency. Therefore, a solution is needed that can uniformly process various non-standard format spreadsheet files. Summary of the Invention

[0004] This disclosure provides a method for processing tabular files, an electronic device, a storage medium, and a program product.

[0005] According to one aspect of this disclosure, a method for processing a table file is provided. The method includes: obtaining a user-provided table file containing cell data and a first table template containing standard headers; identifying at least one category field corresponding to the first-level header rows of the table file and constructing a category field set; determining a corresponding second-level header array based on the category field set; combining the second-level header array and the first table template to obtain a second table template; and importing the cell data from the table file into the second table template according to the correspondence between the table file and the second table template.

[0006] According to the above solution, the category field is dynamically identified and a secondary header array is constructed, thereby automatically expanding the standard template to adapt to the import of product information from multiple suppliers and multiple product categories. This significantly improves processing efficiency and avoids the time-consuming and labor-intensive traditional manual mapping. Simultaneously, through precise matching of correspondences and data import, the accuracy and integrity of the data are ensured, enhancing the standardization level of supply chain management. It can also handle table files with inconsistent headers without additional configuration, making it suitable for large-scale, multi-category product data operation scenarios, ultimately reducing operating costs and improving user experience.

[0007] According to at least one embodiment of this disclosure, determining the corresponding secondary header array based on a category field set includes: sending a field request to a pre-configured first database based on the category field set; obtaining the unique attribute fields corresponding to each category in the category field set returned by the first database as secondary header fields; and constructing a secondary header array using the secondary header fields corresponding to the category field set.

[0008] According to the above solution, using a pre-configured database for field requests and responses automatically retrieves the unique attribute fields for each product category and constructs a secondary header array, significantly improving the efficiency of header expansion and avoiding the tedious manual configuration of multiple product category fields. Simultaneously, centralized database management ensures field standardization and maintainability, enhancing the system's adaptability to adding new product categories.

[0009] According to at least one embodiment of this disclosure, a second table template is obtained by combining a secondary header array and a first table template, including: merging the secondary header array with the primary header of the first table template to generate an extended header; generating a second table template based on the extended header; wherein the primary header of the first table template contains basic header fields.

[0010] According to the above scheme, the secondary header array is merged with the primary header to generate an extended header, and a second table template is generated accordingly. This improves the adaptability and scalability of the template, and allows for the dynamic integration of unique fields according to different product categories without the need for multiple manual adjustments to the template structure. At the same time, by inheriting the basic header fields, the standardization and consistency of the table are ensured, improving the accuracy and efficiency of data import.

[0011] According to at least one embodiment of this disclosure, importing cell data from a table file into a second table template based on the correspondence between the table file and the second table template includes: semantically matching the header fields of the table file with the header fields of the extended header of the second table template to generate a header matching result containing a matching degree value and a matching relationship; determining a corresponding filling strategy based on the matching degree value and the header type; and importing cell data from the table file into the second table template according to the filling strategy.

[0012] According to the above solution, matching results are generated through semantic matching, and the filling strategy is dynamically determined based on the matching degree value and the header type. This can automatically handle the problem of inconsistent supplier headers without full manual intervention. At the same time, the strategy-based execution ensures the flexibility and robustness of the filling process and improves the efficiency of importing complete multi-category data. In addition, the strategy can be adaptively adjusted according to the matching degree, reducing data errors and optimizing user interaction, ultimately improving the overall reliability and speed of supply chain commodity information processing.

[0013] According to at least one embodiment of this disclosure, a corresponding filling strategy is determined based on the matching degree value and the header type; and cell data in the table file is imported into the second table template according to the filling strategy, including: when the header type is a first-level header and the matching degree value is greater than or equal to a first preset threshold, the filling strategy is determined to be direct filling, and the cell data is imported into the corresponding first-level header field in the second table template; after the first-level header field is filled, a set of second-level header fields related to the category field in the table file is determined from the second-level header array of the second table template; based on the set of second-level header fields, row-by-row saturation filling is performed on the second-level header fields in the second table template.

[0014] According to the above scheme, the filling strategy is determined based on the matching degree value and the header type, and combined with the row-by-row saturation filling mechanism, the accuracy and completeness of data import are improved. It can prioritize the processing of high matching first-level fields, and the dynamic saturation filling of second-level fields can avoid data loss or confusion.

[0015] According to at least one embodiment of this disclosure, saturation filling is performed on the secondary header fields in the second table template based on the secondary header field set, including: traversing each row of data in the second table template; for the current row of data, obtaining the category field value representing the product category in the row of data; determining the product category to which the row of data belongs based on the category field value; extracting the set of secondary header fields related only to the product category from the secondary header array; importing the cell data in the table file that matches the set of secondary header fields into the corresponding secondary header positions in the second table template; and forcibly setting all secondary header field positions in the second table template that are not in the set of secondary header fields to empty.

[0016] According to the above scheme, the row-by-row traversal and dynamic extraction of secondary field sets based on product category, combined with matching import and forced emptying, improve the targeting and completeness of the filling process. It can ensure that each row of data is only saturated with the fields corresponding to its product category, while isolating irrelevant parts and avoiding errors caused by confusion of multiple product categories.

[0017] According to at least one embodiment of this disclosure, importing cell data matching the set of secondary header fields in a table file into the corresponding secondary header position in a second table template includes: when the matching degree value is greater than a first preset threshold, performing a data filling operation for complete matching; when the matching degree value is greater than a second preset threshold and less than or equal to the first preset threshold, displaying an import control in the second table template, and responding to the user's selection operation on the import control, performing the import of cell data or rejecting the import of cell data; when the matching degree value is less than or equal to the second preset threshold, not performing a data filling operation; wherein, the first preset threshold is greater than the second preset threshold.

[0018] According to the above scheme, the relevance of the secondary header field to the product category is first determined to decide whether to set it to null. If there is a relevance, the filling strategy is further selected based on the matching degree value. This two-step progressive judgment and filling mechanism significantly improves the accuracy and security of data processing, automatically isolates irrelevant fields, and hierarchically controls the import of relevant fields, avoiding the accumulation of errors caused by blind filling. In addition, threshold grading and user control interaction enhance the flexibility and controllability of the filling process, allowing for the integration of manual judgment to optimize accuracy when the matching degree is moderate.

[0019] According to at least one embodiment of this disclosure, identifying at least one category field corresponding to the first-level header row of a table file and constructing a category field set includes: identifying the header row of the first n rows of the table file based on header row features and determining the index value of the header row, where n is a preset positive integer; extracting the header fields of the table file based on the index value of the header row; extracting category fields from the header fields and constructing a category field set; wherein the category field set includes one category or multiple distinct categories.

[0020] According to the above solution, the identification of the first n rows based on the header row features, index extraction, and category deduplication construction improve the automation and accuracy of processing various formats of supplier spreadsheet files. It can quickly locate and summarize category information without manual intervention on multiple rows of data. By combining the preset n and feature rules, the robustness and efficiency of identification are improved, adapting to different spreadsheet file formats and reducing the complexity of supply chain management.

[0021] According to another aspect of this disclosure, an electronic device is provided, comprising: a memory storing execution instructions; and a processor executing the execution instructions stored in the memory, causing the processor to perform a method according to any embodiment of the first aspect of this disclosure.

[0022] According to another aspect of this disclosure, a readable storage medium is provided, wherein executable instructions are stored therein, which, when executed by a processor, are used to implement the method of any embodiment of the first aspect of this disclosure.

[0023] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements the method of any of the embodiments described in the first aspect of this disclosure. Attached Figure Description

[0024] The accompanying drawings illustrate exemplary embodiments of the present disclosure and, together with the description thereof, serve to explain the principles of the present disclosure. These drawings are included to provide a further understanding of the present disclosure and are incorporated in and constitute a part of this specification.

[0025] Figure 1 This is a schematic flowchart of the table file processing method proposed in the embodiments of this disclosure.

[0026] Figure 2 This is a flowchart illustrating the method for determining the secondary header array provided in an embodiment of this disclosure.

[0027] Figure 3 A flowchart illustrating the second table template generation method provided in this embodiment of the disclosure.

[0028] Figure 4 This is a flowchart illustrating the cell data import method provided in an embodiment of the present disclosure.

[0029] Figure 5 This is a schematic diagram of the process for importing a second table template according to an embodiment of this disclosure.

[0030] Figure 6 This is a flowchart illustrating a two-level header filling method provided for a disclosed embodiment.

[0031] Figure 7 This is a flowchart illustrating the secondary header matching and filling method provided in this embodiment of the disclosure.

[0032] Figure 8 This is a flowchart illustrating the method for constructing a set of category fields provided in an embodiment of this disclosure.

[0033] Figure 9 This is a schematic block diagram of the structure of a form document processing apparatus according to one embodiment of the present disclosure.

[0034] Figure 10 This is a schematic block diagram of an electronic device according to one embodiment of the present disclosure. Detailed Implementation

[0035] The present disclosure will now be described in further detail with reference to the accompanying drawings and examples. It should be understood that the specific examples described herein are for illustrative purposes only and are not intended to limit the scope of the disclosure. Furthermore, it should be noted that, for ease of description, only the parts relevant to the present disclosure are shown in the accompanying drawings.

[0036] It should be noted that, where there is no conflict, the embodiments and features described in this disclosure can be combined with each other. The technical solutions of this disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0037] With the widespread adoption of e-office tools, many applications are no longer limited to completing tasks using offline spreadsheets. For example, in e-commerce or supply chain management, different suppliers have their own product list spreadsheets. Moreover, the formats and content of these spreadsheets vary, requiring manual breakdown and organization based on experience to conform to online spreadsheet requirements. This task consumes significant manpower and time. If the spreadsheets are complex, containing multi-level headers, it places even higher demands on staff's ability to identify and categorize product attributes. Furthermore, standardizing and converting spreadsheet formats will also take even longer.

[0038] Therefore, this disclosure proposes a method for processing tabular files. In practical applications, this tabular processing method can be executed by a local server or a cloud server.

[0039] It should be noted that, where there is no conflict, the embodiments and features described in this disclosure can be combined with each other. The technical solutions of this disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0040] Figure 1 This is a flowchart illustrating the table file processing method proposed in an embodiment of this disclosure. Figure 1 The method shown includes steps 101 to 105. This method can be executed by an electronic device (such as a local computer, cloud server, etc.).

[0041] Specifically, Figure 1 The method shown includes step 101: obtaining a user-provided table file containing cell data and a first table template containing standard table headers.

[0042] It's important to note that the spreadsheet files mentioned here are typically offline Excel files or similar spreadsheets uploaded by suppliers, containing multiple rows of product data such as brand, category, specifications, and price. These data may have inconsistent headers depending on the supplier. The first spreadsheet template mentioned here is a pre-defined online standard spreadsheet template with fixed basic header fields, used for standardized structured management of product information. By obtaining these inputs, this method ensures that subsequent processing is based on a reliable data source and a standard framework, avoiding the complexity of building a template from scratch.

[0043] Next, we need to import the different spreadsheet files provided by users (potentially multiple different users) into the online standard spreadsheet. The following steps will detail the process of importing different spreadsheets.

[0044] Step 102: Identify at least one category field corresponding to the first-level header row of the table file, and construct a category field set.

[0045] In practical applications, the index position of the header rows is determined by analyzing the first few rows (e.g., the first 5 rows) of the table file and using pre-defined header recognition rules (such as including descriptive text, not containing pure numbers or null values, and ensuring that each column contains unique content). For example, an AI model can be used to extract features and calculate the index for the row data. Then, category fields related to the product category are extracted from the identified header rows, such as "product category," "category," or "product type." These category fields represent the classification to which the product belongs (e.g., flooring, paint, etc.). Finally, the extracted unique category fields are aggregated into a set (it should be noted that if there are duplicate entries in the extracted category fields, deduplication is required). This set of category fields may contain a single category or multiple distinct categories, thus providing a basis for subsequent dynamic expansion. This recognition process ensures accurate capture of category information even if the table files provided by suppliers vary in format (i.e., have completely different header formats), avoiding the inefficiency of manual parsing.

[0046] Step 103: Determine the corresponding secondary header array based on the category field set.

[0047] In practical applications, a query request containing a set of category fields is sent to a pre-configured database. This database stores the unique attribute fields for each category (e.g., for the "flooring" category, this might include "tree species name" and "surface layer process"). After the database returns a list of unique fields for each category, these fields are further combined into a secondary header array, for example, organized as a JSON array. This ensures that the array covers all extended fields for all categories in the set, without repeating common fields. This determination process enables dynamic adaptability of the header, automatically generating extended parts based on the actual category, thus improving processing flexibility.

[0048] It's important to note that the second-level headers mentioned here are in contrast to the first-level headers. If multiple different products are involved, multiple second-level headers will be set under the first-level header. For example, the first-level header might be "Products," and the second-level headers could be "Flooring" and "Paint." Furthermore, second-level headers in a spreadsheet file can be on different rows within the same column (the same column as the header column). Of course, multiple second-level headers can also be on different rows.

[0049] Step 104: Combine the second-level header array and the first table template to obtain the second table template.

[0050] In practical applications, the content of cell data in spreadsheet files, such as product categories, is diverse and uncertain. The content provided by the first spreadsheet template is only basic and may not fully match all cell data in the spreadsheet file. Therefore, to better meet the import requirements of cell data, the first spreadsheet template is modified to create a second spreadsheet template. The specific process is as follows: The second-level header array is merged with the first-level header (i.e., basic header fields, such as "brand" and "purchase price") of the first spreadsheet template to form an extended header, for example, by appending the second-level fields after the sales specifications column or as a sub-level. Then, the second spreadsheet template is generated based on this extended header. This template inherits the structure of the first template and extends the category-specific fields, thus forming a complete online spreadsheet framework that supports multi-category product information. This combination process ensures the standardization and personalization of the template, facilitating subsequent data import.

[0051] Step 105: Based on the correspondence between the table file and the second table template, import the cell data from the table file into the second table template.

[0052] In practical applications, semantic matching is used to calculate the correspondence between the header fields of the table file and the extended header of the second table template. For example, an AI model is used to evaluate the field matching degree (1.0 for perfect match, 0.5-1.0 for semantic similarity, and 0 for no match). Then, data filling is performed based on the matching results. For example, for fields with high matching degree, the cell data in the table file is directly mapped row by row to the corresponding position in the second table template to ensure data alignment and integrity. For multi-category rows, the filling of extended fields can also be processed row by row. This import process achieves seamless conversion from diverse table file source data to standard templates, reducing data loss or errors and improving data import efficiency. The specific matching and import process will be described in detail in subsequent embodiments and will not be repeated here.

[0053] Based on the publicly available solutions described above, dynamically identifying category fields and constructing a secondary header array automatically expands the standard template to adapt to the import of product information from multiple suppliers and product categories. This significantly improves processing efficiency and avoids the time-consuming and labor-intensive process of traditional manual mapping. Simultaneously, through precise matching of correspondences and data import, it ensures data accuracy and integrity, enhancing the standardization level of supply chain management. It can also handle table files with inconsistent headers without additional configuration, making it suitable for large-scale, multi-category product data operation scenarios, ultimately reducing operating costs and improving user experience.

[0054] In one or more embodiments of this disclosure, such as Figure 2 This is a flowchart illustrating the method for determining the secondary header array provided in an embodiment of this disclosure. Figure 2As shown, step 103, determining the corresponding secondary header array based on the category field set, includes: Step 1031: Sending a field request to a pre-configured first database based on the category field set. Step 1032: Obtaining the unique attribute fields corresponding to each category in the category field set returned by the first database as secondary header fields. Step 1033: Constructing a secondary header array using the secondary header fields corresponding to the category field set.

[0055] The category field set mentioned here is a unique list of categories extracted from the header rows of a spreadsheet file. For example, it might include multiple categories such as "flooring" and "paint." This field request can encapsulate the category set in JSON format and transmit it to a primary database via an API interface or query statement (such as an SQL SELECT). This database pre-stores the attribute mapping relationships for each category. For example, a relational database table might use the category name as the key and associate it with a list of unique attribute fields, thus ensuring that the request can efficiently retrieve relevant data.

[0056] Furthermore, the system receives response data from the database. This response may be a structured array or object. For example, for the "flooring" category, the returned response might include specific attribute fields such as "tree species name," "surface layer process," and "environmental protection level." These fields are category-specific extended attributes, not general basic fields. In actual processing, categories in the collection can be processed one by one, ensuring that each category has an independent list of fields. If a category lacks a corresponding field, an empty list or default value can be returned to avoid processing interruption. Through this feedback mechanism, this step achieves comprehensive coverage of category diversity, avoiding the limitations of hard-coded fields.

[0057] All unique attribute fields retrieved from the database are organized into a unified array structure by category. This can be achieved using a programming language (such as JavaScript or Python) to merge the field list into a deduplicated multidimensional array or nested JSON object, where each element contains a category identifier and its associated field list, ensuring the array is ordered and free of redundancy. During the construction process, metadata such as field types or required field flags can be added to enhance the compatibility of subsequent template combinations, resulting in an array that can be directly used to expand table headers.

[0058] Based on the publicly available solutions described above, utilizing a pre-configured database for field requests and responses automatically retrieves the unique attribute fields for each product category and constructs a secondary header array, significantly improving the efficiency of header expansion and avoiding the tedious manual configuration of multiple product category fields. Simultaneously, centralized database management ensures field standardization and maintainability, enhancing the system's adaptability to adding new product categories. Furthermore, it enables rapid response to requests when processing large-scale supplier data, reducing latency and ultimately optimizing the overall import process performance and lowering the error rate.

[0059] In one or more embodiments of this disclosure, such as Figure 3 This is a flowchart illustrating the second table template generation method provided in this embodiment of the disclosure. Figure 3 As shown, step 104, which involves combining the secondary header array and the first table template to obtain the second table template, includes: Step 1041: Merging the secondary header array with the primary header of the first table template to generate an extended header. Step 1042: Generating the second table template based on the extended header; wherein, the primary header of the first table template contains basic header fields.

[0060] In practical applications, the secondary header array is merged with the primary header of the first table template (which is an online standard table template) to form an extended header specifically designed to meet the import requirements of the table file. The secondary header array refers to a list of category-specific attribute fields determined from the category field set, such as dynamic fields like "tree species name" and "surface layer process." The first table template is a pre-defined online table framework whose primary header contains basic header fields, such as general fields like "brand," "category," and "purchase price," applicable to all product types. During the merging process, programming logic (such as in JSON configuration) can be used to append the second-level header array to the end of the first-level header or as a sub-level. For example, if the first-level header is [Brand, Category, Purchase Price], and the corresponding second-level header array is [Tree Species Name, Surface Finish], then the extended header may generate [Brand, Category, Purchase Price, Tree Species Name, Surface Finish]. This ensures that the merging is free of redundancy and maintains the logical order of the fields. At the same time, a hierarchy identifier can be added to distinguish between the first-level and second-level parts, thus forming a unified extended header structure.

[0061] Using extended headers as a template, a header framework renders or instantiates a new table instance—the second table template—within the online table system. For example, table components can be dynamically generated using front-end frameworks (such as React or Vue), or table objects can be created using back-end services (such as Node.js or Java). This generation process ensures that the second table template inherits the overall layout and style of the first table template, while incorporating extended fields from the second-level header array to form a complete table that supports multiple rows of data. If the extended headers involve a multi-level structure, merged cells or nested header rendering can be applied to visually display the hierarchical relationship between the first-level basic fields and the second-level category-specific fields, thus completing the construction of the second table template.

[0062] Based on the publicly available solutions, merging the secondary header array with the primary header array to generate an extended header array, and then generating a second table template accordingly, improves the adaptability and scalability of the template. It can dynamically incorporate unique fields according to different product categories without having to manually adjust the template structure multiple times. At the same time, by inheriting the basic header fields, it ensures the standardization and consistency of the table, and improves the accuracy and efficiency of data import.

[0063] In one or more embodiments of this disclosure, such as Figure 4 This is a flowchart illustrating the cell data import method provided in an embodiment of this disclosure. Figure 4 As shown, step 105, which involves importing cell data from the table file into the second table template based on the correspondence between the table file and the second table template, includes: Step 1051: Semantically matching the header fields of the table file with the header fields of the extended header of the second table template to generate a header matching result containing matching degree values ​​and matching relationships. Step 1052: Determining the corresponding filling strategy based on the matching degree values ​​and header types; and importing cell data from the table file into the second table template according to the filling strategy.

[0064] In practical applications, the header fields of a table file (usually a fixed template from a supplier) are semantically matched with the header fields of the extended header of a second table template to generate a header matching result containing matching scores and matching relationships. The header fields of the table file are a list of fields extracted from an Excel or similar file provided by the supplier, such as "product category," "brand," and "market price."

[0065] The extended header of the second table template is the complete header obtained from the previous combination, including primary basic fields and secondary category-specific fields. During semantic matching, an AI model (such as a natural language processing-based similarity algorithm) can be used to compare fields one by one. For example, two header arrays are input into the AI ​​model, which evaluates a perfect match (same field name, match score 1.0), semantic similarity (synonyms or inclusion relationships, match score 0.5-1.0), or no match (match score 0). The output is a JSON-formatted array where each element contains the source field name, the target field name (or -1 indicating no match), and the match score value. For example, [{AField:Brand,BField:Brand,rate:1.0},{AField:Paint,BField:-1,rate:0}], thus establishing precise correspondences between fields and ensuring that the results cover all potential matches to support subsequent data filling.

[0066] After obtaining the matching results, the header types are categorized. For example, the first-level header consists of general basic fields (such as "Brand" and "Category"), while the second-level header consists of category-specific extended fields (such as "Tree Species Name"). Then, an appropriate fill strategy is set based on the matching score (three strategies: direct fill, user-selective fill, and reject fill). For example, if the matching score is greater than or equal to a preset threshold (such as 0.8), the fill strategy is direct fill; if the matching score is between a lower threshold (such as 0.5-0.8), the fill strategy is user-selectable fill; if the matching score is below the threshold (such as 0.5), the strategy is skip or manual intervention.

[0067] When performing the fill operation, the data rows of the table file are traversed row by row. For matching fields, the source cell data is mapped to the corresponding position in the second table template. For example, values ​​are copied column by column and data type compatibility is ensured (such as number formatting). When processing rows with multiple categories, first-level fill is performed first, and then second-level saturation fill is triggered to complete the entire import process.

[0068] Based on the publicly available solutions described above, generating matching results through semantic matching and dynamically determining the filling strategy based on the matching degree value and header type can automatically handle supplier header inconsistencies without requiring full manual intervention. At the same time, the strategy-based execution ensures the flexibility and robustness of the filling process, improving the efficiency of importing complete multi-category data. Furthermore, the strategy can adaptively adjust based on the matching degree, reducing data errors and optimizing user interaction, ultimately improving the overall reliability and speed of supply chain commodity information processing.

[0069] In one or more embodiments of this disclosure, such as Figure 5 This is a schematic diagram illustrating the process of importing a second form template according to an embodiment of this disclosure. Figure 5 As shown, step 1052: determining the corresponding fill strategy based on the matching degree value and the header type; and importing cell data from the table file into the second table template according to the fill strategy, includes: Step 501: when the header type is a first-level header and the matching degree value is greater than or equal to a first preset threshold, the fill strategy is determined to be direct fill, and the cell data is imported into the corresponding first-level header field in the second table template. Step 502: after completing the filling of the first-level header field, the set of second-level header fields related to the category field in the table file is determined from the second-level header array of the second table template. Step 503: based on the set of second-level header fields, row-by-row saturation fill is performed on the second-level header fields in the second table template.

[0070] It should be noted that the saturation filling mentioned here refers to ensuring that all secondary header fields related to the product category in the current row are fully filled (if there is no corresponding data, default values ​​or empty values ​​are used to fill in), while unrelated secondary header fields are forcibly left empty. This achieves standardization and non-redundant integration of multi-category product information, effectively avoiding or reducing incorrect or missing entries.

[0071] In practical applications, when the header type is a first-level header and the matching score is greater than or equal to the first preset threshold, the fill strategy is determined to be direct fill, and the cell data is imported into the corresponding first-level header field in the second table template. First-level header types refer to general basic fields (such as "Brand," "Category," "Purchase Price," etc.), which do not depend on a specific category. The first preset threshold can be set to a high value, such as 0.8 or 1.0, to ensure high-confidence matching. After determining the fill strategy, the direct fill operation is performed, including traversing all data rows in the table file. For each matching field pair, cell data (such as text, number, or date values) is extracted from the corresponding column in the source table file and copied row by row to the corresponding first-level field position in the second table template. For example, if the "Brand" field has a matching score of 1.0, all row values ​​from the source column are directly mapped there. Simultaneously, data type conversion (such as string normalization) is handled to avoid formatting errors, ensuring that the first-level fill is completed as the basic framework, providing the necessary category context for subsequent second-level processing. If the calculated matching score for a first-level header is less than or equal to the second threshold (e.g., 0.5), it indicates a no-match, and the filling strategy is to not fill it. If the calculated matching score for a first-level header falls between the first and second thresholds, the user can selectively decide whether to fill it.

[0072] After populating the first-level header fields, the set of second-level header fields related to the category fields in the table file is determined from the second-level header array of the second table template. Specifically, first, it is confirmed that the category field values ​​(such as the sales specification column) have been successfully imported from the first-level population. These values ​​represent the category to which each row of products belongs (such as "flooring" or "paint"). Then, relevant subsets are extracted from the previously constructed second-level header array (a structured list containing category-specific fields). For example, for the populated category value "flooring", the array is queried to obtain its associated fields such as "tree species name", "surface coating process", "environmental protection level", etc., forming a targeted set. This set only contains the category fields actually involved in the current table file, avoiding irrelevant expansion; that is, all second-level header fields in the set are fields that conform to the specific attributes of the product category, or in other words, are second-level header fields related to the product category.

[0073] Based on the set of secondary header fields obtained from the previous matching, row-by-row saturation filling is performed on the secondary header fields in the second table template. Specifically, all data rows of the second table template are traversed row by row. For each row, the already filled category field value is first read to confirm the product category. Then, fields matching the product category are selected from the set of secondary header fields, and it is further determined whether there is semantically matching corresponding cell data in the table file (such as the rate value based on the previous matching result). If a match exists, the source cell data is directly imported into the corresponding position of the current row in the second table template, for example, the value of the "tree species name" column is copied over. If there is no match or the matching degree is low, preset default values ​​(such as empty values ​​or "unknown") are filled to ensure field saturation, that is, all relevant secondary fields are fully processed, while irrelevant field positions are forcibly set to empty to avoid data redundancy. This process is repeated until all rows are saturated, thereby realizing the comprehensive import of multi-category data. The specific implementation process of saturation filling will be described in detail in subsequent embodiments, and will not be repeated here. Please refer to the subsequent embodiments for details.

[0074] Based on the publicly available solutions mentioned above, it is known that determining the filling strategy based on the matching degree value and the header type, combined with the row-by-row saturation filling mechanism, improves the accuracy and completeness of data import. It can prioritize the processing of high-matching first-level fields, and the use of dynamic saturation filling of second-level fields can avoid data loss or confusion.

[0075] In one or more embodiments of this disclosure, such as Figure 6 This is a flowchart illustrating a two-level header filling method provided for a disclosed embodiment. Figure 6 As shown, step 503, which involves performing saturation filling on the secondary header fields in the second table template based on the secondary header field set, includes: Step 5031: Traversing each row of data in the second table template. Step 5032: For the current row of data, obtaining the category field value representing the product category in that row. Step 5033: Determining the product category to which the row of data belongs based on the category field value. Step 5034: Extracting a set of secondary header fields related only to the product category from the secondary header array. Step 5035: Importing the cell data from the table file that matches the set of secondary header fields into the corresponding secondary header positions in the second table template. Step 5036: Forcibly setting all secondary header field positions in the second table template that are not in the set of secondary header fields to empty.

[0076] In practical applications, when filling in the second-level header, each row of data in the second table template is traversed. The second table template has already completed the first-level header filling and contains multiple rows of product information. The traversal process can start from the first row and iterate row by row. For example, a loop structure (such as a for loop) can be used to scan all rows to ensure that the entire table is covered without missing any data rows.

[0077] Further, locate the category field in the current row (this field was imported in the first-level population stage and is usually a sales specification column), and read its specific value. For example, if the value is "flooring," it means that the products in this row belong to the flooring category. Data validation can be applied during the reading process, such as checking whether the value is empty or valid. If it is empty, the row can be skipped or the default category can be filled to maintain the continuity of processing. This retrieval step relies on the results of the first-level population to ensure that the product category information is available and serves as the trigger point for the second-level processing.

[0078] By parsing the read values ​​and mapping them to standard product category definitions, for example, using string matching or enumeration checks to confirm "flooring" as a predefined product category, and if the value contains variations (such as "solid wood flooring"), normalization logic (such as keyword extraction) can be applied to standardize it to the core category. This determination process ensures that the category classification of each row of data is accurate, providing a precise context for subsequent field extraction and avoiding cross-category confusion.

[0079] The algorithm queries the previously constructed secondary header array (a structured list, such as a JSON object with product category as the key), filters out a subset of fields that match the current product category. For example, for the "flooring" category, it extracts unique fields such as "tree species name," "surface layer process," and "environmental protection level" to form a temporary secondary header field set. This secondary header field set excludes other fields irrelevant to the product category, ensuring that the extracted results are compact and highly targeted. If the product category has no corresponding field, an empty set is returned.

[0080] For each secondary field in the current row, a match is found in the previously generated header matching results. If the match score meets the first threshold (e.g., greater than 0.8), cell data is extracted from the corresponding column and current row position in the table file and copied to the current row secondary position in the second table template. For example, cell data from the "Tree Species Name" column in the source table file is imported into the "Tree Species Name" field at the corresponding position of the target secondary header in the second table template, while handling data conversion (e.g., unit unification or null value filling) to ensure compatibility. If no match is found, the data is left blank or filled with default values ​​according to the filling strategy. This import process ensures accurate filling of relevant data. Specifically, all secondary header fields in the current row are scanned, and fields that do not belong to the set of extracted secondary header fields (e.g., extended fields of other categories) are identified and set to null values ​​(e.g., null or empty strings). For example, if the category of the current row is "Flooring," the "Paint Type" (paint category field) position is left blank. This forced blanking mechanism prevents irrelevant data filling, ensuring that each row only contains the information required for its category, avoiding data redundancy or chaos.

[0081] Based on the publicly available solutions mentioned above, it is known that traversing by row and dynamically extracting the set of secondary fields based on product categories, combined with matching import and forced emptying, improves the targeting and completeness of the filling process. This ensures that each row of data is only saturated with the fields corresponding to its product category, while isolating irrelevant parts and avoiding errors caused by confusion between multiple product categories.

[0082] In one or more embodiments of this disclosure, such as Figure 7 This is a flowchart illustrating the secondary header matching and filling method provided in this embodiment of the disclosure. Figure 7 As shown, step 5035, importing cell data matching the set of secondary header fields in the table file into the corresponding secondary header position in the second table template, includes: Step 50351: When the matching degree value is greater than the first preset threshold, perform a data filling operation for complete matching. Step 50352: When the matching degree value is greater than the second preset threshold and less than or equal to the first preset threshold, display an import control in the second table template, and in response to the user's selection operation of the import control, perform the import of cell data or refuse to import cell data. Step 50353: When the matching degree value is less than or equal to the second preset threshold, do not perform a data filling operation; wherein, the first preset threshold is greater than the second preset threshold.

[0083] In practical applications, when filling fields belonging to the set of secondary header fields, it is necessary to further select the appropriate filling strategy based on the matching degree value before filling. Specifically, for the current row of data, based on the previously extracted set of secondary header fields, the relevance of each secondary header field to the product category is determined. For example, it checks whether the field belongs to the unique attribute list of the current row's category value (such as "flooring"). If it is not relevant (such as belonging to an extended field of other categories), the position of that field in the second table template is directly forced to be empty (such as null or an empty string) to prevent cross-category data pollution or incorrect filling. If it is relevant, it further enters the matching degree value evaluation stage. When the matching degree value is greater than the first preset threshold, a data filling operation of complete matching is performed. The first preset threshold can be set to 1.0, indicating that the field names are completely consistent. During execution, cell data (such as numbers, text, or dates) is extracted from the corresponding column and current row position in the table file and directly imported into the corresponding secondary position in the second table template. At the same time, data cleaning is performed (such as removing extra spaces or converting units) to ensure seamless integration and avoid any manual intervention.

[0084] When the matching score is greater than the second preset threshold and less than or equal to the first preset threshold, an import control is displayed in the second table template. In response to the user's selection of the import control, the system either imports cell data or rejects the import. The second preset threshold can be set to 0.5, representing cases where the semantics are similar but have subtle differences (such as abbreviations or synonyms). The displayed import control can be a graphical interface element, such as a pop-up confirmation box or hover tooltip, containing a preview of the source data, a matching score, and a description of potential differences. The user makes a decision by clicking the "Confirm" or "Reject" button. If confirmed, the source cell data is imported into the target location, and optionally, a log is recorded for auditing. If rejected, the location is left empty or retains a default value. This response mechanism introduces user verification to ensure reliable filling of cells with moderate matching scores.

[0085] When the matching score is less than or equal to the second preset threshold, no data filling operation is performed. For example, the import of the field is skipped directly, and the position in the second table template is kept empty or filled with a preset placeholder (such as "N / A") to eliminate errors that may be caused by low confidence matching. The first preset threshold is greater than the second preset threshold, forming a progressive hierarchical framework to ensure that high matching is processed automatically with priority and low matching is strictly excluded.

[0086] Based on the publicly available solutions, the mechanism of first determining whether to set a second-level header field to null depends on its relevance to the product category. If relevance is found, a further filling strategy is selected based on the matching degree. This two-step progressive judgment and filling mechanism significantly improves the accuracy and security of data processing. It can automatically isolate irrelevant fields and hierarchically control the import of relevant fields, avoiding the accumulation of errors caused by blind filling. Furthermore, threshold grading and user control interaction enhance the flexibility and controllability of the filling process, allowing for the incorporation of manual judgment to optimize accuracy when the matching degree is moderate.

[0087] In one or more embodiments of this disclosure, such as Figure 8 This is a flowchart illustrating a method for constructing a set of category fields provided in an embodiment of this disclosure. Figure 8 As shown, step 102, which involves identifying at least one category field corresponding to the first-level header row of the table file and constructing a category field set, includes: Step 1021: Identifying the header row of the first n rows of the table file based on header row features, and determining the index value of the header row, where n is a preset positive integer. Step 1022: Extracting the header fields of the table file based on the index values ​​of the header rows. Step 1023: Extracting category fields from the header fields and constructing a category field set; wherein the category field set includes one or more distinct categories.

[0088] In practical applications, the first n rows of a table file are identified based on header row features to determine their index values, where n is a preset positive integer. For example, n can be set to 5 to cover the beginning of a typical table. Header row features include rules such as containing descriptive text (e.g., words like "name" or "date"), not containing pure numbers (e.g., 123) or null values, and each column having distinct content (no duplicate headers). The identification process can utilize AI models or algorithms to analyze the first n rows of data. For example, a JSON string of input row data can be entered into a preset command, and the feature matching degree can be evaluated row by row. If a row meets all the rules, its 0-based index value (e.g., between 0 and 4) is returned; if it cannot be determined, null is returned, and a backup manual mode can be triggered. This identification step ensures accurate location of header rows even if the supplier's template rules are uncertain, avoiding the inefficiency of blindly scanning the entire file.

[0089] Furthermore, a specific index value (e.g., index 1, indicating the second row) can be used to locate the corresponding row in the table file, and then the cell contents of that row can be read column by column as a list of header fields. For example, if the row data is [serial number, product category, brand, tree species name, surface process], it can be extracted into a string array. During extraction, potential merged cells or empty columns should be handled (e.g., ignoring null values ​​or filling placeholders), and cleaning logic (e.g., removing leading and trailing spaces or converting to lowercase) can be applied to standardize field names.

[0090] The process involves extracting category fields from the header fields and constructing a category field set, which includes one or more distinct categories. Specifically, the extracted header field list is scanned to identify categories-related fields. For example, keywords such as "category," "product category," and "sales specifications" are matched; if multiple matches exist, the most accurate one is selected. Then, all data rows in the table file (below the header row) are traversed, collecting values ​​from the category field columns and removing duplicates. For instance, a set data structure (such as a Set) is used to store unique values, such as collecting values ​​for flooring, paint, and tiles, forming a unique category field set. If there is only one category, the set size is 1. This construction process ensures the integrity and uniqueness of the set.

[0091] Based on the publicly available solutions described above, the identification of the first n rows based on header row features, index extraction, and category deduplication improves the automation and accuracy of processing various formats of supplier spreadsheet files. It enables rapid location and aggregation of category information without manual intervention across multiple rows of data. By combining preset n with feature rules, the robustness and efficiency of the identification are enhanced, adapting to different spreadsheet file formats and reducing the complexity of supply chain management.

[0092] After obtaining the second table template by combining the second-level header array and the first table template, the process also includes storing the second table template in the template library.

[0093] Based on any of the above embodiments, this disclosure also provides a tabular file processing apparatus. Figure 9 This is a schematic block diagram of a form document processing apparatus according to one embodiment of this disclosure. Figure 9 As shown, the table file processing device includes: an acquisition module 91, used to acquire a table file containing cell data provided by a user, and a first table template containing standard table headers; a construction module 92, used to identify at least one category field corresponding to the first-level header row of the table file, and construct a category field set; a determination module 93, used to determine the corresponding second-level header array based on the category field set; a combination module 94, used to combine the second-level header array and the first table template to obtain a second table template; and an import module 95, used to import cell data from the table file into the second table template according to the correspondence between the table file and the second table template.

[0094] The determination module 93 is used to send field requests to a pre-configured first database based on the category field set; obtain the unique attribute fields corresponding to each category in the category field set returned by the first database as secondary header fields; and construct a secondary header array using the secondary header fields corresponding to the category field set.

[0095] The combination module 94 is used to merge the secondary header array with the primary header of the first table template to generate an extended header; and to generate a second table template based on the extended header; wherein the primary header of the first table template contains the basic header fields.

[0096] Import module 95 is used to semantically match the header fields of the table file with the header fields of the extended header of the second table template, and generate a header matching result containing the matching degree value and the matching relationship; based on the matching degree value and the header type, the corresponding filling strategy is determined; and the cell data in the table file is imported into the second table template according to the filling strategy.

[0097] Import module 95 is used to determine the filling strategy as direct filling when the header type is a first-level header and the matching degree value is greater than or equal to the first preset threshold, and import the cell data into the corresponding first-level header field in the second table template; after completing the filling of the first-level header field, it determines the set of second-level header fields related to the category field in the table file from the second-level header array of the second table template; based on the set of second-level header fields, it performs row-by-row saturation filling on the second-level header fields in the second table template.

[0098] Import module 95 is used to traverse each row of data in the second table template; for the current row of data, it retrieves the category field value representing the product category in the row; based on the category field value, it determines the product category to which the row of data belongs; it extracts the set of second-level header fields that are only related to the product category from the second-level header array; it imports the cell data in the table file that matches the set of second-level header fields into the corresponding second-level header positions in the second table template; and it forces all second-level header field positions in the second table template that are not in the set of second-level header fields to be empty.

[0099] Import module 95 is used to perform a data filling operation for a complete match when the matching degree value is greater than the first preset threshold; when the matching degree value is greater than the second preset threshold and less than or equal to the first preset threshold, an import control is displayed in the second table template, and in response to the user's selection operation of the import control, the import of cell data is performed or the import of cell data is rejected; when the matching degree value is less than or equal to the second preset threshold, no data filling operation is performed; wherein, the first preset threshold is greater than the second preset threshold.

[0100] Module 92 is used to identify the first n rows of a table file based on the header row features, determine the index value of the header row, where n is a preset positive integer; extract the header fields of the table file based on the index value of the header row; extract the category fields from the header fields and construct a category field set; wherein the category field set includes one category or multiple distinct categories.

[0101] The specific implementation process of the functions and roles of each module in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0102] The executing entity of the distributed lock allocation method in the specific embodiments of this disclosure can be an electronic device such as a server (including a local server or a cloud computing platform).

[0103] Therefore, based on any of the above embodiments, this disclosure also provides an electronic device that can execute the distributed lock allocation method of any of the embodiments described above.

[0104] Figure 10 This is a schematic block diagram of an electronic device according to one embodiment of the present disclosure.

[0105] The hardware architecture of the electronic device 1000 can be implemented using a bus architecture. The bus architecture can include any number of interconnect buses and bridges, depending on the specific application of the hardware and overall design constraints. Bus 1100 connects various circuits, including one or more processors 1200, memory 1300, and / or hardware modules. Bus 1100 can also connect various other circuits 1400, such as peripheral devices, voltage regulators, power management circuits, external antennas, etc.

[0106] Bus 1100 can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Component (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, only one connection line is used in this diagram, but this does not imply that there is only one bus or only one type of bus.

[0107] This disclosure also provides a readable storage medium storing a computer program that, when executed by a processor, is used to implement the methods described above. A "readable storage medium" can be any means capable of containing, storing, communicating, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples of a readable storage medium include: an electrical connection with one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and portable read-only memory (CDROM), etc.

[0108] This disclosure also provides a computer program product, the methods of which can be implemented wholly or partially through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented wholly or partially as a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed, all or part of the processes or functions of this disclosure are performed.

[0109] Computer programs or instructions can be stored in a readable storage medium or transferred from one readable storage medium to another. For example, the computer program or instructions can be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The readable storage medium can be any available medium capable of access, or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; an optical medium, such as a digital video optical disc; or a semiconductor medium, such as a solid-state drive. The computer-readable storage medium can be a volatile or non-volatile storage medium, or it can include both volatile and non-volatile types of storage media.

[0110] Those skilled in the art will understand that embodiments of this disclosure can be provided as methods, systems, or computer program products. Therefore, this disclosure can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this disclosure can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0111] This disclosure is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0112] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0113] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0114] In the description of this specification, the references to terms such as "one embodiment / mode," "some embodiments / modes," "example," "specific example," or "some examples," etc., refer to specific features, structures, or characteristics described in connection with that embodiment / mode or example, which are included in at least one embodiment / mode or example of this disclosure. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment / mode or example. Moreover, the specific features, structures, or characteristics described may be combined in any suitable manner in one or more embodiments / modes or examples. Furthermore, without contradiction, those skilled in the art can combine and integrate the different embodiments / modes or examples described in this specification, as well as the features of different embodiments / modes or examples.

[0115] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this disclosure, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0116] Those skilled in the art should understand that the above embodiments are merely for illustrating the present disclosure and are not intended to limit the scope of the disclosure. Those skilled in the art can make other changes or modifications based on the above disclosure, and these changes or modifications still fall within the scope of the present disclosure.

Claims

1. A tabular file processing method characterized by, The method comprises: obtaining a table file provided by a user and containing cell data, and a first table template containing standard table headers; identifying at least one category field corresponding to a first-level table header row of the table file, and constructing a category field set; determining a corresponding second-level table header array based on the category field set; combining the second-level table header array and the first table template to obtain a second table template; based on the correspondence between the table file and the second table template, importing cell data in the table file into the second table template.

2. The table file processing method according to claim 1, characterized by, The determination of the corresponding second-level table header array based on the category field set comprises: sending a field request to a pre-configured first database based on the category field set; obtaining, as second-level table header fields, the specific attribute fields corresponding to each category in the category field set and fed back by the first database; constructing the second-level table header array by using the second-level table header fields corresponding to the category field set.

3. The table file processing method according to claim 1, characterized by, The combination of the second-level table header array and the first table template to obtain a second table template comprises: merging the second-level table header array and the first-level table header of the first table template to generate an extended table header; generating the second table template based on the extended table header; wherein the first-level table header of the first table template contains basic table header fields.

4. The table file processing method according to claim 1, characterized by, The importing of the cell data in the table file into the second table template based on the correspondence between the table file and the second table template comprises: performing semantic matching between the table header fields of the table file and the extended table header of the second table template to generate a table header matching result containing a matching degree value and a matching relationship; determining a corresponding filling strategy based on the matching degree value and the table header type, and importing the cell data in the table file into the second table template according to the filling strategy.

5. The table file processing method according to claim 4, characterized by, The determination of the corresponding filling strategy based on the matching degree value and the table header type; and the importing of the cell data in the table file into the second table template according to the filling strategy, comprise: when the table header type is a first-level table header and the matching degree value is greater than or equal to a first preset threshold, determining that the filling strategy is direct filling, and importing the cell data into the corresponding first-level table header field in the second table template; after completing the filling of the first-level table header field, determining a second-level table header field set related to the category field in the table file from the second-level table header array of the second table template; performing row-by-row saturation filling on the second-level table header fields in the second table template based on the second-level table header field set.

6. The table file processing method according to claim 5, characterized by, The saturation filling of the second-level table header fields in the second table template based on the second-level table header field set comprises: traversing each row of data in the second table template; for the current row of data, obtaining a category field value representing a product category in the row of data; determining the product category to which the row of data belongs based on the category field value; extracting a second-level table header field set related only to the product category from the second-level table header array; Importing cell data in the table file matching the secondary table header field set into corresponding secondary table header positions in the second table template; Forcing all secondary table header field positions in the current row data in the second table template not in the secondary table header field set to be empty.

7. The table file processing method according to claim 1 or 6, characterized by, The importing cell data in the table file matching the secondary table header field set into corresponding secondary table header positions in the second table template comprises: When the matching degree value is greater than a first preset threshold, performing a complete matching data filling operation; When the matching degree value is greater than a second preset threshold and less than or equal to the first preset threshold, displaying an import control in the second table template, and in response to a selection operation of the import control by a user, performing an operation of importing the cell data or rejecting the import of the cell data; When the matching degree value is less than or equal to the second preset threshold, not performing a data filling operation; The first preset threshold is greater than the second preset threshold. Optionally, the identifying at least one category field corresponding to a primary table header row of the table file and constructing a category field set comprises: Performing table header row identification on the first n rows of the table file based on table header row characteristics to determine an index value of the table header row, wherein n is a preset positive integer; Extracting table header fields of the table file based on the index value of the table header row; Extracting category fields from the table header fields and constructing a category field set; wherein the category field set includes one category or multiple categories that are different from each other.

8. An electronic device, comprising: comprise: a memory storing execution instructions; and a processor executing the execution instructions stored in the memory, so that the processor executes the method in any one of claims 1 to 7.

9. A readable storage medium, the readable storage medium storing execution instructions, the execution instructions being executed by a processor to execute the method in any one of claims 1 to 7.

10. A computer program product comprising a computer program, characterized in that, The computer program is executed by a processor to implement the method in any one of claims 1 to 7.

Images