Daily switching method and device of bank distributed core system, medium and bank system

Abstract

The invention provides a daily switching method and device of a bank distributed core system, a medium and a bank system. The method comprises the following steps: acquiring a transaction code, an accounting date permission mode code and an accounting date use mode code; according to the date permission mode code and the accounting date use mode code, determining that a target transaction date of the core system is a transaction date of the core system or an accounting date of the peripheral system, the target transaction date being a transaction date corresponding to the transaction code in the core system; after all the target transaction dates are updated, daily switching operation is executed on all the distributed core systems to complete daily switching work of the core systems, and the problem that according to an existing scheme, due to the fact that daily switching cannot be synchronized between an associated system and the core systems, accounting and accounting errors are caused is solved; and transaction failure or business accounting date chaos can be caused, so that the banking business is influenced.

Description

Technical Field

[0001] The present application relates to the field of distributed core system control technology, and in particular to a daily cutting method for a bank's distributed core system, a daily cutting device for a bank's distributed core system, a computer-readable storage medium, and a bank system. Background Art

[0002] Core banking systems require extremely high business continuity. Core accounting date processing is crucial to the stable operation of banking businesses. However, commercial banks currently face the following challenges when building distributed core systems:

[0003] Question 1: In addition to the core system, banks also have many related systems that require the use of accounting dates. These systems also need to call the core system for accounting processing during transactions. If the related systems and the core system cannot be synchronized due to date cuts, accounting and bookkeeping errors may occur, resulting in transaction failures or confusion in business accounting dates.

[0004] Question 2: Since the core system of commercial banks adopts a distributed architecture, at the daily cut-off point, the clocks of different nodes within the core system cannot be strictly synchronized. There may be problems with multiple accounting dates existing at the same time, resulting in transaction failures.

[0005] In summary, if commercial banks fail to check and control the above situations, it will cause confusion in accounting dates or business interruptions within the core and between systems, which will have a huge impact on the bank's business and reputation.

[0006] That is, the existing solution may lead to accounting and bookkeeping errors due to the lack of synchronization between the associated systems and the core system, which may cause transaction failures or confusion in business accounting dates, thereby affecting banking business. Summary of the Invention

[0007] The main purpose of this application is to provide a daily cutting method for a distributed core system of a bank, a daily cutting device for a distributed core system of a bank, a computer-readable storage medium and a bank system, so as to at least solve the problem in existing solutions that the daily cutting between the associated system and the core system cannot be synchronized, which may lead to accounting and account errors, transaction failures or confusion in business accounting dates, thereby affecting bank business.

[0008] In order to achieve the above-mentioned purpose, according to one aspect of the present application, a daily cutting method for a distributed core system of a bank is provided, the method comprising: obtaining a transaction code, an accounting date permission mode code and an accounting date usage mode code, the accounting date permission mode code representing a unique identifier of the accounting date permission mode, the accounting date usage mode code representing a unique identifier of the accounting date usage mode, the accounting date usage mode representing the use of the transaction date of the core system, or the use of the accounting date of the peripheral system, the accounting date permission mode representing a mode allowing the transaction date and the accounting date to be different; according to the date permission mode code and the accounting date usage mode code, determining that the target transaction date of the core system is the transaction date of the core system, or the accounting date of the peripheral system, the target transaction date is the transaction date corresponding to the transaction code in the core system; after updating all the target transaction dates, performing daily cutting operations on each distributed core system respectively to complete the daily cutting work of the core system.

[0009] Optionally, based on the date permission mode code and the accounting date usage mode code, the target transaction date of the core system is determined to be the transaction date of the core system, or the accounting date of the peripheral system, including: when the date permission mode code indicates that the transaction date and the accounting date are allowed to be different only during the buffer period, and the accounting date usage mode code indicates the use of the transaction date of the core system, the target transaction date of the core system is determined to be the transaction date of the core system; when the date permission mode code indicates that the transaction date and the accounting date are allowed to be different only during the buffer period, and the accounting date usage mode code indicates the use of the accounting date of the peripheral system, the target transaction date of the core system is determined to be the accounting date of the peripheral system.

[0010] Optionally, in the process of determining that the target transaction date of the core system is the transaction date of the core system or the accounting date of the peripheral system based on the date permission method code and the accounting date usage method code, the method further includes: when the date permission method code indicates that the transaction date and the accounting date are not allowed to be different, generating an error message to prompt the core system to reject transaction processing.

[0011] Optionally, based on the date permission mode code and the accounting date usage mode code, the target transaction date of the core system is determined to be the transaction date of the core system, or the accounting date of the peripheral system, including: when the date permission mode code indicates that the transaction date and the accounting date are allowed to be different at any time, and the accounting date usage mode code indicates the use of the transaction date of the core system, the target transaction date of the core system is determined to be the transaction date of the core system; when the date permission mode code indicates that the transaction date and the accounting date are allowed to be different at any time, and the accounting date usage mode code indicates the use of the accounting date of the peripheral system, the target transaction date of the core system is determined to be the accounting date of the peripheral system.

[0012] Optionally, obtaining the transaction code, the accounting date permission mode code and the accounting date usage mode code includes: receiving the transaction code sent by the peripheral system; constructing a code mapping relationship, wherein the code mapping relationship represents the mapping relationship between the transaction code, the accounting date permission mode code and the accounting date usage mode code; and determining the accounting date permission mode code and the accounting date usage mode code based on the transaction code and the code mapping relationship.

[0013] Optionally, a day-cut operation is performed on each distributed core system separately, including: performing a data consistency check on each distributed core system to ensure that all transactions have been processed according to the correct accounting date and that the data status of all nodes is consistent, and the data status includes account balances, transaction records and interest calculation results; after the data consistency check is completed, closing all online transaction entrances to prevent new transactions from entering the core system during the day-cut process; and independently performing a day-cut operation on each node in each distributed core system, and the day-cut operation includes updating the accounting date, adjusting the account balance, calculating interest and generating reports.

[0014] Optionally, after performing the date cut operation on each distributed core system respectively, the method further includes: when the system is currently in a preset buffer period and a new transaction code sent by the peripheral system is received again, repeating the date update step until the system is no longer in the preset buffer period. The date update step represents determining that the target transaction date of the core system is the transaction date of the core system, or the accounting date of the peripheral system, based on the date permission method code and the accounting date usage method code.

[0015] According to another aspect of the present application, a daily cutting device for a distributed core system of a bank is provided, the device comprising: an acquisition unit for acquiring a transaction code, an accounting date permission mode code and an accounting date usage mode code, the accounting date permission mode code representing a unique identifier of the accounting date permission mode, the accounting date usage mode code representing a unique identifier of the accounting date usage mode, the accounting date usage mode representing the use of the transaction date of the core system, or the use of the accounting date of the peripheral system, the accounting date permission mode representing a mode allowing the transaction date and the accounting date to be different; a determination unit for determining, based on the date permission mode code and the accounting date usage mode code, that the target transaction date of the core system is the transaction date of the core system, or the accounting date of the peripheral system, the target transaction date is the transaction date corresponding to the transaction code in the core system; a first processing unit for performing daily cutting operations on each distributed core system respectively after updating all the target transaction dates to complete the daily cutting work of the core system.

[0016] According to another aspect of the present application, a computer-readable storage medium is provided, wherein the computer-readable storage medium includes a stored program, wherein when the program is executed, the device where the computer-readable storage medium is located is controlled to execute any one of the methods described.

[0017] According to another aspect of the present application, a banking system is provided, comprising: a core system and a peripheral system in communication connection, wherein the core system is configured to execute any one of the methods described.

[0018] By applying the technical solution of the present application, the accounting date permission method code and the accounting date usage method code are introduced to clearly switch the target transaction date of the core system, so that the subsequent day-cutting operations executed on each distributed core system can be synchronized. Compared with the existing solution, it will not cause transaction failure or confusion in business accounting dates, and thus solves the problem of the existing solution that accounting and account errors may occur due to the inability to synchronize day cuts between the associated system and the core system, which may cause transaction failure or confusion in business accounting dates, thereby affecting banking business. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0020] Figure 1 A schematic diagram of a daily switching method for a distributed core system of a bank provided according to an embodiment of the present application is shown;

[0021] Figure 2 A structural block diagram of a daily cutting device of a bank's distributed core system provided according to an embodiment of the present application is shown. DETAILED DESCRIPTION

[0022] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in this application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0023] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0024] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present application described here. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0025] As described in the background technology, in addition to the core system, banks also have many related systems that require the use of accounting dates, and they need to call the core system for accounting processing during transactions. If the related systems and the core system cannot be synchronized due to the date cut, accounting and accounting errors will occur, which will cause transaction failures or confusion of business accounting dates. Because the core system of a commercial bank adopts a distributed architecture, at the time of the date cut, the clocks of different nodes in the core system cannot be strictly synchronized. There may be a problem of multiple accounting dates existing at the same time, resulting in transaction failures. To solve the problem that the existing solution cannot synchronize the related systems and the core system due to the date cut, which will cause accounting and accounting errors, transaction failures or confusion of business accounting dates, thereby affecting bank business, the embodiments of the present application provide a bank distributed core system date cut method, a bank distributed core system date cut device, a computer-readable storage medium, and a bank system.

[0026] For ease of description, some nouns or terms involved in the embodiments of the present application are explained below:

[0027] Accounting date: The accounting date is the bank's bookkeeping date. All bank transactions are calculated and reconciled based on the accounting date. It is the unified clock for the bank's accounting and business processing, and is of great significance to the development of banking business.

[0028] The day-cut buffer period is a special time period set to resolve differences between systems and within distributed systems. During this period, accounting dates in peripheral systems and the new core system are allowed to differ. Within this period, two accounting dates can coexist. Outside of this period, the accounting dates of peripheral systems and the new core system must remain consistent (unless the associated system has not yet uploaded an accounting date).

[0029] ADRC: One of the Accounting Date Rule Code buffer period parameters, used to control the accounting date control method;

[0030] ADVC: One of the Accounting Date Verify Code buffer period parameters, used to handle inconsistent accounting dates.

[0031] The technical solutions in the embodiments of the present invention will be described clearly and completely below with reference to the accompanying drawings in the embodiments of the present invention.

[0032] In this embodiment, a daily cutting method for a bank's distributed core system is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0033] Figure 1 This is a flow chart of a daily cutting method of a bank distributed core system provided according to an embodiment of the present application. Figure 1 As shown, the method includes the following steps:

[0034] Step S101: Acquire a transaction code, an accounting date permission mode code, and an accounting date usage mode code. The accounting date permission mode code uniquely identifies the accounting date permission mode. The accounting date usage mode code uniquely identifies the accounting date usage mode. The accounting date usage mode identifies whether to use the transaction date of the core system or the accounting date of the peripheral system. The accounting date permission mode identifies the mode in which the transaction date and the accounting date are allowed to differ.

[0035] Among them, obtaining the transaction code, the accounting date permission method code and the accounting date usage method code in step S101 includes: receiving the above-mentioned transaction code sent by the above-mentioned peripheral system; constructing a code mapping relationship, the above-mentioned code mapping relationship represents the mapping relationship between the above-mentioned transaction code, the above-mentioned accounting date permission method code and the above-mentioned accounting date usage method code; determining the above-mentioned accounting date permission method code and the above-mentioned accounting date usage method code based on the above-mentioned transaction code and the above-mentioned code mapping relationship.

[0036] Through code mapping, the system automatically applies the most appropriate accounting date processing rules for different transaction types. This means that for transactions requiring high accounting date consistency (such as deposits and loans), the "no differences allowed" ADVC and "use core system transaction date" ADRC settings can be used. For transactions that allow date flexibility (such as those initiated through some electronic banking channels), the "any differences allowed" ADVC and "use peripheral system accounting date" ADRC settings can be used. This dynamic mapping mechanism ensures the system can flexibly adapt to various business rules, improving transaction processing efficiency and accuracy.

[0037] Step S102: Determine, based on the date permission mode code and the accounting date usage mode code, the target transaction date of the core system as the transaction date of the core system or the accounting date of the peripheral system, wherein the target transaction date is the transaction date corresponding to the transaction code in the core system.

[0038] Among them, according to the above-mentioned date permission method code and the above-mentioned accounting date usage method code, the target transaction date of the above-mentioned core system is determined to be the above-mentioned transaction date of the above-mentioned core system, or the above-mentioned accounting date of the above-mentioned peripheral system, including: when the above-mentioned date permission method code indicates that the above-mentioned transaction date and the above-mentioned accounting date are different only during the buffer period, and the above-mentioned accounting date usage method code indicates that the above-mentioned transaction date of the above-mentioned core system is used, the above-mentioned target transaction date of the above-mentioned core system is determined to be the above-mentioned transaction date of the above-mentioned core system; when the above-mentioned date permission method code indicates that the above-mentioned transaction date and the above-mentioned accounting date are different only during the buffer period, and the above-mentioned accounting date usage method code indicates that the above-mentioned accounting date of the above-mentioned peripheral system is used, the above-mentioned target transaction date of the above-mentioned core system is determined to be the above-mentioned accounting date of the above-mentioned peripheral system.

[0039] During the day-cut buffer period, banks can choose whether to accept transactions with inconsistent dates based on business scenarios and the status of peripheral systems. For example, when ADVC is set to "Allow differences only during the buffer period" and ADRC is set to "Use peripheral system accounting date," banks can process transactions initiated by peripheral systems during the buffer period, using the peripheral system's accounting date as the target transaction date. This ensures the continuity and accuracy of cross-system transactions during the critical day-cut period, especially given that some peripheral systems may complete the day-cut before the core system. After the day-cut buffer period expires, the system updates all target transaction dates to ensure data consistency. When ADRC is set to "Use core system transaction date," all transactions will use the core system's transaction date as the target transaction date. This helps avoid accounting confusion caused by date inconsistencies and ensures data consistency and accounting accuracy within and across core systems. By allowing transactions with inconsistent dates to be processed during the buffer period, banks can significantly reduce transaction disruptions caused by day-cuts and improve business continuity. This is particularly important for business scenarios requiring 24 / 7 continuous service, such as online payments and automatic transfers, ensuring uninterrupted service even during bank day-cut operations. For peripheral systems that require interaction with core systems during the day-cut buffer period, by setting the ADRC to "use the peripheral system's accounting date," the bank eliminates the need for extensive system modifications to accommodate the core system's day-cut schedule. This reduces the cost and complexity of transforming the bank's entire IT architecture while minimizing compatibility issues between peripheral and core systems.

[0040] Regarding “when the date allows the method code to represent that the above-mentioned transaction date and the above-mentioned accounting date are different only during the buffer period, and the above-mentioned accounting date uses the method code to represent the use of the above-mentioned transaction date of the above-mentioned core system, the above-mentioned target transaction date of the above-mentioned core system is determined to be the above-mentioned transaction date of the above-mentioned core system; when the date allows the method code to represent that the above-mentioned transaction date and the above-mentioned accounting date are different only during the buffer period, and the above-mentioned accounting date uses the method code to represent the use of the above-mentioned accounting date of the above-mentioned peripheral system, the above-mentioned target transaction date of the above-mentioned core system is determined to be the above-mentioned accounting date of the above-mentioned peripheral system”, this application provides a specific usage scenario: In the bank's distributed core system, when processing transactions related to inter-bank payments, the bank needs to interact with third-party payment systems (such as NetsUnion, UnionPay, etc.). These third-party payment systems may not be synchronized with the bank's core system at the day-cut time point, especially during high-concurrency transaction periods, the synchronization problem of day-cut is more prominent. In order to ensure the smooth progress of such transactions within the day-cut buffer period while maintaining data consistency and compliance, the following processing methods and benefits are provided:

[0041] How to handle scenarios where the transaction date and accounting date are consistent: If ADVC is set to "Allow differences only during the buffer period," this means that during the buffer period, when the bank's core system receives a transaction request from a third-party payment system, even if the transaction date is inconsistent with the core's accounting date, the transaction will not be immediately rejected, as this is expected during the buffer period. If ADRC is set to "Use core system transaction date," this means that all transactions received during the buffer period will use the core system's transaction date as the target transaction date, ensuring that all transactions are processed according to the core system's rules.

[0042] Benefits of aligning transaction dates with accounting dates: It maintains consistency with core system rules and simplifies internal transaction processing logic. It ensures that all transactions are accounted for using the same accounting date during the buffer period, avoiding accounting confusion caused by using different accounting dates. During periods of high concurrency, the core system can more efficiently process large volumes of transactions, reducing transaction failures and improving customer experience and the bank's reputation.

[0043] Handling scenarios where the transaction date and accounting date are inconsistent: If ADVC is set to "Allow differences only during the buffer period," transaction requests with inconsistent transaction dates can be received and processed during the buffer period, preventing transactions from being rejected due to date issues. If ADRC is set to "Use external system accounting date," transactions received during the buffer period will be recorded and processed using the external system's (such as a third-party payment system's) accounting date as the target transaction date. This is typically because the external system has specific accounting rules or regulatory requirements that require it to use its own accounting date.

[0044] Benefits of scenarios where transaction dates and accounting dates are inconsistent: Improved compatibility and flexibility with third-party payment systems allow for processing transactions requiring interest calculation and accounting based on external accounting dates. During the buffer period, banks can better manage day-cut time differences between different systems, avoiding transaction interruptions or failures caused by day-cut time misalignment. This improves the customer experience, especially during periods of high transaction volume, allowing customer-initiated interbank payment transactions to be processed quickly without being impacted by the bank's internal day-cut operations.

[0045] In which, in the process of determining that the target transaction date of the above-mentioned core system is the above-mentioned transaction date of the above-mentioned core system or the above-mentioned accounting date of the above-mentioned peripheral system based on the above-mentioned date permission method code and the above-mentioned accounting date usage method code, the above-mentioned method also includes: when the above-mentioned date permission method code indicates that the above-mentioned transaction date and the above-mentioned accounting date are not allowed to be different, an error message is generated to prompt the above-mentioned core system to reject transaction processing.

[0046] By strictly controlling the consistency of transaction dates and accounting dates, banks can ensure the correctness of all transactions and the accuracy of their accounting records. This mechanism prevents mis-booking or accounting confusion caused by date inconsistencies, safeguarding the bank's data quality and supporting accurate financial reporting and compliance. Setting the ADVC setting to "Do Not Dissimilar" effectively mitigates risks associated with accounting date inconsistencies, such as duplicate transactions, unauthorized transactions, or interest calculation errors caused by date errors. This helps banks better manage their business risks, protect customer funds, and maintain their reputation and compliance. During the non-buffer period, all transactions must strictly align with the accounting date in the core system, enhancing transaction security. Abnormal date inputs are identified as potential attacks or misoperations. The system immediately generates an error message and rejects the transaction, effectively detecting and preventing such security threats and protecting the bank and its customers from losses. Outside the buffer period, by prohibiting transactions with inconsistent accounting dates, banks can avoid additional date conversion and verification steps, thereby speeding up transaction processing. This not only improves the bank's business processing capabilities, but also reduces transaction response time, providing a more efficient service experience for customers. Setting the ADVC setting to "Do Not Allow Differences" simplifies date processing logic within the system architecture and reduces complex interactions between peripheral and core systems. During the non-buffer period, all transactions adhere to a unified accounting date rule, reducing the complexity of system design and maintenance and potential points of failure.

[0047] In addition, based on the above-mentioned date permission method code and the above-mentioned accounting date usage method code, the target transaction date of the above-mentioned core system is determined to be the above-mentioned transaction date of the above-mentioned core system, or the above-mentioned accounting date of the above-mentioned peripheral system, including: when the above-mentioned date permission method code indicates that the above-mentioned transaction date and the above-mentioned accounting date are allowed to be different at any time, and the above-mentioned accounting date usage method code indicates that the above-mentioned transaction date of the above-mentioned core system is used, the above-mentioned target transaction date of the above-mentioned core system is determined to be the above-mentioned transaction date of the above-mentioned core system; when the above-mentioned date permission method code indicates that the above-mentioned transaction date and the above-mentioned accounting date are allowed to be different at any time, and the above-mentioned accounting date usage method code indicates that the above-mentioned accounting date of the above-mentioned peripheral system is used, the above-mentioned target transaction date of the above-mentioned core system is determined to be the above-mentioned accounting date of the above-mentioned peripheral system.

[0048] When ADRC is set to "Use core system transaction date", it means that even if the transaction date is different from the accounting date, the system can accept and process the transaction and convert the transaction date to the current accounting date of the core system. This is particularly suitable for business scenarios that do not require high consistency in accounting dates, such as transactions in some electronic banking channels, ensuring 7×24-hour transaction service capabilities and improving customer satisfaction. When ADRC is set to "Use peripheral system accounting date", the system will use the accounting date provided by the peripheral system for accounting processing, which is especially important when processing inter-bank transactions with third-party systems (such as UnionPay, NetsUnion, etc.). Third-party systems may have their own day-cutting rules and accounting dates. Allowing the use of the accounting date of the peripheral system can ensure that the transaction processing logic of the bank and the third-party system is consistent, avoid transaction failures, and ensure business continuity.

[0049] Step S103: After all the target transaction dates are updated, a day-cutting operation is performed on each of the distributed core systems to complete the day-cutting work of the core system.

[0050] In the above steps, by intervening the accounting date permission method code and the accounting date usage method code, the target transaction date of the core system is clearly switched, so that the subsequent day-cutting operations executed on each distributed core system can be synchronized. Compared with the existing solution, it will not cause transaction failure or confusion in business accounting dates, and thus solves the problem of the existing solution that the failure to synchronize the day-cutting between the associated system and the core system will lead to accounting and book errors, which will cause transaction failure or confusion in business accounting dates, thereby affecting banking business.

[0051] Accounting Date Allowance Codes (ADVCs) allow the system to flexibly allow or reject transactions with inconsistent dates, particularly during the day-cut buffer period. This ensures that transactions are processed correctly even when the day-cut times of peripheral systems are not fully synchronized with the core system, avoiding transaction failures and a degraded customer experience. Accounting Date Use Codes (ADRCs) specify the accounting date used in transactions, whether in the peripheral system or the core system. This provides greater flexibility to accommodate diverse business scenarios, such as those requiring the use of an external date for interest calculation. In a distributed architecture, accounting dates can be updated independently on each node. After the buffer period expires, the system updates all target transaction dates, reducing reliance on system synchronization and improving the speed and efficiency of day-cut operations. Asynchronous day-cut and post-processing tasks between nodes ensure the continuity of external services during the day-cut process, ensuring stable business operations while meeting the high availability requirements of banking services. Using parameterized configurations (ADVCs and ADRCs) to manage day-cut rules allows the system to dynamically adjust accounting date processing strategies based on diverse business needs and external system characteristics, reducing the need for hard-coded rules and simplifying system design and subsequent maintenance. The system can automatically determine the target transaction date based on the combination of transaction code, peripheral system and accounting date control method, which reduces the complexity for developers and operations personnel in dealing with day cuts and transaction date inconsistencies.

[0052] The day-cut buffer period can be set in different transaction scenarios. Whether accounting date inconsistencies are allowed in the event of inconsistent accounting days and what accounting date to use in the event of inconsistencies can be set at the system and transaction levels. It has good business scalability and can maximize business continuity during the cross-system day-cut process. The day-cut buffer period provides a "buffer" for clock asynchrony that may exist between internal nodes. According to the CAP principle, the requirements for consistency are reduced, which can greatly reduce the dependence of the accounting date status between distributed system nodes, improve system performance and availability, but also put forward dynamic optimization requirements for the system consistency convergence time. By introducing the buffer period mechanism, it can effectively be compatible with the dual accounting dates of the old and new core systems, which can greatly reduce the complexity of the core system and the difficulty of peripheral system transformation.

[0053] The buffer period is parameterized and can be appropriately set based on accounting date convergence. For example, during the parallel phase of a new core system's commissioning, to support collaboration between peripheral and core systems, the buffer period can be appropriately extended. Recommended duration is 1 minute before to 10 minutes after the daily cutoff. (This shorter duration is primarily due to the fact that the bank's daily cutoff typically occurs no earlier than 1 minute, often due to system anomalies that can cause delayed migration. Therefore, 10 minutes of exception handling time is reserved after the daily cutoff, meaning 23:59 to 00:10.) As the system's daily cutoff mechanism improves, the buffer period can be gradually shortened.

[0054] Among them, daily cutting operations are performed on each distributed core system respectively, including: performing data consistency checks on each distributed core system to ensure that all transactions have been processed according to the correct accounting date and that the data status of all nodes is consistent, and the above data status includes account balances, transaction records and interest calculation results; after the data consistency check is completed, all online transaction entrances are closed to prevent new transactions from entering the core system during the daily cutting process; daily cutting operations are performed independently on each node in each distributed core system, and the above daily cutting operations include updating the accounting date, adjusting the account balance, calculating interest and generating reports.

[0055] Performing a data consistency check before the day-cut ensures that transactions on all nodes have been correctly processed according to the current accounting date. This check covers key data status, such as account balances, transaction records, and interest calculation results. This helps promptly identify and correct any potential inconsistencies or errors, ensuring the accuracy and integrity of post-day-cut data. Data consistency is a crucial aspect of banking operations, directly impacting the reliability of financial reports and the security of customer funds. Closing the online transaction portal after the data consistency check prevents new transactions from entering the core system during the day-cut process, avoiding conflicts between the day-cut operation and new transaction processing. This reduces the likelihood of system failures or anomalies during this critical period, thereby improving the stability and reliability of the entire distributed system. This is crucial for ensuring business continuity during this critical time. Closing the online transaction portal allows all system resources to be focused on completing the day-cut operation, including updating the accounting date, adjusting account balances, calculating interest, and generating reports. This optimization ensures that the day-cut operation is completed efficiently and promptly on each node, avoiding resource waste and unnecessary delays, and improving overall system performance. In a distributed core system, each node independently performs daily shedding operations, minimizing inter-node dependencies and making the daily shedding process more flexible and controllable. Even if an individual node fails, daily shedding operations on other nodes can continue without significant impact, enhancing the system's fault tolerance and recovery speed.

[0056] In one embodiment of the present application, after performing the day-cutting operation on each distributed core system, the method further includes: when the system is currently in a preset buffer period and receives a new transaction code sent by the peripheral system again, repeating the date updating step until the system is no longer in the preset buffer period. The date updating step indicates that the target transaction date of the core system is determined to be the transaction date of the core system or the accounting date of the peripheral system based on the date permission method code and the accounting date usage method code.

[0057] During the buffer period, even if peripheral systems or customers initiate transactions on the new accounting date (T+1), the bank's core system can allow these transactions to be processed according to preset rules (using the peripheral system's accounting date or the core system's transaction date) based on the set ADVC and ADRC parameters. This ensures the continuity of transaction processing during the day-cut buffer period, avoids transaction delays or interruptions caused by day-cut operations, and improves customer satisfaction. By repeatedly executing the date update steps during the buffer period, banks can flexibly handle long transactions or batch transactions that span day-cut time points. For example, if a batch task begins immediately after the core day-cut operation on day T is completed, and the peripheral system has already switched to day T+1, the core system can use the peripheral system's accounting date according to the ADRC parameters to smoothly process these tasks, enhancing the system's ability to handle complex transaction scenarios.

[0058] The Date Allowed Mode Code (ADVC) parameter is used to control the control method of uploading accounting dates to the peripheral system during the buffer period and the new core. It includes four options: not allowing differences, allowing differences only during the buffer period, allowing differences at any time, and allowing dates greater than the core.

[0059] 0 - no differences allowed (personal core not used);

[0060] 1-Differences are allowed only during the buffer period (default rule);

[0061] 2- Different channels are allowed at any time (a small number of channels are used, such as electronic channels);

[0062] 3- Allow date to be greater than core (personal core is not used);

[0063] 0 - Not Allowed: During the buffer period, the accounting date in the peripheral system cannot differ from the core online transaction date. If the peripheral system submits a different accounting date, the core will issue an error and reject the transaction. Peripheral systems using this setting must be able to tolerate different accounting dates returned by different units during the core buffer period. This is suitable for scenarios where the peripheral system does not conduct transactions during the day-cut period, or transactions are very rare, and cross-system consistency of accounting dates is highly required, even if sacrificing business continuity during the buffer period is acceptable.

[0064] 1 - Differences allowed only during the buffer period: During the buffer period, the accounting date submitted by the external system can differ from the core accounting date, and the external system's accounting date will be used as the core system's transaction date. With this setting, even if accounting dates of linked systems differ during the buffer period due to date synchronization issues, the core will not report an error. The core will use the accounting date submitted by the linked system for accounting purposes, effectively ensuring transaction continuity. This setting is suitable for scenarios with high transaction volume and high business continuity requirements, including cross-border payment scenarios such as China UnionPay and China National Payment Service (CNS).

[0065] 2-Allow differences at all times: Peripheral systems are allowed to differ from the core date at any time (regardless of the buffer period), with the core system's online transaction date serving as the core transaction date. Peripheral systems using this setting can effectively ensure transaction continuity at all times without error reporting. This is suitable for scenarios requiring high business continuity and requiring interest calculation based on the core accounting date, such as transactions initiated through in-bank channels like over-the-counter banking, online banking, and self-service banking.

[0066] 3-Allow Date Later than Core: Peripheral systems are allowed to have accounting dates later than the core system's online transaction dates, but not later than the core system's. The peripheral system's accounting date is used as the core system's accounting date. This feature allows peripheral systems to initiate batch task registrations before the core system performs a day-cut. The core registers the batch tasks initiated by the prior day-cut system and executes them asynchronously after the core day-cut completes. This feature is suitable for scenarios where the day-cut occurs before the core day-cut, or where long transactions may span the period before and after the day-cut, such as batch payment and deduction for intermediary services.

[0067] The accounting date usage code ADRC is used in conjunction with ADVC to set the method for using the core accounting date when the peripheral system and the core system are inconsistent. There are two specific configuration methods:

[0068] Use the external system date (default rule);

[0069] Date of use of core systems (used in a limited number of channels, such as electronic channels);

[0070] Furthermore, to precisely configure day-cut controls for different transactions in various peripheral systems, the core should support different accounting date processing rules at the granularity of the requesting system and transaction code. Other combinations of date allowance and date usage can also be configured based on specific application scenarios. Therefore, the core day-cut combination is: peripheral system code - transaction code - ADVC and ADRC. The specific accounting date control methods are shown in Table 1.

[0071] Table 1

[0072]

[0073]

[0074]

[0075] The core day-cut component supports setting accounting date verification rules, accounting date reference, and buffer period length before and after day-cut based on the initiator, sender, and service code. The initiator, sender, and service code all support the use of the wildcard character * to match all.

[0076] Setting a buffer period does not affect the customer's 7*24 hour experience. The core system can extend the buffer period as needed (it can be set longer in the initial production and parallel period). Specific setting suggestions are as follows:

[0077] Different systems can be set differently, but the buffer period of the back-end system must be set no less than the daily processing time of the initiator (or sender) (to avoid the back-end system rejecting transactions when only the buffer period accounting date is different). For different components and services included in the new core (such as deposits, remittances, settlements, and bank cards), consider setting the same cache period.

[0078] If the daily cut time of different transaction initiator peripheral systems is different and exceeds the daily cut processing time of the core system itself, the core system can set different buffer periods for different initiator peripheral systems. However, since the buffer period after the daily cut is based on the longest buffer period in the configuration, the subsequent day-end process will continue after waiting for the longest buffer period. It is actually meaningless to set different times for the same system. Therefore, it is recommended to set the same buffer period for the same system.

[0079] Currently, a certain bank's core buffer period is configured as follows: a 1-minute buffer period before the day-end cut and a 10-minute buffer period after the day-end cut. By default, accounting date differences are only permitted during the buffer period, using the external system's accounting date. A buffer period is not used for deposits or remittances, and transactions are rejected if the accounting date is inconsistent. In addition to the default rule, a special configuration is also available: when electronic channels are the sender, accounting dates are always permitted to differ, using the core system's accounting date. This is because electronic channels use the core system's accounting date as the basis.

[0080] The default buffer period configuration is: 1 minute before the day cut and 10 minutes after the day cut. By default, only the accounting date is allowed to be different during the buffer period, and the accounting date of the external system is used. The buffer period is not used for deposits and remittances, and the transaction is rejected when the accounting date is inconsistent.

[0081] A special configuration allows for sending systems that are not sensitive to accounting dates to use the core system's accounting date at any time. This is because the electronic channel's accounting date is prefixed with eight zeros, and the core system's accounting date is used as the standard. Unified queries do not automatically switch dates; the current accounting date can be queried by calling the deposit online transaction function.

[0082] Specific explanation of the priority of the initiating system code + sending system code + service code: In terms of parameter configuration, fine-grained parameter control is supported according to the three dimensions of initiating system, sending system and service. The transaction initiating system refers to the physical starting point where the transaction is actually initiated, including counters, electronic channels, self-service machines and business front-ends, etc. The sending system refers to the previous system where the transaction is submitted to the core system, such as intermediary business, wealth management, insurance and other business systems. The transaction is the core transaction code called. In actual use, each parameter supports wildcard settings, and personalized parameters have higher priority than general configurations. For example: the default parameters initiating system and sending system use unified settings for calling any core service, then the response fields are all configured as "*", and this parameter has the lowest priority; the personalized parameters that precisely define the initiating system code + sending system code + service code have the highest priority to take effect, and so on. In the case of partial overlap between parameters, the system will select parameters with a high degree of personalization to take effect.

[0083] In order to enable those skilled in the art to more clearly understand the technical solution of the present application, the implementation process of the daily cutting method of the bank distributed core system of the present application will be described in detail below with reference to specific embodiments.

[0084] This embodiment relates to a specific daily switching method for a distributed core system of a bank, including:

[0085] Receive the transaction code sent by the peripheral system; establish a code mapping relationship, where the code mapping relationship represents the mapping relationship between the transaction code, the accounting date permission mode code, and the accounting date usage mode code; determine the accounting date permission mode code and the accounting date usage mode code based on the transaction code and the code mapping relationship, where the accounting date permission mode code represents the unique identifier of the accounting date permission mode, the accounting date usage mode code represents the unique identifier of the accounting date usage mode, the accounting date usage mode represents whether to use the transaction date of the core system or the accounting date of the peripheral system, and the accounting date permission mode represents the method in which the transaction date and the accounting date are allowed to differ;

[0086] If the date permission method code indicates that the transaction date and accounting date are allowed to differ only during the buffer period, and the accounting date usage method code indicates that the transaction date of the core system is used, the target transaction date of the core system is determined to be the transaction date of the core system; if the date permission method code indicates that the transaction date and accounting date are allowed to differ only during the buffer period, and the accounting date usage method code indicates that the accounting date of the peripheral system is used, the target transaction date of the core system is determined to be the accounting date of the peripheral system;

[0087] After all target transaction dates are updated, a data consistency check is performed on each distributed core system to ensure that all transactions have been processed according to the correct accounting date and that the data status of all nodes is consistent, including account balances, transaction records, and interest calculation results. After the data consistency check is completed, all online transaction entries are closed to prevent new transactions from entering the core system during the daily cut process. The daily cut operation is independently performed on each node in each distributed core system, including updating the accounting date, adjusting account balances, calculating interest, and generating reports.

[0088] After performing the date cut operation on each distributed core system respectively, when the system is currently in the preset buffer period and receives a new transaction code sent by the peripheral system again, the date update step is repeated until the system is no longer in the preset buffer period. The date update step is characterized by determining that the target transaction date of the core system is the transaction date of the core system, or the accounting date of the peripheral system based on the date permission method code and the accounting date usage method code.

[0089] It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and that, although a logical order is shown in the flowcharts, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0090] The embodiment of the present application also provides a daily cutting device for a distributed core system of a bank. It should be noted that the daily cutting device for a distributed core system of a bank of the embodiment of the present application can be used to execute the daily cutting method for a distributed core system of a bank provided by the embodiment of the present application. The device is used to implement the above-mentioned embodiments and preferred implementation methods, and those that have been explained will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware for a predetermined function. Although the device described in the following embodiments is preferably implemented in software, implementation in hardware, or a combination of software and hardware, is also possible and conceivable.

[0091] The following introduces the daily cutting device of the bank distributed core system provided in the embodiment of the present application.

[0092] Figure 2 This is a structural block diagram of a daily cutting device of a bank distributed core system provided according to an embodiment of the present application. Figure 2 As shown, the device includes:

[0093] An acquisition unit 21 is configured to acquire a transaction code, an accounting date permission mode code, and an accounting date usage mode code, wherein the accounting date permission mode code uniquely identifies the accounting date permission mode, the accounting date usage mode code uniquely identifies the accounting date usage mode, the accounting date usage mode identifies whether to use the transaction date of the core system or the accounting date of the peripheral system, and the accounting date permission mode identifies a mode in which the transaction date and the accounting date are allowed to differ.

[0094] a determination unit 22 configured to determine, based on the date permission mode code and the accounting date usage mode code, that the target transaction date of the core system is the transaction date of the core system or the accounting date of the peripheral system, wherein the target transaction date is the transaction date corresponding to the transaction code in the core system;

[0095] The first processing unit 23 is configured to perform a day-cutting operation on each of the distributed core systems after all the target transaction dates are updated, so as to complete the day-cutting work of the core system.

[0096] In the above-mentioned device, by intervening the accounting date permission method code and the accounting date usage method code, the target transaction date of the core system is clearly switched, so that the subsequent day-cutting operations executed on each distributed core system can be synchronized. Compared with the existing solution, it will not cause transaction failure or confusion of business accounting dates, and thus solves the problem of the existing solution that the failure to synchronize the day-cutting between the associated system and the core system will lead to accounting and book errors, which will cause transaction failure or confusion of business accounting dates, thereby affecting banking business.

[0097] In one embodiment of the present application, the determination unit includes a first determination module and a second determination module. The first determination module is used to determine that the target transaction date of the core system is the above-mentioned transaction date of the core system when the date permission method code represents that the above-mentioned transaction date and the above-mentioned accounting date are different only during the buffer period, and the above-mentioned accounting date usage method code represents the use of the above-mentioned transaction date of the above-mentioned core system; the second determination module is used to determine that the target transaction date of the core system is the above-mentioned accounting date of the above-mentioned peripheral system when the above-mentioned date permission method code represents that the above-mentioned transaction date and the above-mentioned accounting date are different only during the buffer period, and the above-mentioned accounting date usage method code represents the use of the above-mentioned accounting date of the above-mentioned peripheral system.

[0098] During the day-cut buffer period, banks can choose whether to accept transactions with inconsistent dates based on business scenarios and the status of peripheral systems. For example, when ADVC is set to "Allow differences only during the buffer period" and ADRC is set to "Use peripheral system accounting date," banks can process transactions initiated by peripheral systems during the buffer period, using the peripheral system's accounting date as the target transaction date. This ensures the continuity and accuracy of cross-system transactions during the critical day-cut period, especially given that some peripheral systems may complete the day-cut before the core system. After the day-cut buffer period expires, the system updates all target transaction dates to ensure data consistency. When ADRC is set to "Use core system transaction date," all transactions will use the core system's transaction date as the target transaction date. This helps avoid accounting confusion caused by date inconsistencies and ensures data consistency and accounting accuracy within and across core systems. By allowing transactions with inconsistent dates to be processed during the buffer period, banks can significantly reduce transaction disruptions caused by day-cuts and improve business continuity. This is especially important for business scenarios that require 24 / 7 continuous service, such as online payment and automatic transfer, ensuring that customers can enjoy uninterrupted service when performing daily bank operations.

[0099] In one embodiment of the present application, the determination unit includes a generation module, which is used to generate an error message to prompt the above-mentioned core system to reject transaction processing when the target transaction date of the above-mentioned core system is the above-mentioned transaction date of the above-mentioned core system or the above-mentioned accounting date of the above-mentioned peripheral system based on the above-mentioned date permission method code and the above-mentioned accounting date usage method code.

[0100] By strictly controlling the consistency between transaction dates and accounting dates, banks can ensure the correctness of all transactions and the accuracy of their accounts. This mechanism prevents mis-booking or accounting confusion caused by date inconsistencies, safeguarding the bank's data quality and supporting accurate financial reporting and compliance. Setting ADVC to "Do Not Dissimilar" effectively mitigates risks associated with accounting date inconsistencies, such as duplicate transactions, unauthorized transactions, or interest miscalculations caused by date errors. This helps banks better manage their business risks, protect customer funds, and maintain their reputation and compliance. During the non-buffer period, all transactions must strictly align with the accounting date in the core system, enhancing transaction security.

[0101] In one embodiment of the present application, the determination unit includes a third determination module and a fourth determination module. The third determination module is used to determine that the target transaction date of the core system is the above-mentioned transaction date of the core system when the date permission method code represents that the above-mentioned transaction date and the above-mentioned accounting date are different at any time, and the above-mentioned accounting date uses the method code to represent the use of the above-mentioned transaction date of the above-mentioned core system; the fourth determination module is used to determine that the target transaction date of the core system is the above-mentioned accounting date of the above-mentioned peripheral system when the date permission method code represents that the above-mentioned transaction date and the above-mentioned accounting date are different at any time, and the above-mentioned accounting date uses the method code to represent the use of the above-mentioned accounting date of the above-mentioned peripheral system.

[0102] When ADRC is set to "Use core system transaction date", it means that even if the transaction date is different from the accounting date, the system can accept and process the transaction and convert the transaction date to the current accounting date of the core system. This is particularly suitable for business scenarios that do not require high consistency in accounting dates, such as transactions in some electronic banking channels, ensuring 7×24-hour transaction service capabilities and improving customer satisfaction. When ADRC is set to "Use peripheral system accounting date", the system will use the accounting date provided by the peripheral system for accounting processing, which is especially important when processing inter-bank transactions with third-party systems (such as UnionPay, NetsUnion, etc.). Third-party systems may have their own day-cutting rules and accounting dates. Allowing the use of the accounting date of the peripheral system can ensure that the transaction processing logic of the bank and the third-party system is consistent, avoid transaction failures, and ensure business continuity.

[0103] In one embodiment of the present application, the acquisition unit includes a receiving module, a building module and a fifth determination module, the receiving module is used to receive the above-mentioned transaction code sent by the above-mentioned peripheral system; the building module is used to construct a code mapping relationship, and the above-mentioned code mapping relationship represents the mapping relationship between the above-mentioned transaction code, the above-mentioned accounting date permission method code and the above-mentioned accounting date usage method code; the fifth determination module is used to determine the above-mentioned accounting date permission method code and the above-mentioned accounting date usage method code based on the above-mentioned transaction code and the above-mentioned code mapping relationship.

[0104] Through code mapping, the system automatically applies the most appropriate accounting date processing rules for different transaction types. This means that for transactions requiring high accounting date consistency (such as deposits and loans), the "no differences allowed" ADVC and "use core system transaction date" ADRC settings can be used. For transactions that allow date flexibility (such as those initiated through some electronic banking channels), the "any differences allowed" ADVC and "use peripheral system accounting date" ADRC settings can be used. This dynamic mapping mechanism ensures the system can flexibly adapt to various business rules, improving transaction processing efficiency and accuracy.

[0105] In one embodiment of the present application, the first processing unit includes a first processing module, a second processing module and a third processing module. The first processing module is used to perform a data consistency check on each distributed core system to ensure that all transactions have been processed according to the correct accounting date and that the data status of all nodes is consistent. The data status includes account balances, transaction records and interest calculation results; the second processing module is used to close all online transaction entrances after the data consistency check is completed to prevent new transactions from entering the core system during the daily cutting process; the third processing module is used to independently perform daily cutting operations on each node in each distributed core system. The daily cutting operations include updating accounting dates, adjusting account balances, calculating interest and generating reports.

[0106] Performing a data consistency check before the day-cut ensures that transactions on all nodes have been correctly processed according to the current accounting date. This check covers key data status, such as account balances, transaction records, and interest calculation results. This helps promptly identify and correct any potential inconsistencies or errors, ensuring the accuracy and integrity of post-day-cut data. Data consistency is a crucial aspect of banking operations, directly impacting the reliability of financial reports and the security of customer funds. Closing the online transaction portal after the data consistency check prevents new transactions from entering the core system during the day-cut process, avoiding conflicts between the day-cut operation and new transaction processing. This reduces the likelihood of system failures or anomalies during this critical period, thereby improving the stability and reliability of the entire distributed system. This is crucial for ensuring business continuity during this critical time. Closing the online transaction portal allows all system resources to be focused on completing the day-cut operation, including updating the accounting date, adjusting account balances, calculating interest, and generating reports. This optimization ensures that the day-cut operation is completed efficiently and promptly on each node, avoiding resource waste and unnecessary delays, and improving overall system performance. In a distributed core system, each node independently performs daily shedding operations, minimizing inter-node dependencies and making the daily shedding process more flexible and controllable. Even if an individual node fails, daily shedding operations on other nodes can continue without significant impact, enhancing the system's fault tolerance and recovery speed.

[0107] In one embodiment of the present application, the above-mentioned device also includes a second processing unit for, after performing the day cutting operation on each distributed core system respectively, repeating the date updating step when it is currently in the preset buffer period and receiving a new transaction code sent by the above-mentioned peripheral system again, until it is not currently in the above-mentioned preset buffer period. The above-mentioned date updating step represents determining, based on the above-mentioned date permission method code and the above-mentioned accounting date usage method code, that the above-mentioned target transaction date of the above-mentioned core system is the above-mentioned transaction date of the above-mentioned core system, or the above-mentioned accounting date of the above-mentioned peripheral system.

[0108] During the buffer period, even if peripheral systems or customers initiate transactions on the new accounting date (T+1), the bank's core system can allow these transactions to be processed according to preset rules (using the peripheral system's accounting date or the core system's transaction date) based on the set ADVC and ADRC parameters. This ensures the continuity of transaction processing during the day-cut buffer period, avoids transaction delays or interruptions caused by day-cut operations, and improves customer satisfaction. By repeatedly executing the date update steps during the buffer period, banks can flexibly handle long transactions or batch transactions that span day-cut time points. For example, if a batch task begins immediately after the core day-cut operation on day T is completed, and the peripheral system has already switched to day T+1, the core system can use the peripheral system's accounting date according to the ADRC parameters to smoothly process these tasks, enhancing the system's ability to handle complex transaction scenarios.

[0109] The daily cutting device of the above-mentioned distributed core banking system includes a processor and a memory. The acquisition unit, determination unit, and first processing unit are all stored as program units in the memory. The processor executes the program units stored in the memory to implement the corresponding functions. The above-mentioned modules are all located in the same processor; alternatively, the above-mentioned modules can be located in different processors in any combination.

[0110] The processor contains a kernel, which retrieves the corresponding program unit from memory. One or more kernels can be configured. Adjusting kernel parameters can address existing solutions that suffer from accounting and bookkeeping errors caused by date synchronization issues between the associated and core systems. This can lead to transaction failures or confusion in business accounting dates, impacting banking operations.

[0111] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0112] An embodiment of the present invention provides a computer-readable storage medium, which includes a stored program, wherein when the program is running, the device where the computer-readable storage medium is located is controlled to execute the daily cutting method of the bank's distributed core system.

[0113] An embodiment of the present invention provides a processor, which is used to run a program, wherein the daily cutting method of the bank's distributed core system is executed when the program is running.

[0114] An embodiment of the present invention provides a device comprising a processor, a memory, and a program stored in the memory and executable on the processor. When the processor executes the program, at least the following steps are implemented: obtaining a transaction code, an accounting date permission mode code, and an accounting date usage mode code, wherein the accounting date permission mode code represents a unique identifier of the accounting date permission mode, the accounting date usage mode code represents a unique identifier of the accounting date usage mode, the accounting date usage mode represents the use of the transaction date of the core system or the use of the accounting date of the peripheral system, and the accounting date permission mode represents a mode in which the transaction date and the accounting date are allowed to differ; determining, based on the date permission mode code and the accounting date usage mode code, a target transaction date for the core system as the transaction date of the core system or the accounting date of the peripheral system, wherein the target transaction date is the transaction date corresponding to the transaction code in the core system; and after updating all the target transaction dates, performing a day-cutting operation on each distributed core system to complete the day-cutting work of the core system. The device herein may be a server, a PC, a PAD, a mobile phone, etc.

[0115] The present application also provides a computer program product, which, when executed on a data processing device, is suitable for executing an initialized program having at least the following method steps: obtaining a transaction code, an accounting date permission method code and an accounting date usage method code, wherein the above-mentioned accounting date permission method code represents a unique identifier of the accounting date permission method, the above-mentioned accounting date usage method code represents a unique identifier of the accounting date usage method, the above-mentioned accounting date usage method represents the use of the transaction date of the core system, or the use of the accounting date of the peripheral system, and the above-mentioned accounting date permission method represents a method of allowing the above-mentioned transaction date and the above-mentioned accounting date to be different; according to the above-mentioned date permission method code and the above-mentioned accounting date usage method code, determining that the target transaction date of the above-mentioned core system is the above-mentioned transaction date of the above-mentioned core system, or the above-mentioned accounting date of the above-mentioned peripheral system, the above-mentioned target transaction date is the transaction date corresponding to the above-mentioned transaction code in the above-mentioned core system; after updating all the above-mentioned target transaction dates, performing a day-cutting operation on each of the above-mentioned distributed core systems respectively to complete the day-cutting work of the above-mentioned core system.

[0116] The present application also provides a banking system, which includes: a core system and a peripheral system in communication connection, wherein the core system is used to execute any of the above methods. By intervening in the accounting date permission mode code and the accounting date usage mode code, the target transaction date of the core system is clearly switched, so that the subsequent execution of the day-cut operation on each distributed core system can be synchronized. Compared with the existing solution, it will not cause transaction failure or confusion of business accounting dates, thereby solving the problem of the existing solution that the failure to synchronize the day-cut between the associated system and the core system will lead to accounting and book errors, which will cause transaction failure or confusion of business accounting dates, thereby affecting banking business.

[0117] Obviously, those skilled in the art will appreciate that the various modules or steps of the present invention described above can be implemented using a general-purpose computing device, can be centralized on a single computing device, or can be distributed across a network of multiple computing devices. They can be implemented using program code executable by the computing device, and thus, can be stored in a storage device and executed by the computing device. In some cases, the steps shown or described herein can be performed in a different order than that shown, or can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0118] Those skilled in the art will appreciate that the embodiments of the present application can be provided as methods, systems, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt 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.) that contain computer-usable program code.

[0119] 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 box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes 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 steps in the process. 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.

[0120] 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.

[0121] 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.

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

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

[0124] Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. The 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 memory (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 technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, 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 media such as modulated data signals and carrier waves.

[0125] 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.

[0126] From the above description, it can be seen that the above embodiments of the present application achieve the following technical effects:

[0127] 1) The day-cutting method of the distributed core system of the bank of the present application, by intervening the accounting date permission method code and the accounting date usage method code, clearly switches the target transaction date of the core system, so that the subsequent day-cutting operations executed on each distributed core system can be synchronized. Compared with the existing scheme, it will not cause transaction failure or confusion of business accounting dates, and thus solves the problem of the existing scheme that the failure to synchronize the day-cutting between the associated system and the core system will lead to accounting and book errors, which will cause transaction failure or confusion of business accounting dates, thereby affecting the bank's business.

[0128] 2) The day-cutting device of the distributed core system of the bank of the present application intervenes in the accounting date permission mode code and the accounting date usage mode code, thereby clearly switching the target transaction date of the core system, so that the subsequent day-cutting operations executed on each distributed core system can be synchronized. Compared with the existing solution, it will not cause transaction failure or confusion in business accounting dates, and thus solves the problem of the existing solution that the failure to synchronize the day-cutting between the associated system and the core system will lead to accounting and account errors, which will cause transaction failure or confusion in business accounting dates, thereby affecting bank business.

[0129] The above description is merely a preferred embodiment of the present application and is not intended to limit the present application. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present application shall be included within the scope of protection of the present application.

Claims

1. A daily switching method for a bank's distributed core system, characterized in that: include: Obtaining a transaction code, an accounting date permission mode code, and an accounting date usage mode code, wherein the accounting date permission mode code represents a unique identifier of an accounting date permission mode, the accounting date usage mode code represents a unique identifier of an accounting date usage mode, the accounting date usage mode represents whether to use a transaction date of a core system or an accounting date of a peripheral system, and the accounting date permission mode represents a mode in which the transaction date and the accounting date are allowed to be different; determining, based on the date permission mode code and the accounting date usage mode code, the target transaction date of the core system as the transaction date of the core system or the accounting date of the peripheral system, wherein the target transaction date is the transaction date corresponding to the transaction code in the core system; After all the target transaction dates are updated, the daily cut operation is performed on each distributed core system to complete the daily cut work of the core system.

2. The method according to claim 1, characterized in that Determining, based on the date permission mode code and the accounting date usage mode code, that the target transaction date of the core system is the transaction date of the core system or the accounting date of the peripheral system includes: If the date permission mode code indicates that the transaction date and the accounting date are allowed to be different only during the buffer period, and the accounting date usage mode code indicates that the transaction date of the core system is used, determining the target transaction date of the core system to be the transaction date of the core system; When the date permission mode code indicates that the transaction date and the accounting date are allowed to be different only during the buffer period, and the accounting date usage mode code indicates that the accounting date of the peripheral system is used, the target transaction date of the core system is determined to be the accounting date of the peripheral system.

3. The method according to claim 1, characterized in that In the process of determining, based on the date permission mode code and the accounting date usage mode code, that the target transaction date of the core system is the transaction date of the core system or the accounting date of the peripheral system, the method further includes: In the case where the date permission mode code indicates that the transaction date and the accounting date are not allowed to be different, an error message is generated to prompt the core system to reject the transaction processing.

4. The method according to claim 1, wherein Determining, based on the date permission mode code and the accounting date usage mode code, that the target transaction date of the core system is the transaction date of the core system or the accounting date of the peripheral system includes: When the date permission mode code indicates that the transaction date and the accounting date are allowed to be different at any time, and the accounting date usage mode code indicates that the transaction date of the core system is used, determining the target transaction date of the core system to be the transaction date of the core system; When the date permission mode code indicates that the transaction date and the accounting date are allowed to be different at any time, and the accounting date usage mode code indicates the use of the accounting date of the peripheral system, the target transaction date of the core system is determined to be the accounting date of the peripheral system.

5. The method according to claim 1, wherein Obtain transaction codes, accounting date permission mode codes, and accounting date usage mode codes, including: receiving the transaction code sent by the peripheral system; Constructing a code mapping relationship, wherein the code mapping relationship represents a mapping relationship between the transaction code, the accounting date permission mode code, and the accounting date usage mode code; The accounting date permission mode code and the accounting date usage mode code are determined according to the transaction code and the code mapping relationship.

6. The method according to claim 1, characterized in that Perform daily switching operations on each distributed core system, including: Performing data consistency checks on each distributed core system to ensure that all transactions have been processed according to the correct accounting date and that the data status of all nodes is consistent, including account balances, transaction records, and interest calculation results; After the data consistency check is completed, all online transaction entrances are closed to prevent new transactions from entering the core system during the daily cutting process; A daily cut operation is independently performed on each node in each distributed core system, and the daily cut operation includes updating the accounting date, adjusting the account balance, calculating interest, and generating reports.

7. The method according to any one of claims 1 to 6, characterized in that After performing the daily switching operation on each distributed core system, the method further includes: When the system is currently in the preset buffer period and a new transaction code is received again from the peripheral system, the date updating step is repeated until the system is no longer in the preset buffer period. The date updating step is characterized in that the target transaction date of the core system is determined to be the transaction date of the core system or the accounting date of the peripheral system based on the date permission method code and the accounting date usage method code.

8. A daily cutting device for a bank's distributed core system, characterized in that: include: an acquisition unit, configured to acquire a transaction code, an accounting date permission mode code, and an accounting date usage mode code, wherein the accounting date permission mode code represents a unique identifier of an accounting date permission mode, the accounting date usage mode code represents a unique identifier of an accounting date usage mode, the accounting date usage mode represents whether to use a transaction date of a core system or an accounting date of a peripheral system, and the accounting date permission mode represents a mode in which a difference between the transaction date and the accounting date is permitted; a determining unit, configured to determine, based on the date permission mode code and the accounting date usage mode code, that the target transaction date of the core system is the transaction date of the core system or the accounting date of the peripheral system, wherein the target transaction date is the transaction date corresponding to the transaction code in the core system; The first processing unit is configured to perform a day-cutting operation on each of the distributed core systems after all the target transaction dates are updated, so as to complete the day-cutting work of the core system.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium includes a stored program, wherein when the program is executed, the device where the computer-readable storage medium is located is controlled to execute the method according to any one of claims 1 to 7.

10. A banking system, characterized in that: include: A core system and a peripheral system in communication connection, wherein the core system is used to execute the method according to any one of claims 1 to 7.

Images