A cross-system data path retrieval method based on a hierarchical object tree

Abstract

The present application relates to the technical field of data processing, in particular to a cross-system data path retrieval method based on a hierarchical object tree, which aims at the problems of multi-service enterprise internal multi-system data dispersion, difficult data path positioning, and high business theme expansion cost, takes a unified data base as the base, first generates a business object registration item, constructs a hierarchical object tree and establishes a source data index, then collects business indicators and performs cross-platform data path retrieval, combines deviation calculation to generate early warning, approval and assigned items, and finally writes back the disposal results to form a management closed loop. The method adopts a modular architecture and can adapt to the data retrieval needs of multiple business lines and support flexible expansion of business themes.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and more specifically, to a cross-system data path retrieval method based on a hierarchical object tree. Background Technology

[0002] With the advancement of enterprise informatization, most multi-business enterprises have deployed multiple business management systems, with various types of operational data stored across different platforms. Cross-system data path retrieval and location are crucial technical foundations for enterprises to conduct business analysis, cost control, and decision support. Their retrieval efficiency and architectural adaptability directly affect the operational efficiency of enterprise management.

[0003] Existing cross-system data retrieval solutions are typically designed for single business scenarios, lacking a unified hierarchical mapping mechanism for business objects. Data association between different systems relies on point-to-point connections, resulting in insufficient standardization of data path location and high adaptation costs when adapting to multiple business lines. Furthermore, the retrieval rules of existing solutions are deeply tied to business themes. When adding new business analysis themes or management modules, adjustments to the underlying data architecture and retrieval logic are often required, leading to insufficient flexibility in architectural expansion. In addition, most solutions only focus on the data retrieval process and fail to integrate with management processes such as early warning, approval, and handling, making it difficult to support closed-loop management of the entire business process.

[0004] To address these issues, this invention proposes a cross-system data path retrieval method based on a hierarchical object tree, thereby resolving the problems existing in the prior art. Summary of the Invention

[0005] In view of the shortcomings of the existing technology, the purpose of this invention is to provide a cross-system data path retrieval method based on a hierarchical object tree.

[0006] To achieve the above objectives, the present invention provides the following technical solution: A cross-system data path retrieval method based on a hierarchical object tree specifically includes the following steps: Step S1: Obtain cross-platform source data from multiple business platforms, generate business object registration items based on the cross-platform source data, and write the business object registration items into a unified data base. The unified data base stores business object registration items, hierarchical object tree nodes, source data indexes, target data versions, early warning events, and handling status. Step S2: Based on the business object registration items, establish a hierarchical object tree to represent the hierarchical relationship of business objects, and establish a source data index between the hierarchical object tree nodes and the cross-platform source data; Step S3: Collect cross-platform source data according to business indicators and form target data versions. Perform cross-platform data path retrieval based on hierarchical object tree and source data index to obtain the data path corresponding to the business indicators. Step S4: Calculate the indicator deviation based on the operating indicators, target data version, and data path, and generate early warning events, approval items, and assignment items associated with the indicator deviation; Step S5: Write back the handling results and status of the warning events, approval items, and assigned items to the unified data base, and associate the data path, handling process, and handling results with the warning event number.

[0007] Furthermore, the generation of business object registration items in step S1 specifically includes: identifying business objects and classifying business matters in the source system records of different business platforms; registering project, contract, cost, expense, sales, payment collection, approval, meeting and assigned business data belonging to the same business object into the same business object association range in the unified data base; and providing an object identification basis for the subsequent generation of hierarchical object tree nodes and the establishment of source data index.

[0008] Furthermore, the unified data base writing in step S1 specifically includes: establishing associations between the business object registration items and the corresponding source system records, business items, data versions, and handling status, so that cross-platform source data can be retrieved and written back according to business object, business item, target data version, or warning event number after writing.

[0009] Furthermore, the establishment of the hierarchical object tree in step S2 specifically includes: using the business object registration item as the object identifier basis for cross-platform business data, classifying the cross-platform source data into the corresponding hierarchical object tree nodes according to the investment management line, construction management line, and operation management line, and recording the business main line, superior business object, subordinate business object, and associated source data index in each hierarchical object tree node, so that the data of the same business object in different business platforms can be uniformly located through the hierarchical object tree nodes.

[0010] Furthermore, the investment management line node configuration in step S2 specifically includes: configuring project planning, project establishment, investment calculation, financing arrangement, and business objectives as hierarchical object tree nodes according to the relationship formed by the business objects, and establishing a connection between the target data version corresponding to the business objectives and the source data index corresponding to the investment calculation and financing arrangement, so that the business objectives can be traced back to the corresponding source system records along the investment management line.

[0011] Furthermore, the construction management line node configuration in step S2 specifically includes: configuring target cost, dynamic cost, contract, project progress, design change, visa, payment and settlement matters as hierarchical object tree nodes according to the business relationship between the business objects, and associating the construction management line nodes with the corresponding source data index and target data version respectively, so that cost, contract, payment and settlement related indicators can form a data path along the construction management line.

[0012] Furthermore, the specific configuration of the operation management line node in step S2 includes: configuring sales, contracts, payments, expenses, leases, senior living accommodations, and operating income items as hierarchical object tree nodes according to the aggregation relationship of operation business, and associating the operation management line node with the business object registration items and source data index, so that the relevant indicators of operating income, expenses, sales, and payments can be retrieved across system paths along the operation management line.

[0013] Furthermore, the operational indicator collection and cross-platform data path retrieval in step S3 specifically include: retrieving the target data version from the unified data base according to the indicator caliber configured in the theme hub, and tracing the source data index associated with the target data version along the hierarchical object tree nodes to form a data path between operational indicators, target data version, hierarchical object tree nodes, source system records, and business items; different theme hubs share the unified data base, operational object registration rules, hierarchical object tree, and path retrieval rules, and perform operational indicator collection, path retrieval, and deviation processing according to their respective configured indicator caliber, target source, early warning threshold, and handling process.

[0014] Furthermore, the expansion of the subject hub in step S3 specifically includes: when adding a new subject hub, connecting the new subject hub to the unified data base, and configuring corresponding indicator rules and processing procedures for the new subject hub, so that the new subject hub can use the business object registration rules, hierarchical object tree and path retrieval rules to perform data collection, path tracing and deviation processing.

[0015] Furthermore, the closed-loop handling process in step S5 specifically includes: the early warning center generates an early warning event based on the indicator deviation; the file management, meeting management, assessment and evaluation, and instruction assignment record or process the data location, handling process, responsibility feedback, and result feedback associated with the early warning event, and write back to the unified data base after associating the data path, approval items, assignment items, handling process, and handling result with the same early warning event number.

[0016] Compared with the prior art, the present invention has the following beneficial effects: 1. To address the issues of fragmented data across multiple systems and insufficient standardization of cross-platform data path location in multi-business enterprises, this invention constructs a hierarchical object tree and establishes a source data index. This maps business data from different platforms to a unified business object hierarchical framework, achieving centralized indexing and path location of data based on a unified data foundation. This technical approach provides a unified positioning benchmark for cross-system data retrieval, helps improve the orderliness of data association in multi-business line scenarios, and reduces the adaptation cost of cross-platform data searching. 2. To address the issue of high costs associated with expanding business themes in existing retrieval solutions, this invention adopts a modular architecture design. Based on a unified data foundation, each business theme hub shares a hierarchical object tree and path retrieval rules, with differences only made to the indicator definitions, warning thresholds, and handling procedures. When adding a new business theme hub, there is no need to adjust the underlying data architecture and core retrieval logic; expansion can be achieved simply by configuring the corresponding rules. This improves the architecture adaptability of the solution and reduces the implementation workload for new business scenarios. 3. Addressing the disconnect between data retrieval and operational management processes, this invention, based on cross-system data path retrieval, simultaneously achieves the collection of operational indicators, deviation calculation, early warning assignment, and result feedback, forming a complete link from data retrieval to task handling based on five key modules. This design links data retrieval capabilities with operational management processes, helping to enhance the application value of data retrieval results and supporting closed-loop management of operational tasks throughout the entire process. Attached Figure Description

[0017] Figure 1 This is an architectural diagram of the method described in this invention; Figure 2 This is a flowchart of a cross-system data path retrieval method based on a hierarchical object tree according to the present invention; Figure 3 This is a flowchart illustrating the implementation of step S3 of the present invention. Detailed Implementation

[0018] Example, refer to Figure 1 This embodiment presents a cross-system data path retrieval method based on a hierarchical object tree, which is aimed at construction companies that simultaneously operate businesses such as urban renewal, health and elderly care, and ecological real estate. The company typically deploys an ERP business platform, an OA office platform, a financial expense control platform, and an operating data display platform. Different platforms store business data such as projects, contracts, costs, expenses, sales, payments, approvals, meetings, and assignments. This method is implemented based on a modular architecture of one base, three main lines, five key elements, and an X-center. The base serves as a unified data foundation, storing business object registration items, hierarchical object tree nodes, source data indexes, target data versions, early warning events, and handling status. The three main lines include investment management, construction management, and operation management. The investment management line relates to project planning, project initiation, investment calculation, financing arrangements, and business objectives. The construction management line relates to target costs, dynamic costs, contracts, project progress, design changes, visas, payments, and settlements. The operation management line relates to sales, contracts, cash collection, expenses, leasing, senior living accommodation, and operating revenue. The five key elements include an early warning center, document management, and... The system integrates five key functions: meeting management, evaluation and assessment, and instruction assignment. These functions use the same early warning event number to link data location, handling process, and result feedback. Each module relies on a unified data platform to achieve data interoperability and process linkage. The X-Center includes an operational analysis center, a cost control center, an expense management center, and a marketing decision-making center, and can be expanded to include thematic centers such as fund management, health and wellness operations, asset operations, investment promotion operations, and project progress. All centers share a unified data platform, business object registration rules, hierarchical object trees, and path retrieval rules, differing only in indicator definitions, target sources, early warning thresholds, and handling procedures. When adding a new thematic center, expansion can be completed simply by configuring the corresponding indicator rules and handling procedures in the unified data platform, without modifying the underlying architecture. Reference Figure 2 This embodiment specifically includes the following steps: Step S1: Obtain cross-platform source data and generate business object registration items.

[0019] S11. Obtain source business records from the ERP business platform, OA office platform, and financial expense control platform through RESTful interfaces, file exchange interfaces, or message interfaces; For data obtained via API, the system reads the source platform identifier, source business type, source document key, business status, last update time, project code, company code, amount field, quantity field, approval status, and source data access address. For data obtained via file exchange, the system reads identical content according to the pre-configured field order and field names. Source business records can be in JSON, XML, CSV, or other parsable data formats. Each time a source business record is received, the source platform identifier, source business type, and source document key are concatenated in a fixed order separated by underscores to form a unique identifier for the business object. When the same unique identifier for the business object corresponds to multiple versions, the version with the latest update time is given priority. If the latest update time is the same but the version number is different, the version with the higher version number is used. If the latest update time and version number are the same, the order is determined by the timestamp of the data being written to the unified data base, the first version written is retained, and a duplicate reception identifier is recorded. S12. Convert the source business records into unified business object registration items; The registration items for business entities must include at least the unique identifier of the business entity, the source platform identifier, the source business type, the source document key, the source document status, the source data version, the last update time, the business format identifier, the company code, the project code, the business process code, the business main line identifier, the life cycle stage identifier, the indicator type, the numerical unit, the actual value, the target value, the period of occurrence, the responsible organization, the responsible person, the source data access address, and the write-back address. The actual values ​​are business data values ​​after unit conversion; monetary indicators uniformly adopt the local currency unit corresponding to the enterprise's financial accounting caliber, and the conversion exchange rate adopts the enterprise's financial benchmark exchange rate on the day the business occurs. The exchange rate configuration is maintained in the measurement rule table of the unified data base; area indicators uniformly adopt square meters, and the conversion factor adopts the unit conversion factor corresponding to the national measurement standard; quantity indicators adopt the standard measurement unit of the corresponding business object, and the conversion relationship is pre-configured in the master data mapping table; ratio indicators adopt dimensionless values; business object registration items with the same indicator type use the same unit, and values ​​of different units are not included in the direct summation of the same indicator; S13. Determine the ownership of business types, companies, and projects according to preset priorities; For source business records with complete project codes, project nodes, company nodes, and business type nodes should be determined based on the project code first. For source business records that do not carry a project code but carry a contract code, property code, cost allocation code, or expense allocation code, the project affiliation is determined based on the project code in the corresponding associated record. For source business records for which the project code cannot be determined but the company code and business type identifier can be determined, they shall be classified into the public matter business process under the corresponding company node. For cases where multiple projects are associated with the same source business record, business object registration items are generated separately based on the project allocation details recorded in the source business record. If the project allocation details are not recorded, no ratio estimation is performed. Instead, the data is written into the pending aggregation node and an aggregation anomaly flag is generated. The pending aggregation node is set under the corresponding company-level node and is at the same level as the business process level. Business objects in the pending aggregation node do not participate in the calculation of formal business indicators. After the data management personnel of the corresponding company periodically verify and supplement the project attribution, they are transferred to the corresponding business process node. S14. Determine the main business lines and lifecycle stages; The following rules are used to determine the main business line: (1) Based on the source business type, directly match the main business line. Project establishment, investment calculation, financing plan and investment decision approval are included in the investment management line; cost items, contracts, visas, payments and settlements are included in the construction management line; sales, collection of payments, expenses, leasing, health and wellness operation income and operation service items are included in the operation management line. (2) When no main line is configured for the source business type, it is matched according to the project life cycle stage. The planning, design, investment and financing stages are assigned to the investment management line, the construction stage is assigned to the construction management line, and the operation stage is assigned to the operation management line. (3) If the aforementioned rules still cannot determine the main line, the main line shall be determined based on the relationship between the indicator type and the central configuration; When the same business entity obtains different main line results through different rules, a main line conflict flag is written and it enters a pending verification state. Business entities in the pending verification state can be displayed as pending data, but they do not participate in formal indicator collection and early warning calculation. They are automatically pushed to the data administrator of the corresponding project for verification. The pending verification state is lifted after the main line is confirmed.

[0020] Step S2: Generate a hierarchical object tree and establish a source data index.

[0021] S21. Based on the enterprise's organizational structure, business type affiliation, and project master data, establish a five-level hierarchical object tree consisting of the group level, business type level, company level, project level, and business process level. Group-level nodes correspond to the corporate group headquarters; business format-level nodes correspond to business segments such as urban renewal, health and elderly care, and ecological real estate; company-level nodes correspond to platform companies, project companies, or other business entities; project-level nodes correspond to construction projects, operation projects, sales projects, or service projects; and business process-level nodes correspond to investment calculations, financing arrangements, cost items, contracts, project progress, visa matters, expense items, sales resources, collection matters, operating income, approval matters, or assigned matters. The node coding adopts a hierarchical segmented coding method. The group level is a 2-digit code, and the business type level, company level, project level, and business process level each add a 2-digit code in turn. The parent node code is the preceding segment of the current node code. Each node stores the node code, node name, node level, parent node code, effective period, responsible organization, responsible person, lower-level node index, source data index, target data index, and disposal entry index. When an organizational affiliation is adjusted at a project level node, the path before the adjustment and its effective and end times are retained, and the path after the adjustment and its effective start time are generated. The operating object is matched with a valid path according to the period during which the adjustment occurs. If the period during which the adjustment occurs falls entirely within the effective period of a certain path, the corresponding path is directly matched. If the period during which the adjustment occurs spans multiple adjustment points, the corresponding path is matched separately after splitting the period according to the adjustment point, so as to avoid re-aggregating historical data according to the adjusted organizational relationship. S22. Establish a five-level path and horizontal main line label for each business object; The five-level path of the business target is denoted as ,in, Indicates any business entity, Store the group node code, business type node code, company node code, project node code, and business process node code in sequential array format; The main business line identifier is denoted as Its value can be either the investment management line, construction management line, or operation management line. The life cycle stage identifier serves as a refined attribute of the main business line identifier, used to distinguish between stages such as planning, investment, financing, construction, and operation. The business main line identifier is not used as a sixth-level tree node, but as a horizontal retrieval condition that runs through the five-level hierarchical object tree. When searching, the data range is first determined by the hierarchical tree node, and then filtered by the business main line identifier field. Thus, under the same project node, the business links corresponding to the investment management line, construction management line and operation management line can be retrieved separately, or the overall business situation can be viewed by following all main lines. S23. Establish source data indexes at the business process layer; The source data index should include at least the source platform identifier, source business type, source document key, source document status, source data version, last update time, source data access address, and write-back address; The source data index and the business process layer nodes are associated in a one-to-many manner. When a source business record is added or updated, the source data index of the corresponding business process node is automatically updated synchronously according to the five-level path of the business object. The index update and the update of the business object registration item are completed in the same transaction. The offline business process layer of investment management can index project initiation records, investment calculation records, financing plan records, business target records, and investment adjustment approval records; The construction management offline business process layer can index target cost records, dynamic cost records, contract records, change order records, payment application records, settlement records, and cost adjustment approval records; The offline business process layer of operations management can index sales resource records, contract records, payment records, expense application records, reimbursement records, operating revenue records, occupancy records, and marketing strategy approval records.

[0022] Step S3: Collect operating indicators and perform cross-platform data path retrieval.

[0023] like Figure 3 As shown, the specific steps are as follows: S31. Configure indicator aggregation rules for each indicator; The rules for collecting indicators should include at least the indicator type, applicable central point, applicable business line, numerical unit, source business type, set of valid statuses, actual value field, statistical time field, data category, source of target value, indicator direction, warning threshold version, and handling process identifier. Data categories include sequential data and snapshot data; data that is irreversible after a business transaction occurs and is accumulated based on the number of transactions is classified as sequential data. Effective contract amounts, confirmed payment amounts, incurred expense amounts, and received payment amounts can be processed as sequential data and summarized according to the period of occurrence and validity status. Metrics that can be updated multiple times within a business cycle and only the latest status is retained are classified as snapshot data. Dynamic costs, available resources, inventory resources, and project operating forecasts can be treated as snapshot data and their values ​​are taken from the latest valid version within the statistical period before being aggregated. In the case of multiple snapshot versions within the same project, the same business process, and the same statistical period, only the valid version with the latest update time is selected to avoid repeatedly accumulating status values ​​from different time points. S32. Collect the streaming data; For nodes Business Main Line Indicator Types and statistical period The actual collected value is denoted as The calculation method is as follows: ; The set of aggregation ranges satisfies: ; In the formula, This represents the set of business entities that have completed standardized registration. Indicates the business target. The five-level path representing the business target, Represents any node in a hierarchical object tree. Indicates the main business line identifier. The main business identifier representing the target business entity. Indicates the indicator type. This indicates the type of indicator corresponding to the business entity. Indicates the period for query statistics. Indicates the period during which the business entity occurs. This indicates the valid status of the business object; the value is 1 when it is valid and 0 when it is invalid. This represents the actual value of the business entity after conversion to a unified unit. and Having the same units of measurement, all using index types The corresponding unified unit; only when the business objects belong to the same indicator type. Furthermore, only when the same units are used will they enter the same summation set; Snapshot data is first filtered by version: grouped by project node, business process node, statistical period, and indicator type. Within each group, it is sorted in descending order by the most recent update time. The first valid version in the sorted order is selected as the value for that group. Then, it is aggregated according to the same node, main line, indicator, and period conditions as above. S33, Match the target value; The target value record should include at least the target value version identifier, indicator type, business line identifier, applicable node code, effective period, target value, value unit, approval status, approval document key, and effective time. At the project and business process levels, priority is given to matching effective target value records that are consistent with the current project node, business process node, business line, indicator type, and statistical period. At the company, business format, and group levels, the target value is the result of the hierarchical aggregation of all effective target values ​​of all lower-level nodes, and the aggregation caliber is consistent with the actual value aggregation caliber. If a lower-level node has a target value pending configuration, the corresponding indicator of the upper-level node is simultaneously marked as a target value pending configuration. Nodes without configured active target values ​​will not have their deviation rate calculated or warning levels assigned; instead, the target value will be displayed as pending configuration in the corresponding indicator location. Target values ​​must not be automatically replaced by actual values, historical averages, or unapproved forecast values. S34. Perform path retrieval based on user operation; A single path retrieval request must include at least the current node code, business main line identifier, indicator type, statistical period, central identifier, warning status, and permission identifier; The permission identifier corresponds to the user's authorized scope. During retrieval, only nodes and data within the user's authorized scope are returned. For users who do not have permission to access the source business record, the source document key and source data access address fields are displayed in mask form, and sensitive values ​​are processed by magnitude for range. When the current node is a group-level node, it returns the business-level nodes that meet the search criteria and their indicator results; when the current node is a business-level node, it returns the company-level nodes that meet the search criteria and their indicator results; when the current node is a company-level node, it returns the project-level nodes that meet the search criteria and their indicator results; when the current node is a project-level node, it returns the business process-level nodes that meet the search criteria and their indicator results; when the current node is a business process-level node, it returns the corresponding source data index and source business record, including the source document key, source document status, value, responsible person, last update time, and source data access address. When the business process layer is retrieved and no valid lower-level node is found, drill-down is terminated and the source business record is displayed; after the user selects a source business record, the original record in the corresponding ERP business platform, OA office platform or financial expense control platform is located through its source data access address. For all mainline views, cross-mainline summaries are only performed on data with completely consistent indicator types, numerical units, statistical granularity, and effective status rules; for indicators with inconsistent statistical definitions, the results of each mainline are displayed separately, and direct summation is not performed.

[0024] Step S4: Calculate the deviation and generate early warnings, approvals, and assignments.

[0025] S41. Calculate the adverse deviation rate for indicators with valid target values; For nodes Business Main Line Indicator Types and statistical period Unfavorable deviation rate is denoted as The calculation method is as follows: ; In the formula, Indicates the actual collected value. This indicates a valid target value that shares the same node range, business scope, indicator type, statistical period, and numerical unit as the actual collected value. This represents the directional coefficient for indicators. For cost, expense, and deviation indicators, a higher value indicates increased risk, and the value is 1. For revenue, cash collection, and progress indicators, a lower value indicates increased risk, and the value is -1. The coefficient value is configured synchronously with the indicator aggregation rules. Indicates indicator type The corresponding denominator protection value, dimensions and index type Correspondingly, monetary indicators are set to the smallest monetary unit for corporate financial accounting, while quantity indicators are set to the smallest counting precision of the corresponding unit of measurement. This is to avoid the situation where the denominator is meaningless when the target value is 0. The values ​​are maintained in the indicator configuration rules. S42. Generate warning levels based on the warning threshold version; Configure a yellow alert threshold for each business line and indicator type. and red alert threshold Where: ; Both the yellow and red warning thresholds are dimensionless values. Their effectiveness is based on the company's approved cost control system, budget management system, business target management system, or valid resolutions formed at business analysis meetings. The warning threshold version is associated with the effective period. If the statistical period falls within the effective period of the threshold, the corresponding version of the threshold will be used for hierarchical judgment. when When the value is below the yellow warning threshold, a green status is generated; when A yellow alert is generated when the threshold is not less than the yellow alert threshold and less than the red alert threshold. when A red alert is generated when the value is not less than the red alert threshold. Each early warning event includes at least the early warning event number, node path, business line, lifecycle stage, indicator type, statistical period, actual value, target value, adverse deviation rate, early warning level, responsible organization, responsible person, processing time limit, source data index, and current handling status; the early warning event number is generated by concatenating the node code, business line identifier, indicator type code, and statistical period code in a fixed order; For unclosed early warning events with the same node path, business line, indicator type, statistical period, and target value version, only one activity event is retained; when triggered repeatedly, the actual value, most recent update time, and warning level of the activity event are updated, and approval or assignment items are not generated repeatedly; the statistical period adopts a method that is compatible with both natural and custom periods, and the period matching is determined by the complete overlap of the start and end times. S43. Match the handling process according to the main business line and business process; The early warning events in the investment management offline system can be matched with adjustments to project initiation, investment calculation, financing plan, business objectives, or investment decision review processes; The early warning events under the construction management line can be matched with target cost adjustments, contract changes, engineering visas, payment control, settlement review, or cost deviation explanation processes; Offline operational management alerts can be matched with processes for budget adjustments, overspending explanations, sales strategy adjustments, pricing policy approvals, payment collection reminders, operational revenue rectification, or operational plan adjustments. When matching processes, the handling template is selected in sequence according to project-level rules, company-level rules, and group-level rules. The template configured at the project level is matched first. If there is no project-level template, the company-level template is matched. If neither is configured, the group-level general template is matched. If no handling template is matched, the warning event is marked as a process pending configuration and pushed to the corresponding management personnel for template configuration. Irrelevant processes are not automatically selected. The template has a pre-defined mapping relationship between form fields and warning event fields. When an approval or assignment is initiated, the corresponding fields of the warning event are automatically written into the corresponding positions of the form according to the mapping relationship. The written content includes the warning event number, node path, business line, life cycle stage, business type, company, project, business link, indicator type, statistical period, actual value, target value, adverse deviation rate, source document key, responsible organization, responsible person and processing time limit.

[0026] Step S5: Write back the processing results and form a closed loop through the five key measures.

[0027] S51. Receive status feedback information for approvals, meetings, and assignments; Approval forms, meeting items, and assigned tasks all carry warning event numbers; after the OA office platform or meeting management page returns the process instance identifier, handling status, handling opinion, responsible person, completion deadline, and update time, the corresponding content is written into the unified data base; status changes are proactively triggered to write back through the message interface, synchronously updating the full status information of the corresponding warning event; The handling status includes at least the following: pending, in process, completed, rejected, closed, and overdue. For handling results involving target adjustments, a new version of the target value record is generated only when the approval is granted and the target value record has an effective time, valid version, and approval document key. The target value index is then updated to point to the latest effective version. For handling results involving contract adjustments, cost control, payment collection, engineering rectification, or business strategy adjustments, the original target value is retained, and the actual value and deviation rate are recalculated after subsequent updates to the source business data. S52. Handle early warning events according to the five key measures; The early warning center stores the early warning event number, early warning level, responsible organization, responsible person, first response time, current status and escalation status, serving as a unified entry point for displaying and processing early warning events, and synchronizing the progress information of all activity early warnings in real time; The record management system establishes an independent record catalog based on the warning event number, and collects source business records, target value versions, deviation calculation results, approval forms, meeting minutes, assignment feedback and closure records in chronological order to form a traceable chain of business evidence. Meeting management sets inclusion criteria based on warning level, overdue duration, and number of organizations involved. Warning items that meet the criteria are automatically added to the meeting candidate list. Meeting resolutions are associated with warning event numbers and hierarchical object tree nodes and written back to the unified data base. The assessment and evaluation generate assessment data based on the response time of the early warning event, the completion of the handling, the overdue status, the recurrence, and the implementation status of meeting resolutions. The assessment rules can be configured according to the company's management requirements. The instructions for assignment break down the processing opinions that do not require adjustment of target values ​​but require specific actions into independent assignment items, and save the responsible organization, responsible person, completion deadline, related source documents and feedback requirements; S53. Recalculate the warning status and execute shutdown or escalation; When the source business record, target value version, approval status, or assignment feedback changes, the actual value and adverse deviation rate of the corresponding indicator are recalculated; the warning event is set to closed status when the following conditions are met: If the approvals, meeting resolutions, or assigned tasks associated with the warning event have been completed, and the recalculated adverse deviation rate is lower than the yellow warning threshold; or if the warning event has been confirmed by effective approval as not requiring further handling, the approver can directly close it after indicating the reason for closure; if the warning event exceeds the processing time limit and is still pending or in the processing state, it will be pushed to the next higher level of responsible organization according to the preset time threshold. After the upgrade, the original responsible person will receive the notification simultaneously, and the original warning event number and all historical handling records will be retained. S54. Execution permission verification and data consistency verification; Each time a display, retrieval, drill-down, approval initiation, or source data access occurs, verification is performed based on the user's organization, authorized project, authorized business type, authorized business line, and source platform access permissions. Users without access to source business records can only obtain summary indicators, warning levels, and de-identified processing status, but not source document keys, source data access addresses, and sensitive business fields; When a document from the same source is voided, withdrawn, rejected, or updated, its validity status is updated based on the unique identifier of the business entity. Expired business entities will no longer participate in subsequent indicator collection, but historical versions and processing records will be retained to ensure the traceability of business data and early warning handling processes. Data consistency verification can be achieved through two methods: scheduled batch verification and real-time triggered verification, to ensure that the data at the base station is consistent with the data at the source platform.

[0028] Through the detailed description of the above embodiments, the present invention provides a cross-system data path retrieval method based on a hierarchical object tree. This method establishes a data foundation using a unified data base, constructs a hierarchical object tree based on business object registration items, and establishes a source data index, forming a unified framework for cross-system data location. On this basis, it performs business indicator collection and cross-platform data path retrieval, combines deviation calculation to generate corresponding early warnings, approvals, and assignments, and achieves a management closed loop through result write-back. This method adopts a modular architecture design, covering multiple business lines such as investment, construction, and operation. It can adapt to the cross-system data retrieval needs of multi-business enterprises and supports flexible expansion of multiple thematic hubs, providing a feasible technical implementation path for the location, analysis, and control of cross-system business data.

[0029] The preset parameters in the above formulas shall be set by those skilled in the art according to the actual situation.

[0030] 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, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0031] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes 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 this application.

[0032] Those skilled in the art will recognize that the units 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.

[0033] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0034] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0035] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

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

Claims

1. A cross-system data path retrieval method based on a hierarchical object tree, characterized in that, The method flow is as follows: Step S1: Obtain cross-platform source data from multiple business platforms, generate business object registration items based on the cross-platform source data, and write the business object registration items into a unified data base. The unified data base stores business object registration items, hierarchical object tree nodes, source data indexes, target data versions, early warning events, and handling status. Step S2: Based on the business object registration items, establish a hierarchical object tree to represent the hierarchical relationship of business objects, and establish a source data index between the hierarchical object tree nodes and the cross-platform source data; Step S3: Collect cross-platform source data according to business indicators and form target data versions. Perform cross-platform data path retrieval based on hierarchical object tree and source data index to obtain the data path corresponding to the business indicators. Step S4: Calculate the indicator deviation based on the operating indicators, target data version, and data path, and generate early warning events, approval items, and assignment items associated with the indicator deviation; Step S5: Write back the handling results and status of the warning events, approval items, and assigned items to the unified data base, and associate the data path, handling process, and handling results with the warning event number.

2. The cross-system data path retrieval method based on a hierarchical object tree according to claim 1, characterized in that, The specific steps of generating the business object registration item in step S1 include: identifying business objects and assigning business items to source system records in different business platforms; registering project, contract, cost, expense, sales, payment, approval, meeting and assigned business data belonging to the same business object to the same business object association range in the unified data base; and providing the object identification basis for the subsequent generation of hierarchical object tree nodes and the establishment of source data index.

3. The cross-system data path retrieval method based on a hierarchical object tree according to claim 2, characterized in that, The unified data base writing in step S1 specifically includes: establishing associations between the business object registration items and the corresponding source system records, business items, data versions, and handling status, so that cross-platform source data can be retrieved and written back according to business object, business item, target data version, or early warning event number after writing.

4. The cross-system data path retrieval method based on a hierarchical object tree according to claim 1, characterized in that, The establishment of the hierarchical object tree in step S2 specifically includes: using the business object registration item as the object identifier basis for cross-platform business data, classifying the cross-platform source data into the corresponding hierarchical object tree nodes according to the investment management line, construction management line, and operation management line, and recording the business main line, superior business object, subordinate business object, and associated source data index in each hierarchical object tree node, so that the data of the same business object in different business platforms can be uniformly located through the hierarchical object tree nodes.

5. The cross-system data path retrieval method based on a hierarchical object tree according to claim 4, characterized in that, The specific configuration of the investment management line nodes in step S2 includes: configuring project planning, project establishment, investment calculation, financing arrangement and business objectives as hierarchical object tree nodes according to the business relationship between the business objects, and establishing a connection between the target data version corresponding to the business objectives and the source data index corresponding to the investment calculation and financing arrangement, so that the business objectives can be traced back to the corresponding source system records along the investment management line.

6. The cross-system data path retrieval method based on a hierarchical object tree according to claim 4, characterized in that, The specific configuration of the construction management line nodes in step S2 includes: configuring target cost, dynamic cost, contract, project progress, design change, visa, payment and settlement matters as hierarchical object tree nodes according to the succession relationship of construction business, and associating the construction management line nodes with the corresponding source data index and target data version respectively, so that cost, contract, payment and settlement related indicators can form a data path along the construction management line.

7. The cross-system data path retrieval method based on a hierarchical object tree according to claim 4, characterized in that, The specific configuration of the operation management line node in step S2 includes: configuring sales, contract signing, payment collection, expenses, leasing, health and wellness accommodation and operation revenue items as hierarchical object tree nodes according to the aggregation relationship of operation business, and associating the operation management line node with the business object registration item and source data index, so that operation revenue, expenses, sales and payment collection related indicators can be retrieved across system paths along the operation management line.

8. The cross-system data path retrieval method based on a hierarchical object tree according to claim 1, characterized in that, Step S3, which involves the collection of operational indicators and the retrieval of cross-platform data paths, specifically includes: retrieving the target data version from the unified data base according to the indicator criteria configured in the thematic hub, and tracing the source data index associated with the target data version along the hierarchical object tree nodes to form a data path between operational indicators, target data versions, hierarchical object tree nodes, source system records, and business items; different thematic hubs share the unified data base, operational object registration rules, hierarchical object trees, and path retrieval rules, and perform operational indicator collection, path retrieval, and deviation processing according to their respective configured indicator criteria, target sources, early warning thresholds, and handling procedures.

9. A cross-system data path retrieval method based on a hierarchical object tree according to claim 8, characterized in that, The specific expansion of the theme hub in step S3 includes: when adding a new theme hub, connecting the new theme hub to the unified data base, and configuring corresponding indicator rules and processing procedures for the new theme hub, so that the new theme hub can use the business object registration rules, hierarchical object tree and path retrieval rules to perform data collection, path tracing and deviation processing.

10. A cross-system data path retrieval method based on a hierarchical object tree according to claim 1, characterized in that, The closed-loop handling process in step S5 specifically includes: the early warning center generates an early warning event based on the indicator deviation; the file management, meeting management, assessment and evaluation, and instruction assignment record or process the data location, handling process, responsibility feedback and result feedback associated with the early warning event, and write back to the unified data base after associating the data path, approval items, assignment items, handling process and handling result with the same early warning event number.

Images