Multi-type account management method and device, equipment, storage medium and program product

Abstract

The invention provides a multi-type account management method and device, equipment, a storage medium and a program product. Relates to the technical field of data processing. The method comprises the following steps: generating a global account coding identifier corresponding to each account according to a preset account coding rule and account information, and carrying out associated storage on the global account coding identifier and the account information corresponding to each account; obtaining a global account code identifier and a transaction type corresponding to the target account from transaction data, and determining a corresponding preset accounting rule according to the global account code identifier and the transaction type; generating a corresponding entry according to a preset bookkeeping rule corresponding to the target account, and performing associated storage in a preset bookkeeping table; converting the initial reconciliation statement into a standard reconciliation statement by adopting a corresponding data analyzer; and account checking processing is carried out based on the standard account checking list and the preset account keeping list. According to the method, unified management of multiple types of accounts is realized, the entry is accurately generated, the account statement of different types of accounts is uniformly processed, and the account management efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus, device, storage medium and program product for managing multiple types of accounts. Background Technology

[0002] In the precious metals business of financial institutions, the diversification of business scenarios has given rise to various account types. When banks conduct domestic and foreign precious metals transactions, they need to manage physical precious metals such as international gold, gold exchange gold, and branch inventory, while also involving funds accounts in different currencies. Different accounts correspond to different storage scenarios and clearing systems, and must meet the compliance and asset control requirements of domestic and foreign business, thus forming a multi-source and multi-attribute account management pattern.

[0003] Currently, a separate management system is adopted for funds accounts and precious metals accounts. Funds accounts are managed centrally through an internal accounting system, which supports reconciliation of accounting records with external systems. In contrast, precious metals accounts are scattered across independent systems such as international gold exchanges, gold exchanges, and branch internal accounts. Some of these systems rely on manual record keeping and have inconsistent management standards, with some being recorded by physical units and others by monetary value, resulting in a lack of collaborative management mechanisms.

[0004] However, with multiple types of accounts scattered across different systems, the relevant technologies cannot achieve unified management, resulting in complex and inefficient operations during bookkeeping and reconciliation. Summary of the Invention

[0005] The multi-type account management method, apparatus, device, storage medium, and program products provided in this application are used to achieve unified management, accounting, and reconciliation of multi-type accounts, thereby improving account management efficiency.

[0006] In a first aspect, embodiments of this application provide a method for managing multiple types of accounts, the method comprising:

[0007] In response to obtaining multiple different types of account information, a global account code identifier corresponding to each account is generated according to a preset account coding rule and the account information, and the global account code identifier and the account information corresponding to each account are associated and stored. The multiple different types of accounts include at least one type of fund account and at least one type of precious metal account.

[0008] In response to receiving transaction data of the target account, the system obtains the global account code identifier and transaction type corresponding to the target account from the transaction data, and determines the corresponding preset accounting rules based on the global account code identifier and transaction type.

[0009] The corresponding journal entries are generated according to the preset accounting rules for the target account and stored in the preset accounting table.

[0010] In response to receiving an initial statement for a target account, the system obtains a global account code identifier corresponding to the target account from the initial statement and determines a data parser corresponding to the target account based on the global account code identifier, so as to convert the initial statement into a standard statement using the corresponding data parser.

[0011] Reconciliation is performed based on the standard statement and the preset accounting table.

[0012] In one possible implementation, the step of generating a global account code identifier corresponding to each account according to a preset account coding rule and the account information in response to obtaining multiple different types of account information includes:

[0013] In response to receiving a user-initiated encoding generation request, it establishes connections with multiple systems containing accounts of different types;

[0014] Retrieve corresponding account information from multiple different systems;

[0015] According to the preset account coding rules, the coding-related information is extracted from the account information, and a global account coding identifier corresponding to each account is generated based on the coding-related information.

[0016] In one possible implementation, the target account is a precious metals account, the preset accounting rule is a binary accounting rule, and the step of generating corresponding journal entries according to the preset accounting rule corresponding to the target account and storing them in a preset accounting table includes:

[0017] Obtain the unit weight of precious metals from the transaction data;

[0018] Generate physical holding entries and valuation entries based on the unit weight of the precious metals;

[0019] The physical holding entries and valuation entries are stored together in a pre-defined accounting table.

[0020] In one possible implementation, the step of responding to receiving an initial statement for a target account, obtaining a global account code identifier corresponding to the target account from the initial statement, and determining a data parser corresponding to the target account based on the global account code identifier, so as to convert the initial statement into a standard statement using the corresponding data parser, includes:

[0021] In response to obtaining the initial statement, the account identification information is extracted from the initial statement, and the corresponding global account code identifier is matched based on the account identification information;

[0022] The corresponding data parser is determined based on the matched global account code identifier;

[0023] The data parser is used to extract transaction elements from the initial statement, including transaction time, transaction number, transaction subject, transaction quantity, and transaction object.

[0024] The transaction elements are converted into a standard statement containing a global account code identifier according to a preset field format.

[0025] In one possible implementation, the method further includes:

[0026] Mark each completed standard reconciliation statement;

[0027] In response to a transaction time discrepancy, the transaction time is extended by a preset transaction duration error value and the comparison is repeated.

[0028] In response to a difference marked as an amount or weight, the corresponding external system interface is invoked to query the original transaction voucher;

[0029] In response to a transaction being marked as missing, a request to complete the transaction is sent to the corresponding external system.

[0030] In response to the elimination of differences after processing, the flag is updated to pass;

[0031] If a difference still exists after processing, an anomaly alarm is triggered and the difference details are pushed to the preset terminal.

[0032] In one possible implementation, the method further includes:

[0033] In response to the completion of associated storage, entry generation, or reconciliation processing, the account status information is automatically updated, including the current balance, number of holdings, recent transaction time, and reconciliation status.

[0034] Real-time monitoring is used to determine whether the account status information triggers preset warning conditions;

[0035] In response to triggering preset warning conditions, the system automatically generates warning information and pushes it to the user via a preset path.

[0036] In one possible implementation, the method further includes:

[0037] In response to the arrival of the preset reporting period, it automatically summarizes the account information, transaction data and reconciliation results corresponding to each global account code identifier;

[0038] Multi-dimensional statistical reports are generated based on preset report templates. These multi-dimensional statistical reports include account balance reports categorized by institution, transaction detail reports categorized by account type, and reconciliation discrepancy analysis reports.

[0039] The multi-dimensional statistical reports are automatically pushed to a preset list of recipients and stored in the report history database.

[0040] Secondly, embodiments of this application provide a multi-type account management device, including:

[0041] The generation module is used to generate a global account code identifier corresponding to each account in response to obtaining multiple different types of account information, based on a preset account coding rule and the account information;

[0042] The storage module is used to associate and store the global account code identifier and the account information corresponding to each account, wherein the multiple different types of accounts include at least one type of fund account and at least one type of precious metal account;

[0043] The acquisition module is used to, in response to receiving transaction data of the target account, acquire the global account code identifier and transaction type corresponding to the target account from the transaction data;

[0044] The determination module is used to determine the corresponding preset accounting rules based on the global account code identifier and the transaction type;

[0045] The generation module is also used to generate corresponding journal entries according to the preset accounting rules corresponding to the target account;

[0046] The storage module is also used to associate and store entries in a preset accounting table;

[0047] The acquisition module is further configured to, in response to receiving an initial statement of the target account, acquire the global account code identifier corresponding to the target account from the initial statement of the target account;

[0048] The determining module is further configured to determine the data parser corresponding to the target account based on the global account code identifier, so as to use the corresponding data parser to convert the initial statement into a standard statement;

[0049] The reconciliation module is used to perform reconciliation processing based on the standard reconciliation statement and the preset accounting table.

[0050] Thirdly, embodiments of this application provide a multi-type account management device, including: a memory and a processor;

[0051] The memory stores computer-executed instructions;

[0052] The processor executes computer execution instructions stored in the memory, causing the processor to perform the first aspect and / or various possible implementations of the first aspect as described above.

[0053] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the first aspect and / or various possible implementations of the first aspect.

[0054] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0055] The multi-type account management method, apparatus, device, storage medium, and program product provided in this application generate a global account code identifier through preset account coding rules, providing a unified identity identifier for different types of accounts. In subsequent operations, regardless of the account type, the unique code identifier can quickly and accurately locate and identify the account, avoiding identification confusion caused by different account types. The global account code identifier is associated with the corresponding account information for each account, achieving centralized management of account information. This facilitates comprehensive monitoring and analysis of the entire account system, providing a solid foundation for subsequent transaction processing, reconciliation, and other operations. By obtaining the global account code identifier and transaction type from transaction data, the preset accounting rules matching the target account and transaction type can be accurately determined. This precise matching method ensures that each transaction is recorded according to the correct rules, avoiding accounting errors and confusion, and improving the accuracy and reliability of financial data. It supports multiple types of accounts and transactions. When a new account type or transaction type appears, only the corresponding accounting rules need to be preset, and matching can be performed upon receiving transaction data, without requiring large-scale modifications to the entire system, thus improving the system's scalability and adaptability. The system generates corresponding journal entries according to preset accounting rules, ensuring that every transaction is recorded in a unified manner. These generated entries are stored in a preset accounting table, resulting in a well-organized financial data structure. By determining the corresponding data parser based on the global account code identifier, initial reconciliation statements in various formats can be converted into a unified standard reconciliation statement. This eliminates obstacles caused by data format differences, allowing subsequent reconciliation processing to be based on a unified data format, improving the efficiency and accuracy of reconciliation. By comparing the standard reconciliation statement with the data in the preset accounting table, discrepancies and errors in account transaction records can be detected promptly, ensuring that the accounting records match the actual business situation. The method provided in this application achieves unified management of various types of accounts, improving the efficiency and accuracy of account management. Attached Figure Description

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

[0057] Figure 1 This application provides an application scenario diagram for multi-type account management;

[0058] Figure 2 A flowchart illustrating a multi-type account management method provided in an embodiment of this application;

[0059] Figure 3 A flowchart illustrating a multi-type account management method provided in another embodiment of this application;

[0060] Figure 4 This is a schematic diagram of the structure of a multi-type account management device provided in an embodiment of this application;

[0061] Figure 5 This is a schematic diagram of the structure of a multi-type account management device provided in an embodiment of this application.

[0062] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0063] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0064] The collection, storage, use, processing, transmission, provision, and disclosure of financial data or user data involved in the technical solution of this application all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0065] It should be noted that in the embodiments of this application, certain software, components, models and other existing solutions in the industry may be mentioned. These should be regarded as exemplary and are only intended to illustrate the feasibility of implementing the technical solution of this application. However, it does not mean that the applicant has used or necessarily used the solution.

[0066] To clearly understand the technical solution of this application, the solutions of the prior art will be described in detail first.

[0067] In the course of financial institutions' business operations, the involvement of both domestic and international transactions has led to a multi-type and multi-attribute account management structure. Different accounts correspond to different storage scenarios and clearing systems, requiring them to meet domestic and international business compliance requirements and asset control standards respectively. Currently, financial institutions employ a management system that separates cash accounts from precious metal accounts. Cash accounts are primarily managed uniformly through an internal accounting system, which can complete the accounting records for domestic and international clearing funds and support reconciliation with external systems. However, precious metal accounts are scattered across multiple independent systems, with international gold, gold exchange gold, and branch inventory each corresponding to different management systems, and some precious metal accounts relying on manual recording and maintenance. Furthermore, the management standards for precious metal accounts are inconsistent; some are recorded according to physical units, while others are recorded according to monetary value, lacking an effective collaborative management mechanism, resulting in a lack of coordinated management between the two types of accounts. Because multiple types of accounts are scattered across different systems, existing technology cannot achieve unified account management. During daily bookkeeping, it is necessary to switch between different systems, and additional data adjustments are required due to differences in accounting standards. During the reconciliation process, it is necessary not only to connect reconciliation data from different systems, but also to deal with the problem of inconsistent units. The overall operation process is complex, which greatly reduces business processing efficiency and increases the risk of data errors.

[0068] Therefore, when facing the technical problems in existing technologies, to achieve global account collaboration and reduce management complexity, the focus is first on the issue of account system isolation. Funds and precious metals accounts belong to different systems and lack a unified identifier, resulting in a lack of linkage. To avoid resource consumption and efficiency losses from cross-system operations, a global account code identifier is generated for each type of account through preset account coding rules. This accurately associates the code with account information, eliminating the need to scan multiple systems to locate accounts. This avoids the resource waste caused by blindly switching systems and quickly establishes a unified account identity, breaking down system isolation barriers. Addressing the issue of inconsistent accounting standards and lack of matching rules for different accounts, to ensure accurate accounting and compliance with business specifications, the generated global account code identifier quickly locates the account type. This is combined with the transaction type in the transaction data to match preset accounting rules, and the entries are stored in a unified accounting table linked to the global code. This avoids accounting errors caused by differences in accounting standards, eliminates the need for manual data adjustments, ensures compliant entry generation, and improves accounting efficiency. Finally, to reduce labor costs and improve reconciliation accuracy, a dedicated data parser for each account is bound using the global account code identifier. Upon receiving the initial reconciliation statement, the system automatically converts statements of different formats and units into a standard format using a code-matching parser, and then reconciles them with a unified accounting table. This avoids the inefficiency and errors of manual format conversion, eliminates the need for additional data discrepancy handling, ensures the reconciliation system is compatible with data from multiple sources, improves reconciliation efficiency, and solves the problems of inefficient and error-prone reconciliation.

[0069] Figure 1This is a diagram illustrating an application scenario that enables the management of multiple account types provided in this application, such as... Figure 1 As shown in the diagram, the scenario diagram corresponding to the multi-type account management provided in this application includes: application server 101, terminal device 102, and external server. It is understood that there are multiple accounts opened with multiple external financial institutions, i.e., multiple different types of accounts, therefore multiple external servers are possible. For example, as... Figure 1 External servers 103a and 103b are mentioned.

[0070] Among them, the multi-type account management device can be integrated into the application server 101. The application server 101 is the core device for deploying the financial business management system, responsible for the unified management of fund accounts and precious metal accounts and the execution of accounting processing logic; the terminal device 102 is used by business personnel to perform operations such as account inquiry and transaction initiation.

[0071] Specifically, when the method provided in this application is executed for the first time, or when a new type of account is added, the user needs to initiate an encoding generation request on the terminal device 102. The encoding generation request may include the identifier of an external server. After receiving the request, the application server 101 establishes a connection with the corresponding external server, such as external server 103a and external server 103b, and obtains the account information of the corresponding account. In response to obtaining multiple different types of account information, the application server 101 generates a global account code identifier corresponding to each account according to the preset account encoding rules and account information, and stores the global account code identifier and the account information corresponding to each account in association. The application server 101 also integrates a business processing device for processing business transactions. After processing the transaction, the business processing device sends the transaction data to the multi-type account management device. In response to receiving the transaction data of the target account, the device obtains the global account code identifier and transaction type corresponding to the target account from the transaction data, and determines the corresponding preset accounting rules according to the global account code identifier and transaction type. The device generates the corresponding journal entry according to the preset accounting rules corresponding to the target account and stores it in association in the preset accounting table. External financial institutions periodically send account statements to application server 101. For example, external server 103a sends an initial account statement to application server 101. In response to receiving the initial account statement for the target account, application server 101 obtains the global account code identifier corresponding to the target account from the initial account statement, and determines the data parser corresponding to the target account based on the global account code identifier. The corresponding data parser is then used to convert the initial account statement into a standard account statement. Reconciliation is then performed based on the standard account statement and the preset accounting table.

[0072] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0073] Figure 2 This is a flowchart illustrating a multi-type account management method provided in an embodiment of this application, as shown below. Figure 2 As shown, the execution entity in this embodiment is a multi-type account management device. This device can be implemented through a computer program, or through a medium storing the relevant computer program, such as a USB flash drive and / or optical disc, or through a physical device integrating or installing the relevant computer program, such as a chip or a multi-type account management device. The multi-type account management device can be a server, a server cluster, etc. The multi-type account management method provided in this embodiment includes the following steps:

[0074] S201. In response to obtaining multiple different types of account information, generate a global account code identifier corresponding to each account according to the preset account coding rules and account information, and associate and store the global account code identifier and the account information corresponding to each account. The multiple different types of accounts include at least one type of fund account and at least one type of precious metal account.

[0075] For example, different types of accounts may include a funds account opened with the central bank, a funds account established with Bank B, a precious metals account opened with the International Gold Exchange, a precious metals account opened with the Gold Exchange, etc.

[0076] Among them, the preset account coding rules refer to the predefined coding generation specifications used to transform account information into structured global codes, ensuring the uniqueness, recognizability and compatibility of the codes.

[0077] For example, a hierarchical structured coding system is used, consisting of "account type code + system affiliation code + business scenario code + unique serial number": Account type code (2 digits): "01" for funds accounts, "02" for precious metals accounts; System affiliation code (3 digits): "INT" for international gold systems, "CEX" for gold exchange systems, etc.; Business scenario code (2 digits): "CN" for domestic transactions, "AB" for overseas transactions; Unique serial number (6 digits): Automatically generated according to the account creation order to ensure uniqueness. Example: The global account code identifier for an international gold account (overseas transactions) might be "02INTAB000001".

[0078] Account information refers to the basic attribute data of an account, such as the currency of a funds account, the precious metal type (gold, silver) of a precious metal account, the account line code, and the account line name.

[0079] Optionally, connections can be established with systems corresponding to different accounts, such as through API interfaces or data synchronization tools, such as ETL to connect to fund account systems, such as internal account systems, precious metal account systems, such as international gold management systems, to collect account information in batches.

[0080] Specifically, when multiple different types of account information are obtained, the system parses key attributes related to coding within the account information, such as account type and system affiliation. It matches the corresponding fields in the coding rules and automatically generates a global account code identifier. A "Global Account Information Table" is then created in the multi-type account management device, with fields including: global account code identifier, original account ID, account type, system affiliation, basic attributes (currency / precious metal type, etc.), status, and creation time. The generated global account code identifier is then associated and stored with the corresponding original account information.

[0081] Optionally, a real-time synchronization trigger can be set to automatically synchronize and update the associated records in the multi-type account management devices when the original system account information changes, such as status updates or attribute modifications, to ensure data consistency.

[0082] S202. In response to receiving transaction data of the target account, obtain the global account code identifier and transaction type corresponding to the target account from the transaction data, and determine the corresponding preset accounting rules based on the global account code identifier and transaction type.

[0083] The target account refers to the specific account that receives the relevant information. It can be a funds account or a precious metals account, and is uniquely identified by a global account code.

[0084] Transaction data refers to business data generated when an account undergoes changes, including key information such as the transaction entity (target account), transaction behavior (e.g., buying, selling, transferring), transaction quantity / amount, transaction time, and counterparty. For example, precious metal purchase transaction data may include information such as "Account A, Purchase, 100 grams of gold, 2024-09-25, Exchange B".

[0085] Among them, transaction type refers to the category of transaction behavior divided according to business scenario, including one-sided transactions, such as buying, selling, foreign exchange settlement, and foreign exchange sales; and two-way transactions, such as domestic and foreign transfers, intra-system transfers, and inventory adjustments.

[0086] Among them, the preset accounting rules refer to the predefined accounting processing specifications, which are dynamically matched according to the account type (funds / precious metals) and transaction type, and clarify the accounting direction, accounting unit, and mapping relationship of accounting subjects.

[0087] It is understandable that transactions with other external financial institutions are handled by a separately deployed trading system. After the transaction is completed, the trading system sends the transaction data to a multi-type account management device for further processing.

[0088] Specifically, upon receiving transaction data from the target account, the system locates the account identifier field, extracts the global account code, and parses the code to obtain basic account attributes, such as "02" representing a precious metals account and "BRN" representing a branch system. The system then parses the transaction behavior field in the transaction data to obtain the transaction type, such as buy or sell. Using the global account code identifier and transaction type as indexes, the corresponding preset accounting rules are determined.

[0089] Optionally, an accounting rule matrix table can be pre-established in a multi-type account management device, using the global account code identifier and transaction type as the primary key to associate specific accounting rule content.

[0090] For example, in a precious metals account, the corresponding accounting rules for a purchase are: debit to precious metals inventory (physical unit); credit to funds payable (currency unit).

[0091] Optionally, the accounting unit can be automatically switched according to rules. For example, precious metals accounts default to physical units such as "grams" and "ounces," while funds accounts default to currency units such as "RMB" and "USD," and the unit conversion relationship is recorded, such as 1 ounce = 31.1035 grams. When no rule is matched, such as in the case of a new type of transaction, the default rule is triggered, the pending status is recorded, and the operations and maintenance personnel are notified to avoid transaction interruption. When there are version iterations of rules, the activation / deactivation of rules is controlled by the effective time field to ensure a smooth transition between old and new rules.

[0092] S203. Generate corresponding journal entries based on the preset accounting rules for the target account and store them in the preset accounting table.

[0093] An entry is a standardized data unit that records changes in account transactions. It includes information such as the posting direction, accounting subject, transaction amount / quantity, posting unit, and associated global account code, serving as the core voucher for accounting processing. For example, the entry for a precious metals purchase transaction might be "Debit: Precious Metals Inventory (100 grams), Credit: RMB Funds Account (50,000 yuan)". A pre-defined journal entry table is a structured data table used to uniformly store all account transaction entries. It achieves centralized management of entries for both the funds account and precious metals account by associating them with global account codes, supporting multi-dimensional queries and reconciliation. The table may include fields such as entry ID, global account code, transaction serial number, debit / credit direction, accounting subject, amount / quantity, posting unit, and transaction time.

[0094] Specifically, based on the pre-defined accounting rules, the core elements in the transaction data are parsed and mapped to journal entry fields. For example, the accounting subject is determined according to the account mapping relationship defined in the rules, and the accounting direction is determined according to the transaction type. After the journal entry is generated, it is bound to the global account code identifier and transaction serial number, and stored in the pre-defined accounting table.

[0095] Optionally, for two-way transactions, such as transfers, paired entries need to be generated, such as crediting the transferring account and debiting the receiving account, and linked through the same transaction serial number to ensure account balance.

[0096] S204. In response to receiving the initial statement of the target account, obtain the global account code identifier corresponding to the target account from the initial statement of the target account, and determine the data parser corresponding to the target account based on the global account code identifier, so as to use the corresponding data parser to convert the initial statement of the target account into a standard statement of the target account.

[0097] The initial statement refers to the raw, unprocessed reconciliation data file obtained directly from various external systems, such as the financial exchange system and the branch's internal accounting system.

[0098] A standard reconciliation statement refers to a reconciliation data file generated after processing according to unified specifications, such as preset field structures, units of measurement, and data formats.

[0099] Optionally, before receiving the initial statement, dedicated data receiving channels can be set up for different external systems, such as receiving MT608 messages through the SWIFT network interface, receiving XML format statements through the Gold Exchange Open Platform API, and receiving Excel statements through the branch's internal file transfer protocol.

[0100] Specifically, upon receiving the initial account statement for the target account, the system locates and extracts the account identification information field based on the format of the source system of the initial account statement. Then, it matches the corresponding global account code identifier based on the account identification information. A mapping relationship between global account code identifiers and data parsers is pre-configured in the multi-type account management device, such as a parser configuration table. A query is performed in the parser configuration table based on the obtained global account code identifier to filter out the corresponding data parser. The matched data parser is then activated and processes the initial account statement according to preset logic to obtain a standard account statement.

[0101] S205. Perform reconciliation processing based on standard reconciliation statements and preset accounting tables.

[0102] The reconciliation process involves comparing and verifying the data in the standard reconciliation statement with the data in the pre-set accounting table to confirm whether the transaction information recorded by the two is consistent. The core is to verify the completeness, accuracy and consistency of account transactions, and finally output the reconciliation results, such as consistency, difference and the reason for the difference.

[0103] Specifically, based on the global account code identifier in the standard reconciliation statement, the entries corresponding to the same code are selected from the preset accounting table, and the reconciliation begins.

[0104] For example, the record "2024-09-25, Purchase, 100 grams of gold" in the standard account statement needs to be found in the preset accounting table as a debit entry with the same date, the same transaction type, and a quantity error within the allowable range.

[0105] Optionally, during reconciliation, a multi-dimensional comparison can be adopted. For example, for cash accounts, the comparison can be made of transaction amount, transaction summary, and account balance. For precious metals accounts, the comparison can be made of transaction weight, number of precious metal units, open position balance, and valuation amount. If the comparison items are completely consistent, the reconciliation is marked as successful; if there are differences, they are marked as reconciliation differences and the differences are recorded.

[0106] The multi-type account management method provided in this application generates a global account code identifier through preset account coding rules, providing a unified identity identifier for different types of accounts. In subsequent operations, regardless of the account type, the unique code identifier can quickly and accurately locate and identify the account, avoiding identification confusion caused by different account types. The global account code identifier is associated with and stored with the corresponding account information for each account, achieving centralized management of account information. This facilitates comprehensive monitoring and analysis of the entire account system, providing a solid foundation for subsequent transaction processing, reconciliation, and other operations. By obtaining the global account code identifier and transaction type from transaction data, the preset accounting rules matching the target account and transaction type can be accurately determined. This precise matching ensures that each transaction is recorded according to the correct rules, avoiding accounting errors and confusion, and improving the accuracy and reliability of financial data. It supports multiple types of accounts and transactions. When a new account type or transaction type appears, only the corresponding accounting rules need to be preset and matched upon receiving transaction data, without requiring large-scale modifications to the entire system, thus improving the system's scalability and adaptability. The system generates corresponding journal entries according to preset accounting rules, ensuring that every transaction is recorded in a unified manner. These generated entries are stored in a preset accounting table, resulting in a well-organized financial data structure. By determining the corresponding data parser based on the global account code identifier, initial reconciliation statements in various formats can be converted into a unified standard reconciliation statement. This eliminates obstacles caused by data format differences, allowing subsequent reconciliation processing to be based on a unified data format, improving the efficiency and accuracy of reconciliation. By comparing the standard reconciliation statement with the data in the preset accounting table, discrepancies and errors in account transaction records can be detected promptly, ensuring that the accounting records match the actual business situation. The method provided in this application achieves unified management of various types of accounts, improving the efficiency and accuracy of account management.

[0107] As an optional implementation, based on the above embodiments, in response to obtaining multiple different types of account information, a global account code identifier corresponding to each account is generated according to a preset account coding rule and the account information, including:

[0108] In response to receiving a user-initiated encoding generation request, it establishes connections with multiple systems containing accounts of different types;

[0109] Retrieve corresponding account information from multiple different systems;

[0110] According to the preset account coding rules, the coding-related information is extracted from the account information, and a global account code identifier corresponding to each account is generated based on the coding-related information.

[0111] The code generation request refers to the operation instruction initiated by users, such as system administrators or business personnel, to trigger the global account code generation process. It can be submitted manually through the system interface or automatically triggered by a scheduled task. It includes parameters such as the range of accounts that need to generate codes, such as all accounts or newly added accounts.

[0112] For example, the system where the account is located could be the NOSTRO clearing system corresponding to the funds account, the overseas interbank account system corresponding to the international gold account, the exchange member system corresponding to the gold exchange account, or the branch internal management system corresponding to the branch inventory account, etc.

[0113] Among them, coding-related information refers to the key attribute data extracted from account information used to generate global account codes, including account type (funds or precious metals), system identifier, business scenario (domestic or overseas), account status (normal or frozen), etc., which are the core input items of coding rules.

[0114] Optionally, users can select the function to generate a global account code identifier in the visual operation interface and specify the account range, such as adding a new account or all accounts, and then submit a request.

[0115] Specifically, upon receiving a user-initiated code generation request, communication is established using the corresponding connection protocol based on the interface specifications of the systems hosting different accounts. For example, for international gold accounts, a connection is established via the SFTP protocol or a dedicated API interface; for the gold exchange member system, a connection is established via the HTTPS interface of the gold exchange's open platform, using API keys and tokens for authentication. After establishing the connection, account information corresponding to each account is obtained from each system. For example, from the international gold account system, fields such as account number, precious metal type, storage location, account opening date, and account status are extracted using SQL queries. Based on preset account coding rules, coding-related information, such as account type, business scenario, and system affiliation, is extracted from the account information. The extracted coding-related information is then mapped to coding components according to the preset account coding rules, such as mapping a funds account to 01 and a precious metal account to 02; mapping the international gold system to INT and domestic transactions to CN, etc. The mapped codes are then arranged in sequence to generate a global account code identifier for each account.

[0116] The multi-type account management method provided in this application, in response to obtaining multiple different types of account information, generates a global account code identifier corresponding to each account based on preset account coding rules and account information. The method includes: in response to receiving a user-initiated code generation request, establishing connections with the systems containing multiple different types of accounts; obtaining corresponding account information from multiple different systems; extracting coding-related information from the account information according to preset account coding rules, and generating a global account code identifier corresponding to each account based on the coding-related information. By connecting different account systems, data silos are broken down, enabling cross-system data flow. Obtaining corresponding account information from multiple different systems ensures the comprehensiveness of the information required for code generation. Extracting coding information based on preset rules ensures a unified coding format. Then, generating a global account code identifier based on the coding-related information serves as a globally unique code, ensuring that accounts are uniquely identified across multiple systems, avoiding confusion caused by duplicate coding, and supporting cross-system data association and querying.

[0117] As an optional implementation, based on the above embodiments, the target account is a precious metals account, the preset accounting rule is a binary accounting rule, and corresponding journal entries are generated according to the preset accounting rule corresponding to the target account and stored in a preset accounting table, including:

[0118] Retrieve the unit weight of precious metals from transaction data;

[0119] Generate physical holdings and valuation entries based on the unit weight of precious metals;

[0120] The physical holding entries and valuation entries are stored together in a pre-defined accounting table.

[0121] Among them, the dual-track accounting rule refers to a special accounting standard designed for precious metal accounts. It requires the simultaneous recording of changes in the physical quantity and monetary value of precious metals, forming two accounting tracks: physical holdings and valuation. This reflects both the actual weight of precious metals held in the account and their monetary value calculated at market prices, thus meeting the dual needs of physical control and financial accounting.

[0122] Among them, physical holding entries refer to accounting vouchers that record changes in the weight of precious metals based on physical units such as grams and ounces. They only reflect changes in quantity and do not involve currency value conversion. Their core purpose is for physical inventory management, such as tracking the actual amount of precious metals stored.

[0123] Valuation entries are accounting documents generated by converting the weight of precious metals into monetary value based on real-time market prices, using monetary units as the measurement basis. They reflect changes in the asset value of precious metals and are primarily used for financial statement preparation and asset valuation.

[0124] Specifically, when the target account is confirmed to be a precious metals account, the corresponding accounting rule is selected as the binary accounting rule. Precious metal weight-related fields are extracted from the precious metals transaction data. If the original weight unit is a non-standard unit, the unit conversion module is automatically invoked for conversion, for example, converting 2 ounces of gold to 62.207 grams of gold. The processed standard weight is bound to the transaction serial number and global account code, providing basic data for the generation of the two types of subsequent entries. Using the unit weight as the core, accounting subjects are matched according to the transaction type to determine the accounting direction, and the global account code and transaction serial number are bound as association identifiers, forming a physical holding entry that only reflects changes in precious metal weight. The real-time interface is called to obtain the precious metals market price at the time of the transaction, and the monetary value is calculated according to the valuation amount = standard weight × real-time unit price. Subsequently, accounting subjects are matched according to the transaction type to determine the accounting direction, and the calculated valuation amount and corresponding currency unit are filled in. The global account code and transaction serial number of the physical holding entry are shared to achieve association, generating a valuation entry. The physical holding entry and valuation entry are stored in a designated location in the preset accounting table.

[0125] Optionally, a combined index can be created in the global account code identifier + transaction serial number + entry type fields to support quick querying of the complete dual-track entry for a certain transaction; or a dual-track association marker field can be added, where the two types of entries in the same transaction are marked with the same value, which facilitates quick matching of the two types of entries during subsequent reconciliation and verifies the logical consistency between the physical quantity and the estimated amount.

[0126] The multi-type account management method provided in this application embodiment targets precious metal accounts and uses a binary accounting rule as the preset accounting rule. It generates corresponding journal entries based on the preset accounting rule for the target account and stores them in a preset accounting table. The method includes: obtaining the unit weight of precious metals from transaction data; generating physical holding entries and valuation entries based on the unit weight of precious metals; and storing the physical holding entries and valuation entries in the preset accounting table. The physical holding entries record the physical transfer of precious metals, while the valuation entries record the impact of price changes on the accounting records. After separation, errors in physical operations will not directly contaminate the valuation data, and vice versa, facilitating the identification of the root cause of the problem. The linked physical holding entries and valuation entries form a complete chain, supporting full-process traceability from transaction initiation to position changes and valuation adjustments.

[0127] As an optional implementation, based on the above embodiments, in response to receiving an initial statement for the target account, the global account code identifier corresponding to the target account is obtained from the initial statement, and the data parser corresponding to the target account is determined according to the global account code identifier, so as to convert the initial statement into a standard statement using the corresponding data parser, including:

[0128] In response to obtaining the initial statement, the account identification information is extracted from the initial statement, and the corresponding global account code is matched based on the account identification information;

[0129] The corresponding data parser is determined based on the matched global account code identifier;

[0130] A data parser is used to extract transaction elements from the initial statement. These elements include transaction time, transaction number, transaction subject, transaction quantity, and transaction object.

[0131] The transaction elements are converted into a standard statement containing a global account code identifier according to the preset field format.

[0132] Account identification information refers to the original information in the initial account statement used to uniquely identify the target account. Due to differences in the source system, the format varies, such as the member account code in the financial exchange account statement. It is the core basis for matching the global account code identifier.

[0133] Among them, the preset field format refers to the unified data structure specification set by the standard statement, such as field name, data type, length, format requirements, etc., to ensure that the structure of statements from different sources is consistent after conversion.

[0134] Specifically, after obtaining the initial account statement, account identification information is extracted using preset field location rules. Then, based on the pre-stored correspondence between system account identification information and global account codes, the corresponding global account code is matched. The prefix of the global account code is extracted, and prefix matching is performed based on pre-configured information including the global account code prefix and data parser name to select a suitable data parser. Using the selected data parser, target transaction elements are extracted according to the built-in mapping rules between initial fields and transaction elements, such as the transaction number: extracted from the transaction serial number column of the branch Excel file. The transaction elements are converted according to preset field formats, such as converting transaction time to "YYYY-MM-DD HH:MM:SS" format and transaction objects to preset codes, such as converting Shanghai Gold Exchange to 101. Finally, the standardized transaction elements are combined with the global account code according to the preset field formats to generate a standard account statement.

[0135] The multi-type account management method provided in this application, in response to receiving an initial account statement for a target account, obtains the global account code identifier corresponding to the target account from the initial account statement, and determines the data parser corresponding to the target account based on the global account code identifier, so as to convert the initial account statement into a standard account statement using the corresponding data parser. The method includes: in response to obtaining the initial account statement, extracting account identification information from the initial account statement, and matching the corresponding global account code identifier based on the account identification information; determining the corresponding data parser based on the matched global account code identifier; using the data parser to extract transaction elements from the initial account statement, including transaction time, transaction number, transaction subject, transaction quantity, and transaction object; and converting the transaction elements into a standard account statement containing the global account code identifier according to a preset field format. Extracting account identification information from the initial account statement and quickly matching unique codes through a global account code identifier library avoids manual searching or hard-coded associations, reducing human error and time costs. Automatically determining the corresponding data parser based on the global code identifier eliminates the need to develop separate processing logic for account statements from different sources, improving processing efficiency. A dedicated data parser customizes parsing rules for different statement formats, ensuring that key elements are extracted completely and accurately, avoiding data omissions or errors due to format differences. The extracted transaction elements are converted to a preset standard format, eliminating semantic ambiguity between statements from different sources and improving data consistency. The converted standard statement includes a global account code identifier and standardized fields, which can be directly used for subsequent reconciliation, reducing manual processing steps.

[0136] As an optional implementation, based on the above embodiments, the method further includes:

[0137] Mark each completed standard reconciliation statement;

[0138] In response to a transaction time discrepancy, the transaction time is extended by a preset transaction duration error value and the comparison is repeated.

[0139] In response to a difference marked as an amount or weight, the corresponding external system interface is invoked to query the original transaction voucher;

[0140] In response to a transaction being marked as missing, a request to complete the transaction is sent to the corresponding external system.

[0141] In response to the elimination of differences after processing, the flag is updated to pass;

[0142] If a difference still exists after processing, an anomaly alarm is triggered and the difference details are pushed to the preset terminal.

[0143] The preset transaction duration error value refers to a pre-set reasonable time range deviation that allows for the existence of transaction time, such as ±5 minutes. It is used to handle differences in transaction time records caused by system clock asynchrony and to avoid misjudging them as real differences.

[0144] The external system interface refers to the communication interface that connects to the external system from which the statement of account is generated.

[0145] Among them, original transaction vouchers refer to files or data stored in external systems that record the original transaction information.

[0146] Among them, the order replenishment request refers to the instruction sent to the external system to request the re-pushing of the transaction data when there is a transaction record in the standard statement but the corresponding entry is missing in the preset accounting table. The instruction includes key location information such as transaction number and transaction time.

[0147] Among them, the preset terminal refers to the pre-configured device that receives abnormal alarms and difference details.

[0148] Specifically, after the reconciliation process is completed, each standard reconciliation statement record is automatically marked according to the preset marking rules, such as marked as passed or different. Transaction time difference: The time record of the same transaction in the standard reconciliation statement and the preset accounting table deviates by more than ±1 minute, but other information is consistent.

[0149] When the standard statement indicates a transaction time discrepancy, a preset transaction duration error value is read. Using the transaction time in the standard statement as a benchmark, the extended time range is calculated. For example, if the standard statement's transaction time is "2024-09-26 10:30:00" and the error value is ±5 minutes, the adjusted comparison time range is "2024-09-26 10:25:00 ~ 2024-09-26 10:35:00". In the preset journal entry sheet, entries with transaction numbers matching the standard statement and transaction times within the adjusted range are filtered out, and the amount / weight, transaction object, and other information are verified again to ensure they match.

[0150] When the standard reconciliation statement is marked as having a difference in amount or weight, the corresponding external system interface is determined and a connection is established based on the reconciliation statement source field in the standard reconciliation statement. The original transaction voucher returned by the external system is received, and the amount / weight information in the voucher is extracted and compared with the standard reconciliation statement and the preset accounting table. When the standard reconciliation statement is marked as having a missing transaction record, the parameters for a replacement request are assembled according to the specific type of missing transaction record, and a request is sent through the external system's replacement request interface. The replacement request result returned by the external system is received, and the reconciliation process is repeated.

[0151] After the discrepancy is eliminated, the standard statement is marked as passed; if discrepancies still exist after discrepancy processing, an anomaly alarm is generated and the anomaly details are pushed to the preset terminal.

[0152] For example, alarm levels are categorized based on the severity of unresolved discrepancies: Level 1 alarms indicate large discrepancies or batch missing data; Level 2 alarms indicate small discrepancies or single missing data. Alarm information is assembled according to the alarm level, including: basic discrepancy information such as global account code, transaction number, discrepancy type, and discrepancy amount / weight. Alarm information is pushed according to preset terminal configurations: Level 1 alarms are pushed to maintenance personnel's work terminals and via SMS; Level 2 alarms are pushed to the business management platform, etc.

[0153] The multi-type account management method provided in this application includes: marking each completed standard reconciliation statement; in response to a mark indicating a transaction time difference, extending the transaction time by a preset transaction duration error value and then re-comparing; in response to a mark indicating an amount or weight difference, calling the corresponding external system interface to query the original transaction voucher; in response to a mark indicating a missing transaction record, sending a supplementary order request to the corresponding external system; in response to the elimination of the difference after processing, updating the mark to pass; in response to the existence of a difference after processing, triggering an abnormal alarm and pushing the difference details to a preset terminal. Marking the standard reconciliation statements with differences breaks down complex reconciliation problems into manageable subcategories, which can be addressed in a targeted manner after classification. Extending the transaction time by a preset error value and then re-comparing can automatically resolve false differences caused by system synchronization delays or incorrect time zone settings, avoiding the time cost and error risk of manual adjustments. Calling the external system interface to query the original transaction voucher ensures the authority of the data source. Sending a supplementary order request to the external system realizes the automated supplementation of missing records, avoiding delays and omissions in manual supplementation and ensuring the completeness of reconciliation. Once the discrepancy is resolved, the record is automatically updated to "passed," creating a complete reconciliation history. If a discrepancy still exists after processing, an alarm is immediately triggered, and discrepancy details are pushed to preset terminals to ensure that relevant personnel intervene as soon as possible and prevent the problem from escalating.

[0154] As an optional implementation, based on the above embodiments, the method further includes:

[0155] In response to the completion of associated storage, entry generation, or reconciliation processing, the account status information is automatically updated, including the current balance, number of positions held, the time of the most recent transaction, and the reconciliation status.

[0156] Real-time monitoring tasks are used to determine whether account status information triggers preset warning conditions;

[0157] In response to triggering preset warning conditions, the system automatically generates warning information and pushes it to the user via a preset path.

[0158] Account status information refers to a set of key data used to reflect the core dynamics of an account in real time, covering the account's asset size, transaction history, and reconciliation results. It may include the current balance, number of positions, recent transaction time, and reconciliation status.

[0159] Among them, the real-time monitoring task refers to the continuously running automated detection program that scans the status information of all accounts at a preset frequency, such as every 30 seconds, compares it with preset warning conditions, and captures abnormal statuses in real time, avoiding delays and omissions caused by manual monitoring.

[0160] Among them, the preset early warning conditions refer to the abnormal judgment rules pre-configured according to the business risk management needs, which are distinguished by account type.

[0161] The preset path refers to the pre-defined channels for pushing early warning information, such as the work terminals of maintenance personnel. The corresponding path can be matched according to the warning level, such as emergency / normal.

[0162] Specifically, once any one of the operations—association storage, journal entry generation, or reconciliation processing—is completed, the corresponding account status information is automatically updated. For example, the current balance of the funds account is set to the original balance plus the journal entry amount (positive for debits and negative for credits), ensuring real-time data synchronization. The most recent transaction time is retrieved, overwriting the original field value to ensure the latest transaction node is recorded. The reconciliation status is directly overwritten by the final result field of the reconciliation task, while also recording the reconciliation completion time. Scheduled monitoring tasks scan accounts at a set frequency, matching alert conditions based on account type and comparing status information to determine if an alert has been triggered. For example, if precious metals account B holds 450 grams of gold, and the matching condition is <500 grams, an alert is triggered. Once an alert is triggered, information including basic information and trigger details is generated according to a template, and a push path is matched based on the alert level to push the information to the user.

[0163] The multi-type account management method provided in this application further includes: automatically updating account status information in response to the completion of associated storage, entry generation, or reconciliation processing. The account status information includes the current balance, number of positions held, recent transaction time, and reconciliation status. A real-time monitoring task is used to determine whether the account status information triggers a preset warning condition. In response to triggering the preset warning condition, a warning message is automatically generated and pushed to the user according to a preset path. After completing associated storage, entry generation, or reconciliation processing, the account status information is automatically updated to ensure real-time consistency of data across all modules within the system. Through a real-time monitoring task, the current data is compared with the preset warning condition, and an immediate response is initiated upon triggering. Warning information is pushed according to a preset path to ensure that the user is informed immediately.

[0164] As an optional implementation, based on the above embodiments, the method further includes:

[0165] In response to the arrival of the preset reporting period, it automatically summarizes the account information, transaction data and reconciliation results corresponding to each global account code identifier;

[0166] Multi-dimensional statistical reports are generated based on preset report templates. These multi-dimensional statistical reports include account balance reports categorized by institution, transaction detail reports categorized by account type, and reconciliation discrepancy analysis reports.

[0167] Automatically push multi-dimensional statistical reports to a preset list of recipients and store them in the report history database.

[0168] The preset report cycle refers to the pre-configured time interval for automatic report generation, which can be set according to business needs, such as daily or monthly, and supports differentiated configuration based on account type.

[0169] Among them, multi-dimensional statistical reports refer to a standardized set of reports that summarize and analyze account data from different business perspectives.

[0170] The reconciliation discrepancy analysis report summarizes the reconciliation results of all accounts within the period, including the types and quantities of discrepancies and their processing progress.

[0171] The preset recipient list refers to a pre-defined list of report recipients and their permissions, including name, department, receiving channel, and report viewing permissions.

[0172] The report history database refers to a structured database used to store all generated reports, recording the report name, generation time, cycle type, storage format, and associated cycle.

[0173] Specifically, a scheduled task monitors the preset report cycle and initiates data aggregation upon the scheduled time. It extracts account type, affiliated institution, and other information from the global account information table and groups them by code; extracts transaction entries within the cycle from the preset accounting table; and extracts reconciliation records from the reconciliation result table. Invalid data is then removed, and the three types of data are associated using global account codes. Numerical data is aggregated to form a unified dataset. Reports are generated based on built-in preset report templates, and the report engine is used to populate the templates with data. Matching personnel are selected from the preset recipient list, and permissions are verified. Reports are then pushed to the preset recipients via specified paths. Simultaneously, reports are stored in binary form in the historical database, metadata is recorded, indexes are created, data is retained according to a strategy, and archived offline upon expiration.

[0174] The multi-type account management method provided in this application further includes: automatically summarizing account information, transaction data, and reconciliation results corresponding to each global account code identifier in response to reaching a preset reporting period; generating multi-dimensional statistical reports based on preset report templates, including account balance reports categorized by institution, transaction detail reports categorized by account type, and reconciliation difference analysis reports; and automatically pushing the multi-dimensional statistical reports to a preset recipient list and storing them in a report history database. Upon reaching the preset reporting period, the method automatically summarizes account information, transaction data, and reconciliation results corresponding to each global account code identifier, avoiding omissions or errors from manual summarization. The generation of multi-dimensional statistical reports meets the needs of differentiated decision-making, and relevant reports are pushed according to roles based on the preset recipient list, avoiding information overload. All generated reports are archived periodically and support retrieval by time, institution, account type, and other conditions, meeting audit and review needs.

[0175] Figure 3 A flowchart illustrating a multi-type account management method provided in another embodiment of this application is shown below. Figure 3 As shown, the multi-type account management method provided in this embodiment includes a specific implementation plan for generating global code identifiers, bookkeeping, and reconciliation. The multi-type account management method provided in this embodiment includes the following steps:

[0176] S301. In response to receiving a user-initiated encoding generation request, establish connections with multiple systems containing different types of accounts.

[0177] S302. Obtain corresponding account information from multiple different systems.

[0178] S303. Extract coding-related information from account information according to preset account coding rules, and generate a global account coding identifier for each account based on the coding-related information.

[0179] S304. In response to receiving transaction data of the target precious metal account, obtain the global account code identifier and transaction type corresponding to the target precious metal account from the transaction data, and determine the corresponding preset accounting rule as a binary accounting rule based on the global account code identifier and transaction type.

[0180] S305. Obtain the unit weight of precious metals from the transaction data.

[0181] S306. Generate physical holding entries and valuation entries based on the unit weight of precious metals.

[0182] S307. Store the physical holding entries and valuation entries together in the preset accounting tables.

[0183] S308. In response to obtaining the initial statement, extract the account identification information from the initial statement and match the corresponding global account code identifier based on the account identification information.

[0184] S309. Determine the corresponding data parser based on the matched global account code identifier.

[0185] S310. Use a data parser to extract transaction elements from the initial statement of account. Transaction elements include transaction time, transaction number, transaction subject, transaction quantity, and transaction object.

[0186] S311. Convert the transaction elements into a standard statement containing a global account code identifier according to the preset field format.

[0187] S312. Perform reconciliation based on standard reconciliation statements and preset accounting tables, and mark each standard reconciliation statement that has completed the reconciliation process.

[0188] S313. In response to being marked as a transaction time difference, the transaction time is extended by the preset transaction duration error value and then re-compared.

[0189] S314. In response to a mark indicating a difference in amount or weight, the corresponding external system interface is invoked to query the original transaction document.

[0190] S315. In response to being marked as having a missing transaction record, a request to complete the transaction is sent to the corresponding external system.

[0191] S316. In response to the elimination of differences after processing, the update flag is marked as passed.

[0192] S317. If a difference still exists after processing, an abnormal alarm is triggered and the difference details are pushed to the preset terminal.

[0193] It should be noted that the execution order of S313-S315 and S316-S317 is not important.

[0194] In this embodiment, the implementation method and technical effect of S301-S317 are similar to those of the corresponding solutions in the above embodiments, and will not be repeated here.

[0195] Figure 4 The structural diagram of the multi-type account management device provided in this application is as follows: Figure 4 As shown, the multi-type account management device 40 provided in this embodiment includes: a generation module 41, a storage module 42, an acquisition module 43, a determination module 44, and a reconciliation module 45.

[0196] The generation module 41 is used to generate a global account code identifier corresponding to each account according to a preset account coding rule and account information in response to receiving multiple different types of account information; the storage module 42 is used to associate and store the global account code identifier and the account information corresponding to each account, wherein the multiple different types of accounts include at least one type of fund account and at least one type of precious metal account; the acquisition module 43 is used to acquire the global account code identifier and transaction type corresponding to the target account from the transaction data in response to receiving the transaction data of the target account; and the determination module 44 is used to determine the global account code identifier and transaction type according to the transaction type. The system includes: determining the corresponding preset accounting rules; generating module 41, which is also used to generate corresponding journal entries based on the preset accounting rules for the target account; storing module 42, which is also used to store the journal entries in a preset accounting table; obtaining module 43, which is also used to obtain the global account code identifier corresponding to the target account from the initial account statement in response to receiving the initial account statement; determining module 44, which is also used to determine the data parser corresponding to the target account based on the global account code identifier, so as to use the corresponding data parser to convert the initial account statement into a standard account statement; and reconciliation module 45, which is used to perform reconciliation processing based on the standard account statement and the preset accounting table.

[0197] The multi-type account management device provided in this embodiment can perform... Figure 2 The implementation principles and technical effects of the methods shown are similar, and will not be repeated here.

[0198] Optionally, the generation module 41, in response to obtaining multiple different types of account information and generating a global account code identifier corresponding to each account according to a preset account coding rule and account information, is specifically used for: in response to receiving a coding generation request initiated by a user, establishing a connection with the systems where multiple different types of accounts reside; obtaining the corresponding account information from multiple different systems; extracting coding-related information from the account information according to the preset account coding rule, and generating a global account code identifier corresponding to each account based on the coding-related information.

[0199] Optionally, the target account is a precious metals account, and the preset accounting rule is a binary accounting rule. When generating corresponding entries according to the preset accounting rule corresponding to the target account, the generation module 41 is specifically used to: obtain the unit weight of precious metals in the transaction data; and generate physical holding entries and valuation entries respectively according to the unit weight of precious metals. When storing the entries in the preset accounting table, the storage module 42 is specifically used to: store the physical holding entries and valuation entries in the preset accounting table respectively.

[0200] Optionally, the acquisition module 43, in response to receiving the initial statement of the target account and obtaining the global account code identifier corresponding to the target account from the initial statement, is specifically used for: extracting account identifier information from the initial statement in response to obtaining the initial statement, and matching the corresponding global account code identifier based on the account identifier information; the determination module 44, in response to determining the data parser corresponding to the target account based on the global account code identifier, and using the corresponding data parser to convert the initial statement into a standard statement, is specifically used for: determining the corresponding data parser based on the matched global account code identifier; using the data parser to extract transaction elements from the initial statement, the transaction elements including transaction time, transaction number, transaction subject, transaction quantity, and transaction object; and converting the transaction elements into a standard statement containing the global account code identifier according to a preset field format.

[0201] Optionally, the multi-type account management device provided in this embodiment further includes a marking module, a comparison module, a calling module, a sending module, and an updating module.

[0202] Accordingly, the marking module is used to mark each standard reconciliation statement that has completed the reconciliation process; the comparison module is used to re-compare the transaction after extending the transaction time by a preset transaction duration error value in response to the marking as a transaction time difference; the calling module is used to call the corresponding external system interface to query the original transaction voucher in response to the marking as an amount or weight difference; the sending module is used to send a supplementary order request to the corresponding external system in response to the marking as a missing transaction record; the updating module is used to update the marking as passed in response to the elimination of the difference after processing; the sending module is also used to trigger an abnormal alarm and push the difference details to the preset terminal in response to the existence of differences after processing.

[0203] Optionally, the update module is also used to automatically update account status information in response to the completion of associated storage or entry generation or reconciliation processing. The account status information includes the current balance, number of positions, recent transaction time and reconciliation status. The determination module 44 is also used to determine whether the account status information triggers a preset warning condition using a real-time monitoring task. The generation module 41 is also used to automatically generate warning information in response to triggering the preset warning condition. The sending module is also used to push the warning to the user according to a preset path.

[0204] Optionally, the multi-type account management provided in this embodiment also includes a summary module.

[0205] Accordingly, the aggregation module is used to automatically aggregate account information, transaction data and reconciliation results corresponding to each global account code identifier in response to the arrival of the preset reporting period; the generation module 41 is also used to generate multi-dimensional statistical reports according to the preset report template, including account balance reports classified by institution, transaction detail reports classified by account type and reconciliation difference analysis reports; the sending module is also used to automatically push the multi-dimensional statistical reports to the preset recipient list; and the storage module 42 is also used to store the multi-dimensional statistical reports in the report history database.

[0206] Figure 5 A structural diagram of the various types of account management devices provided in this application. (For example...) Figure 5 As shown, the multi-type account management device 50 provided in this embodiment includes a processor 51 and a memory 52. ​​The processor 51 and the memory 52 are connected via a bus and communicate with each other.

[0207] In the specific implementation process, the processor 51 executes the computer execution instructions stored in the memory 52, causing the processor 51 to perform the above-described method.

[0208] The specific implementation process of processor 51 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0209] In the above embodiments, it should be understood that the processor 51 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0210] The memory 52 may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0211] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0212] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0213] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0214] The aforementioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0215] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0216] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0217] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0218] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0219] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0220] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0221] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for managing multiple account types, characterized in that, The method includes: In response to obtaining multiple different types of account information, a global account code identifier corresponding to each account is generated according to a preset account coding rule and the account information, and the global account code identifier and the account information corresponding to each account are associated and stored. The multiple different types of accounts include at least one type of fund account and at least one type of precious metal account. In response to receiving transaction data of the target account, the system obtains the global account code identifier and transaction type corresponding to the target account from the transaction data, and determines the corresponding preset accounting rules based on the global account code identifier and transaction type. The corresponding journal entries are generated according to the preset accounting rules for the target account and stored in the preset accounting table. In response to receiving an initial statement for a target account, the system obtains a global account code identifier corresponding to the target account from the initial statement and determines a data parser corresponding to the target account based on the global account code identifier, so as to convert the initial statement into a standard statement using the corresponding data parser. Reconciliation is performed based on the standard statement and the preset accounting table.

2. The method according to claim 1, characterized in that, In response to receiving multiple different types of account information, the process generates a global account code identifier corresponding to each account based on a preset account coding rule and the account information, including: In response to receiving a user-initiated encoding generation request, it establishes connections with multiple systems containing accounts of different types; Retrieve corresponding account information from multiple different systems; According to the preset account coding rules, the coding-related information is extracted from the account information, and a global account coding identifier corresponding to each account is generated based on the coding-related information.

3. The method according to claim 1, characterized in that, The target account is a precious metals account, the preset accounting rule is a binary accounting rule, and the step of generating corresponding journal entries according to the preset accounting rule for the target account and storing them in a preset accounting table includes: Obtain the unit weight of precious metals from the transaction data; Generate physical holding entries and valuation entries based on the unit weight of the precious metals; The physical holding entries and valuation entries are stored together in a pre-defined accounting table.

4. The method according to claim 1, characterized in that, In response to receiving an initial statement for the target account, the method of obtaining a global account code identifier corresponding to the target account from the initial statement, and determining a data parser corresponding to the target account based on the global account code identifier, so as to convert the initial statement into a standard statement using the corresponding data parser, includes: In response to obtaining the initial statement, the account identification information is extracted from the initial statement, and the corresponding global account code identifier is matched based on the account identification information; The corresponding data parser is determined based on the matched global account code identifier; The data parser is used to extract transaction elements from the initial statement, including transaction time, transaction number, transaction subject, transaction quantity, and transaction object. The transaction elements are converted into a standard statement containing a global account code identifier according to a preset field format.

5. The method according to claim 1, characterized in that, The method further includes: Mark each completed standard reconciliation statement; In response to a transaction time discrepancy, the transaction time is extended by a preset transaction duration error value and the comparison is repeated. In response to a difference marked as an amount or weight, the corresponding external system interface is invoked to query the original transaction voucher; In response to a transaction being marked as missing, a request to complete the transaction is sent to the corresponding external system. In response to the elimination of differences after processing, the flag is updated to pass; If a difference still exists after processing, an anomaly alarm is triggered and the difference details are pushed to the preset terminal.

6. The method according to claim 1, characterized in that, The method further includes: In response to the completion of associated storage, entry generation, or reconciliation processing, the account status information is automatically updated, including the current balance, number of holdings, recent transaction time, and reconciliation status. Real-time monitoring is used to determine whether the account status information triggers preset warning conditions; In response to triggering preset warning conditions, the system automatically generates warning information and pushes it to the user via a preset path.

7. The method according to claim 1, characterized in that, The method further includes: In response to the arrival of the preset reporting period, it automatically summarizes the account information, transaction data and reconciliation results corresponding to each global account code identifier; Multi-dimensional statistical reports are generated based on preset report templates. These multi-dimensional statistical reports include account balance reports categorized by institution, transaction detail reports categorized by account type, and reconciliation discrepancy analysis reports. The multi-dimensional statistical reports are automatically pushed to a preset list of recipients and stored in the report history database.

8. A multi-type account management device, characterized in that, include: The generation module is used to generate a global account code identifier corresponding to each account in response to obtaining multiple different types of account information, based on a preset account coding rule and the account information; The storage module is used to associate and store the global account code identifier and the account information corresponding to each account, wherein the multiple different types of accounts include at least one type of fund account and at least one type of precious metal account; The acquisition module is used to, in response to receiving transaction data of the target account, acquire the global account code identifier and transaction type corresponding to the target account from the transaction data; The determination module is used to determine the corresponding preset accounting rules based on the global account code identifier and the transaction type; The generation module is also used to generate corresponding journal entries according to the preset accounting rules corresponding to the target account; The storage module is also used to associate and store entries in a preset accounting table; The acquisition module is further configured to, in response to receiving an initial statement of the target account, acquire the global account code identifier corresponding to the target account from the initial statement of the target account; The determining module is further configured to determine the data parser corresponding to the target account based on the global account code identifier, so as to use the corresponding data parser to convert the initial statement into a standard statement; The reconciliation module is used to perform reconciliation processing based on the standard reconciliation statement and the preset accounting table.

9. A multi-type account management device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

11. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method according to any one of claims 1-7.

Images