Report establishment method and device, equipment and storage medium

Abstract

The invention discloses a report building method and device, equipment and a storage medium, and relates to the technical field of data processing, and the report building method comprises the following steps: obtaining a report specification document and a user configuration instruction; analyzing the report specification document through a natural language model and a visual technology to generate an initial metadata template frame, and receiving an adjustment operation of a user on the initial metadata template frame through a visual configuration interface to form a target metadata template; the method comprises the following steps: acquiring original metadata through a target data source, and executing multi-dimensional verification on the original metadata to generate standardized report data; and performing report establishment based on the target metadata template and the standardized report data to generate a target report. According to the method, manual coding by professional developers is not needed, a business user can complete report configuration through a visual interface, the communication time of technology and business departments is shortened, and meanwhile, the method adapts to different supervision scenes and data types.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a report building method, apparatus, device and storage medium. Background Technology

[0002] As regulatory requirements become more detailed and dynamically adjusted, the structure, fields, validation rules, and reporting formats of reports need to be frequently adapted. Report building has become a crucial preliminary step in the data reporting process, placing higher demands on versatility, flexibility, and response speed.

[0003] Currently, the mainstream regulatory report building technology in the industry mainly relies on a customized development model of "one case, one code". Developers manually write parsing code for each report or its specific version to realize the parsing and storage of report data. Since all report parsing logic needs to be manually coded, the workload is huge. The report structures of different regulatory agencies are significantly different, and the code cannot be effectively migrated and reused. When new reports or changes in report structure occur, redevelopment is required. At the same time, there are also some low-code reporting tools, but their functions are relatively basic and cannot meet the needs of complex regulatory scenarios. Summary of the Invention

[0004] The main purpose of this application is to provide a report building method, device, equipment and storage medium, which aims to enable business users to complete report configuration through a visual interface without the need for professional developers to manually code, thereby bridging the communication gap between technical and business departments, and adapting to different regulatory scenarios and data types.

[0005] To achieve the above objectives, this application proposes a report building method, the method comprising: Obtain the report specification document and user configuration instructions; The report specification document is analyzed using natural language models and visual technology to generate an initial metadata template framework. The user's adjustment operations on the initial metadata template framework are received through a visual configuration interface to form the target metadata template. The raw metadata is obtained from the target data source, and multi-dimensional validation is performed on the raw metadata to generate standardized report data. The target report is generated by building a report based on the target metadata template and the standardized report data.

[0006] In one possible implementation, the step of parsing the report specification document using a natural language model and visual technology to generate an initial metadata template framework includes: A pre-trained natural language model in the financial field is used to perform semantic parsing on the text content in the report specification document, identify and establish the relationship between various report elements, including report fields, data types, business verification rules and reporting cycles; The table sample in the report specification document is analyzed by object detection algorithm and text recognition technology to determine the cell position and cell text of the table sample, and to generate the text table mapping relationship between each cell position and each cell text. Based on the financial knowledge graph, the report fields are matched with standard data source fields to determine the data mapping suggestions corresponding to the report fields; Based on the relationship between the report elements, the mapping relationship between the text tables, and the data mapping suggestions, the initial metadata template framework is generated.

[0007] In one possible implementation, the step of using a pre-trained natural language model in the financial field to perform semantic parsing on the text content in the report specification document, identifying and establishing the relationship between various report elements, includes: The report specification document is preprocessed by converting the non-editable format document in the report specification document into editable text, removing redundant format symbols and dividing it into several text segments; After loading the natural language model and performing word segmentation, part-of-speech tagging, and named entity recognition on each text segment, the report fields, data types, business verification rules, and reporting cycles in each text segment are extracted to form several report elements. The financial knowledge graph is invoked to perform consistency checks on each of the aforementioned report elements and to establish the relationship between the report elements.

[0008] In one possible implementation, the step of performing structural parsing on the table sample in the report specification document using object detection algorithms and text recognition technology to determine the cell positions and cell text of the table sample, and generating a text table mapping relationship between each cell position and each cell text, includes: The table sample is converted into a standardized image, and an image denoising algorithm is used to process interfering pixels. The cell positions of the table sample are then identified using a target detection algorithm. Text recognition technology is used to extract the cell text in each cell of the table example, and the cell coordinates corresponding to each cell text are determined; Based on the cell coordinates corresponding to each cell text, a text table mapping relationship between each cell position and each cell text is generated.

[0009] In one possible implementation, receiving user adjustments to the initial metadata template framework via a visual configuration interface to form a target metadata template includes: The initial metadata template framework is loaded through a visual configuration interface; After receiving the user's adjustment operation on the initial metadata template framework through the rule component library, the adjustment operation is converted into executable logic instructions; According to the executable logic instructions, the initial metadata template framework is adjusted and its integrity is verified to form the target metadata template.

[0010] In one possible implementation, performing multi-dimensional validation on the original metadata to generate standardized report data includes: Establish and perform multi-dimensional verification on the original metadata based on a multi-dimensional verification mechanism; If the verification fails, the original metadata is marked as abnormal, and the reason for the abnormality is recorded and pushed to the user terminal to receive the user's correction operation on the original metadata. The verification is then re-executed until the verification passes. The original metadata that has passed verification is formatted and reorganized to generate standardized report data.

[0011] In one possible implementation, the step of building the report based on the target metadata template and the standardized report data to generate the target report includes: Load the target metadata template and parse the report structure, field layout, and output format requirements in the target metadata template; Based on the report structure and field layout, the standardized report data is populated into the target metadata template, and users can fine-tune the populated target metadata template to build a report data model. According to the output format requirements, the report data model is rendered to generate the target report.

[0012] Furthermore, to achieve the above objectives, this application also proposes a report building device, the report building device comprising: The acquisition module is used to acquire report specification documents and user configuration instructions; The parsing module is used to parse the report specification document using natural language models and visual technology, generate an initial metadata template framework, and receive user adjustments to the initial metadata template framework through a visual configuration interface to form a target metadata template. The verification module is used to obtain raw metadata from the target data source, perform multi-dimensional verification on the raw metadata, and generate standardized report data. The module is used to build reports based on the target metadata template and the standardized report data, and generate the target report.

[0013] In addition, to achieve the above objectives, this application also proposes a report building device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the report building method described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the report building method described above.

[0015] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the report building method described above.

[0016] This application provides a report building method, apparatus, device, and storage medium. The report building method obtains a report specification document and user configuration instructions, then parses the report specification document using a natural language model and visual technology to generate an initial metadata template framework. It receives user adjustments to the initial metadata template framework through a visual configuration interface to form a target metadata template. It then obtains raw metadata from a target data source and performs multi-dimensional validation on the raw metadata to generate standardized report data. Finally, it builds a report based on the target metadata template and the standardized report data, generating the target report. This eliminates the need for manual coding by professional developers; business users can complete report configuration through a visual interface, bridging the communication gap between technical and business departments. It allows personnel familiar with regulatory rules to directly participate in report building, reducing misunderstandings, and adapting to different regulatory scenarios and data types. Attached Figure Description

[0017] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1This is a flowchart illustrating the report building method of this application in Implementation Example 1. Figure 2 A flowchart illustrating the report building process provided for the report building method in this application; Figure 3 The system architecture diagram provided for the report building method in this application; Figure 4 This is a schematic diagram of the device structure of the hardware operating environment involved in the report building method in this application embodiment.

[0020] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0021] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0022] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0023] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device, big data service platform, or report building system capable of realizing the above functions. The following description uses a report building system as an example to illustrate this embodiment and the subsequent embodiments.

[0024] Based on this, the embodiments of this application provide a report building method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the report building method of this application, provided in Implementation Example 1.

[0025] In this embodiment, the report building method includes steps S11 to S14: Step S11: Obtain the report specification document and user configuration instructions; It should be noted that the report specification document refers to the document issued by the regulatory agency to clarify the report submission requirements. It includes core information such as report structure, field definitions, validation rules, submission format, and reporting cycle. The format may include PDF, Excel sample, Word document, etc. User configuration instructions refer to the custom instructions entered by business users or implementation personnel based on actual submission needs regarding report construction, including data source selection, template personalization settings, output format preferences, etc.

[0026] In one possible implementation, the system supports multiple methods for obtaining report specification documents, including local file upload, network link import, and direct synchronization with regulatory agency interfaces; user configuration commands can be entered through visual interface form filling, drop-down selection, drag-and-drop configuration, etc., reducing the difficulty of user operation; the system will perform format compatibility verification on the obtained report specification documents, support mainstream file formats, and prompt users to perform format conversion for formats that cannot be directly parsed.

[0027] Specifically, firstly, it provides diverse document upload entry points to receive report specification documents uploaded by users, or synchronize the latest report specification documents through data interfaces with regulatory agencies; then, through interactive components of the visual configuration interface, it collects configuration commands input by users, including target data source type (such as SQL database, API interface), report output format (such as Excel, PDF), personalized field settings, etc.; finally, it verifies the completeness of the report specification documents (checking whether they contain necessary report structure, validation rules, and other information), and verifies the rationality of user configuration commands (such as verifying whether the data source is connected), ensuring that the received information is valid and usable.

[0028] Step S12: The report specification document is parsed using natural language models and visual technology to generate an initial metadata template framework. The user's adjustment operation on the initial metadata template framework is received through a visual configuration interface to form a target metadata template. It should be noted that the natural language model refers to a language processing model pre-trained on financial corpora, possessing the ability to recognize financial terminology and perform semantic parsing, used to extract key information from the text of report specification documents. Visual technology refers to a combination of object detection algorithms and text recognition technology, used to parse the table sample structure in report specification documents. The initial metadata template framework refers to a preliminary template structure generated based on the parsing results, containing the core elements of the report, covering basic information such as report metadata, field definitions, table structure, and data mapping suggestions. The visual configuration interface refers to an interactive interface providing an Excel-like operation experience, supporting user configuration operations through drag-and-drop, component selection, etc. Adjustment operations refer to user modifications, additions, and deletions to the initial metadata template framework, including field attribute adjustments, validation rule configuration, and structure optimization. The target metadata template refers to the final standardized and executable metadata template formed after user adjustments and integrity verification.

[0029] The core objective of this step is to automatically parse report specifications using technical means, quickly generate an initial template framework, and then combine this with user interaction adjustments to achieve precise template customization. This reduces manual coding workload while ensuring the template meets business requirements, solving the problems of traditional template building relying on hard coding and being inefficient. In one possible implementation, the natural language model uses a finely tuned BERT model from the financial field, which can accurately identify business verification rules such as "non-performing loan rate ≤ 5%"; the object detection algorithm in the visual technology uses the YOLO algorithm, and the text recognition technology uses the CRNN algorithm to ensure the accuracy of table structure parsing; the visual configuration interface supports multi-sheet linkage design and cross-sheet calculation configuration to meet complex report requirements; after user adjustments, the system will perform real-time integrity checks and prompt for missing necessary configuration items.

[0030] For details, please refer to steps S21-S53, which will not be repeated here.

[0031] Step S13: Obtain raw metadata from the target data source, perform multi-dimensional validation on the raw metadata, and generate standardized report data; It should be noted that the target data source refers to the data source specified in the user configuration instructions, used to provide report data, including various types such as SQL databases, API interfaces, and cross-database tables. Raw metadata refers to the unprocessed raw data directly obtained from the target data source, which may contain issues such as inconsistent formatting, logical inconsistencies, and missing data. Multi-dimensional validation refers to a multi-level validation mechanism covering field-level, business-level, and compliance-level validation. Field-level validation verifies data format (e.g., regular expression matching of ID card numbers), data length, etc.; business-level validation verifies data logical consistency; and compliance-level validation verifies whether the data conforms to regulatory standards (e.g., conforms to G0400 reporting specifications). Standardized report data refers to report data that has passed multi-dimensional validation, but has been converted and reorganized according to the format requirements defined in the target metadata template, resulting in a unified structure, standardized format, and accurate data. (See reference for details.) Figure 2 .

[0032] The core purpose of this step is to ensure the accuracy, compliance, and standardization of report data, intercept erroneous data in advance, and avoid reports failing to meet regulatory requirements due to data issues, thus providing high-quality data support for subsequent report construction. In one possible implementation, the system supports simultaneous connection to multiple target data sources, enabling cross-database data querying and integration; multi-dimensional validation rules can be automatically executed through a rule engine, and data that fails validation will be marked with an anomaly type (such as format errors or logical conflicts) and pushed to the user's terminal; after the user corrects the abnormal data, the system will automatically re-execute the validation until all data passes; the standardization process will convert the data into the format specified by the target metadata template (such as displaying thousands separators and retaining two decimal places).

[0033] For details, please refer to steps S61-S63, which will not be repeated here.

[0034] Step S14: Based on the target metadata template and the standardized report data, build the report and generate the target report.

[0035] It's important to note that report building refers to the process of populating a target metadata template with standardized report data, rendering it according to the template's defined format requirements, and ultimately generating a report that meets regulatory requirements and user needs. The target report refers to the final report that, after being built, can be directly used for regulatory submissions. It can be in various formats such as Excel and PDF, and is characterized by clear structure, accurate data, and strong compliance. The core purpose of this step is to combine standardized data with customized templates to automate report building, significantly shortening the report generation cycle while ensuring that the reports comply with regulatory standards and user configuration requirements, ultimately achieving the goal of self-service report building.

[0036] In one possible implementation, the report building process allows users to fine-tune the template after data population, including adjusting cell styles, modifying header formats, and adding remarks. Format rendering strictly adheres to the output requirements defined in the target metadata template, such as setting cell borders, header hierarchy styles, and data display precision. The generated target report synchronously records a report generation log (e.g., data source, generation time, and verification results), supporting audit traceability. The system supports exporting multiple target report formats to meet the reporting requirements of different regulatory agencies. (See reference for details.) Figure 2 .

[0037] For details, please refer to steps S71-S73, which will not be repeated here.

[0038] This embodiment enables business users to configure reports through a visual interface without the need for manual coding by professional developers. This shortens the communication gap between technical and business departments, allows personnel familiar with regulatory rules to directly participate in report building, reduces misunderstandings, and adapts to different regulatory scenarios and data types.

[0039] In one feasible implementation, the step of parsing the report specification document using natural language models and visual technologies to generate an initial metadata template framework includes: Step S21: Use a pre-trained natural language model in the financial field to perform semantic parsing on the text content in the report specification document, identify and establish the relationship between report elements, including report fields, data types, business verification rules and reporting cycles. It should be noted that the pre-trained natural language model in the financial field refers to a language processing model that has been pre-trained and fine-tuned based on financial industry corpora (such as regulatory policy documents, financial statement texts, and financial reporting specifications), possessing the ability to recognize financial professional terminology, understand semantics, and analyze logical connections. Text content refers to the textual descriptions in the report specification documents, excluding the table templates, covering information such as field descriptions, rule requirements, and filling instructions. Semantic parsing refers to the process of processing the text content through word segmentation, part-of-speech tagging, and named entity recognition to extract core information and understand its semantic meaning. Report elements refer to the core elements required to construct the report template. Report fields refer to the names of data items to be filled in the report (e.g., "balance of various loans"), data types refer to the data formats corresponding to the report fields (e.g., numeric, character, date), business validation rules refer to the rules that ensure the logical correctness of the data (e.g., "non-performing loan ratio ≤ 5%)", and reporting cycle refers to the frequency of report submission (e.g., monthly, quarterly, annual). Report element relationships refer to the logical connections between various report elements, such as mapping relationships like "report field - corresponding data type" and "report field - associated business validation rules".

[0040] The core purpose of this step is to automatically extract key report elements from the text of the report specification document and clarify the logical relationships between these elements, replacing the tedious work of manually extracting elements and improving template building efficiency. In one possible implementation, the pre-trained natural language model for the financial field uses a fine-tuned BERT model, specifically optimized for recognizing financial terminology and regulatory rules. During semantic parsing, a financial professional dictionary is used to ensure the accurate extraction of professional terms such as "core tier 1 capital" and "risk-weighted assets." For ambiguous business verification rules, the system will mark them and allow users to supplement and confirm them in subsequent steps.

[0041] For details, please refer to steps S31-S33, which will not be repeated here.

[0042] Step S22: The table sample in the report specification document is structurally parsed using object detection algorithm and text recognition technology to determine the cell position and cell text of the table sample, and to generate a text table mapping relationship between each cell position and each cell text. It's important to clarify that object detection algorithms refer to computer vision algorithms used to identify the positions of tables and cells in images, such as the YOLO algorithm, which can quickly and accurately locate the boundaries of tables and the coordinate range of their internal cells. Text recognition technology refers to techniques used to extract text content within cells of an image, such as the CRNN algorithm, which can convert text in cell images into editable character formats. The table examples in the report specification document refer to sample tables included in the report specification document, used to demonstrate the specific structure and field layout of the report; they are a visual representation of the report structure. Cell position refers to the coordinate information of each cell in the table example in the image coordinate system (such as the coordinates of the top left corner and bottom right corner), used to accurately locate the cell's position in the table. Cell text refers to the text content contained within each cell in the table example, such as field names, remarks, etc. Text table mapping relationships refer to the relationships between the cell positions and their corresponding cell text.

[0043] The core purpose of this step is to automatically parse the table sample structure in the report specification document, accurately obtain the position and content relationship of cells, avoid the tedious operation of manually disassembling tables, ensure the accuracy of report structure restoration, and provide table layout information for the initial metadata template framework.

[0044] In one possible implementation, the object detection algorithm and text recognition technology work together. First, the object detection algorithm locates the table and cell positions, and then text recognition is performed on each cell individually. For tilted or blurry table examples, image correction and noise reduction are performed first to improve the accuracy of text recognition. The generated text table mapping relationship is stored in a structured format, which supports quick querying of the corresponding text content by cell position.

[0045] For details, please refer to steps S41-S43, which will not be repeated here.

[0046] Step S23: Match the report fields with standard data source fields based on the financial knowledge graph to determine the data mapping suggestions corresponding to the report fields; It's important to clarify that a financial knowledge graph refers to a large-scale structured knowledge base containing entities, relationships, and attributes within the financial field. Entities include report fields, data source fields, and financial indicators; relationships include "field correspondence" and "indicator association"; attributes include the data type, business meaning, and domain of the fields; and knowledge sources include financial industry standards, regulatory norms, and internal enterprise data source dictionaries. Report fields refer to the names of data items that need to be filled in the report, extracted from the report specification document. Standard data source fields refer to standardized fields defined in internal enterprise data sources (such as SQL databases and API interfaces), possessing unified naming conventions, data types, and business meanings. Matching refers to the process of finding the most suitable data source field by calculating the similarity between report fields and standard data source fields in semantics, business meaning, and data type dimensions. Data mapping suggestions refer to the system recommending a "report field - standard data source field" correspondence to the user based on the matching results, for the user's reference and confirmation.

[0047] The core objective of this step is to intelligently recommend mapping relationships between report fields and data source fields, reducing the workload and errors associated with manual matching by users. This ensures that report data can be accurately retrieved from the data source, laying the foundation for subsequent data extraction and report construction. In one possible implementation, the matching process uses a semantic similarity algorithm combined with business rules, prioritizing fields with consistent data types and highly relevant business meanings. For report fields with a similarity score below a preset threshold, the system recommends multiple candidate data source fields and labels them with similarity scores. The financial knowledge graph is updated regularly, synchronizing newly added report fields, data source fields, and their relationships to ensure matching accuracy.

[0048] Specifically, firstly, all report fields are selected from the report elements extracted in step S21, and standard data source fields and related attributes (data type, business meaning, etc.) are obtained from the enterprise's internal data source dictionary. Next, based on the financial knowledge graph, a semantic similarity algorithm is called to calculate the similarity between each report field and each standard data source field, and a weighted score is calculated by combining rules such as data type consistency and business domain relevance. Then, the standard data source fields with the highest and lowest weighted scores are selected as candidate matching fields. Finally, the candidate matching field information, similarity scores, and matching criteria (such as "highly relevant business meaning" and "consistent data type") are integrated to generate data mapping suggestions for each report field, which are then pushed to the user interface for user confirmation.

[0049] Step S24: Based on the relationship between the report elements, the mapping relationship between the text tables, and the data mapping suggestions, generate the initial metadata template framework.

[0050] It should be noted that the initial metadata template framework refers to the preliminary template framework formed after integrating the above three types of information, which includes the core structure and configuration information of the report. It covers core content such as template metadata (report name, reporting cycle, etc.), report structure (field layout, cell position, etc.), field attributes (data type, required fields, etc.), validation rules (business validation rules), and data source mapping suggestions (correspondence between report fields and data source fields). The core purpose of this step is to integrate the key information parsed and matched in the early stages, automatically generate a structured initial template framework, replacing the traditional method of manually writing templates, significantly shortening template setup time, and ensuring that the template framework fully covers report specification requirements and data acquisition needs. In one possible implementation, the initial metadata template framework is stored in JSON Schema format, which has good readability and scalability; the framework automatically marks the source of each configuration information (e.g., "business validation rules come from report specification document text parsing"), facilitating user traceability; for conflicting information (e.g., the reporting cycle in the text parsing is inconsistent with the annotation in the table sample), the system will mark the conflict point and prompt the user for confirmation.

[0051] Specifically, the process first integrates three core information categories: report element relationships, text table mapping relationships, and data mapping suggestions. Redundant data is removed, and information conflicts are resolved (e.g., through user-preset rules or by prompting users to confirm conflicting content). Next, the basic structure of the template framework is built based on JSON Schema format, including template metadata, report structure, field attributes, validation rules, and data source mapping. Then, the integrated information is populated into the corresponding levels: the reporting period is entered into the template metadata, the correspondence between cell positions and report fields is entered into the report structure, data types and business validation rules are entered into the field attributes, and data mapping suggestions are entered into the data source mapping level. Finally, the populated framework is validated for completeness to ensure it contains the core information required for report construction. After successful validation, the initial metadata template framework is output and displayed to the user for subsequent adjustments.

[0052] For example, the module integrates three types of information: the relationship between report elements is "Net Core Tier 1 Capital - Numerical - ≥5 billion RMB - Quarterly", the text table mapping relationship is "(100,200,300,250) - Net Core Tier 1 Capital", and the data mapping suggestion is "Net Core Tier 1 Capital → Net Core Tier 1 Capital (Ending Value)". A JSON Schema format framework is constructed, the reporting period "Quarterly" is filled in the template metadata, the cell positions (100,200,300,250) are bound to the field "Net Core Tier 1 Capital" in the report structure, the data type "Numerical" and the validation rule "≥5 billion RMB" are filled in the field attributes, and the recommended corresponding relationship is filled in the data source mapping. After the integrity verification is correct, the initial metadata template framework is generated.

[0053] This embodiment leverages a pre-trained model in the financial field to accurately identify core elements and relationships in reports, aligning with the professional scenarios of regulatory reports and reducing element omissions or misjudgments. Through object detection and text recognition technologies, it quickly locates cell positions and text, automatically generating mapping relationships to replace manual table breakdown and improve parsing efficiency. Simultaneously, it utilizes a financial knowledge graph to achieve accurate matching between report fields and standard data source fields, providing scientific mapping suggestions and reducing the workload and errors of manual matching. This automates parsing and framework generation, eliminating the need for business users to possess coding or complex parsing skills, empowering them to directly participate in template building. The parsing process adheres to the element definitions and structural specifications of financial regulatory reports, ensuring that the initial template framework complies with regulatory requirements and reducing compliance risks.

[0054] In one feasible implementation, the step of using a pre-trained natural language model in the financial field to perform semantic parsing on the text content in the report specification document, and identifying and establishing the relationship between various report elements, includes: Step S31: Perform text preprocessing on the report specification document, convert the non-editable format document in the report specification document into editable text, remove redundant format symbols and divide it into several text segments; It's important to note that text preprocessing refers to a series of operations that standardize the text content in report specification documents, aiming to improve the accuracy and efficiency of subsequent semantic analysis. Non-editable documents refer to document formats where the text content cannot be directly modified, such as scanned PDFs or image-based report descriptions. Editable text refers to text formats that allow direct text extraction, modification, and analysis, such as TXT, editable PDFs, and text content in Word documents. Redundant formatting symbols refer to symbols in the text that do not carry core information, including redundant line breaks, spaces, special punctuation, and formatting tags (such as font style labels). Text fragments refer to text units with independent meanings, segmented according to semantic logic, with each fragment focusing on a single report-related description (such as field definitions or rule descriptions). The core purpose of this step is to eliminate interference from document format differences and redundant information, transforming non-standardized text into clean, well-organized, and easily parsed text fragments, ensuring that the subsequent natural language model can accurately identify the core information.

[0055] In one possible implementation, for non-editable documents such as scanned PDFs, OCR (Optical Character Recognition) technology is used for text conversion, and the recognition accuracy is optimized by combining financial professional dictionaries; the removal of redundant format symbols retains key symbols related to the report rules (such as logical symbols such as "≤" and "="); the text segmentation adopts a semantic segmentation algorithm, using periods, semicolons, paragraph separators, etc. as boundaries to ensure the semantic integrity of each segment.

[0056] Specifically, the first step is to identify the format type of the report specification document. For non-editable format documents, OCR technology or format conversion tools are used to convert them into editable text. Next, redundant format symbols are cleaned up in the converted editable text, removing unnecessary line breaks, spaces, invalid punctuation, and format marks, while retaining core semantically relevant symbols. Finally, a semantic-based segmentation algorithm is used, combined with the report's business logic (such as the semantic boundaries of field descriptions and rule descriptions), to segment the complete text into several independent text fragments, each focusing on single report-related information.

[0057] Step S32: Load the natural language model, perform word segmentation, part-of-speech tagging and named entity recognition on each text segment, and extract the report fields, data types, business verification rules and reporting cycles from each text segment to form several report elements; It should be noted that the natural language model refers to a language processing model pre-trained and fine-tuned with financial domain corpora, possessing the ability to recognize financial terminology, understand semantics, and extract key information, specifically adapted to text parsing scenarios for regulatory reporting specifications. Word segmentation refers to the process of breaking down text fragments into the smallest semantic units according to financial domain vocabulary rules, such as breaking down "core tier 1 capital net amount must be numerical" into lexical units like "core tier 1 capital net amount," "must be," and "numerical." Part-of-speech tagging refers to labeling each segmented lexical unit with grammatical attributes (such as nouns, verbs, quantifiers, logical operators, etc.) to assist in identifying report element types. Named entity recognition refers to the technology of identifying and extracting specific entities in the financial domain from the word segmentation results, such as report field names, data type identifiers, and regulatory indicators. Report fields refer to the names of data items that need to be filled in the report (such as "core tier 1 capital net amount" and "non-performing loan ratio"). Report elements refer to the collection of core information such as integrated and extracted report fields, data types, business verification rules, and reporting cycles, and are the basic units for constructing report templates.

[0058] The core objective of this step is to accurately extract the essential elements required for report construction from text fragments through automated processing using a natural language model, replacing the tedious manual sentence-by-sentence extraction and improving the efficiency and accuracy of element extraction. In one possible implementation, the natural language model employs a finely tuned BERT model specific to the financial field, optimized and trained using a regulatory reporting corpus to enhance the accuracy of report element recognition. During extraction, a financial dictionary and regular expressions are used to strengthen the recognition of logical symbols such as "≥", "≤", and "=", as well as keywords such as "numerical" and "quarterly". For ambiguous expressions (such as fields with unclear data types), they are marked as elements awaiting confirmation, allowing users to supplement them later.

[0059] Specifically, firstly, a pre-trained natural language model fine-tuned for the financial domain is loaded, and the model parameters are initialized to adapt to the report text parsing scenario. Then, word segmentation, part-of-speech tagging, and named entity recognition are performed sequentially on each text segment to split semantic units, label grammatical attributes, and identify financial domain entities. Then, based on the labeling results and financial business logic, report fields (such as core data items identified by named entities), data types (such as keywords such as "numerical" and "character"), business verification rules (such as expressions containing logical symbols), and reporting periods (such as time keywords such as "monthly" and "quarterly") are extracted. Finally, the extracted information is organized into structured report elements, with each element clearly corresponding to the core information of the text segment.

[0060] Step S33: Call the financial knowledge graph to perform consistency verification on each of the report elements and establish the report element association relationship between each of the report elements.

[0061] It should be noted that a financial knowledge graph refers to a large-scale structured knowledge base containing entities, relationships, and attributes in the financial field. Entities include report fields, data types, regulatory indicators, and validation rules. Relationships include "field-data type correspondence" and "field-validation rule association." Attributes include the business meaning of fields, the applicable scope of data types, and the compliance standards of validation rules. Data sources include regulatory norms, financial industry standards, and internal business dictionaries of enterprises. Consistency validation refers to the process of comparing extracted report elements with standard information in the financial knowledge graph to verify the rationality, accuracy, and conflict-free nature of the elements. For example, it verifies whether data types and fields are compatible and whether validation rules comply with industry norms. Report element relationships refer to the correspondence between various report elements based on business logic and semantics, including mapping relationships such as "report field-corresponding data type," "report field-associated business validation rule," and "report field-corresponding reporting period."

[0062] The core objective of this step is to ensure the accuracy and consistency of report elements through a financial knowledge graph, eliminating erroneous or conflicting elements, and simultaneously clarifying the logical relationships between elements to ensure that the template framework complies with financial business logic and regulatory requirements. In one possible implementation, consistency verification will proceed from three dimensions: data type compatibility (e.g., "Net Core Tier 1 Capital" should match "numerical"), verification rule compliance (e.g., risk indicator thresholds meet regulatory requirements), and field name standardization. Elements that fail verification (e.g., fields and data types do not match) will be marked as abnormal and the user will be prompted for confirmation. Relationship establishment uses a semantic matching algorithm, combined with preset relationship rules in the financial knowledge graph, to automatically construct mappings between elements.

[0063] Specifically, the process first involves accessing a financial knowledge graph to obtain standard information related to report elements (such as standard data types for fields, compliance verification rules, etc.). Next, the extracted report elements are compared with this standard information to perform consistency checks, verifying whether fields and data types are compatible, whether verification rules conform to industry standards, and whether field names are standardized. If any anomalies are found (e.g., "Net Core Tier 1 Capital" is marked as "character type"), the abnormal element is flagged and the user is prompted to correct it. Finally, based on the verified report elements and the preset relationship rules in the financial knowledge graph, the relationships between elements are established, clarifying the corresponding logic of report fields and data types, business verification rules, and reporting cycles.

[0064] This embodiment efficiently separates key elements such as report fields and data types through word segmentation, part-of-speech tagging, and named entity recognition, replacing manual extraction, reducing omissions and misjudgments. Then, it uses financial knowledge graphs to verify elements, eliminate conflicts and errors, and ensure that report elements comply with financial business logic and regulatory standards. This establishes the relationship between elements, clarifies the correspondence between fields and data types and verification rules, and provides clear logical support for template framework generation.

[0065] In one feasible implementation, the step of performing structural analysis on the table samples in the report specification document using object detection algorithms and text recognition technology to determine the cell positions and cell text of the table samples, and generating text table mapping relationships between each cell position and each cell text, includes: Step S41: Convert the table sample into a standardized image, use an image noise reduction algorithm to process interfering pixels, and use a target detection algorithm to identify the cell positions of the table sample. It should be noted that the table sample refers to the table included in the report specification document, used to demonstrate the specific structure, field layout, and filling examples of the report. It is the core reference for reconstructing the report framework and can take the form of an embedded table in the document or a table image in a scanned document. Standardized images refer to converting table samples of different formats and resolutions into images of a preset size and a unified color mode (such as grayscale) to ensure consistency in subsequent algorithmic processing. Image denoising algorithms refer to computer vision algorithms used to remove interfering pixels from images, such as Gaussian filtering and median filtering, which can eliminate redundant information such as shadows, spots, and blurriness in table images. Interfering pixels refer to ineffective pixels that affect the recognition of table structure, including noise points, background noise, and abnormal pixels caused by scanning distortion. Object detection algorithms refer to algorithms used to accurately locate the boundaries of tables and cells in images, such as the YOLO algorithm and the Faster R-CNN algorithm, which can identify the overall outline of the table and the specific location range of each cell within it. Cell position refers to the coordinate information of each cell in the standardized image coordinate system, usually represented by the coordinate values ​​of the top left and bottom right corners (x1, y1, x2, y2), which is used to specify the spatial position of the cell in the table.

[0066] The core objective of this step is to eliminate format differences and interference factors in table samples through image standardization and algorithm optimization, accurately identify the spatial location of cells, replace the tedious manual cell positioning operation, and improve the efficiency and accuracy of report structure parsing. In one possible implementation, when the table sample is converted into a standardized image, the image resolution is automatically adjusted to a preset standard (e.g., 300 DPI) to ensure clear details; the image noise reduction algorithm adaptively selects the filtering method based on the type of interfering pixels, using Gaussian filtering for the paper texture of the scanned document and median filtering for random noise; the object detection algorithm first identifies the overall boundary of the table, and then segments each cell based on the table's line features, ensuring that cell location identification is complete and without overlap.

[0067] Specifically, the process begins by reading the table sample from the report specification document. Regardless of whether the original format is an embedded table, a scanned document, or an image, it is uniformly converted into a standardized image with a preset size and grayscale mode. Next, an image denoising algorithm is activated to filter out interfering pixels in the standardized image, removing redundant information such as shadows, spots, and textures, while enhancing table lines and cell outlines. Then, an object detection algorithm is loaded to first identify the overall boundary coordinates of the table, and then, based on the horizontal and vertical features of the table, to segment and locate the specific position of each cell, recording the coordinates (x1, y1, x2, y2) of the top left and bottom right corners of each cell to form a set of cell positions.

[0068] Step S42: Use text recognition technology to extract the cell text in each cell of the table sample, and determine the cell coordinates corresponding to each cell text; It should be noted that text recognition technology refers to computer vision technologies that can convert text content in images into editable text, such as CRNN (Convolutional Recurrent Neural Network) and OCR (Optical Character Recognition) technologies, which are specifically optimized for recognizing professional terminology in the financial field. Cell text refers to the text information contained in each cell of the table sample, including report field names (such as "Net Core Tier 1 Capital"), data descriptions, and filling examples.

[0069] The core purpose of this step is to automatically extract the text content within cells and associate it with the corresponding cell coordinates, replacing the tedious work of manually entering text cell by cell. This ensures the accuracy and efficiency of text extraction and provides a foundation for establishing the mapping relationship between text and table positions in the future.

[0070] In one possible implementation, the text recognition technology will be optimized in conjunction with a financial professional dictionary to improve the recognition accuracy of professional terms such as "non-performing loan ratio" and "risk-weighted assets"; for slanted or blurry cell text, the cell image will be corrected and enhanced first; after the text is extracted, error correction processing will be performed to automatically correct recognition errors such as similar-looking characters and missing characters; after each cell text is extracted, it will be immediately bound to the coordinates of that cell to ensure one-to-one correspondence.

[0071] Specifically, firstly, based on the set of cell locations identified in step S41, a partial image corresponding to each cell is captured one by one, ensuring that the captured range accurately covers the cell boundary and does not include the content of adjacent cells; then, text recognition technology is loaded to perform text recognition on the partial image of each cell, converting the text in the image into editable text, and combining it with a financial professional dictionary for error correction and optimization to ensure the accuracy of the text content; finally, each recognized cell text is associated and bound with the corresponding cell coordinates (x1, y1, x2, y2), recording the correspondence between "text and coordinates" to form a text coordinate association set.

[0072] Step S43: Based on the cell coordinates corresponding to each cell text, generate a text table mapping relationship between each cell position and each cell text.

[0073] It's important to note that text table mapping refers to structured data that records the one-to-one correspondence between cell positions and cell text. Clearly defining the logical relationship of "a certain spatial location corresponding to a certain text content" within the table is the core basis for reconstructing the report structure and determining the field layout. The core purpose of this step is to structurally associate cell position information with text content, forming a clear and standardized mapping relationship. This provides accurate table structure information for generating the initial metadata template framework, ensuring that the template can accurately reproduce the table layout and field distribution in the report specification document.

[0074] In one possible implementation, the text table mapping relationship is stored in JSON format for easy parsing and use later. After the mapping relationship is generated, an integrity check is performed to ensure that each cell position has corresponding text content without omissions or duplications. Blank text or garbled text that fails to be recognized is marked as "to be supplemented" to prompt the user to manually complete it, thus ensuring the integrity of the mapping relationship.

[0075] Specifically, the system extracts all corresponding data of "cell position - cell text" from the text coordinate association set and removes redundant information. Then, it constructs a text table mapping relationship according to a preset structured format (such as JSON). Each mapping entry contains cell coordinates (x1, y1, x2, y2) and the corresponding cell text, clarifying the one-to-one correspondence between the two. Finally, it performs an integrity check on the generated mapping relationship to check for cell positions without associated text or cell text without associated positions. If any such cases exist, an exception is marked and the user is prompted to handle it. After the check passes, the complete text table mapping relationship is output.

[0076] This embodiment uses a target detection algorithm to accurately locate cell positions, avoiding errors from manual segmentation, and uses text recognition technology to automatically extract cell text, replacing manual input and significantly improving the efficiency of table information extraction. It is compatible with different format, blurry or slanted table samples. Through image preprocessing and algorithm optimization, it improves the parsing and adaptation capabilities of complex tables, thereby providing accurate table layout information for the initial metadata template framework, shortening the template building cycle, and responding to the rapid iteration needs of regulatory reports.

[0077] In one feasible implementation, the step of receiving user adjustments to the initial metadata template framework through a visual configuration interface to form a target metadata template includes: Step S51: Load the initial metadata template framework through the visual configuration interface; It should be noted that the visual configuration interface refers to an interactive interface developed based on the Univer framework and Vue3, providing an Excel-like operation experience. It features drag-and-drop design, multi-sheet linkage, cross-sheet calculations, and other functions, allowing business users to configure report templates without coding. The initial metadata template framework refers to the preliminary template structure generated after initial text parsing, table parsing, and field matching. It includes the core report structure (such as field layout and cell position), field attributes (such as data type and validation rules), and data source mapping suggestions, and is stored in JSON Schema format.

[0078] The core objective of this step is to present the abstract initial metadata template framework to users in a visual and easy-to-use format, reducing the user's understanding cost of the template structure, providing an intuitive interactive platform for subsequent adjustments, empowering business users to directly participate in template optimization, and breaking the traditional reliance on technical personnel for template configuration. In one possible implementation, the visual configuration interface supports real-time preview of the template framework, allowing users to switch between "edit mode" and "preview mode" to view the adjustment effects; during loading, it automatically adapts to the template's multi-sheet structure, clearly displaying the field layout and relationships of each sheet; key configuration items in the template (such as validation rules and data source mapping) are highlighted for easy user location.

[0079] Specifically, the initial metadata template framework generated earlier is first retrieved from the system storage module, and its JSON Schema format structure information is parsed, including template metadata, report structure, field attributes, validation rules, etc. Then, based on an Excel-like interface layout, the core content of the template framework is rendered into the visual configuration interface, restoring key information such as field layout, cell position, and sheet structure. At the same time, abstract field attributes and validation rules are presented in the form of editable components. Finally, the interface interaction functions are initialized, enabling drag-and-drop, editing, component selection, and other operation permissions to ensure that users can flexibly adjust the template framework, and simultaneously loading template version information, generating logs, and other auxiliary content for user reference.

[0080] Step S52: After receiving the user's adjustment operation on the initial metadata template framework through the rule component library, the adjustment operation is converted into executable logic instructions; It's important to note that the rule component library refers to a collection of pre-built business rule components within the system. These components cover various types, including numerical range validation, logical judgment, formula calculation, and format conversion. Each component corresponds to standardized configuration parameters (e.g., the "numerical range" component includes maximum and minimum value parameters). Adjustment operations refer to user modifications, additions, and deletions to the initial metadata template framework based on business needs through a visual configuration interface. These operations include dragging and dropping components to add validation rules, modifying field attributes, adjusting data mapping relationships, and adding cross-table calculation logic. Executable logic instructions refer to structured instructions that the system converts user adjustment operations into code that can be recognized and executed by the rule parsing engine. These instructions can take the form of SQL logic or Java code snippets, ensuring that the adjusted rules can be executed automatically.

[0081] The core purpose of this step is to transform the user's visual operations into executable logic for the system, avoiding the tediousness and errors of manually writing code. At the same time, it reduces the difficulty of user operations through component-based configuration, allowing business users to complete complex rule configurations without having to master programming skills, and enabling rapid optimization of templates.

[0082] In one possible implementation, the rules component library supports user-defined component extensions, and components required for special business scenarios can be added through the OSGi plugin framework; the conversion process of adjustment operations will be combined with financial knowledge graphs for logical verification to ensure that the converted instructions comply with financial business specifications; for complex formula calculation operations, the system will provide a visual formula editor to assist users in configuring and automatically converting them into execution logic.

[0083] Specifically, through the interactive interface of the rule component library, the system receives user adjustment operations, records the component type selected by the user, the configured parameters, and the operation object (such as the target field and cell position); then, it parses the standardized parameters of the selected component, combines them with the structural information of the initial metadata template framework, and clarifies the business logic corresponding to the adjustment operation (such as configuring the "≤5%" parameter for the "numerical range" component, corresponding to the validation logic of "non-performing loan rate ≤5%"); finally, based on the component type and business logic, the adjustment operation is automatically converted into executable logical instructions, such as converting numerical validation rules into SQL validation statements and formula calculation rules into Java code snippets, ensuring that the instructions conform to the execution standards of the rule parsing engine.

[0084] Step S53: Adjust and verify the integrity of the initial metadata template framework according to the executable logic instructions to form the target metadata template.

[0085] It's important to note that integrity verification refers to a comprehensive validation of the adjusted template, covering dimensions such as field completeness (whether necessary fields are included), logical consistency (no rule conflicts), configuration completeness (no missing parameters), and compliance (meeting regulatory requirements). This ensures the template can be used correctly for subsequent report creation. The core purpose of this step is to ensure the accuracy, completeness, and compliance of the template through automated system adjustments and validation, avoiding logical conflicts or configuration omissions that may result from manual adjustments. Simultaneously, it creates a final template that meets user needs and regulatory requirements, providing reliable support for automated report generation.

[0086] In one possible implementation, the adjustment process retains the template version record, supporting subsequent traceability and rollback; the integrity verification adopts a combination of rule verification and machine learning verification, focusing on checking financial compliance-related configurations; when the verification fails, the system will clearly mark the anomaly (such as "a certain field is missing a mandatory field verification rule") and prompt the user to correct it until the verification passes.

[0087] Specifically, firstly, executable logic instructions are loaded, and the logic corresponding to the instructions is executed through the rule parsing engine to adjust the initial metadata template framework, including updating field attributes, adding / modifying validation rules, optimizing data mapping relationships, and adjusting table layout. Then, an integrity verification mechanism is initiated to perform a comprehensive verification from four dimensions: field integrity (checking whether any fields required by the report specification are missing), logical consistency (verifying whether there are conflicts between rules, such as contradictory validation thresholds for two values ​​of the same field), configuration integrity (confirming that no component parameters are missing), and compliance (verifying whether the rules conform to regulatory standards, such as the G0400 report specification). If an anomaly is found during verification, the anomaly information is marked and pushed to the user interface. After receiving the user's correction operation, the adjustment and verification are re-executed. After the verification passes, the adjusted template is solidified in JSON Schema format to form the target metadata template and stored in the template repository.

[0088] This embodiment provides an Excel-like operation experience through a visual configuration interface. No coding is required, and business users can directly participate in template adjustments, reducing reliance on the IT team. Through drag-and-drop configuration of the rule component library, adjustments to validation rules, field attributes, etc., can be quickly completed, and the operations take effect immediately without compilation or deployment. The system automatically converts user adjustments into executable logical instructions, avoiding errors from manual coding and ensuring the accuracy of template logic. After adjustment, it automatically performs integrity checks to check for missing configurations or logical conflicts, ensuring that the target metadata template meets the requirements for report building. Notably, template adjustments do not require modification of the underlying code, making the risks controllable and subsequent iterations and updates more convenient, reducing maintenance workload.

[0089] In one feasible implementation, the step of performing multi-dimensional validation on the original metadata to generate standardized report data includes: Step S61: Establish and perform multi-dimensional verification on the original metadata based on a multi-dimensional verification mechanism; It should be noted that the multi-dimensional verification mechanism refers to a three-tiered progressive verification system covering field-level, business-level, and compliance-level verification. Each layer focuses on different dimensions of quality requirements, forming a comprehensive data verification barrier. Raw metadata refers to unprocessed raw data directly obtained from the target data source (such as SQL databases or API interfaces), which may contain issues such as inconsistent formats, logical contradictions, and non-compliance with regulatory requirements. Field-level verification refers to the verification of basic attributes such as data format, data length, and data type. For example, using regular expressions to verify the format of ID card numbers and mobile phone numbers, and checking whether numeric data contains non-numeric characters. Business-level verification refers to verification based on financial business logic, ensuring the consistency of logical relationships between data. For example, verifying the summation logic of "life insurance premium income = individual life insurance premium + group life insurance premium" and the threshold logic logic of "loan loss provision ratio ≥ 120%". Compliance-level verification refers to verification against regulatory requirements, ensuring that data definitions and reporting standards comply with the reporting specifications of the corresponding regulatory agencies (such as G0400 reporting specifications, Basel III regulatory requirements, etc.).

[0090] The core purpose of this step is to intercept errors in the original metadata in advance through multi-level and comprehensive verification, ensuring that the data entering the subsequent process is accurate, logical, and compliant, thus guaranteeing the quality of regulatory reports from the source and avoiding compliance risks caused by data issues.

[0091] In one possible implementation, the rules of the multi-dimensional verification mechanism can be configured and extended through a rule component library, allowing users to add or modify verification rules according to specific report requirements. The execution order of verification rules can be flexibly adjusted, with the default execution order being "field-level - business-level - compliance-level" to ensure that the basic format is correct before performing higher-level verification. For batch raw metadata, parallel verification processing is supported to improve verification efficiency.

[0092] Specifically, firstly, pre-defined field-level, business-level, and compliance-level validation rules are loaded from the rule repository, including format regular expressions, business logic formulas, and regulatory standards. Next, field-level validation is performed on the original metadata, verifying the data type, format, and length of each field to ensure compliance, and marking errors such as formatting errors and type mismatches. Then, business-level validation is performed, verifying the relationships between data based on pre-defined business logic rules, and investigating logical contradictions and abnormal calculation results. Next, compliance-level validation is performed, comparing the data scope and reporting range against the reporting specifications issued by regulatory agencies to ensure compliance. Finally, the results of the three-layer validation are summarized, recording the validation status (pass / fail) and specific problem descriptions for each data item.

[0093] Step S62: If the verification fails, the original metadata is marked as abnormal, and the reason for the abnormality is recorded and pushed to the user terminal to receive the user's correction operation on the original metadata. The verification is then re-executed until the verification passes. It should be noted that anomaly marking refers to the special identification of raw data items that fail validation, clearly indicating the anomaly type (such as "incorrect field format," "business logic conflict," or "compliance threshold exceeded"), to facilitate users in quickly locating problematic data. The anomaly reason refers to the specific reason why the data failed validation, such as "net core tier 1 capital contains non-numeric characters" or "loan loss provision ratio does not meet the regulatory requirement of 120%." The user terminal refers to the device used by the user to operate the report building system, including computers, tablets, etc., which supports receiving anomaly prompts pushed by the system and performing data correction operations. Correction operations refer to the user's modifications, supplements, and replacements of anomaly data to ensure that the data complies with the validation rules.

[0094] The core objective of this step is to establish a closed-loop mechanism of "verification-marking-push-correction-re-verification," ensuring that all original metadata is corrected and passes verification, preventing erroneous data from entering subsequent report building processes. Simultaneously, clear anomaly prompts reduce the difficulty of correction for users and improve data rectification efficiency. In one possible implementation, anomaly markers are highlighted with different colors, with different anomaly types corresponding to different colors (e.g., red for format errors, yellow for logical contradictions). The anomaly cause is synchronously associated with the corresponding verification rules, helping users understand why the verification failed. The push notification received by the user terminal includes the anomaly data item, anomaly type, anomaly cause, and correction suggestions, allowing users to directly jump to the data correction page from the push notification interface. When re-performing verification, only the corrected data items are verified, eliminating the need for a full re-verification and improving efficiency.

[0095] Specifically, firstly, the original metadata items that fail verification are marked as exceptions, and corresponding identifiers are assigned according to the exception type; then, the reason for the exception of each data item is recorded in detail, and the corresponding verification rules and problem descriptions are associated; through the system message push mechanism, the list of exception data, exception type, exception reason and correction suggestions are pushed to the user terminal; the correction operation submitted by the user through the terminal is received, and the corrected metadata is obtained; finally, the corrected metadata is re-performed with multi-dimensional verification, and if there are still items that fail verification, the above process is repeated until all data passes verification.

[0096] Step S63: Perform format conversion and data reorganization on the verified original metadata to generate standardized report data.

[0097] It should be noted that format conversion refers to standardizing the original metadata according to the format rules defined in the target metadata template. This includes data type standardization, numerical format standardization (such as retaining two decimal places and adding thousands separators), and character encoding standardization. Data reorganization refers to rearranging and combining the original metadata according to the report structure, field order, and relationships of the target metadata template. This ensures that the data organization structure is consistent with the report template and supports requirements such as cross-table data association and multi-sheet data linkage. Standardized report data refers to report data with a unified structure, standardized format, and direct compatibility with the target metadata template after format conversion and data reorganization. It possesses the characteristics of accuracy, consistency, and standardization.

[0098] The core purpose of this step is to transform fragmented raw metadata into standardized data that meets the requirements for report building, eliminate data format differences and structural chaos, ensure that the data can be directly populated into the target metadata template, improve the efficiency and accuracy of report building, and at the same time ensure that the generated reports meet the format requirements of regulatory agencies.

[0099] In one possible implementation, the format conversion rules are consistent with the format conversion rule metadata in the target metadata template to ensure that the converted format meets the report output requirements; the data reorganization process supports cross-data source and cross-table data integration and can automatically match related data according to the association relationship defined in the template; standardized report data will be stored in a structured format, which is convenient for quick subsequent filling into the template and supports flexible adjustment.

[0100] Specifically, the process begins by reading the format conversion rules from the target metadata template and performing format conversion on the validated raw metadata. This converts date fields to a standard format, retains decimal places and adds thousands separators to numeric fields as required, and standardizes the encoding format for character fields. Then, based on the report structure, field order, and association rules of the target metadata template, the converted metadata is reorganized, arranging the data according to the report field order and establishing cross-table data associations and multi-sheet data linkage relationships. Finally, the standardized report data undergoes a simple validation to ensure uniform format, complete structure, and no missing or incorrect data, generating the final standardized report data.

[0101] This embodiment employs a multi-dimensional verification mechanism covering field-level, business-level, and compliance-level checks to comprehensively intercept format errors, logical conflicts, and non-compliant data, ensuring data accuracy. It also automatically marks abnormal data, records the reasons, and pushes instructions to user terminals to guide corrections, avoiding the tediousness and omissions of manual investigation and shortening the data rectification cycle. At the same time, compliance-level checks strictly adhere to regulatory standards, avoiding regulatory penalties caused by erroneous data reporting and ensuring report compliance.

[0102] In one feasible implementation, the step of building the report based on the target metadata template and the standardized report data to generate the target report includes: Step S71: Load the target metadata template and parse the report structure, field layout, and output format requirements in the target metadata template; It should be noted that the target metadata template refers to a standardized, executable metadata template that has been adjusted and optimized by the user and passed integrity verification. It is stored in JSON Schema format and contains all the core configuration information required for report creation. Loading refers to the process by which the system retrieves the target metadata template from the template repository and loads it into the report generation module. During the loading process, the version validity and integrity of the template are simultaneously verified. Report structure refers to the overall organizational form of the report, including the number of sheets, the functional division of each sheet, cross-sheet relationship logic, and hierarchical structure (such as tree-like grouping logic). Field layout refers to the specific location distribution of fields in the cells, the order of fields, primary / foreign key relationships, and required field identifiers. Output format requirements refer to the final presentation format of the report defined in the template, including file format (such as Excel, PDF), data display specifications (such as thousands separator, decimal places), header style, cell borders, and font format.

[0103] The core objective of this step is to clarify the report's construction standards and requirements by loading and parsing the key configurations of the target metadata template. This provides a precise basis for subsequent data population and format rendering, ensuring that the generated reports comply with regulatory standards and user needs. In one possible implementation, the template's version information and generation logs are read synchronously when loading the target metadata template, supporting version rollback. The parsing process uses a rule-based parsing engine to automatically identify multi-sheet linkage logic and cross-sheet calculation rules within the report structure. For complex field layouts, a visual layout diagram is generated for user reference. The output format requirements parsing distinguishes between required and optional configurations, ensuring that core format requirements are not overlooked.

[0104] Specifically, the process begins by retrieving the corresponding target metadata template from the centralized template repository based on the report identifier (such as report name and number), and verifying that the template version is the latest valid version. Next, the report structure information in the template is parsed to determine the number of sheets, cross-table association rules, and hierarchical grouping logic. Then, the field layout information is extracted to clarify the cell coordinates, arrangement order, data type, and relationships of each field. The output format requirements are then parsed to organize key information such as file format, data display specifications, and style configuration. Finally, the parsing results are organized into structured data to form a three-dimensional configuration list of "report structure - field layout - output format" for subsequent data filling and format rendering modules to call.

[0105] Step S72: Based on the report structure and the field layout, fill the standardized report data into the target metadata template, and allow users to fine-tune the filled target metadata template to build a report data model; It should be noted that standardized report data refers to structured data that has passed multi-dimensional verification and has been converted and reorganized into a unified format, characterized by standardized format, logical consistency, and data accuracy. "Filling" refers to the system accurately writing the corresponding fields from the standardized report data into the specified cell positions of the target metadata template according to the report structure and field layout configuration, achieving automatic matching between data and template. "Fine-tuning" refers to minor modifications made by users to the filled template through a visual configuration interface based on specific business needs. These modifications include adjusting cell data, changing field display names, adding remarks, and adjusting the field order; fine-tuning does not require modifying core rules. The report data model refers to the structured data model formed after data filling and user fine-tuning, containing complete data, field relationships, and cross-table logic, and is the direct basis for report format rendering.

[0106] The core objective of this step is to achieve precise integration of standardized data and templates, while simultaneously meeting users' personalized needs through flexible fine-tuning, constructing a logically rigorous and data-complete data model to lay the foundation for the final report generation. In one possible implementation, data filling employs an automatic matching mechanism between field names and template fields, supporting both batch and incremental filling; fine-tuning operations are implemented through an Excel-like visual interface, supporting drag-and-drop adjustments of field positions and direct editing of cell content; the system records user fine-tuning operation logs for easy traceability and rollback; after the report data model is built, data consistency verification is performed to ensure the accuracy of cross-table data references.

[0107] Specifically, firstly, based on the field layout of the target metadata template, a mapping relationship is established between standardized report data and template fields to ensure consistency in field names and data types. Then, the standardized report data is automatically filled into the corresponding cell positions in the template according to the mapping relationship, realizing synchronous filling of multi-sheet data and automatic matching of cross-table related data. Next, a visual fine-tuning interface is provided, supporting users to directly edit cell data, add notes, adjust field order, and other operations, with real-time synchronous preview of the fine-tuning results. Finally, the data filling and fine-tuning operations are integrated to build a report data model containing complete data, field relationships, and cross-table logic, synchronously recording data sources and adjustment logs.

[0108] Step S73: According to the output format requirements, perform report format rendering on the report data model to generate the target report.

[0109] It should be noted that the output format requirements refer to the final report presentation standards defined in the target metadata template, including file format, data display specifications, style configuration, etc. Report format rendering refers to the process by which the system visualizes the report data model according to the output format requirements, including style application, format conversion, layout optimization, and other operations. The target report refers to the final report generated after format rendering, which can be directly used for regulatory submissions. It is characterized by clear structure, standardized format, accurate data, and compliance with regulatory requirements. File formats supported include Excel, PDF, and others.

[0110] The core purpose of this step is to transform the abstract report data model into an intuitive and standardized visual report, ensuring that the report format meets the reporting requirements of regulatory agencies and the viewing habits of users, while guaranteeing the professionalism and readability of the report, and ultimately achieving the goal of self-service report building.

[0111] In one possible implementation, the format rendering supports batch processing of multiple reports, improving generation efficiency; for Excel format reports, it supports automatic setting of cell formats, freezing of headers, and adding data filtering functions; for PDF format reports, it supports adding watermarks, page numbers, and signature areas; during the rendering process, a report generation log is generated synchronously, recording information such as rendering time, format configuration, and data volume for audit traceability; the generated target report supports online preview, download, and direct submission interface integration.

[0112] Specifically, the process begins by loading the output format requirements from the target metadata template, clarifying rules such as file type, data display specifications, header style, and cell configuration. Then, the report data model is rendered using preset font, color, border, and alignment settings, and the data display format is configured (e.g., numbers are kept to two decimal places, and dates are uniformly formatted as "YYYY-MM-DD"). Next, based on the file format requirements, the rendered report data is converted to the corresponding file type (e.g., Excel or PDF), optimizing the file layout and formatting. Finally, the target report is generated, allowing users to preview it online. The report file is stored in a specified location, and the report generation log is simultaneously recorded in the end-to-end log module for subsequent auditing and traceability.

[0113] This embodiment analyzes the core requirements of the target metadata template to ensure accurate matching between standardized data and template structure and field layout. It replaces manual input with automatic filling, significantly improving report building efficiency. It also allows users to flexibly adjust the filled template to adapt to special business needs, balancing standardization and personalization to enhance report usability. Furthermore, it constructs a structured report data model through filling and fine-tuning, clarifying data relationships and ensuring rigorous report logic and data integrity. The entire process requires no coding, relying on template guidance and visual operation. Business users can independently complete report building, reducing dependence on the IT team. In addition, it supports complex report structures such as multi-sheet linkage and cross-sheet calculations to meet the diverse layout and data association requirements of regulatory reports.

[0114] For example, to help understand the system architecture of the prompt word generation method, please refer to... Figure 3 , Figure 3 The system architecture diagram provided for the report building method in this application.

[0115] Specifically, this overall architecture achieves end-to-end management of report templates from user interaction to data storage: First, users operate through the visual configuration interface, merge configuration interface, and template management interface (with front-end tools 1 and 2, which can be VUE2 or Univer) in the user interface layer. For example, in the visual configuration interface, the initial metadata template framework is loaded and the field layout is adjusted. The front-end operation request is passed to the application service layer, where the template parsing service handles the template parsing requirements (such as parsing the report structure of the target metadata template), the log tracking service records the entire process operation (such as template generation logs), and the template management service is responsible for the version and permission management of the template. Next, the metadata template definition module in the metadata engine layer builds the template structure (such as defining the association between report fields and data types), the template storage management module handles the temporary storage and updating of templates, and the rule parsing engine executes the verification rules (such as multi-dimensional data verification). Finally, the relational database in the data access layer provides the original metadata, the log repository stores operation and exception logs, and the template repository stores the target metadata template. For example, the target metadata template of the "Annual Summary Report" is persisted to the template repository, and the data verification exception logs are written to the log repository, realizing end-to-end support from user operation to template implementation.

[0116] It should be noted that the examples in the figure are only for understanding this application and do not constitute a limitation on the prompt word generation method of this application. Any simple transformations based on this technical concept are all within the protection scope of this application.

[0117] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0118] This application also provides a report building device, the report building device comprising: The acquisition module is used to acquire report specification documents and user configuration instructions; The parsing module is used to parse the report specification document using natural language models and visual technology, generate an initial metadata template framework, and receive user adjustments to the initial metadata template framework through a visual configuration interface to form a target metadata template. The verification module is used to obtain raw metadata from the target data source, perform multi-dimensional verification on the raw metadata, and generate standardized report data. The module is used to build reports based on the target metadata template and the standardized report data, and generate the target report.

[0119] The report building apparatus provided in this application, employing the report building method in the above embodiments, can solve the technical problems in the background art. Compared with the prior art, the beneficial effects of the report building apparatus provided in this application are the same as those of the report building method provided in the above embodiments, and other technical features in the report building apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0120] This application provides a report building device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the report building method in the above embodiment 1.

[0121] The following is for reference. Figure 4 The diagram illustrates a structural schematic of a report building device suitable for implementing embodiments of this application. The report building device in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 4 The report building equipment shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0122] like Figure 4As shown, the report building device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the report building device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touch screen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the report building device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows report building devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0123] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0124] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0125] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the report building methods provided by the above methods.

[0126] The system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0127] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0128] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A method for building reports, characterized in that, include: Obtain the report specification document and user configuration instructions; The report specification document is analyzed using natural language models and visual technology to generate an initial metadata template framework. The user's adjustment operations on the initial metadata template framework are received through a visual configuration interface to form the target metadata template. The raw metadata is obtained from the target data source, and multi-dimensional validation is performed on the raw metadata to generate standardized report data. The target report is generated by building a report based on the target metadata template and the standardized report data.

2. The report building method as described in claim 1, characterized in that, The process of parsing the report specification document using natural language models and visual technology to generate an initial metadata template framework includes: A pre-trained natural language model in the financial field is used to perform semantic parsing on the text content in the report specification document, identify and establish the relationship between various report elements, including report fields, data types, business verification rules and reporting cycles; The table sample in the report specification document is analyzed by object detection algorithm and text recognition technology to determine the cell position and cell text of the table sample, and to generate the text table mapping relationship between each cell position and each cell text. Based on the financial knowledge graph, the report fields are matched with standard data source fields to determine the data mapping suggestions corresponding to the report fields; Based on the relationship between the report elements, the mapping relationship between the text tables, and the data mapping suggestions, the initial metadata template framework is generated.

3. The report building method as described in claim 2, characterized in that, The process employs a pre-trained natural language model from the financial field to perform semantic parsing on the text content of the report specification document, identifying and establishing the relationship between various report elements, including: The report specification document is preprocessed by converting the non-editable format document in the report specification document into editable text, removing redundant format symbols and dividing it into several text segments; After loading the natural language model and performing word segmentation, part-of-speech tagging, and named entity recognition on each text segment, the report fields, data types, business verification rules, and reporting cycles in each text segment are extracted to form several report elements. The financial knowledge graph is invoked to perform consistency checks on each of the aforementioned report elements and to establish the relationship between the report elements.

4. The report building method as described in claim 2, characterized in that, The step of performing structural analysis on the table samples in the report specification document using object detection algorithms and text recognition technology to determine the cell positions and cell text of the table samples, and generating text table mapping relationships between each cell position and each cell text, includes: The table sample is converted into a standardized image, and an image denoising algorithm is used to process interfering pixels. The cell positions of the table sample are then identified using a target detection algorithm. Text recognition technology is used to extract the cell text in each cell of the table example, and the cell coordinates corresponding to each cell text are determined; Based on the cell coordinates corresponding to each cell text, a text table mapping relationship between each cell position and each cell text is generated.

5. The report building method as described in claim 1, characterized in that, The step of receiving user adjustments to the initial metadata template framework through a visual configuration interface to form a target metadata template includes: The initial metadata template framework is loaded through a visual configuration interface; After receiving the user's adjustment operation on the initial metadata template framework through the rule component library, the adjustment operation is converted into executable logic instructions; According to the executable logic instructions, the initial metadata template framework is adjusted and its integrity is verified to form the target metadata template.

6. The report building method as described in claim 1, characterized in that, The step of performing multi-dimensional validation on the original metadata to generate standardized report data includes: Establish and perform multi-dimensional verification on the original metadata based on a multi-dimensional verification mechanism; If the verification fails, the original metadata is marked as abnormal, and the reason for the abnormality is recorded and pushed to the user terminal to receive the user's correction operation on the original metadata. The verification is then re-executed until the verification passes. The original metadata that has passed verification is formatted and reorganized to generate standardized report data.

7. The report building method as described in claim 1, characterized in that, The process of building a report based on the target metadata template and the standardized report data to generate the target report includes: Load the target metadata template and parse the report structure, field layout, and output format requirements in the target metadata template; Based on the report structure and field layout, the standardized report data is populated into the target metadata template, and users can fine-tune the populated target metadata template to build a report data model. According to the output format requirements, the report data model is rendered to generate the target report.

8. A report building device, characterized in that, include: The acquisition module is used to acquire report specification documents and user configuration instructions; The parsing module is used to parse the report specification document using natural language models and visual technology, generate an initial metadata template framework, and receive user adjustments to the initial metadata template framework through a visual configuration interface to form a target metadata template. The verification module is used to obtain raw metadata from the target data source, perform multi-dimensional verification on the raw metadata, and generate standardized report data. The module is used to build reports based on the target metadata template and the standardized report data, and generate the target report.

9. A report generation device, characterized in that, The report building device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the report building method as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the report building method as described in any one of claims 1 to 7.

Images