Contract generation method and equipment based on low-code platform, and medium

Abstract

The embodiment of the invention discloses a contract generation method and device based on a low-code platform and a medium, and relates to the technical field of low-code development, and the method comprises the steps: obtaining a contract creation demand form inputted by a user through a form interface corresponding to the low-code platform, the contract creation demand form comprises contract dynamic data and contract attribute information; based on the contract attribute information, a corresponding contract template file is loaded on a front-end page through a preset plug-in, contract configuration information corresponding to the contract template file is determined, and the contract configuration information comprises form fields and business logic rules; and according to the contract configuration information, performing front-end and back-end verification on the contract dynamic data, and when the cooperative verification is passed, performing dynamic matching on the contract dynamic data and the contract template file to generate a target contract file.

Description

Technical Field

[0001] This specification relates to the field of low-code development technology, and in particular to a contract generation method, device and medium based on a low-code platform. Background Art

[0002] In the existing technology, contract generation mainly relies on two methods: traditional template tools and customized development systems. The traditional method usually uses a combination of preset document templates and manual filling, and replaces basic fields through the document merge function in office software (such as Microsoft Word). Systems with a higher degree of automation are built on a code development platform and perform batch generation by establishing a mapping relationship between database fields and template bookmarks. However, existing template systems mostly use a fixed field mapping mechanism and cannot dynamically adapt to the complex logical rules of different business scenarios. When multiple contract templates or dynamic clause combinations are involved, matching rules need to be redeveloped, resulting in high system maintenance costs. In addition, traditional methods usually only perform basic format verification on the front end. Different contract templates may involve multiple business rules, and compliance verification at the business logic level cannot be achieved, resulting in risks in generating contracts, which in turn causes the contract generation process to be unable to meet the needs of various business scenarios.

[0003] Therefore, the traditional contract generation process uses a fixed field mapping method, which cannot dynamically adapt to the complex logical rules of different business scenarios, and the verification method is single, resulting in the contract generation process being unable to meet the needs of various business scenarios. Summary of the Invention

[0004] One or more embodiments of this specification provide a contract generation method, device and medium based on a low-code platform to solve the following technical problems: the traditional contract generation process adopts a fixed field mapping method, which cannot dynamically adapt to the complex logical rules of different business scenarios, and the verification method is single, resulting in the contract generation process being unable to meet the needs of various business scenarios.

[0005] One or more embodiments of this specification adopt the following technical solutions:

[0006] One or more embodiments of the present specification provide a contract generation method based on a low-code platform, the method comprising: obtaining a contract creation requirement form input by a user through a form interface corresponding to the low-code platform, wherein the contract creation requirement form includes contract dynamic data and contract attribute information; based on the contract attribute information, loading the corresponding contract template file on the front-end page through a preset plug-in, and determining the contract configuration information corresponding to the contract template file, wherein the contract configuration information includes form fields and business logic rules; performing front-end and back-end verification on the contract dynamic data according to the contract configuration information, and when the collaborative verification passes, dynamically matching the contract dynamic data with the contract template file to generate a target contract file.

[0007] One or more embodiments of this specification provide a contract generation device based on a low-code platform, including:

[0008] at least one processor; and,

[0009] a memory communicatively connected to the at least one processor; wherein,

[0010] The memory stores instructions that can be executed by the at least one processor. The instructions are executed by the at least one processor to enable the at least one processor to perform the above method.

[0011] One or more embodiments of this specification provide a non-volatile computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured to execute the above method.

[0012] At least one of the above technical solutions adopted in the embodiments of this specification can achieve the following beneficial effects: Through the technical solutions of the embodiments of this specification, in order to address the defects of rigid field mapping and single verification logic in traditional contract generation, by building a dynamic, rule-driven contract generation system, the system's adaptability to complex business scenarios and the accuracy of data processing are significantly improved, the business rules and template configurations are deeply decoupled, and the flexible definition and automatic execution of contract generation logic are realized, providing highly scalable technical support for multi-dimensional business needs; the traditional fixed field mapping mode relies on pre-hard-coded field correspondences. When business rules change, the mapping logic needs to be redeveloped, and it is difficult to cope with complex scenarios such as dynamic clauses and conditional branches. The embodiments of this specification abstract business logic rules into configurable parameters through the dynamic association of contract attribute information and template configuration information, and embed them into the form design of the low-code platform. In the calculator, for example, for the differentiated liquidated damages calculation logic for procurement contracts and lease contracts, developers can define conditional judgment rules and formulas through a graphical interface without modifying the underlying code; the traditional single verification method can only implement basic format verification and cannot cover complex business rules and multi-system data collaboration. The embodiment of this specification builds a multi-level and multi-dimensional data verification network through a front-end and back-end collaborative verification system; the innovative design of the dynamic matching mechanism further enhances the system's scenario adaptability. Traditional template filling usually uses static field replacement and cannot handle requirements such as selective display of clauses and dynamic expansion of the number of table rows. The embodiment of this specification drives the document generation engine to perform intelligent content arrangement by parsing the business logic rules in the contract configuration information; in addition, through the technical collaboration of the low-code platform and the PageOffice plug-in, the openness and maintainability of the contract generation process are reconstructed. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the following briefly introduces the drawings required for the embodiments or the description of the prior art. Obviously, the drawings described below are only some of the embodiments described in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without inventive work. In the drawings:

[0014] Figure 1 A flowchart of a contract generation method based on a low-code platform provided in an embodiment of this specification;

[0015] Figure 2 A flowchart of another contract generation method based on a low-code platform provided in an embodiment of this specification;

[0016] Figure 3 A structural diagram of a contract generation device based on a low-code platform provided in an embodiment of this specification. DETAILED DESCRIPTION

[0017] To help those skilled in the art better understand the technical solutions in this specification, the following will provide a clear and complete description of the technical solutions in the embodiments of this specification, in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of this specification without creative work should fall within the scope of protection of this specification.

[0018] The embodiments of this specification provide a contract generation method based on a low-code platform. It should be noted that the execution entity in the embodiments of this specification can be a server or any device with data processing capabilities. Figure 1 A flowchart of a contract generation method based on a low-code platform provided in an embodiment of this specification is as follows: Figure 1 As shown, it mainly includes the following steps:

[0019] Step S101: Obtain the contract creation requirement form entered by the user through the form interface corresponding to the low-code platform.

[0020] The contract creation requirement form includes contract dynamic data and contract attribute information;

[0021] In one embodiment of this specification, the process of building a contract creation request form within a low-code platform relies on the platform's visual form designer. Developers design the interface layout by dragging and dropping pre-configured form components (such as input boxes, drop-down selectors, and date pickers), and bind each component to the corresponding data model fields. Form design must adhere to the requirements of the contract business scenario. For example, for a procurement contract, dynamic data input items such as supplier name and product details must be configured, while contract attribute information, including metadata attributes such as contract type, business identifier, and template version, is implemented through independent drop-down components or category bookmarks. The form's front-end interaction logic must be configured through the low-code platform's logic orchestration module. When a user triggers a form submission, the platform automatically executes the data collection process: first, the user's form input is structured and encapsulated, separating the dynamic data and attribute information into independent data objects. Dynamic data objects are serialized based on field type (for example, the amount field is automatically converted to floating-point data), while attribute information is filtered for validity based on a preset enumeration value range, for example, limiting contract types to only platform-defined options such as "Technical Services" and "Goods Procurement."

[0022] During the data submission phase, the low-code platform synchronously transmits form data to the backend service via a built-in API gateway. During transmission, the platform automatically appends security verification information such as user identity tokens and session identifiers to ensure the security of the data link. After receiving the form data, the backend service first parses the contract attribute information, maps it to the corresponding data processing channel using the business type code, and retrieves the corresponding validation rule set based on the template version number, providing baseline parameters for subsequent dynamic data validation. During the preprocessing of form data, the platform performs preliminary cleansing based on the metadata definitions configured for the fields. For example, date fields are automatically converted to a standard timestamp format, and a JSON array structure is generated for checkboxes in multi-select clauses. During this process, the platform's built-in exception interceptor monitors data conversion anomalies in real time. When illegal characters or formatting errors are detected, a partial refresh mechanism on the frontend page is immediately triggered, displaying a visual error prompt next to the corresponding form component to guide the user in making data corrections. After data preprocessing is complete, dynamic data is logically associated with attribute information and stored. The platform ensures the atomic writing of two types of data through a distributed transaction mechanism, uses a document-based database to store the specific content of dynamic data, and records the associated index of contract attribute information in a relational database. It can also automatically generate a globally unique contract identification code during the storage process.

[0023] Through the above technical solution, the intelligent collection of contract creation requirement forms is realized through the low-code platform, which shows multi-dimensional technical advantages compared to the traditional form construction mode. Under the traditional development model, the creation of contract requirement forms needs to go through a complete development cycle including demand analysis, UI design, front-end coding, back-end interface development and data verification rule writing, which is usually time-consuming and has high cross-departmental collaboration costs. The embodiment of this specification relies on the visual form designer of the low-code development platform, which can directly drag and drop preset components (such as linked drop-down boxes, dynamic tables) to complete the form layout, and define the explicit and implicit logic and data constraint rules between fields in a configured manner, compressing the form construction cycle to hours. For example, when it is necessary to add a new field specific to a cross-border trade contract (such as an INCOTERMS clause selector), there is no need to wait for the development schedule, and business personnel can independently complete the component addition and logic configuration.

[0024] Step S102: Based on the contract attribute information, the corresponding contract template file is loaded on the front-end page through a preset plug-in, and the contract configuration information corresponding to the contract template file is determined.

[0025] The contract configuration information includes form fields and business logic rules.

[0026] Based on the contract attribute information, before loading the corresponding contract template file on the front-end page through the preset plug-in, the method further includes: pre-defining a plurality of standard contract template files corresponding to business scenarios,

[0027] Among them, the standard contract template file includes fixed text content and replaceable bookmark tags generated by local software editing; a bookmark named with a specific prefix is set in the replaceable bookmark tag of the standard contract template file, and based on the fixed text content, the multiple form fields corresponding to each standard contract template file are determined; through the multiple bookmarks and the multiple form fields, the contract configuration information corresponding to each standard contract template file is determined, and the standard contract template file and the contract configuration information are uploaded to the low-code development platform to build a contract template library.

[0028] In one embodiment of the present specification, during the standardized implementation process of building a contract template library, a benchmark contract template that meets the needs of various business scenarios is first created using a local document editing tool (such as Microsoft Word). The template document is divided into a fixed clause area and a dynamic content area, and bookmarks in a specific format are inserted into the clause positions that need to be dynamically filled. For example, a "#FIELD_ContractAmount" bookmark is inserted into the contract amount clause, where "#FIELD_" is the preset prefix identifier and the suffix part uses camel case naming to correspond to the business field name. At the same time, it is necessary to ensure that the physical position of the bookmark mark is consistent with the semantic logic of the contract text to avoid dislocation of the content after dynamic filling due to changes in the paragraph structure. After the template document is edited, a dedicated parsing tool is used to perform a structural analysis of the template file. The tool automatically scans all bookmark tags that begin with a preset prefix in the document and extracts their full names as field identifiers. For example, when the "#FIELD_EffectiveDate" bookmark is detected, the system identifies "EffectiveDate" as the associated field name. At the same time, contextual semantic analysis is performed in combination with the fixed text content of the template to determine the business attributes of each field. For example, in a template that includes the clause "Party A shall complete payment within [#FIELD_PaymentDays] working days," it will be automatically determined that the "PaymentDays" field needs to be associated with a numeric form component, and it will be inferred that the field should be configured with a numeric range validation rule.

[0029] When generating contract configuration information based on the parsing results, bookmark tags are bidirectionally mapped to form fields. Each bookmark tag corresponds to the input type, validation rules, and business logic constraints of the configuration field. For example, the "#FIELD_ContractAmount" bookmark associates the amount input component and automatically adds configuration parameters such as the currency unit and decimal point precision. At the same time, field dependency rules are set based on the logical relationship between template clauses. For example, when "#FIELD_ContractType" is selected as "Annual Framework Agreement", the mandatory status of the "#FIELD_RenewalClause" field is automatically activated. These configuration information is stored in a structured data format (such as JSON), forming a metadata description file that is strongly associated with the template file.

[0030] After completing the local template configuration, batch upload operations are performed through the template management interface provided by the low-code platform. During the upload process, template compliance checks are automatically performed to verify whether the bookmark naming complies with the prefix specification, detect whether there are isolated bookmarks with unconfigured fields, and confirm the compatibility of the form fields with the platform's existing component library. The verified template files and their configuration information will be classified and stored in the platform document library, and index relationships will be established according to dimensions such as business type, applicable area, and version number. For example, the procurement contract template forms a three-level directory structure according to "Business Type = Procurement", "Region = APAC", and "Version = V2.3", which is convenient for subsequent accurate retrieval. The final template library supports version traceability. When the template is updated, the historical version configuration information is retained to ensure the traceability of the generated contract.

[0031] Based on the contract attribute information, before loading the corresponding contract template file on the front-end page through a preset plug-in, the method also includes: querying the permission configuration table of the low-code platform according to the pre-acquired user role identifier and the business type in the contract attribute information; according to the permission configuration table, determining whether the user has access rights to the contract template file corresponding to the business type, and if so, loading the corresponding contract template file on the front-end page.

[0032] In one embodiment of this specification, a multi-dimensional permission configuration table must first be established on the platform management side. The permission configuration table can adopt a matrix data structure, with the horizontal dimension storing user role identifiers (such as legal affairs specialist, procurement manager, etc.) and the vertical dimension defining business type codes (such as PROCUREMENT-001, LEASE-002, etc.). The matrix intersection nodes record the specific permission status (access allowed / access denied). Each business type code is associated with a specific template file group. For example, PROCUREMENT-001 corresponds to a set of five templates including a standard procurement contract and a supplementary agreement. The permission configuration table is maintained through a visual interface, allowing administrators to intuitively view the template access rights map for each role in different business scenarios. When a user initiates a contract creation request, the user role identifier is first extracted from the identity authentication service, such as parsing the "contract_reviewer" role from the JWT token. The business type code in the contract attribute information is also parsed, such as obtaining the "INTL_SALES" identifier from the form submission data. These two key parameters are encapsulated into a permission query request and transmitted to the permission service engine via an internal API call. The service engine uses a distributed caching mechanism to accelerate queries, combining roles and business types as cache keys, and returning permission determination results within milliseconds.

[0033] When a user role has cross-business line permissions, such as a Senior Legal Director with approval authority for multiple business types, the most granular permission rules are automatically matched based on the business type code. For example, if a user holds permissions for both "DOMESTIC_LEASE" and "INTL_LEASE" business types, when processing international lease contracts, the English template library corresponding to "INTL_LEASE" will be accurately selected. For special cases where no explicit permissions are configured, permission inheritance rules are triggered. For example, when a new "CLOUD_SERVICE" business type is added, it automatically inherits the default permission settings for other service contracts in the same product line.

[0034] After completing permission verification, the template loading decision is executed. If permission verification passes, the front-end plug-in retrieves a list of templates that match the business type and user role from the template library and dynamically renders them to the page component using asynchronous loading technology. Template version control is implemented during the loading process, automatically selecting the latest version currently in effect or the user-specified historical version. For restricted templates, a hierarchical prompt mechanism is implemented: ordinary users receive a standard permission shortage prompt, while users with application permissions are displayed a template preview summary with an entry for applying for permission escalation, achieving flexible permission management.

[0035] Through this technical solution, a dynamic permission verification mechanism overcomes the limitations of the traditional static permission model, achieving both enhanced security and flexibility. Traditional approaches rely on pre-configured fixed role-template mapping tables, requiring a complete readjustment of the entire permission system as business types expand. This solution, however, isolates permissions based on business type, allowing new business lines to independently configure permission rules. For example, when adding a cross-border e-commerce business, only the "EC_INTERNATIONAL" column in the permission matrix needs to be expanded, eliminating the need to modify the permissions for existing businesses like procurement and leasing, effectively reducing configuration workload. This modular permission management enables the system to support exponential business expansion and avoids the performance degradation caused by permission table expansion in traditional architectures. Furthermore, while traditional permission checks typically perform end-point interception during file downloads, this solution performs access control before templates are loaded, effectively preventing the leakage of sensitive template metadata. Traditional permission models directly interrupt operations when a user's permissions are insufficient, while this solution introduces a permission substitution mechanism: when a user's preferred template is unavailable, an alternative template with equivalent legal validity is automatically recommended, highlighting the differences for the user to confirm. For example, when a regional sales manager applies for a headquarters-exclusive template, the system recommends a regional customized template and automatically fills in existing data to maintain the continuity of business processes. This flexible processing reduces business interruption rates and is particularly suitable for multinational companies' multi-time zone collaboration scenarios.

[0036] Based on the contract attribute information, the corresponding contract template file is loaded on the front-end page through the preset plug-in, specifically including: parsing the business type information and template version information in the contract attribute information; according to the business type information and template version information, retrieving the corresponding contract template file from the contract template library of the low-code platform, wherein the contract template library pre-stores multiple contract template files, and each contract template file is associated with at least one business type identifier and version number; loading the retrieved contract template file on the front-end page through the preset plug-in, and activating the editable state of the contract template file.

[0037] In one embodiment of this specification, during the dynamic loading process of contract templates, the low-code platform's metadata parsing engine first performs in-depth processing of contract attribute information. A structured business type code and semantic version identifier are extracted from the user-submitted form data. The business type code uses a three-part structure to identify the business area, subcategory, and applicable year. Version information follows the semantic versioning specification: the major version number identifies significant changes to terms, the minor version number corresponds to regular revisions, and the revision number indicates adjustments to the template format. Data cleansing is automatically performed during the parsing process, converting ambiguous user-entered expressions (such as "Latest Technical Service Contract") into standard business type identifiers within the platform. The contract template library utilizes a multi-level storage architecture: a hot data layer stores precompiled versions of frequently accessed templates, while a cold data layer archives historical versions of templates. During retrieval, the prefix of the business type code (such as "SVC") is used to quickly locate the business area partition, and an inverted index is used to match specific subcategory identifiers. Version matching utilizes a sliding window algorithm, automatically selecting the closest compatible version when the exact version does not exist (e.g., a request for V2.1.5 returns the latest available version in the V2.1.x series).

[0038] In one embodiment of the present specification, the preset plug-in can be a PageOffice plug-in, which parses the template file structure through the PageOffice plug-in and decomposes the document into editable blocks (such as the main terms of the contract, the signature column, and the attachment directory). Each editable block is bound to the field identifier of the dynamic data model and automatically mapped to the corresponding position of the front-end form component during rendering. For example, the contract amount clause block is associated with the amount input component, and interactive functions such as automatic matching of currency symbols and thousandths formatting are activated at the same time. The plug-in also implements a difference visualization mechanism. When there are structural changes between the current and subsequent versions of the template, the user is prompted by color markings to add / modify the clause area. The granularity of editing permissions is dynamically adjusted according to the user role. Legal specialists can modify the text of the clause but lock the signatory information area. Business personnel have the right to edit the data field but are prohibited from modifying the clause template.

[0039] Through the above technical solution, the traditional method of relying on manual retrieval of file directories to select templates is prone to technical problems such as version misuse. The embodiment of this specification uses a semantic version matching algorithm to ensure the timeliness and compliance of loaded templates. The version sliding matching mechanism further avoids business stagnation caused by strict version verification in traditional systems, and can still ensure business process continuity when local versions are unavailable. The embodiment of this specification uses metadata-driven automatic mapping technology to adaptively handle common iterative scenarios such as template field additions, deletions, and order changes. For example, when Template V3 adjusts "Payment Method" from an independent chapter to an appendix, the system can still accurately identify the field location and complete data filling, avoiding the data dislocation problem caused by template revisions in the traditional method.

[0040] Step S103: Perform front-end and back-end verification on the contract dynamic data according to the contract configuration information. When the collaborative verification passes, dynamically match the contract dynamic data with the contract template file to generate the target contract file.

[0041] According to the contract configuration information, the contract dynamic data is verified on the front-end and back-end, specifically including: matching the contract dynamic data with the form fields in the contract configuration information to determine the regular expression corresponding to the contract dynamic data; performing format verification on the contract dynamic data through the regular expression built into the front-end page, wherein the regular expression is predefined based on the field type of the form field; when the format verification passes, calling the rule engine of the low-code platform to perform logical compliance verification on the contract dynamic data according to the business logic rules in the contract configuration information.

[0042] In one embodiment of the present specification, the front-end and back-end verification implementation process of the dynamic contract data relies on the deep integration of the low-code development platform and the rule engine. First, in the contract configuration stage, the field types and business rules are predefined through the visual form designer of the low-code platform, and each form field is associated with the regular expression template corresponding to the field type. For example, the date type field is automatically bound to the date format regular expression, and the amount field has built-in currency value verification rules. These regular expressions are stored in the platform metadata database and form a strong association with the form configuration. When the user enters the contract data on the front-end page, the user input data is automatically mapped and matched with the form fields in the configuration by dynamically parsing the current contract configuration. This process achieves precise correspondence based on the field identifier, ensuring that each input item can accurately obtain its preset regular expression. The front-end page has pre-loaded the corresponding regular expression into the verification logic of the form component during the rendering stage. The format verification is triggered immediately when the user enters the input. Basic rules such as the ID number format and the number of digits of the bank account number are intercepted before the data is submitted, effectively reducing the transmission of invalid requests.

[0043] For data that has passed the front-end verification, the built-in rule engine of the low-code platform is called to perform in-depth logical compliance verification. The rule engine performs multi-dimensional cross-validation on the data by parsing the business logic rules preset in the contract configuration, such as the numerical correlation between the contract amount and the payment cycle, the temporal relationship between the signing date and the effective date, the dependency between the clause selection and the additional conditions, etc. This process adopts a declarative rule configuration method, abstracting the business logic into independently manageable rule units, and automatically performing complex verification through the reasoning mechanism of the rule engine to ensure the legality and rationality of the data at the business level. The verification results are fed back to the front end through a unified interface, forming a complete verification closed loop. For data that fails the verification, the system accurately locates the problem field and returns a specific error description to guide the user to make targeted corrections. The logs and error information generated during the verification process are synchronously recorded in the audit module to provide data support for subsequent process optimization and compliance review.

[0044] Compared with the traditional verification method, the embodiment of this specification realizes the dynamic management and intelligent execution of verification rules. The traditional method usually uses hard coding to implement verification logic, and regular expressions and business rules are scattered throughout the code, resulting in high rule maintenance costs and poor response to business changes. The embodiment of this specification uses the metadata management mechanism of the low-code platform to atomically bind the verification rules to the form fields. Rule changes only need to adjust the configuration in the visual interface to take effect globally, which significantly improves the efficiency of rule maintenance. In addition, the front end of the conventional verification mode only performs simple format checks, and deep business verification relies entirely on the back end implementation, resulting in delayed verification feedback and fragmented user experience. This example uses the front-end and back-end collaborative mechanism of the rule engine to implement real-time format verification on the front end while the back-end rule engine performs in-depth verification based on the same set of configuration rules, which not only ensures the immediacy of the verification response, but also ensures the integrity and consistency of the business rule verification; in addition, through the configurable characteristics of the rule engine, it effectively solves the long-tail verification needs in enterprise contract management. Business personnel directly configure verification rules through natural language or logical expressions, such as setting the effective conditions of region-specific clauses, special numerical ranges required by industry supervision, etc., which greatly enhances the system's adaptability to complex business scenarios and enables the contract management system to quickly respond to changes in policies and regulations and business model innovations.

[0045] Dynamically matching the contract dynamic data with the contract template file to generate a target contract file specifically includes: parsing a bookmark list in the contract template file through a preset plug-in, wherein the bookmarks in the bookmark list are named with a preset prefix and correspond one-to-one to the form fields; matching the bookmark list with the contract dynamic data according to the form fields in the contract template file to determine an element matching pair, wherein the element matching pair includes a form field and a matching bookmark; based on the element matching pair, writing the field value in the contract dynamic data corresponding to the form field that matches the bookmark name into the corresponding bookmark position in a preset document format to generate the target contract file.

[0046] After matching the bookmark list with the contract dynamic data, the method further includes: determining whether there are unmatched elements, where the unmatched elements include any one or more of unmatched form fields and unmatched bookmarks; when unmatched elements exist, triggering an exception handling service and returning the unmatched elements to the user.

[0047] In one embodiment of the present specification, the dynamic matching process of contract dynamic data and template files is implemented based on a preset document parsing engine and data mapping mechanism. By integrating the document parsing interface of the PageOffice plug-in, the bookmark tags in the contract template file are automatically scanned, and all bookmarks named with a preset prefix are extracted to form a structured bookmark list, such as "PO_". During the parsing process, bookmark format verification is performed simultaneously to exclude invalid bookmarks with irregular naming or missing prefixes, thereby ensuring the accuracy of the subsequent matching process. After removing the prefix of each valid bookmark, its core name establishes a logical association with the field identifier defined in the low-code platform form designer to form a preset naming mapping rule. In the data matching stage, the bookmark list and the contract dynamic data are matched according to the form fields in the contract template file to determine the element matching pair. It should be noted that the contract dynamic data corresponds to multiple form fields, and each form field has a corresponding bookmark in the contract template file.

[0048] After completing the basic matching, the data writing operation is executed. By calling the document operation interface of the PageOffice plug-in, the successfully matched field values are filled into the corresponding bookmark position according to the preset format of the template. This process strictly adheres to the format specifications of the original document, keeping the format features such as paragraph style and font attributes unchanged. For template areas containing complex structures such as tables and annotations, DOM tree traversal technology is used to accurately locate bookmark nodes to ensure the accuracy and format integrity of data insertion. The final generated contract document achieves accurate replacement of key data while maintaining the professional layout of the original template.

[0049] In addition, an exception detection mechanism is set up in the matching process to identify unmatched elements by comparing the symmetric difference between the bookmark list and the data field set. Unmatched elements cover two types of situations: there is a bookmark in the template but the form field corresponding to the bookmark does not exist in the dynamic contract data, or there is a form field that exists in the dynamic contract data but does not exist in the template. When an unmatched element is detected, the exception handling service is triggered, and the abnormal element type, location information and associated context are recorded in the error log. At the same time, a visual alert is pushed to the user through the front-end interface, indicating the specific unmatched items and their possible impact. For the missing of key fields, business rules can be configured to automatically terminate the process or start the default value filling strategy.

[0050] The above technical solution achieves intelligent dynamic matching of data and templates, locates fill positions by leveraging the Office bookmark feature, and implements automated content replacement through front-end and back-end data binding, significantly reducing system maintenance complexity and improving business agility. By decoupling document object model operations from business data logic, a standardized processing flow is formed through abstract bookmark parsing, data mapping, and format preservation. This allows for seamless adaptation to multiple document formats, including Word and WPS, and supports plug-and-play use of complex layout templates, significantly improving system scalability and cross-platform compatibility.

[0051] After generating the target contract file, the method also includes: obtaining the review level identifier and notification configuration information in the contract attribute information; based on the review level identifier, calling the approval routing service of the low-code platform, and pushing the target contract file to the designated approval node to approve the target contract file; when the approval is passed, parsing the notification configuration information in the contract attribute information, wherein the notification configuration information includes the message channel corresponding to the preset contact; based on the notification configuration information, sending a notification message to the preset contact through the message service of the low-code platform, wherein the notification message includes the contract identifier, generation time and contract file access link.

[0052] In one embodiment of the present specification, after the target contract file is generated, the preset review level identifier and notification configuration information are first extracted from the contract attribute information. The review level identifier defines the hierarchical structure of the approval process required for the current contract. For example, a simple contract may only require approval from the department head, while a complex contract must go through multiple nodes such as legal review, financial review, and senior management approval in sequence. The notification configuration information clarifies the notification method and recipient that need to be triggered after the contract is approved, specifically including the identity identifier of the preset contact person and its corresponding message channel type, such as email, SMS, enterprise instant messaging tool, or internal system notification. The system converts the review rules and notification policies into executable logical parameters by parsing the structured data in the contract attributes. Next, the approval routing service built into the system's low-code platform automatically matches the preset approval process template based on the review level identifier. The approval routing service pushes the target contract file to the corresponding first approval node through a visually configured rule engine, and dynamically binds the contract file metadata, approval path description, and related operation permissions to the approval task. Approver receives to-do items through the low-code platform's task center. They can directly view contract content and approval history on the web interface and perform approval, rejection, or referral actions. Approval status changes are monitored in real time, with rejections automatically returning to the contract editing stage and approvals triggering subsequent notifications.

[0053] When the contract approval process is fully passed, the message channel strategy and contact list defined in the notification configuration information are parsed. For each preset contact, according to the type of message channel registered (such as email, SMS or system message), the corresponding message service interface of the low-code platform is called to automatically generate dynamic notification content containing the contract ID, generation time and contract file access link. The message template supports a variable replacement mechanism to accurately embed contract-specific information into the notification text. At the same time, the access link uses encrypted token technology to ensure secure access to the contract file. For scenarios that require multi-channel concurrency, the system uses asynchronous message queues for distribution to ensure message delivery reliability in high-concurrency scenarios.

[0054] By deeply integrating the standardized service components of the low-code platform, the system complexity and development and maintenance costs have been significantly reduced. The approval routing service can directly reuse the company's existing approval process configuration, avoiding the repeated development of approval logic code. At the same time, it ensures that the contract approval process is consistent with the company's other business approval systems, which is conducive to achieving process collaboration and data integration across business systems. Adjustments to the approval level only need to be reconfigured through the visual interface to take effect, without the need for code-level modifications, greatly enhancing the system's agility in adapting to changes in business rules. At the notification mechanism level, the standardized interface call of the low-code platform message service realizes the unified management of multi-channel message triggers. Compared with the conventional operation of manually writing notification content, it not only improves the accuracy of information transmission, but also eliminates the risk of customer communication caused by human error. The approval process and notification strategy are implemented in a configurable manner, allowing business personnel to directly participate in the optimization and adjustment of process rules. When the company adds a new message channel type or approval node, it only needs to expand the corresponding service component on the low-code platform to quickly achieve functional upgrades without the need for structural transformation of the contract generation system.

[0055] Figure 2 A flowchart of another contract generation method based on a low-code platform provided in an embodiment of this specification is as follows: Figure 2 As shown, first create a new project based on the Haiyue inBuilder low-code development platform, and use the visual interface design and modular component functions provided by the platform to complete the construction of the system basic framework through drag-and-drop operations. Developers need to configure the form designer in the platform, define the field structure required for contract data entry, such as contract subject information, business terms, amount, date and other key parameters, and establish a mapping relationship with the back-end database. At the same time, integrate the PageOffice plug-in to the project front end, and realize the deep docking of the web page with the local Office / WPS software by calling its API interface, ensuring that users can directly activate the local office software in the browser to perform document operations.

[0056] Design a standard contract template in local Office software (such as Microsoft Word). The template content must include fixed clauses and variable data placeholders. Use Word's bookmark function to insert specific identifiers prefixed with "PO_" (for example, "PO_CompanyName" and "PO_ContractAmount") in variable locations. Each bookmark corresponds to a field that needs to be dynamically replaced when the contract is generated. Template design must follow formatting specifications to avoid formatting errors during subsequent replacements due to complex typesetting. After completing the template design, upload the template to the cloud or local server for storage using the system's attachment management module, and set up template classification, permission control, and version management mechanisms. Build data entry forms based on the low-code platform, and the form fields must match the variables defined in the bookmarks in the contract template one by one. During form development, use the platform's built-in rule engine to set data validation logic. For example, limit the numeric format and range for the amount field, verify the time sequence of the date field, and verify the compliance of the contract subject information with the corporate credit database. When users fill out the form on the front end, validation rules are triggered in real time, prompting and intercepting illegal input to ensure the integrity and legality of the submitted data.

[0057] After the user submits the validated form data, the backend service parses the contract template file, locates bookmarks beginning with "PO_," and populates the corresponding form field values into the document according to pre-set rules. During this process, the PageOffice plug-in maintains document format stability, ensuring that text replacement does not affect the original layout, tables, and chart structure. For scenarios requiring complex formatting adjustments (such as dynamic additions or deletions to clauses resulting in changes in pagination), the system implements adaptive layout by invoking Office software macros or pre-set style templates. After the content replacement is complete, a temporary contract file is generated for the user to preview online. Users can finalize the contract content in the front-end preview interface and return to the form to resubmit any changes. After confirmation, the contract can be exported to a standard PDF or retained in an editable Word format, automatically adding a digital watermark or electronic signature to enhance legal validity. All generated contracts are linked to the original template version and data snapshots. A log records the operator, time points, and modification history for full lifecycle traceability. Furthermore, the template library is regularly scanned for compliance, and template update notifications are sent based on changes in laws, regulations, or business rules to ensure the timeliness and legality of contract content.

[0058] Through the technical solutions of the embodiments of this specification, the defects of rigid field mapping and single verification logic in traditional contract generation are addressed. By building a dynamic, rule-driven contract generation system, the system's adaptability to complex business scenarios and the accuracy of data processing are significantly improved, the business rules and template configurations are deeply decoupled, and the flexible definition and automatic execution of contract generation logic are realized, providing highly scalable technical support for multi-dimensional business needs; the traditional fixed field mapping mode relies on pre-hard-coded field correspondences. When business rules change, the mapping logic needs to be redeveloped, which makes it difficult to cope with complex scenarios such as dynamic clauses and conditional branches. The embodiments of this specification abstract business logic rules into configurable parameters through the dynamic association of contract attribute information and template configuration information, and embed them into the form designer of the low-code platform, such as for procurement contracts and leasing contracts. With the differentiated liquidated damages calculation logic, developers can define conditional judgment rules and formulas through a graphical interface without modifying the underlying code; the traditional single verification method can only implement basic format verification and cannot cover complex business rules and multi-system data collaboration. The embodiment of this specification builds a multi-level and multi-dimensional data verification network through the front-end and back-end collaborative verification system; the innovative design of the dynamic matching mechanism further enhances the system's scenario adaptability. Traditional template filling usually uses static field replacement and cannot handle requirements such as selective display of clauses and dynamic expansion of table rows. The embodiment of this specification drives the document generation engine to perform intelligent content arrangement by parsing the business logic rules in the contract configuration information; in addition, through the technical collaboration of the low-code platform and the PageOffice plug-in, the openness and maintainability of the contract generation process are reconstructed.

[0059] The embodiment of this specification also provides a contract generation device based on a low-code platform, such as Figure 3 As shown, the device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed 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 perform the above method.

[0060] The embodiments of this specification also provide a non-volatile computer storage medium storing computer executable instructions, wherein the computer executable instructions are configured to execute the above method.

[0061] The various embodiments in this specification are described in a progressive manner. Similar portions between the various embodiments can be referenced to each other, and each embodiment focuses on the differences from the other embodiments. In particular, the device, apparatus, and non-volatile computer storage medium embodiments are generally similar to the method embodiments, so their descriptions are relatively simplified. For relevant details, refer to the descriptions of the method embodiments.

[0062] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0063] The devices and media provided in the embodiments of this specification correspond one-to-one to the methods. Therefore, the devices and media also have similar beneficial technical effects to their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices and media will not be repeated here.

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

[0065] This specification is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of this specification. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0066] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0067] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0068] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0069] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0070] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media (transitory media), such as modulated data signals and carrier waves.

[0071] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0072] The foregoing description is merely one or more embodiments of this specification and is not intended to limit this specification. It will be apparent to those skilled in the art that various modifications and variations may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of one or more embodiments of this specification are intended to be within the scope of the claims of this specification.

Claims

1. A contract generation method based on a low-code platform, characterized in that: The method comprises: Obtaining a contract creation requirement form input by a user through a form interface corresponding to the low-code platform, wherein the contract creation requirement form includes contract dynamic data and contract attribute information; Based on the contract attribute information, a corresponding contract template file is loaded on the front-end page through a preset plug-in, and contract configuration information corresponding to the contract template file is determined, wherein the contract configuration information includes form fields and business logic rules; According to the contract configuration information, the contract dynamic data is verified on the front and back ends. When the collaborative verification passes, the contract dynamic data is dynamically matched with the contract template file to generate the target contract file.

2. A contract generation method based on a low-code platform according to claim 1, characterized in that: Based on the contract attribute information, before loading the corresponding contract template file on the front-end page through the preset plug-in, the method further includes: Predefine standard contract template files corresponding to multiple business scenarios, wherein the standard contract template files include fixed text content and replaceable bookmarks generated by editing with local software; Setting a bookmark named with a specific prefix in a replaceable bookmark tag of the standard contract template file, and determining a plurality of form fields corresponding to each of the standard contract template files based on the fixed text content; Through the multiple bookmarks and the multiple form fields, the contract configuration information corresponding to each standard contract template file is determined, and the standard contract template file and the contract configuration information are uploaded to the low-code platform to build a contract template library.

3. A contract generation method based on a low-code platform according to claim 1, characterized in that: Based on the contract attribute information, before loading the corresponding contract template file on the front-end page through the preset plug-in, the method further includes: Query the permission configuration table of the low-code platform based on the pre-acquired user role identifier and the business type in the contract attribute information; According to the permission configuration table, it is determined whether the user has the access rights to the contract template file corresponding to the business type. If so, the corresponding contract template file is loaded on the front-end page.

4. A contract generation method based on a low-code platform according to claim 1, characterized in that: Based on the contract attribute information, the corresponding contract template file is loaded on the front-end page through the preset plug-in, specifically including: Parsing the business type information and template version information in the contract attribute information; According to the business type information and template version information, a corresponding contract template file is retrieved from a contract template library of the low-code platform, wherein the contract template library pre-stores a plurality of contract template files, and each contract template file is associated with at least one business type identifier and a version number; The retrieved contract template file is loaded on the front-end page through a preset plug-in, and the editable state of the contract template file is activated.

5. A contract generation method based on a low-code platform according to claim 1, characterized in that: According to the contract configuration information, the contract dynamic data is verified by front-end and back-end, specifically including: Matching the contract dynamic data with the form fields in the contract configuration information to determine a regular expression corresponding to the contract dynamic data; Performing format verification on the contract dynamic data using the regular expression built into the front-end page, wherein the regular expression is predefined based on the field type of the form field; When the format check passes, the rule engine of the low-code platform is called to perform logical compliance verification on the contract dynamic data according to the business logic rules in the contract configuration information.

6. A contract generation method based on a low-code platform according to claim 1, characterized in that: Dynamically matching the contract dynamic data with the contract template file to generate a target contract file specifically includes: Parsing a bookmark list in the contract template file by a preset plug-in, wherein the bookmarks in the bookmark list are named with a preset prefix and correspond one-to-one to the form fields; According to the form fields in the contract template file, the bookmark list and the contract dynamic data are matched to determine an element matching pair, wherein the element matching pair includes a form field and a matching bookmark; According to the element matching pair, the field value in the contract dynamic data corresponding to the form field matching the bookmark name is written into the corresponding bookmark position according to the preset document format to generate the target contract file.

7. A contract generation method based on a low-code platform according to claim 6, characterized in that: After matching the bookmark list with the contract dynamic data, the method further includes: Determining whether there are unmatched elements, wherein the unmatched elements include any one or more of unmatched form fields and unmatched bookmarks; When there is an unmatched element, the exception handling service is triggered and the unmatched element is returned to the user.

8. A contract generation method based on a low-code platform according to claim 1, characterized in that: After generating the target contract document, the method further includes: Obtaining the audit level identifier and notification configuration information in the contract attribute information; According to the review level identifier, the approval routing service of the low-code platform is called to push the target contract document to the designated approval node for approval of the target contract document; When the approval is passed, the notification configuration information in the contract attribute information is parsed, wherein the notification configuration information includes the message channel corresponding to the preset contact; According to the notification configuration information, a notification message is sent to the preset contact through the message service of the low-code platform, wherein the notification message includes the contract identifier, generation time and contract file access link.

9. A contract generation device based on a low-code platform, characterized in that: The device comprises: at least one processor; and, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor. The instructions are executed by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1 to 8.

10. A non-volatile computer storage medium storing computer executable instructions, characterized in that: The computer executable instructions are configured to execute the method according to any one of claims 1 to 8.

Images