CN115409589B - Financial data standardization system and method thereof - Google Patents
Financial data standardization system and method thereof Download PDFInfo
- Publication number
- CN115409589B CN115409589B CN202211079015.2A CN202211079015A CN115409589B CN 115409589 B CN115409589 B CN 115409589B CN 202211079015 A CN202211079015 A CN 202211079015A CN 115409589 B CN115409589 B CN 115409589B
- Authority
- CN
- China
- Prior art keywords
- data
- bill
- report
- information
- easy
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 53
- 238000007726 management method Methods 0.000 claims abstract description 98
- 238000004458 analytical method Methods 0.000 claims abstract description 9
- 238000013523 data management Methods 0.000 claims abstract description 5
- 238000013499 data model Methods 0.000 claims description 43
- 230000008520 organization Effects 0.000 claims description 39
- 238000012545 processing Methods 0.000 claims description 37
- 230000006870 function Effects 0.000 claims description 31
- 230000008569 process Effects 0.000 claims description 30
- 238000013475 authorization Methods 0.000 claims description 21
- 238000013506 data mapping Methods 0.000 claims description 19
- 238000012795 verification Methods 0.000 claims description 16
- 238000011425 standardization method Methods 0.000 claims description 15
- 238000003860 storage Methods 0.000 claims description 11
- 230000002159 abnormal effect Effects 0.000 claims description 10
- 238000011161 development Methods 0.000 claims description 7
- 238000012544 monitoring process Methods 0.000 claims description 6
- 230000005540 biological transmission Effects 0.000 claims description 3
- 238000013500 data storage Methods 0.000 claims description 3
- 230000010354 integration Effects 0.000 claims description 3
- 238000013507 mapping Methods 0.000 claims description 3
- 238000000275 quality assurance Methods 0.000 claims description 3
- 238000012216 screening Methods 0.000 claims description 3
- 230000001502 supplementing effect Effects 0.000 claims description 3
- 238000004891 communication Methods 0.000 claims description 2
- 238000013481 data capture Methods 0.000 claims description 2
- 238000012423 maintenance Methods 0.000 claims description 2
- 238000013515 script Methods 0.000 claims description 2
- 230000001360 synchronised effect Effects 0.000 claims 2
- 238000007405 data analysis Methods 0.000 abstract description 3
- 238000010276 construction Methods 0.000 description 15
- 238000010586 diagram Methods 0.000 description 10
- 238000012546 transfer Methods 0.000 description 9
- 238000010606 normalization Methods 0.000 description 6
- 238000001914 filtration Methods 0.000 description 5
- 238000006243 chemical reaction Methods 0.000 description 4
- 230000005856 abnormality Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 235000006719 Cassia obtusifolia Nutrition 0.000 description 2
- 235000014552 Cassia tora Nutrition 0.000 description 2
- 244000201986 Cassia tora Species 0.000 description 2
- 238000004364 calculation method Methods 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000004913 activation Effects 0.000 description 1
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000005520 cutting process Methods 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 230000009849 deactivation Effects 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 239000000945 filler Substances 0.000 description 1
- 238000005111 flow chemistry technique Methods 0.000 description 1
- 239000000446 fuel Substances 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 238000007493 shaping process Methods 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
- 238000010200 validation analysis Methods 0.000 description 1
- 239000011800 void material Substances 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/12—Accounting
- G06Q40/125—Finance or payroll
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
- G06F16/84—Mapping; Conversion
- G06F16/86—Mapping to a database
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/166—Editing, e.g. inserting or deleting
- G06F40/177—Editing, e.g. inserting or deleting of tables; using ruled lines
- G06F40/18—Editing, e.g. inserting or deleting of tables; using ruled lines of spreadsheets
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Business, Economics & Management (AREA)
- Finance (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Accounting & Taxation (AREA)
- Databases & Information Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computational Linguistics (AREA)
- Economics (AREA)
- General Health & Medical Sciences (AREA)
- Artificial Intelligence (AREA)
- Health & Medical Sciences (AREA)
- Data Mining & Analysis (AREA)
- Development Economics (AREA)
- Audiology, Speech & Language Pathology (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- General Business, Economics & Management (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The invention provides a financial data standardization system and a method thereof, wherein a service type unit in the system is used for defining source information data types, the service type unit comprises a service bill, main data, a certificate or a service interface, and the financial data standardization system carries out corresponding data circulation and data management on source information data according to the service types; the data structure definition unit configures a table structure based on the management requirement of the service type data converted by the service type unit and dynamically generates data table information; the module release unit is used for carrying out front-end list display, card display and query condition configuration on the service types of the defined table structure, so that management on the data information of the defined table structure is rapidly realized. The invention carries out type judgment on the reimbursement sheets which are easy to report quickly, carries out standardized treatment on the reimbursement sheets, can rapidly carry out data analysis and classification on the reimbursement sheets, and finally generates standardized form data, thereby greatly facilitating the analysis and management work of financial data in the later period.
Description
Technical Field
The invention belongs to the technical field of financial data processing, and particularly relates to a financial data standardization system and a financial data standardization method.
Background
Under the surge of global digital economy, digital transformation has become an important point of attention and development for various industries. Enterprises have restarted to think about the internal operation management mode; and as the financial management of enterprise's core, need to apply the digital technology to innovate traditional financial flow better, promote the innovative development of business with the finance, successfully realize that the finance is business enabling, finally become intelligent enterprise.
The easy quick report is excellent financial digital management software, takes connection as a core, aims at integrating industry and finance, relies on an internet aggregation enterprise according to a public consumption platform, helps enterprises establish compliance cost reimbursement, cost payment and budget cost control from a financial view, assists enterprises to carry out agile decision analysis from the operation view, and promotes enterprises to reduce reimbursement management cost, improve reimbursement efficiency and realize benefit maximization through intelligent cost management and refined cost accounting.
When the quick report system is used, the quick report system cannot perform standardized processing on the reimbursement list, so that the reimbursement list cannot be rapidly analyzed and classified, and finally standardized form data cannot be generated, and certain trouble is brought to follow-up financial accounting, reimbursement data analysis and management work.
Disclosure of Invention
Based on the technical problems existing in the prior art, the invention provides a financial data standardization system and a method thereof, which solve the problem that the prior art can not carry out standardization processing on the reimbursement bill which is easy to report quickly.
According to a first aspect of the technical scheme of the present invention, the present invention provides a financial data standardization system, which comprises a service type unit, a data structure definition unit, a module release unit, a data mapping unit and a standardization log unit, wherein the service type unit is used for defining source information data types, the service type unit comprises a service bill, main data, certificates or service interfaces, and the financial data standardization system performs corresponding data circulation and management on source information data according to the service types; the data structure definition unit configures a table structure based on the management requirements of the service type data converted from the service type unit and dynamically generates data table information; the module issuing unit is used for performing front-end list display, card display and query condition configuration on the service types of the defined table structure.
The source information data type is defined by classifying and naming source information data of the financial data processing standardization system.
Further, the data mapping unit is used for defining a data mapping rule, and the data mapping rule is used for corresponding the external service system source information data and the standard service management data of the financial data standardization system in a data mapping mode, so that the format unification of the external system source data and the standard service management data of the financial data standardization system is realized; the one-to-one direct establishment of the data mapping relationship is supported, and the many-to-one or one-to-many mapping relationship is supported through SQL logic; .
Furthermore, the financial data based standardization system also comprises a financial data standardized support system which is used for supporting the operation of the financial data standardized system, wherein a management platform system and a technical platform system are arranged in the financial data standardized support system, the management platform system is used for supporting the normal operation of the platform and recording the daily operation condition, and the technical platform system is used for providing the data storage and transmission functions; the management platform system is internally provided with a right management module, a log management module, a task management module, a business management module, a parameter setting module and an accessory management module; the technical platform system is internally provided with an enterprise-level distributed application service unit, a distributed relational database RD6, a distributed message queue unit, a distributed cache unit, a platform DevOps and a computer and storage platform unit.
According to a second aspect of the present invention, there is provided a financial data standardization method for carrying out standardized data processing on an easy-to-report-reimbursement sheet by using the above financial data standardization system, the financial data standardization method specifically including the steps of:
step S1, obtaining an easy-to-report outbound message;
s2, the easy-to-report bill is standardized;
step S3, the easy-to-report bill is standardized to a downstream bill and a standardized log is recorded;
and S4, pushing the bill association by the downstream bill.
Step S2, the easy-to-report bill is standardized, and the bill is standardized after receiving the request parameter easy-to-report outbound message entity, and the request parameter easy-to-report outbound message entity calls an interface of which the hawk-erplink service path is hawk-erplink/client/ekb/outbound handle; step S2, the easy-to-report bill standardization further comprises the following steps:
step S21, analyzing the easily-fast-reported outbound message entity;
s22, constructing connection information easy to report;
step S23, obtaining a bill data entity, performing information empty judgment and verification, and constructing a data model entity based on the type of the bill data entity;
step S24, the data model entity is saved.
Further, the step S3 of normalizing the easy-to-report bill to the downstream bill and recording the normalized log specifically comprises the following steps:
Step S31, obtaining service types and inquiring stored bill information;
step S32, various files required by standardization are acquired;
and step S33, the bill is standardized, and the problems generated in the standardization process are recorded and stored in a standardized log unit.
Further, the step S4 of pushing the document association from the downstream document includes the following steps: s41, inquiring the corresponding standardized logs and grouping; and step S42, finishing the pushing of the downstream bill.
Preferably, the step S21 specifically includes the following steps:
step S211, judging the bill type;
step S212, judging the tenant;
step S213, tissue judgment;
the step S211 of document type determination further includes the following technical contents:
the code starts with 'B', and the bill type is a reimbursement bill;
the code starts with J, and the bill type is a borrowing bill;
the code starts with S, and the bill type is the application form;
step S212, tenant judgment further includes the following technical contents:
screening a bill with enterprise ID as a client 1, marking the tenant name as 'tenant 1', marking the enterprise ID as abnormal data if the enterprise ID does not exist, and marking 'unknown easy-to-report enterprise ID' by information; checking the tenant name, acquiring the tenant Id of the tenant name, and storing the tenant Id to an easy-to-report outbound message entity;
The step S213 of organizing the judgment further includes the following technical contents:
marking a 'legal name' field in a legal entity in the easy-quick-report outbound message entity as an organization name, carrying out organization verification according to the organization name and a tenant ID acquired before, acquiring the tenant and the organization ID under the organization name, storing the organization ID to the easy-quick-report outbound message entity, and if the organization name is empty, popping up the abnormal 'the name in the legal entity object in the outbound message is empty'.
More preferably, in the step S22 of constructing the connection information of easy and fast reporting, the construction of the connection information of easy and fast reporting is performed after the analysis is completed, and the construction of the connection information object of easy and fast reporting is performed according to the obtained organization ID and tenant ID, and the step S22 specifically includes the following steps:
step S221, acquiring ekb connection configuration of a tenant;
step S222, obtaining an easy-to-report authorization;
step S223, constructing easy-to-report OpenAPI connection information;
acquiring ekb connection configuration of a tenant, and acquiring a three-party connection configuration entity of easy-to-report connection configuration information in a middle system according to an upper organization ID and the tenant ID;
acquiring an easy-to-report authorization, and according to the acquired three-party connection configuration entity, calling a path https of/(app. Ekuaibao. Com/api/openapi/v1/auth/getAccess token to acquire a return result, performing null judgment and verification on a value in the return result, and constructing an easy-to-report authorization entity according to a corresponding relation after verification;
Step S223 constructs easy-to-report OpenAPI connection information: and constructing an easy-quick-report interface connection information entity according to the tenant ID, the domain name in the three-party connection configuration entity and the easy-quick-report authorization entity.
Compared with the prior art, the financial data standardization system and the financial data standardization method have the beneficial effects that:
the invention judges the type of the reimbursement bill which is easy to report quickly based on the financial data standardization system, then carries out standardization treatment on the reimbursement bill, can rapidly analyze and classify the reimbursement bill, and finally generates standardized form data, thereby greatly facilitating the management, analysis and statistics of financial data by financial staff.
Drawings
FIG. 1 is a functional block diagram of a financial data normalization system of the present invention;
FIG. 2 is a block flow diagram of a method of normalizing financial data in accordance with the present invention;
FIG. 3 is a block flow diagram of the easy-to-report data normalization of FIG. 2;
FIG. 4 is a block flow diagram of resolving the easy-to-report outbound message entity of FIG. 3;
FIG. 5 is a block flow diagram of the easy-to-report connection information construction of FIG. 3;
FIG. 6 is a block flow diagram of the data model entity constructed based on the document data entity type of FIG. 3;
FIG. 7 is a block flow diagram of the save data model entity of FIG. 3;
FIG. 8 is a block flow diagram of the easy-to-report document of FIG. 2 normalized to a downstream document and recorded with a normalized log;
FIG. 9 is a block flow diagram of the normalization of documents and recording of existing problems for saving to the normalization log unit of FIG. 8;
FIG. 10 is a block flow diagram of the downstream document-pushing document association of FIG. 2;
FIG. 11 is a detailed flow chart of another financial data standardization process in accordance with the invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention. It is apparent that the described embodiments are only some embodiments of the present invention, not all embodiments, and that all other embodiments obtained by persons of ordinary skill in the art without making creative efforts based on the embodiments in the present invention are within the protection scope of the present invention.
The invention provides a financial data standardization system and a method thereof, which belong to the technical field of financial data processing, wherein a service type unit in the system is used for defining source information data types, the service type unit comprises a service bill, main data, certificates or service interfaces, and the financial data standardization system carries out corresponding data circulation and data management on source information data according to the service types; the data structure definition unit configures a table structure based on the management requirements of the service type data converted from the service type unit and dynamically generates data table information; the module issuing unit is used for performing front-end list display, card display and query condition configuration on the service types of the defined table structure. The invention judges the type of the reimbursement bill which is easy to report quickly based on the financial data standardization system, then carries out standardization treatment on the reimbursement bill, can rapidly carry out data analysis and classification on the reimbursement bill, and finally generates standardized form data, thereby greatly facilitating the management, analysis and statistics of financial data of financial staff in later period.
The source information data type is defined by classifying and naming source information data of the financial data processing standardization system.
The data normalization system and the working method thereof according to the present application will be described in detail with reference to the accompanying drawings.
As shown in fig. 1, the application provides a financial data standardization system, which comprises a service type unit, a data structure definition unit, a module issuing unit, a data mapping unit and a standardized log unit, wherein the service type unit is used for defining source information data types, the service type unit mainly comprises service receipts, main data, certificates or service interfaces, and the financial data standardization system carries out corresponding data circulation and data management on source information data according to the service types; the data structure definition unit configures a table structure based on the management requirements of the service type data converted from the service type unit and dynamically generates data table information; the module issuing unit is used for performing front-end list display, card display and query condition configuration on the service types of the defined table structure.
Further, the data mapping unit is used for defining a data mapping rule, and the data mapping rule corresponds the source information data of the external service system and the standard service management data of the financial data standardization system in a data mapping mode, so that the source data of the external system and the standard service management data of the financial data standardization system are unified in format; the standard business management data supporting the external system source data and the financial data standardization system directly establish a data mapping relation based on a one-to-one relation, and the standard business management data supporting the external system source data and the financial data standardization system establish a data mapping relation based on a many-to-one or one-to-many relation through SQL logic;
Further, the financial data standardization system further comprises a financial data standardization supporting system, wherein the financial data standardization supporting system is used for supporting the operation of the financial data standardization system, a management platform system and a technical platform system are arranged in the financial data standardization supporting system, the management platform system is used for supporting the normal operation of the platform and recording the daily operation condition, and the technical platform system is used for providing the data storage and transmission functions; the management platform system is internally provided with a right management module, a log management module, a task management module, a business management module, a parameter setting module and an accessory management module; the technical platform system is internally provided with an enterprise-level distributed application service unit, a distributed relational database RD6, a distributed message queue unit, a distributed cache unit, a platform DevOps and a computer and storage platform unit.
The functions of each functional module in the management platform system of the financial data standardization supporting system are as follows:
1. and the permission management module is used for: the authority management module is a bottom layer core function of the financial data standardization system and mainly comprises functions of user management, role management, data authority management and the like; the authority management module realizes the authorization of inquiring the data range based on the user login authorization, the role access control authorization and the data authority through a flexible configuration mode. User management realizes control of user access system authority by defining user login codes and user passwords. Role management realizes authority control of roles on an operation menu and an operation button by defining role codes, role names, operation menus and operation buttons; the data authority management presets the data authority level of the financial data standardized data processing, the data authority registration comprises organization-level authority control, department-level authority control and user-level authority control, and user access authority control, operation button authority and operation data authority control are realized through user allocation roles and the data authority level.
2. And the log management module is used for: the log management module defines a log in log, an operation log, a service log, a task log, and an interface log. The system manager can check the reasons of error occurrence and system operation traces through the log management module. Providing basis for analysis of application condition and operation tracing of the financial data standardized data processing system.
The log management function node records the user log-in system time, log-out system time and whether the user is on line currently or not. The operation log management function node records various operation information records of the system, including records of operations such as data inquiry, data addition, data modification, data deactivation/activation, data deletion and the like, of a user. The service log management function node records service calling information, calling time and processing result information among the micro services of the platform. The task log management function node records the timing task execution information of the system background, including the timing task execution result, the execution time and the like. The interface log management function node records the calling record, the executing result and the executing message information of the external system integrated interface.
3. The task management module:
The task management module centrally manages all background automatic task information of the platform and can set task execution time; based on the task management module, the task management module can be applied automatically according to the requirements of the stipulation Fan Shixian, such as data capture, data processing and the like, so that manual operation is reduced, and usability of the system and the like is enhanced. And the task execution log is combined to track, record and analyze the task execution condition. The task management module comprises task management and a task executor, and the task management can be defined by information such as tasks, operation modes, task parameters, execution strategies and the like. The task executor binds the tasks on the basis of task management and the like, sets the execution sequence and the execution time of the tasks, realizes the sequential execution of the multiple tasks, and can meet the requirement of complex background task processing scenes.
4. Business process module:
the business process module comprises three modules of process category definition, approval process design, approval message center and the like. The corresponding approval process strategy can be flexibly set aiming at the functional node with approval requirements, and bill approval application is realized. The process category is used for defining functional nodes needing approval and comprises information such as process identification, approval path, withdrawal path, data interface and the like. The approval process design is used for designing a specific approval process for the process category. The approval message center centrally manages all approval messages in the running process of the approval process.
5. Parameter setting module:
the parameter setting module is used for defining some control parameter information in the process of system application operation and task execution; the method is used for solving different application requirements of different enterprises; controlling through parameter setting management; the method is convenient for a manager to carry out quick configuration application when carrying out system initialization configuration, and enhances the flexibility of the platform.
6. And the accessory management module is used for:
the accessory management function in the accessory management module defines an accessory management path, accessory uploading size limit control and accessory uploading type control; in addition, the storage period of the accessory can be flexibly set.
And based on an accessory management center of the accessory management module, all accessory information of the financial data standardization system can be checked in a concentrated mode, and meanwhile, the operation of uploading or checking the accessory information can be performed on each business function node.
The technical platform system is internally provided with an enterprise-level distributed application service unit, a distributed relational database RD6, a distributed message queue unit, a distributed cache unit, a platform DevOps and a computer and storage platform unit; the functions of each functional module in the technical platform system of the financial data standardization supporting system are as follows:
The enterprise-level distributed application service EDAS (Enterprise Distributed Application Service) adopted by the invention is a Cloud native PaaS platform for application hosting and micro-service management, provides full stack solutions for application development, deployment, monitoring, operation and maintenance and the like, supports micro-service operation environments such as Spring Cloud, apache Dubbo and the like, helps a client application to easily Cloud, and saves service resource input cost.
Preferably, the distributed relational database RD6 used in the invention is a relational database, which is a MySQL database. The distributed message queue unit adopts a message queue middleware which is RabbitMQ; the financial data standardized support system has a high-performance, high-availability, scalable and final consistency architecture, and can solve the problems of application coupling, asynchronous message, flow cutting and the like. Furthermore, the distributed caching unit in the financial data standardization supporting system adopts the distributed caching as Redis, so that the data which are frequently used and fixed in line pairs, such as login authorization information and basic files, are stored, and the data can be rapidly used in the service occurrence process.
In particular, platform DevOps in the financial data standardization support system facilitates communication, collaboration and integration between development (application/software engineering), technical operation and Quality Assurance (QA) departments, which adopts gitlab+jenkins+bash scripts+docker mirror servers+k8s or docker swarm automatic pull mirror deployment. In the financial data standardization supporting system, when a developer submits or merges codes, the Gitlab can check the operation of submitting the codes or merging the codes, inform Jenkins to execute compiled codes and package codes to a docker mirror image, submit the mirror image to a mirror image server, and a trigger of the mirror image server can inform k8s or docker swarm to update the mirror image and deploy an environment.
Further, the financial data standardization support system adopts a computer and a storage platform unit, which realizes the storage and management of computer information data and saves the data in a computer platform.
As shown in FIG. 2, the invention provides a financial data standardization method, which is a method for carrying out standardized data processing on an easy-to-report-reimbursement bill by using the financial data standardization system, and solves the technical problem that the easy-to-report-reimbursement bill is difficult to carry out standardized processing in the prior art. The financial data standardization method specifically comprises the following steps:
step S1, obtaining an easy-to-report outbound message;
s2, the easy-to-report bill is standardized;
step S3, the easy-to-report bill is standardized to a downstream bill and a standardized log is recorded;
and S4, pushing the bill association by the downstream bill.
The financial data standardization method adopts the prior art of easy quick report (a financial integration software developed by Beijing Hesi information technology Limited company, which enables an integrated bank and a third party payment platform to pay public and private, automatically generates certificates for the financial software, and is connected with the existing OA, CRM, ERP business systems of enterprises) and pushes request parameters to the financial data standardization system through a connection interface. The financial data standardization method adopts a connection interface to connect an easy-quick report platform, the connection interface calls an openApi path to be an interface of a domain name/openApi/ekuaibao/receiver-output-message, a message in a request parameter is converted into an easy-quick report outbound message entity, codes in the easy-quick report outbound message entity are verified, the beginning of ' B ' is an easy-quick report-reimbursement list, the beginning of ' J ' is an easy-quick report-borrowing list, and meanwhile, the reimbursement bill information belonging to an authorized tenant is received according to the corresponding enterprise ID (known) and the enterprise ID in the easy-quick report outbound message entity, and if the reimbursement bill information is not matched, the reimbursement bill information is marked as abnormal ' unknown easy-quick report enterprise ID; then, the outbound message which is easy to report is used as a parameter, and an interface with a path of hawk-erplink/client/ekb/outbound handle in hawk-erplink service is called to store the single data flow which is easy to report; the return value is obtained and then is directly returned to the quick report without processing; meanwhile, creating an interface monitoring entity, and storing the fields in the message entity which is easy to report out and the returned results of the stored easy-to-report list into the interface monitoring entity according to the corresponding relation and storing the results into a database; and storing error information recorded in the financial data standardization process into log management.
As shown in fig. 3, step S2 is easy-to-report data standardization, which is to perform document standardization after receiving the request parameter easy-to-report outbound message entity, and call the hawk-erplink service path to be the hawk-erplink/client/ekb/outbound handle interface; step S2, the easy-to-report bill standardization further comprises the following steps:
step S21, analyzing the easily-fast-reported outbound message entity;
s22, constructing connection information easy to report;
step S23, obtaining a bill data entity and performing empty judgment verification, and constructing a data model entity based on the type of the bill data entity;
step S24, the data model entity is saved.
Further, as shown in fig. 4, as a preferred embodiment of the present invention, the step S21 specifically includes the following steps:
step S211, judging the bill type;
step S212, judging the tenant;
and S213, organizing judgment.
The step S211 of determining the document type in the parsing of the easy-to-report outbound message entity shown in fig. 4 further includes the following technical contents:
the code starts with 'B', and the bill type is a reimbursement bill;
the code starts with J, and the bill type is a borrowing bill;
the code starts with S, and the bill type is the application form;
step S212, tenant judgment further includes the following technical contents:
Screening a bill with enterprise ID of client 1, wherein the tenant name is recorded as ' tenant 1 ', and the enterprise ID is recorded as abnormal ' unknown easy-to-report enterprise ID; checking the tenant name, acquiring the tenant Id of the tenant name, and storing the tenant Id to an easy-to-report outbound message entity;
the step S213 of organizing the judgment further includes the following technical contents:
marking a 'legal name' field in a legal entity in the easy-quick-report outbound message entity as an organization name, carrying out organization verification according to the organization name and a tenant ID acquired before, acquiring the tenant and the organization ID under the organization name, storing the organization ID to the easy-quick-report outbound message entity, and if the organization name is empty, popping up the abnormal 'the name in the legal entity object in the outbound message is empty'.
Further, as shown in fig. 5, as a preferred embodiment of the present invention, the step S22 specifically includes the following steps:
step S221, acquiring ekb connection configuration of a tenant;
step S222, obtaining an easy-to-report authorization;
step S223, constructing the OpenAPI connection information easy to report quickly.
The steps in the construction of the connection information of easy and fast reporting shown in fig. 5 further include the following technical content, the construction of the connection information of easy and fast reporting is performed after the analysis is completed, and the connection information object of easy and fast reporting is constructed according to the obtained organization ID and tenant ID;
Step S221, obtaining ekb connection configuration of the tenant: and acquiring the quick-report connection configuration information of the three-party connection configuration entity in the middle station system according to the upper organization ID and the tenant ID.
Step S222, obtaining easy-to-report authorization: according to the construction request parameter map of the three-party connection configuration entity obtained in the step S221, the calling path is https:// app.
Step S223, constructing easy-to-report OpenAPI connection information: and constructing an easy-quick-report interface connection information entity according to the tenant ID, the domain name in the three-party connection configuration entity and the easy-quick-report authorization entity.
As shown in fig. 6, as a preferred embodiment of the present invention, the step S23 specifically includes the following steps:
step S231, a borrowing bill is constructed;
step S232, constructing a reimbursement bill document;
and S233, constructing a data model entity based on the borrowing bill and the reimbursement bill.
Further, step S23 obtains the document data entity and performs void judgment verification, and constructs a data model entity based on the type of the document data entity: after the quick report connection information object is constructed, the receipt data entity is obtained through the quick report connection information, the receipt type in the quick report outbound information entity and the receipt ID call acquisition receipt data list interface, and the data entity is constructed and stored according to the receipt data entity after empty judgment and verification.
Step S231 is to construct a borrowing bill, only select the bill with the bill state of 'paid' to carry out service processing, and then construct a complete borrowing bill.
Step S231 obtains the business type corresponding to the middle system according to the name of the quick report template, the borrowing list supports the personal borrowing application list at present, the rest is marked as abnormal, and the processing is not supported temporarily; the receipt data entity which is easy to report back at present only comprises a single receipt, so that the receipt is subjected to data assembly according to the service type. Firstly, matching a bill approval flow with parameters of a middle financial approver to obtain a bill financial approver id, taking the financial approver id as a parameter calling path to obtain financial approver information by using an easy-to-report interface of https:// app.ekuaibao.com/api/openapi/v1/staffs/getStaffIds, and taking a bill number, a title, presenter information, financial approver information, borrowing date, repayment date, borrowing department, expense undertaking department, borrowing amount, payment subject, payment account information, payment time, payment channel, batch number, collection information (collection information comprises account type, account name, account number, account category, bank category, account opening point), remark, id, bill state, enterprise id, template information, source organization, source id, source code and source date as main table information, synchronizing the presenter information to a middle personnel file, and synchronizing the financial approver information to the middle personnel file; and then supplementing information of tenants, organizations, service types, users and the like to construct a reimbursement bill data model entity. And finally, calling an interface with a dm path of hawk-dm/client/ext/saveMutiform data to store data.
And S232, constructing a reimbursement bill, namely selecting only the bill with the bill state of paid to carry out service processing, and then constructing a complete reimbursement bill.
Firstly, obtaining a service type corresponding to a middle system according to an easy quick report template name, wherein the reimbursement bill currently supports "purchase" of a expenditure requesting bill "," daily expense reimbursement bill "," business trip reimbursement approval bill T "," group construction expense reimbursement approval bill "and the rest are marked as abnormal and are not supported for processing; then, the information entity and the bill id calling path are connected by using an easy-to-report interface to obtain details of the reimbursement single data, and then, the easy-to-report departments are called by paging until all departments are obtained, wherein the calling path is https; preferably, paging is used to call the easy-to-report department, and one thousand are acquired at a time. The receipt data entity returned by the current quick report only comprises a single receipt, so that the receipt is subjected to data assembly according to the affiliated service type, the receipt financial approver id is obtained by matching the receipt approval flow with the parameters of a middle financial approver, then the financial approver id is used as a quick report interface with a parameter calling path of https:// app.
Still further, the step S232 of constructing the reimbursement bill includes the steps of:
step S2321, document serial number, title, submitter information, financial approver information, reimbursement date, reimbursement department, payment subject, payment account information, payment time, payment channel, batch number, collection information (account type, account opening name, account number category, bank category, account opening site), remark, reimbursement total amount, payment amount, enterprise paid amount, document id, document state, enterprise id, template information, source organization, source id, source code, source date are stored as main table information;
step S2322, sub-table information is constructed: performing cyclic processing on a form detail set in the acquired reimbursement form details, firstly judging that the acquired center system cost type parameter is matched with a form detail cost department code, if the acquired center system cost type parameter is not matched successfully, recording that the reimbursement form detail cost type is abnormally popped up, and according to the bill details, corresponding to cost type information, whether the bill details are apportioned, amount, currency, date, starting date, ending date, consumption city, invoice form, invoice number, department information, service period and consumption event to sub-table information according to matching relation, and recording invoice id contained in the bill details as a subsequent flow processing basis; then supplementing information of tenants, organizations, service types, users and the like to construct a reimbursement bill data model entity;
Step S2323, calling an easy-to-report INVOICE information interface according to a receipt id as a parameter, wherein a calling path is https:// app.ekuaibao.com/api/openapi/v2/extension/flow/INVOICE/search to obtain receipt information-EkbFlowInvoieinfo entity, preparing to construct a plurality of INVOICE data model entities under the reimbursement bill, acquiring an INVOICE information set of a data book receipt in the receipt information according to the receipt id, filtering an INVOICE of a "shaping" type according to the INVOICE type, traversing the information set according to the INVOICE type, calling the easy-to-report interface according to the INVOICE id set and the INVOICE type of each group, and constructing an INVOICE data model of the returned INVOICE data set according to the receipt id set and the INVOICE type by https:// app.ekuaibao.com/api/v 2/extension/INVOICE/jeject/search, and then carrying out single-report model data combination of the returned INVOICEs with the plurality of INVOICE data models.
The process of constructing the invoice data model entity is divided into two steps, wherein the first step of constructing the invoice data model entity process is to construct a main table: and saving the bill id of the invoice main body to a main table, and constructing the information of the other fields of the main table according to different logics according to the invoice type. The invoice of the "invoice" type stores bill categories, invoice categories, buyer names, buyer tax payer identification numbers, buyer address phones, buyer issuer and account numbers, seller names, seller tax payer identification numbers, invoice codes, invoice numbers, invoicing dates, price tax totals, tax amounts, whether deductions are made, deductible tax amounts, non-tax amounts, remarks to main table information in an invoice body. The invoice of the type taxi stores bill category, invoice code, invoice number, amount, whether deduction is carried out, consumption type, taxi ticket loading time, taxi ticket unloading time, taxi milestone and taxi invoice location to main table information in an invoice main body. The invoice of the "passengCar" type stores bill category, invoice code, invoice number, date of invoicing, amount, tax rate, whether deduction is made, tax amount can be made, tax amount not made, consumption type, name of passenger, outbound, arrival to main table information in the invoice theme. The invoice of the "train" type holds bill category, invoice number, date of invoicing, amount, tax rate, whether to withhold, withhold tax amount, non-tax amount, consumption type, train ticket number, outbound, arrival station, as type, occupant name to main table information in the invoice body. The invoice of the "flightiterary" type stores the bill category, invoice number, billing date, amount, tax rate, whether deducted, deductable tax, non-tax amount, consumption type, airline e-ticket travel ticket price, airline e-ticket travel ticket tax, airline e-ticket travel ticket premium, airline e-ticket travel ticket fuel additional fee, airline e-ticket travel ticket civil aviation development fund, outbound, arrival station, airline e-ticket travel ticket flight number, airline e-ticket travel ticket validation code, airline e-ticket travel ticket time, airline e-ticket travel ticket filler, seat type, passenger identity number, passenger name, airline e-ticket sales unit code to main table information in the invoice body. The "tolls" type invoice stores bill category, invoice code, invoice number, billing date, amount, whether to withhold, consumption type, road toll invoice entry, road toll invoice exit to main table information in the invoice body. The invoice of the "fixed" type holds bill category, invoice code, invoice number, amount, whether to withhold, consumption type to main table information in the invoice body. The invoice of the 'main print' type stores bill category, invoice code, invoice number, tax rate, tax amount, whether to deduct, non-tax amount, purchaser name, purchaser tax payer identification number, seller name, seller tax payer identification number to main table information in an invoice body.
The second step of the invoice data model entity constructing process is to construct a sub-table: calling an easy-to-report INVOICE detail interface according to an INVOICE id of a main table for constructing an INVOICE data model, wherein a path is https:// app. Ekuaibao. Com/api/openapi/v2/extension/INVOICE/object/INVOICE id/detail, acquiring an INVOICE detail, traversing the INVOICE detail, and storing the INVOICE detail id, commodity service name, quantity, unit price, tax rate, tax amount, amount and price tax in total to sub-table information according to a corresponding relation; and finally, constructing the invoice main table sub-table information into an invoice data model entity.
Step S2324, merging the reimbursement single data model entity constructed in step S2323 with the corresponding invoice data model entities, and calling the interface of dm service path hawk-dm/client/ext/saveMutiform data to store data.
Step S233, constructing a data model entity based on the borrowing bill and the reimbursement bill;
as shown in fig. 7, as a preferred embodiment of the present invention, the step S24 of traversing and storing the data model entity specifically includes the following steps:
step S241, checking whether necessary data is complete;
step S242, obtaining a table structure;
step S243, repeatedly checking the data per se;
And step S244, splicing and storing the data.
Further, step S241 checks whether the necessary data information is complete, and stores the tenant ID, service type, organization ID, form creator ID, entity itself data, and master table data of the data model entity, which cannot be empty, otherwise pops up an exception.
Step S242 obtains a table structure, obtains a corresponding table structure (including a main table and a sub-table) according to the service type to which each data model entity belongs, obtains a main table name and a sub-table name according to the service type,
step S243 performs repeated verification on the data itself, and performs repeated verification on the data itself: and comparing the main table name and the bill id which are just acquired with a database, and storing if the main table name and the bill id do not exist.
Step S244, splicing and storing data, correspondingly constructing a main table and a sub-table entity object to be stored according to the fields stored during constructing a data model entity and the fields of the acquired table structure, and establishing association between the sub-table and the main table entity; after the summarization is completed, the data are stored in batches, so that the time consumption is long when a large amount of data is avoided; and returning the document id and the main table entity id after the storage is completed.
As shown in fig. 8, as a preferred embodiment of the present invention, step S3 is to normalize the easy-to-report bill to a downstream bill and record a normalization process to form standard log information; the method specifically comprises the following steps:
Step S31, obtaining service types and inquiring stored bill information;
step S32, obtaining files required by standardization;
step S33, the bill is standardized, and the problems are recorded and stored in a standardized log unit.
Step S3, the quick receipt is easily standardized to a downstream receipt and recorded in a standardized log, and the receipt and the borrowing receipt are standardized to the downstream receipt (a group construction receipt, a daily receipt, a travel receipt and a expenditure invitation receipt) in two ways, wherein one way is to obtain the receipt id and the main table entity id according to the above process to perform single financial data standardization, and the other way is to perform batch standardization according to a date interval through a task mode. In the invention, the bill standardization acquires the service type, the data conversion rule, the tenant id and the bill id (date interval), firstly, the configured data conversion rule is inquired from the system according to the tenant id, the source service type (reimbursement bill or borrowing bill) and the target service type (downstream bill type), other conditions are known, and then the dm bill standardization interface is called, and the path is hawk-dm/client/trans/Transform. The bill standardization flow is as follows:
step S31, acquiring a service type, acquiring a target service type id from a data conversion rule, inquiring complete target service type information, and then acquiring a bill: when the standardization is carried out according to the date interval, all documents in the period need to be inquired according to the date interval and returned, and when the document id is input, the documents are directly inquired according to the id and returned. Acquiring invoice information: taking out 'flow' from the acquired bill set, summarizing, inquiring the corresponding invoice main table and sub-table information (which are associated before) from the system, then grouping the invoice main tables according to 'flow' (generally, one bill comprises a plurality of invoice main tables), and then associating the invoice sub-tables through each invoice main table id to prepare for subsequent business processing.
Step S32, obtaining files required for standardization: and acquiring all department files, organization tax rate information, personnel files, user information, bank account and customer information under the tenant, acquiring a user file comparison table named as 'ekbpsn-user' and a user file comparison table named as 'EKB-DEPT', and recording failure information content into a standardized log if one ring of acquisition fails.
Step S33, the bill is standardized, and the problems are recorded and stored in a standardized log unit: and (5) standardizing the acquired bill information, wherein each bill is standardized until the downstream bill is divided into four layers. And respectively constructing a downstream bill main table, a downstream bill detail table, a downstream bill invoice table and a downstream bill data model, and recording a standardized log.
As shown in fig. 9, as a preferred embodiment of the present invention, the step S33 specifically includes the following steps:
s331, constructing a main list of downstream receipts;
s332, constructing a downstream bill detail table;
s333, constructing a downstream bill invoice sub-table;
step S334, a downstream bill data model is built and recorded in a standardized log unit.
The downstream bill master table is constructed in step S331, which directly stores the fields of whether the bill is shared, tenant id, source service type id, source organization, source service type code, source date, bill id, bill code, theme, payment channel, transaction date, reimbursement total amount, payment amount and payment time into the downstream bill master table, obtains payment body information from the organization file by the bill payment body name, obtains tax payer category from the organization tax rate file by the payment body id, obtains submitter information from personnel file by the submitter code, obtains user code from user file by the financial approver code in contrast, obtains user information from the user file by the user code, obtains bank account information from the bank account file by the payment account id, obtains department information from the department file by the reimbursement department code, and stores the information obtained by the file into the downstream bill master table, and if the bill target service type is a payment invitation bill, the additional storage field is required. The downstream bill master table construction processing logic in step S331 is as follows:
if the bill collection account type is PERSONAL, the downstream bill collection account type is stored with 1; the account type is PUBLIC, and the downstream bill collection account type is stored with 2; finding a customer from the file acquired before according to the collection name, and storing the id of the customer until a payment statement is made only when one customer is acquired, otherwise recording abnormality; and matching account categories, wherein "BANK" is stored as "1", "WXPAY" is stored as "2", "ALIPAY" is stored as "3", and "OVERSEABANK" is stored as "4", and then storing the collection account number, the collection BANK category, the collection account opening BANK and remarks to the main list of the expense payment statement.
Step S332, constructing a downstream bill detail table: recording the required cost department information and the starting time ending time for bill invoice sub-table construction, then storing bill id, easy-to-report bill detail id, cost type code and cost type in bill detail to the detail sub-table, acquiring department information from department files by the cost department code, storing custom item 1 as department id, custom item 2 as department category, storing custom item 3 as starting time and custom item 4 as ending time.
Step S333, constructing a downstream bill invoice sub-table: according to bill id (flowwid), acquiring bill invoice detail set from the bill invoice set summarized before, traversing the bill invoice detail set to prepare for constructing a downstream bill invoice sub-table, counting the deduction tax and price tax sum according to invoice row id (flowwid), and recording the type of tax rate which is not 0; and storing the downstream bill reimbursement details into a downstream bill data model detail table.
Constructing a downstream bill invoice sub-table into two categories: the bill category codes are "invoice" tax transfer amount and other bill category tax transfer amount, the invoice sub-table collection under the downstream bill main table obtained in the step S331 is obtained, the invoice sub-table is traversed, and the downstream bill invoice sub-table is generated and generated according to the corresponding relation between the invoice main table and the invoice sub-table according to the preparation information obtained in advance.
Wherein "invoice" entry tax transfer amount generation rules:
if the price tax total is greater than the reimbursement amount and there is only one category of tax rate that is not 0, and if the deductible tax amount is equal to 0 or the tax amount is 0, the entry tax amount transfers out an amount=0;
if the discounts the tax aggregate is greater than the reimbursement amount and the category of tax rate is not 0 is only one, the entry tax transfer amount=0;
if the price tax total is greater than the reimbursement amount and the tax rate is not 0 is of only one kind, and if the deductible tax amount is not equal to 0 or the tax amount is not 0, a calculation is made with the following calculation formula: an entry tax transfer amount= ((price tax total-reimbursement amount)/(1+tax rate)) [ (tax rate [ (tax/reimburseable tax) ]).
Other bill category entry tax transfer amount generation rules:
if the price tax total is greater than the reimbursement amount and there is only one category of tax rate that is not 0, and if the deductible tax amount is equal to 0 or the tax amount is 0, the entry tax amount transfers out an amount=0;
if the price tax total is greater than the reimbursement amount and there is only one type of tax rate that is not 0, and if the deductible tax is not equal to 0 or the tax is not 0, the entry tax transfer amount = tax- (reimbursement amount/1 + tax rate) ×tax rate;
If the discounts price tax total is greater than the reimbursement amount and there is only one category of tax rate that is not 0, the incoming tax is transferred out of amount = 0.
In the construction of the downstream bill invoice sub-table in the step S333, the invoice information is stored in the downstream bill invoice sub-table;
step S334, a downstream bill data model is built and recorded to a standardized log unit:
constructing a summarized downstream bill main table, a downstream bill detail table and a downstream bill invoice table in the steps S331, S332 and S333, further constructing a downstream bill data model entity, recording bill abnormality information and file missing information generated in the steps S331, S332 and S333, creating a standardized log unit entity, and storing information such as tenant, source bill information, target bill information, bill producer information, error information (null if no error exists), log state (success if no bill abnormality information and file missing information exist, failure) and the like into the standardized log unit entity;
the process of storing the downstream bill data model is to traverse and store an archive information file, wherein the archive information file comprises a group construction reimbursement bill, a daily reimbursement bill, a travel reimbursement bill and a expenditure expense bill, and the process of storing the downstream bill data model is roughly divided into four steps:
Step S3341, checking whether the necessary data is complete: storing tenant ID, service type, organization ID, form creator ID and entity data of the data model entity, wherein the main table data cannot be empty, otherwise, the main table data is popped up to be abnormal;
step S3342, obtaining a table structure: according to the service type of each data model entity, a corresponding table structure (comprising a main table and a sub-table) is obtained, and a main table name and a sub-table name are obtained according to the service type;
step S3343, repeatedly checking the data itself: comparing the main table name and the bill id which are just acquired with a database, and storing if the main table name and the bill id do not exist;
step S3344, splice data and save: according to the fields stored during the construction of the data model entity and the fields of the acquired table structure, correspondingly constructing a main table and sub-table entity objects to be stored, and establishing association between the sub-table and the main table entity; after the summarization is completed, the data are stored in batches, so that the time consumption is long when a large amount of data is avoided.
Further, according to the document id, a standardized log is stored, and if the system monitors data for the repeatedly executed interface, the standardized log corresponding to the document id is updated; if the message is the outbound message which is easy to report the new push, a new message is added. After the standardization to the downstream bill data model and the standardization log are stored, returning a result to the interface calling service;
Step S4, pushing bill association of the downstream bill: as shown in fig. 10, the step receives the returned result after the standardized downstream bill data model is completed, calls dm service to push downstream bill interface, and if there is unknown error, finally saves the result to newly added interface monitoring error information; the downstream bill can be pushed from the task management module, the pushing target is all the bills in the appointed date period, the dm service is called by the task module xxljob service to push the downstream bill interface, and the path is hawk-dm/client/push-ae. More specifically, the step S4 of pushing the document association by the downstream document includes the steps of: s41, inquiring the corresponding standardized logs and grouping; and step S42, finishing the pushing of the downstream bill. The functional steps in step S4 are as follows:
step S41, inquiring and grouping corresponding standardized logs, and if the downstream bill is pushed by the interface monitoring execution flow, acquiring the corresponding standardized log set (in other embodiments, executing according to a single bill id) through the bill id set; if the downstream bill is directly pushed for the task module, acquiring a corresponding standardized log set according to a specified date period; and classifying the standardized log sets by groups according to service classification (for example, classifying according to a group construction reimbursement bill, a daily reimbursement bill, a travel reimbursement bill, a payment statement and the like), and filtering out service types which do not need to push downstream documents.
Step S42, finishing pushing of the downstream bill: filtering the standardized log set completed according to the service classification, wherein the documents with the standardized state of failure are not pushed by downstream documents; the pushing rule is one-to-one mapping of a target bill primary key and bill association, the standardized log sets of different service types are traversed respectively, and creator, tenant id, source data id, service type, service date, organization id, source bill code, source bill type and organization name are stored in a bill association entity and are put into the standardized log sets; and finally, the downstream bill pushing is finished.
The interface information used in the financial data standardization method is specifically as follows:
1. receiving an outbound message:
the invoked service: hawk-openapi;
path: domain name/openApi/ekuaibao/receiver-outbound-message;
interface method name: handleekb outlbound;
request type: post;
request parameters: string; httpServletResponse;
return parameters: r is R;
the function is as follows: the easy-to-report push easy-to-report list data outbound message to the middle station.
2. Obtaining authorization:
calling a service: hawk-erplink-api;
path:
https://app.ekuaibao.com/api/openapi/v1/auth/getAccessToken；
request type: post;
Request parameters: map;
return parameters: string;
the function is as follows: the middle station obtains the authorization easy to report quickly.
3. Acquiring a data list of the easy-to-report list:
calling a service: hawk-erplink-api;
path: https:// app.ekuaibao.com/api/openapi/v1/docs;
request type: get;
request parameters: token, document coding, document type, document id collection;
return parameters: a bill data list;
the function is as follows: the middle platform pulls the easy-to-report list of the data.
4. Acquiring details of the easy-to-report list:
calling a service: hawk-erplink-api;
path: https:// app.ekuaibao.com/api/openapi/v1/flowDetails;
request type: post;
request parameters: token, document id;
return parameters: bill details;
the function is as follows: the middle platform obtains the details of the easy-to-report list.
5. And (5) acquiring an easy-to-report department:
calling a service: hawk-erplink-api;
path: https:// app. Ekuaibao. Com/api/openapi/v 1/parts;
request type: post;
request parameters: token, paging parameters;
return parameters: department information;
the function is as follows: the middle platform acquires the information of the departments which are easy to report quickly.
6. Acquiring employee information easy to report quickly:
calling a service: hawk-erplink-api;
path: https:// app.ekuaibao.com/api/openapi/v1/staffs/getStaffIds;
Request type: post;
request parameters: token, employee ID, cell phone number, mailbox, job number, third party ID;
return parameters: staff information;
the function is as follows: the middle platform acquires the employee information easy to report quickly.
7. Acquiring invoice information easy to report quickly:
calling a service: hawk-erplink-api
Path:
https://app.ekuaibao.com/api/openapi/v2/extension/flow/INVOICE/search；
request type: post;
request parameters: token, query type, single number or document id;
return parameters: invoice information;
the function is as follows: the middle platform obtains the ticket issuing information of the quick-report reimbursement ticket.
8. Acquiring an invoice main body easy to report quickly:
calling a service: hawk-erplink-api;
path:
https://app.ekuaibao.com/api/openapi/v2/extension/INVOICE/object/objectId/search；
request type: post;
request parameters: a token, invoice type, invoice id collection;
return parameters: an invoice main body collection;
the function is as follows: the middle platform obtains the ticket issuing main body which is easy to report and reimburse rapidly.
9. Acquiring an invoice detail easy to report quickly:
calling a service: hawk-erplink-api;
path:
https://app.ekuaibao.com/api/openapi/v2/extension/INVOICE/object/invoice/invoiceId/detail；
request type: post;
request parameters: token, invoice Id;
return parameters: invoice details;
the function is as follows: the middle platform obtains the bill receipt details which are easy to report and reimburse.
The intra-pair Feign interface in the financial data standardization method is as follows:
description: the core is to convert the remote call API interface defined in the mode of JAVA annotation into the HTTP request form finally through a series of encapsulation and processing, then decode the response result of the HTTP request into JAVA Bean and put the JAVA Bean back to the caller.
1. And (5) storing the detail easy to report:
the invoked service: hawk-dm;
path: hawk-dm/client/ext/saveMutiform data;
interface method name: saveMultextFormData;
request type: post;
request parameters: data model data;
return parameters: storing the result;
the function is as follows: and storing the constructed external bill.
2. Inquiring the quick report-facilitating single data interface after receiving the quick report-facilitating message:
the invoked service: hawk-erplink;
path: hawk-erplink/client/ekb/outboundHandle;
interface method name: handleekb outlbound;
request type: post;
request parameters: the outbound message is easily and quickly reported;
return parameters: r is R;
the function is as follows: and processing the obtained easy-to-report outbound message.
3. Standardized processing interface of the easy-to-report list:
the invoked service: hawk-dm;
path: hawk-dm/client/trans/Transform;
interface method name: a doTransform;
request type: post;
request parameters: service type, data conversion rule, tenant id and document id;
return parameters: normalizing the result;
the function is as follows: the quick report bill is standardized to a downstream bill and a standardized log is recorded.
4. Pushing document association generates a credential interface:
the invoked service: hawk-dm;
Path: hawk-dm/client/transform/sendRelation;
interface method name: sendrelay;
request type: post;
request parameters: document id;
return parameters: storing the result;
the function is as follows: and pushing the standardized downstream bill to bill association.
5. Pushing document association generates a credential interface:
the invoked service: hawk-dm;
path: hawk-dm/client/transform/sendRelation;
interface method name: sendrelay;
request type: post;
request parameters: document id;
return parameters: storing the result;
the function is as follows: the normalized downstream documents (currently pushed one by one) are pushed to the document association.
6. Pushing document association generates a credential interface:
the invoked service: hawk-dm;
path: hawk-dm/client/push-ae;
interface method name: pushAe;
request type: post;
request parameters: date period, tenant id;
return parameters: storing the result;
the function is as follows: and pushing the standardized downstream documents (all documents during a certain date are acquired) to the document association.
In a further embodiment, in combination with the above-described financial data standardization system, a financial data standardization process is provided, as shown in fig. 11, comprising the steps of:
Step W1, pushing bill number information of an reimbursement bill to a financial data standardization system after successful payment of the reimbursement bill easy to report quickly, wherein the financial data standardization system holds the bill number to acquire detailed data easily and quickly; the method comprises the steps that a reimbursement bill is started and scanned correspondingly, whether the reimbursement bill is paid successfully or not is inquired, if the reimbursement bill is paid successfully, bill number information of the reimbursement bill is pushed to a financial data standardization system, and the financial data standardization system holds the bill number to acquire detailed data easily and quickly;
step W2, distinguishing the bill types, namely determining the beginning of the bill type S as an application form, and directly filtering out the application form; the receipt type B is received at the beginning and stored on the reimbursement receipt issued by the data structure definition; receiving and storing the beginning of the bill type J to a borrowing list published by the data structure definition; in detail, acquiring a bill type through bill type judgment, defining a bill at the beginning of a bill type S as an application form, and directly filtering the application form; defining the bill at the beginning of the bill type B as a reimbursement bill, receiving the reimbursement bill at the beginning of the bill type B and storing the reimbursement bill on reimbursement bill released by the data structure definition; and the reimbursement bill at the beginning of the bill type J is defined as a borrowing bill, the borrowing bill at the beginning of the bill type J is received, and the borrowing bill is stored on the borrowing bill released by the data structure definition. Further, data standardization rule processing is carried out on the borrowing list and the reimbursement list, wherein the data standardization rule processing adopts service types, data structure definition, template release, data mapping and standardization logs; the data standardization rule processing is carried out by adopting the same method as the financial data standardization method;
Step W3, processing the reimbursement bill and the borrowing bill which are easy to report quickly into standard bills according to a financial data standardization rule, namely, standard borrowing bill, daily reimbursement bill, travel reimbursement bill, group construction reimbursement bill and expense invitation bill;
and step W4, pushing the bill to the bill association at the same time, and processing financial certificates.
Finally, it should be noted that: the foregoing description is only a preferred embodiment of the present invention, and the present invention is not limited thereto, but it is to be understood that modifications and equivalents of some of the technical features described in the foregoing embodiments may be made by those skilled in the art, although the present invention has been described in detail with reference to the foregoing embodiments. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims (6)
1. A financial data standardization method, it applies the standardized system of the financial data to carry on the standardized processing of the financial data to the easy-to-report bill, the standardized system of the said financial data includes business type unit, data structure definition unit, module release unit, data mapping unit and standardized log unit, the business type unit is used for defining the source information data type, the business type unit includes business bill, main data, certificate or service interface, the standardized system of the financial data will make corresponding data circulation and data management according to the business type from the source information data; the data structure definition unit configures a table structure based on the management requirements of the service type data converted from the service type unit and dynamically generates data table information; the module release unit is used for performing front-end list display, card display and query condition configuration on the service types of the defined table structure; defining source information data types to classify and name source information data of a financial data processing standardization system;
The financial data standardization method specifically comprises the following steps:
step S1, obtaining an easy-to-report outbound message;
s2, the easy-to-report bill is standardized;
step S3, the easy-to-report bill is standardized to a downstream bill and a standardized log is recorded;
step S4, pushing bill association by downstream bill;
step S2, the easy-to-report bill is standardized, and the bill is standardized after receiving the request parameter easy-to-report outbound message entity, and the request parameter easy-to-report outbound message entity invokes the hawk-erplink service, and the path is an interface of hawk-erplink/client/ekb/outbound handle; step S2, the easy-to-report bill standardization further comprises the following steps:
s21, analyzing the easily-fast-reported outbound message data entity;
s22, constructing connection information easy to report;
step S23, obtaining an easy-to-report bill data entity and carrying out information empty judgment verification, and constructing a data model entity based on the type of the bill data entity;
step S24, a data model entity is saved;
the step S3 of standardizing the quick report bill to the downstream bill and recording the standardized log specifically comprises the following steps:
step S31, obtaining service types and inquiring stored bill information;
step S32, obtaining file information required by standardization;
Step S33, the bill data is standardized, and the problems are recorded and stored in a standardized log unit;
the step S23 specifically includes the following steps:
step S231, a borrowing bill is constructed; only selecting a bill with a bill state of 'paid', carrying out service processing, and then constructing a complete borrowing bill;
step S232, constructing a reimbursement bill document; only selecting a bill with the state of paid bill to carry out service processing, and then constructing a complete reimbursement bill;
step S233, constructing a data model entity based on the borrowing bill and the reimbursement bill;
step S23, obtaining a bill data entity and performing empty judgment verification, and constructing a data model entity based on the type of the bill data entity: after the quick report connection information object is constructed, acquiring a bill data list interface through the quick report connection information, the bill type in the quick report outbound information entity and the id call of the bill to acquire the bill data entity, and constructing and storing the data entity according to the bill data entity after empty judgment and verification;
step S231, a borrowing list is constructed to obtain a business type corresponding to a center system according to an easy report template name, a document approval stream is matched with a center financial approver parameter to obtain a document financial approver id, then the financial approver id is used as a parameter call path to obtain financial approver information by using an easy report interface of https:// app.ekuaibao.com/api/openapi/v 1/staffs/getStaffs, then document numbers, titles, submitter information, financial approver information, borrowing dates, repayment dates, borrowing departments, expense undertaking departments, borrowing amounts, payment subjects, payment account information, payment time, payment channels, batch numbers, collection information, remarks, document ids, document states, enterprise ids, template information, source organizations, source ids, source codes and source dates are used as main table information to be stored, and then the document information is synchronized to a center personnel file, and the financial approver information is synchronized to the center personnel; supplementing tenant, organization and service type information to construct a reimbursement bill data model entity; finally, calling the dm path to store data for the hawk-dm/client/ext/saveMutiform data interface;
Step S232, constructing a reimbursement bill document, firstly obtaining a service type corresponding to a middle platform system according to a quick report template name, then obtaining reimbursement bill details by using a quick report interface connection information entity and a document id calling path as https:// app.ekuaibao.com/api/openapi/v1/flowDetails, and then calling quick report departments by paging until all departments are obtained, wherein the calling path is https:// app.ekuaibao.com/api/v 1/defaults; and matching the bill approval flow with parameters of a middle financial approver to obtain the bill financial approver id, taking the financial approver id as a parameter calling path to obtain the financial approver information by using an easy-to-report interface of https:// app.
2. The method for normalizing financial data according to claim 1, wherein the data mapping unit is configured to define a data mapping rule, which corresponds the external service system source information data to the standard service management data of the financial data normalizing system in a data mapping manner, so as to unify formats of the external system source data and the standard service management data of the financial data normalizing system; the one-to-one direct establishment of the data mapping relationship is supported, and the many-to-one or one-to-many mapping relationship is supported through SQL logic; the standardized log unit is used for storing information records of the data standardization processing process;
The financial data standardization system further comprises a financial data standardization support system for supporting operation of the financial data standardization system; a management platform system and a technical platform system are arranged in the financial data standardization supporting system, and the management platform system is used for daily operation management of the data standardization system; the management platform system is internally provided with a right management module, a log management module, a task management module, a business management module, a parameter setting module and an accessory management module;
the authority management module comprises functions of user management, role management and data authority management, and the authority management module realizes authority control of a control user access system based on user login authorization, role access control authorization and data authority query data range authorization;
the log management module defines a login log, an operation log, a service log, a task log and an interface log; a system manager checks the reasons of error occurrence and system operation marks through a log management module, and provides basis for analysis of application conditions and operation tracing of the financial data standardized data processing system;
The task management module centrally manages all background automatic task information of the platform, sets task and task execution time, and realizes automatic application of data capture and data processing items according to appointment specifications based on the task management module;
the business process module flexibly sets corresponding approval process strategies aiming at the functional nodes with approval requirements, so that bill approval application is realized;
the parameter setting module is used for defining some control parameter information in the system application operation and task execution process, solving different application requirements of different enterprises and controlling through parameter setting management;
the accessory management function in the accessory management module defines an accessory management path, accessory uploading size limit control and accessory uploading type control.
3. The financial data standardization method according to claim 2, characterized in that a technical platform system is used for providing data storage and transmission functions, and an enterprise-level distributed application service unit, a distributed relational database RD6, a distributed message queue unit, a distributed cache unit, a platform DevOps and a computer and storage platform unit are arranged in the technical platform system; the enterprise-level distributed application service unit is a cloud native PaaS platform for application hosting and micro-service management, provides a full stack type solution for application development, deployment, monitoring and operation and maintenance, and the distributed relational database RD6 is a relational database which is a MySQL database; the distributed message queue unit adopts a message queue middleware RabbitMQ; the distributed cache unit adopts a distributed cache Redis, so that the frequent use of login authorization information and basic files is realized, and the part of data can be quickly used in the service occurrence process; the platform DevOps promotes the development, the technical operation and the communication, the cooperation and the integration among the quality assurance departments, and adopts the gitlab+Jenkins+bash script+docker mirror image server+k8s or docker swarm to automatically pull the mirror image for deployment; the computer and the storage platform unit realize the storage and management of computer information data and store the data in the computer platform.
4. A method of standardizing financial data according to claim 3, wherein the step S4 of pushing document associations downstream comprises the steps of:
s41, inquiring the corresponding standardized logs and grouping; and step S42, finishing the pushing of the downstream bill.
5. The method for normalizing financial data according to claim 4, wherein said step S21 comprises the steps of:
step S211, judging the bill type;
step S212, judging the tenant;
step S213, tissue judgment;
the step S211 of document type determination further includes the following technical contents: the code starts with 'B', and the bill type is a reimbursement bill; the code starts with J, and the bill type is a borrowing bill; the code starts with S, and the bill type is the application form;
step S212, tenant judgment further includes the following technical contents: screening a document with enterprise id of client 1, marking the name of tenant as 'tenant 1', and marking the document as abnormal data if the enterprise id does not exist; checking the tenant name, acquiring the tenant id of the tenant name, and storing the tenant id to an easy-to-report outbound message entity;
the step S213 of organizing the judgment further includes the following technical contents: marking a 'legal name' field in a legal entity in the easy-quick-report outbound message entity as an organization name, carrying out organization verification according to the organization name and a tenant id obtained before, obtaining the organization id under the tenant and the organization name, storing the organization id to the easy-quick-report outbound message entity, and if the organization name is empty, popping up the abnormal 'the name in the legal entity object in the outbound message is empty'.
6. The financial data standardization method according to claim 5, characterized in that in the step S22 of constructing the easy-to-report connection information, the easy-to-report connection information is constructed by constructing the easy-to-report connection information after the analysis is completed, and constructing the easy-to-report connection information object according to the obtained organization id and tenant id, the step S22 specifically includes the following steps:
step S221, acquiring ekb connection configuration of a tenant;
step S222, obtaining an easy-to-report authorization;
step S223, constructing easy-to-report OpenAPI connection information, acquiring ekb connection configuration of a tenant, and acquiring an easy-to-report connection configuration information three-party connection configuration entity in a middle system according to an organization id and the tenant id;
acquiring an easy-to-report authorization, and according to the acquired three-party connection configuration entity, calling a path https of/(app. Ekuaibao. Com/api/openapi/v1/auth/getAccess token to acquire a return result, performing null judgment and verification on a value in the return result, and constructing an easy-to-report authorization entity according to a corresponding relation after verification; step S223 constructs easy-to-report OpenAPI connection information:
and constructing an easy-quick-report interface according to the tenant id, the domain name in the three-party connection configuration entity and the easy-quick-report authorization entity to connect the information entity.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211079015.2A CN115409589B (en) | 2022-09-05 | 2022-09-05 | Financial data standardization system and method thereof |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211079015.2A CN115409589B (en) | 2022-09-05 | 2022-09-05 | Financial data standardization system and method thereof |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115409589A CN115409589A (en) | 2022-11-29 |
| CN115409589B true CN115409589B (en) | 2023-09-12 |
Family
ID=84163160
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211079015.2A Active CN115409589B (en) | 2022-09-05 | 2022-09-05 | Financial data standardization system and method thereof |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115409589B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116644030B (en) * | 2023-07-26 | 2023-10-20 | 北京华科诚信科技股份有限公司 | Electronic filing data processing system and implementation method thereof |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105243582A (en) * | 2015-09-24 | 2016-01-13 | 四川长虹电器股份有限公司 | Financial cloud based XBRL accounting software standard data interface system and method |
| CN113781159A (en) * | 2021-08-23 | 2021-12-10 | 河南宇章信息技术有限公司 | Intelligent finance and tax integrated service platform based on multi-tenant SaaS technology |
| CN114547170A (en) * | 2022-02-18 | 2022-05-27 | 中远海运科技股份有限公司 | Method for standardized extraction and modeling of unstructured financial statement data |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106202536B (en) * | 2016-07-26 | 2019-09-24 | 四川长虹电器股份有限公司 | Global metadata standardized platform system and its construction method based on XBRL |
-
2022
- 2022-09-05 CN CN202211079015.2A patent/CN115409589B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105243582A (en) * | 2015-09-24 | 2016-01-13 | 四川长虹电器股份有限公司 | Financial cloud based XBRL accounting software standard data interface system and method |
| CN113781159A (en) * | 2021-08-23 | 2021-12-10 | 河南宇章信息技术有限公司 | Intelligent finance and tax integrated service platform based on multi-tenant SaaS technology |
| CN114547170A (en) * | 2022-02-18 | 2022-05-27 | 中远海运科技股份有限公司 | Method for standardized extraction and modeling of unstructured financial statement data |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115409589A (en) | 2022-11-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20230377032A1 (en) | System and method for processing transaction records for users | |
| US8924272B2 (en) | System and method for management and verification of invoices | |
| CN112232045B (en) | An automated enterprise accounting management system and its management method | |
| US20080133388A1 (en) | Invoice exception management | |
| US20030088487A1 (en) | Travel expense reimbursement system and method | |
| US20090244600A1 (en) | Billing and remittance payment system | |
| US8645225B1 (en) | Organic supplier enablement based on a business transaction | |
| US20130226798A1 (en) | Methods and systems for automating payments utilizing rules and constraints | |
| US20050222944A1 (en) | System and method for managing the reimbursement of expenses using expense reports | |
| CN114495085B (en) | Reimbursement method for online identification and management of multi-platform invoice | |
| US20040019561A1 (en) | Electronic billing system utilizing a universal billing format data transmission | |
| US20160027124A1 (en) | Thematic Repositories for Transaction Management | |
| CN113362025B (en) | Data accounting system, method, computer-readable storage medium, and electronic device | |
| CN104463418A (en) | A bank settlement account review management system | |
| CN111292012A (en) | Sharing management method, system and system construction method supporting fixed assets | |
| CN113240503A (en) | Reimbursement invoice management method, device and medium based on intelligent equipment | |
| CN115409589B (en) | Financial data standardization system and method thereof | |
| JP4159261B2 (en) | Personal advance expense settlement system, personal advance expense settlement method, program and recording medium | |
| CN112633825A (en) | Enterprise sales promotion cost control system | |
| Ma et al. | RPA Financial Robot Boosts the Digital and Intelligent Transformation of Enterprise Finance | |
| CN111027969A (en) | Method for storing and acquiring electronic document format file template | |
| US7343345B1 (en) | Payment model for an enterprise resource planning system | |
| CN110458632A (en) | It is a kind of to be made out an invoice the automatic invoice issuance system and method for amount based on enterprise | |
| AU2021103954A4 (en) | METHOD FOR SECURE AND AUTOMATIC PAYROLL SYSTEM USING IoT SENSORS WITH TWO FACTOR AUTHENTICATION | |
| CN117172945A (en) | Entry invoice management system and implementation method thereof |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |