A kind of data management method, system, computer device and storage medium of remittance

Abstract

The application discloses a kind of data management methods, systems, computer equipment and storage medium of current account, the method can when client triggers new collection, obtain new item data, and set associated data based on new item data.Recreate business node according to the business data in associated data, and generate business approval information according to business node.Again, through the second client, business approval is carried out, and the first approval result data of feedback is checked to transaction information, so that new item data is stored.The method can make multiple clients operate on the same platform through unified standardized components, and when the client triggers new collection, automatically match multi-dimensional standardized associated data according to new item data, ensure the consistency and real-time update of current account related information.And, automatically execute business process according to the business data in associated data, improve the management efficiency of current account data.

Description

Technical Field

[0001] The present application relates to the field of financial technology, and in particular to a method, system, computer equipment and storage medium for managing accounts receivable and payable data. Background Art

[0002] Receivables data is generated in financial technology fields such as leasing. Managing receivables data encompasses various business items, including payment management, collection and payment process management, and audit and archiving. These items are often distributed across different business lines and divisions, depending on specific business locations. This requires additional development work for each new receivables item.

[0003] Due to the development cycle required, the management responsiveness and flexibility of accounts receivable data were limited. This made it difficult to quickly respond to new business needs. This was especially true when it came to offline collection and reconciliation. Since newly added collection items could not be promptly synchronized to relevant business departments, the efficiency of accounts receivable management was reduced, impacting the operational efficiency of the entire financial system and the accuracy of financial management. Summary of the Invention

[0004] In view of this, embodiments of the present application provide a method, system, computer device, and storage medium for managing accounts receivable data to quickly synchronize the management status of accounts receivable data and improve the management efficiency of accounts receivable data.

[0005] According to one aspect of the present application, a method for managing receivables data is provided, the method comprising:

[0006] Acquiring newly added payment data, the newly added payment data including data specified by the first client and / or data generated by the first client when executing a transaction; the first client establishing a communication connection with the server via a unified standardized interface;

[0007] Setting associated data based on the newly added payment data, wherein the associated data includes business data and verification data, and the verification data is key information extracted from the newly added payment data;

[0008] Creating a business node according to the business data in the associated data, and generating business approval information according to the business node;

[0009] Sending the business approval information to a second client, and receiving first approval result data fed back by the second client in response to the business approval information, where the second client is a client associated with the business node; the second client establishes a communication connection with the server through a unified standardized interface;

[0010] If the first approval result data includes a first conclusion identifier, obtaining transaction information of the transaction business, performing verification on the transaction information based on the verification data, and storing the newly added payment data as current payment data according to the verification result;

[0011] If the first approval result data includes a second conclusion identifier, a resubmission message is sent to the first client.

[0012] According to another aspect of the present application, a current account data management system is provided, comprising: a server and at least one first client and at least one second client communicating with the server via a unified standardized interface; the server comprising:

[0013] an acquisition module, configured to acquire newly added payment data, wherein the newly added payment data includes data specified by the first client and / or data generated by the first client when executing a transaction;

[0014] an association setting module, configured to set association data based on the newly added payment data, wherein the association data includes business data and verification data, and the verification data is key information extracted from the newly added payment data;

[0015] A node creation module, configured to create a business node according to the business data in the associated data, and generate business approval information according to the business node;

[0016] an approval request module, configured to send the business approval information to a second client, and receive first approval result data fed back by the second client in response to the business approval information, wherein the second client is a client associated with the business node; and the second client establishes a communication connection with the server via a unified standardized interface;

[0017] a verification module, configured to obtain a transaction amount of the transaction business when the first approval result data includes a first conclusion identifier, verify the transaction amount based on the turnover amount, and store the newly added payment data according to the verification result;

[0018] A feedback module is configured to send resubmission information to the first client when the first approval result data includes a second conclusion identifier.

[0019] According to another aspect of the present application, a computer device is provided, comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor implements the above-mentioned method for managing accounts receivable data when executing the computer program.

[0020] According to another aspect of the present application, a storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the above-mentioned account data management method is implemented.

[0021] By means of the above technical solution, embodiments of the present application provide a method, system, computer device, and storage medium for managing accounts receivable data. The method can obtain newly added payment data when a client triggers a new payment, and set associated data based on the newly added payment data. The associated data includes business data and verification data. A business node is then created based on the business data in the associated data, and business approval information is generated based on the business node. The business approval information is automatically sent to a second client, and first approval result data feedback from the second client regarding the business approval information is received. If the first approval result data includes a first conclusion identifier, transaction information for the transaction business is obtained, the transaction information is verified based on the verification data, and based on the verification result, the newly added payment data is stored as accounts receivable data. If the first approval result data includes a second conclusion identifier, a resubmission message is sent to the first client. The method enables multiple clients to perform operations on the same platform through unified and standardized components. When a client triggers a new payment, the method automatically matches the multi-dimensional standardized associated data based on the newly added payment data, ensuring consistency and real-time updates of accounts receivable related information. In addition, business processes are automatically executed based on the business data in the associated data to complete operations such as creating, searching, collecting, verifying transactions, and storing accounts receivable items, thereby improving the management efficiency of accounts receivable data.

[0022] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0024] Figure 1 An application scenario diagram of a method for managing receivables and payables data provided by an embodiment of the present application is shown;

[0025] Figure 2 A flow chart of a method for managing receivables and payables data provided in an embodiment of the present application is shown;

[0026] Figure 3 A schematic diagram of the flow relationship of current account data provided by an embodiment of the present application is shown;

[0027] Figure 4 A schematic diagram of the flow chart for verifying the amount of cash flow provided in an embodiment of the present application is shown;

[0028] Figure 5 A schematic diagram of the refund application data management process provided in an embodiment of the present application is shown;

[0029] Figure 6 A schematic diagram of the refund approval process provided in an embodiment of the present application is shown;

[0030] Figure 7 A schematic diagram of a process for updating a status tag according to an embodiment of the present application is shown;

[0031] Figure 8 The following is a structural diagram of a current account data management system provided by an embodiment of the present application;

[0032] Figure 9 A schematic diagram of the computer device structure provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

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

[0034] Before describing the specific implementation of this application, some concepts involved in the specific implementation are first described.

[0035] The accounts receivable data described in the embodiments of the present application generally refers to various payment records stored in the financial management system, including but not limited to: accounts receivable, accounts payable, advances received, prepaid accounts, special payments and receipts, bills, contracts, agreements, etc.

[0036] The newly added payment data described in the embodiments of this application refers to payment data triggered by a client input and stored in a data management system for unified management. The newly added payment data can be created and input through the creation interface of the current account data management system. After being configured and processed by the current account data management system, it is stored in the current account data management system. In some embodiments, the newly added payment data, once stored, may also be referred to as current account data.

[0037] The current account data management system described in the embodiment of the present application refers to a combination of hardware devices and software applications for providing an operating environment for the current account data management method. Figure 1 In the context of FinTech applications shown in the figure. Figure 1The application scenario shown, combined with the current account data management method, can form a current account data management system. Depending on specific business needs, the current account data management system can be given different system names, including but not limited to financial system, transaction system, leasing system, accounting system, audit system, etc.

[0038] The current account data management system may include a server and multiple clients. The server may be deployed in the cloud and configured to receive, send, manage, and maintain current account data. The multiple clients may establish communication connections with the server to receive and send current account data, as well as generate and display specific user interfaces based on the current account data for user interaction.

[0039] To meet the business requirements of a current account data management system, servers and clients must possess data communication and processing capabilities. Therefore, each server and client is equipped with functional components to implement these capabilities. For example, a server may include a processor and a communication module. The processor can manage and maintain current account data by running applications related to current account data management methods. The communication module is configured to connect to clients and establish communication channels with multiple clients to receive and send current account data.

[0040] Similarly, the client can also include a controller and a communicator. The controller processes the receivables data by running an application program related to the receivables data management method, thereby presenting the receivables data based on the processing results. The communicator is configured to connect to the server and establish a communication channel with the server to receive and send receivables data.

[0041] The multiple clients that establish communication connections with the server can be categorized into different types based on specific business needs. For example, the leasing business encompasses departments involved in managing accounts receivable data, including operations, product, business, assets, marketing, and finance. These departments, depending on their responsibilities, participate in different stages of accounts receivable data management. For example, when the product department executes a product transaction, it generates transaction data related to goods and payments. This transaction data is uploaded to the accounts receivable data management system and is referred to as newly added payment data. The finance department is required to review and approve this newly added payment data.

[0042] Since different business departments participate in different business stages in the process of current account data management, different types of clients are required for different business departments to perform data management work in the corresponding business stages. In some embodiments, multiple clients can be divided into a first client and a second client. Among them, the first client is used to trigger current account management business, such as adding new receipts, initiating refund applications, etc. The second client is used to perform approval business, such as approving new receipts and refund applications. For example, operations, products, business, assets, marketing and other departments initiate new receipts through the first client, and finance and other departments approve the new receipts through the second client.

[0043] It should be noted that the terms "first client" and "second client" merely distinguish the client's role in the current account data management process and do not define the client itself or the specific functions it can perform. Some clients can function as both the first client and the second client, provided that hardware requirements are met. When managing current account data, a client can perform the functions of the first client or the second client by running different types of current account data management applications or logging in with different user permissions.

[0044] In order to improve the consistency and synchronization of payment data, the first client and the second client can establish a communication connection with the server through a unified standardized interface. The unified standardized interface is a communication interface developed based on network connection requirements and specific communication transmission protocols. For example, the unified standardized interface can be one or more combinations of interfaces such as RESTful API, OpenAPISpecification, GraphQL, gRPC, WebSocket, Server-Sent Events (SSE), JMS API, etc. In some embodiments, a specific unified standardized interface can also be customized based on the security and communication methods of the specific business scenario to achieve a communication connection between the server and the client.

[0045] A unified, standardized interface makes communication between clients and servers more efficient, secure, and maintainable through standardized methods. Furthermore, this unified, standardized interface enables clients from multiple business departments scattered across different regions to perform business operations on the same server-provided management platform, improving the consistency and real-time update performance of business information.

[0046] In some embodiments, the client may further include an output component for presenting receivables data, including but not limited to a display, a speaker, a buzzer, a vibration motor, an indicator light, etc. The client may use the output component to display a user interface for managing receivables data. The user interface may be presented via a dedicated financial management application or a specific web page.

[0047] For example, when the user interface is presented via a dedicated financial management application, the client may also include memory for storing the application files of the financial management application. During transactions or financial management, the user can use application launch commands to control the client's controller to run the financial management application. Once running, the financial management application can invoke the communicator to establish a communication connection with the server and receive or send receivables data as needed.

[0048] For another example, when the user interface is presented via a webpage, the user can control the client to run a browser application and enter the address of the current account management webpage in the browser application, thereby controlling the client to access the current account management platform webpage. During the webpage access process, the server will send the webpage content data and current account data to the client based on the webpage content. After receiving the webpage content data and current account data, the client can use the browser application to render the webpage, presenting the user interface related to current account data management.

[0049] It should be noted that the display method of the above-mentioned user interface related to accounts receivable data management is only an example and does not limit the specific presentation method. In actual applications, both the client and the server can receive, send and process accounts receivable data through dedicated applications, network applications, mini-programs, multi-application collaboration, etc. according to specific hardware conditions and user needs.

[0050] Based on this, the client in the embodiments of the present application can be one or more combinations of personal computers, mobile terminals, smart home devices, smart wearable devices, vehicle information systems, workstations, industrial control terminals, virtual reality devices, augmented reality devices and other devices.

[0051] The current account data management method provided in the embodiments of the present application can be applied to a server. Specifically, after a client establishes a communication connection with the server, the server can execute the current account data management method to build a current account data management platform. The client can then access the current account data management platform by executing a management application or accessing a specific network address, thereby participating in the current account data management service.

[0052] Based on the server described in the above embodiment, a method for managing receivables data is provided in this embodiment, such as Figure 2 As shown, the method includes:

[0053] S101. Acquire new payment data.

[0054] The newly added payment data may be data specified via the first client. Specifically, in some embodiments, users in departments such as operations, product, business, assets, and marketing can run a receivables data management application on a terminal device such as a personal computer. They can then log in to the user information authorized for their department through the management application, allowing the terminal device to access the business functions of the first client. After running the application and logging in the user information, the first client can present a user interface for managing receivables data.

[0055] The user interface may include multiple business-related functional options, such as the name, type, approval authority, and number of a newly added receivable. Users can add a new receivable by specifying specific values ​​for the corresponding functional options in the user interface and clicking Submit or other confirmation functions. As the new receivable is entered, the first client generates new payment data based on the specific values ​​specified by the user. After generating the new payment data, the first client transmits the new payment data to the server via a data transmission channel with the server, so that the server can obtain the new payment data.

[0056] In other embodiments, the newly added payment data may also be data generated by the first client when executing a transaction. The newly added payment data may also be automatically generated based on the user's transaction behavior by reading the data generated during the transaction process. For example, when the first client displays a QR code for receiving payment, the current payment data management application may monitor the scanned status of the QR code. When the QR code is detected to be scanned, the payment user information of the currently logged-in user and the payment user information of the user who scanned the QR code may be obtained respectively. The name, type, approval authority and other information may be matched based on the business department, function, management authority and other information to which the payment user information belongs. The corresponding business number is assigned to the payment business through automatic numbering, thereby generating newly added payment data. Similarly, after generating the newly added payment data, the first client may send the newly added payment data to the server through a data transmission channel with the server, so that the server can obtain the newly added payment data.

[0057] When the newly added payment data is data generated by the first client when executing a transaction business, the first client can read transaction business-related files when executing the transaction business, and extract multi-dimensional information of the newly added payment data from the relevant files based on data screening and processing functions.

[0058] That is, in a feasible implementation, the first client can obtain the transaction business file in response to the initiation instruction of the transaction business. And extract the original text information from the transaction business file. Then, based on the text information preprocessing algorithm, preprocess the original text information. Among them, the preprocessing can convert the natural language text into structured text, including text cleaning, word segmentation (Tokenization), stop word removal (Stop Words Removal), stemming (Stemming), lemmatization (Lemmatization), part-of-speech tagging (Part-of-Speech Tagging), named entity recognition (Named Entity Recognition, NER), removal or replacement of sensitive words, text normalization, synonym replacement, text deduplication, text encoding, serialization processing, etc. After obtaining the structured text through preprocessing, the first client can perform semantic analysis through a pre-trained semantic processing model. The semantic processing model is a model used to understand and generate natural language text in natural language processing (NLP). The semantic processing model can output corresponding classification labels based on the input structured text information. Each classification label can correspond to a dimension of new payment data. By setting different classification labels, multiple dimensions of new payment data can be automatically identified, and new payment data with multiple dimensions of information can be obtained.

[0059] In one feasible implementation, the newly added payment data can also be generated by the server based on the first client's transaction. Specifically, the first client can send transaction-related information or files to the server. The server then extracts the original text from the transaction files. Using a text preprocessing algorithm, the server preprocesses the original text and outputs classification labels corresponding to multiple dimensions of the newly added payment data based on a semantic processing model. This automatically identifies the multiple dimensions of the newly added payment data, thereby obtaining newly added payment data with multiple dimensions.

[0060] It should be noted that the specific content of the newly added payment data can be actively input by the user, that is, the newly added payment data includes data specified by the first client. The newly added payment data can also be automatically generated by identifying and analyzing business data related to the transaction behavior, that is, the newly added payment data includes data generated by the first client when executing the transaction. The newly added payment data can also be partially actively input by the user and partially automatically generated by identifying and analyzing business data, that is, the newly added payment data includes data specified by the first client and data generated by the first client when executing the transaction.

[0061] S102: Setting associated data based on the newly added payment data.

[0062] like Figure 3 As shown, after obtaining the newly added payment data, the server can perform business process matching and association settings based on the newly added payment data. That is, through data matching, the server can obtain the associated data associated with the newly added payment data. The associated data includes business data. Business data refers to data that is associated with specific transaction businesses corresponding to the newly added payment data. Business data can be used to determine the specific business processes subsequently triggered by the newly added payment. For example, business data may include whether approval is required, the required approval authority, the specific approval node, whether verification is required, the specific verification content, and so on.

[0063] After receiving the newly added payment data, the server can match the business data based on the multi-dimensional information contained in the newly added payment data, based on the business process trigger rules pre-set by the current account data management platform. The pre-set business process trigger rules are used to set matching strategies for different dimensions of information. Matching strategies can be set based on a combination of information types, information values, and other factors.

[0064] For example, the newly added payment data obtained by the server may include "Payment Type: Service Fee, Payment Amount: 2000, Department Information: Business Department." During the business data matching process, the pre-set business process trigger rules can match the service fee to the service fee business process. The payment amount of 2000 can be matched to a low-amount range, and the approval process for low amounts can be determined as General Approval, with approval authority: General Clerk Approval. The business department can then be matched to the information synchronization node in the business process, thereby obtaining business data. The business data includes the business process: Service Fee, the approval process: General Approval, the approval authority: General Clerk, and the information synchronization node: Business Department.

[0065] The associated data may also include verification data, which is key information extracted from the newly added payment data. In some embodiments, the verification data may include transaction data, which is automatically generated based on the newly added payment data and used to subsequently verify the transaction amount. Therefore, the transaction amount in the transaction data is equal to the amount in the newly added payment data. For example, if the acquired newly added payment data includes "Service fee, 2000", the server may automatically set an associated transaction data with an amount of 2000 for subsequent verification of the transaction amount.

[0066] In order to set the associated data, the server can perform data matching through the multi-dimensional information in the newly added payment data. During the matching process, each dimensional information can be preset with a project label, so that the server can perform data matching based on the project label. When the newly added payment data is input through the option control in the user interface provided by the accounts receivable data management system, a standardized project label can be directly specified. However, since business data is mostly natural language text content, the newly added payment data generated by the business data cannot directly obtain the project label converted from the table, which may affect the accuracy of the matching results. Therefore, in order to set the associated data based on the newly added payment data, the server can extract the first project label and the second project label from the newly added payment data. Among them, the first project label is the project label specified by the first client. The second label is the project label corresponding to the business data, and the business data is the data generated when the first client performs the transaction business.

[0067] After extracting the first and second project tags, the server may standardize the second project tag to generate a third project tag. The third project tag is a project tag in a preset project tag library that is synonymous with the second project tag. The server may have a pre-set project tag library that stores standardized project tags and associations between standardized project tags and non-standardized project tags. After obtaining the second project tag, the server may perform a match in the project tag library based on the second project tag. If a match is found for any standardized project tag, a project tag synonymous with the second project tag, i.e., the third project tag, may be obtained.

[0068] The associated data is then matched based on the first and third item tags. For example, the server reads the contract text during a transaction and finds "Prepaid AA Project Payment," a keyword representing the payment type, i.e., the second item tag. However, since "Prepaid AA Project Payment" is not a standardized item tag, the server needs to match the second item tag with a synonymous standardized item tag in the preset item tag library, thereby obtaining the third item tag "Prepayment." Associated data is then set based on the third item tag "Prepayment," thereby mitigating the impact of the randomness of natural language text on the associated data setting process and improving the accuracy of the associated data setting process.

[0069] To ensure traceability of the payment collection process, in one feasible implementation, the server can also obtain identification information for the newly added payment data. This identification information includes at least one of a transaction serial number, a user ID, and the first client's identification number. A traceability identifier is generated based on this identification information, the first item tag, and the third item tag, and then added to the newly added payment data, ensuring traceability.

[0070] The traceability identifier can be a combination of one or more characters, numbers, or barcodes, used to identify each payment data item. The server can assign a unique index to each payment data item by setting the traceability identifier. During subsequent payment data management, the server can use the traceability identifier, or a portion of the characters within the traceability identifier, to locate the specific payment item, thereby performing data management tasks related to the payment data.

[0071] S103: Create a business node according to the business data in the associated data, and generate business approval information according to the business node.

[0072] After setting up linked data, the server can automatically generate appropriate business processes based on the business data in the linked data and create business nodes based on the business processes. A business node refers to the person, department, or client directly involved in a specific business within the business process. In the server, a business node can be represented by a person ID, department ID, or client ID. For example, based on business data such as "Business Process: Service Fee, Approval Process: General Approval, Approval Authority: General Clerk, Information Synchronization Node: Business Department," the business nodes can be determined as follows: Business Personnel: YW0010, Approval Personnel: SP PT0001, and Information Synchronization Personnel: YW0001 to YW0010.

[0073] After creating a business node, the server can generate business-related information based on the business node. This business-related information is used to present the business-related user interface on the client corresponding to the business node, so that the corresponding client can perform the corresponding business process operations. Since business personnel and information synchronization personnel do not participate in specific business approvals, in some embodiments, the server can also generate business approval information only for business nodes determined to participate in the approval, that is, generate business approval information for the approval personnel, approval department, and approval client. Based on this, the generated approval-related information is called business approval information, and the business approval information can be used to present the approval-related user interface on the second client.

[0074] S104: Send the service approval information to the second client, and receive first approval result data fed back by the second client in response to the service approval information.

[0075] After determining the business node, the server can obtain second client identification information corresponding to the business node based on the determined business node. After generating the business approval information, the server can send the business approval information to the second client corresponding to the business node according to the second client identification information.

[0076] After receiving the business approval information, the second client can generate an approval-related user interface based on the business approval information. For example, the approval-related user interface can include key information related to the new fund data, such as fund type, fund amount, department, and the like. In order to perform the approval work, the approval-related user interface can also include approval function controls, such as an agree control, a reject control, and the like. Through the interactive operation on the second client, the second client can feed back approval result data for the business approval information to the server.

[0077] The second client can feed back different types of approval result data to the server for different stages of the business process. For ease of description, the approval result data fed back in the new fund stage is referred to as first approval result data, and the approval result data fed back in the refund and other fund stages is referred to as second approval result data.

[0078] According to different operation contents performed on the user interface in the approval process, the approval result data can include different conclusion identifiers, i.e., a first conclusion identifier and a second conclusion identifier, wherein the first conclusion identifier is used to represent that the approval is passed, and the second conclusion identifier is used to represent that the approval is not passed. For example, after the approver clicks the agree control on the approval interface provided by the second client, the second client can be controlled to feed back the approval result data containing the first conclusion identifier to the server. Similarly, after the approver clicks the reject control on the approval interface provided by the second client, the second client can be controlled to feed back the approval result data containing the second conclusion identifier to the server.

[0079] The first conclusion identifier and the second conclusion identifier can be represented by a string of specific values, such as an “Approval result” field in the approval result data fed back by the second client to the server. By setting the specific value of the field, the approval result can be represented. The first conclusion identifier can be set to 01, and when “Approval result = 01”, it represents that the approval is passed. Similarly, the second conclusion identifier can be set to 00, and when “Approval result = 00”, it represents that the approval is not passed.

[0080] It should be noted that when different services are audited, the approval result can not be limited to two kinds of approval pass and approval fail, but can also include results such as suggestion for modification, re-audit pass after modification, approval pass but with modification, etc. Therefore, the approval result data fed back by the second client to the server can also include other types of conclusion identifiers. For example, a third conclusion identifier representing a suggestion for modification, a fourth conclusion identifier representing a re-audit pass after modification, a fifth conclusion identifier representing an approval pass but with modification, etc. Similarly, the third conclusion identifier, the fourth conclusion identifier, and the fifth conclusion identifier can also be represented by specific numerical values, which will not be listed one by one here.

[0081] S105, if the first approval result data includes the first conclusion identifier, obtaining transaction information of the transaction service, and performing verification on the transaction information based on the verification data, and storing the new fund data as the current fund data according to the verification result.

[0082] After obtaining the first approval result data fed back by the second client, the server can read the first approval result data to determine the approval result of the current service by the second client. If the first conclusion identifier is read in the first approval result data, that is, the approval pass, the server can obtain the transaction amount of the transaction service, and perform verification on the transaction information according to the verification data set in the association data.

[0083] In the process of performing verification, the server can compare the verification data and the transaction information. When the verification data and the transaction information satisfy a preset relationship, a verification pass verification result is generated; when the verification data and the transaction information do not satisfy the preset relationship, a verification fail verification result is generated. The preset relationship can be a numerical value comparison, an information consistency comparison, etc. For example, when the new fund data is obtained, the fund type read from the new fund data is "service fee", and when the transaction service is performed, the fund type also needs to be read from the transaction information generated by the transaction service. If the read fund type is also "service fee", a verification pass verification result can be generated.

[0084] In a feasible implementation, the transaction information can include a transaction amount, and the verification data includes flow data. After the approval pass, the server can verify the transaction information by comparing the transaction amount and the flow amount in the flow data. That is, as shown in Figure 4 The server can read the transaction amount from the transaction information (S1601), and extract the flow amount from the verification data (S1602). If the transaction amount is greater than or equal to the flow amount, a verification pass verification result can be generated, a transaction voucher can be generated (S1603), and the new fund data and the transaction voucher can be stored (S1604).

[0085] Similarly, if the transaction amount is less than the flow amount, a check result of failure can be generated, and a first prompt information can be generated (S1605). The first prompt information can include the check result of the transaction amount and the flow amount, and is used to notify the corresponding client. Therefore, the first prompt information can be "the current transaction amount does not meet the flow amount requirement, please pay attention to check", and the like. The server further sends the first prompt information to the first client and the second client (S1606), so as to notify the corresponding client to perform the transaction business processing which does not meet the requirement.

[0086] In another possible implementation, the associated data further includes contract data associated with the new payment data, and if the first approval result data includes a first conclusion identifier, the server can further extract transaction data related to the contract from the transaction information. The transaction data is data generated by the first client when performing the transaction business.

[0087] If the contract data is consistent with the transaction data based on the contract data, a check result of passing is generated, and the new payment data is stored. If the contract data is inconsistent with the transaction data, a second prompt information is generated. Similarly, the second prompt information can also include the check result of inconsistency prompt content, and can include specific inconsistent item content. For example, "the current payee is inconsistent with the contract payee, please check", and the like. The server further sends the second prompt information to the first client and the second client (S1606), so as to notify the corresponding client to perform the transaction business processing which is inconsistent with the contract content.

[0088] S105, if the first approval result data includes a second conclusion identifier, a resubmit information is sent to the first client.

[0089] After obtaining the first approval result, if the server reads a second conclusion identifier in the first approval result, it indicates that the current new payment business does not pass the approval, and therefore the server can send a resubmit information to the first client, which is used to prompt the first client to modify and resubmit the new payment data.

[0090] In order to obtain the prompt effect and improve the efficiency of the current account data management, in a possible implementation, the second client can mark the unpassed approval items in the approval process, and add the marked approval items in the first approval result to feed back to the server. The server can generate a resubmit information according to the first approval result, and the resubmit information includes the marked content which does not pass the approval, so that after the server sends the resubmit information to the first client, the first client can display the marked content, so as to resubmit the new payment data according to the marked content.

[0091] As can be seen, in the above embodiment, by executing the corresponding steps of the current account data management method, the server can utilize standardized components to enable various business departments to perform operations on the same platform, thereby ensuring information consistency and real-time updates. Furthermore, the server can synchronize data with the clients or financial management systems of other business departments in a timely manner, ensuring that all departments have access to accurate and consistent information, streamlining the information flow process, eliminating duplication of work, and saving time and resources.

[0092] Furthermore, by implementing the accounts receivable management method, the server can be equipped with intelligent, configurable management capabilities for newly added funds. When faced with ever-changing business needs, there's no need for continuous iterative development. With a single-click configuration, businesses like collections, refunds, cash flow sorting, and collection approvals can be brought online, reducing human intervention and improving work efficiency. At the same time, the management platform built on the server can automatically connect to the financial system, push relevant business data, and reduce the possibility of manual errors, thereby resolving business and financial discrepancies. Furthermore, by implementing the accounts receivable management method, the server can not only resolve a large number of daily work issues in a short period of time, but also reduce the amount of human intervention required, further saving human resource costs.

[0093] Furthermore, as a refinement and expansion of the specific implementation of the above embodiment, in order to fully illustrate the specific implementation process of this embodiment, this application provides another method for managing receivables data, such as Figure 5 As shown, the method includes:

[0094] S201. Obtain refund application data.

[0095] The refund application data is data generated by the first client when executing a refund operation. The first client can perform a refund operation based on a user interface provided by the current account data management platform. For example, a refund control can be provided for certain accounts in the user interface. By clicking the refund control, the user instructs the first client to generate refund application data. Since the refund application is initiated for a specific account, the corresponding account information can be included in the refund application data. After generating the refund application data, the first client can send the refund application data to the server.

[0096] S202: Create a refund node according to the refund application data, and generate refund approval information according to the refund node.

[0097] After obtaining the refund application data, the server can read the content of the refund application data to obtain the amount involved in the refund application data and the relevant information of the amount, and then create a refund node based on the refund application data. For some amounts, since the business stages, permissions, and other contents involved are consistent, the refund node can be created directly through the previous business node. That is, in a feasible implementation, when creating a refund node based on the refund application data, the server can read the amount information or traceability identifier involved in the refund application data, and search for the corresponding associated data based on the amount information or traceability identifier, and determine the business process and business node based on the associated data, thereby determining the refund node based on the business node.

[0098] After creating the refund node, the server can generate refund approval information based on the refund node. The refund approval information can be used to present a refund approval user interface on the second client. Therefore, the refund approval information can include information such as the amount associated with the refund application, the initiator information, and the refund method.

[0099] S203: Send the refund approval information to the second client, and receive second approval result data fed back by the second client regarding the refund node information.

[0100] After determining the refund node, the server can send refund approval information based on the determined refund node to the second client corresponding to the refund node. After receiving the refund approval information, the second client can generate an approval-related user interface based on the refund approval information. Similarly, the refund approval user interface can also include payment-related information and functional controls for executing the approval process. Through interactive operations on the second client, the second client can provide feedback to the server regarding the approval result data for the refund approval information. To distinguish it from the approval result data for the new payment stage, the approval result data generated for the refund transaction is referred to as the second approval result.

[0101] S204: Execute a refund service according to the second approval result data.

[0102] After obtaining the second approval result data fed back by the second client, the server can execute the refund service according to the second approval result data. Figure 6 As shown, in one feasible embodiment, the server may first read a conclusion identifier from the second approval result. The conclusion identifier may be a first conclusion identifier indicating approval or a second conclusion identifier indicating rejection. If the second approval result includes the first conclusion identifier, indicating that the current refund application has been approved, a refund service execution instruction may be sent to the second client, causing the second client to initiate a payment request to the first client.

[0103] If the second approval result includes a second conclusion indicator, indicating that the current refund application has been rejected, a refund receipt may be sent to the first client to prompt the first client to reapply for a refund. To achieve a more effective reminder, the refund receipt may include information indicating the reason for the refund rejection, such as items that do not meet the refund requirements.

[0104] S205: Update the newly added payment data associated with the refund application data according to the execution result of the refund service.

[0105] Because a refund operation modifies previously stored payment data, the server can update the newly added payment data associated with the refund application data based on the refund service's execution result. The refund service's execution result can be monitored based on the refund amount, refund method, and refund status of the specific refund service, resulting in different execution results. For example, the execution result could be a refund payment failure, a full refund success, or a partial refund success. Based on these different execution results, the stored receivables data can be updated.

[0106] It can be seen that in the above embodiment, after receiving the refund application, the server can automatically create a refund business node by matching the associated data of the corresponding amount of the refund business, and send the refund approval information to the second client of the refund business node to trigger the approval process. There is no need for the first client to specify the approval node, which reduces human intervention and improves the execution efficiency of the refund approval business.

[0107] In a feasible implementation, the server can also set and update the business status of the current account data according to the execution progress of each business stage. Figure 7 As shown in the figure, after obtaining the newly added payment data, the server creates a status tag and sets the current business status value of the status tag to Pending Association. It also starts a business progress monitoring process to monitor the execution progress of each business stage. When the setup association data is monitored, the status tag is updated to Pending Approval.

[0108] Similarly, through the business progress monitoring process, whether the approval is submitted is monitored. When the business approval information is monitored to be sent to the second client, the status label can be updated to the pending approval state. The execution of the approval business is monitored through the business progress monitoring process. When the first approval result data is monitored to include the second conclusion identifier, since the approval is not passed, the status label can be updated to be modified to the pending approval state. When the first approval result data is monitored to include the first conclusion identifier, the verification result can continue to be monitored. If the verification passes, the status label will be updated to the payment confirmed state. The storage module of the server executes data storage according to the status label, that is, when the status label is the payment confirmed state, a payment voucher is generated and the newly added payment data is stored.

[0109] For refund services, the progress of each stage of the refund process can also be monitored through a business monitoring process. When refund application data is monitored, a status tag can be created and set to pending approval. If the business monitoring process detects that the second approval result data includes a second conclusion identifier, the status tag can be updated to approval rejected. If the business monitoring process detects that the second approval result data includes a first conclusion identifier, the status tag is updated to refund payment in progress. The payment result is also monitored and the status tag is updated accordingly. Specifically, if the payment result is failed, the status tag is updated to refund payment failed. If the payment result is fully successful, the status tag is updated to full refund successful. If the payment result is partially successful, the status tag is updated to partial refund successful. The server's storage module can perform data storage based on the status tag. Specifically, when the status tag indicates full refund successful or partial refund successful, a payment voucher is generated and the stored accounts receivable data is updated.

[0110] Furthermore, as a specific implementation of the current account data management method, the present application embodiment also provides a current account data management system, such as Figure 8 As shown, the accounts receivable data management system includes: a server and at least one first client and at least one second client that establish communication connections with the server through a unified standardized interface.

[0111] The server includes: an acquisition module, an association setting module, a node creation module, an approval request module, a verification module and a feedback module.

[0112] The acquisition module is used to acquire newly added payment data, wherein the newly added payment data includes data specified by the first client and / or data generated by the first client when executing a transaction;

[0113] The association setting module is used to set association data based on the newly added payment data, wherein the association data includes business data and verification data, and the verification data is key information extracted from the newly added payment data;

[0114] The node creation module is used to create a business node according to the business data in the associated data, and generate business approval information according to the business node;

[0115] The approval request module is configured to send the business approval information to a second client and receive first approval result data fed back by the second client in response to the business approval information. The second client is a client associated with the business node. The second client establishes a communication connection with the server through a unified standardized interface.

[0116] The verification module is configured to obtain transaction information of the transaction business when the first approval result data includes a first conclusion identifier, verify the transaction information based on the verification data, and store the newly added payment data as current payment data according to the verification result;

[0117] The feedback module is configured to send resubmission information to the first client when the first approval result data includes a second conclusion identifier.

[0118] It should be noted that for other corresponding descriptions of the various functional units involved in the accounts receivable data management system provided in the embodiment of the present application, reference can be made to the corresponding descriptions in the accounts receivable data management method described in the above embodiment, and will not be repeated here.

[0119] The receivables data management system provided by the above embodiment can realize the systematization and onlineization of business operations such as collection, refund, transaction clearing, and collection approval through one-click configuration. This reduces human intervention, improves work efficiency, and provides good traceability of payment data.

[0120] like Figure 9 As shown, an embodiment of the present application also provides a computer device, which can be specifically a personal computer, a server, a network device, etc. The computer device includes a bus, a processor, a memory and a communication interface, and may also include an input and output interface and a display device. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device is used to store location information. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, the steps in each method embodiment are implemented.

[0121] Those skilled in the art will understand that the structure of the above-mentioned computer device is only a partial structure related to the solution of the present application and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components, or combine certain components, or have a different component arrangement.

[0122] In one embodiment, a computer-readable storage medium is provided. The computer-readable storage medium may be non-volatile or volatile, and stores a computer program thereon. When the computer program is executed by a processor, the steps in the above-mentioned method embodiments are implemented.

[0123] In one embodiment, a computer program product is provided, including a computer program, which implements the steps in the above method embodiments when executed by a processor.

[0124] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties.

[0125] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiment methods can be implemented by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, database or other media used in the embodiments provided in this application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processor involved in the various embodiments provided herein may be, but are not limited to, a general-purpose processor, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, and the like.

[0126] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0127] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A method for managing current account data, characterized in that: The method comprises: Acquiring newly added payment data, the newly added payment data including data specified by the first client and / or data generated by the first client when executing a transaction; the first client establishing a communication connection with the server via a unified standardized interface; Setting associated data based on the newly added payment data, the associated data including business data and verification data, the verification data being key information extracted from the newly added payment data; setting associated data based on the newly added payment data comprising: extracting a first project tag and a second project tag from the newly added payment data, the first project tag being a project tag specified by the first client; the second project tag being a project tag corresponding to business data; the business data being data generated when the first client performs a transaction; performing standardization on the second project tag to generate a third project tag, the third project tag being a project tag in a preset project tag library that is synonymous with the second project tag; and matching associated data according to the first project tag and the third project tag; Creating a business node according to the business data in the associated data, and generating business approval information according to the business node; Sending the business approval information to a second client, and receiving first approval result data fed back by the second client in response to the business approval information, where the second client is a client associated with the business node; the second client establishes a communication connection with the server through a unified standardized interface; If the first approval result data includes a first conclusion identifier, obtaining transaction information of the transaction business, performing verification on the transaction information based on the verification data, and storing the newly added payment data as current payment data according to the verification result; If the first approval result data includes a second conclusion identifier, a resubmission message is sent to the first client.

2. The method according to claim 1, characterized in that The method further comprises: Acquire refund application data, where the refund application data is data generated by the first client when executing a refund service; Creating a refund node according to the refund application data, and generating refund approval information according to the refund node; Sending the refund approval information to the second client, and receiving second approval result data fed back by the second client regarding the refund node information; Executing a refund service based on the second approval result data; According to the execution result of the refund business, the current account data associated with the refund application data is updated.

3. The method according to claim 2, characterized in that Executing a refund service based on the second approval result data includes: Reading a conclusion identifier from the second approval result; If the second approval result includes the first conclusion identifier, sending a refund service execution instruction to the second client, so that the second client initiates a payment request to the first client; If the second approval result includes a second conclusion identifier, refund receipt information is sent to the first client.

4. The method according to claim 1, wherein The method further comprises: Obtaining identification information of the newly added payment data, the identification information including at least one of a business serial number, a user ID, and an identification number of the first client; generating a traceability identifier based on the identification information, the first item tag, and the third item tag; The traceability identifier is added to the newly added payment data.

5. The method according to claim 1, wherein According to the verification result, the newly added payment data is stored as current payment data, including: Reading the transaction amount from the transaction information, and extracting the turnover amount from the verification data; If the transaction amount is greater than or equal to the turnover amount, generating a transaction voucher, and storing the newly added payment data and the transaction voucher; If the transaction amount is less than the turnover amount, a first prompt message is generated, and the first prompt message is sent to the first client and the second client.

6. The method according to claim 1, characterized in that The verification data further includes contract data associated with the newly added payment data. If the first approval result data includes a first conclusion identifier, the method further includes: verifying the transaction information based on the contract data; If the contract data is consistent with the transaction information, storing the newly added payment data; If the contract data is inconsistent with the transaction information, second prompt information is generated, and the second prompt information is sent to the first client and the second client.

7. A data management system for current account, characterized in that: include: A server and at least one first client and at least one second client communicating with the server via a unified standardized interface; the server comprises: an acquisition module, configured to acquire newly added payment data, wherein the newly added payment data includes data specified by the first client and / or data generated by the first client when executing a transaction; An association setting module is configured to set association data based on the newly added payment data, wherein the association data includes business data and verification data, and the verification data is key information extracted from the newly added payment data; the setting of association data based on the newly added payment data includes: extracting a first item tag and a second item tag from the newly added payment data, wherein the first item tag is a item tag specified by the first client; the second item tag is a item tag corresponding to business data; the business data is data generated when the first client performs a transaction; standardizing the second item tag to generate a third item tag, wherein the third item tag is a item tag in a preset item tag library that is synonymous with the second item tag; and matching association data according to the first item tag and the third item tag; A node creation module, configured to create a business node according to the business data in the associated data, and generate business approval information according to the business node; an approval request module, configured to send the business approval information to a second client, and receive first approval result data fed back by the second client in response to the business approval information, wherein the second client is a client associated with the business node; the second client establishes a communication connection with the server via a unified standardized interface; a verification module, configured to obtain transaction information of the transaction business when the first approval result data includes a first conclusion identifier, verify the transaction information based on the verification data, and store the newly added payment data as current payment data according to the verification result; A feedback module is configured to send resubmission information to the first client when the first approval result data includes a second conclusion identifier.

8. A computer device comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein: When the processor executes the computer program, the method according to any one of claims 1 to 6 is implemented.

9. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images