CN110046153B

CN110046153B - Account fund checking method, device and equipment

Info

Publication number: CN110046153B
Application number: CN201811374743.XA
Authority: CN
Inventors: 李涛; 孙宇; 王文翰; 陈春焘; 陈红伟; 武巍
Original assignee: Advanced New Technologies Co Ltd
Current assignee: Advanced New Technologies Co Ltd; Advantageous New Technologies Co Ltd
Priority date: 2018-11-19
Filing date: 2018-11-19
Publication date: 2023-09-05
Anticipated expiration: 2038-11-19
Also published as: CN110046153A

Abstract

The specification provides a method, a device and equipment for checking account funds. The method comprises the following steps: generating a configuration interface so that a user configures query conditions in the configuration interface according to the business for checking account funds, wherein the query conditions are used for describing each business node contained in the business for checking account funds and the association relation between the business nodes; mapping the service nodes into models according to inquiry conditions configured by users, and mapping association relations between the service nodes into association relations between the models; and generating the SQL script of the business for checking the account funds according to the models and the association relation between the models so as to check the account funds. Through the interactive design of the user interface, the logic between the business nodes of the checking business is clearer and more visual, the SQL script is automatically generated, manual writing is not needed, account fund checking is simpler and more convenient, and the checking script is more standard.

Description

Account fund checking method, device and equipment

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method, an apparatus, and a device for checking account funds.

Background

Banks, businesses, and some third party platforms, etc. all need to check funds transferred daily, for example, a payment bank has thousands of business transition users, the number of funds transferred and balance daily is up to trillion, and it is important to check the amount and balance of these transition users occurring daily. Because the number of the accounts is more, the business and fund flows of the accounts are very complex, at present, when checking the business and fund flows of the accounts, some technologies are difficult to understand and maintain, each person writes a checking script, the checking script is difficult to be standardized, and the quality of the checked content is also difficult to control.

Disclosure of Invention

In order to overcome the problems in the related art, the present specification provides a method, an apparatus and a device for checking account funds.

First, the present specification provides a method of account funds reconciliation, the method comprising:

generating a configuration interface so that a user configures query conditions in the configuration interface according to the business for checking account funds, wherein the query conditions are used for describing each business node contained in the business for checking account funds and the association relation between the business nodes;

mapping the service nodes into models according to inquiry conditions configured by users, and mapping association relations between the service nodes into association relations between the models;

generating an SQL script of the business for checking account funds according to the models and the association relation between the models;

checking the account funds through the SQL script of the business for checking the account funds.

Next, the present specification provides an apparatus for account funds reconciliation, the apparatus comprising:

the configuration module is used for generating a configuration interface so that a user configures query conditions in the configuration interface according to the business for checking account funds, wherein the query conditions are used for describing each business node contained in the business for checking account funds and the association relation between the business nodes;

the mapping module maps the service nodes into models according to query conditions configured by users, and maps the association relations between the service nodes into association relations between the models;

the script generation module is used for generating the SQL script of the business for checking account funds according to the models and the association relation between the models;

and the checking module checks the account funds through the SQL script of the business for checking the account funds.

Further, the present application provides an apparatus for reconciling account funds, the apparatus comprising:

a memory for storing executable computer instructions;

a processor for implementing the following steps when executing the computer instructions:

generating SQL scripts of the business for checking account funds according to the models and the association relations between the models;

The application has the beneficial effects that: mapping each service node of the service for checking account funds into a model and mapping the association relation between the service nodes into the association relation between the models according to the query condition configured by the user on the configuration interface, and then generating an SQL script for checking the service for checking account funds according to the association relation between the models. Through the user interface interaction design, the logic among the service nodes of the service for checking account funds is clearer and more visual, and the SQL check script is automatically generated without manual writing, so that the account funds are simpler and more convenient to check, and the check script is more standard.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application as claimed.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the application and together with the description, serve to explain the principles of the application.

FIG. 1 is a flow chart of a method of account funds verification as shown in an exemplary embodiment of the present description;

FIG. 2 is a schematic diagram of query conditions configured via a configuration interface according to an exemplary embodiment of the present disclosure;

FIG. 3 is an edit interface of a service node in a configuration interface according to an exemplary embodiment of the present disclosure;

fig. 4 is a selection interface of a service node association relationship in a configuration interface according to an exemplary embodiment of the present disclosure;

FIG. 5 is a diagram illustrating a mapping result of a service node to a model according to an exemplary embodiment of the present disclosure;

FIG. 6 is a verification anomaly data output interface shown in an exemplary embodiment of the present specification;

FIG. 7 is a block diagram illustrating the structural logic of an account funds checking apparatus according to an exemplary embodiment of the present disclosure;

fig. 8 is a block diagram showing the structural logic of an account funds checking apparatus according to an exemplary embodiment of the present specification.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations consistent with the application. Rather, they are merely examples of apparatus and methods consistent with aspects of the application as detailed in the accompanying claims.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any or all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used herein to describe various information, these information should not be limited by these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the application. The word "if" as used herein may be interpreted as "at … …" or "at … …" or "responsive to a determination", depending on the context.

Banks, businesses, and some third party platforms, etc. all need to check funds transferred daily, for example, a payment bank has thousands of business transition users, the number of funds transferred and balance daily is up to trillion, and it is important to check the amount and balance of these transition users occurring daily. Because the number of accounts is large, the business in and out and the fund flow of the accounts are very complex, at present, when account fund checking is carried out, SQL language is mostly adopted as a tool, business data of the account fund is taken as input, and data with risks are filtered out through SQL query sentences. In short, the process of checking is the process of assembling the target model and filtering the problem data with risks in the process, and the most important process is the assembly of the target model; the prior method is to write SQL manually, and construct a wide table of target Data of the specific account fund service Data for checking and screening step by utilizing join and unit of SQL in combination with sphere filtering according to the table structure of the account fund service Data table and the association relation between the Data tables. However, this method of manually writing SQL script verification is difficult to understand and maintain, and each verifier writes the verification script by himself, so that it is difficult to standardize the verification script, and the quality of the verification content is not well controlled.

In order to solve the above problems, the present disclosure provides a method for checking account funds, which combines interface configuration with SQL checking script, so that checking account funds is more intuitive and simpler, and the specific process is as shown in fig. 1, and includes steps S102-S108:

s102, generating a configuration interface so that a user configures query conditions in the configuration interface according to the business for checking account funds, wherein the query conditions are used for describing each business node contained in the business for checking account funds and the association relation between the business nodes;

s104, mapping the service nodes into models according to query conditions configured by users, and mapping association relations between the service nodes into association relations between the models;

s106, generating the SQL script of the business for checking account funds according to the models and the association relation between the models;

s108, checking the account funds through the SQL script of the business for checking the account funds.

The SQL is a structured query language, is a language tool commonly used in account fund checking, and is a process of querying a business data table of account fund through the SQL query language and filtering and screening data with risks and problems from the business data table, and before the SQL is screened, query conditions are required to be configured so that the SQL screens out the data with problems according to the query conditions. In order to make the user to configure the query condition more clearly and intuitively when checking account funds, the checking method provided by the specification can be realized based on interface configuration, the system can generate a configuration interface after the user enters the checking system, the user can configure the query condition according to the service of checking account funds in the configuration interface, and the query condition configured by the user can be used for describing each service node contained in the service of checking account funds and the association relation between the service nodes. For example, the query condition configured by the user may be represented in the form of a node diagram, the entire node diagram represents the service for checking account funds, each node in the node diagram represents each service node included in the service for checking account funds, and the nodes are connected through a certain association relationship. Fig. 2 shows that the fund of a payment treasured packet service of a certain account is determined by the fund flows of a sending packet 21, a receiving packet 22 and a returning packet 23 according to the inquiry conditions of the payment treasured packet service configuration, so that the packet service comprises three service nodes of the sending packet 21, the receiving packet 22 and the returning packet 23, wherein the data of the service node for returning the packet can be obtained by performing a Join operation on a money transfer fund table and a money transfer base table, and the money transfer fund table 24 and the base table 25 are two service child nodes. And the association between two service nodes in the node diagram can be used for clearly describing the relationship of each service node by marking the association relationship between the two service nodes on the connection line of the two service nodes in the node diagram. For example, a Join operation is required between the transfer fund table and the transfer base table to obtain the redback packet data, so that the association relationship between them is the Inner Join. The data of the red packet service needs to perform a Union all operation on the data of the three service nodes for sending, receiving and receiving the red packet, so that the association relationship between the data is Union all. Of course, the node diagram is only one expression of configuring the query condition in the specification, and the user can also combine the options to configure the final query condition by selecting the configuration options in the interface, which is not limited in the specification.

In one embodiment, a user may configure query conditions in a configuration interface, such as adding service nodes, deleting service nodes, editing service nodes, and/or selecting associations between service nodes. As shown in fig. 2, there are some control icons in the configuration interface, such as an add service node control icon 26, a delete service node control icon 27, an edit service node control icon 28, and a service node association relation selection control icon 29, after clicking these icons, corresponding operations can be performed, for example, a user can perform operations of adding a service node by clicking the add service node control icon 26, add three service nodes "send a packet, get a red packet, and drop a red packet" in a red packet service, and of course, delete a certain service node by deleting the service node control icon 27, and edit some fields of the service cleaning by clicking the edit service node 28. Fig. 3 is an editing interface of the service node "get red packet", through which a user can input and wash out some required fields such as biz_id (service id), actual_current (amount), direction (funds inflow and outflow direction), and biz_time (service occurrence time) corresponding to the service. The association relationship between the service nodes can be selected by clicking the service node association relationship selection control icon 29 in the configuration interface. After clicking on the service node association selection control icon 29, an interface as shown in fig. 4 appears, and the association between the service nodes that can be selected is displayed to the user, so that the user can select according to the relationship between the service nodes.

When the query condition is configured, the association relation among the service nodes corresponds to the connection statement in the SQL. In one embodiment, the association between service nodes includes a lateral connection and a longitudinal connection. When the SQL check script is generated, the service nodes can be mapped into the models, the association relation between the service nodes is mapped into the association relation between the models, and the models can be a data table predefined according to the service nodes, so that the association relation between the models obtained by mapping the association relation between the service nodes, namely the relationship between the data tables. In the SQL language, multiple data tables can be combined through transverse connection and longitudinal connection to obtain final data.

In some embodiments the transverse connection comprises: left outer join (Left outer join), right outer join (Right outer join), full outer join (Full outer join), and/or equal value join (inner join). These associations may correspond to join statements in SQL, all of which represent some operations performed on the data table. In SQL, the result set for Left outer join (Left outer join) includes all rows of the Left table specified in the Left outer clause, not just the rows to which the join columns match, and if a row of the Left table does not match a row in the right table, then all select list columns of the right table in the associated result set row are null. The Right outer join (Right outer join) is the reverse of the left outer join, with the result set including all rows returning the Right table. If a row of the right table does not match a row in the left table, a null value is returned for the left table. The result set of the Full outer join (Full outer join) includes returning all rows in the left and right tables, and when a row does not match a row in another table, the select list column of the other table contains a null value, and if there is a matching row between tables, the row of the entire result set contains the data value of the base table. An equivalence join (inner join) refers to matching rows in two tables according to the value of a column common to each table using a comparison operator, e.g., retrieving all rows in the students and the names tables that have the same student identification number.

In some examples, the longitudinal connections between service nodes include: union all and/or Union. Also, these associations may correspond to join statements in SQL, representing some operations and operations performed on the data table. In SQL language, the abnormal data is queried and filtered mainly through a selection target column, a from query target (the target can be a table or a sub-query nest) and a sphere filtering condition. If we need to display the results of two select statements as a whole we need to use Union or Union all operations, where Union refers to the Union of two result sets, excluding duplicate rows, while ordering the default rules. Union all refers to performing Union operation on two result sets, including repeating rows without ordering; for example, the final checking result of the red packet service is that the checking results of sending packets, receiving red packets and returning red packets of all service points are required to be integrated and displayed as a whole, so that a Union operation, i.e. Union or Union all operation, is required to be performed on three service nodes.

In the service node of the red packet, two service sub-nodes including a fund list and a basic list need to be subjected to a join operation to obtain the final data of the service node of the red packet, so that the relationship between the two service sub-nodes of the fund list and the basic list is Inner join. Similarly, the data of the red packet service needs to be subjected to Union all operation by three service nodes of sending, receiving and returning the red packet, so that the association relationship among the three service nodes of sending, receiving and returning the red packet is Union all. By the operation among the two-dimensional tables, all service nodes of the service for checking account funds can be spliced and combined to obtain the final service for checking account funds. Thus, a complex check service can be decomposed into simple service nodes step by step, and the service nodes are spliced together according to service logic after being processed.

After the user configures the query conditions, the service nodes are mapped into models according to the query conditions configured by the user, and then the association relations between the service nodes are mapped into association relations between the models. The model is a set of models which can be shared and are used for abstracting different types of accounts, and the model can be a data table which contains information needed by checking the business. For example, an account may contain a lot of information including account attributes, amounts, directions of inflow and outflow of funds, account numbers, time of occurrence of business, business-accounting association, etc., some information that must be contained to check account funds may be extracted, some unnecessary information such as account attributes may be discarded, and then a model that is universally applicable to all accounts may be defined.

In one embodiment, the model includes fields for screening query results for service nodes. For example, when checking some account data, the content to be checked contains information such as money amount, account number, etc., and the model may contain fields of query results of the screening service nodes. In one embodiment, the fields of the query result of the screening service node may include: account, amount, inflow and outflow direction of funds, service-account association, service identification and/or service occurrence time. These fields are all the fields that must be used by a certain service node in checking, and by querying these fields, abnormal data can be filtered out.

Because the fields in the model are predefined, but how each account obtains the fields are different, for example, the service and accounting related fields of different accounts are different, some splicing or processing may be required to obtain the information, for example, the field is also the amount, the field identifying the amount in the account a is the account, and the field in the account B is the trans_account, so that in order to unify the information of each account with the field in the model, the user can configure the information in the configuration interface, and then map each service node into the model according to the information configured by the user. Fig. 5 is a schematic diagram of mapping results mapped into a model after the user configures the query condition for each service node. By mapping the information in the account to fields in the model, one-to-one correspondence is made.

After mapping each service node into a model, the service nodes can be mapped into association relations between the models according to the relations between the service nodes, the association relations between the service nodes are selected by a user according to the association between the service nodes when the query condition is configured, and the association relations between the service nodes, namely the association relations between the models, correspond to the connection sentences in the SQL. Because the model is a data table of service data of the corresponding service node, after mapping the association relation of the service node to the model, namely, the operation relation among the data tables, for example, in a red packet service, the red packet service comprises three service nodes of sending red packets, receiving red packets and returning red packets, the association relation among the three service nodes is Union all, after mapping the three service nodes to the model, three data tables, namely, the service data table of sending red packets, the service data table of receiving red packets and the service data table of returning red packets, are obtained, and after mapping the association relation among the nodes to the association relation among the models, the association relation among the three data tables is Union all, namely, union all operation is needed to be carried out on the three data tables, so that the data of the whole red packet service is obtained.

After the service nodes are mapped into the models and the association relations between the service nodes are mapped into the association relations between the models, a check service SQL script can be automatically generated according to the models and the association relations between the models, and then account funds are checked through the check service SQL script.

SQL is a structured query language, all of whose operations can be abstracted into filtering a row of data tables and computation from table to table. The SQL check script of a check service often has the characteristics of layering, nesting and association, and can better abstract the check script corresponding to each service node in the check service and the association between the check script and each service node. That is, the SQL check script of a check service can be obtained by splicing and combining the check scripts of all service nodes in the check service through a certain association relationship. Therefore, in order to generate the SQL check script of the final whole check service, the script of each service node in the check service can be generated first, and then spliced into the SQL script of the final check service. In one embodiment, a service node SQL script can be generated according to the models, and then the service node SQL scripts are automatically spliced together according to the association relation between the models to generate a check service SQL check script for checking account funds.

After the check service SQL check script is automatically generated, the execution efficiency difference is caused by the factors such as the placement position of the sub-query of SQL or the screening condition, the sequence of the screening condition and the like, so that the check speed is further accelerated, the account fund check efficiency is improved, and the SQL script of the service for checking the account fund can be further optimized. In one embodiment, since the screening fields included in the model are extracted from various types of accounts, and are applicable to all accounts, these fields may be relatively few, and the generated script requires a wide range of queries during verification, which is relatively inefficient. Therefore, the time for checking the account funds by the SQL script of the business for checking the account funds can be shortened by adding some preset fields in the SQL script, for example, a field of accounting occurrence time or a series of fields such as a field of last modification time of a record can be added to limit the checking scope, so that the time for running the script to check the account funds is shortened. For example, the collation range may be limited to business data at an account occurrence time of 8:00 to 12:00, or only business data after a modification time of 12:00 may be collated according to actual collation requirements. After a preset rule is added according to actual requirements to limit the checking range, the checking efficiency can be greatly improved.

In one embodiment, in order to improve the checking efficiency of the script, after the SQL checking script for checking the business of the account funds is generated according to the association relation between the models, a mapjoin function may be added in the SQL checking script for checking the business of the account funds, the mapjoin may read all the small tables into the memory, and the data of another table and the table data in the memory are directly taken for matching in the map stage, because the join operation is performed in the map, the reduce operation is omitted, and the efficiency is also much higher. In addition, mapjoin has the great advantage of being able to perform join operations that are not equal, if the unequal conditions are written in where, then the mapreduce process will perform Cartesian products, and the efficiency of operation will be particularly low, if mapjoin operations are used, then join operations of different values will be completed in the map process, and the efficiency will be much higher.

Because the user can use the copy-paste function when configuring the query condition in the configuration interface, the system can actively identify the repeated configuration condition when configuring the query condition, record the multiplexed part, and when the SQL script for checking the business of the account funds checks the account funds, the system can create a temporary offline table to store the recorded query results of the repeated sub-queries, so that the stored query results are directly called as the query results of the same sub-queries when the same sub-queries are encountered next time. Thus, the efficiency of script verification can be greatly improved.

In one embodiment, the transactions requiring account funds to be reconciled include a transaction for a statement reconciliation, and/or a transaction for a balance reconciliation. In general, checking account funds includes three parts, the first part is to perform statement checking, by configuring query conditions on a configuration interface, mapping services and accounts in the query conditions into service models and account models, and mapping association relations between the services and the accounts into association relations between the models, an SQL check script can be automatically generated to perform statement checking on the amount of the services and the accounts and the inflow and outflow directions of each inflow and outflow. And the second part is to collect the amount and check the transaction in the same direction in one day through the configured service model and association relation of query condition mapping, and the collected amount is checked with the daily cut occurrence amount on the account. The third part is balance check, and through the expression of how to clean the status of not rotating in the user configuration inquiry condition, the whole amount table can be used for cleaning all the historical amounts of not rotating of the account, and the balance check is performed with the balance of the account table.

Since some abnormal data often appear in the checking process, the user needs to be prompted that the abnormal data exist and output the data. In one embodiment, after account funds are checked by the generated check service SQL check script, abnormal data in the check process is required to be output to the user interface according to a preset format, the output format of the abnormal data can be specifically set based on the check service, different check service departments adopt different output formats, for example, the information of the abnormal data which is finally required to be output by the generation of the statement detail check service, the generation of the statement summary check service and the balance check service may be different, so that the abnormal data can be specifically set according to actual requirements.

To further explain the method of account funds reconciliation in this description, a specific embodiment is further described below.

The payment treasures are more and more popular, and users of the payment treasures are more and more frequently used, and the daily circulation and balance fund number of the payment treasures are more, so that the payment treasures red package service is also very important for the generation amount detail, the generation amount summarization and the balance verification of the red package service. In order to make the user more intuitive and convenient when checking account funds, a configuration interface can be provided for the user when checking account funds, as shown in fig. 2, the configuration interface comprises different control icons, such as an added node control icon 26, a deleted node control icon 27, an edited node icon 28 and a node association relation selection icon 29, by clicking these icons, the user configures query conditions according to the specific checking flow of the red packet service at the configuration interface, the query conditions configured by the user can be represented in a node diagram form, and the association relation of each service node and each service node included in the red packet service is represented by the node diagram. Since the red packet service includes three parts of the red packet sending 21, the red packet receiving 22 and the red packet returning 23, namely three service nodes, the service node can be added in the configuration interface diagram, and the three services of the red packet sending, the red packet receiving and the red packet returning may further include sub-services, namely, the three service nodes can be further refined and clearly described by adding the service sub-nodes and the association relation of the sub-nodes, for example, the red packet returning service 23 node includes the service sub-node transfer fund table 24 and the transfer basic table 25. After the nodes are added, the nodes can be edited, and some necessary information for checking the business needs is input according to the options of the configuration interface. The association relationship between the nodes can be selected by clicking the node association relationship selection control icon 29 in the interface, the association relationship between the nodes corresponds to a connection sentence in the SQL, and the connection sentence comprises a transverse connection and a longitudinal connection, wherein the transverse connection comprises four relationships, namely, a Left outer join (Left outer join), a Right outer join (Right outer join), a Full outer join (Full outer join) and/or an equivalent join (inner join), and the longitudinal connection comprises two connection relationships, namely: union all and/or Union. The association relationship among the three service nodes for sending the red packet, receiving the red packet and returning the red packet is Union all, so that Union all is selected during selection, and the association relationship of the service sub-nodes in the three service nodes can be selected according to actual conditions. After the node diagram of the Payment treasured red packet service is configured, the system maps each node into a model according to the node diagram, maps the relation between the nodes into the relation of the model, such as the red packet service node into a red packet service model, and the red packet service node into a red packet service model. The service models are a predefined data table, the data table contains fields required by the service node screening query result, for example, fields required to be included in the service node screening query result, such as biz_id (service id), actual_current (amount), direction (funds inflow and outflow direction), and biz_time (service occurrence time), and the data table needs to include the fields. When configuring the node diagram, the user can input the information of the fields, then the system maps the information input by the user into the models, and the association relationship between the models is the association relationship between the nodes, and the connection and the statement in the SQL are corresponding. If the association relationship between two service nodes of sending and receiving red packets is Union all, namely the association relationship of the models of the two service nodes is Union all, the method means that a Union all operation is required to be carried out on the data table of the models of the two service nodes to obtain the data of the red packet service. After the association relation between the model and the model is obtained, the system automatically generates the SQL script for checking the red packet sending service according to the red packet sending service model, and then splices the SQL script for checking the red packet sending service, the SQL script for checking the red packet sending service and the SQL script for checking the red packet sending service according to the association relation of three service nodes to obtain the final SQL script for checking the red packet sending service. After the SQL script of the core-to-red packet service is generated, a plurality of screening fields are added into the script according to the actual checking requirement, for example, only the accounting occurrence time is required to be checked to be 8:00-12:00, a check accounting occurrence time field can be added. Therefore, the verification time of the SQL script can be shortened, and the verification efficiency is improved. As shown in fig. 6, in the verification process, if abnormal data occurs, the abnormal data is output according to a certain format and displayed in a user interface to remind the user of the occurrence of the abnormal data. By the method, a user can more clearly and intuitively configure query conditions according to the check service assistance, and the expansion and folding of service nodes can be realized by combining with the user interface interaction design, so that the user is helped to better think about service association logic and the like from different levels and dimensions, the check script is automatically generated, manual writing is not needed, the standardization of the check script is ensured, and the check work is more convenient and faster.

Corresponding to the embodiment of the checking method in the specification, the specification also provides an account fund checking device. As shown in fig. 7, the apparatus 700 includes:

the configuration module 701 generates a configuration interface so that a user configures a query condition in the configuration interface according to a service for checking account funds, wherein the query condition is used for describing each service node contained in the service for checking account funds and an association relationship between the service nodes;

the mapping module 702 maps the service nodes into models according to query conditions configured by users, and maps association relations between the service nodes into association relations between the models;

a script generation module 703, configured to generate an SQL script of the service for checking account funds according to the model and the association relationship between the models;

and a checking module 704, checking the account funds through the SQL script of the business for checking the account funds.

In one embodiment, configuring the query conditions in the configuration interface includes the operations of: adding service nodes, deleting service nodes, editing service nodes and/or selecting association relations between service nodes.

In one embodiment, the association between the service nodes includes a lateral connection and a longitudinal connection.

In one embodiment, the lateral connection comprises: left external connection, right external connection, all external connection and/or equivalent connection.

In one embodiment, the longitudinal connection comprises: union and/or Union all.

In one embodiment, the model includes a field for the results of the screening queries for the service node.

In one embodiment, the field includes: account, amount, direction of funds inflow and outflow, service identity, service-accounting association, and/or service occurrence time.

In one embodiment, the business of checking account funds includes: a credit statement check service, a credit summary check service and/or a balance check service.

In one embodiment, the SQL script for generating the business for checking account funds according to the models and the association relation between the models specifically comprises:

generating SQL scripts for checking the business of the business node according to the model;

splicing SQL scripts of the business of the check business node according to the association relation between the models to generate SQL scripts of the check business of the check account funds;

in one embodiment, the method further comprises outputting the data of the collation abnormality in a preset format, the preset format being based on the collation service setting.

In one embodiment, after generating the collation service SQL collation script according to the association relation between the models, it further comprises:

and adding a preset screening field in the check service SQL check script.

In one embodiment, after generating the SQL verification script for verifying the business of account funds according to the model and the association relation between the models, the method further comprises:

and adding a mapjoin function in the SQL check script of the business for checking account funds.

In one embodiment, checking the account funds by the SQL script of the business that checks the account funds comprises:

creating a temporary offline table to store the query results of the sub-queries;

and using the query result as the query result of the same sub-query.

The implementation process of the functions and roles of each unit in the above device is specifically shown in the implementation process of the corresponding steps in the above method, and will not be described herein again.

For the device embodiments, reference is made to the description of the method embodiments for the relevant points, since they essentially correspond to the method embodiments. The apparatus embodiments described above are merely illustrative, wherein the elements illustrated as separate elements may or may not be physically separate, and the elements shown as elements may or may not be physical elements, may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purposes of the present application. Those of ordinary skill in the art will understand and implement the present application without undue burden.

In addition, the application also provides a device, as shown in fig. 8, the device 800 can be used for account fund checking, including:

a memory 801 for storing executable computer instructions;

a processor 802 for implementing the following steps in executing the computer instructions:

Since part of the application contributing to the prior art or all or part of the technical solution may be embodied in the form of a software product stored in a storage medium comprising several instructions for causing a terminal device to perform all or part of the steps of the method of the various embodiments of the application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The foregoing description of the preferred embodiments of the application is not intended to be limiting, but rather to enable any modification, equivalent replacement, improvement or the like to be made within the spirit and principles of the application.

Claims

1. A method of account funds reconciliation, the method comprising:

mapping the service nodes into models according to inquiry conditions configured by users, and mapping association relations between the service nodes into association relations between the models, wherein the models comprise information needed when account funds are checked for different types of accounts;

2. An account funds checking method as claimed in claim 1, configuring the inquiry conditions in the configuration interface comprising the operations of: adding service nodes, deleting service nodes, editing service nodes and/or selecting association relations between service nodes.

3. An account funds checking method as claimed in claim 1, wherein the association between the service nodes comprises a lateral connection and a longitudinal connection.

4. A method of account funds checking as claimed in claim 3, the lateral connection comprising: left external connection, right external connection, all external connection and/or equivalent connection.

5. A method of account funds checking as claimed in claim 3, the longitudinal connection comprising: union and/or Union all.

6. An account funds checking method as claimed in claim 1, the model comprising fields of query results of screening service nodes.

7. An account funds checking method as claimed in claim 6, said fields comprising: account, amount, direction of inflow and outflow of funds, service identity, and/or time of service occurrence.

8. An account funds checking method as claimed in claim 1, the business of checking account funds comprising: a credit statement check service, a credit summary check service and/or a balance check service.

9. The account funds checking method as claimed in claim 1, wherein the generating the SQL script of the business for checking account funds according to the model and the association relation between the models comprises:

and splicing the SQL scripts of the business of the check business node according to the association relation between the models so as to generate the SQL scripts of the business of checking account funds.

10. An account funds reconciliation method as defined in claim 1, further comprising outputting the reconciliation anomaly data in a predetermined format.

11. The account funds checking method of claim 1, further comprising, after generating the SQL check script for checking the business of account funds according to the model and the association relationship between models:

and adding a field of a preset screening query result in the SQL check script of the business for checking account funds.

12. The account funds checking method of claim 1, further comprising, after generating the SQL check script for checking the business of account funds according to the model and the association relationship between models:

13. An account funds checking method as claimed in claim 1, checking the account funds by SQL script of the business of checking account funds comprising:

and using the query result as the query result of the same sub-query.

14. An account funds checking apparatus, comprising:

the mapping module maps the service nodes into models according to inquiry conditions configured by users and maps the association relations between the service nodes into association relations between the models, wherein the models comprise information needed when account funds are checked for different types of accounts;

15. An apparatus, the apparatus comprising:

a memory for storing executable computer instructions;

a processor for carrying out the steps of the method of any one of claims 1 to 13 when said computer instructions are executed.