A product identification method based on automatic generation of coding rules

Abstract

This invention discloses a product identifier method based on encoding rules for automatic generation, belonging to the field of product identifier encoding management technology, and is used to solve the problems of encoding chaos and identification difficulties. This invention constructs a closed-loop encoding generation mechanism that covers attribute standardization, rule chain compilation, candidate generation, conflict verification, full lifecycle binding, and log traceability. This ensures that product identifiers have uniqueness, structural integrity, and business applicability during the generation stage. Then, semantic alignment is achieved through field dictionary and alias comparison. Candidate identifiers are dynamically generated by combining exclusive constraints and value domain verification. The availability and consistency of identifiers are ensured through pre-occupied number segments, mapping verification, and rule change sandbox exercises. The platform supports binding external identifiers and lifecycle objects, improving master data management efficiency and system collaboration capabilities.

Description

Technical Field

[0001] This invention relates to the field of product identification coding management technology, and more specifically, to a method for automatically generating product identification based on coding rules. Background Technology

[0002] In the field of master data coding and identification management, existing systems generally use rule templates combined with manual operations to generate product identifiers. These methods rely on fixed field concatenation strategies to manually combine basic product information into a unique code. While the structural design can support basic differentiation between different product lines, in a multi-entry, multi-system parallel collaborative environment, current technical solutions still have significant shortcomings in terms of standardization, data accuracy, and the traceability of the generation logic.

[0003] Specifically, existing coding systems often struggle to normalize attributes and make compliance decisions when there are significant differences in attribute sources, inconsistent field semantics, and missing format processing rules. This leads to ambiguity or duplicate conflicts in the identification content. Furthermore, it is difficult to assess the impact of rule chain changes on already effective identifiers. The lack of version control, sandbox simulation, and canary release mechanisms can easily cause problems such as incorrect product identifier mapping in enterprise information systems, master data synchronization failures, or supply chain fulfillment interruptions. As a result, the lack of structured logging and process traceability mechanisms during the generation path and release process creates obstacles for auditing, security compliance, and master data rollback, thus restricting the evolution capabilities of the coding system and the efficiency of platform-level integration. Summary of the Invention

[0004] In order to overcome the above-mentioned defects of the prior art, the following solutions are proposed to solve the problems of encoding confusion and recognition difficulties in the aforementioned background technology.

[0005] To achieve the above objectives, the present invention provides the following technical solution: A method for automatically generating product identifiers based on coding rules includes the following steps: The coding generation platform receives basic product or material data from multiple business entry points, performs attribute normalization and semantic standardization based on a unified time base and field dictionary, and forms a standardized attribute set with source identifiers. Attribute templates are selected based on the target product category and rule chains are compiled. Candidate identifiers are generated and combined segment by segment. Exclusivity constraints and value range restrictions are applied to the candidate identifiers. Candidates that do not meet the preset boundary conditions are eliminated to obtain a candidate combination list. Within the preset generation window, apply for a pre-reserved number segment for the candidate combination, perform near-duplicate and cross-database mapping checks, block and return adjustment suggestions when there are conflicts, and confirm the pre-reservation and proceed to the next process when there are no conflicts. For pre-acquisition successful candidate combinations, structural integrity, semantic consistency and business availability are checked. When the check passes, an internal primary key and alias code are generated and bound to the product lifecycle object. At the same time, the mapping relationship with the external industry identifier is recorded. Based on the binding results, a machine-readable carrier is generated and published to the enterprise information system. When the attribute template or rule chain changes, an impact domain assessment is performed and the changes take effect in stages, and the generation and publication link logs are saved.

[0006] Furthermore, the encoding generation platform receives basic product or material data from multiple business entry points, performs attribute normalization and semantic standardization based on a unified time base and field dictionary, and forms a standardized attribute set with source identifiers. Specific steps include: Under a unified time reference, the sampling time and arrival time are written for each data record, the arrival offset is calculated and the time alignment is completed; Establish a field dictionary and alias mapping relationship, and standardize field names, data types, and value formats; Perform synonym merging and ambiguity resolution on names, specifications, models, process parameters, and customer-customized items to generate standard descriptions; The units of measurement, accuracy range, and decimal places are standardized to unify the numerical values ​​into the preset measurement system. Conflicting fields are adjudicated according to preset priorities and source credibility, and the basis for the adjudication and the processing results are recorded; Write the source identifier, operator, timestamp, and processing status for each attribute, and output a standardized set of attributes with the source identifier.

[0007] Furthermore, based on the target product category, attribute templates are selected and rule chains are compiled. Candidate identifiers are generated and combined segment by segment. Specific steps include: Locate attribute templates based on the target product category and determine the template version and applicable scope; The attribute template is compiled into an executable rule chain, forming the code segment generation order and dependency relationship; Initialize the code segment context and load the generation operators for fixed segments, derived segments, sequence segments, variant segments, and check segments; Calculate the value of each code segment in the order of code segment generation and complete length processing, padding processing and separator processing; The code segments are combined according to the preset connection method to form candidate identifiers and then output in a formatted manner. Record the constituent code segments, value sources, rule chain version, and generation time of the candidate identifiers, and output the candidate identifier set.

[0008] Furthermore, exclusive constraints and value range restrictions are applied to the candidate identifiers, and candidates that do not meet the preset boundary conditions are eliminated to obtain a candidate combination list. The specific steps include: Establish an exclusive constraint list and a value range restriction table, and associate them with the constraint items in the attribute template; check the exclusive constraints for each candidate identifier segment by segment, and perform rejection processing or downgrade marking as a review candidate when there are mutually exclusive combinations; For each candidate identifier, the value range limit is checked. If out-of-bounds, missing, or illegal characters are found, it is determined that the preset boundary conditions are not met and the identifier is removed. The candidate identifiers that pass the constraint verification are subjected to duplicate checks and merging. A sorting key is generated according to the determinism of the code segment and the reliability of the source. The retained candidate identifiers are summarized to form a candidate combination list, and the reasons for removal, the triggered constraint entries and the processing time are recorded.

[0009] Furthermore, within the preset generation window, a pre-reserved number segment is applied for for the candidate combination. Approximate duplication and cross-database mapping checks are performed. If a conflict exists, the process is blocked and adjustment suggestions are returned. If there is no conflict, the pre-reservation is confirmed and the process proceeds to the next step. Specific steps include: Submit a pre-reservation request for candidate combinations within the preset generation window, allocate the number range and validity period, and record the start and end time of the generation window; Within the valid time limit, perform near-duplicate searches on candidate combinations and screen the currently effective identifiers in the database according to the dimensions of consistency of name terms, specification range, key attributes, and source. Synchronously query cross-database mapping relationships and verify whether candidate combinations have an established unique mapping with external systems or external industry identifiers; When duplicate, conflict, or mapping occupancy is detected, pre-occupancy is blocked and adjustment suggestions are generated, including changing version code segments, variant code segments, or sequence code segments, and the process is returned to the candidate combination stage. When no conflict is detected, the pre-occupancy is confirmed and written into the occupancy record, marking the number range, validity period and operation information, and then proceeding to the subsequent verification process; When the validity period expires and the reservation is not confirmed, the reservation will be automatically released and the number segment will be reclaimed, and the release time and reason will be recorded.

[0010] Furthermore, the pre-acquisition successful candidate combinations are checked for structural integrity, semantic consistency, and business availability. Specific steps include: Perform structural integrity checks according to format, length and code segment completeness, and verify whether the delimiters, padding rules and check bits conform to the rule chain; Perform semantic consistency checks by comparing the attribute template with the field dictionary, verify the mapping relationship between each code segment and the corresponding attribute, check the value and value domain, dependency relationship and derivation relationship, and identify out-of-bounds, missing and contradictory values; Establish availability criteria for business scenarios such as warehousing, requisition, production, after-sales service, and release, and verify the completeness of necessary fields, the satisfaction of uniqueness constraints, and the consistency with the interface requirements of enterprise information systems; For candidate combinations that fail the verification, generate a non-compliance report, record the reasons for failure and rectification suggestions, mark the candidate combination as a review object, and return it to the candidate combination stage for processing; For all candidate combinations that pass the verification, confirm the verification results, generate a verification pass record, and proceed to the subsequent process of generating internal primary keys and aliases.

[0011] Furthermore, upon successful verification, an internal primary key and alias code are generated and bound to the product's entire lifecycle object. Simultaneously, the mapping relationship with external industry identifiers is recorded. Specific steps include: Generate an internal primary key for system alignment, and write the effective time and rule chain version according to a stable and unique encoding rule; Generate alias codes for on-site reading, complete length processing, padding processing and check digit generation, and establish a one-to-one correspondence with the internal primary key; Bind the internal primary key and alias code to the product lifecycle object. The bound object includes version, structural node, process route and customer selection. Write the binding type and effective range. Establish a one-to-one mapping relationship with external industry identifiers, verify the uniqueness and traceability of the mapping, and record the mapping status, effective time and reason for change; Write the internal primary key, alias code, binding record and mapping record into the master data registry, write the operator, timestamp and processing result, and complete the confirmation of generation and binding.

[0012] Furthermore, based on the binding results, a machine-readable carrier is generated and published to the enterprise information system. Specific steps include: Based on the binding results, assemble the data fields of the machine-readable carrier, generate the corresponding parsing template and check bit rules, and complete the formatted output and consistency verification. Releases are initiated to the enterprise information system in the order of master data priority. The request includes a list of target systems and an idempotent flag. If the release fails, a rollback is executed and a retry is triggered. In network or permission-restricted scenarios, enable delayed submission and batch merging strategies. After successful release, refill confirmation information and update the release status and target system list.

[0013] Furthermore, when attribute templates or rule chains change, an impact domain assessment and phased implementation are performed, with specific steps including: The proposed changes were rehearsed in a sandbox environment, generating a list of affected objects and categorizing them into objects in production, objects in the database, and published objects. Choose a freeze strategy, inheritance strategy, replacement strategy, or undo strategy based on the scope of impact, determine the grayscale batch and switching order, and set the rollback threshold; Before taking effect, verify the consistency of the mapping with the product's entire lifecycle objects and external industry identifiers. After the verification is passed, initiate the phased take-off process. During the implementation process, key metrics are continuously monitored. When the rollback threshold is triggered, the system automatically rolls back to the previous stable version. After the implementation is completed, the effective period and policy version are updated and synchronized to the enterprise information system.

[0014] Furthermore, the generation and release chain logs are saved, and the specific steps include: Record link logs at key nodes of application, pre-occupation, verification, activation, release and modification. The logs include the operator, timestamp, object identifier, rule chain version, action type and processing result. Generate checksums for the link logs to ensure consistency and integrity, and create indexes by object and time to support retrieval and aggregation queries; In recall, audit, and traceability scenarios, the generation and release paths are reconstructed based on the link logs, verifiable process records are output, and retention periods and archiving strategies are set for the link logs.

[0015] The technical effects and advantages of the product identification method automatically generated based on coding rules in this invention are as follows: This invention achieves uniqueness, structural integrity, and business applicability of product identifiers during the coding generation stage by constructing a closed-loop coding generation mechanism that includes attribute standardization, rule chain compilation, candidate generation, conflict verification, full lifecycle binding, and log traceability. The system uses a standard field dictionary and alias lookup table to perform semantic alignment and format regularization on attribute data from different business entry points. Driven by the rule chain, it combines identifier content segment by segment and dynamically generates candidate identifiers by incorporating exclusive constraints and value range verification.

[0016] Through steps such as pre-reserving number segments, cross-database mapping, semantic consistency, and availability verification, the system ensures the consistency and publishability of identifiers. Internal primary keys and alias codes are bound together and external mapping is supported, improving the system integration capability of identifiers. Furthermore, the introduction of versioned templates and sandbox evaluation mechanisms supports the canary release of rule chain changes, and the generation of verification records and path backtracking in conjunction with link logs improves the synchronization efficiency, stability, and evolutionary adaptability of enterprise master data across multiple business systems. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating a product identification method for automatic generation based on coding rules according to the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] In order to achieve the above objectives, Figure 1 A schematic diagram of a product identification method automatically generated based on coding rules according to the present invention is provided, which specifically includes the following steps; The coding generation platform receives basic product or material data from multiple business entry points, performs attribute normalization and semantic standardization based on a unified time base and field dictionary, and forms a standardized attribute set with source identifiers. Attribute templates are selected based on the target product category and rule chains are compiled. Candidate identifiers are generated and combined segment by segment. Exclusivity constraints and value range restrictions are applied to the candidate identifiers. Candidates that do not meet the preset boundary conditions are eliminated to obtain a candidate combination list. Within the preset generation window, apply for a pre-reserved number segment for the candidate combination, perform near-duplicate and cross-database mapping checks, block and return adjustment suggestions when there are conflicts, and confirm the pre-reservation and proceed to the next process when there are no conflicts. For pre-acquisition successful candidate combinations, structural integrity, semantic consistency and business availability are checked. When the check passes, an internal primary key and alias code are generated and bound to the product lifecycle object. At the same time, the mapping relationship with the external industry identifier is recorded. Based on the binding results, a machine-readable carrier is generated and published to the enterprise information system. When the attribute template or rule chain changes, an impact domain assessment is performed and the changes take effect in stages, and the generation and publication link logs are saved.

[0020] Step 1: The encoding generation platform receives basic product or material data from multiple business entry points, performs attribute normalization and semantic standardization based on a unified time base and field dictionary, and forms a standardized attribute set with source identifiers. The specific implementation is as follows: The encoding platform establishes a unified time base, which is an absolute time axis based on Coordinated Universal Time (UTC) plus local time zone offset, and is fixed at a record granularity of year, month, day, hour, minute, and second. For each data record from the R&D, procurement, manufacturing, and sales entry points, the platform simultaneously writes the sampling time and arrival time. The sampling time is the time value when the data is generated in the business system, and the arrival time is the time value when the data is received by the platform. After converting both to the unified time base, the platform maps the sampling time to the unified time base first, then the arrival time to the unified time base, and finally subtracts the sampling time from the arrival time to obtain the arrival offset. The arrival offset is used for subsequent time sequence alignment and delay diagnosis. Based on this, the platform rearranges the time order of the same object records across entry points to ensure that the attribute updates of the same object depend on the latest valid arrival record.

[0021] Attribute shaping is performed based on the field dictionary and alias mapping relationship, specifically as follows: The field dictionary is a base table that explicitly lists the field name, field meaning, data type, value format, allowed value range, minimum length and maximum length; It should be noted that the standard vocabulary library is a collection of words that accompany the field dictionary. It is maintained by the coding generation platform, originates from enterprise standards and industry standards, and is versioned and updated incrementally on a regular basis according to the rule chain version. The alias mapping is a lookup table that maps synonymous field names to standard field names. First, field names are standardized according to the field dictionary to ensure that only one standard field name is used for the same meaning. Then, data types are unified: numeric fields are standardized to fixed-point numbers or integers, character fields to fixed-length or variable-length types, and date and time fields to text expressions with a unified time base. Subsequently, the platform performs synonym merging and ambiguity resolution on names, specifications, models, process parameters, and customer-customized items. The synonym merging rules are as follows: If a candidate expression corresponds one-to-one with a standard expression in the standard vocabulary, it will be replaced with that standard expression; if multiple candidate expressions match the same standard expression, the platform will select the one with the highest priority based on the order of alias matching.

[0022] The ambiguity resolution rule is as follows: when multiple expressions for the same field appear and all are within the value range, the expression with higher source credibility and smaller arrival offset is selected first. The platform uniformly processes measurement units, precision ranges, and decimal places, with the default measurement system being millimeters for length, kilograms for mass, degrees Celsius for temperature, and years, months, days, hours, minutes, and seconds under a unified time base.

[0023] The unified processing order is as follows: first, convert the original units to the preset measurement system; then, round to the specified decimal places according to the precision range in the field dictionary; finally, perform value range boundary verification. If the value exceeds the value range, it is marked as non-compliant and enters the subsequent conflict resolution process.

[0024] The conflicting fields are adjudicated according to preset priority and source credibility. The process is as follows: The default priority is a source ranking table from high to low, and the source credibility is a level label consistent with the source ranking table. The adjudication process is as follows: When multiple values ​​appear for the same field of the same object, the platform first compares the preset priorities of the sources and selects the value with the higher priority. When the priorities are the same but the values ​​are different, the arrival offset is compared and the value with the smaller arrival offset is selected. When both the priority and the arrival offset are the same, the final value is determined according to the conflict resolution strategy in the field dictionary. The conflict resolution strategy includes retaining the value that was most recently approved by manual review or retaining the value that is consistent with the previously published record.

[0025] The platform writes a source identifier, operator, timestamp, and processing status for each attribute. The source identifier clearly records the source system name and identifier. The operator is the identity of the person who triggered the data to enter the platform or performed the review action. The final output standardized attribute set with source identifiers is stored in a key-value pair structure. Each key is a standard field name, and each value is a standard expression after synonym merging, unit conversion, precision unification, and conflict resolution. It also includes four metadata items: source identifier, operator, timestamp, and processing status. This standardized attribute set will serve as the sole input source for subsequent attribute template selection, rule chain compilation, candidate identifier generation, and constraint verification.

[0026] Step 2: Select an attribute template based on the target product category and compile the rule chain. Generate and combine candidate identifiers by segment. Apply exclusive constraints and value range restrictions to the candidate identifiers. Eliminate candidates that do not meet the preset boundary conditions to obtain a candidate combination list. The specific implementation is as follows: The encoding generation platform first uses the target product category in the standardized attribute set as the search key to locate the attribute template in the template library. It then selects the template version based on the template's applicability and validity period. Each attribute template provides a clear definition for each type of code segment, including fixed segments, derived segments, sequence segments, variant segments, and check segments. Each segment defines its name, meaning, length, allowed character set, value source, value range, null placeholder, length handling method, padding method, and separator usage method. Based on this, the platform establishes a code segment context. The code segment context is a structured container used to store the values ​​of each segment and the dependencies between segments. Its initial content comes from the mapping table built into the standardized attribute set and the template. The template library is a centralized storage for attribute templates. Templates are indexed by category, region, and effective range, and version backtracking is supported.

[0027] The attribute template is compiled into an executable rule chain, forming the execution order and dependencies from fixed segments to validation segments. The values ​​of fixed segments come from the template's constant table and are used to represent product categories or platform codes. The values ​​of derived segments are derived from the standardized attribute set based on the mapping table in the template; for example, material grades, process parameters, or region codes are mapped to standardized segment values. When a derived segment depends on multiple attributes, the platform parses the upstream attributes first according to the dependencies, and then parses the segment.

[0028] The value of the sequence segment comes from the sequence allocator, which explicitly defines the distribution range, such as product category, region, and date, and ensures that the serial number within the distribution range is sequentially increasing and unique. The variant segment is used to express customer customization information or process selection. The platform obtains standardized variant codes through the variant mapping table based on the customization items in the standardized attribute set. When there are multiple customizations, they are concatenated according to the priority order specified in the template or merged in a preset manner. The value of the verification segment is used to verify the correctness after the combination is completed. The platform reads each character of the aforementioned segments sequentially according to the text algorithm described in the template, assigns a position weight to each character starting from the first character, with characters at the beginning having a smaller weight and characters at the end having a larger weight, then multiplies the value corresponding to the character with its position weight and sums them sequentially, and finally uses the sum to find the corresponding verification character in the preset value set to obtain the value of the verification segment.

[0029] The encoding generation platform calculates the value of each segment sequentially according to the execution order of the rule chain and performs length processing and padding. Length processing refers to trimming or expanding the segment value according to the template setting when the actual length of the segment value is inconsistent with the segment length. Padding refers to adding specified characters to the left or right to reach the segment length when the segment value is insufficient. Delimiter processing refers to connecting segments according to the delimiter specified in the template, such as using a hyphen. For segments that allow null values, the platform writes a null placeholder when the corresponding source is missing in the standardized attribute set and marks the segment as a null placeholder on the candidate identifier. Subsequently, the platform combines fixed segments, derived segments, sequence segments, variant segments, and check segments according to the preset connection method to form candidate identifiers and outputs them in a formatted manner. At the same time, it records the constituent code segments, value source, rule chain version, and generation time to form a candidate identifier set.

[0030] To facilitate understanding, an example without limiting the scope of protection is given: The target product category is pump body components. The fixed segment is the pump body category code from the template constant table. The derived segment obtains the material code and region code from the mapping table based on the material grade and region code. The sequence segment obtains the currently unused sequence number within the distribution range of "pump body components plus East China region plus the current date". The variant segment obtains the standardized color code from the variant mapping table based on the customer-customized spray color. The verification segment reads the combined segment values ​​from left to right according to the aforementioned text algorithm and obtains the verification character. After the platform completes length processing, padding processing, and separator processing, it generates a candidate identifier. At the same time, the candidate identifier's supplementary information includes the constituent code segments, value source, rule chain version, and generation time.

[0031] The encoding generation platform first establishes an exclusive constraint list and a value range restriction table based on the constraints in the attribute template. The exclusive constraint list specifies the segment value combinations that are not allowed to appear simultaneously and the handling methods after triggering them; the value range restriction table lists the allowed character set, allowed value set, minimum length, and maximum length for each segment. The preset boundary conditions are derived from the boundary definitions in the attribute template. The boundary definitions clearly define the handling strategies when a segment value goes out of bounds, a segment value is missing, or a segment value contains illegal characters. During initialization, the platform associates the exclusive constraint list and the value range restriction table with the attribute template and attaches a constraint number and constraint description after each constraint for easy subsequent recording and traceability. The platform verifies exclusive constraints on each segment of candidate identifiers: When the segment value combination in a candidate identifier is exactly the same as a constraint number in the exclusive constraint list, the platform performs either rejection or downgrading according to the handling method. Rejection is used for combinations that are physically impossible to be true simultaneously, such as a region code indicating domestic use while an industry identifier uses a format applicable only to overseas markets, or a material code corresponding to a non-heat-treated material while a process parameter segment indicates the need for high-temperature heat treatment. Downgrading is used for combinations where insufficient information leads to insufficient reliability, such as a variant segment containing null placeholders while a customer-customized item requires them to be specified.

[0032] For each candidate identifier that matches a constraint, the constraint number, constraint description, and processing result are recorded. Candidate identifiers that are downgraded are marked as review candidates for manual or semi-automatic review. Subsequently, the value range restrictions are checked for each candidate identifier. If a segment value is found to be out of bounds, empty, or contains illegal characters, the platform determines that the candidate identifier does not meet the preset boundary conditions and removes it. Simultaneously, the corresponding segment name, out-of-bounds description, and processing time are recorded in the candidate identifier's supplementary information. For derived segments, if no entry matching the standardized attribute set is found in the mapping table, the platform marks the derived segment as having a missing value and removes it according to the preset boundary conditions.

[0033] For candidate identifiers verified through exclusion constraints and value range limitations, the encoding generation platform performs duplicate checks and merging processes. The principle of duplicate checks is that complete consistency checks and approximate consistency checks are performed in parallel. Complete consistency checks refer to all segment values, including the check segment, being identical, which is considered a duplicate. The platform retains the one with an earlier generation time or higher source credibility and records the merging relationship. Approximate consistency checks refer to all segment values ​​except the sequence segment being identical, differing only in the sequence segment, and originating from the same standardized attribute set. This is determined to be caused by duplicates triggered by the same object, retaining the one with the smaller sequence number and recording the merging relationship. Subsequently, the identifiers are sorted according to the principle of generating sorting keys based on segment determinism and source credibility. The order of segment determinism from high to low is: fixed segment, derived segment, variant segment, sequence segment, check segment. Within the same sorting dimension, they are further sorted from high to low source credibility. After sorting, the platform summarizes the retained candidate identifiers to form a candidate combination list. Simultaneously, for the candidate identifiers that are removed, the reason for removal, the triggered constraint entries, and the processing time are recorded, and a structured verification report is generated.

[0034] For example, in the candidate identifier set, there are two candidate identifiers whose fixed segment, derived segment, and variant segment are completely identical. Their sequence segments are a smaller sequence value and a larger sequence value, respectively. Their check segments are different check characters obtained by text algorithm. The exclusive constraint list stipulates that when the area code is within the territory, the external industry identifier of the foreign standard cannot be used. Neither of the two candidate identifiers hits the constraint and both meet the length and character set requirements of the value range restriction table. Based on this, it is determined that the two candidate identifiers are approximately the same. The one with the smaller sequence number is retained and the merging relationship is recorded. Then, the candidate identifier is added to the candidate combination list according to the sorting key. This candidate combination list will serve as the only input for applying for a pre-reserved number segment for the candidate combination within the preset generation window, performing near-duplicate and cross-database mapping verification, ensuring that the candidate object has met the preset boundary conditions and passed the exclusive and value range verification before entering the pre-reservation stage.

[0035] Step 3: Within the preset generation window, apply for a pre-reserved number segment for the candidate combination, perform near-duplicate and cross-database mapping checks, block if a conflict exists and return adjustment suggestions, confirm the pre-reservation and proceed to the next process if no conflict exists. The specific implementation is as follows: A preset generation window is created, consisting of a start time and an end time, both recorded using a unified time base. Within this window, after receiving a pre-occupancy request for a candidate combination, a number range and a validity period are allocated to that combination. The number range is a consecutive interval of available numbers, and the validity period is the maximum time the pre-occupancy request is allowed to remain in an occupied state. The platform writes the generation window start time, end time, number range, validity period, and a unique identifier for the same candidate combination into the occupancy record, along with the operator's name and a timestamp under the unified time base, as the basis for subsequent confirmation or release.

[0036] The unique identifier of the candidate combination is a globally unique identification code generated by the platform. It is obtained by deterministic encoding after sequential connection based on the rule chain version, the values ​​of the constituent code segments and the generation time, ensuring that it is not repeated under the same rule chain version.

[0037] Within the effective time limit, perform near-duplicate retrieval and cross-database mapping verification on candidate combinations. Near-duplicate retrieval is based on item-by-item comparison of four types of comparable elements. The first type of element is name tokens, which refer to the sequence of terms obtained by segmenting the name field in the standardized attribute set according to spaces, hyphens and common delimiters; the platform judges the consistency of names by comparing the consistency of the term sequences one by one; The second type of element is the specification range. The specification range refers to the decomposition of the standardized specification field into numerical expressions with minimum and maximum values, and expressed in the same unit of measurement. The platform judges the consistency of the specifications by comparing whether the numerical values ​​completely overlap or strictly contain each other. The third category of elements is the consistency of key attributes. Key attributes include material grade, process parameters and region code. The platform judges the consistency of key attributes by comparing the standardized values ​​of key attributes to ensure they are completely equal. The fourth element is source consistency, which means that the source system name and the source system identifier are the same, or the source link points to the same upstream record in the master data registry; the platform uses this to determine whether it was triggered by the same source at different times. Cross-database mapping verification is based on cross-database mapping relationships, which refer to one-to-one binding records between internal master data and external systems or external industry identifiers. The platform searches for whether there is already a binding object or an effective external industry identifier corresponding to the candidate combination, and uses the existence of a unique mapping as the criterion for judgment.

[0038] The encoding generation platform performs blocking or confirmation based on the above retrieval and verification results. If duplicates, conflicts, or mapping occupancy are detected, the platform blocks the pre-occupancy process for that candidate combination and generates adjustment suggestions to return to the candidate combination stage; The proposed adjustments consist of three categories of changes: The first type of change is to change the version code segment. The change method is to select the next available version identifier within the value range allowed by the template and recombine the candidate identifiers. The second type of change is to change the variant code segment. The change method is to select a variant code that is different from the existing combination in the variant mapping table based on the customer customization item and recombine the candidate identifiers. The third type of change is to change the sequence code segment. The change method is to apply for a new serial number within the same distribution range and replace the original serial number.

[0039] If no conflict is detected, the platform confirms the pre-occupancy status of the candidate combination, writes the number range, validity period and operation information into the occupancy record, and enters the structural integrity, semantic consistency and business availability verification process; if the confirmation is not completed before the validity period expires, the platform automatically releases the pre-occupancy status of the candidate combination and reclaims the number range, and writes the release time and release reason into the occupancy record to ensure that the number range resources are reclaimed in a timely manner and can be redistributed.

[0040] Step 4: Perform structural integrity, semantic consistency, and business availability checks on the pre-selected candidate combinations. If the checks pass, generate internal primary keys and aliases, and bind them to the product's full lifecycle objects. Simultaneously, record the mapping relationship with external industry identifiers. The specific implementation is as follows: The process of obtaining confirmed pre-allocation candidate combinations is described, along with the steps for verifying the structural integrity, semantic consistency, and business availability of these successfully pre-allocated candidate combinations. The structural integrity check is based on the rule chain version. The fixed segment, derived segment, sequence segment, variant segment and check segment in the candidate combination are checked one by one. The platform first compares whether the segment length and segment meaning of each segment are consistent with the attribute template, then checks whether the separator appears in the specified position, and checks whether the segment value is filled according to the direction and characters set in the attribute template when the segment value is insufficient.

[0041] The platform then verifies the correctness of the verification segment. It reads all characters in the candidate combination except for the verification segment in sequence, assigns a position weight to each character from left to right, multiplies the value corresponding to each character with the position weight of the character and accumulates them continuously. It uses the accumulated result to find the verification character that should appear in the preset character set and compares it with the verification segment value in the candidate combination one by one. If they are completely consistent, the verification segment is determined to be valid. The above process records the name of the inspection item, the inspection result and the description of non-compliance item, as part of the structural integrity verification record.

[0042] Semantic consistency verification is based on field dictionaries and attribute templates. It verifies the mapping relationship between each code segment and the standardized attribute set item by item. The platform first checks whether the value of each segment originates from a standardized attribute field consistent with the segment's meaning and whether the value is within the defined value range of the segment. For segment values ​​with dependencies, the platform confirms that the upstream values ​​are ready and meet the requirements of the derived mapping table in the dependency order, and then verifies again whether the values ​​of the downstream derived segments match the upstream values. For cases of out-of-bounds values, null values, or cases where no corresponding entry can be found in the derived mapping table, the platform marks the segment as semantically inconsistent and generates a non-compliance report at the candidate combination level. The non-compliance report includes the non-compliance field name, expected value range, actual value, and explanation of the cause. If a logical contradiction is detected between segment values, such as a material code indicating a non-heat-treated material while process parameters require heat treatment, the platform directly determines the candidate combination as semantically inconsistent and stops its subsequent business availability verification.

[0043] Business availability verification establishes availability criteria for five business scenarios: warehousing, requisition, production, after-sales service, and release. The platform verifies the completeness of necessary fields one by one, including whether the reserved spaces for internal primary keys, external industry identifiers, packaging-related fields, and regulatory fields can be filled after generation. The platform verifies the satisfaction of uniqueness constraints, including whether there are duplicate combinations that could cause business confusion under the same product category, the same region code, and the same version. The platform also verifies the consistency with the requirements of the enterprise information system interface, including whether the field name, field length, character set, and whether the required identifier is included are completely consistent with the interface definition. For candidate combinations that fail any type of verification, the platform generates a non-compliance report, records the reasons for failure and rectification suggestions, and marks the candidate combination as a review object and returns it to the candidate combination stage for processing.

[0044] The platform first generates an internal primary key for system alignment. The internal primary key serves as a stable, unique, and semantically neutral identifier in the platform's master data registry. The allocation of internal primary keys takes place within a central namespace, which is independent of product category, region code, and date. This ensures that the internal primary key remains unchanged during historical version changes and cross-system transfers. When generating the internal primary key, the platform simultaneously writes the effective time and rule chain version. The effective time is recorded as year, month, day, hour, minute, and second using a unified time base. The rule chain version is consistent with the rule chain version used above and is used to trace the generation basis of the candidate combinations corresponding to the internal primary key. The platform then generates alias codes for on-site identification. These alias codes are composed of fixed segments, derived segments, sequence segments, and variant segments connected in a preset manner, and their length and padding are processed. After the alias codes are generated, the platform calculates a check segment value. Specifically, it reads each character of the alias code from left to right, assigns a predefined weight to each character, multiplies the character's value by the weight, and then sequentially accumulates the results. The accumulated result is used to find a check character in a preset character set, and this check character is appended to the end of the alias code as its check bit. The platform ensures a one-to-one correspondence between the internal primary key and the alias code, prohibiting multiple alias codes from pointing to the same internal primary key, and also prohibiting one alias code from pointing to multiple internal primary keys. The platform simultaneously writes the internal primary key, alias code, constituent segments, value source, rule chain version, and generation time into the master data registry, along with the operator, timestamp, and processing result, forming a stable record that can be consumed by the business system.

[0045] During the binding and mapping phase, the platform binds internal primary keys and alias codes to product lifecycle objects. These product lifecycle objects include versions, structural nodes, process routes, and customer options. The platform writes the binding type and effective period during binding. The binding type indicates whether the binding is initial, replacement, or inherited. The effective period records the start and end times using a unified time base, used to trace the specific status of the version, structural node, process route, and customer options corresponding to the internal primary key within a specific timeframe. Simultaneously, the platform establishes a one-to-one mapping relationship with external industry identifiers, performing uniqueness verification again before mapping to ensure no other internal primary key maintains a valid mapping with the external industry identifier. The platform writes the mapping status, effective time, and change reason into the master data registry. The change reason explains the specific motivation for the initial, replacement, or revocation of the mapping.

[0046] Step 5: Generate a machine-readable carrier based on the binding results and publish it to the enterprise information system. When the attribute template or rule chain changes, perform an impact domain assessment and phased implementation, and save the generation and publication link logs. The specific implementation is as follows: The encoding generation platform first assembles the data fields of the machine-readable carrier based on the binding results. The data fields of the machine-readable carrier must at least include an internal primary key, alias code, version, structural nodes, process route, customer options, external industry identifier, effective date, rule chain version, and visible text for on-site reading. The platform generates a parsing template based on the field definitions in the attribute template. The parsing template specifies the name, length, character set, and position order of each field within the carrier.

[0047] The platform generates check bits according to the check bit rules. It reads all field characters to be printed or written sequentially from left to right, assigns a predefined weight to each character, multiplies the character's value by its weight, and accumulates these values ​​sequentially. The accumulated result is used to find a check character in a fixed character set, which is then appended to the end of the data as the check bit. The platform performs formatted output and consistency checks on the generated machine-readable data. The consistency check verifies whether the field names, field lengths, character sets, and check bits match the parsing template.

[0048] Subsequently, the code generation platform initiates the release to the enterprise information system according to the priority of master data. The specific steps are as follows: The release request includes a list of target systems and an idempotency identifier. The target system list refers to the list of systems that need to be synchronized, including product lifecycle management systems, enterprise resource planning systems, warehouse management systems, manufacturing execution systems, and order management systems. The idempotency identifier is a unique value that can identify the same transaction in duplicate requests, used to ensure that network jitter or system retries do not generate duplicate records. After receiving responses from the target systems, the platform judges the release result. If any target system reports failure, the platform executes a rollback strategy. The rollback strategy is to undo the current update for successful systems and maintain the previous stable version, while writing the rollback reason and timestamp to the master data registry. If all target systems report success, the platform writes the release confirmation time and the target system list to the master data registry as a confirmation record for this release.

[0049] In scenarios with limited network or access, the code generation platform enables a delayed commit and batch merging strategy. Delayed commits are typically used for temporarily offline on-site sites. The platform stores the records to be published in a local queue and commits them in queue order after the network is restored. Batch merging is used to reduce the number of cross-network commits. The platform collects multiple records to be published within a configurable time window, sorts them according to a defined sorting rule, and submits them to the target system all at once. After each delayed commit and batch merging is completed, the platform populates the release confirmation information and updates the release status and target system list.

[0050] Simultaneously, the proposed changes were rehearsed in a sandbox environment. These changes included adding or deleting fields, changing value ranges, lengths, and separators in attribute templates, as well as changes to execution order, segment generation operators, and checksum rules in the rule chain. The platform generated a list of affected objects based on the master data registry, categorizing them into "in-process objects," "in-stock objects," and "published objects." "In-process objects" refers to objects that have been generated but not yet transferred to the manufacturing or sales process; "in-stock objects" refers to objects that have been stored but not yet released; and "published objects" refers to objects that have been synchronized to the enterprise information system and are in use. The platform calculated the potential impacts of field inconsistencies, parsing template incompatibility, and checksum rule mismatches for each type of object and generated a list for approval purposes.

[0051] The encoding generation platform selects a freeze strategy, inheritance strategy, replacement strategy, or revocation strategy based on the scope of impact, and determines the gray-scale batches and switching order. The freeze strategy maintains the old version unchanged and rejects the writing of the new version within a specified effective period. The inheritance strategy automatically adapts field changes that do not affect semantic consistency, allowing old version objects to transition to the new version without changing their business meaning. The replacement strategy maps and regenerates fields between the old and new versions to ensure objects are usable in the new version. The revocation strategy removes and replaces no longer compliant combinations.

[0052] A gray-scale batch is a phased implementation arrangement that divides the list of affected objects into multiple batches, with the switching order being the execution order of each batch. The rollback threshold is the condition value that triggers a rollback during the phased implementation process; the platform typically uses the failure rate or the rate of inconsistency in key fields as the rollback threshold. When the rollback threshold is triggered, the platform automatically rolls back to the previous stable version. At the same time, it writes rollback records to the master data registry and the enterprise information system. Before taking effect, the platform re-verifies the consistency of the mapping with the product's full lifecycle objects and external industry identifiers to ensure that internal primary keys, aliases, binding records, and mapping records can be fully parsed and used in the new version. After taking effect, the platform updates the effective range and policy version and synchronizes the final results to the enterprise information system to ensure that the version, structural nodes, process routes, and customer selections have clear time boundaries and traceable paths between the old and new versions.

[0053] The process of saving the generation and release log includes: The coding generation platform records a link log at key nodes of application, pre-allocation, verification, activation, publication, and modification. The link log includes the operator, timestamp, object identifier, rule chain version, action type, and processing result. The operator is the identity of the person initiating the action. The object identifier is the internal primary key of the corresponding record in the main data registry. The rule chain version is the version number of the rule chain used when the action occurred; the action type is one of application, pre-allocation, verification, activation, publication, and modification. The processing result is success or failure, along with the reason for failure.

[0054] The platform generates checksums for the log entries to ensure consistency and integrity. The checksum generation process involves concatenating the fields in the log record in a fixed order to obtain a continuous text. Each character of this text is read from left to right, and each character is assigned a positional weight. The numerical value corresponding to each character is multiplied by its positional weight, and the results are summed sequentially. The sum is then moduloed by a fixed positive integer. The modulo result is used to find a checksum character within a fixed character set. This checksum character is the checksum of the log record. The platform saves this checksum along with the log record for detecting missing or tampered log entries.

[0055] An index is created for the link logs. The index key must include at least two dimensions: object identifier and timestamp. If necessary, rule chain version and action type are added as auxiliary dimensions to support retrieval and aggregation queries by object and time. In recall, auditing and tracing scenarios, the platform reconstructs the generation path and release path based on the link logs.

[0056] The generation path is a sequence of steps from application to generating internal primary keys and alias codes and storing them in the database. The release path is a sequence of steps from generating machine-readable media to synchronizing with the enterprise information system, potentially undergoing changes and rollbacks. The platform outputs verifiable process logs, listing the operator, timestamp, rule chain version, action type, and processing result for each step in chronological order, for direct use by external auditors or internal traceability. The platform sets retention periods and archiving policies for the logs. The retention period determines the maximum period for online retrieval, and the archiving policy migrates logs exceeding the retention period to long-term storage in read-only mode. The platform retains indexes and checksums during archiving to ensure long-term availability.

[0057] It should be noted that the threshold information in this embodiment was set in advance by professionals and will not be explained in detail here. Some parameters in the embodiment may have the same English letters, but they are explained with different meanings when used, and will not be explained one by one here.

[0058] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product.

[0059] Those skilled in the art will recognize that the modules and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0060] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0061] 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 technical scope 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.

[0062] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for automatically generating product identifiers based on coding rules, characterized in that: The specific steps include: The coding generation platform receives basic product or material data from multiple business entry points, performs attribute normalization and semantic standardization based on a unified time base and field dictionary, and forms a standardized attribute set with source identifiers. Attribute templates are selected based on the target product category and rule chains are compiled. Candidate identifiers are generated and combined segment by segment. Exclusivity constraints and value range restrictions are applied to the candidate identifiers. Candidates that do not meet the preset boundary conditions are eliminated to obtain a candidate combination list. Within the preset generation window, apply for a pre-reserved number segment for the candidate combination, perform near-duplicate and cross-database mapping checks, block and return adjustment suggestions when there are conflicts, and confirm the pre-reservation and proceed to the next process when there are no conflicts. For pre-acquisition successful candidate combinations, structural integrity, semantic consistency and business availability are checked. When the check passes, an internal primary key and alias code are generated and bound to the product lifecycle object. At the same time, the mapping relationship with the external industry identifier is recorded. Based on the binding results, a machine-readable carrier is generated and published to the enterprise information system. When the attribute template or rule chain changes, an impact domain assessment is performed and the changes take effect in stages, and the generation and publication link logs are saved.

2. The product identification method based on encoding rules for automatic generation according to claim 1, characterized in that: The coding generation platform receives basic product or material data from multiple business entry points, performs attribute normalization and semantic standardization based on a unified time base and field dictionary, and forms a standardized attribute set with source identifiers. Specific steps include: Under a unified time reference, the sampling time and arrival time are written for each data record, the arrival offset is calculated and the time alignment is completed; Establish a field dictionary and alias mapping relationship, and standardize field names, data types, and value formats; Perform synonym merging and ambiguity resolution on names, specifications, models, process parameters, and customer-customized items to generate standard descriptions; The units of measurement, accuracy range, and decimal places are standardized to unify the numerical values ​​into the preset measurement system. Conflicting fields are adjudicated according to preset priorities and source credibility, and the basis for the adjudication and the processing results are recorded; Write the source identifier, operator, timestamp, and processing status for each attribute, and output a standardized set of attributes with the source identifier.

3. The product identification method based on encoding rules for automatic generation according to claim 1, characterized in that: Based on the target product category, select attribute templates and compile rule chains, generate and combine candidate identifiers segment by segment. Specific steps include: Locate attribute templates based on the target product category and determine the template version and applicable scope; The attribute template is compiled into an executable rule chain, forming the code segment generation order and dependency relationship; Initialize the code segment context and load the generation operators for fixed segments, derived segments, sequence segments, variant segments, and check segments; Calculate the value of each code segment in the order of code segment generation and complete length processing, padding processing and separator processing; The code segments are combined according to the preset connection method to form candidate identifiers and then output in a formatted manner. Record the constituent code segments, value sources, rule chain version, and generation time of the candidate identifiers, and output the candidate identifier set.

4. The product identification method based on encoding rules for automatic generation according to claim 1, characterized in that: Apply exclusive constraints and value range restrictions to the candidate identifiers, and eliminate candidates that do not meet the preset boundary conditions to obtain a candidate combination list. The specific steps include: Establish an exclusive constraint list and a value range restriction table, and associate them with the constraint items in the attribute template; check the exclusive constraints for each candidate identifier segment by segment, and perform rejection processing or downgrade marking as a review candidate when there are mutually exclusive combinations; For each candidate identifier, the value range limit is checked. If out-of-bounds, missing, or illegal characters are found, it is determined that the preset boundary conditions are not met and the identifier is removed. The candidate identifiers that pass the constraint verification are subjected to duplicate checks and merging. A sorting key is generated according to the determinism of the code segment and the reliability of the source. The retained candidate identifiers are summarized to form a candidate combination list, and the reasons for removal, the triggered constraint entries and the processing time are recorded.

5. The product identification method based on encoding rules for automatic generation according to claim 1, characterized in that: Within the preset generation window, reserve number segments for candidate combinations, perform near-duplicate and cross-database mapping checks, block and return adjustment suggestions if conflicts exist, and confirm the reservation and proceed to the next process if there are no conflicts. The specific steps include: Submit a pre-reservation request for candidate combinations within the preset generation window, allocate the number range and validity period, and record the start and end time of the generation window; Within the valid time limit, perform near-duplicate searches on candidate combinations and screen the currently effective identifiers in the database according to the dimensions of consistency of name terms, specification range, key attributes, and source. Synchronously query cross-database mapping relationships and verify whether candidate combinations have an established unique mapping with external systems or external industry identifiers; When duplicate, conflict, or mapping occupancy is detected, pre-occupancy is blocked and adjustment suggestions are generated, including changing version code segments, variant code segments, or sequence code segments, and the process is returned to the candidate combination stage. When no conflict is detected, the pre-occupancy is confirmed and written into the occupancy record, marking the number range, validity period and operation information, and then proceeding to the subsequent verification process; When the validity period expires and the reservation is not confirmed, the reservation will be automatically released and the number segment will be reclaimed, and the release time and reason will be recorded.

6. The product identification method based on encoding rules for automatic generation according to claim 5, characterized in that: The structural integrity, semantic consistency, and business availability of the pre-acquisition candidate combinations are verified. The specific steps include: Perform structural integrity checks according to format, length and code segment completeness, and verify whether the delimiters, padding rules and check bits conform to the rule chain; Perform semantic consistency checks by comparing the attribute template with the field dictionary, verify the mapping relationship between each code segment and the corresponding attribute, check the value and value domain, dependency relationship and derivation relationship, and identify out-of-bounds, missing and contradictory values; Establish availability criteria for business scenarios such as warehousing, requisition, production, after-sales service, and release, and verify the completeness of necessary fields, the satisfaction of uniqueness constraints, and the consistency with the interface requirements of enterprise information systems; For candidate combinations that fail the verification, generate a non-compliance report, record the reasons for failure and rectification suggestions, mark the candidate combination as a review object, and return it to the candidate combination stage for processing; For all candidate combinations that pass the verification, confirm the verification results, generate a verification pass record, and proceed to the subsequent process of generating internal primary keys and aliases.

7. The product identification method based on encoding rules for automatic generation according to claim 6, characterized in that: Upon successful verification, an internal primary key and alias code are generated and bound to the product's full lifecycle object. Simultaneously, the mapping relationship with external industry identifiers is recorded. Specific steps include: Generate an internal primary key for system alignment, and write the effective time and rule chain version according to a stable and unique encoding rule; Generate alias codes for on-site reading, complete length processing, padding processing and check digit generation, and establish a one-to-one correspondence with the internal primary key; Bind the internal primary key and alias code to the product lifecycle object. The bound object includes version, structural node, process route and customer selection. Write the binding type and effective range. Establish a one-to-one mapping relationship with external industry identifiers, verify the uniqueness and traceability of the mapping, and record the mapping status, effective time and reason for change; Write the internal primary key, alias code, binding record and mapping record into the master data registry, write the operator, timestamp and processing result, and complete the confirmation of generation and binding.

8. The product identification method based on encoding rules for automatic generation according to claim 7, characterized in that: Based on the binding results, a machine-readable carrier is generated and published to the enterprise information system. The specific steps include: Based on the binding results, assemble the data fields of the machine-readable carrier, generate the corresponding parsing template and check bit rules, and complete the formatted output and consistency verification. Releases are initiated to the enterprise information system in the order of master data priority. The request includes a list of target systems and an idempotent flag. If the release fails, a rollback is executed and a retry is triggered. In network or permission-restricted scenarios, enable delayed submission and batch merging strategies. After successful release, refill confirmation information and update the release status and target system list.

9. The product identification method based on encoding rules for automatic generation according to claim 8, characterized in that: When an attribute template or rule chain changes, an impact domain assessment and phased implementation are performed. The specific steps include: The proposed changes were rehearsed in a sandbox environment, generating a list of affected objects and categorizing them into objects in production, objects in the database, and published objects. Choose a freeze strategy, inheritance strategy, replacement strategy, or undo strategy based on the scope of impact, determine the grayscale batch and switching order, and set the rollback threshold; Before taking effect, verify the consistency of the mapping with the product's entire lifecycle objects and external industry identifiers. After the verification is passed, initiate the phased take-off process. During the implementation process, key metrics are continuously monitored. When the rollback threshold is triggered, the system automatically rolls back to the previous stable version. After the implementation is completed, the effective period and policy version are updated and synchronized to the enterprise information system.

10. A product identification method automatically generated based on coding rules according to claim 9, characterized in that: And save the generation and release chain logs, the specific steps of which include: Record link logs at key nodes of application, pre-occupation, verification, activation, release and modification. The logs include the operator, timestamp, object identifier, rule chain version, action type and processing result. Generate checksums for the link logs to ensure consistency and integrity, and create indexes by object and time to support retrieval and aggregation queries; In recall, audit, and traceability scenarios, the generation and release paths are reconstructed based on the link logs, verifiable process records are output, and retention periods and archiving strategies are set for the link logs.

Images