A method, device and medium for processing inter-system account deletion business

Abstract

This application relates to the field of business processing and specifically discloses a method, device, and medium for processing inter-system account erasure transactions. The method comprises: downloading first transaction detail data from an upstream bank and generating a detail internal code based on the transaction serial number corresponding to each transaction detail; obtaining second transaction detail data returned by the upstream bank at preset intervals based on the same search dimension; determining the account-erased transaction details in the second transaction detail data; determining the original transaction details corresponding to the account-erased transaction details in the first transaction detail data based on the detail internal code corresponding to the account-erased transaction details; and processing the account-erased transaction details and the original transaction details. While ensuring that data in the current system is correctly processed, the method can also be transmitted to further downstream systems, so that the further downstream systems have the foundation for properly processing the account-erased data.

Description

Technical Field

[0001] The present application relates to the field of business processing, and specifically to a method, device and medium for processing inter-system account deletion business. Background Art

[0002] With the advancement of information technology, the speed at which data assets are transferred between heterogeneous systems has increased, creating challenges in handling erroneous data. After upstream systems publish data, it's quickly received, processed, and forwarded to downstream systems. Adjustments to erroneous data in upstream systems inevitably impact downstream systems. In today's interconnected heterogeneous system landscape, various issues can distort data in downstream systems. These issues include data modifications in upstream systems that are unaware of them, data that cannot be updated after the upstream system has already processed the changes, and data that cannot be updated after the downstream system has already passed the data. Furthermore, downstream systems can pass the data down the chain but fail to notify further downstream systems of the changes.

[0003] A typical scenario for this problem arises in the transmission of transaction details between banks' direct bank-enterprise systems and treasury systems. To maintain the relative independence of their systems, banks typically provide data to accessors through a censored mechanism, whereby the accessors proactively query transaction details from the banks. However, for various business reasons, banks may erase already published transaction details without notifying the accessor systems. At the system interface level, these erased transaction details either disappear or are marked as erased. While the accessor systems are aware of these changes, they are unable to effectively process the data. This is primarily due to the erased transaction details having already been processed by their own systems, transmitted to downstream systems, or both. In the financial sector, this often leads to data errors. Summary of the Invention

[0004] To solve the above problems, this application proposes a method, device, and medium for processing inter-system account deletion services, wherein the method includes:

[0005] Download the first transaction detail data from the upstream bank and compile a detail internal code based on the transaction serial number corresponding to each transaction detail; obtain the second transaction detail data returned by the upstream bank based on the same search dimension at preset intervals; determine the erased transaction details in the second transaction detail data; determine the original transaction details corresponding to the erased transaction details in the first transaction detail data based on the detail internal code corresponding to the erased transaction details; and process the erased transaction details and the original transaction details.

[0006] In one example, the preparation of the detail internal code based on the core accounting serial number corresponding to each transaction detail specifically includes: based on the first transaction detail data, determining the transaction serial number, transaction date, transaction account number, debit / credit mark, transaction amount, and post-transaction balance corresponding to each transaction detail; the transaction account number includes at least one of a buyer's account and a seller's account; based on the transaction serial number, transaction date, transaction account number, debit / credit mark, transaction amount, and post-transaction balance, preparing the detail internal code corresponding to each transaction detail.

[0007] In one example, after compiling the detail internal code according to the transaction serial number corresponding to each transaction detail, the method also includes: determining the transaction detail status and transaction detail mark corresponding to each transaction detail; the transaction detail status includes normal status, erased status and erased status.

[0008] In one example, determining the transaction details to be erased in the second transaction details data specifically includes: generating a detail internal code corresponding to each transaction detail in the second transaction details data; determining the transaction details to be selected in the second transaction details; based on the detail internal code of the transaction details to be selected, determining the control transaction of the transaction details to be selected in the first transaction details data; if the transaction details status of the control transaction is normal, then the transaction details to be selected are the transaction details to be erased.

[0009] In one example, determining the transaction details to be selected in the second transaction details specifically includes: determining the first transaction details to be selected that have a bank cancellation mark in the second transaction details data; and determining the second transaction details to be selected that exist in the first transaction details data but do not exist in the second transaction details data by comparing the detail internal codes of the first transaction details data and the second transaction details data.

[0010] In one example, determining the second transaction detail to be selected that exists in the first transaction detail data but does not exist in the second transaction detail data specifically includes: determining the first transaction detail that does not exist in the second transaction detail data but exists in the first transaction detail data under the same dimension; copying the first transaction detail to generate the second transaction detail to be selected.

[0011] In one example, the processing of the erasure transaction details and the original transaction details specifically includes: setting the erasure status of the original transaction details to the erased status, and setting the erasure status of the erasure transaction details to the erased status; splicing the detail internal codes of the erasure transaction details and the original transaction details with the erasure status to distinguish the detail internal codes of the erasure transaction details from the original transaction details; setting the transaction detail mark of the erasure transaction details to a virtual detail; and if the original transaction details have been processed, performing reverse processing based on the erasure transaction details.

[0012] In one example, after processing the cancellation transaction details and the original transaction details, the method further includes: determining that the processing of the first transaction detail data and the second transaction detail data is completed; and transmitting the processed transaction detail data and the corresponding transaction detail status and transaction detail mark to a downstream system.

[0013] The present application also provides an inter-system account erasure business processing method and device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute: downloading first transaction detail data of an upstream bank, and compiling a detail internal code according to the transaction serial number corresponding to each transaction detail; obtaining second transaction detail data returned by the upstream bank based on the same retrieval dimension at preset intervals; determining the account erasure transaction details in the second transaction detail data; determining the original transaction details corresponding to the account erasure transaction details in the first transaction detail data based on the detail internal code corresponding to the account erasure transaction details; and processing the account erasure transaction details and the original transaction details.

[0014] The present application also provides a non-volatile computer storage medium storing computer-executable instructions, characterized in that the computer-executable instructions are configured to: download first transaction detail data of an upstream bank, and compile a detail internal code according to the transaction serial number corresponding to each transaction detail; obtain second transaction detail data returned by the upstream bank based on the same search dimension at preset intervals; determine the erased transaction details in the second transaction detail data; determine the original transaction details corresponding to the erased transaction details in the first transaction detail data based on the detail internal code corresponding to the erased transaction details; and process the erased transaction details and the original transaction details.

[0015] The method proposed in this application can achieve the following beneficial effects: by comparing transaction details under the same search dimension, it can determine the erased transaction details contained in all transaction details issued by the bank, and then process the erased transaction details accordingly. Furthermore, by using the transaction detail status and transaction detail tag corresponding to each transaction detail, it can ensure that the data in the current system is correctly processed while also being passed to downstream systems, so that these downstream systems have the foundation to properly process the erased data. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0017] Figure 1 A flowchart of a method for processing inter-system account deletion services in an embodiment of the present application is shown;

[0018] Figure 2 This is a structural diagram of an inter-system account deletion business processing device in an embodiment of the present application. DETAILED DESCRIPTION

[0019] To make the purpose, technical solutions, and advantages of this application more clear, the technical solutions of this application will be clearly and completely described below in conjunction with the specific embodiments of this application and the corresponding drawings. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0020] The following describes in detail the technical solutions provided by various embodiments of the present application in conjunction with the accompanying drawings.

[0021] Figure 1 This is a flowchart illustrating a method for processing inter-system account cancellations, as provided in one or more embodiments of this specification. This method can be applied to various business areas, such as internet finance and e-commerce. The process can be executed by computing devices in the corresponding fields (e.g., risk control servers or smart mobile terminals for payment services). Certain input parameters or intermediate results in the process can be manually adjusted to improve accuracy.

[0022] The analysis method involved in the embodiments of the present application can be implemented by a terminal device or a server, and the present application does not impose any special restrictions on this. For ease of understanding and description, the following embodiments are described in detail using a server as an example.

[0023] It should be noted that the server can be a single device or a system composed of multiple devices, that is, a distributed server, and this application does not make any specific restrictions on this.

[0024] like Figure 1 As shown, the embodiment of the present application provides a method for processing inter-system account deletion business, including:

[0025] S101: Download the first transaction details data of the upstream bank, and compile the detail internal code according to the transaction serial number corresponding to each transaction detail.

[0026] First, on the transaction date, use the full transaction details query interface provided by the bank to download the transaction details as the first transaction details data. Then, based on the bank transaction serial number, generate a detailed internal code for each transaction detail in the first transaction details data as an identity identifier.

[0027] It should be noted that bank transaction serial numbers may be duplicated, so it is necessary to generate detailed internal codes within the enterprise to prevent duplicate transaction detail identifiers, which could lead to data overwriting, data loss, data duplication, etc. It should be noted that the bank system and downstream systems here are heterogeneous.

[0028] In one embodiment, to prevent duplication of detail internal codes, the transaction serial number, transaction date, transaction account number, debit / credit indicator, transaction amount, and post-transaction balance corresponding to each transaction detail can be obtained when compiling the detail internal code. These factors are then incorporated into the detail internal code to prevent duplication of detail internal codes. The transaction account number can be either the buyer's account or the seller's account, without limitation.

[0029] S102: At preset time intervals, based on the same search dimension, obtain the second transaction details data returned by the upstream bank.

[0030] After a preset time interval, the query of the same dimension is executed again to obtain the second transaction detail data returned by the upstream bank.

[0031] It should be noted that the retrieval dimensions of the first transaction details data and the second transaction details data are the same, that is, the corresponding transaction details occur at the same time and the corresponding transaction accounts are the same. If the upstream bank does not cancel the account, the first transaction details data and the second transaction details data should be exactly the same.

[0032] S103: Determine the account cancellation transaction details in the second transaction detail data.

[0033] At this time, the server will compare the first transaction details data and the second transaction details data provided by the bank for the same search dimension to determine the transaction details of the cancellation transaction in the second transaction details data. Here is an explanation of the transaction details of the cancellation transaction:

[0034] This application sets the status, attributes, and flags corresponding to each transaction detail based on the bank interface documentation provided by the bank. Transaction detail status includes normal, erased, and cancelled. Normal indicates that the transaction is normal and no cancellation has occurred; erased indicates that the transaction details have already been cancelled at the bank when they were retrieved; and cancelled indicates that the transaction details have been cancelled at the bank, but the cancelled transaction was read by the system before the cancellation occurred. Distinguishing between cancelled and cancelled transactions is a key feature of this application. The term "cancelled transaction" here refers to transactions with a cancelled status. It should be noted that after a bank cancels a transaction detail, the transaction detail data may disappear directly or be marked with an cancelled flag. Therefore, it is sometimes possible to directly determine the cancelled transaction details based on the cancellation flag attached to the transaction detail data, but in this case, it is important to distinguish between cancelled and cancelled transaction details. If the cancellation flag is not present, the first and second transaction details are compared to determine the cancellation transaction details. The cancellation transaction details will only appear in the later-acquired transaction details, not in the earlier-acquired transaction details.

[0035] The transaction detail tag is used to identify transaction details generated by non-bank parties as part of this solution, marking them as virtual transaction details. These virtual transaction details are used for account cancellation processing and to ensure the authenticity of transaction details. For example, if the system only wants to display data returned by the upstream bank system, the virtual detail tag can be used for data filtering.

[0036] In one embodiment, when determining the transaction details to be erased, it is necessary to generate a detail internal code corresponding to each transaction detail in the second transaction detail data, determine the transaction details to be selected in the second transaction details, and then, based on the detail internal code of the selected transaction details, determine the reference transaction for the selected transaction details in the first transaction detail data. If the transaction details of the reference transaction are in a normal state, the transaction details to be selected are the erased transaction details. If the transaction details of the reference transaction are in an erased state, the transaction details to be selected are the erased transaction details.

[0037] Furthermore, the transaction details to be selected here include a first transaction detail to be selected that has a bank cancellation flag in the transaction details data, and a second transaction detail to be selected that exists in the first transaction details data but not in the second transaction details data. It should be noted that if, within the same dimension, a first transaction detail exists in the first transaction details data but not in the second transaction details data, the first transaction detail needs to be copied to generate the second transaction detail to be selected. Simultaneously, the first transaction detail in the first transaction details data is set to the cancelled state, and the second transaction detail to be selected is set to the cancelled state.

[0038] S104: Based on the detail internal code corresponding to the account-erasing transaction detail, determine the original transaction detail corresponding to the account-erasing transaction detail in the first transaction detail data.

[0039] After determining the cancellation transaction details, it is necessary to find the original transaction details corresponding to the cancellation transaction details in the first transaction detail data.

[0040] At the same time, after finding the original transaction details corresponding to the erased transaction details, the attributes of the erased transaction details can be changed, that is, the erased detail identifier of the erased transaction details can be changed to the original identifier of the original transaction details.

[0041] For example, a bank has a transaction record with a core accounting serial number of 123456 and a server status of "Normal." A downstream system receives and processes this transaction. Later, the bank cancels the transaction without notifying the downstream system. A subsequent query identifies the canceled transaction and generates a new transaction record with a server status of "Canceled." In this new transaction record, the "Canceled" record identifier is set to 123456 (the original identifier of the canceled transaction). The system can then use the "Canceled" record identifier to locate the original transaction and perform reverse processing (such as reversing the transaction).

[0042] S105: Processing the transaction details of the account cancellation and the original transaction details.

[0043] In one embodiment, when processing both the erased transaction details and the original transaction details, the erased status of the original transaction details needs to be set to "erased," and the erased status of the erased transaction details needs to be set to "erased." Simultaneously, the internal codes of the erased transaction details and the original transaction details are concatenated with the erased status to distinguish the erased transaction details from the internal codes of the original transaction details. For example, the character "Y" is added before the internal code of the original transaction details to indicate that the details of the original transaction details are in the "erased" state. The transaction detail flag of the erased transaction details is then set to "virtual." If the original transaction details have already been processed, reverse processing is performed based on the erased transaction details.

[0044] It should be noted that this system cannot disclose historical transaction details to downstream systems before the historical details data processing is completed, otherwise it may mislead downstream systems.

[0045] The inter-system account cancellation business processing method provided by this application is now illustrated by an example: This application does not limit the time span for downloading transaction details from the bank, but under normal circumstances, the time span is one day. In order to avoid data differences caused by system disconnection, the first transaction details data and the second transaction details data are usually obtained on the day the transaction details occur and one day after the transaction details occur, respectively.

[0046] When obtaining the first transaction details data, on the transaction date, use the full transaction details query interface provided by the bank to download the transaction details, and identify each transaction detail according to the transaction detail identifier clearly stated in the bank's interface document, and identify the transaction details of the account cancellation according to the instructions in the bank's interface document; if the bank's interface document does not explain the transaction details of the account cancellation, it will not be processed.

[0047] If the bank's interface document contains a transaction cancellation indication, the cancellation transaction entry can be identified during the initial query of the transaction details and the transaction details can be directly set to "cancelled." If the bank's interface document does not contain a cancellation transaction, the bank will not return a "cancelled" status. Therefore, this process is appropriate for transaction details returned by the bank with a cancellation indication. This system simply records the "cancelled" status of the transaction details without processing them and provides this status to downstream systems.

[0048] When obtaining the second transaction detail data, execute the query of the same dimension again, and identify each transaction detail according to the transaction detail identifier clearly stated in the bank interface document. For transaction details with bank cancellation identifiers, query in the existing data according to the identity identifier. If the detail already exists in the existing data, it means that the transaction detail was cancelled by the bank after being read back by the system. The identity identifier of this transaction detail can be spliced and cancelled. The status of this transaction detail (cancelled transaction detail) is set to cancelled, the mark of this transaction detail is set to virtual detail, and the cancelled detail identifier of this transaction detail is set to the bank serial number of the original transaction detail.

[0049] The system uses the erased status to identify instances where details were previously erased after being read normally. The erased detail identifier is used to locate the erased transaction details. If the transaction details have already been further processed by the system, the corresponding reverse processing can be performed. The system can also use transaction records with the erased status as the source for reverse processing. Since the serial number of the erased transaction is recorded on the erased transaction, this allows the system to automatically perform reverse processing.

[0050] For transaction details returned by the bank during re-query that have an account cancellation mark, if the mark is not found in the system, the transaction details will be processed according to the logic of the first query, i.e. the transaction details status will be set to "erased". The system's processing of the erased transaction details is the same as the first query and will not be repeated here.

[0051] The data returned by this query is then compared with the data from the previous query based on the transaction identifier in the bank's interface document. Data that existed in the previous query but not in the current one is considered an "offset" transaction. A new transaction detail is created based on the existing data, with the same business elements as the original transaction. Its status is set to "offset," and the "offset" serial number attribute is the identifier of the existing detail. The newly created transaction detail is identified by combining the existing transaction detail identifier with the "offset" identifier, and the transaction flag is set to "virtual." This system treats this transaction detail the same way as the bank can return an "offset" identifier, so I won't go into detail here.

[0052] Executing the above query multiple times on the transaction date allows for relatively real-time identification of various erasure scenarios and prompt processing. For erasures that occur later than the transaction date, or due to force majeure factors such as network outages, preventing a complete picture of the erasure event on the same day, it is necessary to issue another query after the transaction date to fully capture the event. This supplementary query can be issued any day after the transaction date, not limited to T+1.

[0053] When submitting historical transaction details to a bank, the bank has three strategies for returning the erased data: returning no data, returning all data, and returning only the erased data. The following describes the processing steps for each solution.

[0054] If the transaction details for a transaction date are recorded but the cancellation is not recorded (i.e., the transaction details are in a normal state and the bank does not return the cancellation transaction details), the system can identify that the historical details are less than the current day's details based on the bank's returned details flag. This is considered a bank cancellation, and the transaction that requires the current day's query is "created" with two transactions: one that completely replicates the current day's query details and has the status set to "Erased"; the other transaction details are set to "Erased" and the erased transaction details are marked as the normal one. Both transaction details are marked as virtual. The system can detect the occurrence of an cancellation based on the record in the historical details with the status of "Erased". The processing process is similar to the processing of cancellations in the current day's details and will not be further described here. It is important to note that the system cannot disclose historical transaction details to downstream systems before the historical details are processed, as this may mislead downstream systems.

[0055] In the case where the bank returns all erased transactions, that is, when the bank returns two transaction records, one for the erased transaction and one for the erased transaction, the comparison with the current day's details will only reveal that the historical details have one more erased transaction detail than the current day's details. In fact, all processing operations on the detail data only target this extra transaction detail. The processing of the erased transaction detail is the same as for the unerased transaction records. Specifically, the status of the erased transaction record is set to "Erased", and the status of the erased transaction detail is set to "Erased". The erased transaction record number is recorded as the serial number of the normal transaction detail. The markers for the erased and erased transaction details are not recorded, and the data is considered normal. At this point, the system can process the data based on the erased status, which will not be further explained.

[0056] In the scenario where the bank only returns the transaction details of the erased account, by comparison, it can be found that the status of the current day's details is normal, while the historical details are in the erased state. In this case, it is necessary to create an erased transaction, that is, copy the business data of the current day's details, set the status to erased, set the mark to virtual details, set the status of this data returned by the historical details query to erased, set the erased transaction mark to the transaction mark of the normal state, and do not set the mark.

[0057] In the case where the erased transaction details of the day are not recorded and the bank does not return the erased details at all, no difference can be found when comparing the historical details with the details of the day based on the detail identifier, so no processing is required; in the case where the bank returns all the details, it can be identified by comparing with the details of the day that both do not exist, and the status of the erased transaction details is set to erased, the flow status of the erased transaction details is set to erased, the erased transaction identifier attribute is recorded, and the erased transaction details identifier is set to the normal detail identifier spliced with the erased identifier; in the case where the bank only returns the erased flow, it can be identified by comparing with the details of the day, such as the "normal" mark of the original transaction details as "virtual" in the above method, and the current detail is set to the erased status, the attribute of the erased details is recorded as the virtual transaction details identifier, and the current detail identifier is the virtual transaction details identifier spliced with the erased flag.

[0058] By setting the transaction detail status, the erased detail identification, and the virtual transaction detail mark, this system can use a set of processing logic to identify the bank's various processing modes for erased transaction details. While ensuring that the data in this system is processed correctly, these three elements can also be passed to downstream systems so that downstream systems have the basis for normal processing of erased data.

[0059] like Figure 2 As shown, the embodiment of the present application also provides an inter-system account deletion service processing device, including:

[0060] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to:

[0061] Download the first transaction detail data from the upstream bank and compile a detail internal code based on the transaction serial number corresponding to each transaction detail; obtain the second transaction detail data returned by the upstream bank based on the same search dimension at preset intervals; determine the erased transaction details in the second transaction detail data; determine the original transaction details corresponding to the erased transaction details in the first transaction detail data based on the detail internal code corresponding to the erased transaction details; and process the erased transaction details and the original transaction details.

[0062] The embodiment of the present application further provides a non-volatile computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured to:

[0063] Download the first transaction detail data from the upstream bank and compile a detail internal code based on the transaction serial number corresponding to each transaction detail; obtain the second transaction detail data returned by the upstream bank based on the same search dimension at preset intervals; determine the erased transaction details in the second transaction detail data; determine the original transaction details corresponding to the erased transaction details in the first transaction detail data based on the detail internal code corresponding to the erased transaction details; and process the erased transaction details and the original transaction details.

[0064] The various embodiments in this application are described in a progressive manner. Similar portions between the various embodiments can be referred to in conjunction with each other. Each embodiment focuses on the differences between the other embodiments. In particular, the device and medium embodiments are generally similar to the method embodiments, so their descriptions are relatively simple. For relevant portions, refer to the descriptions of the method embodiments.

[0065] The devices and media provided in the embodiments of the present application correspond one-to-one to the methods. Therefore, the devices and media also have similar beneficial technical effects to their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the devices and media will not be repeated here.

[0066] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0067] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0068] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0069] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0070] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0071] Memory may include non-permanent storage in a computer-readable medium, in the form of random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0072] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can be implemented using any method or technology to store information. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change RAM (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media such as modulated data signals and carrier waves.

[0073] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0074] The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.

Claims

1. A method for processing inter-system account deletion business, characterized in that: include: Download the first transaction details data from the upstream bank and compile the details internal code according to the transaction serial number corresponding to each transaction detail; At preset intervals, based on the same search dimension, obtain the second transaction details returned by the upstream bank; Determining the cancellation transaction details in the second transaction detail data; determining, based on the detail internal code corresponding to the transaction detail of the account-erased transaction, the original transaction detail corresponding to the transaction detail of the account-erased transaction in the first transaction detail data; Processing the transaction details of the account cancellation and the original transaction details; After compiling the transaction internal code according to the transaction serial number corresponding to each transaction detail, the method further includes: Determine the transaction detail status and transaction detail mark corresponding to each transaction detail; The transaction details status includes normal status, erased status and erased status; Determining the account cancellation transaction details in the second transaction detail data specifically includes: generating a detail internal code corresponding to each transaction detail in the second transaction detail data; determining a transaction detail to be selected from the second transaction detail; Determining a reference transaction for the transaction detail to be selected in the first transaction detail data based on the detail internal code of the transaction detail to be selected; If the transaction details of the comparison transaction are in a normal state, the transaction details to be selected are the cancellation transaction details; The determining of the transaction details to be selected in the second transaction details specifically includes: Determining a first candidate transaction detail containing a bank cancellation mark in the second transaction detail data; Determining a second transaction detail to be selected that exists in the first transaction detail data but does not exist in the second transaction detail data by comparing the detail internal codes of the first transaction detail data and the second transaction detail data; The determining of the second transaction details to be selected that exist in the first transaction details data but do not exist in the second transaction details data specifically includes: determining, under the same dimension, first transaction details that are not present in the second transaction detail data but are present in the first transaction detail data; Copying the first transaction details to generate the second transaction details to be selected; The processing of the transaction details of the account cancellation and the original transaction details specifically includes: Setting the erasure status of the original transaction details to the erased state, and setting the erasure status of the erasure transaction details to the erased state; splicing the internal code of the transaction details and the original transaction details with the erasure status to distinguish the internal code of the transaction details and the original transaction details; Setting the transaction detail mark of the transaction details to be virtual details; If the original transaction details have been processed, reverse processing is performed based on the cancellation transaction details.

2. The method according to claim 1, characterized in that The process of compiling a detailed internal code based on the transaction serial number corresponding to each transaction detail specifically includes: Based on the first transaction details data, determining the transaction serial number, transaction date, transaction account number, debit / credit indicator, transaction amount, and post-transaction balance corresponding to each transaction detail; the transaction account number includes at least one of a buyer's account and a seller's account; Based on the transaction serial number, transaction date, transaction account number, debit / credit mark, transaction amount, and post-transaction balance, a detailed internal code corresponding to each transaction detail is compiled.

3. The method according to claim 1, characterized in that After processing the transaction details of the account cancellation and the original transaction details, the method further includes: Determining that processing of the first transaction detail data and the second transaction detail data is complete; The processed transaction detail data, the corresponding transaction detail status and the transaction detail tag are passed to the downstream system.

4. A method and device for processing inter-system account deletion business, characterized in that: include: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the steps of the method according to any one of claims 1 to 3.

5. A non-volatile computer storage medium storing computer-executable instructions, characterized in that: The computer executable instructions are configured to perform the steps of the method according to any one of claims 1 to 3.

Images