CN113793211A - Inter-system account checking method, device, subsystem, storage medium and system - Google Patents
Inter-system account checking method, device, subsystem, storage medium and system Download PDFInfo
- Publication number
- CN113793211A CN113793211A CN202111116761.XA CN202111116761A CN113793211A CN 113793211 A CN113793211 A CN 113793211A CN 202111116761 A CN202111116761 A CN 202111116761A CN 113793211 A CN113793211 A CN 113793211A
- Authority
- CN
- China
- Prior art keywords
- data
- reconciliation
- transaction
- account checking
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 65
- 230000002093 peripheral effect Effects 0.000 claims abstract description 101
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 claims abstract description 83
- 238000012545 processing Methods 0.000 claims description 20
- 238000012163 sequencing technique Methods 0.000 claims description 4
- 230000000977 initiatory effect Effects 0.000 claims description 3
- 230000008030 elimination Effects 0.000 claims description 2
- 238000003379 elimination reaction Methods 0.000 claims description 2
- 230000008569 process Effects 0.000 description 11
- 238000010586 diagram Methods 0.000 description 7
- 230000004044 response Effects 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 238000004590 computer program Methods 0.000 description 3
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 239000000284 extract Substances 0.000 description 3
- 238000010276 construction Methods 0.000 description 2
- 230000002354 daily effect Effects 0.000 description 2
- 230000006870 function Effects 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000003203 everyday effect Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/02—Banking, e.g. interest calculation or account maintenance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Engineering & Computer Science (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- Technology Law (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Debugging And Monitoring (AREA)
Abstract
The application provides an inter-system reconciliation method, an inter-system reconciliation device, a subsystem, a storage medium and a system. The method comprises the steps of obtaining a reconciliation request for reconciling the transaction of the peripheral system, wherein the reconciliation request comprises a reconciliation date and identification information of the peripheral system; determining a time period needing account checking according to the account checking date; taking the data of the transaction corresponding to the identification information in the time period as initial flow data and sending the initial flow data to a public system; and receiving target running data which is returned by the public system and has an unknown transaction execution state in the initial running data, generating an inter-system reconciliation result according to the target running data, and sending the reconciliation result to the peripheral system. According to the embodiment of the application, the initial running water data is obtained from the subsystem, the public system performs reconciliation on the initial running water data and the local running water data to obtain the target running water data, the subsystem generates a reconciliation result according to the target running water data and sends the reconciliation result to the peripheral system, and the data sent to the peripheral system is accurate.
Description
Technical Field
The application relates to the field of finance, in particular to an inter-system reconciliation method, device, subsystem, storage medium and system.
Background
The distributed core service system comprises a plurality of subsystems and a public system at present, when each transaction occurs, the public system records the initial state of the transaction, then forwards the initial state to the corresponding subsystem for corresponding processing, each subsystem executes corresponding processing after receiving the transaction and sends the processing result to the public system, and the public system updates the initial state according to the received processing result, wherein the processing result comprises completion or incompletion.
When a certain peripheral system needs account checking, for example, the transaction of the tenderer bank needs to be checked, the transaction flow data of the tenderer bank in the subsystem and the transaction flow data of the tenderer bank in the public system are respectively acquired, and the two data are merged and sent to the peripheral system, so that the peripheral system can check the account according to the merged data. However, after the subsystem finishes processing a certain transaction a, the processing result is not fed back to the public system, the initial state of the transaction a in the public system is still unfinished, at this time, the data fed back to the peripheral system includes that the state of the transaction a is unfinished and finished, and since account checking is not performed between systems, the transaction data of the subsystem and the public system are directly fed back to the peripheral system, and the execution state of the obtained transaction data is wrong for the peripheral system.
Disclosure of Invention
An object of the embodiments of the present application is to provide an inter-system reconciliation method, apparatus, subsystem, storage medium, and system, so as to improve the accuracy of reconciliation.
In a first aspect, an embodiment of the present application provides an inter-system reconciliation method, which is applied to a subsystem in a distributed core service system, and the method includes: the method comprises the steps of obtaining an account checking request for checking the transaction of a peripheral system, wherein the account checking request comprises an account checking date and identification information of the peripheral system; determining a time period needing account checking according to the account checking date; taking the data of the transaction corresponding to the identification information in the time period as initial flow data and sending the initial flow data to the public system; and receiving target running data which is returned by the public system and has an unknown transaction execution state in the initial running data, generating an inter-system reconciliation result according to the fact that the execution state of each transaction in the target running data is complete or incomplete, and sending the reconciliation result to a peripheral system.
According to the embodiment of the application, all the running water data of transactions generated in the reconciliation date, namely the initial running water data, are acquired from the subsystem, and then the initial running water data are sent to the public system, so that the public system can reconcile the initial running water data with the locally stored running water data to acquire the target running water data, and finally, the subsystem generates a reconciliation result according to the target running water data and sends the reconciliation result to the peripheral system, so that the data sent to the peripheral system are accurate.
In any embodiment, the determining, according to the reconciliation date, a time period in which reconciliation is required includes: if the reconciliation date is two continuous natural days, taking the starting time of the reconciliation date to 24 points before the current day as a first time period; the end time from 24 o' clock to the reconciliation date is taken as the second time period.
In any embodiment, the taking the transaction data corresponding to the identification information in the time period as the initial pipelining data includes: taking the transaction data which is in the first time period and corresponds to the identification information as first running water data; taking the transaction data which is in the second time period and corresponds to the identification information as second flow data; taking the first flow data and the second flow data as the initial flow data.
According to the embodiment of the application, the running water data corresponding to two days are respectively acquired for cross-day account checking dates to carry out account checking, so that the running water data are prevented from being omitted.
In any embodiment, the receiving, by the public system, target pipelining data generated after deleting data whose transaction execution state is an unknown state in the initial pipelining data includes: receiving third streaming data which is returned by the public system and generated after deleting the data of which the transaction execution state is an unknown state in the first streaming data; fourth running water data generated after the data of which the transaction execution state is the unknown state in the second running water data is deleted; and sequencing the third running water data and the fourth running water data according to a time sequence to generate the target running water data.
According to the embodiment of the application, the running data corresponding to the two days are respectively acquired for the cross-day account checking date, and the data in the unknown state in the running data of the two days are respectively eliminated, so that the running data are prevented from being omitted.
In any embodiment, the obtaining a reconciliation request for reconciling transactions with the peripheral system includes: when a preset period comes, acquiring an account checking request for checking the transaction of the peripheral system; or when the account checking request sent by the peripheral system is received, the account checking request is obtained.
The embodiment of the application provides that the peripheral system actively initiates the reconciliation request, and the core business system automatically initiates the reconciliation request day by day, and various reconciliation modes can meet the requirements of users.
In any embodiment, the method further comprises: and judging whether the current network state between the public system and the public system is normal, and if so, executing the step of determining the time period needing account checking according to the account checking date.
According to the embodiment of the application, the error time is checked before account checking, so that account checking abnormity caused by self faults of the system is avoided, and the account checking accuracy is improved.
In a second aspect, an embodiment of the present application provides an inter-system reconciliation apparatus, where the reconciliation apparatus is a subsystem in a distributed core service system, and the reconciliation apparatus includes: the system comprises a request obtaining module, a reconciliation processing module and a reconciliation processing module, wherein the request obtaining module is used for obtaining a reconciliation request for reconciling a peripheral system, and the reconciliation request comprises a reconciliation date and identification information of the peripheral system; the time determining module is used for determining the time period needing account checking according to the account checking date; the flow data generation module is used for taking the transaction data which is in the time period and corresponds to the identification information as initial flow data and sending the initial flow data to the public system; the data return module is used for receiving target flow data which is returned by the public system and is generated after the data with the transaction execution state being the unknown state in the initial flow data is deleted; and the reconciliation module is used for generating a reconciliation result between the systems according to the completion or incompletion of the execution state of each transaction in the target flow data and sending the reconciliation result to the peripheral system.
In a third aspect, an embodiment of the present application provides an inter-system reconciliation method, which is applied to a subsystem in a distributed core service system, and the method includes:
obtaining a first reconciliation request for reconciling a transaction of a peripheral system, wherein the reconciliation request comprises a reconciliation date and identification information of the peripheral system;
determining a time period needing account checking according to the account checking date;
taking the transaction data which is in the time period and corresponds to the identification information as initial flow data;
initiating a new second account checking request to a public system, wherein the second account checking request is used for enabling the public system to search the running data of which the execution state corresponding to the peripheral system is unsuccessful;
receiving the running data which is returned by the public system and of which the execution state is unsuccessful, and eliminating the data in the initial running data according to the running data of which the execution state is unsuccessful to obtain target running data;
and generating an account checking result between the systems according to the completion or incompletion of the execution state of each transaction in the target running data, and sending the account checking result to a peripheral system.
In a fourth aspect, an embodiment of the present application provides another method for checking account between systems, where the method is applied to a checking account subsystem in a distributed core service system, and the method includes:
the method comprises the steps of obtaining an account checking request for checking the transaction of a peripheral system, wherein the account checking request comprises an account checking date and identification information of the peripheral system;
sending the reconciliation request to a subsystem so that the subsystem determines a time period needing reconciliation according to the reconciliation date, acquires initial running data according to the time period and the identification information, and sends the reconciliation request to a public system so that the public system acquires the running data of which the execution state is unsuccessful according to the reconciliation request and the time period and the identification information;
receiving the initial pipeline data returned by the subsystem and the pipeline data returned by the public system with the unsuccessful execution state, and performing elimination operation on the initial pipeline data according to the pipeline data with the unsuccessful execution state to obtain target pipeline data;
and generating an account checking result between the systems according to the completion or incompletion of the execution state of each transaction in the target running data, and sending the account checking result to a peripheral system.
In a fifth aspect, an embodiment of the present application provides a subsystem, including: the system comprises a processor, a memory and a bus, wherein the processor and the memory are communicated with each other through the bus; the memory stores program instructions executable by the processor, the processor invoking the program instructions to be capable of performing the method of the first, second or third aspect.
In a sixth aspect, an embodiment of the present application provides a non-transitory computer-readable storage medium, including: the non-transitory computer readable storage medium stores computer instructions that cause the computer to perform the method of the first, second or third aspect.
In a seventh aspect, an embodiment of the present application provides a distributed core system, including the subsystems and the public system described in the third aspect.
Additional features and advantages of the present application will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the embodiments of the present application. The objectives and other advantages of the application may be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are required to be used in the embodiments of the present application will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered as limiting the scope, and that those skilled in the art can also obtain other related drawings based on the drawings without inventive efforts.
Fig. 1 is a schematic flowchart of an inter-system reconciliation method according to an embodiment of the present application;
fig. 2 is a schematic diagram of a daily-final reconciliation flow provided in an embodiment of the present application;
fig. 3 is a schematic diagram of a real-time reconciliation flow provided in an embodiment of the present application;
fig. 4 is a schematic structural diagram of an account checking device according to an embodiment of the present application;
fig. 5 is a schematic structural diagram of an electronic device according to an embodiment of the present disclosure.
Detailed Description
The inventor researches and discovers that for the centralized core business system, account checking can be carried out through the public system because the public system is used for counting the flow state of the transaction. When a peripheral system initiates a cross-system transaction, firstly, the flow data of the transaction is added in a public system, the state of the flow data is set to be in processing, then a certain subsystem (determined by the subsystem according to the specific transaction) processes the transaction, after the subsystem completes the processing, the processed message is informed to the public system, and the public system sets the flow state of the transaction to be completed. However, in some cases, the processing of the subsystem is completed, and the common system is not informed of the completion of the processing due to various reasons, so that the flow state of the transaction in the common system is always in the process. This will cause the problem that the water flow state of the public system is inconsistent with the pipeline state of the subsystem where the business is actually executed, and thus accurate account checking of the pipeline data cannot be realized.
In order to solve the above technical problem, an embodiment of the present application provides an inter-system reconciliation method, where after receiving a reconciliation request from a peripheral system, initial pipelining data of a transaction generated in a reconciliation date is obtained first, then the initial pipelining data is sent to a public system, the public system returns, to a subsystem, target pipelining data generated after deleting data in an unknown state of a transaction execution state in the initial pipelining data, and finally, the subsystem obtains a reconciliation result according to the target pipelining data. Therefore, the generated flow data in the reconciliation result are accurate data.
It should be noted that the reconciliation between systems includes the following principles:
(1) the flow state is that the record in process does not participate in the reconciliation, and if the peripheral system finds that the record in process is absent in the reconciliation, the transaction can be initiated through the retransmission mode. When the retransmission is initiated, the core service system has a clear response code to prompt the processing state and needs human intervention;
(2) for the transaction which definitely prompts failure, if the transaction needs to be initiated again, the peripheral system needs to generate a new transaction (namely new flow data);
(3) only transactions for unknown states (no return message by the core) can be retransmitted.
The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application.
Fig. 1 is a schematic flow chart of an inter-system reconciliation method provided in an embodiment of the present application, where as shown in fig. 1, the method is applied to one subsystem in a distributed core service system, where the distributed core service system includes a plurality of subsystems and a common system, and the common system is in communication connection with each subsystem, and the method includes the following steps:
step 101: the method comprises the steps of obtaining a reconciliation request for reconciliation of a delivery base of a peripheral system, wherein the reconciliation request comprises a reconciliation date and identification information of the peripheral system.
The core business system may include a deposit system, a loan system, an accounting system, etc., which are all subsystems of the core business system. The subsystems involved in different reconciliation requests will also be different.
The peripheral system may be a cell phone bank, for example: the mobile phone bank corresponding to the tendering bank, the mobile phone bank corresponding to the construction bank, and the like, and the mobile phone bank corresponding to the construction bank, and the like can also be a third-party financial system, for example: payroll, wechat wallet, etc.
The reconciliation request is a request for reconciling the distributed core business system with the peripheral system.
The reconciliation date is used for determining the time limit of the running water data, namely the running water data of which the transaction occurs in the reconciliation date are all the data to be acquired. The identification information of the peripheral system is used for identifying the identity of the peripheral system, and each peripheral system corresponds to only one identification information.
Step 102: and determining the time period needing account checking according to the account checking date.
The reconciliation date can be in days or hours. For example: if the reconciliation date is 2021, 9 and 9 days, the time period for which the reconciliation is required is 0 o 'clock at 9 and 9 days at 2021, and 24 o' clock at 9 and 9 days at 2021. If the reconciliation date is 10 o 'clock at 9/2021-11 o' clock at 9/2021, the time period for which the reconciliation is required is 10 o 'clock at 9/2021-11 o' clock, and the running data of the transaction is generated in the hour period. Of course, the reconciliation date may be continuous for multiple days, or discontinuous for multiple days. For example: may be 9/2021-11/2021; it can also be 9/2021 and 11/9/2021.
Step 103: and generating initial flow data of the transaction of the peripheral system in the reconciliation date according to the time period and the identification information.
And after the subsystem determines the time period to be checked, acquiring initial flow data in the time period according to the identification information of the peripheral system. It will be appreciated that the initial pipelined data includes pipelined data of all state types, including pipelined data that has been successful, pipelined data that has an unknown state, and pipelined data that has an unsuccessful state. Each subsystem is provided with a database for self use, so that the subsystems can extract initial flow data from the database according to the time period and the identification information. It can be understood that, after the subsystem extracts the initial pipeline data, the subsystem may also generate the initial pipeline data into a corresponding data file for storage.
Step 104: and receiving target running data which is returned by the public system and generated after deleting the data of which the transaction execution state is an unknown state in the initial running data.
And after acquiring the initial pipeline data, the subsystem sends the initial pipeline data to the public system. The public system stores the running data of all subsystems for executing transaction, acquires the running data with unknown transaction execution state in the running data corresponding to the peripheral system, and eliminates the corresponding running data from the initial running data according to the running number of the running data with unknown state to obtain the target running data. And after the public system acquires the target running data, returning the target running data to the subsystem. It will be appreciated that if there is no pipelining data of unknown state in the common system, then the target pipelining data is the same as the initial pipelining data.
It is understood that an unknown state refers to a state other than both a success and a failure state, for example, a state in process may be understood as an unknown state. In public systems, the execution state of a transaction may be represented by a binary number, such as: "00" indicates a success status, "01" indicates an unsuccessful status, and "10" indicates an unknown status. The execution state may also be represented in other forms, and this is not particularly limited in the embodiments of the present application.
It is to be understood that the subsystem may generate the target pipeline data into a data file for storage after receiving the target pipeline data.
Step 105: and generating an account checking result between the systems according to the completion or incompletion of the execution state of each transaction in the target running data, and sending the account checking result to a peripheral system.
After receiving the target running data returned by the public system, the subsystem can generate a reconciliation file as a reconciliation result for the target running data with the execution state being completed, or can generate a reconciliation file as a reconciliation result for the target running data with the execution state being incomplete. Of course, it is also possible to generate a reconciliation file for the target pipeline data whose status is complete and the target pipeline data whose status is incomplete as a reconciliation result. It will be appreciated that the target pipeline data is obtained by reconciling the subsystems with the pipelines in the common system.
And after the subsystem generates the account checking result, the account checking result is sent to the peripheral system, so that the peripheral system can check the account according to the account checking result.
According to the embodiment of the application, all the running water data of transactions generated in the reconciliation date, namely the initial running water data, are acquired from the subsystem, and then the initial running water data are sent to the public system, so that the public system can reconcile the initial running water data with the locally stored running water data to acquire the target running water data, and finally, the subsystem generates a reconciliation result according to the target running water data and sends the reconciliation result to the peripheral system, so that the data sent to the peripheral system are accurate.
On the basis of the above embodiment, the determining, according to the reconciliation date, the time period in which the reconciliation is required includes:
if the reconciliation date is two continuous natural days, taking the starting time of the reconciliation date to 24 points before the current day as a first time period; the end time from 24 o' clock to the reconciliation date is taken as the second time period.
In a specific implementation, the transaction initiated by the subsystem for the peripheral system may be completed only the next day, for example: the peripheral system initiates a transaction request to the subsystem at 9/11: 59 in 2021, and the subsystem may receive and process the transaction request at 0: 01/9/2021 due to network delay and the like. Then for the same transaction the corresponding time in the peripheral system is 2021, 9, month, 9, day 11:59 and in the subsystem the corresponding time is 2021, 9, month, 10, day 0: 01. Therefore, when the peripheral system initiates a transaction request to the subsystem, the transaction request may include a timestamp when the peripheral system initiates the transaction request, and when the subsystem generates corresponding pipeline data after receiving the transaction request, the subsystem may generate the timestamp according to the time of the subsystem, and the pipeline data further needs to include the timestamp in the transaction request.
When the tie-out date is 2021, 9/9, the subsystem may determine that the running data corresponding to the tie-out date includes running data across days, which is referred to as the tie-out date representing two consecutive natural days. The subsystem can divide the reconciliation date into two time periods, wherein the first time period is 0 point-24 points on 9/2021, and the second time period is 0 point-0 point 1 points on 10/9/2021. When the subsystem acquires the initial pipeline data, pipeline data corresponding to the first time period and pipeline data corresponding to the second time period are required to be acquired.
According to the embodiment of the application, the running water data corresponding to two days are respectively acquired for cross-day account checking dates to carry out account checking, so that the running water data are prevented from being omitted.
On the basis of the above embodiment, the taking the transaction data corresponding to the identification information in the time period as the initial pipelining data includes:
taking the transaction data which is in the first time period and corresponds to the identification information as first running water data;
taking the transaction data which is in the second time period and corresponds to the identification information as second flow data;
taking the first flow data and the second flow data as the initial flow data.
In a specific implementation process, for a reconciliation request including a plurality of time periods, after the time periods are obtained, the running water data of each time period can be respectively obtained, taking two time periods as an example: the first streaming data corresponding to the identification information in the first time period and the second streaming data corresponding to the identification information in the second time period can be respectively obtained. And merging the first running water data and the second running water data into initial running water data.
On the basis of the above embodiment, the receiving of the target pipeline data, which is generated after deleting the data whose transaction execution state is an unknown state in the initial pipeline data and is returned by the public system, includes:
receiving third streaming data which is returned by the public system and generated after deleting the data of which the transaction execution state is an unknown state in the first streaming data; fourth running water data generated after the data of which the transaction execution state is the unknown state in the second running water data is deleted;
and sequencing the third running water data and the fourth running water data according to a time sequence to generate the target running water data.
In a specific implementation process, after receiving first streaming data corresponding to a first time period and second streaming data corresponding to a second time period, the public system acquires data of which the execution state corresponding to the first time period is an unknown state, deletes the data of the unknown state from the first streaming data, and acquires third streaming data. And acquiring data of which the execution state corresponding to the second time period is an unknown state, deleting the data of the unknown state from the second flowing water data, and acquiring fourth flowing water data.
After the third running water data and the fourth running water data are obtained, the third running water data and the fourth running water data are sequenced according to the time sequence, and target running water data are obtained.
According to the embodiment of the application, the running data corresponding to the two days are respectively acquired for the cross-day account checking date, and the data in the unknown state in the running data of the two days are respectively eliminated, so that the running data are prevented from being omitted. On the basis of the above embodiment, the obtaining of the reconciliation request for reconciling the transaction of the peripheral system includes:
when a preset period comes, acquiring an account checking request for checking the transaction of the peripheral system; or
And when the account checking request sent by the peripheral system is received, obtaining the account checking request.
In a specific implementation process, the initiation of the reconciliation request may be automatically initiated by the subsystem according to a preset period, for example: and (4) carrying out daily final account checking on the subsystems, namely starting account checking at 24 points every day. In addition, the reconciliation request can also be initiated by the peripheral system in real time, namely the peripheral system initiates the reconciliation request to the subsystem.
The following description is made with the flow of daily final account checking and real-time account checking respectively:
fig. 2 is a schematic view of a daily-final reconciliation flow provided in an embodiment of the present application, as shown in fig. 2:
step 201: the subsystem generates a reconciliation request; the subsystem initiates a reconciliation request according to a preset period;
step 202: the subsystem checks error events; the subsystem performs error checking, i.e. determines whether the current network state between the subsystem and the public system is normal. If there is an error event, go to step 203; otherwise, executing step 204;
step 203: error processing; the subsystem processes the error and judges whether the error event is processed, if so, the step 204 is executed;
step 204: acquiring initial running water data; after the fact that the subsystem has no unprocessed error events is ensured, the subsystem determines a time period needing account checking according to account checking time, and then initial pipeline data are obtained according to the determined time period and identification information. It will be appreciated that the initial pipelined data includes pipelined data of all state types, including pipelined data that has been successful, pipelined data whose state is unknown, and pipelined data whose state is processing failure. Each subsystem is provided with a database for self use, so that the subsystems can extract initial flow data from the database according to the time period and the identification information.
Step 205: acquiring target running water data; the public system stores the running data of all subsystems for executing transaction, so the subsystems can send the initial running data to the public system, the public system obtains the running data of which the state is unknown in a corresponding time period after receiving the initial running data, the running data which is the same as the running data of the unknown state in the public system is deleted from the initial running data, the deleted initial running data is used as target running data, and the target running data is returned to the subsystems.
Step 206: and generating a reconciliation result. The subsystem generates a reconciliation result for the successful or incomplete target flow data according to the execution state and sends the reconciliation result to the peripheral system, thereby completing the reconciliation of the flow data between the public system and the subsystem with respect to the transactions of the peripheral system occurring within the reconciliation date.
Fig. 3 is a schematic diagram of a real-time reconciliation flow provided in an embodiment of the present application, as shown in fig. 3:
step 301: receiving a reconciliation request; and the subsystem receives a reconciliation request sent by the peripheral system.
Step 302: acquiring initial running water data;
step 303: acquiring target running water data;
step 304: and generating a reconciliation file.
It should be noted that between step 301 and step 302, a step of the subsystem checking for error events may also be added. In addition, the specific implementation process of steps 302 to 304 is the same as that of steps 204 to 206 in the above embodiment, and is not described herein again.
On the basis of the embodiment, the peripheral system compares the account checking result with the locally stored running water data and finds that if the account checking file lacks the running water data, transaction resending information can be sent to the subsystem, and after the subsystem receives the transaction resending information, the subsystem generates a response code according to the transaction resending information, wherein the response code is used for prompting a worker to intervene.
According to the embodiment of the application, the response code is generated to prompt the intervention of the worker, so that the request of the peripheral system can be responded in time.
The embodiment of the application provides another method for reconciliation between systems, which comprises the following steps:
step 1: the subsystem obtains a reconciliation request for reconciling the transaction of the peripheral system, wherein the reconciliation request comprises a reconciliation date and identification information of the peripheral system.
Step 2: the subsystem determines a time period needing account checking according to the account checking date;
and step 3: taking the transaction data corresponding to the identification information in the time period as initial flow data;
and 4, step 4: sending a new reconciliation request to the public system, wherein the new reconciliation request comprises a time period needing reconciliation;
and 5: the public system acquires the running data of which the execution state is an unknown state corresponding to the peripheral system according to the new account checking request, and sends the running data of the unknown state to the subsystem;
step 6: after receiving the running water data with unknown state returned by the public system, the subsystem eliminates the running water data with the same state as the running water data with unknown state from the initial running water data to obtain target running water data;
and 7: and the subsystem generates a reconciliation result according to the target running water data.
The embodiment of the application provides another reconciliation method, which comprises the following steps:
step 1: the subsystem obtains a reconciliation request for reconciling the transaction of the peripheral system, wherein the reconciliation request comprises a reconciliation date and identification information of the peripheral system.
Step 2: the subsystem determines a time period needing account checking according to the account checking date;
and step 3: taking the transaction data corresponding to the identification information in the time period as initial flow data, and storing the initial flow data into a database;
and 4, step 4: sending a new reconciliation request to the public system, wherein the new reconciliation request comprises a time period needing reconciliation;
and 5: the public system acquires the running data of which the execution state is an unknown state corresponding to the peripheral system according to the new account checking request, and stores the running data of the unknown state into a database;
step 6: the account checking platform acquires initial running water data and running water data in an unknown state from a database, and eliminates the running water data which is the same as the running water data in the unknown state from the initial running water data to acquire target running water data;
and 7: and the reconciliation platform generates a reconciliation result according to the target running water data.
It should be noted that the reconciliation platform may be disposed in the subsystem, may also be disposed in the public system, and may also be disposed in other systems than the subsystem and the public system in the distributed core business system.
Fig. 4 is a schematic structural diagram of a reconciliation apparatus provided in an embodiment of the present application, where the apparatus may be a module, a program segment, or a code on an electronic device. It should be understood that the apparatus corresponds to the above-mentioned embodiment of the method of fig. 1, and can perform various steps related to the embodiment of the method of fig. 1, and the specific functions of the apparatus can be referred to the description above, and the detailed description is appropriately omitted here to avoid redundancy. The reconciliation device comprises: a request obtaining module 401, a time determining module 402, a pipeline data generating module 403, a data returning module 404 and a reconciliation module 405, wherein:
the request obtaining module 401 is configured to obtain an account checking request for checking an account of a peripheral system, where the account checking request includes an account checking date and identification information of the peripheral system;
the time determining module 402 is configured to determine a time period in which reconciliation is required according to the reconciliation date;
the flow data generation module 403 is configured to use the transaction data in the time period and corresponding to the identification information as initial flow data, and send the initial flow data to the public system;
the data returning module 404 is configured to receive target pipeline data that is returned by the public system and is generated after deleting data in the initial pipeline data, where the transaction execution state is an unknown state;
the reconciliation module 405 is configured to generate a reconciliation result between the systems according to whether the execution state of each transaction in the target pipeline data is complete or incomplete, and send the reconciliation result to the peripheral system.
On the basis of the foregoing embodiment, the time determining module 402 is specifically configured to:
if the reconciliation date is two continuous natural days, taking the starting time of the reconciliation date to 24 points before the current day as a first time period; the end time from 24 o' clock to the reconciliation date is taken as the second time period.
On the basis of the foregoing embodiment, the pipeline data generating module 403 is specifically configured to:
taking the transaction data which is in the first time period and corresponds to the identification information as first running water data;
taking the transaction data which is in the second time period and corresponds to the identification information as second flow data;
taking the first flow data and the second flow data as the initial flow data.
On the basis of the foregoing embodiment, the data returning module 404 is specifically configured to:
receiving third streaming data which is returned by the public system and generated after deleting the data of which the transaction execution state is an unknown state in the first streaming data; fourth running water data generated after the data of which the transaction execution state is the unknown state in the second running water data is deleted;
and sequencing the third running water data and the fourth running water data according to a time sequence to generate the target running water data.
On the basis of the foregoing embodiment, the request obtaining module 401 is specifically configured to:
when a preset period comes, acquiring an account checking request for checking the transaction of the peripheral system; or
And when the account checking request sent by the peripheral system is received, obtaining the account checking request.
On the basis of the above embodiment, the reconciliation apparatus further includes a checking module, configured to determine whether a current network state between the reconciliation apparatus and the public system is normal, and if so, execute the function corresponding to the time determining module 402.
On the basis of the above embodiment, the reconciliation apparatus further includes an information receiving module, configured to:
receiving transaction resending information; the transaction retransmission information is sent after the peripheral system compares the eliminated running water data in the account checking file with local running water data and determines that the account checking file lacks the running water data;
and generating a response code according to the transaction retransmission information.
Fig. 5 is a schematic structural diagram of an entity of an electronic device provided in an embodiment of the present application, and as shown in fig. 5, the electronic device includes: a processor (processor)501, a memory (memory)502, and a bus 503; wherein,
the processor 501 and the memory 502 are communicated with each other through the bus 503;
the processor 501 is configured to call program instructions in the memory 502 to perform the methods provided by the above-mentioned method embodiments, for example, including: the method comprises the steps of obtaining an account checking request for checking the transaction of a peripheral system, wherein the account checking request comprises an account checking date and identification information of the peripheral system; determining a time period needing account checking according to the account checking date; taking the transaction data corresponding to the identification information in the time period as initial flow data and sending the initial flow data to the public system; receiving target running data which is returned by the public system and generated after deleting the data of which the transaction execution state is an unknown state in the initial running data; and generating an account checking result between the systems according to the completion or incompletion of the execution state of each transaction in the target running data, and sending the account checking result to a peripheral system.
The processor 501 may be an integrated circuit chip having signal processing capabilities. The Processor 501 may be a general-purpose Processor, including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. Which may implement or perform the various methods, steps, and logic blocks disclosed in the embodiments of the present application. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
The Memory 502 may include, but is not limited to, Random Access Memory (RAM), Read Only Memory (ROM), Programmable Read Only Memory (PROM), Erasable Read Only Memory (EPROM), Electrically Erasable Read Only Memory (EEPROM), and the like.
The present embodiment discloses a computer program product comprising a computer program stored on a non-transitory computer readable storage medium, the computer program comprising program instructions which, when executed by a computer, enable the computer to perform the method provided by the above-mentioned method embodiments, for example, comprising: the method comprises the steps of obtaining an account checking request for checking the transaction of a peripheral system, wherein the account checking request comprises an account checking date and identification information of the peripheral system; determining a time period needing account checking according to the account checking date; taking the transaction data corresponding to the identification information in the time period as initial flow data and sending the initial flow data to the public system; receiving target running data which is returned by the public system and generated after deleting the data of which the transaction execution state is an unknown state in the initial running data; and generating an account checking result between the systems according to the completion or incompletion of the execution state of each transaction in the target running data, and sending the account checking result to a peripheral system.
The present embodiments provide a non-transitory computer-readable storage medium storing computer instructions that cause the computer to perform the methods provided by the above method embodiments, for example, including: the method comprises the steps of obtaining an account checking request for checking the transaction of a peripheral system, wherein the account checking request comprises an account checking date and identification information of the peripheral system; determining a time period needing account checking according to the account checking date; taking the transaction data corresponding to the identification information in the time period as initial flow data and sending the initial flow data to the public system; receiving target running data which is returned by the public system and generated after deleting the data of which the transaction execution state is an unknown state in the initial running data; and generating an account checking result between the systems according to the completion or incompletion of the execution state of each transaction in the target running data, and sending the account checking result to a peripheral system.
In another embodiment, the present application further provides a distributed core system, where the distributed core system includes a common system and at least one subsystem, and the common system is communicatively connected to each subsystem. Each subsystem is capable of performing the methods provided by the various method embodiments described above.
In the embodiments provided in the present application, it should be understood that the disclosed apparatus and method may be implemented in other ways. The above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one logical division, and there may be other divisions when actually implemented, and for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection of devices or units through some communication interfaces, and may be in an electrical, mechanical or other form.
In addition, units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
Furthermore, the functional modules in the embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.
In this document, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions.
The above description is only an example of the present application and is not intended to limit the scope of the present application, and various modifications and changes may be made by those skilled in the art. Any modification, equivalent replacement, improvement and the like made within the spirit and principle of the present application shall be included in the protection scope of the present application.
Claims (12)
1. A reconciliation method applied to a subsystem in a distributed core service system, the method comprising:
the method comprises the steps of obtaining an account checking request for checking the transaction of a peripheral system, wherein the account checking request comprises an account checking date and identification information of the peripheral system;
determining a time period needing account checking according to the account checking date;
taking the transaction data corresponding to the identification information in the time period as initial flow data and sending the initial flow data to the public system;
receiving target running data which is returned by the public system and generated after deleting the data of which the transaction execution state is an unknown state in the initial running data;
and generating an account checking result between the systems according to the completion or incompletion of the execution state of each transaction in the target running data, and sending the account checking result to a peripheral system.
2. The method of claim 1, wherein determining the period of time requiring reconciliation based on the reconciliation date comprises:
if the reconciliation date is two continuous natural days, taking the starting time of the reconciliation date to 24 points before the current day as a first time period; the end time from 24 o' clock to the reconciliation date is taken as the second time period.
3. The method of claim 2, wherein the using the transaction data corresponding to the identification information and within the time period as initial pipelining data comprises:
taking the transaction data which is in the first time period and corresponds to the identification information as first running water data;
taking the transaction data which is in the second time period and corresponds to the identification information as second flow data;
taking the first flow data and the second flow data as the initial flow data.
4. The method of claim 3, wherein the receiving target pipeline data returned by the common system and generated after deleting data in the initial pipeline data whose transaction execution state is unknown comprises:
receiving third streaming data which is returned by the public system and generated after deleting the data of which the transaction execution state is an unknown state in the first streaming data; fourth running water data generated after the data of which the transaction execution state is the unknown state in the second running water data is deleted;
and sequencing the third running water data and the fourth running water data according to a time sequence to generate the target running water data.
5. The method of claim 1, wherein obtaining a reconciliation request for reconciling transactions with the peripheral system comprises:
when a preset period comes, acquiring an account checking request for checking the transaction of the peripheral system; or
And when the account checking request sent by the peripheral system is received, obtaining the account checking request.
6. The method of claim 1, further comprising:
and judging whether the current network state between the public system and the public system is normal, and if so, executing the step of determining the time period needing account checking according to the account checking date.
7. An inter-system reconciliation apparatus, wherein the reconciliation apparatus is a subsystem in a distributed core service system, and the reconciliation apparatus comprises:
the system comprises a request obtaining module, a reconciliation processing module and a reconciliation processing module, wherein the request obtaining module is used for obtaining a reconciliation request for reconciling a peripheral system, and the reconciliation request comprises a reconciliation date and identification information of the peripheral system;
the time determining module is used for determining the time period needing account checking according to the account checking date;
the flow data generation module is used for taking the transaction data which is in the time period and corresponds to the identification information as initial flow data and sending the initial flow data to the public system;
the data return module is used for receiving target flow data which is returned by the public system and is generated after the data with the transaction execution state being the unknown state in the initial flow data is deleted;
and the reconciliation module is used for generating a reconciliation result between the systems according to the completion or incompletion of the execution state of each transaction in the target flow data and sending the reconciliation result to the peripheral system.
8. An intersystem reconciliation method, applied to a subsystem in a distributed core service system, includes:
obtaining a first reconciliation request for reconciling a transaction of a peripheral system, wherein the reconciliation request comprises a reconciliation date and identification information of the peripheral system;
determining a time period needing account checking according to the account checking date;
taking the transaction data which is in the time period and corresponds to the identification information as initial flow data;
initiating a new second account checking request to a public system, wherein the second account checking request is used for enabling the public system to search the running data of which the execution state corresponding to the peripheral system is unsuccessful;
receiving the running data which is returned by the public system and of which the execution state is unsuccessful, and eliminating the data in the initial running data according to the running data of which the execution state is unsuccessful to obtain target running data;
and generating an account checking result between the systems according to the completion or incompletion of the execution state of each transaction in the target running data, and sending the account checking result to a peripheral system.
9. An inter-system reconciliation method is applied to a reconciliation subsystem in a distributed core service system, and comprises the following steps:
the method comprises the steps of obtaining an account checking request for checking the transaction of a peripheral system, wherein the account checking request comprises an account checking date and identification information of the peripheral system;
sending the reconciliation request to a subsystem so that the subsystem determines a time period needing reconciliation according to the reconciliation date, acquires initial running data according to the time period and the identification information, and sends the reconciliation request to a public system so that the public system acquires the running data of which the execution state is unsuccessful according to the reconciliation request and the time period and the identification information;
receiving the initial pipeline data returned by the subsystem and the pipeline data returned by the public system with the unsuccessful execution state, and performing elimination operation on the initial pipeline data according to the pipeline data with the unsuccessful execution state to obtain target pipeline data;
and generating an account checking result between the systems according to the completion or incompletion of the execution state of each transaction in the target running data, and sending the account checking result to a peripheral system.
10. A subsystem, comprising: a processor, a memory, and a bus, wherein,
the processor and the memory are communicated with each other through the bus;
the memory stores program instructions executable by the processor, the processor invoking the program instructions to perform the method of any of claims 1-9.
11. A non-transitory computer-readable storage medium storing computer instructions which, when executed by a computer, cause the computer to perform the method of any one of claims 1-9.
12. A distributed core system comprising the subsystems and the common system of claim 10.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111116761.XA CN113793211A (en) | 2021-09-23 | 2021-09-23 | Inter-system account checking method, device, subsystem, storage medium and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111116761.XA CN113793211A (en) | 2021-09-23 | 2021-09-23 | Inter-system account checking method, device, subsystem, storage medium and system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN113793211A true CN113793211A (en) | 2021-12-14 |
Family
ID=79184221
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111116761.XA Pending CN113793211A (en) | 2021-09-23 | 2021-09-23 | Inter-system account checking method, device, subsystem, storage medium and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113793211A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114881778A (en) * | 2022-04-19 | 2022-08-09 | 北京理房通支付科技有限公司 | Cross-system data processing method and device |
| CN114997979A (en) * | 2022-06-14 | 2022-09-02 | 江苏银承网络科技股份有限公司 | Electronic transaction reconciliation method, device and storage medium |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20180075525A1 (en) * | 2016-09-09 | 2018-03-15 | Microsoft Technology Licensing, Llc | Commerce Payment Reconciliation System |
| CN109934712A (en) * | 2019-01-30 | 2019-06-25 | 网联清算有限公司 | Account checking method, account checking apparatus and electronic equipment applied to distributed system |
| CN110223153A (en) * | 2019-04-17 | 2019-09-10 | 深圳壹账通智能科技有限公司 | Account checking method, device, electronic equipment and storage medium |
| CN110544164A (en) * | 2019-08-27 | 2019-12-06 | 中信百信银行股份有限公司 | Full link account checking method and system |
| CN111400379A (en) * | 2020-02-19 | 2020-07-10 | 北京值得买科技股份有限公司 | Multi-party account checking processing method and device |
| CN112907346A (en) * | 2021-03-31 | 2021-06-04 | 中国工商银行股份有限公司 | Account checking data processing method and device |
-
2021
- 2021-09-23 CN CN202111116761.XA patent/CN113793211A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20180075525A1 (en) * | 2016-09-09 | 2018-03-15 | Microsoft Technology Licensing, Llc | Commerce Payment Reconciliation System |
| CN109934712A (en) * | 2019-01-30 | 2019-06-25 | 网联清算有限公司 | Account checking method, account checking apparatus and electronic equipment applied to distributed system |
| CN110223153A (en) * | 2019-04-17 | 2019-09-10 | 深圳壹账通智能科技有限公司 | Account checking method, device, electronic equipment and storage medium |
| CN110544164A (en) * | 2019-08-27 | 2019-12-06 | 中信百信银行股份有限公司 | Full link account checking method and system |
| CN111400379A (en) * | 2020-02-19 | 2020-07-10 | 北京值得买科技股份有限公司 | Multi-party account checking processing method and device |
| CN112907346A (en) * | 2021-03-31 | 2021-06-04 | 中国工商银行股份有限公司 | Account checking data processing method and device |
Non-Patent Citations (1)
| Title |
|---|
| 黄文平: "银行电子化系统整合研究", 《中国优秀硕士学位论文全文数据库（电子期刊）社会科学Ⅰ辑(经济政治与法律)》 * |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114881778A (en) * | 2022-04-19 | 2022-08-09 | 北京理房通支付科技有限公司 | Cross-system data processing method and device |
| CN114997979A (en) * | 2022-06-14 | 2022-09-02 | 江苏银承网络科技股份有限公司 | Electronic transaction reconciliation method, device and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111369350B (en) | Method and device for processing punching quadrature | |
| CN111045794B (en) | Distributed transaction processing method, device, system, computer equipment and storage medium | |
| CN110310020B (en) | Project scheme management method based on data analysis, related device and storage medium | |
| CN113793211A (en) | Inter-system account checking method, device, subsystem, storage medium and system | |
| CN110610414A (en) | Data processing method and system | |
| CN112437000A (en) | Message queue pushing method and device, computer equipment and storage medium | |
| CN112907344A (en) | Accounting data processing method and device, electronic equipment and storage medium | |
| CN111651494A (en) | Data processing method, device, equipment and computer readable storage medium | |
| CN114170023A (en) | Method and device for testing fund transaction operation platform system | |
| CN111444213B (en) | Ledger clearing system and method based on credit business | |
| CN107169767B (en) | Transaction processing method and system | |
| CN111400283B (en) | Data processing method, system, electronic equipment and storage medium | |
| CN111127088B (en) | Method, device, computer equipment and storage medium for realizing final consistency | |
| CN116226144A (en) | Data processing method and device, computer readable storage medium and electronic equipment | |
| CN114185900A (en) | Service data processing method and device, computer equipment and storage medium | |
| CN114969077A (en) | Service data processing method and device | |
| CN116302652A (en) | System alarm information processing method and device and electronic equipment | |
| CN115879889A (en) | Service processing method and device based on block chain and computer equipment | |
| CN114968498A (en) | Distributed transaction processing method and device | |
| CN115510366A (en) | Business message pushing method and device, computer equipment and storage medium | |
| CN114490678A (en) | Abnormal account data processing method, device, equipment and medium | |
| CN113111631B (en) | Data processing method, apparatus, device, storage medium, and program product | |
| CN116188190B (en) | Multi-batch semi-real-time reconciliation method and system for high-concurrency payment system | |
| CN110716930A (en) | Numerical value transfer method, apparatus, computer equipment and storage medium | |
| CN114020611B (en) | Test data monitoring processing method and device, computer equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20211214 |