Construction Plan for Financial Transfer Payment Monitoring System catalogue1. Financial transfer

Construction Plan for Financial Transfer Payment Monitoring System
 
catalogue
1. Financial transfer payment monitoring 3
1.1 Business Description 3
1.2 User characteristics 3
1.3 System related constraints 4
1.4 Functional Requirements and Preliminary Design 4
1.4.1 Basic Data Management 4
1.4.2 Project Management 5
1.4.3 Indicator Management 8
1.4.4 Audit Verification 10
1.4.5 Comprehensive Processing 11
1.4.6 Indicator Reconciliation 11
1.4.7 Data Exchange 13
1.4.8 Analysis and Monitoring 14
1.4.9 Query Report 15
 
1. Financial transfer payment monitoring
1.1 Business Description
Financial transfer payment monitoring is based on the "Golden Finance Engineering" application support platform, with transfer payment project management as the source, budget distribution as the main line, budget execution tracking feedback as the means, and the standardization of the statistical caliber of national financial transfer payment budget information as the basis. It connects the management information of upper and lower level financial transfer payment budgets, comprehensively reflects the arrangement, implementation, and availability of central and local transfer payment funds, and provides strong support for further strengthening the management of financial transfer payment funds. This module covers financial transactions such as standardizing transfer payment projects, informing lower level finance in advance of expected transfer payments, issuing transfer payment budgets, real-time reconciliation of transfer payment funds, and providing feedback on the execution of transfer payment budgets, as shown in the following figure:
1.2 User characteristics
This module mainly involves the following users of financial departments at all levels:
1. System administrator: responsible for the installation, deployment, and maintenance of the application support platform, as well as the normal operation of the module on the platform, completing the allocation of user permissions for this module, ensuring the daily operation of this module, and being able to handle general system errors.
2. Database administrator: responsible for the normal operation and backup of the database.
3. Budget Department (Office, Bureau, etc.): Responsible for receiving superior project and indicator data, as well as maintaining local projects and indicators, and completing the submission of data to the superior financial department.
4. Business Department: Based on the management characteristics of each province, the Business Department (Office) is responsible for the allocation and management of centralized indicators, and registration is carried out in the special transfer payment module.
5. Director (Bureau): Conduct data analysis and queries through various decision analysis reports provided by the module.
6. Other relevant department (office) personnel: With the approval of relevant leaders, they can query and analyze relevant data.
1.3 System related constraints
1. The development of this module should fully utilize the "application support platform". Various basic data, project data, and indicator data should be exchanged between superiors and subordinates through the platform's data exchange components; For provinces and cities that have already used the platform, indicator data and payment data should be extracted from the platform.
2. This module should be able to meet the current management level and adapt to future changes. At present, there are mainly the following modes of hierarchical management: central ->provincial ->city ->county; Central ->Province ->City/County; Or a hybrid mode with both, this module must fully meet the above business operation modes and be able to meet the needs of external business changes.
3. This module aims to develop standard interface specifications to facilitate data exchange with budget execution in various provinces.
4. This module aims to provide a user-friendly data editing interface. The module should provide a comprehensive human-computer interaction interface for data entry for users who have not executed the module.
5. This module aims to provide comprehensive permission management functions. This module needs to meet the management needs of functional permissions and data permissions for users at different levels.
6. The architecture of this module should meet the needs of building a national transfer payment data warehouse. The design of this module should fully consider the need to build a national transfer payment data warehouse to meet the needs of big data computing.
7. This module aims to provide mainstream data warehouse tools (such as Cognos, BO) for report design and data mining
8. Basic data should comply with relevant standards such as financial business basic data specifications.
9. The construction of this module should comply with the current budget management standards (such as concepts, subjects, caliber, etc.).
1.4 Functional Requirements and Preliminary Design
The monitoring module includes ten subsystems, including basic data management, project management, indicator management, execution management, indicator reconciliation, data exchange, audit verification, comprehensive processing, analysis monitoring, query reports, and system settings, to achieve tracking management and monitoring of transfer payment funds.
1.4.1 Basic Data Management
1.4.1.1 Function Description
The basic data management subsystem mainly registers and manages the basic information data related to transfer payment fund management. Through an automatic data synchronization mechanism, it ensures the standardization and uniformity of the basic data related to national transfer payment fund management. The system should reserve sufficient space to add relevant elements according to user requirements.
1.4.1.2 Input elements
（1） Administrative divisions.
This includes administrative division codes, administrative division levels, administrative division names, administrative division abbreviations, and types of administrative divisions.
When designing modules, full consideration should be given to the multidimensional division of administrative divisions and adjustments and changes, such as whether it is a planned city, an ethnic region, a remote and difficult area, a major grain producing area, a key county for poverty alleviation and development at the national or provincial level, and a border island county.
（2） Government revenue and expenditure classification account
Including account code, account name, account category, account coding rules, budget year, etc. When designing the module, full consideration should be given to the adjustment and changes of government revenue and expenditure classification accounts in budget execution, as well as the corresponding relationship between annual budget account changes.
（3） Project based statistical caliber maintenance
This includes project based statistical caliber codes, statistical caliber names, principles of statistical caliber, and documentation explaining statistical caliber. Principle of project statistical caliber, including but not limited to adding or excluding designated projects; Automatically screen and exclude based on elements such as projects, subjects, indicators, administrative divisions, etc; Convert the selected items proportionally, etc. When designing modules, full consideration should be given to hierarchical management based on project statistical standards and mutual referencing between project statistical standards.
1.4.1.3 Elements of output
（1） Operation interface
The operation interface of the basic data management subsystem should be concise and convenient, and various information in the operation interface should be dynamically generated based on the user's permissions. The detailed information in the operation interface should be able to be exported to EXCEL software.
The operation interface for maintaining project statistical caliber should provide convenient and fast means of filtering and defining conditions, and support switching of query results from different caliber perspectives. The result query interface can select the units for data display and input according to user needs, such as yuan, hundred yuan, thousand yuan, ten thousand yuan, one hundred million yuan, etc.
（2） Report output
The module should support generating information settings for the management subsystem based on user permissions through the report module, in order for users to query and verify. For the maintenance results of project statistical caliber, it should be possible to customize and generate relevant management reports according to user needs.
1.4.1.4 Others
The basic data management subsystem should allow the superior financial department to synchronize the latest setting information with the data of the basic data management subsystem of the subordinate finance that needs to be synchronized, and automatically backup relevant information for the subordinate finance before synchronization. The system should remind the lower level finance department of the changes before and after this synchronization.
1.4.2 Project Management
1.4.2.1 Function Description
The project management subsystem mainly registers and manages the transfer payment project situation that needs to be monitored by the superior finance, and distributes the latest project information to the front-end machine of the subordinate finance. The system should reserve sufficient space to add relevant management elements according to user requirements.
1.4.2.2 Input elements
（1） Project elements
The project elements should support tree nesting, mainly including the following elements:
1. Project code. The project code should support a tree structure of no less than five levels, with each level of project supporting no less than 9999 projects. The project code is not equivalent to the project ID in the system database.
2. Project name. The project name should allow users to enter no less than 200 characters. Necessary and reasonable handling should be carried out for project leading and trailing spaces as well as special control characters.
3. Project classification. Including non confidential, confidential, confidential, top secret, etc. For projects above the secret level, the system should automatically perform decryption processing. Provide a manual decryption interface, such as modifying the project name or summary, otherwise the system will automatically hide the project name and associated indicator summary with an * symbol.
4. The supervisory department. The supervisory department should support a tree like structure at or above the third level.
5. Project start date.
6. Project termination date.
7. Year of project issuance.
8. Project level. The system supports central, provincial, municipal, and county input and management of transfer payment projects set at this level. In the system, the superior finance department has the right to freely access all subordinate finance information related to the transfer payment projects they have set up; According to the regulations in the document, the higher-level finance can access the relevant information of transfer payment projects set by the lower level finance; Relevant financial information at the same level is isolated from each other and can only be exchanged through mutual consultation and agreement.
9. Project source. This includes projects at the beginning of the year, additional (central reserve funds, previous year reservations, etc.) projects, and projects carried forward from the previous year. The system should support users to define the source of projects as needed. The project source should support a tree structure of at least three levels. The source of indicators is subject to hierarchical management. For example, the source of indicators for central financial projects needs to be clearly distinguished at the central level. After reaching the provincial level, all funds subsidized by the central government at the provincial level are considered as "central transfer payment funds", and the source of indicators for central financial projects is no longer traced back to the provincial and lower level finance.
10. Project transfer payment attributes. Including general transfer payments, special transfer payments, tax refunds, etc. The transfer payment attribute should support a tree structure of at least three levels.
11. Project usage subjects. The revenue and expenditure accounts corresponding to the projects set by the higher-level finance can be further refined by the lower level finance; For special transfer payment projects, if the lower level finance department needs to make account adjustments, the system should not prohibit them but provide a prompt. In the data package reported by the lower level finance department, special transfer payment projects that adjust income and expenditure accounts should be identified. The system should support users to select the expenditure accounts that can be used for this project, and the system defaults to all accounts.
12. Project funding consolidation (matching funds). For example, for the implementation of proportionate matching of funds, various transfer payment matching rules of the existing central, provincial, municipal, and county (district) should be supported. The system can automatically calculate the minimum transfer payment matching for each level based on the project funds issued by the superior. For funds implemented in project management, support should be provided for multi-level investment consolidation of the project.
13. Estimated number of project releases. The superior finance department can inform the expected distribution of projects, while the subordinate finance department can timely understand and calculate the matching funds that need to be arranged at the local level based on the expected distribution of projects and the consolidation of project funds issued by the superior.
14. Project Summary. The system should support users to input summaries of at least 300 characters. The project summary can be selected to be distributed to the lower level finance department along with other project information, with the default being distributed along with other project information.
15. Project attachments. The system should support storing electronic file attachments in various graphic formats, such as RTF, Word, Excel, XML, etc., and provide a comprehensive attachment query, retrieval, printing, and management interface. Project attachments can be selected to be distributed to lower level finance departments along with other project information, with the default being distributed along with other project information.
16. Project distribution area. The system should support users to select all or specified next level finances when issuing projects.
（2） Project documents
The project is managed using project documents as a carrier. Project documents should support carrying multiple projects and support pre-defined approval processes. The elements of project documents mainly include
1. Project document number. The system should be able to automatically generate documents according to the user's set document rules.
2. Document production time and creator.
3. Document review time, reviewer, and review comments. The system should fully record the reviewers, review time, review comments, etc. at each stage of the project documents.
4. Document status. The status of project documents should include newly added, submitted for review, returned, approved, etc.
5. Document remarks. The system should support document notes of at least 200 characters.
6. Document attachments. The system should support storing electronic file attachments in various graphic formats, such as RTF, Word, Excel, XML, etc., and provide a comprehensive attachment query, retrieval, printing, and management interface.
（3） Project distribution
The system should support manual or automatic issuance based on project or document conditions. When manually distributing, the superior user can select and distribute newly added or adjusted items in a tree like manner, and the project distribution is constrained by the regional elements of the project distribution.
1.4.2.3 Elements of output
（1） Operation interface
1. The operation interface of the project management subsystem should be concise and convenient, and various information in the operation interface should be dynamically generated based on the user's permissions. The detailed information in the operation interface should be able to be exported to EXCEL software.
2. Project input should support user input, external document import, and database connection import.
3. Project input should support pre-defined workflows.
4. The operation interface should provide the following basic functions:
(1) New Project: Add one or more projects.
(2) Modify project: Delete newly added or returned projects created by myself.
(5) Project Submission for Review: The creator submits newly added projects (or modified projects that fail the review) to the reviewer for review, and the document status will change from newly added (or returned) to submitted for review.
(6) Adjustment steps: Add or insert new audit steps without changing the original ones.
(7) Withdrawal for review: The creator retrieves the submitted documents, and the document status will change from submitted for review to new.
(8) Review Information: View the review process and review information of indicator documents.
(9) Document attachment: View or modify the attachment of a document.
(10) Project attachments: View or modify project attachments.
(11) Special modifications: The system should support the creator to make special modifications to the elements of documents or projects that have been approved or issued through a pre-set special modification approval process. The system should support adjustments to certain project fields without being made as special modifications to the project. Such as adding project attachments, etc.
（2） Print out
The system should allow users to print one or more documents in a pre-set format.
1.4.2.4 Business Process
The business process of the project management subsystem is shown in the following figure (the formation and maintenance of projects can be divided into five situations: first, when issuing budget control numbers, an Excel project import table is manually generated and imported into the system; second, before the year, an initial budget project is formed from the central to local transfer payment preparation system and imported into the system; third, after the provincial, municipal, and county people's congresses approve the budget, the transfer payment project table is exported from the budget indicator management software and imported into the system; fourth, during execution, new projects are directly exported from the budget indicator management and imported into the system; fifth, at the end of the year, a review table for local transfer payment projects is issued).
1.4.3 Indicator Management
1.4.3.1 Function Description
The indicator management subsystem mainly involves the allocation of transfer payment budgets from the superior finance to the subordinate finance, as well as the feedback from the subordinate finance to the superior finance on the budget arrangement and execution of transfer payment projects. By manually entering or importing indicator documents, specific businesses such as adding or subtracting budget indicators from superior finance to subordinate accounts can be achieved. The system should reserve sufficient space to increase according to user requirements