A method, apparatus, and medium for converting source system data to target budget data

Abstract

The present application belongs to the technical field of data processing, and particularly relates to a method, device and medium for converting source system data into target budget data, the method comprising: acquiring source business data containing a plurality of source data fields; in response to a configuration instruction, establishing a mapping rule between the source business data and a target budget model, and mapping and converting a responsibility subject field, a time period field and a business object field in the source business data into corresponding dimensions in the target budget model according to the mapping rule; mapping and converting a quantitative index field into a specific data item under a data type dimension to generate a multi-dimensional budget data record; and storing the multi-dimensional budget data record into a target budget database to form a target budget table. The present application realizes automatic conversion of two-dimensional business plan data into multi-dimensional budget data by pre-establishing a mapping rule, avoids repeated entry, ensures data consistency, and adapts to individual dimension configuration requirements of different budget tables.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, and specifically relates to a method, device and medium for converting source system data into target budget data. Background Technology

[0002] Comprehensive budget management, as a core management tool for enterprise resource allocation and operational decision-making, has been widely adopted. In practical applications, significant differences in data structure exist between the two systems mentioned above: business plan data in ERP systems is typically stored using a two-dimensional table structure, organizing data by record-keeping units. This structure is simple and easy to fill out, but not conducive to multidimensional analysis. In contrast, budget data in comprehensive budget management systems is typically stored using a multidimensional data model, locating each data cell by combining dimensions. This inconsistency in data structures prevents business plan data from being directly recognized and used by the budget management system.

[0003] Under current technological conditions, due to the inconsistency in data structures between ERP systems and comprehensive budget management systems, and the lack of established data pathways between the systems, it is necessary to complete the business plan submission in the ERP system and then re-enter the same business data into the comprehensive budget management system according to budget management requirements to complete the budget preparation. This approach requires the same business data to be entered into both systems, increasing the workload.

[0004] Because data entry in the two systems is independent, modified data in the ERP system is not synchronously reflected in the budget system, leading to a disconnect between business plans and business budgets, making data integration impossible. When business plans are adjusted, the already entered budget data cannot be updated synchronously. Since change operations are scattered across the two systems, they are prone to being missed and the historical change data cannot be traced. Summary of the Invention

[0005] This invention provides a method for converting source system data into target budget data. By pre-establishing mapping rules, the method achieves the conversion of two-dimensional business plan data into multi-dimensional budget data, avoiding duplicate data entry and ensuring data consistency.

[0006] Includes the following steps: S1: Obtain source business data, which includes multiple source data fields. The source data fields include at least a first field for identifying the responsible entity, a second field for identifying the time period, a third field for identifying the business object, and at least one quantitative indicator field. S2: In response to the configuration command, establish a mapping rule between the source business data and the target budget model. The mapping rule defines the correspondence between the source data fields and the dimension combinations in the target budget model. The target budget model includes the responsibility entity dimension, time period dimension, business object dimension, and data type dimension. S3: According to the mapping rules, the first field and the second field in the source business data are respectively mapped to the responsible entity dimension and the time period dimension in the target budget model, and the third field is mapped to the business object dimension; S4: Based on the mapping rules, the quantitative indicator fields in the source business data are mapped and converted into specific data items under the data type dimension in the target budget model, and a multi-dimensional budget data record containing the responsible entity dimension, the time period dimension, the business object dimension, and the specific data items is generated; S5: Store the generated multidimensional budget data records into the target budget database to form a target budget table.

[0007] According to another embodiment of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the steps of the method for converting source system data into target budget data.

[0008] According to yet another embodiment of this application, a storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the method for converting source system data into target budget data.

[0009] As can be seen from the above technical solutions, the present invention has the following advantages: This invention achieves automatic conversion from two-dimensional business plan data to multi-dimensional budget data by pre-establishing mapping rules between source business data and target budget models. Business personnel only need to fill in the business plan once in the ERP system, and the system will generate the corresponding budget data according to the mapping rules, reducing manual operation time.

[0010] When business plans change, only one modification is needed in the source system. The system then regenerates the corresponding budget data based on the stored mapping rules, achieving seamless integration between business and financial data. This invention matches source data fields with the dimensions of the target budget model by establishing mapping rules in response to configuration commands. Budget tables for different business types only need to have their mapping rules configured once upon first use, and can be reused repeatedly without requiring the development of a dedicated conversion program for each budget table, resulting in strong adaptability. Attached Figure Description

[0011] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the description will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a flowchart of a method for converting source system data into target budget data. Figure 2 A schematic diagram illustrating an example of a budget model that links a business budget table to a corresponding business plan. Figure 3 An example illustration of selecting the corresponding business plan field for a business budget table column; Figure 4 This is a schematic diagram illustrating the relationship between business plans and business budgets. Figure 5 This is a schematic diagram of an electronic device. Detailed Implementation

[0013] 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.

[0014] Please see Figure 1 The diagram shows a flowchart of a method for converting source system data into target budget data in a specific embodiment. The method includes: S1: Obtain source business data, which includes multiple source data fields. The source data fields include at least a first field for identifying the responsible entity, a second field for identifying the time period, a third field for identifying the business object, and at least one quantitative indicator field.

[0015] In some specific implementations, the source business data comes from original business plan data from systems such as ERP, MES, supply chain management systems, and comprehensive budget management systems.

[0016] In this embodiment, source data fields are the various data columns contained in the source business data, each carrying business information with specific meaning. The source data fields are the objects of the mapping rules and the basic units for establishing the correspondence between the source system and the target budget model. By identifying and classifying the source data fields, the system can automatically understand the structure and semantics of the source data.

[0017] The first field is a field in the source business data used to record "which organization or department is responsible for this business", such as "lead unit", "production department", "responsibility center", etc.

[0018] The first field serves to determine the budget responsibility, specifying which budget organization the budget data will ultimately be attributed to. By abstracting specific business terms into the first field used to identify the responsible party, this method is not limited to a particular field name but can be adapted to any field that carries the semantics of "responsible party," thus expanding the method's applicability.

[0019] The second field is a field in the source business data used to record "which time interval this business plan covers", such as "business plan period", "plan year", "budget month", etc.

[0020] The second field is responsible for the budget time allocation, determining which budget period the budget data is ultimately assigned to. Different source systems represent time differently, such as "202401", "2024-01", "2024 Year No. 1", etc. By abstracting it into a "second field used to identify the time period", the time format can be unified through format normalization, thus ensuring compatibility with multiple time expression methods.

[0021] The third field is a field in the source business data used to record "what product, material, or project this business plan targets", such as "manufacturing model number", "material number", "project number", etc.

[0022] The third field determines the scope of the budget object, specifying which business object the budget data will ultimately be aggregated under. Business objects typically have a hierarchical structure, such as product line - model series - specific model.

[0023] Quantitative indicator fields are fields in the source business data used to record specific numerical business quantities, such as "planned output", "planned cost", and "planned working hours".

[0024] The quantitative indicator field is the source of the "measures" in the budget data, and is the actual value ultimately written into the budget table cells. By supporting "at least one" quantitative indicator field, this method can handle situations where the source business data contains multiple quantitative indicators. Each quantitative indicator field can be independently mapped to a different specific data item under the data type dimension in the target budget model, thereby achieving one-to-many indicator splitting and transformation.

[0025] S2: In response to the configuration command, establish a mapping rule between the source business data and the target budget model. The mapping rule defines the correspondence between the source data fields and the dimension combinations in the target budget model. The target budget model includes the responsibility entity dimension, time period dimension, business object dimension, and data type dimension. In some specific embodiments, configuration instructions refer to operation instructions issued by the user through the configuration interface to define the mapping relationship between source data fields and target budget dimensions.

[0026] A target budget model is a predefined, multi-dimensional data model used to organize and store budget data in an enterprise budget management system. In this invention, the target budget model is the final target structure for data transformation, specifying the dimensions along which budget data should be organized. The existence of the target budget model provides a standardized structure for budget data; business data from different sources can be uniformly written into the same target budget model after transformation, achieving the aggregation and unified management of multi-source data.

[0027] Mapping rules are data structures established through configuration instructions that describe the correspondence between source data fields and dimensions in the target budget model. During data transformation, the mapping rules are queried to determine which dimension in the target budget model each source data field should be transformed into. By storing and managing the mapping rules independently of the transformation logic, The correspondence of dimension combinations refers to the matching and binding relationship between multiple source data fields recorded in the mapping rules and one or more dimensions in the target budget model. In this invention, the correspondence of dimension combinations defines the specific flow of data from the source to the target.

[0028] For example, the first field corresponding to the responsible entity dimension constitutes a correspondence. During the transformation, the system fills the value of the first field into the responsible entity dimension. By explicitly defining the correspondence between each pair of source fields and target dimensions, the system can automatically perform the transformation field by field.

[0029] The responsibility entity dimension is a dimension in the target budget model used to identify "which organization the budget responsibility belongs to". In this embodiment, the responsibility entity dimension receives the mapping transformation result from the first field, converting the department or unit name in the source system into the standard budget organization code in the target budget model. This determines the vertical attribution of data in the budget table, enabling budget data to be aggregated and assessed according to responsibility centers.

[0030] The time period dimension is a dimension in the target budget model used to identify "which time interval the budget data belongs to". In this embodiment, the time period dimension receives the mapping transformation result from the second field, uniformly converting various time formats in the source system into standard budget period codes.

[0031] The role of the time period dimension is to determine the horizontal distribution of data in the budget table, so that budget data can be summarized and compared and analyzed at different time granularities such as monthly, quarterly, and annual.

[0032] The business object dimension is a dimension in the target budget model used to identify "what product, material, or project the budget data targets." In this embodiment, the business object dimension receives the mapping transformation result from the third field, converting the business object code in the source system into standard multi-level business object dimension values. The role of the business object dimension is to further refine the data attribution in the budget table, supporting drill-down analysis by different levels such as product line, model, and material.

[0033] The data type dimension is a dimension in the target budget model used to identify "which type of business indicator the budget data belongs to", such as "material cost", "labor cost", "manufacturing cost", etc.

[0034] In this embodiment, the data type dimension receives the mapping transformation results from the quantitative indicator fields, mapping each quantitative indicator field in the source system to different dimension members under the data type dimension. Different indicator types are distinguished in the cross cells of the budget table, allowing multiple budget indicators under the same dimension combination to coexist in the same budget table.

[0035] S3: According to the mapping rules, the first field and the second field in the source business data are respectively mapped to the responsible entity dimension and the time period dimension in the target budget model, and the third field is mapped to the business object dimension; S4: Based on the mapping rules, the quantitative indicator fields in the source business data are mapped and converted into specific data items under the data type dimension in the target budget model, and a multi-dimensional budget data record containing the responsible entity dimension, the time period dimension, the business object dimension, and the specific data items is generated; S5: Store the generated multidimensional budget data records into the target budget database to form a target budget table.

[0036] This invention achieves automated data conversion between the two-dimensional table structure of the source system and the multi-dimensional model structure of the comprehensive budget management system by acquiring source business data, establishing mapping rules, converting the first, second, and third fields to their corresponding dimensions, converting quantitative indicator fields to specific data items under the data type dimension and generating multi-dimensional budget data records, and finally storing them in the target budget database to form a target budget table. This avoids data inconsistency between the source system and the budget system. The standardized mapping rules ensure the accuracy and repeatability of the conversion results, enabling budget data to be queried, summarized, and analyzed in the multi-dimensional model according to the responsible entity, time period, business object, and data type.

[0037] In one embodiment of the present invention, based on step S2, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0038] S21: The processor based on the electronic device responds to the mapping rule configuration start command triggered by the user in the configuration interface, calls the metadata query interface of the database management system, and sends a metadata read request to the data source where the source business data is located. The request carries the table name identifier of the source business data table. After receiving the request, the data source returns the column structure description dataset of the table.

[0039] The dataset contains the column name string and the corresponding data type code for each column. After receiving the dataset, the processor parses the column name and data type code of each column one by one, assembles all the parsed column names into a source field name list, and stores each column name and its data type code as a field attribute mapping table. The processor renders each field name in the source field name list into the first display area of ​​the configuration interface in the form of a selectable list control, and displays the corresponding data type code identifier next to each option of the selectable list control.

[0040] S22: The processor of the electronic device calls the model structure query interface provided by the model management module of the comprehensive budget management system, and passes the model internal code identifier of the target budget model to the interface. After receiving the query request, the model management module reads the model definition record corresponding to the model internal code from the metadata database. The definition record records the list of all dimension internal codes associated with the model. According to the list of dimension internal codes, each dimension is traversed one by one. For each dimension internal code, the dimension member reading interface is called to obtain all member internal codes and member names under that dimension. After mapping the dimension internal codes to the dimension names and the member internal codes to the member names, a two-level tree data structure of dimension-member is constructed. This tree data structure is rendered to the second display area of ​​the configuration interface. The first level displays the names of each dimension. After the user expands any dimension, the second level displays the list of all member names under that dimension.

[0041] This allows users to intuitively understand the full dimensional composition of the target model and the set of available members under each dimension without needing knowledge of multidimensional database queries. The two-level display of dimensions and members maintains a clear presentation of complex models.

[0042] S23: The processor based on the electronic device listens for mouse click events and keyboard selection events on the first and second display areas of the configuration interface. When it detects that the user clicks on a source field name in the selectable list control in the first display area, it records the identifier of the source field name and stores the identifier in the source field selection cache of the current configuration session. At the same time, it highlights the selected source field name on the interface.

[0043] When a user clicks on a dimension name in the tree structure of the second display area, the dimension internal code of that dimension name is recorded and stored in the target selection cache of the current configuration session. If the user clicks on a second-level member name in the tree structure, the member internal code corresponding to that member name and the dimension internal code of the dimension to which that member belongs are recorded at the same time.

[0044] Real-time detection of whether the source field selection cache and the target selection cache are both non-empty. If both are non-empty, it is determined that the user has completed a selection and pairing operation. The pairing type is determined based on whether the target selection cache stores dimension internal code or member internal code. If the stored data is an in-dimension code, then establish a correspondence between the source field and that dimension; If the stored data is a member's internal code and the member belongs to a data type dimension, then establish a correspondence between the source field and the specified member under that data type dimension; If the stored data is a member internal code and the dimension to which the member belongs is not a data type dimension, then establish a correspondence between the source field and the dimension to which the member belongs, and record the member internal code together in the correspondence. Generate a mapping configuration record and temporarily store it in the mapping configuration record set of the configuration session. Clear the source field selection cache and the target selection cache to wait for the next pairing operation.

[0045] S24: The processor receives the mapping rule saving instruction triggered by the user in the configuration interface, and in response to the instruction, extracts all mapping configuration records from the mapping configuration record set of the current configuration session in storage order, and performs a validity check on each mapping configuration record.

[0046] Optionally, the verification includes checking whether the source field identifier in the record exists in the source field name list obtained in step S21, whether the target dimension identifier exists in the dimension list or its member list obtained in step S22, and whether the same source field identifier has already appeared in the record set.

[0047] If the verification finds that the source field or the target dimension does not exist, an error message is returned to the configuration interface and the saving process is stopped.

[0048] If the verification finds that the same source field identifier appears repeatedly, the record of the most recent configuration will be retained and the previous mapping records of that source field will be deleted.

[0049] After successful verification, the processor converts each mapping configuration record into a rule data row according to the preset rule data table structure. The rule data row contains the source field name field, the target dimension internal code field, and the target member internal code field. The target member internal code field is set to empty when no specific member is specified in the corresponding relationship. The processor establishes a connection with the rule base database and writes all rule data rows into the mapping rule table of the rule base in batches. Each written record is accompanied by the current timestamp and the current logged-in user identifier. After the writing is completed, the processor closes the database connection and returns a save success status information to the configuration interface.

[0050] This approach visually presents the multidimensional structure of the target budget model to users, allowing them to intuitively understand which dimensions the model includes and what available dimension members are available under each dimension, thus lowering the barrier to entry for users to understand the multidimensional budget model structure. Visual selection operations replace manually writing mapping configuration files, enabling the completion of complex mapping configurations between fields and dimensions. Simultaneously, the system records every selection operation by the user in real time, preventing the loss of established mapping relationships before the user completes all configurations.

[0051] In one embodiment of the present invention, based on step S3, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0052] S311: Read the stored mapping rule dataset from the rule base, filter the mapping records with the source data field name as the first field and the second field according to the source field name, read the dimension type value stored in the target dimension type identifier field from the filtered mapping records respectively, set the dimension type value read for the first field as the first dimension type identifier, and set the dimension type value read for the second field as the second dimension type identifier. S312: Based on the obtained first dimension type identifier, determine that the first dimension type identifier points to the responsible entity dimension, access the member data table corresponding to the responsible entity dimension, read the stored coded strings row by row from the coded column of the member data table, compare the field value of the first field with the coded strings of each row in the coded column, and when the comparison is successful, read the member unique identifier code corresponding to that row as the first target code, and write the first target code into the responsible entity dimension value field in the converted data record; S313: Based on the second dimension type identifier, determine that the second dimension type identifier points to the time period dimension, access the member data table corresponding to the time period dimension, read the stored period code values ​​row by row from the period code column of the member data table, normalize the field value of the second field according to the preset standard date format to obtain a standardized date string, compare the standardized date string with each row of period code values ​​in the period code column character by character, and when the comparison is successful, read the unique period code corresponding to that row as the second target code, and write the second target code into the time period dimension value field in the converted data record; S314: Read the mapping rule record configured for the third field from the rule base, extract the combined mapping strategy field from the mapping rule record, parse the strategy type value stored in the combined mapping strategy field, determine the name of the mapping basis field to be used for the mapping based on the strategy type value, and read the corresponding tree structure traversal depth parameter from the system configuration table based on the strategy type value.

[0053] It should be noted that the combined mapping strategy field stores preset mapping mode codes. Each mapping mode code corresponds to a strategy definition record in the system configuration table. The strategy definition record records the list of mapping basis field names and the tree structure traversal depth parameter. After reading the strategy type value, the system uses that value as the primary key to query the configuration table to obtain the corresponding mapping basis field name and traversal depth parameter.

[0054] S315: Based on the mapping basis field name determined in step S314, extract the field value of the third field from the corresponding column of the source business data table as the search keyword, start from the root node of the dimension member tree structure corresponding to the business object dimension, read the mapping keyword value stored in the root node, and compare the search keyword with the keyword value of the root node.

[0055] If the comparison results do not match, the next level child nodes of the root node are accessed in depth-first order, and the mapping key values ​​stored in each child node are read one by one and compared with the search key. If no match is found, the recursive traversal continues to the next level until a successful comparison is found at a certain node in a certain level. The recursive traversal then stops, and that node is identified as the target node for the match.

[0056] S316: Read the storage record of the matching target node located in step S315 in the dimension member tree structure, read the value of the parent node reference pointer field from the storage record, access the storage record of the upper-level node according to the parent node reference pointer, continue to read the parent node reference pointer of the upper-level node, backtrack upwards level by level until the root node is reached, record the node code of each level node in turn during the backtracking process, and after the backtracking is completed, concatenate the recorded node codes in the order from the root node to the target node to generate a complete path code string, and write the complete path code string into the business object dimension value field in the converted data record.

[0057] In this way, by generating a complete path code from the root node to the target node instead of just storing the leaf node code, the transformed business object dimension value fully retains the hierarchical information of the business object in the dimension tree. During the budget data aggregation and analysis process, this path code can be used directly to quickly locate the hierarchical position of the business object in the dimension tree.

[0058] Furthermore, the following steps are included after step S3: S321: Read the transformed responsible entity dimension code generated in step S312, the transformed time period dimension code generated in step S313, and the transformed business object dimension code generated in step S316 from the current transformation session. Use these three code values ​​as query conditions to query the code column of the responsible entity dimension member data table, the period code column of the time period dimension member data table, and the code column of the business object dimension member data table in sequence.

[0059] If a code value that exactly matches the query condition is found in the corresponding code column, the verification is considered to have passed. If no consistent code value is found, the verification is deemed to have failed. The dimension code that failed the verification is marked as an invalid dimension value and the dimension type to which the invalid dimension value belongs is recorded.

[0060] Here, data anomalies that cannot match the target dimension members in the source business data are identified in advance before the complete data transformation is performed, so as to avoid writing invalid dimension codes into the target budget database and causing data errors during subsequent budget summary analysis.

[0061] S322: For each invalid dimension value marked in step S321, read the preset alternative rule table from the rule base. The alternative rule table stores multiple rule records. Each rule record contains a matching condition field and a valid alternative value field. The matching condition field stores a string pattern or range condition for matching invalid dimension values, and the valid alternative value field stores a valid dimension member code.

[0062] Read each rule record in the alternative rule table one by one, and compare the string of the current invalid dimension value with the pattern in the matching condition field of the current rule record; If a match is successful, the encoded value in the valid alternative value field of the rule record is read, the encoded value is set as the corrected dimension value, and the original invalid dimension value is replaced in memory. If the current rule record fails to match, continue reading the next rule record until all rule records have been matched. If all rule records fail to match, the original invalid dimension value is retained and the dimension value is additionally marked as the final uncorrected outlier.

[0063] Optionally, the substitution rule table is stored in the rule base as a relational table. Matching conditions can be defined using patterns such as prefix matching, suffix matching, regular expressions, or exact enumeration. Invalid dimension values ​​are sequentially compared with the matching conditions of each rule using string comparison or regular expression matching. When a rule is matched, subsequent comparisons are terminated, and the corresponding valid substitution value is used directly. This correction operation only occurs in the memory of the current processing thread and does not affect the original values ​​of the source business data.

[0064] Step S323: After the correction operation in step S322 is completed, collect from the memory of the current processing thread the original codes of all invalid dimension values, the dimension type name to which the invalid dimension value belongs, the rule number of the successfully matched replacement rule in step S322, the matching condition string and the valid replacement value code corresponding to the rule, and the final code value actually written to memory after correction. Assemble these data items into a log record according to the preset log table structure.

[0065] If an invalid dimension value does not match any alternative rule in step S322, its matching condition and valid alternative value fields are set to empty, and the abnormal state is marked as uncorrected in the log record. All log records are written to the log record table.

[0066] In one embodiment of the present invention, based on step S4, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0067] S411: The mapping rule base stores all mapping records in the form of a relational table. Each record contains a source field name field, a target dimension type identifier field, and a target dimension member code field. All mapping rule records with the mapping type identifier of quantitative indicator mapping are read from the rule base. The source field name field value and target dimension member code field value stored in each record are extracted one by one. The source field name and target dimension member code in each record are paired to construct a list of quantitative indicator field configurations in key-value pair format. S412: Take the first quantitative indicator field name from the quantitative indicator field configuration list constructed in step S411 as the current processing object, use the field name as the key value to perform a matching query in the hash structure of the configuration list, and read the target dimension member code value corresponding to the key value as the data type dimension member code when the match is successful. S413: Based on the field name of the target quantitative indicator field currently being traversed, locate the column storage location corresponding to the field name in the current data row of the source business data, read the original data byte sequence from the column storage location, convert the byte sequence into numeric data according to the preset data type definition of the column, and store the converted numeric data as the specific value of the quantitative indicator in the numeric variable of the current processing thread.

[0068] Optionally, the source business data here is stored in the database in the form of a two-dimensional relational table, where each row represents a business plan record and each column corresponds to a field.

[0069] S414: Read the responsible entity dimension code, time period dimension code, and business object dimension code generated in step S3, the data type dimension member code obtained from step S412, and the specific value set in step S413. Combine the above data items into a complete record according to the preset multidimensional data record data structure, and use the specific value as the measurement value corresponding to the dimension key combination.

[0070] S415: After completing the processing of the current quantitative indicator field, check whether there are any subsequent quantitative indicator fields in the quantitative indicator field configuration list that have not yet been traversed. If there are untraversed fields, return to step S412 to continue processing the next quantitative indicator field; If all quantitative indicator fields have been processed, collect all multidimensional data records generated in step S414, group them according to the values ​​of the three dimension keys: responsible entity dimension code, time period dimension code, and business object dimension code, perform a summation operation on the specific values ​​in each record within the same group, and use the summation result as the new value for that group, merge each group and keep one record, delete the remaining merged records in each group, and output all the merged records as the final multidimensional budget data record set.

[0071] In some specific embodiments, step S415 further includes the following: S4151: For each record, extract the dimension values ​​for the responsible entity, time period, and business object. Concatenate the three dimension values ​​in a fixed order to form a combined string, and perform a hash operation on the combined string to generate a dimension combination hash value. Establish a hash bucket structure, grouping record pointers with the same dimension combination hash value into the same hash bucket to form a record group; S4152: Access each hash bucket sequentially. For each record group within a bucket, read the data type dimension member code and the corresponding value of the specific data item in each record. Retrieve the horizontal data field array template, where each column position is pre-bound with a different data type dimension member code. Write the value of each specific data item into the column position in the horizontal data field array corresponding to the data type dimension member code of that record.

[0072] S4153: During the writing of the horizontal data field array, detect the write status of each column position.

[0073] If multiple values ​​for specific data items are received in the same column, it is determined that there is duplicate encoding in that column. The system then reads the pre-defined aggregation rules for the dimension member encoding of that data type from the rule base. The aggregation rules indicate either summation or arithmetic average calculations.

[0074] Perform operations on multiple values ​​according to aggregation rules, and write the results back to the column position.

[0075] Once all column positions have been processed, the values ​​of the responsible entity dimension, time period dimension, and business object dimension will be combined with the horizontal data field array to generate a multidimensional budget data record.

[0076] The aggregation rules here define how to merge values ​​when there are conflicts. Accumulation is applied to summable indicators, while arithmetic average is applied to ratio indicators. This ensures that the generated records contain all dimensional information and all indicator data, directly meeting the data entry requirements of the target budget database.

[0077] In some embodiments of this application, the source business data is not limited to production plan data, but can also be sales plan data or procurement plan data. When the source business data is sales plan data, the source data fields also include customer dimension, sales channel dimension, sales region dimension, and sales discount dimension. The mapping rules correspondingly add mapping configurations for these dimensions, and use quantitative indicators such as "planned sales volume" and "planned sales amount" in the sales plan as specific data items under the data type dimension. When the source business data is procurement plan data, the source data fields also include supplier dimension and procurement type dimension. The mapping rules correspondingly add mapping configurations for the supplier dimension and procurement type dimension, and use quantitative indicators such as "planned procurement quantity" and "planned procurement amount" in the procurement plan as specific data items under the data type dimension.

[0078] Furthermore, as a specific implementation of the above embodiments, the application scenario of the present invention is: an enterprise has deployed an ERP system to manage business plans (such as production plans) and a comprehensive budget management system to manage business budgets (such as production budgets).

[0079] Business plan data in the ERP system is stored in a two-dimensional table structure, while business budget data in the comprehensive budget management system is stored in a multi-dimensional model. Due to the inconsistency in the data structures of the two systems, business personnel need to fill in the business plan in the ERP system and then manually re-enter the business budget in the comprehensive budget management system, resulting in duplicate data entry, inconsistency, and low efficiency.

[0080] The present invention provides an embodiment of a data conversion module in a comprehensive budget management system. Based on predetermined rules, a mapping rule is established between business plan data fields and business budget dimension combinations. According to the mapping rule, the two-dimensional business plan data is automatically converted into multi-dimensional business budget data, eliminating duplicate data entry and ensuring data consistency.

[0081] The specific steps of the implementation method include: S101: The source business data is production plan data obtained from the ERP system. The production plan data is stored in a two-dimensional table structure, containing multiple source data fields. These fields include "Production Unit" (first field) for identifying the responsible entity, "Planning Period" (second field) for identifying the time period, "Manufacturing Model Number" and "Material Number" (third field) for identifying the business object, and multiple quantitative indicator fields, including "Beginning Work-in-Process Quantity", "Input Quantity", "Delivered Quantity", "Scrapped Quantity", "Ending Work-in-Process Quantity", "Beginning Work-in-Process Completion Ratio", and "Ending Work-in-Process Completion Ratio".

[0082] Specifically, the source business data can be shown in the following table:

[0083] The production plan data is filled in by the production department in the ERP system, representing the production task arrangement for the "F10" model and "double clamp upper half" material in January 2025.

[0084] In some embodiments of this application, the source business data can also be obtained from other modules of the ERP system, such as sales plan data from the sales module or procurement plan data from the procurement module, and the corresponding source data fields are adaptively adjusted according to the specific business type.

[0085] S102: The production budget table in the comprehensive budget management system is stored using a multi-dimensional model. This target budget model includes a budget organization dimension (corresponding to "production unit" in the source data), a budget period dimension (corresponding to "planning period" in the source data), a manufacturing model dimension (corresponding to "manufacturing model number" in the source data), a material dimension (corresponding to "material number," "material name," and "material drawing number" in the source data), and a data type dimension (corresponding to various quantitative indicator fields in the source data). Unlike two-dimensional table storage, in this multi-dimensional model, each budget data cell represents a cross-combination of multiple dimension members.

[0086] For example, the value of "40%" represents the data value after cross-locating five dimensions: budget organization "001001", budget period "January 2025", manufacturing model "F10", material "double clamp upper half", and data type "beginning work-in-process completion ratio".

[0087] Furthermore, since the ERP system and the comprehensive budget management system are not directly integrated, this embodiment first establishes an intermediate table, pre-sets the production plan data into the intermediate table according to the requirements of the comprehensive budget management system, and generates the corresponding budget model, such as... Figure 2 As shown, this allows the business budget table to be linked to the intermediate table.

[0088] Figure 2 The diagram illustrates the interface for linking the business budget table with the corresponding budget model of the business plan. The left side is the budget table structure definition area, which displays the dimension configuration information of the current budget table; the right side is the middle table selection area, which is used to pre-set the business plan data table structure into the budget model.

[0089] Figure 3 The diagram illustrates the interface for selecting the corresponding business plan fields in each column of the business budget table. Each row of the table represents a column of the budget table, and each row corresponds to the selection of a field from the source data for mapping configuration.

[0090] like Figure 4 As shown, the system displays the correspondence between the production plan field and the production budget dimension combination in the configuration interface, guiding users to complete the field matching configuration operation column by column.

[0091] On the configuration interface, the configuration personnel specify the correspondence between each field of the source business data and each dimension combination in the target budget model.

[0092] Specifically, the mapping rules are established as follows: the first field in the source business data used to identify the responsible entity—the production unit—is mapped to the budget organization dimension in the target budget model; the second field used to identify the time period—the planning period—is mapped to the budget period dimension in the target budget model; the third field used to identify the business object—the manufacturing model number, material number, material name, and material drawing number—is mapped to the business object dimension—manufacturing model and material—in the target budget model; and each quantitative indicator field in the source business data is mapped to a specific data type under the data type dimension in the target budget model. The established mapping relationships are shown in the table below:

[0093] Once the mapping rules are established, the system persistently stores them in the rule base for repeated use during subsequent data transformations. When source business data of the same business type is repeatedly imported, the system automatically matches the stored mapping rules for transformation, without the need for reconfiguration.

[0094] S103: Based on the mapping rules established in step S2, the system performs field-by-field transformation on the source business data.

[0095] Specifically, regarding the responsible entity dimension, the system reads the value "405000" from the "Production Unit" field in the source business data and converts "405000" into a member of the budget organization dimension in the target budget model according to the mapping rules. In this embodiment, "405000" in the source system and "001001" in the target budget system represent coding differences between different systems. The system completes the conversion through the coding mapping relationship of the master data system and determines that the budget data belongs to the budget organization "001001".

[0096] The conversion process is achieved through an organization code mapping table pre-established in the master data system, which records a one-to-one correspondence between the source system's responsible entity code and the target system's budget organization code.

[0097] Regarding the time period dimension, the system reads the value "January 2025" from the "Planned Period" field in the source business data and directly converts it into the budget period dimension member "202500101" (representing January 2025) in the target budget model according to the mapping rules. This time dimension format conversion rule is preset during system initialization, supporting automatic conversion between different formats to ensure that the time dimension is aligned with the budget calendar in the target system.

[0098] Regarding the business object dimension, the system reads the value "F10" from the "Manufacturing Model Number" field in the source business data and converts "F10" into a manufacturing model dimension member in the target budget model according to the mapping rules. Simultaneously, it reads the value "1025010400" from the "Material Number" field and converts "1025010400" into a material dimension member in the target budget model according to the mapping rules, and synchronously associates "Material Name" and "Material Drawing Number" as descriptive attributes of the material dimension. Similarly, this conversion process is completed through the model code mapping table and material code mapping table pre-established in the master data system.

[0099] S104: Based on the mapping rules established in step S2, the system converts each quantitative indicator field in the source business data one by one.

[0100] Specifically, the system extracts the following values ​​from the source business data: "1" for the "Beginning Work-in-Process Quantity", "10" for the "Input Quantity", "8" for the "Delivered Quantity", "1" for the "Scrapped Quantity", "8" for the "Ending Work-in-Process Quantity", "40%" for the "Beginning Work-in-Process Completion Ratio", and "100%" for the "Ending Work-in-Process Completion Ratio".

[0101] According to the mapping rules, the quantitative indicator fields are respectively mapped and converted into specific data types under the data type dimension in the target budget model, including mapping the "beginning work-in-process quantity" to the "beginning work-in-process quantity" type of the data type dimension, mapping the "input quantity" to the "input quantity" type, mapping the "delivery quantity" to the "delivery quantity" type, mapping the "scrap quantity" to the "scrap quantity" type, mapping the "ending work-in-process quantity" to the "ending work-in-process quantity" type, mapping the "beginning work-in-process completion ratio" to the "beginning work-in-process completion ratio" type, and mapping the "ending work-in-process completion ratio" to the "ending work-in-process completion ratio" type.

[0102] During the conversion, the system uses a single row of the source business data as a unit. For each quantitative indicator field in that row, it generates an independent multidimensional budget data record. Each record includes the budget organization dimension, budget period dimension, manufacturing model dimension, and material dimension obtained in step S3, as well as the data type dimension and specific value corresponding to the currently converted quantitative indicator. The multidimensional budget data records are stored as a single row, with each record representing a unique combination of dimensions.

[0103] Specifically, for the "Beginning Work-in-Process Quantity" field in the source business data, the system generates the following multidimensional budget data record:

[0104] For the "Quantity Invested" field, the system generates:

[0105] For the "Delivery Quantity" field, the system generates:

[0106] For the "Quantity Scrapped" field, the system generates:

[0107] For the "Quantity of Work-in-Process at the End of the Period" field, the system generates:

[0108] For the "Percentage of Work-in-Process Completed at the Beginning" field, the system generates:

[0109] For the "Percentage of Work-in-Process Completed at the End of the Period" field, the system generates:

[0110] After the above transformation, a single two-dimensional record of the source business data is converted into seven multi-dimensional budget data records. These multiple records together constitute a complete data record group, which is stored as a whole in the target budget database in the form of a record group.

[0111] S105: After the budget is finalized, the budget execution phase begins. The system retrieves actual execution data from the ERP system in real time or periodically and writes it into the execution data field. By comparing and analyzing the execution data with the budget data, the system achieves budget execution monitoring and deviation analysis functions.

[0112] At this point, the automatic conversion process from production planning data to production budget data is complete. From source data acquisition, mapping rule establishment, field mapping conversion, multidimensional data record generation, to multidimensional budget table storage, each step is executed sequentially and interconnected, jointly achieving the automatic conversion from two-dimensional business planning data to multidimensional business budget data. This avoids business personnel repeatedly entering data between the ERP system and the comprehensive budget management system, improving budget preparation efficiency. When business planning data changes, it is modified only once in the source system, and the system automatically regenerates the corresponding budget data based on the stored mapping rules, maintaining synchronization between business planning and budget data.

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

[0114] like Figure 5 As shown, this application also provides an electronic device, including a display module 103, a memory 102, a processor 101, a communication module 104, and a computer program stored in the memory and executable on the processor 101. When the processor 101 executes the program, it implements the steps of a method for converting source system data into target budget data.

[0115] In embodiments of the present invention, electronic devices include, but are not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the embodiments described and / or claimed herein.

[0116] In this embodiment, processor 101 may be implemented using at least one of an application-specific integrated circuit, a programmable logic device, a field-programmable gate array, a processor, a controller, a microcontroller, a microprocessor, or an electronic unit designed to perform the functions described herein. In some cases, such an implementation may be implemented within a controller. For software implementation, implementations such as processes or functions may be implemented with separate software modules that allow the performance of at least one function or operation. Software code may be implemented by a software application (or program) written in any suitable programming language, and the software code may be stored in memory and executed by the controller.

[0117] The display module 103 is used to display information input by the user or information provided to the user. The display module 103 may include a display panel, which may be configured in the form of a liquid crystal display, an organic light-emitting diode, or the like.

[0118] The memory 102 can be used to store software programs and various data. The memory 102 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0119] The communication module 104 transmits radio signals to and / or receives radio signals from at least one of a base station, an external terminal, and a server. Such radio signals may include voice call signals, video call signals, or various types of data sent and / or received according to text and / or multimedia messages.

[0120] The present invention also provides a storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method for converting source system data into target budget data.

[0121] The storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example,, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0122] The storage medium stores a program product capable of implementing the methods described above in this specification. In some possible implementations, various aspects of this disclosure may also be implemented as a program product comprising program code that, when run on a terminal device, causes the terminal device to perform the steps described in the "Exemplary Methods" section of this specification according to various exemplary embodiments of this disclosure.

[0123] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for converting source system data into target budget data, characterized in that, Includes the following steps: S1: Obtain source business data, which includes multiple source data fields. The source data fields include at least a first field for identifying the responsible entity, a second field for identifying the time period, a third field for identifying the business object, and at least one quantitative indicator field. S2: In response to the configuration command, establish a mapping rule between the source business data and the target budget model. The mapping rule defines the correspondence between the source data fields and the dimension combinations in the target budget model. The target budget model includes the responsibility entity dimension, time period dimension, business object dimension, and data type dimension. S3: According to the mapping rules, the first field and the second field in the source business data are respectively mapped to the responsible entity dimension and the time period dimension in the target budget model, and the third field is mapped to the business object dimension; S4: Based on the mapping rules, the quantitative indicator fields in the source business data are mapped and converted into specific data items under the data type dimension in the target budget model, and a multi-dimensional budget data record containing the responsible entity dimension, the time period dimension, the business object dimension, and the specific data items is generated; S5: Store the generated multidimensional budget data records into the target budget database to form a target budget table.

2. The method for converting source system data into target budget data according to claim 1, characterized in that, Step S2 specifically includes: S21: Obtain the field names and field types of all source data fields contained in the source business data, and render the obtained field names and field types to the configuration interface; S22: Obtain the dimension names of all budget dimensions contained in the target budget model and the list of dimension members corresponding to each budget dimension, and render the obtained dimension names and the list of dimension members to the configuration interface; S23: In response to the selection operation, establish a correspondence between the selected source data field and the selected target budget dimension, and when the selected target budget dimension is the data type dimension, establish a correspondence between the selected source data field and the specified dimension member under the data type dimension; S24: Generate mapping rule data based on the established correspondence. The mapping rule data includes source data field identifiers, target budget dimension identifiers, and the correspondence between the source data fields and the target budget dimension.

3. The method for converting source system data into target budget data according to claim 1, characterized in that, In step S3, the first field and the second field in the source business data are mapped and converted into the responsible entity dimension and the time period dimension in the target budget model, respectively. Specifically, this includes: S311: Read the first dimension type identifier configured for the first field and the second dimension type identifier configured for the second field from the mapping rules; S312: Based on the first dimension type identifier, locate the member data table of the responsible subject dimension, read the code column in the member data table, use the field value of the first field as the search condition, perform equal value matching in the code column, obtain the matching first target code, and set the first target code as the converted responsible subject dimension value; S313: Based on the second dimension type identifier, locate the member data table of the time period dimension, read the period code column in the member data table, perform format normalization processing on the field value of the second field and then compare it with the period code value in the period code column to obtain the matching second target code, and set the second target code as the converted time period dimension value.

4. The method for converting source system data into target budget data according to claim 3, characterized in that, In step S3, the third field is mapped and converted into the business object dimension, specifically including: S314: Read the combined mapping strategy configured for the third field from the mapping rules, the combined mapping strategy including the mapping basis field name and the tree structure traversal depth parameter; S315: Based on the mapping reference field name, extract the field value of the third field from the source business data as the search keyword, starting from the root node of the dimension member tree structure corresponding to the business object dimension, recursively compare the keyword value stored in each node with the search keyword, and locate the matching target node; S316: Read the complete path code of the target node in the dimension member tree structure, and set the complete path code as the transformed business object dimension value.

5. The method for converting source system data into target budget data according to claim 4, characterized in that, After step S3, it also includes S321: Verify whether the responsible entity dimension value obtained in step S312, the time period dimension value obtained in step S313, and the business object dimension value obtained in step S316 exist in the member data table of the responsible entity dimension, the member data table of the time period dimension, and the member data table of the business object dimension, respectively; S322: For dimension values ​​that are not found in the verification result in step S321, a correction operation is performed based on a preset substitution rule, wherein the substitution rule includes the matching conditions for invalid dimension values ​​and the corresponding valid substitution values. The non-existent dimension value is compared with the matching condition. If the comparison is successful, the valid replacement value is read and used to replace the non-existent dimension value to generate the corrected dimension value. S323: Write the dimension values ​​that do not exist in step S321, the matching conditions in step S322, the valid alternative values, and the corrected dimension values ​​into the log record table.

6. The method for converting source system data into target budget data according to claim 1, characterized in that, In step S4, the quantitative indicator fields in the source business data are mapped and converted into specific data items under the data type dimension in the target budget model, specifically including: S411: Read the quantitative indicator field configuration list from the mapping rules, wherein the configuration list records the corresponding identifiers between each quantitative indicator field and each dimension member under the data type dimension; S412: Based on the quantitative indicator field configuration list, traverse each quantitative indicator field in the source business data, and for the target quantitative indicator field currently traversed, extract the field name of the target quantitative indicator field and perform a matching query in the configuration list to obtain the data type dimension member code corresponding to the target quantitative indicator field. S413: Read the value stored in the target quantitative indicator field from the current data row of the source business data, and set the value as the value of the specific data item.

7. The method for converting source system data into target budget data according to claim 6, characterized in that, In step S4, a multi-dimensional budget data record is generated, including the responsible entity dimension, the time period dimension, the business object dimension, and the specific data items. Specifically, this includes: S414: Read the dimension values ​​of the responsible entity dimension, the time period dimension, and the business object dimension generated in step S3, and combine these three dimension values ​​with the data type dimension member code obtained in step S412 and the value of the specific data item set in step S413 to form a multidimensional data record. S415: Repeat steps S412 to S414 until all quantitative indicator fields in the quantitative indicator field configuration list have been traversed, and the values ​​of the specific data items in multiple records under the same dimension combination are merged to generate the final multidimensional budget data record set.

8. The method for converting source system data into target budget data according to claim 7, characterized in that, S415 specifically includes: S4151: Traverse the multidimensional budget data record set, extract the responsible entity dimension value, time period dimension value and business object dimension value from each record, concatenate the three dimension values ​​into a combined string in a fixed order, perform a hash operation on the combined string to generate a dimension combination hash value, and group records with the same dimension combination hash value into the same record group. S4152: Access each record group sequentially, read the data type dimension member code and the corresponding specific data item value in each record in the group, retrieve the horizontal data field array template, and write the value of each specific data item into the column position corresponding to the data type dimension member code in the template. S4153: Detect whether the same column position is written multiple times in the horizontal data field array template; If it exists, the preset aggregation rule is read, and the values ​​of multiple specific data items in the same column position are summed or arithmetic averaged according to the aggregation rule. The calculation result is written back to the column position, and the responsible entity dimension value, time period dimension value, business object dimension value and horizontal data field array are combined to generate a multidimensional budget data record.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method for converting source system data into target budget data as described in any one of claims 1 to 8.

10. A storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method for converting source system data into target budget data as described in any one of claims 1 to 8.

Images