CN115345740A

CN115345740A - Account checking method, account checking device, account checking equipment, account checking storage medium and program product

Info

Publication number: CN115345740A
Application number: CN202210965977.1A
Authority: CN
Inventors: 赵马沙
Original assignee: Guangzhou Wangxing Information Technology Co Ltd
Current assignee: Guangzhou Wangxing Information Technology Co Ltd
Priority date: 2022-08-12
Filing date: 2022-08-12
Publication date: 2022-11-15

Abstract

The application discloses a reconciliation method, a reconciliation device, equipment, a storage medium and a program product, which are applied to a reconciliation system, wherein the method comprises the following steps: the method comprises the steps of obtaining a reconciliation data table, wherein one or more business flow records of one or more business events are recorded in the reconciliation data table, and the business flow records comprise business event identifications and financial operation information; respectively performing bill reconciliation processing on the business flow records based on the business event identification and the financial operation information of each business flow record; determining a check rule corresponding to each business event; and checking whether the business process of the business event is complete or not by adopting the checking rule of the business event according to the checking result obtained after the bill checking treatment is carried out on the business flow record of each business event, so that the enabling of the checking system is realized, the abnormal detection capability of the checking system is improved, the abnormality in the checking process is found in time, and the checking accuracy is improved.

Description

Account checking method, account checking device, account checking equipment, account checking storage medium and program product

Technical Field

The present application relates to the field of data processing technologies, and in particular, to an account checking method, an account checking device, an account checking apparatus, a computer-readable storage medium, and a computer program product.

Background

With the development of internet technology, financial services are also developed. When the financial transaction involves payment, then there is a reconciliation requirement. The reconciliation is an important link of a payment system, and can ensure the safety of the transaction process and the payment.

In the related art, there are two schemes for account checking: the first scheme is offline reconciliation, namely after all the reconciliation participants (such as transaction systems, financial systems, fund systems and other systems) are completely checked out and closed, generating offline billing data, extracting files or data from all the participants by the reconciliation system, and performing reconciliation according to reconciliation logic; and the second scheme is real-time reconciliation, namely when each reconciliation participant generates the data to be reconciled, the reconciliation system performs data polling according to the real-time billing data of one or more parties until the reconciliation data of all the participants are acquired and then is uniformly reconciled.

However, for some businesses, if multiple interactions involving participants, it is not normal to represent the entire business if the reconciliation data for all participants are consistent. For example, in a red packet service, a red packet activity may include three processes of red packet sending, red packet robbing, and balance recovery, where each process corresponds to one accounting operation (an accounting system generates a corresponding accounting flow), and a red packet service system also generates a corresponding service flow. The related art performs bill reconciliation on business flow and accounting flow when performing reconciliation (generally in an offline batch form, and the perception is delayed when problems occur). However, the bill reconciliation is not abnormal, which does not mean that the red packet service is not abnormal, for example, the bill reconciliation in the two flows of red packet sending and red packet robbing is normal, but the balance recovery is not executed (for example, the balance recovery fails), which results in that the accounting system does not have an accounting flow related to the balance recovery, and the red packet service system also does not have a service flow related to the balance recovery.

Disclosure of Invention

The application provides a reconciliation method, a reconciliation device, equipment, a storage medium and a program product, which aim to solve the problem that the conventional reconciliation mode has normal bill reconciliation but is difficult to detect the abnormity of a business layer.

According to an aspect of the present application, there is provided a reconciliation method applied in a reconciliation system, the method including:

the method comprises the steps of obtaining a reconciliation data table, wherein one or more business flow records of one or more business events are recorded in the reconciliation data table, and the business flow records comprise business event identifications and financial operation information;

respectively performing bill reconciliation treatment on the business flow records based on the business event identifications and the account operation information of the business flow records;

determining a check rule corresponding to each business event;

and according to the account checking result obtained after the bill account checking processing is carried out on the business flow record of each business event, checking whether the business flow of the business event is complete or not by adopting the checking rule of the business event.

According to another aspect of the present application, there is provided a reconciliation apparatus provided in a reconciliation system, the apparatus comprising:

the account checking data table acquiring unit is used for acquiring an account checking data table, wherein one or more business flow records of one or more business events are recorded in the account checking data table, and the business flow records comprise business event identifications and account operation information;

the bill reconciliation processing unit is used for respectively carrying out bill reconciliation processing on the business flow records based on the business event identification and the financial operation information of each business flow record;

the check rule determining unit is used for determining a check rule corresponding to each service event;

and the integrity checking unit is used for checking whether the service flow of each service event is complete or not by adopting the checking rule of the service event according to the checking result obtained after the bill checking is carried out on the service flow record of each service event.

According to another aspect of the present application, there is provided a reconciliation apparatus comprising:

at least one processor; and

a memory communicatively coupled to the at least one processor; wherein the content of the first and second substances,

the memory stores a computer program executable by the at least one processor, the computer program being executable by the at least one processor to enable the at least one processor to perform the method of any of the embodiments of the application.

According to yet another aspect of the present application, there is provided a computer-readable storage medium having stored thereon computer instructions for causing a processor to perform the method according to any one of the embodiments of the present application when executed.

According to yet another aspect of the present application, there is provided a computer program product comprising computer executable instructions for implementing the method of any of the embodiments of the present application when executed.

In this embodiment, the reconciliation of the reconciliation system depends on a reconciliation data table, in which one or more business flow records of one or more business events are recorded. When the account checking is carried out, the account checking system can obtain the check rule of the business event and carry out integrity check on the business event by adopting the check rule and the account checking result of the bill account checking of the business flow record except that the business flow record is subjected to conventional bill account checking operation, so as to check whether the business event has a complete business flow, realize the enabling of the account checking system, improve the abnormal detection capability of the account checking system, discover the abnormality in the account checking process in time and further improve the accuracy of the account checking.

Furthermore, since the integrity check of the service is realized by the reconciliation system, the workload of the service system can be reduced, so that the service system can concentrate on the realization of the service logic of the service system, and the service processing capacity of the service system is further improved.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings required to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the description below are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings without creative efforts.

Fig. 1 is a flowchart of an account reconciliation method according to an embodiment of the present application;

fig. 2 is a schematic structural diagram of an account reconciliation system according to an embodiment of the present application;

fig. 3 is a flowchart of an account checking method provided in the second embodiment of the present application;

fig. 4 is a flowchart of a method for performing integrity check on a service event of a non-complex service according to a second embodiment of the present application;

fig. 5 is a flowchart of a method for integrity checking a service event of a complex service according to a second embodiment of the present application;

fig. 6 is a flowchart of an account reconciliation method provided in the third embodiment of the present application;

fig. 7 is a schematic structural diagram of an account checking device according to a fourth embodiment of the present application;

fig. 8 is a schematic structural diagram of a reconciliation device for implementing a reconciliation method in an embodiment of the present application.

Detailed Description

In order to make the technical solutions of the present application better understood by those skilled in the art, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only some embodiments of the present application, and not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

It should be noted that the terms "first," "second," and the like in the description and claims of this application and in the drawings described above are used for distinguishing between similar elements and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used is interchangeable under appropriate circumstances such that the embodiments of the application described herein are capable of operation in sequences other than those illustrated or described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed, but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

Example one

Fig. 1 is a flowchart of an account checking method according to an embodiment of the present application, which may be applied to an account checking system. In practice, the reconciliation system may be connected to an upstream business system and a downstream accounting system, where the business system is a processing system for executing business logic, the accounting system is a system for processing accounting flow, and the reconciliation system is a system for reconciling bills of the business system and the accounting system. For example, in a live broadcast scenario, the business system may be a live broadcast platform, the accounting system may be a system that performs accounting processing on an event that has an accounting flow condition, such as a red envelope and a gift, in a live broadcast process, and the accounting system is a system that performs accounting on business flow of the live broadcast platform and accounting flow of the accounting system.

As shown in fig. 1, the present embodiment may include the following steps:

step 101, an account checking data table is obtained, wherein one or more business flow records of one or more business events are recorded in the account checking data table, and the business flow records comprise business event identifications and financial operation information.

When the method is implemented, the reconciliation data table can be a reconciliation data table of the target service. The target service comprises one or more service events. The target business can be a business with account checking requirements in a business system, such as a red packet business, a selling business, a gift sending business, a game business and the like, and the business can have a currency operation, so that a currency circulation condition that the currency of an account is increased and the currency of the account is reduced exists. The service event refers to a service flow in which the target service is concurrently executed in the same period, for example, if the target service is a red packet service, the service event may include a red packet 1 event, a red packet 2 event, and the like. Each service event may be represented by a service event identification, for example, the identification of a red packet 1 event is a red packet ID 1.

In one implementation, as shown in the schematic architecture diagram of the reconciliation system in fig. 2, the reconciliation system may include a task scheduling module, and the task scheduling module may schedule and schedule the reconciliation task in a pipeline scheduling mode, so as to ensure the real-time performance of the reconciliation. The reconciliation system can obtain a reconciliation task from the task scheduling module and determine a target service and a corresponding service event according to a service identifier and a service event identifier carried in the reconciliation task. The reconciliation task may be issued by the business system, may also be issued by the accounting system, or may be generated based on a set reconciliation trigger logic, which is not limited in this embodiment.

When the target business is determined, the reconciliation system can acquire a reconciliation data table associated with the target business, wherein the reconciliation data table is an intermediate data table used for recording reconciliation data, and the reconciliation data is a data record obtained after data cleaning is performed on real-time data (such as the second/minute level) from a data source. In implementation, the reconciliation data table may be generated by a reconciliation system, or may be generated by other servers or devices having a data cleansing function.

Illustratively, one or more business flow records of one or more business events of the target business are recorded in the reconciliation data table, and the business flow records are data records obtained after the business flow of the business events is cleaned. In one embodiment, the reconciliation data table may be generated as follows:

receiving a service flow sent by a data source; performing data cleaning on the business flow to obtain key data, wherein the key data comprises financial operation information; organizing the key data into business flow records, and writing the business flow records into a reconciliation data table, wherein one business flow record comprises one piece of accounting operation information.

In practice, the data source may be a business system. The business process may be that when accounting operation (or referred to as monetary operation) on a business event is involved in a business processing process of a business system, business data is generated in real time according to accounting operation information of the accounting operation and a business event identifier, and the business data is transmitted to the accounting system in a data stream form. As shown in fig. 2, a data access module can be included in the reconciliation system through which the reconciliation system can receive the traffic flow from the data source.

Illustratively, the business pipeline may include accounting operation information, identification information (e.g., may include business event identification, business identification, etc.), tie-out flag for marking whether the current business pipeline is tie-out, etc. The account operation information may exemplarily include an operation type, an operation amount, an operation time, and the like. The operation types may illustratively include an increase amount operation and a decrease amount operation.

Because the traffic flow contains more information, some information is useless information in the reconciliation scene. In order to avoid the excessively bloated data for account checking, save the storage space of the account checking system and reduce the amount of processed data, as shown in fig. 2, a data cleaning module may be further disposed in the account checking system, and after a real-time service flow is obtained, the service flow may be cleaned by the data cleaning module, and key data used for account checking may be extracted from the service flow, where the key data may include, for example, accounting operation information, a service event identifier, a service identifier, and the like.

After the data cleaning module obtains the key data in the service flow, the key data may be generated into a service flow record according to a set data format, where one service flow record may illustratively include accounting operation information, a service event identifier, and an end mark (for marking whether the current service flow record is the last service flow record of the service flow). And a business flow record contains an account operation information, that is, how many business flow records there are in how many account operation information in the business flow, for example, suppose a business flow is { red packet ID:1; -10,09; +5,09; +5,09; and according to the accounting operation information (-10, 09:

{ Red envelope ID:1 operation type and amount: -10 operation time: 09:00 end: no }

{ Red envelope ID:1 operation type and amount: +5 operation time: 09 end: no }

{ Red envelope ID:1 operation type and amount: +5 operation time: 09 end }

And after the account checking system obtains the business flow record, the business flow record can be written into the account checking data table. The embodiment does not limit the storage form of the business flow record in the reconciliation data table, for example, a new increment can be added in the reconciliation data table, and the whole business flow record similar to the above form can be written into the new increment; or, it can set fields such as service event identification, operation time, operation type and money amount, end mark, etc. in the reconciliation data table, then extract related contents as field values according to the above-mentioned service flow record and fill in the corresponding fields respectively.

It should be noted that, for a target service, multiple service events may be executed concurrently in the same period, and the reconciliation system may receive service flow of multiple service events in the period, and thus generate multiple service flow records of different service events. Then the plurality of business flow records of the plurality of business events may be recorded in the reconciliation data table according to the time dimension, for example, an exemplary reconciliation data table may be as shown in table 1:

red envelope ID:3 operation type and amount +3 operation time: 09
	Red envelope ID:2 operation type and amount +7 operation time: 09
Red envelope ID:3 operation type and amount +5 operation time: 09
	Red envelope ID:2 operation type and amount +2 operation time: 09
Red envelope ID:1 operation type and amount +5 operation time: 09
	Red envelope ID:1 operation type and amount +5 operation time: 09
Red envelope ID 3 operation type and amount-10 operation time: 09
	Red envelope ID:2 operation type and amount-10 operation time: 09
Red envelope ID:1 operation type and amount-10 operation time: 09: end

TABLE 1

And 102, respectively carrying out bill reconciliation treatment on the business flow records based on the business event identification and the financial operation information of each business flow record.

In implementation, as shown in fig. 2, the reconciliation system may further include a reconciliation module, and after the reconciliation module obtains the reconciliation data table, the reconciliation module may traverse each service flow record in the reconciliation data table, for example, traverse from far to near according to the time dimension. And performing bill reconciliation processing according to the service event identification and the accounting operation information of the currently traversed service flow record. The form reconciliation processing mode may adopt a general reconciliation processing mode, and the form reconciliation processing mode in this embodiment is not limited, for example, if an accounting flow consistent with the service event identifier and the accounting operation information is found, the reconciliation is successful, otherwise, the reconciliation is failed.

In an embodiment, as shown in fig. 2, the reconciliation system may further include a tie-out module, and when the reconciliation result of a certain service flow record is a reconciliation failure result, the tie-out module may be used to perform tie-out processing on data. The tie account processing mode may adopt a general tie account processing mode, which is not limited in this embodiment.

And 103, determining a check rule corresponding to each business event.

The check rule is used for checking the business integrity of the current business event. In one implementation, as shown in fig. 2, a configuration center may be included in the reconciliation system, and a reconciliation module in the reconciliation system may search the check rule of the current business event from the configuration center.

In practice, one check rule is equivalent to one rule engine, and when a new service scenario is added, the corresponding rule engine needs to be added. Each rule engine has a corresponding parser for rule parsing, which may be located in the reconciliation module.

And 104, checking whether the business process of the business event is complete or not by adopting a check rule of the business event according to a checking result obtained after the bill checking is carried out on the business flow record of each business event.

In this embodiment, the reconciliation module has a function of verifying the business integrity of the business event, in addition to the bill reconciliation processing in step 102. After the reconciliation module obtains the check rule corresponding to the current business event, the business flow record of the business event can be extracted from the reconciliation data table, and the bill reconciliation result of each extracted business flow can be obtained. And then, the integrity of the business event is checked by combining the check rule and the bill reconciliation result recorded by each business flow, so that whether the business flow of the business event is complete or not is judged.

In practice, as shown in fig. 2, the account checking system may further include a result notification module, and when the account checking module detects an account checking failure result or detects that the service has an integrity problem, an abnormal notification may be generated for the service event identifier of the service event, and the result notification module alerts the abnormal notification to the service system. Of course, if there is no abnormal service, the result notification module may also notify the service system that the service of the service event is normal.

In this embodiment, the reconciliation of the reconciliation system depends on the reconciliation data table, and one or more business flow records of one or more business events are recorded in the reconciliation data table. When reconciliation is carried out, the reconciliation system can not only carry out conventional bill reconciliation operation on the business flow record, but also obtain the check rule of the business event and carry out integrity check on the business event by adopting the check rule and the reconciliation result of the bill reconciliation of the business flow record so as to check whether the business event has an integral business flow, thereby realizing the energization of the reconciliation system, improving the capability of the reconciliation system for detecting abnormity, finding the abnormity existing in the reconciliation process in time and further improving the accuracy of the reconciliation.

Example two

Fig. 3 is a flowchart of an account checking method provided in the second embodiment of the present application, and this embodiment specifically describes a process of checking integrity of a business event on the basis of the first embodiment. As shown in fig. 3, the present embodiment may include the following steps:

step 201, an account checking data table is obtained, wherein one or more business flow records of one or more business events are recorded in the account checking data table, the business flow records include business event identifiers and financial operation information, and the financial operation information includes operation time.

Step 202, based on the business event identifier and the accounting operation information of each business flow record, respectively performing bill reconciliation processing on the business flow record.

Step 203, determining a check rule corresponding to each business event.

Illustratively, the validation rules may include default general rules, and in some cases, specific validation rules associated with the business. The specific check rule may include a conditional expression related to the service, and the general check rule does not have the conditional expression, for example, the general check rule may be expressed as a default value.

In one embodiment, step 203 may further comprise the steps of:

step 203-1, determining a service identifier of each service event, and searching the service identifier in a preset configuration file; if the service identifier is found, executing step 203-2, and if the service identifier is not found, executing step 203-3.

In practice, the service event identifier is associated with the service identifier, and the corresponding service identifier can be obtained according to the service event identifier. For example, the service event identifier includes a service identifier, for example, if the service event identifier is a red packet ID 1, the corresponding service identifier is a red packet identifier. As another example, the service event identifier may be searched from a previously generated identifier binding file, so as to obtain the service identifier bound to the service event identifier. Or for example, the service stream contains the service event identifier and the service identifier, the reconciliation system can extract the service event identifier and the service identifier and record the relationship between the service event identifier and the service identifier, and then the service identifier corresponding to the service event identifier can be obtained according to the recorded relationship. The embodiment does not limit the manner in which the account checking module obtains the service identifier.

After the service identifier is obtained, the reconciliation module can search the service identifier in a preset configuration file. Wherein, the configuration file is pre-configured with one or more service identifications of specific complex services. If the service identifier can be found from the configuration file, it indicates that the current service event is a service event of a complex service, and then step 203-2 may be executed. The complex service is characterized in that: the number of money operations cannot be known at the beginning of the service, but only after the service is finished. For example, in a red envelope game, a user sends a red envelope, it is uncertain how many people will rob the red envelope before the red envelope expires, and after the red envelope expires, the game is ended, and it can be determined how many people rob the red envelope.

If the service identifier cannot be found from the configuration file, it indicates that the current service event is a service event of a non-complex service, and step 203-3 may be executed. Non-complex transactions may include transactional transactions, such as bill-to-account transactions, real-time transactional transactions, delayed-transaction transactions, and the like. The transaction type business is characterized in that a business system can clearly know how many times of currency operations are carried out at the beginning, for example, the gift sending business of a live broadcast platform relates to currency reduction operation of a gift sender and currency increase operation of a main broadcast.

Step 203-2, searching a preset rule database for a check rule corresponding to the service identifier as a specific check rule, and determining the check rule corresponding to the service event as a general check rule and the specific check rule.

Specifically, if it is determined that the current service event is a service event of a complex service, the check rule includes a general check rule and a specific check rule corresponding to the service event. And the specific check rule can be obtained by searching the service identifier of the current service event from a preset rule database. The rule database stores preset specific checking rules of different services.

Step 203-3, determining the check rule corresponding to the business event as a general check rule.

And if the current service event is judged to be a service event of the non-complex service, the check rule is a universal check rule. The check rule is simpler compared with the service event of the complex service.

And 204, determining the last business flow record of each business event in the reconciliation data table according to the operation time.

For each service event, the service flow record in which the latest operation time is located may be used as the last service flow record of the service event. For example, in table 1 of the first embodiment, the last service flow record of the service event "red packet ID:1" is { red packet ID:1 operation type and amount: +5 operation time: 09:04 end: yes }, the last service flow record of the service event "red packet ID:2" is { red packet ID:2 operation type and amount: +7 operation time: 09 end: yes }, and the last service flow record of the service event "red packet ID:3" is { red packet ID:3 operation type and amount: +3 operation time: 09.

Step 205, determining whether the last service flow record is an end flow record, and if so, determining the corresponding service event as a target service event.

After the last service flow record of each service event is determined, whether the last service flow record is the ending flow record of the service event is further judged, if yes, the service flow corresponding to the service event is ended, the service event can be used as a target service event, and the integrity can be further verified subsequently. If not, the business process corresponding to the business event is not finished, the business event is not the target business event, and the time for checking the integrity is not reached.

In an embodiment, the service flow record may include an end flag, where the end flag is used to flag whether the corresponding service flow record is an end flow record, and the end flag may include two values, i.e., ended and not ended, for example, in table 1 of the first embodiment, where "end:" indicates an end flag, "end: yes" indicates that the value of the end flag is ended, and "end: no" indicates that the value of the end flag is ended. Step 205 may further include the steps of:

step 205-1, if the end mark of the last service flow record is ended, determining that the last service flow record is an end flow record.

In this step, if the value of the end flag of the last service flow record of a certain service event is ended, it may indicate that the last service flow record is the end flow record of the service event. For example, in table 1 of the first embodiment, the last service flow record of the service event "red packet ID:1" { red packet ID:1 operation type and amount: +5 operation time: 09 end: yes }, and the end flags of the last service flow record of the service event "red packet ID:2" { red packet ID:2 operation type and amount: +7 operation time: 09 end: yes }, both indicate that the end flag has ended, and both of the two last service flow records are end flow records. And the end mark of the last service flow record { red packet ID:3 operation type and amount: +3 operation time: 09.

Step 205-2, if the end mark of the last service flow record is not ended, obtaining the effective time of the service event, and if the operation time of the last service flow record is within the effective time, determining that the last service flow record is not the end flow record; and if the operation time of the last service flow record exceeds the effective time, judging the last service flow record as the end flow record.

The effective time of each business event is used for representing the life cycle of the current business event, the business events in the life cycle need to be checked continuously until a checking result exists, and if the business events exceeding the life cycle do not have the checking result, the checking is stopped and marked as abnormal checking.

In one implementation, the service identifier of the current service event may be searched from the configuration file, so as to obtain the effective duration of the service event, where different services have different effective durations. And then, taking the operation time of the business event recorded in the first business flow record in the reconciliation data table as the business start time, and calculating the effective time of the business event according to the business start time and the effective duration.

After the valid time of the service event is obtained, the operation time of the last service flow record of the service event may be compared with the valid time. If the operation time of the last service flow record is within the valid time, the service event life cycle is not expired, and a new service flow record can be generated, so that the last service flow record is judged not to be the end flow record. And if the operation time of the last service flow record exceeds the effective time, the service event is indicated to have expired, and no new service flow record is generated, so that the last service flow record is judged to be the end flow record. For example, in the above example, for the last service journal record of the service event "red packet ID:3" { red packet ID:3 operation type and amount: +3 operation time: 09 end: no }, if the validity time of the service event "red packet ID:3" is 09; however, if the validity time of the service event "red packet ID:3" is 10:06, its operation time 09.

And step 206, checking whether the business process of the target business event is complete or not by adopting the check rule of the target business event according to the checking result obtained after the bill checking is carried out on the business flow record of the target business event.

After the target business event is determined, whether the business process of the target business event is complete or not can be verified according to the reconciliation result and the verification rule obtained after the bill reconciliation processing is carried out on the business flow record of the target business event.

The following describes a process of integrity check of a target service event, in which the target service event is a service event of a complex service or a service event of a non-complex service, divided into two cases.

In an embodiment, if the target service event is a service event of a non-complex service, the corresponding check rule is a general check rule, and the general check rule does not have a conditional expression. For a business event of a non-complex business, a business system writes accounting operation information of all accounting operations into a business flow, and the checking of the business event mainly detects whether each accounting operation related to the business event is successfully checked.

Then, referring to fig. 4, step 206 may further include the steps of:

and step 206-1, obtaining the reconciliation result of each business flow record of the target business event after the bill reconciliation processing is carried out.

And the account checking result comprises an account checking failure result and an account checking success result.

When the checking result is obtained, if the checking result of each business flow record after the bill checking is carried out is marked in the checking data table, the checking result of each business flow record of the target business event can be read from the checking data table; if the reconciliation data table does not mark the reconciliation result, searching in the result notification module according to the service event identifier of the target service event, and if the service event identifier of the target service event is not searched, indicating that the reconciliation results of all service flow records of the target service event are successful reconciliation results; if the business event identifier is found, the business flow record indicating that account checking failure exists in all the business flow records of the target business event.

And step 206-3, if account checking failure results exist in the account checking results of the business flow records of the target business event, determining that the business flow of the target business event is incomplete.

Specifically, if an account checking failure result exists in the account checking results of the business flow records of the target business event, which indicates that the operation of the accounting operation in the target business event has failed, it may be determined that the business flow of the target business event is incomplete at this time. That is to say, if any business pipeline record of the target business event has an account checking abnormality, the account checking abnormality of the target business event can be determined.

And step 206-5, if the reconciliation results of all the business flow records of the target business event are successful reconciliation results, judging that the business flow of the target business event is complete.

Specifically, if the reconciliation results of all the business flow records of the target business event are all reconciliation success results, which indicates that all the accounting operations of the target business event are successfully operated, it can be determined that the business flow of the target business event is complete at this time.

In the embodiment, the integrity check of the service event of the non-complex service is simple, and when the reconciliation of each service flow record in the target service event is successful, the service flow of the target service event can be judged to be complete. The whole process is simple, and the account checking efficiency is high.

In another embodiment, if the target service event is a service event of a complex service, the corresponding check rule includes a specific check rule in addition to the general check rule, the general check rule does not have a conditional expression, and the specific check rule has a conditional expression. The reconciliation of complex business is mainly to detect the consistency of all accounting operations on the amount or the consistency of the operation times. Such as a red envelope game, the service integrity refers to: the issued red packet amount = the amount of the red packet robbed + the amount of the red packet retreated.

Then, referring to fig. 5, step 206 may further include the steps of:

and step 206-2, acquiring the reconciliation result of each business flow record of the target business event after the bill reconciliation processing is carried out.

And step 206-4, if the reconciliation failure result exists in the reconciliation result of each business flow record of the target business event, determining that the business flow of the target business event is incomplete.

And step 206-6, if the reconciliation results of all the business flow records of the target business event are reconciliation success results, checking whether the business flow of the target business event is complete or not by adopting the specific checking rule.

Compared with the integrity check of the non-complex service, the integrity check of the complex service needs to adopt a specific check rule to check whether the service flow of the target service event is complete after adopting a general check rule to judge that the account checking results of all the service flow records of the target service event are account checking success results. And if the general check rule is adopted to judge that the account checking result of each business flow record of the target business event has an account checking failure result, the specific check rule is not required to be adopted to check whether the business flow of the target business event is complete, but the business flow of the target business event is directly judged to be incomplete.

In one embodiment, step 206-6 may further include the steps of:

and step 206-6-1, extracting the operation variables from the conditional expression.

Wherein the operation variable may include at least one of a free variable and a constraint variable. For example, if the conditional expression is: when the added amount = the decreased amount, the corresponding operation variables (i.e., free variables) are "added amount" and "decreased amount". For another example, if the conditional expression is: if the number of operations < = set threshold, the corresponding free variable is "number of operations", and the constrained variable is "set threshold".

And step 206-6-2, extracting the business element values corresponding to the operational variables from the business flow records of the target business events, and calculating the values of the operational variables according to the extracted business element values.

After the operational variable (referred to herein as a free variable) is determined, the business element value of the business element associated with the operational variable may be extracted from each business flow record of the target business event. For example, if the operation variable is "increase amount" or "decrease amount", the related business elements are the operation type and the operation amount; if the operation variable is 'operation times', the related business elements are one or combination of account operation information such as operation types, operation amounts, operation time and the like.

For example, in table 1 of the first embodiment, if the target service event is "red packet ID:1", and if the operation variable is "amount increase", the service flow record whose operation type is amount increase operation may be extracted from the service flow record of the target service event, then the operation amount of the extracted service flow record is obtained as the service element value corresponding to the operation variable, and the finally obtained value of the operation variable is "5+5=10"; if the operation variable is 'amount reduced', the operation flow record with the operation type of the operation of amount reduction can be extracted from the service flow record of the target service event, then the operation amount of the extracted service flow record is obtained as the service element value corresponding to the operation variable, and finally the value of the operation variable is '10'. If the operation variable is "operation count", the number of accounting operation information (that is, the number of business flow records) can be calculated from the business flow records of the target business event, and as the value of the operation variable, in table 1, for the target business event "red packet ID:1", the operation count =3.

And step 206-6-3, if the value of the operational variable meets the conditional expression, judging that the business process of the target business event is complete.

And step 206-6-4, if the value of the operational variable does not meet the conditional expression, determining that the service process of the target service event is incomplete.

For example, if the target service is a red packet service, the conditional expression is: the increase amount = the decrease amount, in table 1 of the first embodiment, for each service flow record of the target service event "red envelope ID:1", the increase amount =5+5=10, and the decrease amount =10, the increase amount = the decrease amount, at this time, it can be determined that the operation result of the target service event "red envelope ID:1" conforms to the conditional expression, and then, it is determined that the service flow of "red envelope ID:1" is complete. For each service flow record of the target service event 'red packet ID: 2', the increase amount =2+7=9, and the decrease amount =10, the increase amount ≠ decrease amount, at this time, it can be determined that the operation result of 'red packet ID: 2' does not conform to the conditional expression, and further, it can be determined that the service flow of 'red packet ID: 2' is incomplete. If the "red packet ID:3" is the target service event, the increment =5+3=8, and the decrement =10, the increment is not equal to the decrement, and at this time, it can be determined that the operation result of the "red packet ID:2" does not conform to the conditional expression, and further, it is determined that the service flow of the "red packet ID:3" is incomplete.

For another example, if the target service is killing second (inventory is 10), the conditional expression is: the number of money operations < =10, in table 1 of the first embodiment, if the number of operations of the target service events "red packet ID:1" and "red packet ID:2" is 3, and both are less than 10, it can be determined that the service flows of "red packet ID:1" and "red packet ID:2" are complete. If the 'red packet ID: 3' is the target service event, the operation frequency is 3 and is less than 10, the service process of the 'red packet ID: 3' can be judged to be complete.

In the embodiment, for complex services, the general check rule and the specific check rule can be simultaneously adopted to check the integrity of the services, so that the integrity of the services is better ensured, and the check accuracy of abnormal services is improved.

In this embodiment, before checking the service integrity of a service event, it is necessary to determine whether the service event has a running record ending function, take the service event with the running record ending function as a target service event, and check the service integrity of the target service event. And the integrity check of all business events appearing in the account checking data table is not needed, so that the account checking workload is reduced, and the account checking efficiency is better improved.

EXAMPLE III

Fig. 6 is a flowchart of an account checking method provided in the third embodiment of the present application, and this embodiment specifically describes other bottom-of-pocket account checking processes in an account checking process on the basis of the first embodiment or the second embodiment. As shown in fig. 6, the present embodiment may include the following steps:

step 301, acquiring a reconciliation data table, where one or more business flow records of one or more business events are recorded in the reconciliation data table, and the business flow records include business event identifiers and accounting operation information.

Step 302, acquiring an accounting flow corresponding to the business event identifier, where the accounting flow includes accounting operation information.

In one implementation, the reconciliation system can receive an accounting flow from an account system, which can include a business event identification, accounting operation information, a reconciliation flag for marking whether reconciliation has occurred, and the like.

And traversing the service flow records in the reconciliation data table, extracting the service event identification from the traversed service flow records, and then finding the accounting flow corresponding to the service event identification according to the extracted service event identification.

Step 303, searching accounting operation information of the business workflow record in the accounting operation information of the accounting workflow; if the search is successful, go to step 304, and if the search fails, go to step 305.

And step 304, determining that the account checking result of the business flow record is an account checking success result.

When the accounting flow corresponding to the current business flow record is found, the bill reconciliation processing can be performed on the business flow record and the corresponding accounting flow. When the checking is implemented, the accounting operation information can be extracted from the current business flow record, then the extracted accounting operation information is searched in the corresponding accounting flow, and if the accounting operation information is found, the checking is successful for the current business flow record, that is, the checking result of the current business flow record is the checking successful result, and is the normal business flow record. If the accounting operation information is not found, step 305 is further performed.

In one embodiment, if the reconciliation of the current business flow record is successful, the business flow record may be deleted in the reconciliation data table. In one embodiment, the deleting may be performed in real time when it is determined that the reconciliation of the current business flow record is successful. In another embodiment, the deleting may be performed at a time when all the business flow records of the same business event are deleted in the reconciliation data table after the completion of the subsequent integrity check, in which case, when it is determined that the reconciliation of the current business flow records is successful, the reconciliation success result may be marked in the reconciliation data table.

Step 305, determining whether the operation time of the service flow record exceeds the valid time of the corresponding service event, if so, executing step 306, and otherwise, executing step 307.

Step 306, determining the reconciliation result of the business flow record as a reconciliation failure result.

And 307, waiting for the next reconciliation period to perform bill reconciliation processing on the business flow record.

In this step, if the accounting operation information of the current business flow record cannot be found in the accounting flow, it may be further determined whether the operation time of the business flow record exceeds the valid time of the corresponding business event, and if the operation time exceeds the valid time, it indicates that the current business event exceeds the reconciliation valid period, at this time, it may be determined that the reconciliation of the current business flow record fails, that is, the reconciliation result of the current business flow record is the reconciliation failure result. If the valid time is not exceeded, the current business event is in the reconciliation valid period, the business flow record can be kept in the reconciliation data table, and the next reconciliation period is waited to continue the bill reconciliation processing on the business flow record.

In an embodiment, if the reconciliation result of the current business flow record is a reconciliation failure result, an exception notification may be generated according to the business event identifier in the business flow record, and the exception notification may be alarmed to a business party (i.e., a business system) to remind the business party that the reconciliation exception exists for the business event. Meanwhile, the business flow record can be deleted in the reconciliation data table, and the deletion time can be real-time deletion or deletion after a period of time of caching. In other embodiments, if the corresponding traffic flow record is not deleted immediately after the bill reconciliation process, the reconciliation failure result for the traffic flow record may be marked in the reconciliation data table.

And 308, determining a check rule corresponding to each business event.

And 309, checking whether the service process of the service event is complete or not by adopting a check rule of the service event according to a checking result obtained after the bill checking is carried out according to the service flow record of each service event.

And step 310, judging whether account checking-free accounting flow exists or not, if so, executing step 311, and otherwise, ending the flow.

In the accounting flow received by the reconciliation system, the reconciliation system can judge whether accounting flow which does not participate in reconciliation still exists according to a preset time interval. And if all the accounting flows participate in reconciliation, ending the flow. If there is an accounting pipeline that does not participate in reconciliation, step 311 is performed.

Step 311, according to the operation time carried in the unpaired account flow, determining whether the account flow exceeds the valid time of the corresponding business event, if yes, executing step 312, otherwise, executing step 313.

In step 312, it is determined that the service event corresponding to the account flow has an account checking exception.

Step 313, wait for the next reconciliation cycle to process the accounting flow.

For the accounting running water which does not participate in reconciliation, the operation time of the accounting running water can be acquired, for example, the latest operation time of the accounting running water is acquired, then the effective time of the business event identifier carried by the accounting running water is acquired, if the operation time is in the effective time, which indicates that the accounting running water is in the effective period, the accounting running water is not processed, so that the accounting running water continues to wait for reconciliation processing of the next reconciliation period. If the operation time is not within the valid time, the accounting flow exceeds the valid period, and then the account checking abnormality of the business event corresponding to the accounting flow can be determined, at this time, an abnormality notification can be generated according to the business event identifier, and the abnormality notification is alarmed to the business party.

In a further embodiment, according to the service event identifier with the account checking abnormality, all the accounting running water which does not participate in the account checking of the service event identifier can be found, and the found accounting running water is deleted.

In this embodiment, whether a business event is abnormal or not is judged through checking the accounting flow, so that the abnormality of the business event is found more comprehensively, and the accuracy of account checking is improved better.

Example four

Fig. 7 is a schematic structural diagram of a reconciliation apparatus provided in a fourth embodiment of the present application, where the reconciliation apparatus is disposed in a reconciliation system, and may include the following modules:

the reconciliation data table obtaining unit 401 is configured to obtain a reconciliation data table, where one or more service flow records of one or more service events are recorded in the reconciliation data table, and the service flow records include service event identifiers and accounting operation information;

a bill reconciliation processing unit 402, configured to perform bill reconciliation processing on the service flow records respectively based on the service event identifiers and the accounting operation information of the service flow records;

a check rule determining unit 403, configured to determine a check rule corresponding to each service event;

and an integrity checking unit 404, configured to check whether the service flow of each service event is complete by using a checking rule of the service event according to a reconciliation result obtained after the bill reconciliation processing is performed on the service flow record of each service event.

In one embodiment, the reconciliation data table is generated as follows:

receiving a service flow sent by a data source;

performing data cleaning on the business flow to obtain key data, wherein the key data comprises financial operation information;

organizing the key data into business flow records, and writing the business flow records into the reconciliation data table, wherein one business flow record comprises one piece of accounting operation information.

In one embodiment, the accounting operation information comprises an operation time; integrity check unit 404 may include the following:

the target business event determining unit is used for determining the last business flow record of each business event in the reconciliation data table according to the operation time; judging whether the last service flow record is an end flow record or not, and if so, determining a corresponding service event as a target service event;

and the checking unit is used for checking whether the service flow of the target service event is complete or not by adopting the checking rule of the target service event according to the checking result obtained after the bill checking is carried out on the service flow record of the target service event.

In one embodiment, the traffic flow record further comprises an end flag, the end flag comprising ended and not ended;

the target service event determining unit is specifically configured to:

if the ending mark of the last service flow record is ended, judging that the last service flow record is the ending flow record;

if the ending mark of the last service flow record is not ended, obtaining the effective time of the service event, and if the operation time of the last service flow record is within the effective time, judging that the last service flow record is not the ending flow record; and if the operation time of the last service flow record exceeds the effective time, judging the last service flow record as the end flow record.

In one embodiment, the check rule comprises a general check rule, and the general check rule has no conditional expression; the verification unit is specifically configured to:

acquiring account checking results of all business flow records of the target business event after the bill account checking is carried out, wherein the account checking results comprise account checking failure results and account checking success results;

if the account checking failure result exists in the account checking result of each business flow record of the target business event, judging that the business flow of the target business event is incomplete;

and if the account checking results of all the business flow records of the target business event are account checking success results, judging that the business flow of the target business event is complete.

In another embodiment, the check rule includes a general check rule and a specific check rule corresponding to the target business event, the general check rule has no conditional expression, and the specific check rule has a conditional expression; the verification unit may further include the following units:

the general checking unit is used for acquiring the account checking result of each business flow record of the target business event after the bill account checking processing is carried out, wherein the account checking result comprises an account checking failure result and an account checking success result; if the account checking failure result exists in the account checking result of each business flow record of the target business event, judging that the business flow of the target business event is incomplete; if the account checking results of all the business flow records of the target business event are account checking success results, calling a specific checking unit;

and the specific checking unit is used for checking whether the business process of the target business event is complete or not by adopting the specific checking rule.

In an embodiment, the specific verification unit is specifically configured to:

extracting an operational variable from the conditional expression;

extracting business element values corresponding to the operational variables from all business flow records of the target business event, and calculating the values of the operational variables according to the extracted business element values;

if the value of the operational variable meets the conditional expression, judging that the service flow of the target service event is complete;

and if the value of the operational variable does not meet the conditional expression, judging that the service process of the target service event is incomplete.

In an embodiment, the check rule determining unit 403 is specifically configured to:

determining a service identifier of each service event, and searching the service identifier in a preset configuration file;

if the service identifier is found, searching a check rule corresponding to the service identifier from a preset rule database to serve as a specific check rule, and determining the check rule corresponding to the service event as a general check rule and the specific check rule;

if the service identifier cannot be found, determining the check rule corresponding to the service event as a universal check rule.

In an embodiment, the billing reconciliation processing unit 402 is specifically configured to:

acquiring an accounting flow corresponding to the business event identifier, wherein the accounting flow comprises accounting operation information;

searching the accounting operation information recorded by the business flow in the accounting operation information of the accounting flow;

if the searching is successful, determining the account checking result of the business flow record as an account checking success result;

if the checking fails, whether the operation time of the business flow record exceeds the effective time of the corresponding business event is judged, if so, the reconciliation result of the business flow record is determined to be a reconciliation failure result, and if not, the next reconciliation period is waited to carry out bill reconciliation processing on the business flow record.

In one embodiment, the apparatus further comprises an accounting flow checking unit configured to:

judging whether an account running water without account checking exists;

if yes, judging whether the account flow exceeds the effective time of the corresponding business event according to the operation time carried in the account flow which is not checked; and if the effective time is exceeded, judging that the account checking abnormality exists in the business event corresponding to the account flow, and if the effective time is not exceeded, waiting for the next account checking period to process the account flow.

In one embodiment, the apparatus further comprises:

the business flow record deleting unit is used for deleting the business flow record in the account checking data table for the business flow record of which the account checking result is the account checking success result;

and the exception warning unit is used for generating an exception notification according to the business event identifier in the business flow record of which the account checking result is the account checking failure result, warning the exception notification to a business party, and deleting the business flow record in the account checking data table.

The reconciliation device provided by the embodiment of the application can execute the reconciliation method provided by any one of the first embodiment to the third embodiment of the application, and has corresponding functional modules and beneficial effects of the execution method.

EXAMPLE five

Fig. 8 shows a schematic structural diagram of a reconciliation device 10 that can be used to implement an embodiment of the method of the present application. As shown in fig. 8, the reconciliation apparatus 10 comprises at least one processor 11, and a storage device, such as a Read Only Memory (ROM) 12, a Random Access Memory (RAM) 13, etc., communicatively connected to the at least one processor 11, wherein the storage device stores one or more computer programs executable by the at least one processor, and the processor 11 can perform various appropriate actions and processes according to the computer programs stored in the Read Only Memory (ROM) 12 or the computer programs loaded from the storage unit 18 into the Random Access Memory (RAM) 13. In the RAM 13, various programs and data necessary for the operation of the reconciliation apparatus 10 can also be stored.

In some embodiments, a reconciliation method can be implemented as a computer program tangibly embodied in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and/or installed onto the tie-back device 10 via the ROM 12 and/or the communication unit 19. One or more steps of a reconciliation method as described above may be performed when the computer program is loaded into the RAM 13 and executed by the processor 11.

In some embodiments, a reconciliation method may be implemented as a computer program product comprising computer-executable instructions for performing one or more steps of a reconciliation method described above when executed.

Claims

1. A reconciliation method is applied to a reconciliation system, and comprises the following steps:

the method comprises the steps of obtaining a reconciliation data table, wherein one or more business flow records of one or more business events are recorded in the reconciliation data table, and the business flow records comprise business event identifications and account operation information;

respectively performing bill reconciliation processing on the business flow records based on the business event identification and the financial operation information of each business flow record;

determining a check rule corresponding to each business event;

2. The method of claim 1, wherein the reconciliation data table is generated as follows:

receiving a service flow sent by a data source;

3. The method of claim 1 or 2, wherein the accounting operation information comprises an operation time; the checking account result obtained after the bill checking account processing is carried out according to the business flow record of each business event, and whether the business process of the business event is complete or not is verified by adopting the verification rule of the business event, which comprises the following steps:

determining the last business flow record of each business event in the reconciliation data table according to the operation time;

judging whether the last service flow record is an ending flow record or not, and if so, determining a corresponding service event as a target service event;

and checking whether the business process of the target business event is complete or not by adopting the check rule of the target business event according to the checking result obtained after the bill checking is carried out on the business flow record of the target business event.

4. The method of claim 3, wherein the traffic flow record further comprises an end flag, the end flag comprising ended and not ended;

the judging whether the last service flow record is the end flow record includes:

5. The method of claim 3, wherein the validation rules comprise generic validation rules, wherein the generic validation rules do not have conditional expressions;

the checking whether the service process of the target service event is complete or not by adopting the checking rule of the target service event according to the reconciliation result obtained after the bill reconciliation processing is recorded by the service flow of the target service event comprises the following steps:

acquiring reconciliation results of all business flow records of the target business event after the basic reconciliation processing is carried out, wherein the reconciliation results comprise a reconciliation failure result and a reconciliation success result; if the account checking failure result exists in the account checking result of each business flow record of the target business event, judging that the business flow of the target business event is incomplete;

6. The method according to claim 3, wherein the check rule includes a general check rule and a specific check rule corresponding to the target business event, the general check rule has no conditional expression, and the specific check rule has a conditional expression;

and if the account checking results of all the business flow records of the target business event are account checking success results, checking whether the business flow of the target business event is complete or not by adopting the specific checking rule.

7. The method of claim 6, wherein the verifying whether the business process of the target business event is complete by using the specific check rule comprises:

extracting an operational variable from the conditional expression;

if the value of the operational variable meets the conditional expression, judging that the business process of the target business event is complete;

and if the value of the operational variable does not meet the conditional expression, judging that the business process of the target business event is incomplete.

8. The method according to claim 1, wherein the determining the check rule corresponding to each of the service events comprises:

and if the service identifier cannot be found, determining the check rule corresponding to the service event as a general check rule.

9. The method according to claim 1, 2 or 8, wherein the separately performing a bill reconciliation process on the business flow records based on the business event identifiers of the business flow records and the accounting operation information comprises:

10. The method of claim 9, further comprising:

judging whether an account running water without account checking exists;

11. The method of claim 9, further comprising:

deleting the business flow record in the account checking data table for the business flow record with the account checking result being the successful account checking result;

and for the business flow record with the account checking result being the account checking failure result, generating an abnormal notice according to the business event identifier in the business flow record, alarming the abnormal notice to a business party, and deleting the business flow record in the account checking data table.

12. A reconciliation apparatus, wherein the reconciliation apparatus is provided in a reconciliation system, the apparatus comprising:

13. A reconciliation apparatus, wherein the reconciliation apparatus comprises:

one or more processors;

a storage device for storing one or more programs,

when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-11.

14. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the method according to any one of claims 1-11.

15. A computer program product comprising computer-executable instructions for implementing the method of any one of claims 1-11 when executed.