A mobile end arrears analysis method, device, equipment and product based on a self-service BI platform

Abstract

This invention discloses a mobile-based accounts payable and debt settlement analysis method, apparatus, equipment, and product based on a self-service BI platform, relating to the fields of business intelligence and mobile application technology. The method first responds to a first user's configuration operation by obtaining the selected target chart type, dimensions, and metric fields, dynamically generating a query statement to extract data from the accounts payable and debt settlement dataset and generating a publishable analysis view. In response to a publishing operation, the analysis view is compiled to generate an access link and bound to the mobile terminal menu. In response to a second user's access request, authentication is performed to obtain role information, organizational hierarchy attributes are determined, and the query statement is regenerated based on the analysis view's configuration information. The organizational hierarchy attributes are injected into the query statement as filtering conditions before execution, obtaining target data within the authorized scope. Based on this, a target view is generated, adapted and rendered according to the terminal screen characteristics, and then pushed for display. This improves the flexibility, security, and user experience of mobile BI analysis.

Description

Technical Field

[0001] This invention belongs to the field of business intelligence and mobile application technology, specifically relating to a mobile-based debt collection and settlement analysis method, device, equipment, and product based on a self-service BI platform. Background Technology

[0002] As enterprises undergo deeper digital transformation, data-driven decision-making becomes crucial. Accounts payable and debt collection management, as core components of a company's cash flow and supply chain health, directly impacts its financial security and operational efficiency through efficient analysis and deep insights. Business Intelligence (BI) systems should be key tools for achieving this goal; however, existing technologies face numerous bottlenecks and challenges in this specific business scenario.

[0003] Firstly, regarding the construction of analytical scenarios, most existing BI systems rely on IT personnel for customized development. If business personnel need to create or adjust analytical views, they must submit requirements to the IT department and go through a lengthy process of requirements communication, development coding, and testing and deployment. This development model is not only costly in terms of communication and long response cycles, but also, due to the professional barriers between business and IT personnel, the final analytical views are prone to deviating from actual business needs, making it difficult to quickly respond to the timeliness requirements of management decisions.

[0004] Secondly, regarding the mobile access experience, traditional BI systems are primarily designed for personal computers (PCs), with chart layouts, font sizes, and interaction methods optimized for large screens and mouse operation. Simply migrating these complex PC-based analytical interfaces directly to mobile browsers often results in slow page loading, small and difficult-to-read chart elements, and densely packed controls that are inconvenient to touch. This leads to a severely poor mobile user experience, failing to meet the needs of managers to view and analyze business data in real-time during business trips or meeting breaks.

[0005] Furthermore, regarding data access security, traditional BI systems typically employ rather rudimentary access control, generally only controlling whether a user can access a specific report or analytical view. It's difficult to implement differentiated data access controls for users with different roles or organizational levels within the same analytical view. This leaves sensitive business data vulnerable to insufficient security isolation when accessed across different levels, making it difficult to balance the convenience of data sharing with the rigor of data security management.

[0006] In summary, existing technologies lack flexibility and immediacy in constructing BI analysis scenarios, mobile chart presentation lacks targeted adaptation and optimization, and data access lacks granular permission control mechanisms. To address these technical issues, there is an urgent need in this field for a new solution that enables business personnel to independently and quickly build analytical views, achieve optimized presentation on mobile devices, and implement fine-grained data access control. Summary of the Invention

[0007] The purpose of this invention is to provide a mobile-based debt collection and settlement analysis method, device, computer equipment, computer-readable storage product, and computer program product based on a self-service BI platform, in order to solve the problems of the lack of flexibility and immediacy in the construction of BI analysis scenarios, the lack of targeted adaptation and optimization in the presentation of charts on mobile devices, and / or the lack of a refined permission control mechanism for data access in the existing technology.

[0008] To achieve the above objectives, the present invention adopts the following technical solution: Firstly, a mobile-based method for analyzing accounts payable and debt collection based on a self-service BI platform is provided, including: In response to the analysis scenario configuration operation triggered by the first user through the visualization configuration interface of the self-service BI platform, obtain the selected target chart type, at least one dimension field and at least one measure field; Based on the at least one dimension field and the at least one metric field, a first data query statement is generated, and the first data query statement is applied to query the data to be analyzed from the preset payable and debt collection dataset. Based on the data to be analyzed and the target chart type, generate an analysis view to be published; In response to the publishing operation triggered by the first user through the publishing interface of the self-service BI platform, the analysis view is compiled, an access link is generated, and a binding relationship is established between the access link and the target menu item of the mobile application. In response to an access request triggered by a second user through the target menu item in the mobile application in response to the access link, the second user is authenticated to obtain the second user's role information; Based on the role information, determine the organizational hierarchy attribute of the second user, and generate a second data query statement for data acquisition based on the configuration information of the analysis view associated with the access link; The organizational hierarchy attribute is used as a dynamic filtering condition and injected into the second data query statement to obtain a third data query statement. The third data query statement is then used to query the target data within the second user's permission range from the payable and debt collection dataset. Based on the target data, generate a target analysis view containing the data content; Based on the screen characteristics of the second user's mobile terminal, the target analysis view is adapted and rendered, and the rendering result is pushed to the mobile terminal for output display.

[0009] Based on the above-mentioned invention, a new solution is provided that enables business personnel to independently and quickly build analytical views, achieve optimized presentation on mobile devices, and implement fine-grained data access control. Specifically, in response to the configuration operation of the first user, the selected target chart type, dimensions, and metric fields are obtained. A query statement is dynamically generated to extract data from the accounts payable and debt settlement dataset and generate an analytical view to be published. In response to the publishing operation, the analytical view is compiled to generate an access link and bound to the mobile device menu. In response to the access request of the second user, authentication is performed to obtain role information, organizational hierarchy attributes are determined, and the query statement is regenerated based on the configuration information of the analytical view. The organizational hierarchy attributes are injected into the query statement as dynamic filtering conditions and executed to obtain target data within the authorized scope. Based on the target data, a target analytical view is generated, adapted and rendered according to the characteristics of the mobile terminal screen, and then pushed for display. This allows business personnel to build analytical views independently, automatically obtain differentiated data when users with different permissions access the same view, and adapt mobile charts to device screen characteristics, improving the flexibility, security, and user experience of mobile BI analysis, facilitating practical application and promotion.

[0010] In one possible design, in response to the analysis scenario configuration operation triggered by the first user through the visualization configuration interface of the self-service BI platform, the selected target chart type, at least one dimension field, and at least one measure field are obtained, including: In response to the first user's selection of the chart type control in the visualization configuration interface of the self-service BI platform, determine the selected target chart type; The visualization configuration interface is provided with a list of optional fields in the payable and debt collection dataset, so that each field control corresponding to each optional field in the list is presented on the visualization configuration interface. The list of optional fields includes dimension fields and metric fields. In response to the first user's drag-and-drop operation on the field controls in the visualization configuration interface, at least one field corresponding to at least one field control in the dimension configuration area of ​​the visualization configuration interface is determined as at least one selected dimension field, and at least one field corresponding to at least one field control in the metric configuration area of ​​the visualization configuration interface is determined as at least one selected metric field.

[0011] In one possible design, the organizational hierarchy attribute is used as a dynamic filtering condition and injected into the second data query statement to obtain a third data query statement, including: The value of the organizational hierarchy attribute is used as a condition parameter and appended to the condition clause of the second data query statement to obtain a new condition clause that restricts the query results to include only data rows associated with the organizational hierarchy attribute. Based on the new conditional clause and the other clauses in the second data query statement besides the conditional clause, a third data query statement is assembled.

[0012] In one possible design, based on the target data, a target analysis view containing the data content is generated, including: Based on the role information of the second user, determine the analysis view hierarchy configuration information corresponding to the role information, wherein the analysis view hierarchy configuration information is used to define the number and type of indicator cards to be displayed, and different roles have different analysis view hierarchy configuration information; Based on the target data and the analysis view hierarchy configuration information corresponding to the role information, a target analysis view containing data content is generated, wherein the data content includes indicator cards and charts that match the role permissions of the second user.

[0013] In one possible design, the target analysis view is adapted and rendered based on the screen characteristics of the second user's mobile terminal, including: Obtain the screen characteristic information of the second user's mobile terminal; Based on the target chart type and the screen characteristic information, the target preset style parameters are retrieved from the preset mobile chart style library. The mobile chart style library stores preset style parameters for each chart type under different screen characteristics. The preset style parameters include the coordinate axis text font size for adapting to touch operation and screen size-limited reading needs, and the graphic element color scheme for adapting to screen size-limited visual hierarchy needs. Based on the target preset style parameters, the target analysis view is rendered to adapt to the screen of the second user's mobile terminal.

[0014] In one possible design, prior to the analysis scenario configuration operation triggered by the first user through the visual configuration interface of the self-service BI platform, the method further includes: Using batch synchronization tools, accounts payable data, payment plan data, and contract information data from at least one source business system can be synchronized to the data platform. In the data platform, the synchronized accounts payable data, payment plan data, and contract information data are cleaned and transformed, and the enumerated values ​​of key business fields in the processed data are normalized to construct the accounts payable collection dataset. The key business fields include at least an aging field and a reason for non-payment field.

[0015] In one possible design, after generating the analysis view to be published, the method further includes: In response to the drill-down rule configured by the first user for the target chart in the analysis view, a penetrating query link is established between the target chart and the lower-level detail page. The penetrating query link is configured to: when a trigger operation on the graphic element of the target chart in the target analysis view is detected, extract the dimension value associated with the triggered graphic element, and use the dimension value as a query parameter to dynamically generate a detail data query statement for querying the lower-level detail page.

[0016] In one possible design, the method further includes: Construct an accounts payable risk rule base, wherein the accounts payable risk rule base stores at least one risk assessment condition and the information of the responsible person mapped to each risk assessment condition; Based on the aforementioned payable and debt collection risk rule base, the payable and debt collection dataset is scanned by a scheduled task, and data records that meet any risk judgment condition in the payable and debt collection risk rule base are identified as early warning events. Based on the risk assessment criteria matched by the warning event, the information of the responsible party corresponding to the criteria in the payable debt risk rule base is queried to determine the target responsible party; A structured warning message containing the warning event is generated, and the internal network message push gateway is invoked to send the structured warning message to the enterprise internal communication system, so that the enterprise internal communication system forwards the structured warning message to the mobile terminal of the person in charge of the target.

[0017] In one possible design, a debt collection risk rule base is constructed, including: The self-service BI platform provides optional risk assessment fields and logical operators to its rule configuration interface, wherein the risk assessment fields include at least an amount field and an aging field. In response to the administrator user's use of the risk judgment field and the logical operator to define the composite judgment condition in the rule configuration interface, a risk judgment condition corresponding to the composite judgment condition is generated, and the responsible person information mapped to the risk judgment condition is configured; The mapping relationship between the risk assessment conditions and the information of the responsible persons is stored in the payable and debt collection risk rule base.

[0018] In one possible design, the method further includes: After receiving complaint lead data from an external system, the complaint lead data is parsed to extract key field information from the complaint lead. The key field information includes at least the complaint date, responsible unit, and source of the lead. Based on the key field information obtained from the parsing, a debt collection task is generated, wherein the debt collection task includes a description of the matter to be handled and information on the attribution of responsibility; The debt collection clue tasks are integrated with the early warning events scanned and identified from the debt collection dataset to construct a unified early warning supervision task list, so that the target responsible person can view and process the early warning events and debt collection clue tasks in the early warning supervision task list through a mobile terminal.

[0019] Secondly, a mobile-based debt collection and settlement analysis device based on a self-service BI platform is provided, including a configuration operation response unit, an analysis data query unit, an analysis view generation unit, a release operation response unit, an access request response unit, an attribute statement acquisition unit, a target data query unit, and an analysis view rendering unit. The configuration operation response unit is used to respond to the analysis scenario configuration operation triggered by the first user through the visualization configuration interface of the self-service BI platform, and to obtain the selected target chart type, at least one dimension field and at least one metric field. The analytical data query unit is communicatively connected to the configuration operation response unit, and is used to generate a first data query statement based on the at least one dimension field and the at least one metric field, and to use the first data query statement to query the data to be analyzed from the preset payable and debt collection dataset. The analysis view generation unit is communicatively connected to the configuration operation response unit and the analysis data query unit, respectively, and is used to generate an analysis view to be published based on the data to be analyzed and the target chart type; The release operation response unit is communicatively connected to the analysis view generation unit. It is used to respond to the release operation triggered by the first user through the release interface of the self-service BI platform, compile the analysis view, generate an access link, and establish a binding relationship between the access link and the target menu item of the mobile application. The access request response unit is communicatively connected to the publishing operation response unit, and is used to respond to the access request triggered by the second user through the target menu item in the mobile application for the access link, and to authenticate the second user to obtain the role information of the second user; The attribute statement acquisition unit is communicatively connected to the attribute statement acquisition unit and is used to determine the organizational level attribute of the second user based on the role information, and generate a second data query statement for data acquisition based on the configuration information of the analysis view associated with the access link. The target data query unit is communicatively connected to the attribute statement acquisition unit. It is used to inject the organizational hierarchy attribute as a dynamic filtering condition into the second data query statement to obtain a third data query statement, and to use the third data query statement to query the target data within the permission scope of the second user from the payable and debt collection dataset. The analysis view generation unit is also communicatively connected to the target data query unit and is further configured to generate a target analysis view containing data content based on the target data. The analysis view rendering unit is communicatively connected to the analysis view generation unit. It is used to adapt and render the target analysis view based on the screen characteristics of the second user's mobile terminal, and push the rendering result to the mobile terminal for output display.

[0020] Thirdly, the present invention provides a computer device comprising a storage module, a processing module, and a transceiver module connected in sequence for communication, wherein the storage module is used to store a computer program, the transceiver module is used to send and receive messages, and the processing module is used to read the computer program and execute the mobile terminal debt collection analysis method as described in the first aspect or any possible design in the first aspect.

[0021] Fourthly, the present invention provides a computer-readable storage product storing instructions that, when executed on a computer, perform the mobile terminal debt collection analysis method as described in the first aspect or any possible design within the first aspect.

[0022] Fifthly, the present invention provides a computer program product, including a computer program or instructions, wherein the computer program or instructions, when executed by a computer, implement the mobile terminal payable and debt settlement analysis method as described in the first aspect or any possible design in the first aspect.

[0023] The beneficial effects of the above scheme are: (1) This invention creatively provides a new solution that enables business personnel to independently and quickly build analysis views, obtain optimized presentation effects on mobile devices, and achieve fine-grained data access control. Specifically, in response to the configuration operation of the first user, the selected target chart type, dimension, and measurement fields are obtained, and a query statement is dynamically generated to extract data from the payable and debt collection dataset and generate an analysis view to be published. In response to the publishing operation, the analysis view is compiled to generate an access link and bound to the mobile device menu. In response to the access request of the second user, the identity verification is performed to obtain role information, the organizational hierarchy attribute is determined, and the query statement is regenerated according to the configuration information of the analysis view. The organizational hierarchy attribute is injected into the query statement as a dynamic filtering condition and then executed to obtain the target data within the permission range. Based on the target data, a target analysis view is generated, and after adaptation rendering according to the characteristics of the mobile terminal screen, it is pushed and displayed. In this way, business personnel can build analysis views independently, different users with different permissions can automatically obtain differentiated data when accessing the same view, and the mobile terminal charts can be adapted and rendered according to the characteristics of the device screen, which improves the flexibility, security, and user experience of mobile BI analysis. (2) The target chart type, dimension field and metric field selected by the first user are obtained through the visual configuration interface, and the data query statement is automatically and dynamically generated, so that business personnel can build analysis views independently without writing code. This solves the technical problems of high communication costs and long response cycles caused by the reliance on IT customization development in traditional BI systems, and improves the flexibility and efficiency of analysis scenario construction. (3) By determining the organizational level attribute of the second user based on the role information of the second user during the access phase, and dynamically regenerating the second data query statement, the value of the organizational level attribute is injected as a condition parameter into the condition clause of the query statement, thus realizing the dynamic combination of permission filtering conditions and data query statements. This enables users of different organizational levels to automatically obtain differentiated data result sets that match their permissions when accessing the same analysis view, thereby ensuring data security while realizing fine-grained row-level data access control. (4) By obtaining the actual screen characteristic information of the second user's mobile terminal, and accurately matching the preset style parameters adapted to the current device from the preset mobile terminal chart style library according to the target chart type and screen characteristic information, and then re-rendering the target analysis view based on the parameters, the transformation from fixed style rendering to dynamic adaptation rendering according to device characteristics is realized, which solves the technical problems of poor display effect and inconvenient touch interaction of traditional BI charts on mobile terminal screens, so that mobile terminals with different screen characteristics can obtain a good visualization analysis experience. (5) By constructing a standardized dataset for the topic of accounts payable and debt collection analysis, the raw data is cleaned, transformed and normalized after the data is synchronized to the data platform. This solves the technical problem of inaccurate analysis results caused by scattered data sources, inconsistent data formats and inconsistent field enumeration values. It provides a high-quality unified data foundation for self-service configuration and permission filtering query in subsequent analysis scenarios. (6) By configuring drill-down rules for the target chart in the analysis view and establishing a penetrating query link, when viewing the summary chart on the mobile terminal, the dimension values ​​associated with the triggered graphic elements can be extracted as query parameters through touch interaction, and detailed data query statements can be dynamically generated. This realizes one-stop penetrating analysis from macro indicator overview to micro detailed ledger, and improves the interactive coherence and data exploration efficiency of mobile BI analysis. (7) By constructing a risk rule base for accounts payable and debt collection, the dataset is automatically scanned and risks are identified using scheduled tasks. The target responsible person is automatically determined based on the mapping relationship between the rule conditions and the responsible person. The warning message is securely forwarded to the mobile terminal of the responsible person through the intranet message push gateway and the enterprise internal communication system. This realizes end-to-end closed-loop management from risk rule definition, automatic risk identification, responsible person matching to security warning push. This improves the timeliness of the response to accounts payable and debt collection risks while ensuring the security of intranet transmission of warning data. (8) By accessing complaint clue data from external systems and parsing and extracting key field information, external complaint clues are transformed into standardized debt collection clue tasks. These tasks are then integrated with early warning events generated by internal rule scanning into a unified early warning supervision task list. This achieves dual-source task fusion of external complaint channels and internal data scanning, enabling the responsible person to view and process all pending tasks in a unified view on the mobile terminal. This avoids the inefficiency of management caused by switching between multiple systems and information dispersion, improves the comprehensiveness and processing efficiency of debt collection supervision, and facilitates practical application and promotion. Attached Figure Description

[0024] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the 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.

[0025] Figure 1 This is a flowchart illustrating the mobile-based accounts payable and debt settlement analysis method based on a self-service BI platform, as provided in an embodiment of this application.

[0026] Figure 2This is a schematic diagram of the structure of a mobile debt collection and analysis device based on a self-service BI platform provided in an embodiment of this application.

[0027] Figure 3 A schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0028] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the present invention will be briefly introduced below in conjunction with the accompanying drawings and descriptions of the embodiments or the prior art. Obviously, the following description of the structure of the accompanying drawings is only some embodiments of the present invention. For those skilled in the art, other embodiments can be obtained based on these embodiments without creative effort. It should be noted that the description of these embodiments is for the purpose of helping to understand the present invention, but does not constitute a limitation of the present invention.

[0029] It should be understood that although the terms "first" and "second", etc., may be used herein to describe various objects, these objects should not be limited by these terms. These terms are only used to distinguish one object from another. For example, the first object may be referred to as the second object, and similarly, the second object may be referred to as the first object, without departing from the scope of the exemplary embodiments of the invention.

[0030] It should be understood that the term "and / or" that may appear in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A exists alone, B exists alone, or A and B exist simultaneously. Another example is A, B and / or C, which can mean that any one of A, B, and C or any combination thereof exists. The term " / and" that may appear in this document describes another relationship between related objects, indicating that two relationships can exist. For example, A / and B can mean: A exists alone or A and B exist simultaneously. In addition, the character " / " that may appear in this document generally indicates that the related objects before and after it are in an "or" relationship.

[0031] Example like Figure 1As shown, the mobile-based accounts payable and debt collection analysis method based on a self-service BI platform provided in the first aspect of this embodiment can be executed, but is not limited to, by a computer device with certain computing resources, such as a server or cloud server deployed with a self-service BI platform. The self-service BI platform, as the core software system carrying the method of this invention, runs on the server and provides a visual configuration interface and a publishing interface for the first user (i.e., the configurer of the analysis scenario, such as a business analyst) to access and operate through a browser or other client. Simultaneously, the self-service BI platform provides a mobile application access interface for the second user (i.e., the viewer of the analysis view, such as a manager or field debt collection personnel) to access through a mobile terminal. The server is responsible for executing core computing and data processing tasks such as configuration response of the analysis scenario, dynamic generation of data query statements, compilation and publishing of analysis views, user identity verification, data permission filtering and injection, adaptation and rendering of analysis views, and push notifications to mobile terminals. The server establishes a data connection with a pre-set accounts payable and debt collection dataset to support data query and scanning operations on the dataset. The server also establishes a communication connection with the enterprise's internal communication system to support the secure push of early warning messages within the intranet. The mobile terminal can be a portable device such as a smartphone or tablet, on which a mobile application is installed. The mobile application communicates with the server via a wireless network to receive and display the adapted and rendered analysis view page.

[0032] like Figure 1 As shown, the mobile terminal debt collection analysis method includes, but is not limited to, the following steps S1 to S9.

[0033] S1. In response to the analysis scenario configuration operation triggered by the first user through the visualization configuration interface of the self-service BI platform, obtain the selected target chart type, at least one dimension field, and at least one measure field.

[0034] In step S1, the self-service BI platform provides a graphical configuration interface for the first user (i.e., the configurator of the analysis scenario, such as a business analyst), enabling the first user to independently construct the analysis scenario through interface interaction without writing code. The analysis scenario configuration operation refers to a set of interactive operations performed by the first user to construct an accounts payable and debt collection analysis view, including at least the selection of chart type and the selection of analysis data fields. The target chart type refers to the visual chart format the first user wishes to use to present the data, such as a bar chart, pie chart, line chart, or indicator card. The dimension field refers to the business field used to classify or group the data, such as unit name, department name, payment type, or aging range. The measure field refers to the business field used for numerical calculation or statistics, such as the amount payable, outstanding balance, or reduction rate. Through this step, the self-service BI platform can capture the first user's configuration intent, providing an input basis for subsequently dynamically generating data query statements and rendering analysis views. Preferably, in response to the analysis scenario configuration operation triggered by the first user through the visualization configuration interface of the self-service BI platform, the selected target chart type, at least one dimension field and at least one measure field are obtained, including but not limited to the following steps S11 to S13.

[0035] S11. In response to the first user's selection operation of the chart type control in the visualization configuration interface of the self-service BI platform, determine the selected target chart type.

[0036] In step S11, the visualization configuration interface includes a chart type selection area displaying multiple chart type controls. Each control corresponds to a selectable chart type, such as a bar chart, pie chart, line chart, or indicator card. These control types can be interface elements presented as icons, thumbnails, or list items. When the first user selects a chart type control by clicking or touching, the self-service BI platform receives the selection and determines the chart type corresponding to the selected control as the target chart type. For example, if the first user needs to view the comparative distribution of accounts payable and debt settlement for each unit, they can select a bar chart control; if they need to view the percentage composition of each type of payment, they can select a pie chart control.

[0037] S12. Provide the visualization configuration interface with a list of optional fields in the payable and debt settlement dataset, so as to present on the visualization configuration interface each field control corresponding to each optional field in the list of optional fields, wherein the list of optional fields includes dimension fields and metric fields.

[0038] In step S12, the self-service BI platform queries the data structure information of a pre-set accounts payable and debt collection dataset in the background, extracts the field names and field types available for analysis from the dataset, and generates a list of optional fields. The list of optional fields includes two types of fields: dimension fields and measure fields. Dimension fields are suitable for classification or grouping (e.g., text or enumeration fields such as unit, department, aging range, payment type, etc.), while measure fields are suitable for numerical aggregation operations (e.g., numerical fields such as payable amount or outstanding balance, etc.). The self-service BI platform renders each optional field in the list as an interactive field control on the visualization configuration interface, ensuring a one-to-one correspondence between the field control and the optional field. The first user can intuitively see all the data fields available for building analytical views on the visualization configuration interface.

[0039] S13. In response to the first user's drag-and-drop operation on the field controls in the visualization configuration interface, at least one field corresponding to at least one field control in the dimension configuration area of ​​the visualization configuration interface is determined as at least one selected dimension field, and at least one field corresponding to at least one field control in the metric configuration area of ​​the visualization configuration interface is determined as at least one selected metric field.

[0040] In step S13, the visualization configuration interface also includes a dimension configuration area and a metric configuration area. The dimension configuration area is an interface area for receiving and placing dimension field controls, and the metric configuration area is an interface area for receiving and placing metric field controls. The first user can drag and drop the field controls presented in step S12 from the field list area to the dimension configuration area or the metric configuration area. When the self-service BI platform detects that a field control has been dragged and dropped to the dimension configuration area, it identifies the field corresponding to that field control as the selected dimension field; and when it detects that a field control has been dragged and dropped to the metric configuration area, it identifies the field corresponding to that field control as the selected metric field. Thus, the self-service BI platform not only obtains the fields selected by the first user, but also automatically determines the analysis role of each field based on the target configuration area to which the field is dragged and dropped, i.e., whether the field participates in data grouping as a dimension or in numerical calculation as a metric. For example, if the first user drags and drops the "Unit" field control to the dimension configuration area and the "Amount Payable" field control to the measure configuration area, the self-service BI platform will determine "Unit" as the dimension field and "Amount Payable" as the measure field. The subsequent generated query will use "Unit" as the grouping dimension and perform aggregate calculations on "Amount Payable".

[0041] Based on the above steps S11 to S13, the self-service BI platform obtains the chart display format desired by the first user through the selection operation of the chart type control, obtains the data fields selected by the first user through the presentation of the optional field list and the drag operation of the field control, and automatically determines the analysis role of each field. In this way, the analysis scenario construction process that requires writing code or configuring complex forms in traditional BI systems is transformed into an intuitive graphical interactive operation, which reduces the technical threshold for building analysis scenarios and improves the configuration efficiency of analysis views.

[0042] S2. Generate a first data query statement based on the at least one dimension field and the at least one metric field, and use the first data query statement to query the data to be analyzed from the preset payable and debt collection dataset.

[0043] In step S2, after obtaining at least one dimension field and at least one measure field selected by the first user in step S1, the self-service BI platform automatically constructs a first data query statement for data querying based on the dimension field and the measure field. Specifically, the first data query statement can be a Structured Query Language (SQL) statement or a similar data query instruction. The self-service BI platform uses the at least one dimension field as a grouping criterion and places it in the grouping clause (e.g., the GROUPBY clause) of the first data query statement; it uses the at least one measure field as an aggregation calculation object and places it in the query clause (e.g., the SELECT clause) of the first data query statement, and combines it with corresponding aggregation functions (e.g., the SUM function, the COUNT function, or the AVG function, etc.) to perform numerical aggregation on the measure field. Thus, the first data query statement can group the data according to the dimensions specified by the first user and perform statistical calculations on the measure values ​​within each group.

[0044] In step S2, the pre-built accounts payable collection dataset is a thematic dataset pre-built and stored in the database or data warehouse connected to the self-service BI platform. It contains multi-dimensional and multi-indicator data records related to accounts payable collection, such as accounts payable details, aging distribution, non-payment reason classification, and payment plan execution status for each unit. The self-service BI platform sends the generated first data query statement to the database containing the accounts payable collection dataset for execution and retrieves the data to be analyzed from the returned query results. The data to be analyzed is a structured data result set obtained by grouping and aggregating according to the dimensions and metrics selected by the first user, such as summary data of accounts payable amounts grouped by unit and statistical data of outstanding balances grouped by aging interval. The data to be analyzed will serve as the data foundation for generating subsequent analysis views, providing data input for rendering visualization charts based on the target chart type in step S3. Through this step, the self-service BI platform achieves automatic conversion from user configuration intent to data query statements, eliminating the need for IT personnel to manually write query code. This seamlessly connects the configuration process of the analysis scenario with the underlying data query logic, improving the automation level and response efficiency of analysis scenario construction.

[0045] S3. Based on the data to be analyzed and the target chart type, generate an analysis view to be published.

[0046] In step S3, specifically, after obtaining the data to be analyzed through step S2, the self-service BI platform binds the data to be analyzed with the target chart type determined in step S1 to generate the analysis view to be published. The analysis view to be published is a structured page description object containing visualization chart components, data configuration information, and layout information. It is presented in preview mode in the visualization configuration interface before publication, allowing the first user to confirm and adjust the effect.

[0047] In step S3, specifically, the self-service BI platform, based on the target chart type, invokes the corresponding chart rendering engine to map the dimension values ​​in the data to be analyzed to the chart's category axis (e.g., the X-axis category of a bar chart or the sector category of a pie chart), and maps the metric values ​​in the data to the chart's numerical axis (e.g., the Y-axis height of a bar chart or the sector size of a pie chart). It then generates corresponding graphic elements (e.g., bars, sectors, and lines) according to the visual specifications of the target chart type. The chart rendering engine can be a built-in chart library component of the self-service BI platform. This component pre-sets rendering templates for various chart types, each defining rendering configuration items such as coordinate system parameters, graphic element styles, legend layouts, and data label formats for that chart type. The self-service BI platform matches the corresponding rendering template according to the target chart type, fills the data to be analyzed into the data slots of the rendering template, and generates the visual chart in the analysis view.

[0048] In step S3, the analysis view to be published may include, in addition to the visualization chart, other visualization components associated with the target chart type, such as indicator cards, data tables, text titles, carousel banners, warning icons, or timeout status indicators. The self-service BI platform can dynamically adjust the position, size, and arrangement of each visualization component in the analysis view based on the layout adjustment operations performed by the first user in the visualization configuration interface to meet personalized display needs. The analysis view to be published is in an editable preview state. The first user can perform operations such as style fine-tuning, data filtering condition supplementation, or chart type switching before publishing, until the business analysis needs are met and the publishing operation is triggered. Through this step, the self-service BI platform transforms the structured data result set into intuitive visualization charts, providing directly compileable view objects for scenario publishing in the subsequent step S4.

[0049] S4. In response to the publishing operation triggered by the first user through the publishing interface of the self-service BI platform, compile the analysis view, generate an access link, and establish a binding relationship between the access link and the target menu item of the mobile application.

[0050] In step S4, specifically, after the self-service BI platform generates the analysis view to be published in step S3, it provides a publishing interface to the first user. The publishing interface is the entry point in the self-service BI platform used to convert the configured analysis view from an editable state to an accessible state. The first user can trigger the publishing operation by clicking the publishing button or other interactive methods after confirming that the preview effect of the analysis view meets business requirements.

[0051] In step S4, in response to the publishing operation, the self-service BI platform compiles the analysis view. This compilation process transforms the structured page description object of the analysis view into a standardized resource package that can be directly accessed and rendered by mobile applications. Specifically, the compilation process may include: serializing the chart configuration information, data query configuration information, layout information, and style information in the analysis view to generate corresponding configuration files; packaging the chart rendering logic, interaction logic, and style resources referenced in the configuration files to generate a front-end loadable resource file; and assigning a globally unique access identifier to the analysis view for subsequent access and identification. After the compilation process, the self-service BI platform generates the access link, which is a Uniform Resource Locator (URL) pointing to the compiled analysis view. This access link carries the access identifier for subsequent querying and loading of the corresponding analysis view based on the access identifier.

[0052] In step S4, after generating the access link, the self-service BI platform establishes a binding relationship between the access link and the target menu item of the mobile application. Specifically, the self-service BI platform maintains menu configuration information, which defines the menu items displayed in the mobile application and their corresponding navigation targets. Responding to the first user's binding operation in the menu configuration interface, the self-service BI platform configures the access link as the navigation address of the target menu item, thereby establishing the binding relationship. This binding relationship can be stored in the self-service BI platform's menu configuration database or configuration file. Therefore, when the second user subsequently accesses the target menu item through the mobile application, the mobile application can obtain the corresponding access link based on the binding relationship and trigger an access request for that analysis view. Through this step, the self-service BI platform achieves the transformation from the edit preview state of the analysis view to a distributable access state, providing an entry point for the second user's mobile access in subsequent step S5.

[0053] S5. In response to the second user's access request triggered by the access link through the target menu item in the mobile application, authenticate the second user to obtain the second user's role information.

[0054] In step S5, specifically after the self-service BI platform completes the publishing and menu binding of the analysis view in step S4, the analysis view becomes accessible. The second user (i.e., the viewer of the analysis view, such as an administrator or field debt collection personnel) can use the mobile application installed on their mobile terminal to browse and click the bound target menu item in the application interface, triggering an access request for the access link. The access request is sent by the mobile application to the server where the self-service BI platform is located via a wireless network, and the access request carries the access link and the second user's identity credentials.

[0055] In step S5, in response to receiving the access request, the self-service BI platform first verifies the identity of the second user. Identity verification refers to the process of validating the legitimacy of the second user's identity credentials. Specifically, the self-service BI platform may have a built-in or interfaced identity authentication and authorization module, which maintains a user identity information database. This database stores identity credentials such as user identifiers, login passwords, tokens, or biometrics for each legitimate user. The self-service BI platform compares the identity credentials carried in the access request with the records in the user identity information database to confirm whether the second user is a legitimate user. If the identity verification is successful, the platform retrieves the role information associated with the second user from the identity authentication and authorization module; if the identity verification fails, it returns an access denied message to the mobile application.

[0056] In step S5, the role information is used to characterize the second user's functional identity or management level in the accounts payable analysis business. For example, the role information may include leadership decision-making roles, business management roles, and financial management roles. The role information is pre-configured in the user management module of the self-service BI platform. Each user can be assigned one or more roles, and the relationship between roles and users can be stored in a role permission configuration table or user attribute information. The self-service BI platform uses the obtained role information of the second user as the basis for data permission filtering and differentiated presentation of analysis views in subsequent steps. Through this step, the self-service BI platform completes the identity verification and functional role identification of mobile terminal access users, providing the prerequisite for determining organizational hierarchy attributes and dynamically generating permission filtering query statements based on role information in step S6.

[0057] S6. Based on the role information, determine the organizational hierarchy attribute of the second user, and based on the configuration information of the analysis view associated with the access link, generate a second data query statement for data acquisition.

[0058] In step S6, specifically, after the self-service BI platform obtains the role information of the second user in step S5, it further determines the organizational hierarchy attribute of the second user based on the role information and reconstructs the second data query statement for obtaining data during the access phase. Specifically, the self-service BI platform first determines the organizational hierarchy attribute of the second user based on the role information. The organizational hierarchy attribute refers to the level or jurisdiction to which the second user belongs in the enterprise organizational structure, such as the group headquarters, provincial company, municipal company, district / county company, or specific department. The self-service BI platform can maintain a mapping relationship between roles and organizational levels, which can be stored in a role-organization mapping table or user attribute configuration information. For example, a leadership decision-making role can be mapped to the group headquarters level, allowing the user to view data from all subordinate units across the entire group; a business management role can be mapped to the provincial or municipal company level, allowing the user to view data from that level and its subordinate levels; a financial management role can be mapped to the department level, allowing the user to view data from their department. The self-service BI platform determines the corresponding organizational level attribute based on the second user's role information by querying the mapping relationship between the role and the organizational level, thus providing a basis for permission boundaries for subsequent data permission filtering.

[0059] In step S6, the self-service BI platform generates a second data query statement for data acquisition based on the configuration information of the analysis view associated with the access link. The access link carries a unique access identifier assigned in step S4. The self-service BI platform uses this access identifier to retrieve the configuration information of the analysis view from the configuration repository. This configuration information is the metadata information saved during the configuration phases of steps S1 to S3, describing the chart types, dimension fields, measure fields, data query logic, and layout styles included in the analysis view. The self-service BI platform parses the configuration information, extracts the recorded dimension and measure fields, and dynamically regenerates the second data query statement according to the same construction rules as those used to generate the first data query statement in step S2. Specifically, the self-service BI platform places the dimension fields from the configuration information as grouping criteria in the grouping clause and the measure fields as aggregation calculation objects in the query clause, combining them with corresponding aggregation functions. The second data query statement is structurally similar to the first data query statement, but it is dynamically generated during the access phase rather than being generated and stored permanently during the configuration phase. This allows for the dynamic injection of permission filtering conditions from the current user during the access phase, enabling user-identity-based data access control. Through this step, the self-service BI platform completes the mapping transformation from user roles to organizational levels, as well as the dynamic reconstruction from scenario configuration metadata to data query statements. This provides the execution foundation for injecting the organizational level attributes as filtering conditions into the query statement in step S7, thereby achieving fine-grained data permission control.

[0060] S7. The organizational hierarchy attribute is used as a dynamic filtering condition and injected into the second data query statement to obtain a third data query statement. The third data query statement is then used to query the target data within the second user's permission range from the payable and debt collection dataset.

[0061] In step S7, specifically, after the self-service BI platform determines the organizational hierarchy attribute of the second user and generates the second data query statement in step S6, it transforms the organizational hierarchy attribute into a permission filtering condition at the data query level and injects it into the second data query statement, thereby achieving differentiated data access control for users at different organizational levels. The organizational hierarchy attribute as a dynamic filtering condition means that during the access phase, conditional restrictions are dynamically added to the query statement based on the actual organizational hierarchy of the current accessing user, rather than being pre-fixed in the query statement during the configuration phase, thus achieving flexible and precise row-level data permission control. The third data query statement refers to the complete query statement with permission restriction function obtained after injecting the organizational hierarchy attribute as a filtering condition. The target data refers to the data result set that has been filtered by the organizational hierarchy attribute and is allowed to be viewed within the second user's permission scope. Preferably, injecting the organizational hierarchy attribute as a dynamic filtering condition into the second data query statement to obtain the third data query statement includes, but is not limited to, the following steps S71-S72.

[0062] S71. The value of the organizational hierarchy attribute is used as a condition parameter and appended to the condition clause of the second data query statement to obtain a new condition clause for restricting the query results to contain only data rows associated with the organizational hierarchy attribute.

[0063] In step S71, specifically, the self-service BI platform obtains the specific value of the organizational hierarchy attribute determined in step S6 (e.g., "Provincial Company A" or "Department B"), and appends this value as a condition parameter to the condition clause (i.e., the WHERE clause) of the second data query statement. Specifically, if a condition clause already exists in the second data query statement, the self-service BI platform appends the filtering condition of the organizational hierarchy attribute to the original condition clause using logical operators (e.g., AND or IN), forming an expanded new condition clause; if a condition clause does not exist in the second data query statement, the self-service BI platform creates a new condition clause containing the filtering condition of the organizational hierarchy attribute. The function of the new condition clause is to restrict the query results to only include data rows associated with the organizational hierarchy attribute. For example, it returns only data records where the responsible unit belongs to the provincial company where the second user is located and its subordinate units, thereby achieving secure filtering at the data row level.

[0064] S72. Based on the new conditional clause and the other clauses in the second data query statement other than the conditional clause, assemble a third data query statement.

[0065] In step S72, specifically, after obtaining the new conditional clause in step S71, the self-service BI platform assembles this new conditional clause with other clauses in the second data query statement besides the original conditional clauses to obtain the third data query statement. Specifically, the second data query statement typically consists of multiple clauses, such as SELECT clauses, FROM clauses, GROUP BY clauses, and ORDER BY clauses. The self-service BI platform replaces the original conditional clauses with the new conditional clause generated in step S71 and assembles it with the other clauses according to the syntax rules of query statements to form a complete and grammatically correct third data query statement. Logically, the third data query statement is equivalent to adding filtering conditions related to the organizational hierarchy attributes to the second data query statement, thereby ensuring that the data result set returned after executing the statement only contains data rows that the second user is authorized to view.

[0066] Based on steps S71-S72 above, the self-service BI platform dynamically combines permission filtering conditions with data query statements by appending organizational hierarchy attribute values ​​as conditional parameters to conditional clauses and then assembling them with new conditional clauses and other clauses. This allows the same analytical view to automatically return differentiated data result sets matching the permissions of users at different organizational levels, ensuring data security while achieving flexible row-level data access control. Then, the self-service BI platform uses the third data query statement to retrieve target data within the second user's permission range from the accounts payable and debt settlement dataset. The self-service BI platform sends the third data query statement to the database containing the accounts payable and debt settlement dataset for execution and retrieves the target data from the returned query results. The target data is the structured data result set that the second user has the right to view after filtering by organizational hierarchy attributes. The target data will serve as the data input for generating the target analytical view containing data content in subsequent step S8.

[0067] S8. Based on the target data, generate a target analysis view containing the data content.

[0068] In step S8, specifically, after the self-service BI platform obtains the target data filtered by organizational hierarchy attributes in step S7, it populates the target data into the chart component of the analysis view, generating the target analysis view containing actual business data content. This target analysis view corresponds to the analysis view to be published generated in step S3, the difference being that the analysis view to be published is a view template generated during the configuration phase and not yet populated with user-specific data; while the target analysis view is a complete analysis page generated during the access phase, populated with the target data, and directly viewable by the second user. Through this step, the self-service BI platform achieves the transformation from a data result set filtered by permissions to a visual analysis page, enabling the second user to intuitively view the accounts payable and debt settlement analysis data matching their permissions. Preferably, generating a target analysis view containing data content based on the target data includes, but is not limited to, the following steps S81-S82.

[0069] S81. Based on the role information of the second user, determine the analysis view hierarchy configuration information corresponding to the role information, wherein the analysis view hierarchy configuration information is used to define the number and type of indicator cards to be displayed, and different roles correspond to different analysis view hierarchy configuration information.

[0070] In step S81, specifically, the self-service BI platform queries the pre-defined correspondence between roles and analysis view level configuration information based on the role information of the second user obtained in step S5, and determines the analysis view level configuration information that matches the current second user. The analysis view level configuration information is pre-configured in the self-service BI platform, defining the number and type of indicator cards and chart components visible to users with different functional roles in the same analysis scenario. Since users with different roles have different focuses in accounts payable analysis, for example, leadership decision-making roles focus on overall core accounts payable progress indicators (such as the total amount of overdue SME payments, handling of complaint leads, and other macro indicators), business management roles, in addition to the former, also need to focus on the unit's execution-level indicators (such as details of small accounts payable), and financial management roles need to view more comprehensive accounts aging structure and capital pressure analysis indicators, and can view detailed charts in a separate interface through a lightweight interactive method. Therefore, different roles correspond to different analysis view level configuration information. The analysis view hierarchy configuration information can be stored in a role view configuration table. Each record includes fields such as role identifier, a list of visible indicator cards, and a list of visible chart components. The self-service BI platform can determine the analysis view hierarchy configuration information corresponding to the second user by querying this configuration table based on the second user's role information.

[0071] S82. Based on the target data and the analysis view hierarchy configuration information corresponding to the role information, generate a target analysis view containing data content, wherein the data content includes indicator cards and charts that match the role permissions of the second user.

[0072] In step S82, specifically, the self-service BI platform combines the target data obtained in step S7 with the analysis view hierarchy configuration information determined in step S81 to generate the target analysis view. Specifically, the self-service BI platform extracts corresponding indicator values ​​(e.g., monthly balance of SME payments over 60 days, change from the beginning of the year, and year-on-year change rate) from the target data according to the list of visible indicator cards defined in the analysis view hierarchy configuration information, and fills these indicator values ​​into the corresponding indicator card templates to generate indicator cards matching the permissions of the second user role. Simultaneously, the self-service BI platform maps the dimension values ​​and measure values ​​in the target data to the category axis and value axis of the corresponding charts according to the list of visible chart components defined in the analysis view hierarchy configuration information, rendering and generating corresponding chart components (e.g., bar charts distributed by responsible units, pie charts distributed by payment type, etc.). Since the target data obtained in step S7 has been filtered by organizational hierarchy attributes, and the analysis view hierarchy configuration information determined in step S81 matches the role of the second user, the data content in the generated target analysis view simultaneously meets the data permission requirements of the organizational hierarchy and the view structure requirements of the functional role.

[0073] Based on the above steps S81 to S82, the self-service BI platform determines the view level configuration through role information, and then combines the target data with the view level configuration to generate the target analysis view. This enables users with different roles to see different combinations of indicator cards and charts in the same analysis scenario, thus meeting the personalized analysis needs of different management levels while ensuring data security access control.

[0074] S9. Based on the screen characteristics of the second user's mobile terminal, the target analysis view is adapted and rendered, and the rendering result is pushed to the mobile terminal for output display.

[0075] In step S9, specifically after the self-service BI platform generates the target analysis view in step S8, it does not directly push the target analysis view to the mobile terminal. Instead, it first obtains the screen characteristics of the mobile terminal used by the second user, adapts and renders the target analysis view based on these screen characteristics, and then pushes the adapted rendering result to the mobile terminal for display. Since different mobile terminals may have different screen sizes, resolutions, or pixel densities, using a uniform chart style for rendering may result in problems such as chart elements being too small to read, blurry text, or touch operation areas being too small for interaction on some mobile terminals. Therefore, this step adapts and renders the target analysis view according to the actual screen characteristics of the second user's mobile terminal, ensuring that the target analysis view achieves good display effects and interactive experience on mobile terminals with different screen characteristics. The rendering result refers to page resource data, such as HTML page data or image data, generated after adaptation and rendering and directly loadable and displayed by the mobile terminal. Preferably, the target analysis view is adapted and rendered based on the screen characteristics of the second user's mobile terminal, including but not limited to the following steps S91 to S93.

[0076] S91. Obtain the screen characteristic information of the second user's mobile terminal.

[0077] In step S91, specifically, the self-service BI platform acquires the screen characteristic information of the mobile terminal currently used by the second user. The screen characteristic information refers to parameters describing the physical or logical display attributes of the mobile terminal screen, such as screen resolution (e.g., 1170×2532 pixels or 1080×2400 pixels), screen size (e.g., 6.1 inches or 6.7 inches), pixel density (e.g., pixels per inch (DPI)), or device type identifier. This screen characteristic information can be obtained by the mobile application when sending the access request by calling relevant interfaces of the mobile terminal operating system, and is carried along with the access request to the self-service BI platform. The self-service BI platform extracts the screen characteristic information from the received access request as the basis for subsequent style parameter matching and device adaptation rendering.

[0078] S92. Based on the target chart type and the screen characteristic information, retrieve the target preset style parameters from the preset mobile chart style library. The mobile chart style library stores preset style parameters for each chart type under different screen characteristics. The preset style parameters include, but are not limited to, coordinate axis text font size for adapting to touch operation and screen size-limited reading needs, and graphic element color scheme for adapting to screen size-limited visual hierarchy needs.

[0079] In step S92, specifically, the self-service BI platform uses the target chart type and the screen characteristic information as joint query conditions to retrieve target preset style parameters adapted to the current mobile terminal screen characteristics from a preset mobile chart style library. The mobile chart style library is a set of style parameters pre-built and stored in the self-service BI platform. For each chart type (e.g., bar chart, pie chart, line chart, or indicator card), the library pre-stores preset style parameters corresponding to different screen characteristics. For example, for the same bar chart type, a smaller axis text font size and tighter spacing between graphic elements can be used on large, high-resolution screens to fully utilize screen space and display more information; while on small, lower-resolution screens, a larger axis text font size and looser spacing between graphic elements are used to ensure clear text readability and convenient touch operation. The preset style parameters include at least: coordinate axis text font size (i.e., the font size of coordinate axis tick labels and legend text adjusted according to screen size and resolution) for adapting to touch operation and screen-limited reading needs; and graphic element color scheme (i.e., graphic element color scheme and transparency level scheme adjusted according to screen size, for example, establishing a clear visual hierarchy in the limited space of a small screen by adjusting transparency layer by layer, making the core data layer visually prominent and the auxiliary information layer visually recede). The target preset style parameters are the optimal combination of style parameters found in the mobile chart style library that matches both the target chart type and the screen characteristic information.

[0080] S93. Based on the target preset style parameters, render the target analysis view to adapt to the screen of the second user's mobile terminal.

[0081] In step S93, specifically, the self-service BI platform re-renders each chart component and indicator card component in the target analysis view generated in step S8 based on the target preset style parameters found in step S92. Specifically, the self-service BI platform applies the axis text font size from the target preset style parameters to the axis labels and legend text of each chart in the target analysis view, applies the graphic element color scheme to the graphic element color scheme of each chart, and adaptively adjusts the layout size and arrangement of each chart component and indicator card component according to a preset mobile scene baseline width (e.g., 375px). After this re-rendering, the chart text size in the target analysis view is suitable for reading on a mobile terminal screen, the spacing between graphic elements is suitable for finger touch operation, and the color hierarchy is suitable for conveying information hierarchy within the limited space of a small screen, thereby achieving adaptation to the second user's mobile terminal screen.

[0082] Based on steps S91-S93 above, the self-service BI platform obtains the actual screen characteristics of the mobile terminal, accurately matches style parameters adapted to the current device from a pre-set mobile chart style library, and re-renders the target analysis view based on these parameters. This achieves a shift from "rendering with a fixed style" to "dynamically adapting rendering based on device characteristics," solving the technical problems of poor display effects and inconvenient touch interaction of traditional BI charts on small mobile screens. This ensures that mobile terminals with different screen characteristics can obtain a good visualization and analysis experience. Then, the self-service BI platform pushes the rendering result to the second user's mobile terminal for output display. The self-service BI platform can send the rendering result to the mobile application in the form of a page data stream via a wireless network. After receiving the data, the mobile application loads and displays the rendering result on the mobile terminal's screen, allowing the second user to directly view a screen-adapted and optimized payable / debt clearing analysis view that matches their permissions on their mobile terminal.

[0083] Therefore, based on the mobile-based accounts payable and debt settlement analysis method described in steps S1 to S9 above, a new solution is provided that enables business personnel to independently and quickly build analysis views, obtain optimized presentation effects on mobile devices, and achieve fine-grained data access control. Specifically, in response to the configuration operation of the first user, the selected target chart type, dimensions, and metric fields are obtained; a query statement is dynamically generated to extract data from the accounts payable and debt settlement dataset and generate an analysis view to be published; in response to the publishing operation, the analysis view is compiled to generate an access link and bound to the mobile device menu; in response to the access request of the second user, authentication is performed to obtain role information, organizational hierarchy attributes are determined, and a query statement is regenerated based on the configuration information of the analysis view. The organizational hierarchy attributes are injected as dynamic filtering conditions into the query statement and executed to obtain target data within the authorized scope; a target analysis view is generated based on the target data, adapted and rendered according to the characteristics of the mobile terminal screen, and then pushed for display. This allows business personnel to build analysis views independently, automatically obtain differentiated data when users with different permissions access the same view, and adapt mobile charts to device screen characteristics, improving the flexibility, security, and user experience of mobile BI analysis, facilitating practical application and promotion.

[0084] Based on the technical solution of the first aspect mentioned above, this embodiment also provides a possible design for how to construct a unified data format for accounts payable and debt settlement analysis data foundation. That is, before responding to the analysis scenario configuration operation triggered by the first user through the visualization configuration interface of the self-service BI platform, the method also includes, but is not limited to, the following steps S101 to S102.

[0085] S101. Using a batch synchronization tool, accounts payable data, payment plan data, and contract information data from at least one source business system will be synchronized to the data platform.

[0086] In step S101, specifically, the self-service BI platform uses a batch synchronization tool to periodically or near-real-time synchronize raw business data related to accounts payable collection from at least one source business system to the data platform. The source business system refers to the information system within an enterprise responsible for managing accounts payable, payment plans, and contract information, such as an Enterprise Resource Planning (ERP) system, financial management system, or contract management system. The batch synchronization tool can be a data synchronization component (e.g., DataX), which supports extracting data from different types of databases or data sources and loading the extracted data into the target storage system. The data platform is an intermediate data layer used to aggregate and store raw data from multiple source business systems and provide unified data services for upper-level analytical applications. Through this step, the self-service BI platform achieves the aggregation of accounts payable collection-related data scattered across different source business systems into a unified data platform, providing a raw data foundation for subsequent data cleaning, transformation, and normalization processing.

[0087] S102. In the data platform, the synchronized accounts payable data, payment plan data, and contract information data are cleaned and transformed, and the enumerated values ​​of key business fields in the processed data are normalized to construct the accounts payable collection dataset, wherein the key business fields include at least an aging field and a non-payment reason field.

[0088] In step S102, specifically after the self-service BI platform synchronizes the data to the data platform in step S101, it processes the aggregated raw data to construct a standardized dataset for accounts payable and debt collection analysis. Specifically, the synchronized accounts payable data, payment plan data, and contract information data are first cleaned and transformed. Cleaning may include removing duplicate records, filtering incomplete or abnormal data rows, and / or correcting incorrectly formatted data items. Transformation may include uniform conversion of field types, standardized conversion of data formats, concatenation of data from multiple tables, and calculation of derived fields to meet analytical needs (e.g., calculating aging values ​​based on the due date and the current date).

[0089] In step S102, after cleaning and transforming the data, the enumeration values ​​of key business fields in the processed data are further normalized. These key business fields refer to the critical dimension fields used for data classification, filtering, and grouping in accounts payable analysis, such as the aging field and the reason for non-payment field. Since fields with the same business meaning may use different enumeration value representations in different source business systems (for example, the same reason for non-payment might be represented by code "01" in one system and by the text "incomplete" in another), using them directly for analysis without normalization would lead to inaccurate data filtering and unreliable grouping statistics. The normalization process involves uniformly mapping the enumeration values ​​of the same key business field from different source systems to a preset standard enumeration value, thereby eliminating data representation differences between different source systems. For example, all codes or text descriptions representing the reason for non-payment, "incomplete" or "not accepted," from all source systems can be uniformly mapped to the standard enumeration value "incomplete" or "not accepted." After the cleaning, transformation and normalization processes, the payable and debt collection dataset is constructed. This dataset is the thematic and standardized data set used for querying in steps S2, S6 and S7.

[0090] Based on the above possible design one, the self-service BI platform aggregates accounts payable collection data scattered across multiple source business systems into a data middle platform. After cleaning, transformation, and normalization of key field enumeration values, a standardized dataset for accounts payable collection analysis is constructed. This solves the technical problem of inaccurate analysis results caused by scattered data sources, inconsistent data formats, and inconsistent field enumeration values, and provides a high-quality unified data foundation for self-service configuration and permission filtering queries in subsequent analysis scenarios.

[0091] Based on the technical solution of the first aspect mentioned above, this embodiment also provides a possible design two for how to realize the step-by-step drill-down query from summary chart to detailed data. That is, after generating the analysis view to be published, the method also includes, but is not limited to, the following step S300.

[0092] S300. In response to the drill-down rule configured by the first user for the target chart in the analysis view, a penetrating query link is established between the target chart and the lower-level detail page, wherein the penetrating query link is configured to: when a trigger operation on a graphic element of the target chart in the target analysis view is detected, extract the dimension value associated with the triggered graphic element, and use the dimension value as a query parameter to dynamically generate a detail data query statement for querying the lower-level detail page.

[0093] In step S300, specifically after the self-service BI platform generates the analysis view to be published in step S3, it provides the first user with a drill-down rule configuration function. This allows the first user to configure drill-down rules for specified charts in the analysis view, establishing a penetrating query link from the summary chart to the lower-level detail page. The drill-down rule defines the jump mapping relationship between the summary chart and the lower-level detail page, specifically including: the source chart that triggers the drill-down (i.e., the target chart), the type of graphic element that triggers the drill-down (e.g., bars in a bar chart, sectors in a pie chart, or data points in a line chart), and the target page for the drill-down (i.e., the lower-level detail page, such as the debt collection ledger detail list page). The penetrating query link refers to the complete data processing link from the moment the graphic element of the target chart is clicked to the final loading and display of the lower-level detail page.

[0094] In step S300, specifically, the drill-down rule can be stored as part of the configuration information of the analysis view, and saved together with the configuration information of the analysis view associated with the access link generated in step S4. After the target analysis view is generated in step S8, when the second user views the target analysis view on their mobile terminal, they can trigger a graphic element in the target chart (e.g., clicking the bar representing "Unit A" in the bar chart) through touch operations such as finger touch or click. After the mobile application detects the trigger operation, it extracts the dimension value associated with the triggered graphic element (e.g., the unit name "Unit A" corresponding to the bar) according to the mapping relationship configured in the drill-down rule, and uses the dimension value as a query parameter to dynamically generate the detailed data query statement through the self-service BI platform. The detailed data query statement is a query statement used to query the detailed data corresponding to the dimension value from the payable and debt collection dataset. Its structure is similar to the aforementioned data query statements, but it adds a conditional clause with the dimension value as a filtering condition (e.g., WHERE Unit = 'Unit A'). After the self-service BI platform executes the detailed data query statement, it fills the obtained detailed data into the template of the lower-level detailed page, generates displayable detailed page data, and pushes it to the mobile terminal for display, thereby realizing a step-by-step query from summary analysis charts to detailed ledger data.

[0095] Based on the above-mentioned second possible design, by configuring drill-down rules for the target charts in the analysis view and establishing a penetrating query link, users can directly drill down to view the corresponding detailed data through touch interaction when viewing summary charts on mobile devices. This achieves one-stop penetrating analysis from macro-level indicator overview to micro-level detailed ledgers, allowing users to explore the data step by step without returning to the menu or switching pages, thus improving the interactive continuity and data exploration efficiency of mobile BI analysis.

[0096] Based on the technical solution of the first aspect mentioned above, this embodiment also provides a possible design three for how to automatically identify debt collection risks and securely push warnings to the responsible persons. That is, the method also includes, but is not limited to, the following steps S111 to S114.

[0097] S111. Construct an accounts payable risk rule base, wherein the accounts payable risk rule base stores at least one risk assessment condition and the information of the responsible person mapped to each risk assessment condition.

[0098] In step S111, specifically, the self-service BI platform provides an early warning rule configuration function, enabling administrators to flexibly define risk assessment conditions and their corresponding responsible person information according to the risk management needs of accounts payable collection business, and store these rules in a structured manner in the accounts payable collection risk rule library. The accounts payable collection risk rule library is a data set used to centrally store and manage early warning rules for collection risks. Each rule record contains at least one risk assessment condition and the responsible person information mapped to that condition. The risk assessment condition refers to a logical expression used to determine whether a certain accounts payable data record constitutes a risk, such as an amount condition (e.g., an amount less than or equal to 200,000 yuan), a time condition (e.g., overdue days exceeding 60 days), or a logical combination of the above conditions. The responsible person information refers to the identifier or contact information of the personnel who should receive the early warning notification when a data record is determined to meet the risk assessment condition. Preferably, constructing the accounts payable collection risk rule library includes, but is not limited to, the following steps S1111 to S1113.

[0099] S1111. Provide optional risk assessment fields and logical operators to the rule configuration interface of the self-service BI platform, wherein the risk assessment fields include at least an amount field and an aging field.

[0100] In step S1111, specifically, the self-service BI platform provides a rule configuration interface to the administrator user. This interface displays selectable risk assessment fields and logical operators. The risk assessment fields refer to business fields in the accounts payable and debt collection dataset that can be used to construct risk assessment conditions, such as amount fields (e.g., amount payable or outstanding balance) and aging fields (e.g., overdue days or aging range). The logical operators are logical connection symbols used to combine multiple single assessment conditions, such as "AND," "OR," "greater than," "less than," and "equal to." The administrator user can intuitively select the required risk assessment fields and logical operators in the rule configuration interface, providing input elements for subsequently constructing composite assessment conditions.

[0101] S1112. In response to the administrator user in the rule configuration interface using the risk judgment field and the logical operator to define a composite judgment condition, generate a risk judgment condition corresponding to the composite judgment condition, and configure the responsible person information mapped to the risk judgment condition.

[0102] In step S1112, specifically, the administrator user defines composite judgment conditions visually using the risk judgment fields and logical operators provided in step S1111 within the rule configuration interface. These composite judgment conditions refer to complex risk judgment logic composed of multiple single judgment conditions combined through logical operators. For example, "Age field greater than 60 days AND Amount field less than or equal to 200,000 yuan" is used to identify the risk of small accounts payable overdue for more than 60 days and not exceeding 200,000 yuan. The self-service BI platform generates corresponding risk judgment conditions based on the composite judgment conditions defined by the administrator user and receives the responsible person information configured by the administrator user for these risk judgment conditions, such as designating a department head or debt collection specialist as the recipient of the rule's warning. Furthermore, the administrator user can also preset different responsible person information for the same risk judgment condition by unit or department to achieve refined responsibility-based management.

[0103] S1113. Store the mapping relationship between the risk assessment conditions and the responsible person information in the payable and debt collection risk rule base.

[0104] In step S1113, specifically, the self-service BI platform stores the mapping relationship between the risk assessment conditions and the responsible person information generated in step S1112 as a rule record in the accounts payable risk rule base. The accounts payable risk rule base can be deployed in the database connected to the self-service BI platform and stored in the form of structured data tables. Each rule record includes at least a rule identifier, a logical expression (or structured description) of the risk assessment conditions, and the corresponding responsible person identifier. By persistently storing the mapping relationship in the rule base, subsequent scheduled scanning and early warning triggering steps can quickly query and match the corresponding rules, achieving standardized management and reuse of early warning logic.

[0105] Based on the above steps S1111 to S1113, by providing administrator users with a visual rule configuration interface, it is possible to flexibly define composite judgment conditions using risk judgment fields and logical operators, and establish and persistently store the mapping relationship between risk judgment conditions and responsible persons. This realizes the visual custom configuration and structured storage management of early warning rules, enabling business personnel to flexibly adjust the early warning logic according to actual risk control needs without coding, thereby improving the management efficiency and maintainability of risk early warning rules.

[0106] S112. Based on the payable debt collection risk rule base, the payable debt collection dataset is scanned by a scheduled task, and data records that meet any risk judgment condition in the payable debt collection risk rule base are identified as early warning events.

[0107] In step S112, specifically, after the self-service BI platform completes the construction of the accounts payable risk rule base, it periodically scans the accounts payable dataset through a scheduled task mechanism to automatically identify data records that meet the risk assessment conditions. The scheduled task can be a background task automatically triggered at a preset time interval (e.g., daily, hourly, or a custom time), managed and executed by the task scheduling module of the self-service BI platform. During each scan, the self-service BI platform traverses the data records in the accounts payable dataset, matching each data record with each risk assessment condition stored in the accounts payable risk rule base. The matching assessment refers to comparing the corresponding field value in the data record with the threshold or range in the risk assessment condition, and making a comprehensive judgment according to the logical operator combinations defined in the risk assessment condition. If a field value of a data record meets a certain risk assessment condition (i.e., meets any risk assessment condition), the data record is identified as a warning event. The warning event is a structured event object containing information such as the data record identifier that triggered the warning, the identifier of the met risk assessment condition, the trigger time, and a description of the warning content. Through this step, the self-service BI platform achieves automated risk scanning and early warning event identification of accounts payable and debt collection data.

[0108] S113. Based on the risk assessment conditions matched by the warning event, query the information of the responsible person corresponding to the conditions in the payable and debt collection risk rule base to determine the target responsible person.

[0109] In step S113, specifically, after the self-service BI platform identifies the warning event in step S112, it queries the accounts payable risk rule base according to the risk assessment conditions matched by the warning event to obtain the responsible person information pre-associated with the risk assessment conditions, thereby determining the target responsible person for the warning event. Specifically, the self-service BI platform uses the risk assessment condition identifier satisfied by the warning event identified in step S112 as the query key to search for the corresponding rule record in the accounts payable risk rule base and extracts the pre-configured responsible person information from the rule record. Since the corresponding responsible person information has been configured for each risk assessment condition in step S1112, and the mapping relationship has been persistently stored in the rule base in step S1113, this step can quickly determine the target responsible person through a simple database query operation. The target responsible person is the person who should receive the warning event notification, such as the person in charge of debt collection in the unit or department involved in the warning event. Through this step, the self-service BI platform achieves automatic association and matching from risk events to responsible persons without manual judgment or assignment.

[0110] S114. Generate a structured warning message containing the warning event, and call the intranet message push gateway to send the structured warning message to the enterprise internal communication system, so that the enterprise internal communication system forwards the structured warning message to the mobile terminal of the target responsible person.

[0111] In step S114, specifically after the self-service BI platform identifies the target responsible party in step S113, it encapsulates the warning event into a structured warning message and pushes it to the target responsible party's mobile terminal through an intranet secure channel. Specifically, the self-service BI platform first generates a structured warning message containing the warning event. This structured warning message may include a warning title (e.g., "Accounts Payable Clearance Warning Reminder"), a warning content description (e.g., "As of the current date, your organization has X small accounts payable exceeding 60 days in age and not exceeding 200,000 yuan, totaling Y yuan. Please handle this promptly"), trigger time, and statistics on the amount and number of transactions involved in the warning event. The message format can be text or key-value pairs to facilitate parsing and display by the recipient.

[0112] In step S114, the self-service BI platform can specifically invoke the intranet message push gateway to send the structured warning message to the enterprise's internal communication system. The intranet message push gateway is a message routing component deployed in the enterprise's intranet environment, responsible for pushing the warning message generated by the self-service BI platform to the designated enterprise internal communication system according to preset routing rules. The enterprise internal communication system can be an internal instant messaging platform already deployed by the enterprise (e.g., a private deployment version of WeChat for Business) or an internal office automation (OA) messaging module, etc. After receiving the structured warning message, the enterprise internal communication system forwards the structured warning message to the target responsible person's mobile terminal based on the target responsible person information carried in the message. Because the entire link from the self-service BI platform generating the warning message, through the intranet message push gateway, to the enterprise internal communication system, and then to the target responsible person's mobile terminal is within a controllable environment of the enterprise's intranet, the warning data does not pass through untrusted external public networks during transmission, effectively ensuring the data security of sensitive financial warning information during transmission and reception. Meanwhile, the structured early warning messages can be sent according to preset push frequency (e.g., once a day or real-time push) and message format to meet different early warning notification needs.

[0113] Based on the above-mentioned possible design three, a risk rule base for accounts payable and debt collection is constructed to realize the visual configuration and structured storage of early warning rules. The dataset is automatically scanned and risks are identified through scheduled tasks. The target responsible person is automatically determined through the mapping relationship between rule conditions and responsible persons. The early warning message is securely forwarded to the responsible person's mobile terminal through the intranet message push gateway and the enterprise's internal communication system. This realizes end-to-end closed-loop management from risk rule definition, automatic risk identification, responsible person matching to security early warning push. While improving the timeliness of the response to accounts payable and debt collection risks, it also ensures the security of intranet transmission of early warning data.

[0114] Based on the aforementioned possible design three technical solution, this embodiment also provides a possible design four for how to integrate external complaint clues and internal early warning events for unified supervision and management. That is, the method also includes, but is not limited to, the following steps S115 to S117.

[0115] S115. After receiving complaint lead data from an external system, the complaint lead data is parsed to extract key field information from the complaint lead, wherein the key field information includes at least the complaint date, responsible unit, and source of the lead.

[0116] In step S115, specifically, the self-service BI platform, in addition to the capabilities described in possible design three, also possesses the ability to receive and process complaint lead data from external systems. The external system refers to a business system independent of the self-service BI platform, used for accepting and recording user complaints or service requests, such as a customer service hotline system (e.g., the 95598 power service hotline) or an online complaint handling platform. The complaint lead data refers to complaint record data related to overdue payments generated by the external system, such as user complaints about a unit's failure to pay on time. The self-service BI platform can receive complaint lead data pushed or sent by the external system through preset data interfaces (e.g., application programming interfaces (APIs) or message queues).

[0117] In step S115, after receiving the complaint lead data, the self-service BI platform parses the complaint lead data and extracts key field information related to debt collection supervision and management. Since complaint lead data generated by different external systems may have different data formats and field naming conventions, the self-service BI platform can extract unified standardized key field information from the complaint lead data through pre-configured field mapping rules or data parsing templates. This key field information is core data used for subsequently generating debt collection task leads and determining responsibility, and includes at least: complaint date (i.e., the time the complaint was initiated), responsible unit (i.e., the unit involved in the complaint), and source of the lead (i.e., the channel through which the complaint was received, such as the 95598 hotline, online customer service, or email complaint). Through this step, the self-service BI platform achieves standardized access to external complaint lead data and extraction of key information, providing a data foundation for subsequently incorporating external leads into unified supervision and management.

[0118] S116. Based on the key field information obtained from the parsing, generate a debt collection task, wherein the debt collection task includes, but is not limited to, description information of the matters to be handled and information on the attribution of responsibility.

[0119] In step S116, specifically, after the self-service BI platform extracts the key field information in step S115, it generates the debt collection task based on this information. The debt collection task is a pending task object originating from an external complaint channel, corresponding to the warning event generated by the system's internal rule scanning in possible design three. The self-service BI platform constructs a data structure for the debt collection task based on the key field information. This data structure includes at least a description of the pending matter and information on responsibility attribution. The description of the pending matter is a text description generated based on the key fields of the complaint lead, used to explain the specific content of the debt collection task, such as "According to a complaint from the 95598 hotline, there is a clue that Unit A has outstanding accounts payable; please verify and handle it." The information on responsibility attribution is information determined based on the responsible unit field, used to specify the responsible party for handling the debt collection task, such as the debt collection manager's identifier or the responsible department identifier corresponding to the responsible unit. Through this step, the self-service BI platform transforms external complaint leads into debt collection task objects with a format consistent with internal warning events, providing standardized task data for subsequent dual-source task integration.

[0120] S117. Integrate the debt collection clue tasks with the early warning events scanned and identified from the debt collection dataset to construct a unified early warning supervision task list, so that the target responsible person can view and process the early warning events and debt collection clue tasks in the early warning supervision task list through a mobile terminal.

[0121] In step S117, specifically, the self-service BI platform integrates the debt collection clue tasks generated in step S116 with the early warning events scanned and identified from the debt collection dataset in step S112 of the possible design, to construct a unified early warning and supervision task list. This integration refers to the process of merging task objects from two different data sources (external complaint clues and internal data scans) according to a unified data structure and display format. Specifically, the self-service BI platform can standardize the debt collection clue tasks and the early warning events into task entries with the same field structure. For example, each task entry includes a task type identifier (used to distinguish between an "early warning event" and a "debt collection clue task"), task description, responsible unit, responsible person, generation time, and processing status. Then, the self-service BI platform merges the two types of task entries into the same task list and arranges them according to a preset sorting rule (e.g., sorted in descending order of generation time or by urgency) to construct the unified early warning and supervision task list.

[0122] In step S117, the early warning and supervision task list integrates early warning events generated by the system's internal intelligent identification and debt collection clues from external complaint channels. This allows the responsible party to view and process all pending early warning events and debt collection clues in a unified mobile supervision view without having to log into different systems or switch between different interfaces. The early warning and supervision task list can be displayed through the mobile application of the self-service BI platform. Its display format may include a task list view and a task details view: the task list view displays summary information of all pending task items in a list format (e.g., task type tags, responsible unit, generation time, processing status, etc.), and supports filtering and switching by task type (early warning event or debt collection clue task); the task details view displays complete information for a single task item and provides processing operation entry points (e.g., buttons for confirming processing, transferring to others, or marking as completed). The responsible party can view the early warning and supervision task list and process tasks through their mobile terminal in the mobile application, thereby achieving an end-to-end debt collection supervision management closed loop from risk identification to task assignment to processing tracking.

[0123] Based on the above-mentioned possible design four, by accessing complaint clue data from external systems and parsing and extracting key field information, external complaint clues are transformed into standardized debt collection clue tasks. These tasks are then integrated with early warning events generated by internal rule scanning into a unified early warning and supervision task list. This achieves dual-source task fusion of external complaint channels and internal data scanning, enabling the responsible personnel to view and process all pending tasks in a unified view on mobile terminals. This avoids the inefficiencies of management caused by switching between multiple systems and information dispersion, and improves the comprehensiveness and processing efficiency of debt collection supervision.

[0124] like Figure 2 As shown, the second aspect of this embodiment provides a virtual device for implementing the mobile terminal debt collection and settlement analysis method described in the first aspect or any possible design in the first aspect, including a configuration operation response unit, an analysis data query unit, an analysis view generation unit, a release operation response unit, an access request response unit, an attribute statement acquisition unit, a target data query unit, and an analysis view rendering unit. The configuration operation response unit is used to respond to the analysis scenario configuration operation triggered by the first user through the visualization configuration interface of the self-service BI platform, and to obtain the selected target chart type, at least one dimension field and at least one metric field. The analytical data query unit is communicatively connected to the configuration operation response unit, and is used to generate a first data query statement based on the at least one dimension field and the at least one metric field, and to use the first data query statement to query the data to be analyzed from the preset payable and debt collection dataset. The analysis view generation unit is communicatively connected to the configuration operation response unit and the analysis data query unit, respectively, and is used to generate an analysis view to be published based on the data to be analyzed and the target chart type; The release operation response unit is communicatively connected to the analysis view generation unit. It is used to respond to the release operation triggered by the first user through the release interface of the self-service BI platform, compile the analysis view, generate an access link, and establish a binding relationship between the access link and the target menu item of the mobile application. The access request response unit is communicatively connected to the publishing operation response unit, and is used to respond to the access request triggered by the second user through the target menu item in the mobile application for the access link, and to authenticate the second user to obtain the role information of the second user; The attribute statement acquisition unit is communicatively connected to the attribute statement acquisition unit and is used to determine the organizational level attribute of the second user based on the role information, and generate a second data query statement for data acquisition based on the configuration information of the analysis view associated with the access link. The target data query unit is communicatively connected to the attribute statement acquisition unit. It is used to inject the organizational hierarchy attribute as a dynamic filtering condition into the second data query statement to obtain a third data query statement, and to use the third data query statement to query the target data within the permission scope of the second user from the payable and debt collection dataset. The analysis view generation unit is also communicatively connected to the target data query unit and is further configured to generate a target analysis view containing data content based on the target data. The analysis view rendering unit is communicatively connected to the analysis view generation unit. It is used to adapt and render the target analysis view based on the screen characteristics of the second user's mobile terminal, and push the rendering result to the mobile terminal for output display. The working process, working details and technical effects of the aforementioned device provided in the second aspect of this embodiment can be found in the first aspect or any possible design in the first aspect of the mobile terminal debt collection analysis method, and will not be repeated here.

[0125] like Figure 3As shown, the third aspect of this embodiment provides a computer device for executing the mobile terminal debt collection and settlement analysis method as described in the first aspect or any possible design within the first aspect. The device includes a storage module, a processing module, and a transceiver module connected in sequence. The storage module stores a computer program, the transceiver module sends and receives messages, and the processing module reads the computer program and executes the mobile terminal debt collection and settlement analysis method as described in the first aspect or any possible design within the first aspect. Specifically, the storage module may include, but is not limited to, random-access memory (RAM), read-only memory (ROM), flash memory, first-in-first-out (FIFO) memory, and / or first-in-last-out (FILO) memory, etc.; the processing module may, but is not limited to, use a microprocessor of the STM32F105 series. Furthermore, the computer device may also include, but is not limited to, a power supply module, a display screen, and other necessary components.

[0126] The working process, working details and technical effects of the aforementioned computer device provided in the third aspect of this embodiment can be found in the mobile terminal debt collection analysis method described in the first aspect or any possible design in the first aspect, and will not be repeated here.

[0127] This fourth aspect of the embodiment provides a computer-readable storage product that stores instructions comprising the mobile terminal debt settlement analysis method as described in the first aspect or any possible design within the first aspect. Specifically, the computer-readable storage product stores instructions that, when executed on a computer, perform the mobile terminal debt settlement analysis method as described in the first aspect or any possible design within the first aspect. The computer-readable storage product refers to a data storage medium, which may include, but is not limited to, computer-readable storage media such as floppy disks, optical disks, hard disks, flash memory, USB flash drives, and / or Memory Sticks. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices.

[0128] The working process, working details and technical effects of the aforementioned computer-readable storage product provided in the fourth aspect of this embodiment can be found in the mobile terminal debt collection analysis method described in the first aspect or any possible design in the first aspect, and will not be repeated here.

[0129] This fifth aspect of the embodiment provides a computer program product, including a computer program or instructions, which, when executed by a computer, implement the mobile terminal debt collection and settlement analysis method as described in the first aspect or any possible design within the first aspect. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device.

[0130] Finally, it should be noted that the above description is merely a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A mobile-based accounts payable and debt settlement analysis method based on a self-service BI platform, characterized in that, include: In response to the analysis scenario configuration operation triggered by the first user through the visualization configuration interface of the self-service BI platform, obtain the selected target chart type, at least one dimension field and at least one measure field; Based on the at least one dimension field and the at least one metric field, a first data query statement is generated, and the first data query statement is applied to query the data to be analyzed from the preset payable and debt collection dataset. Based on the data to be analyzed and the target chart type, generate an analysis view to be published; In response to the publishing operation triggered by the first user through the publishing interface of the self-service BI platform, the analysis view is compiled, an access link is generated, and a binding relationship is established between the access link and the target menu item of the mobile application. In response to an access request triggered by a second user through the target menu item in the mobile application in response to the access link, the second user is authenticated to obtain the second user's role information; Based on the role information, determine the organizational hierarchy attribute of the second user, and generate a second data query statement for data acquisition based on the configuration information of the analysis view associated with the access link; The organizational hierarchy attribute is used as a dynamic filtering condition and injected into the second data query statement to obtain a third data query statement. The third data query statement is then used to query the target data within the second user's permission range from the payable and debt collection dataset. Based on the target data, a target analysis view containing the data content is generated; Based on the screen characteristics of the second user's mobile terminal, the target analysis view is adapted and rendered, and the rendering result is pushed to the mobile terminal for output display.

2. The mobile terminal debt collection analysis method according to claim 1, characterized in that, In response to an analysis scenario configuration operation triggered by a first user through the visualization configuration interface of a self-service BI platform, the method acquires the selected target chart type, at least one dimension field, and at least one measure field, including: in response to the first user's selection operation of the chart type control in the visualization configuration interface of the self-service BI platform, determining the selected target chart type; providing the visualization configuration interface with a list of optional fields in the accounts payable and debt collection dataset, so as to present on the visualization configuration interface each field control corresponding one-to-one with each optional field in the list of optional fields, wherein the list of optional fields includes dimension fields and measure fields; in response to the first user's drag-and-drop operation of the field controls in the visualization configuration interface, determining at least one field corresponding one-to-one with at least one field control dragged and dropped into the dimension configuration area of ​​the visualization configuration interface as the selected at least one dimension field, and determining at least one field corresponding one-to-one with at least one field control dragged and dropped into the measure configuration area of ​​the visualization configuration interface as the selected at least one measure field; And / or, the organizational hierarchy attribute is used as a dynamic filtering condition and injected into the second data query statement to obtain a third data query statement, including: appending the value of the organizational hierarchy attribute as a condition parameter to the condition clause of the second data query statement to obtain a new condition clause for restricting the query results to contain only data rows associated with the organizational hierarchy attribute; and assembling the third data query statement based on the new condition clause and other clauses in the second data query statement other than the condition clause. And / or, based on the target data, generate a target analysis view containing data content, including: determining analysis view hierarchy configuration information corresponding to the role information of the second user, wherein the analysis view hierarchy configuration information is used to define the number and type of indicator cards to be displayed, and different roles correspond to different analysis view hierarchy configuration information; generating a target analysis view containing data content based on the target data and the analysis view hierarchy configuration information corresponding to the role information, wherein the data content includes indicator cards and charts that match the role permissions of the second user; And / or, based on the screen characteristics of the second user's mobile terminal, adapt and render the target analysis view, including: Obtain the screen characteristic information of the second user's mobile terminal; Based on the target chart type and the screen characteristic information, the target preset style parameters are retrieved from the preset mobile chart style library. The mobile chart style library stores preset style parameters for each chart type under different screen characteristics. The preset style parameters include the coordinate axis text font size for adapting to touch operation and screen size-limited reading needs, and the graphic element color scheme for adapting to screen size-limited visual hierarchy needs. Based on the target preset style parameters, the target analysis view is rendered to adapt to the screen of the second user's mobile terminal.

3. The mobile terminal debt collection analysis method according to claim 1, characterized in that, Prior to the analysis scenario configuration operation triggered by the first user through the visual configuration interface of the self-service BI platform, the method further includes: Using batch synchronization tools, accounts payable data, payment plan data, and contract information data from at least one source business system can be synchronized to the data platform. In the data platform, the synchronized accounts payable data, payment plan data, and contract information data are cleaned and transformed, and the enumerated values ​​of key business fields in the processed data are normalized to construct the accounts payable collection dataset. The key business fields include at least an aging field and a reason for non-payment field.

4. The mobile terminal debt collection analysis method according to claim 1, characterized in that, After generating the analysis view to be published, the method further includes: In response to the drill-down rule configured by the first user for the target chart in the analysis view, a penetrating query link is established between the target chart and the lower-level detail page. The penetrating query link is configured to: when a trigger operation on the graphic element of the target chart in the target analysis view is detected, extract the dimension value associated with the triggered graphic element, and use the dimension value as a query parameter to dynamically generate a detail data query statement for querying the lower-level detail page.

5. The mobile terminal debt collection analysis method according to claim 1, characterized in that, The method further includes: Construct an accounts payable risk rule base, wherein the accounts payable risk rule base stores at least one risk assessment condition and the information of the responsible person mapped to each risk assessment condition; Based on the aforementioned payable and debt collection risk rule base, the payable and debt collection dataset is scanned by a scheduled task, and data records that meet any risk judgment condition in the payable and debt collection risk rule base are identified as early warning events. Based on the risk assessment criteria matched by the warning event, the information of the responsible party corresponding to the criteria in the payable debt risk rule base is queried to determine the target responsible party; A structured warning message containing the warning event is generated, and the internal network message push gateway is invoked to send the structured warning message to the enterprise internal communication system, so that the enterprise internal communication system forwards the structured warning message to the mobile terminal of the person in charge of the target.

6. The mobile terminal debt collection analysis method according to claim 5, characterized in that, Constructing an accounts payable risk rule base includes: providing optional risk assessment fields and logical operators to the rule configuration interface of a self-service BI platform, wherein the risk assessment fields include at least an amount field and an aging field; in response to an administrator user using the composite assessment conditions defined by the risk assessment fields and the logical operators in the rule configuration interface, generating risk assessment conditions corresponding to the composite assessment conditions, and configuring the mapped responsible person information for the risk assessment conditions; and storing the mapping relationship between the risk assessment conditions and the responsible person information in the accounts payable risk rule base. And / or, the method further includes: After receiving complaint lead data from an external system, the complaint lead data is parsed to extract key field information from the complaint lead. The key field information includes at least the complaint date, responsible unit, and source of the lead. Based on the key field information obtained from the parsing, a debt collection task is generated, wherein the debt collection task includes a description of the matter to be handled and information on the attribution of responsibility; The debt collection clue tasks are integrated with the early warning events scanned and identified from the debt collection dataset to construct a unified early warning supervision task list, so that the target responsible person can view and process the early warning events and debt collection clue tasks in the early warning supervision task list through a mobile terminal.

7. A mobile-based accounts payable and debt settlement analysis device based on a self-service BI platform, characterized in that, It includes a configuration operation response unit, an analysis data query unit, an analysis view generation unit, a publish operation response unit, an access request response unit, an attribute statement retrieval unit, a target data query unit, and an analysis view rendering unit; The configuration operation response unit is used to respond to the analysis scenario configuration operation triggered by the first user through the visualization configuration interface of the self-service BI platform, and to obtain the selected target chart type, at least one dimension field and at least one metric field. The analytical data query unit is communicatively connected to the configuration operation response unit, and is used to generate a first data query statement based on the at least one dimension field and the at least one metric field, and to use the first data query statement to query the data to be analyzed from the preset payable and debt collection dataset. The analysis view generation unit is communicatively connected to the configuration operation response unit and the analysis data query unit, respectively, and is used to generate an analysis view to be published based on the data to be analyzed and the target chart type; The release operation response unit is communicatively connected to the analysis view generation unit. It is used to respond to the release operation triggered by the first user through the release interface of the self-service BI platform, compile the analysis view, generate an access link, and establish a binding relationship between the access link and the target menu item of the mobile application. The access request response unit is communicatively connected to the publishing operation response unit, and is used to respond to the access request triggered by the second user through the target menu item in the mobile application for the access link, and to authenticate the second user to obtain the role information of the second user. The attribute statement acquisition unit is communicatively connected to the attribute statement acquisition unit and is used to determine the organizational level attribute of the second user based on the role information, and generate a second data query statement for data acquisition based on the configuration information of the analysis view associated with the access link. The target data query unit is communicatively connected to the attribute statement acquisition unit. It is used to inject the organizational hierarchy attribute as a dynamic filtering condition into the second data query statement to obtain a third data query statement, and to use the third data query statement to query the target data within the permission scope of the second user from the payable and debt collection dataset. The analysis view generation unit is also communicatively connected to the target data query unit and is further configured to generate a target analysis view containing data content based on the target data. The analysis view rendering unit is communicatively connected to the analysis view generation unit. It is used to adapt and render the target analysis view based on the screen characteristics of the second user's mobile terminal, and push the rendering result to the mobile terminal for output display.

8. A computer device, characterized in that, It includes a storage module, a processing module, and a transceiver module that are sequentially connected in communication. The storage module is used to store computer programs, the transceiver module is used to send and receive messages, and the processing module is used to read the computer programs and execute the mobile terminal debt collection analysis method as described in any one of claims 1 to 6.

9. A computer-readable storage product, characterized in that, The computer-readable storage product stores instructions that, when executed on a computer, perform the mobile terminal debt collection analysis method as described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or the instructions are executed by the computer, they implement the mobile terminal debt collection and settlement analysis method as described in any one of claims 1 to 6.

Images