A payment slip generation method and computing device

Abstract

This application relates to the field of document payment, providing a payment order generation method and computing device. The method includes: in response to receiving a document payment task, generating a pre-payment instruction based on the invoice data to be paid corresponding to the document payment task; filling at least one target field in the pre-payment instruction according to preset field filling rules; dividing the filled pre-payment instruction into at least one payment instruction group according to preset payment grouping rules; each payment instruction group includes at least one pre-payment instruction; and generating a payable payment order corresponding to each payment instruction group. Based on this solution, the computing device can automatically identify the invoice data to be paid, dynamically generate and fill pre-payment instructions, and realize intelligent order merging and splitting according to payment grouping rules to form payment instruction groups, thereby realizing the automatic generation of payable payment orders, reducing manual intervention, and improving payment processing efficiency and accuracy.

Description

Technical Field

[0001] This application relates to the field of document payment technology, and in particular to a payment order generation method and computing device. Background Technology

[0002] In corporate financial management, accounts payable refers to the financial settlement activity in which a company pays suppliers for goods, services, or labor after purchasing them, in accordance with the contractual agreements or credit terms signed with the suppliers. Accounts payable is a key link in maintaining supply chain stability, controlling financial risks, and optimizing cash flow management.

[0003] In typical enterprise resource planning (ERP) or financial systems, payment personnel manually create payment orders and fill in the necessary fields based on the approved invoice payment plans. Furthermore, in scenarios involving multiple invoices, it's necessary to determine whether to merge or split the invoices to generate a single payment order, or to split them into multiple independent payment orders.

[0004] The payment process of the above system relies heavily on manual operation. In scenarios with a large volume of documents, the processing efficiency is low, and operational errors are prone to occur, making it difficult to meet the timeliness requirements of large-volume payment scenarios. Summary of the Invention

[0005] This application provides a payment order generation method and computing device, which can avoid the problem that the payment efficiency caused by manually creating payment orders does not meet the timeliness requirements of payment scenarios.

[0006] To achieve the above objectives, the embodiments of this application adopt the following technical solutions: In a first aspect, embodiments of this application provide a method for generating payment orders, the method comprising: responding to receiving a document payment task, generating a pre-payment instruction based on the pending invoice data corresponding to the document payment task; filling in at least one target field in the pre-payment instruction according to a preset field filling rule; the field filling rule is used to complete any unfilled fields in the pre-payment instruction, and the target field includes any unfilled field in the pre-payment instruction; dividing the filled pre-payment instruction into at least one payment instruction group according to a preset payment grouping rule; the payment grouping rule is used to group the filled pre-payment instructions by the target field, and each payment instruction group includes at least one filled pre-payment instruction; and generating a payable payment order corresponding to each payment instruction group.

[0007] Based on this solution, the computing device can automatically identify invoice data to be paid, dynamically generate and fill in pre-payment instructions, and realize intelligent order merging and splitting according to payment grouping rules to form payment instruction groups, thereby realizing the automatic generation of payable payment orders, reducing manual intervention and improving payment processing efficiency and accuracy.

[0008] In one possible implementation, a prepayment instruction is generated based on the pending invoice data corresponding to the document payment task, including: obtaining the pending invoice data from the invoice database based on the document payment task; performing structured processing on each pending invoice data to obtain structured invoice data; and generating a prepayment instruction based on the structured invoice data and the payment slip template.

[0009] Based on this solution, the computing device can perform structured parsing of the acquired invoice data, extract relevant fields to generate prepayment instructions, and realize the generation of prepayment instructions and the filling of some parameters.

[0010] In another possible implementation, at least one target field in the prepayment instruction is filled according to a preset field filling rule, including: obtaining the unfilled fields of the prepayment instruction; determining at least one of the unfilled fields as target fields based on the field names corresponding to the required fields in the field filling rule; the field filling rule includes required fields, at least one field filling value corresponding to each target field, and a first mapping relationship, wherein the required fields include at least one of the expected payment date, expected disbursement date, disbursement bank account, and payment voucher, and the first mapping relationship includes a mapping relationship between the field filling value and the structured invoice data; determining the field filling value corresponding to the target field in the field filling rule according to the structured invoice data in the prepayment instruction and the first mapping relationship; and writing the field filling value into the corresponding target field.

[0011] Based on this solution, the computing device can obtain the field filling value corresponding to the target field and automatically fill it into the target field according to the mapping relationship, making the field filling process of the prepayment instruction efficient and accurate, and avoiding the risk of errors caused by manual input.

[0012] In another possible implementation, before dividing the filled pre-payment instructions into at least one payment instruction group according to preset payment grouping rules, the method further includes: determining the payment status of the pre-payment instructions based on preset invoice standard rules; the payment status includes standard payment status and non-standard payment status; generating a first payment identifier corresponding to the standard payment status or non-standard payment status based on the payment status corresponding to the pre-payment instructions; writing the first payment identifier to the corresponding pre-payment instructions; determining negative pre-payment instructions and positive pre-payment instructions based on the field values ​​of the pre-payment instructions; the field value of the amount field corresponding to the negative pre-payment instructions is negative, and the field value of the amount field corresponding to the positive pre-payment instructions is positive; the user identifier and the first payment identifier in the negative pre-payment instructions are the same as the user identifier and the first payment identifier in the positive pre-payment instructions, and the user identifier is used to indicate information such as company, supplier, payment currency, planned payment method, and payer's bank account; writing the field value of the target field corresponding to the positive pre-payment instructions to the target field corresponding to the negative pre-payment instructions.

[0013] Based on this solution, the computing device can automatically associate positive and negative prepayment instructions, so that the negative prepayment instructions inherit the field values ​​of the target fields of the positive instructions, ensuring data consistency and integrity, and realizing offsetting processing in the payment process.

[0014] In another possible implementation, the payment status of the prepayment instruction is determined based on preset invoice standard rules, including: comparing the field values ​​in the prepayment instruction with the preset invoice standard rules; if each field value does not meet the invoice standard rules, the payment status of the prepayment instruction is a standard payment status; if any field value meets the invoice standard rules, the payment status of the prepayment instruction is a non-standard payment status.

[0015] Based on this solution, the computing device can accurately identify and classify the payment status of prepayment instructions, ensuring the compliance and efficiency of subsequent processing.

[0016] In another possible implementation, according to a preset payment grouping rule, the filled pre-payment instructions are divided into at least one payment instruction group, including: obtaining an independent identifier in each filled pre-payment instruction; the independent identifier is used to identify the payment method corresponding to the pre-payment instruction, and the independent identifier includes one of independent payment status and non-independent payment status; determining each pre-payment instruction with an independent identifier of independent payment status as a first payment instruction group; obtaining the field value of the amount field of the pre-payment instruction in each first payment instruction group; clustering the pre-payment instructions with an independent identifier of non-independent payment status based on the user identifier and the first payment identifier to obtain at least one second payment instruction group; the user identifier and the first payment identifier of the pre-payment instructions in the second payment instruction group are the same; obtaining the sum of the field values ​​of the amount field of the pre-payment instructions in each second payment instruction group.

[0017] Based on this solution, the computing device can cluster pre-payment instructions according to payment grouping rules and perform amount statistics on the payment instruction groups formed by clustering, providing data support for subsequent payment operations and improving the automation level and processing efficiency of the payment process.

[0018] In another possible implementation, before generating a payable payment slip corresponding to each payment instruction group, the method further includes: determining the payment status of the payment instruction group based on invoice standard rules; generating a second payment identifier corresponding to the payment instruction group; and writing the second payment identifier to the corresponding payment instruction group.

[0019] Based on this solution, the computing device can generate a second payment identifier for each payment instruction group to determine whether the payment instruction group is a standard payment type, thereby achieving accurate identification and classification management of non-standard payment types.

[0020] In another possible implementation, before generating a payable payment slip corresponding to each payment instruction group, the method further includes: determining negative payment slips and positive payment slips based on the field value of the amount field in the payment instruction group; negative payment slips include a first payment instruction group where the field value of the amount field is less than zero, or a second payment instruction group where the field value of the amount field is less than zero, and the user identifier of the negative payment slip is the same as the user identifier of the positive payment slip; and writing the field value of the target field corresponding to the positive payment slip to the target field corresponding to the negative payment slip.

[0021] Based on this solution, the computing device can associate negative payment orders with positive payment orders and make the target fields of negative payment orders conform to the target fields of positive payment orders, ensuring the consistency and compliance of the target field values ​​in negative payment orders and realizing offsetting processing in the payment process.

[0022] In another possible implementation, the pre-payment instructions are divided into at least one payment instruction group according to a preset payment grouping rule. The method also includes: if the sum of the field values ​​of the amount field of the pre-payment instructions in the payment instruction group is zero, then the field value corresponding to the disbursing bank account in the payment instruction group is deleted.

[0023] Based on this solution, the computing device can clear the value of the bank account field in the payment instruction group with a value of zero, so as to avoid invalid fund transfers and improve the processing speed of the computing device.

[0024] Secondly, embodiments of this application also provide a payment order generation system, which includes a payment instruction generation module configured to generate a pre-payment instruction based on the pending invoice data corresponding to the document payment task in response to receiving a document payment task; a field filling module configured to fill at least one target field in the pre-payment instruction according to preset field filling rules; an instruction grouping module configured to divide the filled pre-payment instruction into at least one payment instruction group according to preset payment grouping rules; and a payment order generation module configured to generate a payable payment order corresponding to each payment instruction group.

[0025] Thirdly, embodiments of this application also provide a computing device, including: a processor and a memory; the processor and the memory are coupled; the memory is used to store program instructions; the processor is used to execute the program instructions to perform the method as described in any of the first aspects above.

[0026] Fourthly, embodiments of this application provide a chip for performing the methods described in any of the first aspects above.

[0027] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer-executable instructions, which, when executed by a computer, implement the method as described in any of the first aspects.

[0028] In a sixth aspect, embodiments of this application provide a program product including a computer program that, when executed by a processor, implements the method as described in any of the first aspects. Attached Figure Description

[0029] Figure 1 A flowchart illustrating a payment slip generation method provided in this application embodiment; Figure 2 A schematic diagram illustrating a process for generating a prepayment instruction, provided as an embodiment of this application; Figure 3 This application provides a schematic diagram of a process for filling a target field in an embodiment. Figure 4A schematic diagram illustrating the configuration of a payment field verification rule provided in an embodiment of this application; Figure 5 A schematic diagram of a configuration interface for a field filling rule provided in an embodiment of this application; Figure 6 A flowchart illustrating the verification of a prepayment instruction provided in an embodiment of this application; Figure 7 A flowchart illustrating a prepayment instruction grouping is provided as an embodiment of this application; Figure 8 This application provides a schematic diagram of a payment instruction group processing flow. Figure 9 A schematic diagram of a configuration interface for an invoice standard rule provided in an embodiment of this application; Figure 10 A schematic diagram of an interface for generating a payable payment slip, provided as an embodiment of this application; Figure 11 A schematic diagram of an interface for verifying a payment slip provided in an embodiment of this application; Figure 12 This is a schematic diagram of the structure of a payment order generation system provided in an embodiment of this application; Figure 13 This is a schematic diagram of a computing device provided in an embodiment of this application. Detailed Implementation

[0030] The technical solutions of the embodiments of this application will now be described with reference to the accompanying drawings. To facilitate a clear description of the technical solutions of the embodiments of this application, the use of terms such as "first," "second," etc., in the embodiments of this application is for illustrative purposes and to distinguish the objects being described. There is no particular order between them, nor does it indicate a specific limitation on the number of devices in the embodiments of this application, and they do not constitute any limitation on the embodiments of this application.

[0031] The following explanations of the technical terms mentioned in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0032] Accounts payable invoices are payment vouchers issued by suppliers to businesses after purchasing goods or services. They record information such as the amount payable to the supplier, the payment date, and the invoice number, and are one of the important documents in a company's financial management.

[0033] A payment slip is a voucher generated by a company when making a payment. It records detailed payment information, including the payee, payment amount, and payment method. It is one of the important documents in corporate financial management, used to regulate and record payment activities.

[0034] A payment document is a formal document that records a company's payment activities and is used to confirm and track payment details. It is typically generated during a company's payment process to ensure the compliance and traceability of payment operations.

[0035] The estimated payment date refers to the date that a company anticipates making payments to suppliers or other payees, based on contractual agreements, invoice information, or payment schedules. It is typically used for financial management and cash flow planning to ensure that companies fulfill their payment obligations on time.

[0036] The estimated disbursement date refers to the date that a company anticipates will actually execute the payment transaction, based on its payment plan, contractual agreements, or invoice information. It is typically used for financial management and fund allocation to ensure that the company fulfills its payment obligations on time.

[0037] The application scenarios of this application will be explained below.

[0038] The typical process of processing accounts payable invoices often requires manual intervention. This means that finance personnel manually create payment orders based on invoice information, verify the amount and supplier account information, and confirm the payment time and payment method for each transaction. In large-volume payment scenarios, manual processing can easily lead to problems such as low processing efficiency and inability to meet timeliness requirements.

[0039] To address the aforementioned issues, this application provides a payment order generation method that utilizes a computing device and pre-defined rules within the device to process invoices to be paid, thereby grouping these invoices and generating corresponding payable payment orders. This avoids the inefficiency of document processing caused by manual intervention and improves the accuracy and timeliness of payment processing.

[0040] The payment slip generation method provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0041] Figure 1 This is a flowchart illustrating a payment slip generation method provided in an embodiment of this application. The following is based on... Figure 1 The payment slip generation method provided in the embodiments of this application will be described by way of example.

[0042] like Figure 1 As shown, the payment slip generation method provided in this application embodiment includes the following steps S100 to S400.

[0043] S100: In response to receiving a document payment task, the computing device generates a prepayment instruction based on the pending invoice data corresponding to the document payment task.

[0044] The computing device refers to the hardware device that can implement the payment order generation method. The method provided in this application embodiment can be deployed in the computing device in the form of software. The computing device can call the preset payment processing logic to perform subsequent operations by responding to the trigger of software instructions.

[0045] In this embodiment, the document payment task can be triggered by the computing device itself, by an instruction sent by an external system, or by the user manually. In the scenario where the computing device triggers the document payment task itself, it can periodically generate the task to process the enterprise's accounts payable invoices in batches. For example, the device can scan the accounts payable database daily to identify overdue or soon-to-be-overdue invoices and automatically generate corresponding payment tasks.

[0046] In scenarios where instructions sent by an external system trigger the computing device to generate payment slips, the external system corresponding to the computing device, such as a corporate financial system, can generate a payment task and send it to the computing device when it detects a qualified invoice to be paid. This triggers the computing device to execute the payment slip generation process, thereby achieving automated processing. This allows the payment slip generation process to begin without manual intervention, enabling the handling of routine payment tasks.

[0047] In some embodiments, the computing device also supports receiving document payment tasks manually entered by finance personnel through a graphical interface. For example, when a specific payable invoice requires urgent payment or special payment arrangements, finance personnel can manually create document payment tasks through the graphical interface to initiate the payment order generation process.

[0048] After receiving a payment task, the computing device extracts key payment information fields from the pending invoice data within the task. These fields include company, supplier, supplier address, bank account information, invoice amount, currency, payment terms, and payment date. Based on this key payment information, the computing device generates corresponding pre-payment instructions. Each pre-payment instruction corresponds to one pending invoice and includes the key payment information fields of that invoice.

[0049] In some embodiments, the content included in a document payment task may be limited, not including all the key payment information fields of the corresponding invoice to be paid. In this case, the key payment information fields obtained by the computing device are insufficient to directly generate a complete prepayment instruction. The computing device can obtain the complete information fields of the invoice to be paid corresponding to the document payment task from the invoice database, thereby enabling the computing device to generate a complete prepayment instruction.

[0050] Figure 2This is a schematic diagram of a process for generating a prepayment instruction, provided as an embodiment of this application.

[0051] like Figure 2 As shown, the process of generating a prepayment instruction by a computing device in this embodiment may include the following steps S110 to S130.

[0052] S110: The computing device retrieves the invoice data to be paid from the invoice database based on the document payment task.

[0053] In some embodiments, the document payment task may carry the identification information of the invoice to be paid. The computing device queries and obtains the complete data record of the corresponding invoice to be paid from the invoice database based on the identification information and the preset data retrieval script in the computing device, and obtains the corresponding invoice data to be paid.

[0054] The identification information for invoices awaiting payment can be an invoice number, invoice code, business document number, or unique transaction identifier, used to uniquely identify invoices awaiting payment in the invoice database. The data retrieval script can be a query statement template adapted to the invoice database structure. Taking the invoice database as a relational database as an example, the data retrieval script is written in Structured Query Language (SQL) and includes placeholders to dynamically populate the identification information of invoices awaiting payment to generate an executable database query statement.

[0055] After the computing device substitutes the identification information of the invoice to be paid into the placeholder, it can generate a customized query statement for the current document payment task based on the data retrieval script. The computing device can then send the query statement to the invoice database to initiate a data retrieval request, thereby obtaining the complete data record of the invoice to be paid.

[0056] In another embodiment, the document payment task itself does not contain the identification information of the invoices to be paid, but rather a description of the invoices to be paid that the computing device needs to operate on. For example, the task content in the document payment task is "currently payable invoices that have been approved". The computing device can construct a retrieval logic suitable for the invoice database together with the data retrieval script based on the description conditions in the task content. By traversing the invoices to be paid in the database that meet the payment status, approval status and payment period conditions, it can filter out one or more sets of invoice data that match the document payment task.

[0057] In this embodiment, in addition to the invoice data table storing invoices to be paid, the invoice database may also include a supplier table, a payment plan table, and an approval table, so that the computing device can use the joint query of multiple data tables to obtain the invoice data that meets the conditions for the document payment task in the invoice data table.

[0058] In another embodiment, when performing a joint query across multiple data tables, the computing device can retrieve the payment plan, supplier information, and approval status of the invoice to be paid from data tables such as the supplier table, payment plan table, and approval table. The payment plan may include fields such as planned payment line number, planned payment date, and planned payment amount. The supplier information may include fields such as supplier name, address, payment location, and payment account. The approval status indicates whether the invoice to be paid has been approved. When the approval status is "approved" or an equivalent, the computing device includes the invoice in the subsequent processing flow; if the approval status is "not approved" or "under approval," the computing device will exclude it during the data retrieval process, so that it can be included in the processing scope after subsequent approval.

[0059] S120: The computing device performs structured processing on each invoice data to be paid to obtain structured invoice data.

[0060] It should be understood that the invoice data to be paid obtained by the computing device from the invoice database through the data retrieval script may contain unstructured or semi-structured fields. In this case, the computing device cannot generate the corresponding prepayment instruction based on the invoice data. Therefore, the computing device can perform structured processing on the invoice data to obtain the corresponding structured invoice data, which can then be used to generate the prepayment instruction.

[0061] In this embodiment, the structured processing of the invoice data to be paid involves converting the raw row data retrieved from the invoice database by the computing device into standardized parameters in key-value pair format. Each key-value pair represents a mapping relationship between a field and its corresponding field value. For example, in the raw row data, "INV_001" corresponds to the invoice number field, and "2025-01-01" corresponds to the invoice date field. After structured processing, a set of key-value pairs such as {Invoice Number: INV_001, Invoice Date: 2025-01-01} is formed.

[0062] The above-described structured processing is only one feasible implementation method provided in the embodiments of this application. In practical applications, other data standardization methods can be adopted according to actual system requirements, and the embodiments of this application do not impose any restrictions here.

[0063] S130: The computing device generates a prepayment instruction based on the structured invoice data and the payment form template.

[0064] The payment slip template refers to the standardized set of fields that the payment slip output by the computing device should include, including but not limited to the payee's name, payee account, payment amount, currency, reason for payment, and invoice number. In this embodiment, because the computing device ultimately generates the payment slip through a payment instruction group formed by at least one pre-payment instruction, the field structure of the pre-payment instruction is consistent with the field structure in the payment slip template. This allows the pre-payment instruction to be directly mapped to the final generated payable payment slip without the need for additional format conversion or mapping processing.

[0065] It should be noted that the prepayment instruction generated by the computing device at this time only contains the content it reads from the invoice database. Some fields in the prepayment instruction have not yet been filled. The prepayment instruction in this state is only stored in the computing device as intermediate data for generating the payment order, so that it can be called in subsequent processes.

[0066] For example, the computing device may have multiple core tables to store intermediate data during the execution of the payment order generation method. For example, the core tables in the computing device may include a smart payment acquisition batch table, a smart payment acquisition data error information table, and a smart payment acquisition pre-payment instruction temporary table, etc.

[0067] The intelligent payment batch table can be updated every time the computing device receives a payment task that triggers the generation of a payment order. It is used to record parameters such as the batch identifier, task trigger time, processing status, and operator information of this payment task.

[0068] The Smart Payment Data Acquisition Error Information Table is used to record the original data entries that are abnormal during the data acquisition and structured processing, along with their error types, occurrence times, and processing status, so that subsequent reconciliation or manual intervention can be carried out.

[0069] The temporary table for obtaining prepayment instructions in smart payment is used to temporarily store prepayment instructions generated from the original invoice data after structured processing. At this time, the prepayment instructions have not yet undergone payment status verification and grouping processing, and the field values ​​corresponding to some fields are still empty. They need to be filled in according to the field filling rules in subsequent steps.

[0070] After receiving a prepayment instruction, the computing device can query negative invoice records in the invoice database to obtain unexpired negative invoices. After obtaining the unexpired negative invoices, the computing device can deduplicate them with the corresponding invoices in the prepayment instruction to avoid duplicate invoices from participating in payment grouping.

[0071] S200: The computing device fills in at least one target field in the prepayment instruction according to the preset field filling rules.

[0072] The field filling rules can be used to complete and validate any missing fields in the prepayment instruction to ensure that the values ​​of the target fields meet the requirements for generating the payment order. The target fields refer to the fields in the prepayment instruction obtained by the computing device in step S100 that have not yet been filled, such as the expected payment date, expected disbursement date, disbursement bank account, and payment voucher.

[0073] In some embodiments of this application, the field filling rules are set in the computing device and are rules for generating the field values ​​of target fields using the content in the prepayment instruction or the content obtained by the computing device from the invoice database through a data retrieval script. For example, the expected payment date can be determined by combining the "invoice date" or "payment period" field of the invoice to be paid with the payment cycle of the supplier corresponding to the invoice to be paid.

[0074] The expected disbursement date is calculated based on the company's funding plan and the bank's settlement cycle. For example, the expected disbursement date can be increased by 1 to 2 business days from the expected payment date to ensure the smooth completion of fund allocation and approval processes. The disbursement bank account is obtained by matching the supplier, supplier address, and payment currency fields in the pre-payment instruction with a pre-set disbursement account mapping table to ensure the accuracy and compliance of account information.

[0075] Payment vouchers can be generated automatically using a pre-set payment voucher template in the computing device, combined with fields such as the delivery currency and issuing bank account information in the pre-payment instruction. This automatically generates payment vouchers that comply with corporate financial regulations. After obtaining the field values ​​for target fields such as the expected payment date, expected disbursement date, issuing bank account, and payment voucher, the computing device can write these values ​​into the corresponding fields in the pre-payment instruction, thus fully filling in the target fields. In this way, the computing device can obtain the field values ​​corresponding to unfilled fields in the pre-payment instruction based on preset field filling rules and complete them, ensuring the completeness and accuracy of all key field information.

[0076] Figure 3 This is a schematic diagram illustrating a process for filling a target field, provided in an embodiment of this application. The following is in conjunction with... Figure 3 The process of filling the target field of the prepayment instruction with a computing device provided in the embodiments of this application is illustrated by way of example.

[0077] like Figure 3 As shown, the process of filling the target field of the prepayment instruction with a computing device provided in this application embodiment may include the following steps S210 to S240.

[0078] S210: Unfilled fields of the computing device for obtaining prepayment instructions.

[0079] In this embodiment of the application, the computing device can identify fields that have not yet been filled with field values ​​by traversing the fields in the prepayment instruction, treat them as unfilled fields, and record their field names and corresponding data types.

[0080] It should be noted that the process of identifying unfilled fields needs to be combined with the data structure definition of the pre-payment instruction to ensure accurate determination of whether the current state of each field is empty or a default value. Simultaneously, the computing device will determine the filling priority based on field attributes. For example, the computing device can set fields related to payment address and payment timeliness, such as expected payment date, expected disbursement date, disbursement bank account, and payment voucher, as high priority, filling them first to ensure the timeliness and accuracy of the payment process.

[0081] S220: Based on the field names corresponding to the required fields in the field filling rules, the computing device determines at least one of the unfilled fields as the target field.

[0082] In this embodiment, the field filling rule includes required fields, at least one field filling value corresponding to each target field, and a first mapping relationship. The required fields may include at least one of the following: expected payment date, expected disbursement date, disbursement bank account, and payment voucher. The field filling value refers to the field value filled into the target field, which may be a system preset value or a value obtained through a preset algorithm. The first mapping relationship includes the mapping relationship between the field filling value and the structured invoice data.

[0083] It should be understood that required fields refer to those fields that must be filled in the prepayment instruction. These fields are set according to the company's financial regulations and payment compliance requirements to ensure the legality and compliance of the payment process and the integrity of financial data. For example, payment field validation rules can be preset in the computing device to verify the completeness and compliance of fields in the prepayment instruction and to identify required fields. This means marking mandatory fields that need to be completed in the prepayment instruction to ensure they are prioritized for filling in subsequent processes.

[0084] In some embodiments, payment field validation rules can be defined based on the format of the final payment slip generated by the computing device. That is, the field names in the payment field validation rules are determined by the fields present in the payment slip. In addition to field names, payment field validation rules may also include attributes such as the data type, length limit, value type, value range, and whether each field is required.

[0085] The computing device can filter out the required fields that need to be filled in from the unfilled fields of the pre-payment instruction based on the required field identifiers in the payment field verification rules, and use them as target fields.

[0086] Figure 4This is a schematic diagram illustrating the configuration of a payment field verification rule provided in an embodiment of this application.

[0087] like Figure 4 As shown, the computing device provides a graphical interface 40 for configuring payment field validation rules to financial personnel. The payment field validation rule configuration interface 40 includes a query area 41 and a revision area 42. The query area 41 receives user-input query conditions, such as company code, field name, and English description of the field, to quickly locate the corresponding field and its validation attributes. The revision area 42 displays detailed configuration information for each field, including field name, data type, length limit, value type, value range, and whether it is required, allowing users to dynamically adjust and maintain the field validation rules.

[0088] In some embodiments, certain fields in the payment field validation rules may also have corresponding SQL statements, which are used to dynamically obtain field values ​​during execution as the source of field filling values. For example, for the "Individual Supplier Identifier" field, its field value can be dynamically filled with "YES" or "NO" by executing a preset SQL statement during the filling process, based on the field value corresponding to the "Supplier Number" field in the pre-payment instruction, associating it with the supplier master data table, querying whether the supplier is an individual, and so on.

[0089] Similarly, for the "expected payment date" field, the computing device can obtain the corresponding field value from the database by executing an SQL statement during the verification of the prepayment instruction.

[0090] It should be noted that the method of dynamically retrieving field values ​​by setting SQL statements in the payment field validation rules is only one example provided in this application embodiment. In actual applications, the computing device can also use the obtained invoice data to synchronously retrieve field values ​​associated with the invoices to be paid from the related data table during the generation of pre-payment instructions, such as supplier bank account information and contractual payment terms, and fill them into the target fields corresponding to the pre-payment instructions based on the field filling rules. This application embodiment does not limit this and can be flexibly configured according to actual business scenarios.

[0091] S230: The computing device determines the field filling value corresponding to the target field in the field filling rules based on the structured invoice data in the prepayment instruction and the first mapping relationship.

[0092] In some embodiments, the field fill values ​​in the prepayment instruction can be field values ​​directly stored therein, or they can be based on... Figure 4The values ​​obtained by dynamically querying the SQL statements configured in the payment field validation rules are shown in the diagram. Correspondingly, the first mapping relationship, which includes the mapping between field fill values ​​and structured invoice data, can also be the SQL statements configured in the payment field validation rules. This allows querying the field values ​​associated with the structured invoice data in the data table using SQL statements and using them as field fill values.

[0093] For example, when a prepayment instruction enters the field filling stage, the computing device can determine the field value of the target field corresponding to the supplier name and supplier number fields in the data table using the field values ​​in the structured invoice data, such as the field values ​​corresponding to the supplier name and supplier number fields. After obtaining the corresponding field value, the computing device can use it as the field filling value and fill it into the target field corresponding to the prepayment instruction.

[0094] In another embodiment, the field filling rules, in addition to the above-mentioned content, may also include payment voucher setting rules and the mapping relationship between payment vouchers and issuing bank accounts. The payment voucher setting rules are used to generate payment vouchers corresponding to pre-payment instructions. These rules may include a mapping relationship between the enterprise's issuing bank account and the payment voucher name format. This ensures that the generated payment voucher corresponds to the issuing bank account, guaranteeing that the payment voucher information matches the enterprise's actual issuing account and preventing payment failures or incorrect fund flows due to account information mismatches.

[0095] The mapping relationship between payment vouchers and issuing bank accounts is dynamically matched through a preset fund account configuration table, so that the correct payment vouchers are generated and associated with the corresponding accounts during the pre-payment instruction generation process.

[0096] Figure 5 This is a schematic diagram of a configuration interface for a field filling rule provided in an embodiment of this application.

[0097] like Figure 5 As shown in (a), the graphical configuration interface provided by the computing device may also include a payment voucher setting rule configuration interface 51, through which users can configure the payment voucher types and naming rules corresponding to different bank accounts. Furthermore, the computing device can add, modify, or export payment voucher setting rules in response to user operations, enabling flexible management and dynamic retrieval of payment vouchers.

[0098] like Figure 5As shown in (b), the mapping relationship between payment vouchers and issuing bank accounts can also be queried through the query interface 52 provided by the computing device. This interface stores the mapping relationships between payment vouchers and bank accounts historically generated by the computing device and allows users to manually adjust or add configurations based on actual business needs. After generating a payment voucher, the computing device can construct corresponding records based on the mapping relationship between the payment voucher and the issuing bank account and store them in the device, facilitating subsequent auditing, tracing, and compliance verification.

[0099] S240: The computing device writes the field fill value into the corresponding target field.

[0100] In this embodiment, after the computing device determines the field fill value corresponding to the target field in the prepayment instruction based on the above steps, it can write the field fill value into the corresponding target field, thus completing the field fill operation of the prepayment instruction. This process can automatically fill each target field in the prepayment instruction through pre-set field fill rules, ensuring data accuracy and process consistency.

[0101] In some embodiments of this application, after the computing device completes the field filling, it will further perform the verification and optimization operation of the pre-payment instruction, identify the standard payment process and the non-standard payment process, and perform preliminary filtering of special points and risk points in the payment process.

[0102] Figure 6 This is a schematic flowchart illustrating the verification of a prepayment instruction, provided as an embodiment of this application. The following is in conjunction with... Figure 6 The verification process of the prepayment instruction provided in the embodiments of this application is illustrated by way of example.

[0103] like Figure 6 As shown, the process of a computing device verifying a prepayment instruction may include the following steps S201 to S205.

[0104] S201: Based on preset invoice standard rules, the computing device determines the payment status of the prepayment instruction.

[0105] In this embodiment of the application, the payment status of the prepayment instruction includes either a standard payment status or a non-standard payment status. The distinction between standard and non-standard payment status refers to whether the payment status meets preset compliance conditions, i.e., invoice standard rules.

[0106] The standard invoice rules can store conditions that trigger non-standard payment statuses, such as invoice amount exceeding limits, supplier mismatch, or payment transaction type requiring special approval. After receiving a prepayment instruction, the computing device can compare the field values ​​in the prepayment instruction using the conditions in the standard invoice rules.

[0107] If none of the field values ​​meet the invoice standard rules, the prepayment instruction will be in a standard payment status. If any field value in the prepayment instruction meets the invoice standard rules, the prepayment instruction will be in a non-standard payment status.

[0108] It should be understood that the invoice standard rules applied in this application embodiment can also be a set of rules that can be customized and configured by the user according to the actual business scenario. The computing device can support dynamic updates and version management of the invoice standard rules through a graphical interface.

[0109] S202: The computing device generates a first payment identifier corresponding to the standard payment status or the non-standard payment status based on the payment status corresponding to the pre-payment instruction.

[0110] After receiving the payment status of a pre-payment instruction, the computing device can generate a first payment identifier corresponding to the corresponding status. For example, a pre-payment instruction with a standard payment status will generate a first payment identifier of "standard"; a pre-payment instruction with a non-standard payment status will generate a first payment identifier of "non-standard". The first payment identifier is used to identify the path selection of the pre-payment instruction in the subsequent processing flow, ensuring that the computing device can perform differentiated processing on instructions of different payment types.

[0111] After obtaining the payment status, if the payment status is a non-standard payment status, the computing device can generate a corresponding non-standard reason based on the specific conditions in the invoice standard rules triggered by the pre-payment instruction field value. This is used to record the factors that cause the pre-payment instruction to be judged as non-standard, such as "invoice amount exceeds the limit" or "supplier qualifications do not meet the requirements". The non-standard reason is associated with the first payment identifier and stored for subsequent approval process calls and audit traceability.

[0112] For example, the core tables set in the computing device can also include a smart payment non-standard reason table, which can be used to store non-standard reason records associated with pre-payment instructions in non-standard payment states. This table can record the type of non-standard reason, triggering rule items, processing suggestions, and approval remarks through the instruction header ID of the pre-payment instruction as the associated field. This table supports multi-dimensional queries and statistical analysis, making it easy for users to quickly locate the causes of abnormal payments and formulate response strategies.

[0113] S203: The computing device writes the first payment identifier to the corresponding prepayment instruction.

[0114] After obtaining the first payment identifier, the computing device can write it into a designated field of the corresponding pre-payment instruction, ensuring that the identifier is persistently bound to the pre-payment instruction data. By writing the first payment identifier into the pre-payment instruction, the computing device can read and judge the first payment identifier in subsequent processing, facilitating the classification and grouping of pre-payment instructions and improving the automated execution efficiency and risk control capabilities of the payment process.

[0115] S204: Based on the field value of the prepayment instruction, the computing device determines negative and positive prepayment instructions.

[0116] Among them, negative prepayment instructions are prepayment instructions with a negative value in the remaining amount field, which usually correspond to refund or cancellation business scenarios; positive prepayment instructions are prepayment instructions with a positive value in the remaining amount field, which correspond to regular payment business scenarios.

[0117] The computing device can identify the instruction type by reading field values ​​in the prepayment instruction, such as the value corresponding to the remaining amount field, and determining whether the value is positive or negative. The remaining amount field is a numeric field in the prepayment instruction used to record the prepayment amount. Its value reflects the direction and magnitude of the actual amount to be paid or offset under this instruction. The value of the remaining amount field can be determined by the computing device when acquiring the invoice data to be paid, based on the difference between the original amount on the invoice, the amount already paid, and other deducted amounts.

[0118] In this embodiment, when the value of the remaining amount field is negative, the computing device can determine it as a negative prepayment instruction; when the value of the remaining amount field is positive, the computing device can determine it as a positive prepayment instruction. By distinguishing between negative and positive prepayment instructions, the system can execute differentiated processing logic for different business scenarios, such as applying different rules in payment grouping, payment account matching, and approval flow path selection, to ensure accurate separation and compliant processing of refund and payment operations.

[0119] Furthermore, before determining negative and positive prepayment instructions, the computing device can read the independent identifier from the prepayment instruction to determine whether the corresponding prepayment instruction needs to be grouped and merged. If the independent identifier in the prepayment instruction indicates an independent payment status, the computing device will not perform the following processing procedure on the prepayment instruction, but will directly execute step S300.

[0120] If the independent identifier in the prepayment instruction is in a non-independent payment state, the computing device will include the prepayment instruction in the batch grouping and merging process. At this time, the computing device can perform the operation corresponding to step S204 on the prepayment instruction to determine the attribute of the prepayment instruction.

[0121] In this embodiment of the application, when the computing device determines the payment status based on the field value of the remaining amount field, it can first read the independent identifier of the prepayment instruction and include all prepayment instructions with independent identifiers as non-independent payment status in the processing scope of determining the payment status, and then classify them according to the positive or negative value of the remaining amount field.

[0122] When determining the payment status of a prepayment instruction, the computing device first reads each negative and positive prepayment instruction and obtains the user identifier corresponding to each negative prepayment instruction. The user identifier identifies the company, supplier, payment currency, planned payment method, and the payer's bank account. After obtaining the user identifier corresponding to the negative prepayment instruction, the computing device matches all positive prepayment instructions with the same user identifier and the same first payment identifier, based on the information in that user identifier. The successfully matched positive prepayment instructions are then associated with their corresponding negative prepayment instructions.

[0123] The computing device ensures that the user identifier and first payment identifier in the negative prepayment instruction are the same as those in the positive prepayment instruction, thus forming a precise match between the negative and positive prepayment instructions and ensuring a clear and traceable correspondence between refunds and payments.

[0124] If the computing device finds multiple positive prepayment instructions corresponding to a negative prepayment instruction when matching negative and positive prepayment instructions, it will associate the negative prepayment instruction with the instruction with the largest value of the remaining amount field among the multiple positive prepayment instructions.

[0125] S205: The computing device writes the field value of the target field corresponding to the positive prepayment instruction to the target field corresponding to the negative prepayment instruction.

[0126] In this embodiment of the application, the computing device performs matching and association between negative prepayment instructions and positive prepayment instructions before grouping them. The purpose is to ensure that the target fields of negative prepayment instructions and positive prepayment instructions are consistent, so as to ensure that the two can be executed together in subsequent batch processing.

[0127] After the computing device completes the association and matching of negative and positive prepayment instructions, it can write the field value of the target field corresponding to the positive prepayment instruction to the target field corresponding to the negative prepayment instruction. This makes the target fields of the negative prepayment instruction, such as the expected payment date, payment voucher, payment configuration file, and issuing bank account, conform to the corresponding field value of the positive prepayment instruction, thereby achieving consistent processing of the negative prepayment instruction with the associated positive instruction in subsequent processes.

[0128] After the computing device performs the assignment operation on the target field of the negative prepayment instruction, it can write the row identifier of the positive prepayment instruction into the extended attribute field of the negative prepayment instruction to determine the data source of the target field of the negative prepayment instruction, which is convenient for subsequent traceability and auditing.

[0129] In some embodiments, before writing the target field value of a positive prepayment instruction into a negative prepayment instruction, the computing device may verify the bank account of the payer in the negative prepayment instruction. If the bank account of the payer in the negative prepayment instruction is empty, the bank account information of the payer in the positive prepayment instruction will not be written when writing the positive prepayment instruction during matching, so as to ensure that the negative prepayment instruction can still complete the association matching and field inheritance even without a specified payer account.

[0130] S300: The computing device divides the filled pre-payment instructions into at least one payment instruction group according to the preset payment grouping rules.

[0131] Each payment instruction group may include at least one padded pre-payment instruction, and the pre-payment instructions within the same group satisfy the same payment grouping rule. The payment grouping rule can group the padded pre-payment instructions based on their target fields. For example, the payment grouping rule can group pre-payment instructions with the same user identifier and first payment status into the same group.

[0132] In this embodiment, the payment grouping rule includes two sub-rules, corresponding to the grouping processing of pre-payment instructions with independent identifiers indicating an independent payment status and pre-payment instructions with independent identifiers indicating a non-independent payment status, respectively. Because the independent identifier is used to identify whether a pre-payment instruction corresponds to an independent payment demand, the payment grouping rule will differentiate the processing of pre-payment instructions with different independent identifiers to avoid confusion between independent and non-independent payment instructions and ensure the accuracy and compliance of fund flows.

[0133] Figure 7 This is a schematic flowchart illustrating a prepayment instruction grouping method provided in an embodiment of this application. The following is in conjunction with... Figure 7 The content shown herein serves as an exemplary illustration of the process by which a computing device groups prepayment instructions in an embodiment of this application.

[0134] like Figure 7 As shown, the process by which the computing device groups prepayment instructions includes the following steps S310 to S360.

[0135] S310: The computing device obtains the unique identifier in each filled prepayment instruction.

[0136] The independent identifier is used to identify the payment method corresponding to the prepayment instruction. The independent identifier includes one of independent payment status and non-independent payment status. In this embodiment, the independent identifier field in the prepayment instruction may have multiple fields, such as invoice independent payment status and supplier independent payment status, which are used to control independent payment requests based on invoice and supplier dimensions, respectively.

[0137] Specifically, the computing device can determine the field value of the invoice independent payment status for the corresponding pre-payment instruction based on the data stored in the invoice database during the process of acquiring the invoice data to be paid. The supplier independent payment status can be determined based on the configuration items in the supplier master data to obtain the field value. Furthermore, the invoice independent payment status indicates whether the pre-payment instruction needs to be processed independently based on a single invoice, while the supplier independent payment status indicates whether payment settlement needs to be completed independently at the supplier level.

[0138] When either the invoice independent payment status or the supplier independent payment status terminal is "yes", the independent identifier of the prepayment instruction is "independent payment status"; when both the invoice independent payment status and the supplier independent payment status are "no", the independent identifier of the prepayment instruction is marked as "non-independent payment status", and thus enters the corresponding grouping process according to the above rules in the grouping stage.

[0139] S320: The computing device identifies each prepayment instruction that is independently identified as having an independent payment status as the first payment instruction group.

[0140] After obtaining an independent identifier, the computing device can determine the grouping strategy for each prepayment instruction based on the corresponding field values. For example, for prepayment instructions with an independent identifier indicating an independent payment status, the computing device can group them based on the invoice, planned payment bank number, company, supplier, supplier address, payment currency, payment method, expected payment date, issuing bank account, payment voucher, payment profile, first payment identifier, and specified invoice deduction.

[0141] The planned payment line number refers to the identifier of the line data in the prepayment instruction, used to distinguish different payment lines within the same prepayment instruction. Designated invoice deduction refers to the process where, during the payment process, a company offsets payments against specific invoices based on actual business circumstances.

[0142] If the prepayment instruction generated by the computing device does not contain a combination of fields identical to the above information, then the prepayment instruction will be grouped separately to form the first payment instruction group.

[0143] S330: The computing device obtains the field value of the amount field of the prepayment instruction in each first payment instruction group.

[0144] After receiving the first payment instruction group, the computing device can read the corresponding field value from the remaining amount field of the prepayment instruction in the first payment instruction group. The computing device can determine the remaining amount field value as the field value corresponding to the prepayment amount field of the payment instruction group, and use the prepayment amount field value as the basis for subsequent fund planning calculation and payment execution.

[0145] S340: The computing device clusters pre-payment instructions that are independently identified as non-independent payment states based on the user identifier and the first payment identifier to obtain at least one group of second payment instructions.

[0146] After obtaining the independent identifier, if the independent identifier is in a non-independent payment state, the computing device can perform clustering based on the content corresponding to the user identifier and the first payment identifier to obtain a second payment instruction group, wherein the user identifier of the pre-payment instruction in the second payment instruction group is the same as the first payment identifier.

[0147] In this embodiment, the user identifier may include the company, supplier, supplier address, payment currency, payment method, expected payment date, bank account number, payment voucher, payment configuration file, and designated invoice for deduction. The computing device may aggregate pre-payment instructions that are independently identified as non-independent payment instructions and whose user identifier and first payment identifier are the same into the same group to form at least one second payment instruction group.

[0148] It should be noted that the clustering rules based on user identifiers and first payment identifiers described above are merely an example provided in this application's embodiments. In practical applications, the computing device may also respond to user input instructions to perform special processing on certain supplier or invoice numbers, such as prioritizing or delaying payment, or requiring other data to be identical before merging. This application will not elaborate on this further.

[0149] It should be understood that during the process of generating the first payment instruction group and the second payment instruction group, the computing device will generate a corresponding group number based on the grouping result. This number can be automatically generated based on the grouping rules defined in the computing device. For example, the group number of the second payment instruction group starts with 20000 and increments, while the group number of the first payment instruction group starts with 80000 and increments.

[0150] Furthermore, pre-payment instructions within each group share the same header data number, which is automatically generated by the computing device based on the group number. This header data number serves as a unique identifier to distinguish different payment instruction groups, and is used for data tracking and management in the subsequent payment order generation process.

[0151] S350: The computing device obtains the sum of the field values ​​of the amount field of the prepayment instruction in each second payment instruction group.

[0152] After receiving the second payment instruction group, the computing device can summarize the field values ​​of the remaining amount field of the prepayment instruction in each payment instruction group based on the group number to obtain the prepayment amount corresponding to each payment instruction group.

[0153] For example, if a second payment instruction group contains three prepayment instructions with remaining amounts of 5,000 yuan, 3,000 yuan and 2,000 yuan respectively, then the prepayment amount of the group is the sum of the values ​​of the remaining amount field, which is 10,000 yuan.

[0154] S360: If the sum of the field values ​​of the amount field of the prepayment instruction in the payment instruction group is zero, the computing device will delete the field value corresponding to the disbursement bank account in the payment instruction group.

[0155] After obtaining the prepayment amount for each payment instruction group, the computing device will check the field value corresponding to that field. If the field value of the prepayment amount is zero, it will be determined that the payment instruction group does not require actual payment, and the system will automatically mark it as an "empty payment group" and archive it.

[0156] The computing device can also clear the issuing bank information corresponding to payment instruction groups with a prepayment amount of zero, including fields such as bank account name, bank account number, bank name, and branch name, and simultaneously update the prepayment instruction header data and line data in the corresponding payment instruction group to ensure the accuracy and security of payment data. At the same time, the computing device will record this processing in a log table for subsequent auditing and tracing.

[0157] In this embodiment of the application, after the computing device generates the payment instruction group, it can store it in the core table. For example, based on the header data number or group number, the header data and row data corresponding to the payment instruction group can be stored in the smart payment pre-payment instruction header table and the smart payment pre-payment instruction row table, respectively, for subsequent use when generating payment orders.

[0158] Upon receiving a payment instruction set, the computing device can automatically trigger a payment order generation task, or it can generate a payment order in response to a user instruction. Before generating the payment order, the computing device can verify and process the generated payment instruction set, facilitating the generation of a corresponding payable payment order.

[0159] Figure 8 This is a schematic diagram of a payment instruction group processing flow provided in an embodiment of this application. The following is in conjunction with… Figure 8 The processing procedure of the payment instruction group by the computing device in the embodiments of this application is illustrated by way of example.

[0160] like Figure 8 As shown, the process of a computing device processing a payment instruction group may include the following steps S401 to S405.

[0161] S401: The computing device determines the payment status of the payment instruction group based on the invoice standard rules.

[0162] In this embodiment of the application, the invoice standard rules, in addition to including conditions for detecting the invoice payment status, may also include rules for verifying the payment status of payment instruction groups, used to determine whether the payment instruction group meets the standard payment status. The verification rules corresponding to the invoice payment status and the detection rules corresponding to the payment status of the payment instruction group can be distinguished through rule encoding.

[0163] Figure 9 This is a schematic diagram of a configuration interface for an invoice standard rule provided in an embodiment of this application. For example... Figure 9 As shown, the configuration interface for invoice standard rules includes a rule query area 91 and a rule display area 92. The rule query area 91 is used to input query conditions to filter specific rules, and the rule display area 92 is used to display a list of rules that meet the conditions and their detailed configuration information. Users can maintain invoice standard rules through this interface, including adding, editing, enabling, or disabling rules.

[0164] For example, the computing device can determine whether a rule is a verification rule for the invoice payment status or a verification rule for the payment status of a payment instruction group by the field value corresponding to the rule code in the rule display area. For instance, a rule code prefixed with INVOICE indicates that the rule is used for invoice payment status verification, while a rule code prefixed with CHECK is used for verification of the payment status of a payment instruction group.

[0165] It should be understood that the process of verifying the payment status of the payment instruction group is similar to the verification logic of determining the invoice payment status in the aforementioned step S201. The difference is that the verification object changes from a single invoice to the entire payment instruction group. The rules used for verification can be distinguished by rule coding, which will not be elaborated here.

[0166] S402: The computing device generates a second payment identifier corresponding to the payment instruction group.

[0167] After obtaining the payment status of each payment, the computing device generates a second payment identifier corresponding to each payment instruction group. The second payment identifier is used to identify the payment status of the payment instruction group. The second payment identifier can include two states: "standard" and "non-standard". For example, a payment instruction group with a standard payment status will generate a second payment identifier of "standard"; a payment instruction group with a non-standard payment status will generate a second payment identifier of "non-standard".

[0168] Correspondingly, after obtaining the payment status, if the payment status is a non-standard payment status, the computing device can generate a corresponding non-standard reason based on the specific conditions in the invoice standard rules triggered by the field values ​​of the payment instruction group, in order to record the factors that cause the payment instruction group to be judged as non-standard.

[0169] S403: The computing device writes the second payment identifier to the corresponding payment instruction group.

[0170] After obtaining the second payment identifier, the computing device can write it into a designated field of the corresponding payment instruction group to achieve data association between the payment status and the payment instruction group.

[0171] S404: The computing device determines negative and positive payment orders based on the field value of the amount field in the payment instruction group.

[0172] After obtaining the second payment identifier for each payment instruction group, the computing device can query the first and second payment instruction groups for payment instruction groups with a prepayment amount less than zero, an independent identifier in a non-independent payment state, and a second payment identifier of "non-standard", and identify them as negative payment orders.

[0173] After receiving a negative payment order, the computing device can determine the corresponding positive payment order based on the user identifier. For example, the computing device can determine any payment instruction group with a field value greater than zero in the prepayment amount field as a positive payment order by considering the company, supplier, supplier address, payment currency, payment method, issuing bank account, second payment identifier, designated invoice deduction, and corresponding independent identifier, and prioritize the one with the largest amount.

[0174] S405: The computing device writes the field value of the target field corresponding to the positive payment slip to the target field corresponding to the negative payment slip.

[0175] After receiving both negative and positive payment orders, the computing device can write the target fields of the positive payment order, such as the expected payment date, payment voucher, payment configuration file, and issuing bank account, as well as the group number and header data number of the positive payment order, into the corresponding fields of the negative payment order, thereby enabling the payment order parameters to conform to the operation.

[0176] The computing device can also record the original group number and header data number of the negative payment slip into the spare field of the negative payment slip to ensure the integrity of the traceability information. Subsequently, the computing device re-aggregates the payment amount according to the updated group number. If the aggregated amount is zero, the issuing bank information under that group is cleared, including the bank account name, bank account number, bank name, and branch name.

[0177] In another embodiment, the computing device can match the non-standard reason of the original negative payment order with the header data number and write it into the newly generated payment instruction group, ensuring that the non-standard status is traceable. The computing device can also store the non-standard reason of the original negative payment order in a core table based on the group number corresponding to the positive payment order, thus establishing a link between the original non-standard record in the non-standard reason table and the new payment order, ensuring that the historical status of the payment instructions can be fully presented during audit tracing.

[0178] S400: The computing device generates a payable payment slip corresponding to each payment instruction group.

[0179] After receiving the processed payment instruction sets, the computing device can generate corresponding payable payment slips based on the content of each payment instruction set. It should be noted that the process of generating payable payment slips can be triggered automatically by the computing device or manually by the user through the graphical interface provided by the computing device.

[0180] Figure 10 This is a schematic diagram of an interface for generating a payable payment slip, provided as an embodiment of this application.

[0181] After the computing device receives the payment instruction set, it can store it in the corresponding core table for backup. For example... Figure 10 As shown in (a), the computing device can respond to the operation command triggered by the user and display the data retrieval interface 1010. The data retrieval interface 1010 includes a summary area 1011 and a conditional filtering area 1012. The summary area 1011 displays the summary information of the current payable payment orders, including parameters such as acquisition time, acquisition status, company code, number of acquired invoices, and number of unprocessed invoices.

[0182] The conditional filtering area 1012 allows users to filter by criteria such as company number, invoice type, invoice number, supplier name, payment date, and due date to locate the corresponding payment instruction group. After the user filters using the conditional filtering area 1012, the computing device can automatically refresh the display content of the summary area 1011 to present the payment instruction group information that meets the filtering criteria, ensuring that the user can quickly locate the target data.

[0183] The computing device can respond to a user's triggering action on the parameter of the number of unprocessed invoices in the summary area 1011, and display... Figure 10 The pending invoice list interface 1020 shown in (b) displays the payment header data and payment line data of all pending invoices associated with the selected payment instruction group. The payment header data may include information such as company number, supplier number, payment amount, payment method, and issuing bank account, while the payment line data includes information such as invoice number, group number, payment amount, and payment mode.

[0184] The computing device can also display the following after the user triggers the "Process" button on the pending invoice list interface 1020: Figure 10 The review interface 1030 shown in (c) displays content similar to the pending invoice list interface 1020, and adds controls for the payment header data and payment line data of the processed invoices, enabling users to perform operations such as modifying, deleting, merging, splitting, counting, and importing invoices into the enterprise management system.

[0185] In this embodiment of the application, when the computing device displays the review interface 1030, it can convert the payment instruction group corresponding to the invoice displayed on the interface into an actual payment instruction group, and store the data therein into core tables such as the intelligent payment header table, intelligent payment line table, intelligent payment header backup table, intelligent payment line backup table, and intelligent payment check record temporary table.

[0186] The smart payment header table and smart payment line table are used to store the header and line-level data of payment instructions to ensure the integrity and traceability of payment information; the smart payment header backup table and smart payment line backup table are used to record the original data before each operation to support subsequent auditing and rollback; the smart payment checklist temporary table is used to temporarily store the payment instructions selected by the user in the review interface until the final confirmation is completed and the automatic execution of the payment process by the computing device is triggered.

[0187] If the user triggers the "Import to Enterprise Management System" control in the review interface 1030, the computing device will respond to the user's operation, automatically importing the reviewed payment instruction data into the enterprise management system and generating a payable payment slip. The computing device can synchronously store the relevant data when generating the payable payment slip into core tables such as the intelligent payment import batch table, intelligent payment import header table, intelligent payment import row table, and intelligent payment log table, ensuring that the entire operation is traceable.

[0188] After the payable payment order is generated, the computing device can also display corresponding payable payment order generation status prompts on other pages to ensure that users can keep track of the processing progress in real time.

[0189] In some embodiments of this application, Figure 10 The interface shown is for display and operation confirmation only. The above operation can be triggered by the user after step S300 or step S405, or it can be automatically triggered by the computing device itself to realize the automatic generation and push of payment slips.

[0190] Figure 11 This is a schematic diagram of an interface for verifying payment slips, provided as an embodiment of this application.

[0191] After generating a payable payment slip, the computing device will automatically initiate a real-time verification process to review the received payment slip for compliance and risk control. After initiating the real-time verification process, the computing device can send the following to the verifier: Figure 11 The payment order details displayed include key fields such as payment order number, payment amount, payee information, and issuing bank, for verification and confirmation. After the verifier reviews the payment according to preset rules and finds no errors, they provide feedback on the approval result through the communication connection with the computing device. The computing device then determines whether to continue the payment process based on this feedback. If the verification passes, the payment API interface is automatically invoked to push the payment instruction to the bank system, and the payment status is updated in real time to the intelligent payment log table. If the verification fails, the reason for the error is marked, and the process is returned to the modification stage, ensuring that every payment complies with internal control requirements and compliance standards.

[0192] It should be understood that, Figure 11 The payment details shown are only an example; in actual applications, they can be flexibly configured according to the actual needs of the enterprise, and this application will not elaborate further.

[0193] Based on the technical solutions provided in the embodiments of this application, the computing device can realize closed-loop management of the entire process from invoice data extraction, pre-payment instruction generation, payment order creation to in-process control verification through automated programs and preset rules, which significantly improves payment efficiency and accuracy.

[0194] Corresponding to the aforementioned embodiments of the payment order generation method, this application also provides an embodiment of a payment order generation system.

[0195] Figure 12 This is a schematic diagram of the structure of a payment order generation system provided in an embodiment of this application.

[0196] like Figure 12 As shown, the payment order generation system 1200 may include an instruction generation module 1210, a field filling module 1220, an instruction grouping module 1230, and a payment order generation module 1240. The payment instruction generation module 1210 is configured to generate a pre-payment instruction based on the pending invoice data corresponding to the received document payment task in response to receiving such a task.

[0197] The field filling module 1220 is configured to fill at least one target field in the pre-payment instruction according to preset field filling rules. The instruction grouping module 1230 is configured to divide the filled pre-payment instruction into at least one payment instruction group according to preset payment grouping rules. The payment order generation module 1240 is configured to generate a payable payment order corresponding to each payment instruction group.

[0198] Figure 13 This is a schematic diagram of a computing device provided in an embodiment of this application.

[0199] like Figure 13 As shown, the computing device 1300 includes a processor 1301 and a memory 1302. Exemplarily, the computing device 1300 may also include a communications interface 1303 and a communications bus 1304.

[0200] The processor 1301, memory 1302, and communication interface 1303 communicate with each other via communication bus 1304. The communication interface 1303 may include a transmitter and receiver for communicating with other devices or communication networks, and may be a wired interface (port), such as a fiber distributed data interface (FDDI) or a gigabit Ethernet interface (GE).

[0201] In some embodiments, the processor 1301 is used to execute program 1305, specifically performing the relevant steps in the payment slip generation method embodiments described above. For example, program 1305 may include program code, which includes computer-executable instructions.

[0202] For example, processor 1301 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement some embodiments of this application. Computing device 1300 may include one or more processors, which may be processors of the same type, such as one or more CPUs; or they may be processors of different types, such as one or more CPUs and one or more ASICs. The CPU may be a single-core CPU or a multi-core CPU.

[0203] In some embodiments, memory 1302 is used to store program 1305. Memory 1302 may include high-speed random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device.

[0204] Specifically, program 1305 can be called by processor 1301 to cause computing device 1300 to execute the payment order generation method.

[0205] Some embodiments of this application provide a computer-readable storage medium storing at least one executable instruction that, when executed on a computing device 1300, causes the computing device 1300 to perform the payment slip generation method described in the above embodiments.

[0206] For example, the computer-readable storage medium can be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device.

[0207] This application provides a chip system in some embodiments, which is applied to a server. The chip system includes one or more interface circuits and one or more processors. The interface circuits and processors are interconnected via lines. The interface circuits are used to receive signals from the server's memory and send signals to the processors, the signals including computer instructions stored in the memory. When the processor executes the computer instructions, the server performs various steps in the payment slip generation method shown in the above-described method embodiments.

[0208] The embodiments described above are merely specific embodiments of this application and are not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the technical solution of this application should be included within the scope of protection of this application.

Claims

1. A method of generating a payment slip, characterized by, The method includes: In response to receiving a document payment task, a prepayment instruction is generated based on the pending invoice data corresponding to the document payment task; According to preset field filling rules, at least one target field in the prepayment instruction is filled; the field filling rules are used to complete the unfilled fields in the prepayment instruction, and the target field includes any unfilled field in the prepayment instruction; According to a preset payment grouping rule, the pre-payment instruction after filling is divided into at least one payment instruction group; the payment grouping rule is used to group the pre-payment instruction after filling by the target field, and each payment instruction group includes at least one pre-payment instruction after filling. Generate a payable payment slip corresponding to each of the payment instruction groups.

2. The method of claim 1, wherein, The step of generating a prepayment instruction based on the pending invoice data corresponding to the document payment task includes: Based on the document payment task, retrieve the invoice data to be paid from the invoice database; Each of the invoices to be paid is processed using a structured method to obtain structured invoice data. The prepayment instruction is generated based on the structured invoice data and payment slip template.

3. The method of claim 2, wherein, The step of filling in at least one target field in the prepayment instruction according to preset field filling rules includes: Retrieve the unfilled fields of the prepayment instruction; Based on the field names corresponding to the required fields in the field filling rules, at least one of the unfilled fields is determined as the target field; the field filling rules include required fields, at least one field filling value corresponding to each target field, and a first mapping relationship; the required fields include at least one of expected payment date, expected disbursement date, disbursement bank account, and payment voucher; the first mapping relationship includes the mapping relationship between the field filling value and the structured invoice data. Based on the structured invoice data in the prepayment instruction and the first mapping relationship, the field filling value corresponding to the target field is determined in the field filling rule; Write the field fill value into the corresponding target field.

4. The method according to any one of claims 1 to 3, characterized in that, Before dividing the filled pre-payment instruction into at least one payment instruction group according to a preset payment grouping rule, the method further includes: Based on preset invoice standard rules, the payment status of the prepayment instruction is determined; the payment status includes standard payment status and non-standard payment status. Based on the payment status corresponding to the prepayment instruction, a first payment identifier corresponding to the standard payment status or the non-standard payment status is generated; Write the first payment identifier to the corresponding prepayment instruction; Based on the field values ​​of the prepayment instructions, negative prepayment instructions and positive prepayment instructions are determined; the field value of the amount field corresponding to the negative prepayment instructions is negative, and the field value of the amount field corresponding to the positive prepayment instructions is positive; the user identifier and the first payment identifier in the negative prepayment instructions are the same as the user identifier and the first payment identifier in the positive prepayment instructions, and the user identifier is used to indicate information such as company, supplier, payment currency, planned payment method, and bank account of the payer; Write the field value of the target field corresponding to the positive prepayment instruction into the target field corresponding to the negative prepayment instruction.

5. The method of claim 4, wherein, The determination of the payment status of the prepayment instruction based on preset invoice standard rules includes: Compare the field values ​​in the prepayment instruction with the preset invoice standard rules; If none of the field values ​​meet the invoice standard rules, then the payment status of the prepayment instruction is the standard payment status; If any of the field values ​​satisfies the invoice standard rules, then the payment status of the prepayment instruction is a non-standard payment status.

6. The method according to claim 4, characterized in that, The step of dividing the filled pre-payment instruction into at least one payment instruction group according to a preset payment grouping rule includes: Obtain the unique identifier in each filled prepayment instruction; the unique identifier is used to identify the payment method corresponding to the prepayment instruction, and the unique identifier includes one of independent payment status and non-independent payment status; Each of the pre-payment instructions, which is independently identified as having an independent payment status, is respectively designated as a first payment instruction group; Obtain the value of the amount field of the prepayment instruction in each of the first payment instruction groups; Based on the user identifier and the first payment identifier, the pre-payment instructions that are independently identified as non-independent payment states are clustered to obtain at least one second payment instruction group; the user identifier and the first payment identifier of the pre-payment instructions in the second payment instruction group are the same; Obtain the sum of the value of the amount field of the prepayment instruction in each of the second payment instruction groups.

7. The method according to claim 6, characterized in that, Before generating a payable payment slip corresponding to each of the payment instruction groups, the method further includes: Based on the aforementioned invoice standard rules, the payment status of the payment instruction group is determined; Generate a second payment identifier corresponding to the payment instruction group; Write the second payment identifier into the corresponding payment instruction group.

8. The method according to claim 6 or 7, characterized in that, Before generating a payable payment slip corresponding to each of the payment instruction groups, the method further includes: Based on the field value of the amount field in the payment instruction group, negative payment orders and positive payment orders are determined; the negative payment order includes the first payment instruction group in which the field value of the amount field is less than zero, or the second payment instruction group in which the field value of the amount field is less than zero, and the user identifier of the negative payment order is the same as the user identifier of the positive payment order; Write the field value of the target field corresponding to the positive payment slip to the target field corresponding to the negative payment slip.

9. The method according to any one of claims 1 to 8, characterized in that, The step of dividing the filled pre-payment instruction into at least one payment instruction group according to a preset payment grouping rule further includes: If the sum of the field values ​​of the amount field of the prepayment instruction in the payment instruction group is zero, then the field value corresponding to the disbursement bank account in the payment instruction group will be deleted.

10. A computing device, characterized in that, include: Processor and memory; The processor and the memory are coupled; the memory is used to store program instructions. The processor is used to execute the program instructions to perform the payment slip generation method as described in any one of claims 1 to 9.

Images