CN117237058A

CN117237058A - Order processing method and related equipment

Info

Publication number: CN117237058A
Application number: CN202311416522.5A
Authority: CN
Inventors: 吕豪
Original assignee: CMB Yunchuang Information Technology Co Ltd
Current assignee: CMB Yunchuang Information Technology Co Ltd
Priority date: 2023-10-30
Filing date: 2023-10-30
Publication date: 2023-12-15

Abstract

The embodiment of the application provides an order processing method and related equipment, which are used for merging a plurality of payment orders so as to improve payment efficiency as much as possible. The method of the embodiment of the application comprises the following steps: responding to a payment request of a payment order of a user, and acquiring payment order data corresponding to the payment order; wherein the payment order data at least comprises a payment type and a payment element of the payment order; determining a merging rule of the payment bill data according to the payment type, and merging the payment bill data based on the merging rule to obtain payment modification data; and modifying the payment modification data according to the payment element, and acquiring statement data so that the user pays the payment order according to the statement data.

Description

Order processing method and related equipment

Technical Field

The embodiment of the application relates to the technical field of internet information, in particular to an order processing method and related equipment.

Background

With the development of computer internet technology, online payment on a system network is a very common phenomenon, and thus, it is becoming more and more important for financial institutions. However, the current system only supports one-stroke payment, if each stroke is required to pay, the payment elements are approximately the same, the same operation is required to be carried out each time, the steps are complicated, and the time is required for confirming and updating the subsequent payment state, so that the efficiency is affected. At the same time, each payment account has a large number of payment records, which is detrimental to funds management.

Disclosure of Invention

The embodiment of the application provides an order processing method and related equipment, which are used for merging a plurality of payment orders so as to improve payment efficiency as much as possible.

An embodiment of the present application provides a method for processing an order, including:

responding to a payment request of a payment order of a user, and acquiring payment order data corresponding to the payment order; wherein the payment order data at least comprises a payment type and a payment element of the payment order;

determining a merging rule of the payment bill data according to the payment type, and merging the payment bill data based on the merging rule to obtain payment modification data;

and modifying the payment modification data according to the payment element, and acquiring statement data so that the user pays the payment order according to the statement data.

Optionally, before the acquiring the payment order data corresponding to the payment order, the method further includes:

acquiring the payment type and the payment element selected by the user in the payment request;

acquiring to-be-combined payment order data aiming at the payment type and the payment element in the payment order;

Determining an operation state identification of the payment sheet data to be combined, and processing the payment sheet data to be combined according to the operation state identification;

and acquiring the payment bill data according to the processed payment bill data to be combined, the payment type and the payment element.

Optionally, the determining the operation state identifier of the payment list data to be combined, and processing the payment list data to be combined according to the operation state identifier includes:

when the operation state is identified as a first operation state, the payment data to be combined are returned, so that the user pushes another payment data to be combined;

when the operation state is identified as a second operation state, modifying the payment data to be combined until the operation state is identified as a third operation state;

and when the operation state is identified as the third operation state, executing the step of acquiring the payment bill data according to the processed payment bill data to be combined, the payment type and the payment element.

Optionally, the determining a merging rule of the payment bill data according to the payment type, and merging the payment bill data based on the merging rule to obtain payment modification data includes:

When the payment list data meets a preset merging condition, determining the merging rule according to the payment type of the payment list data;

determining the payment element of the payment bill data according to the merging rule, and setting a payment identification mark according to the payment element;

classifying the payment bill data meeting the preset merging condition according to the payment identification mark, and storing the payment bill data of the same payment identification mark into a preset storage address;

and merging the payment bill data positioned at the same preset storage address according to the merging rule to generate the payment modification data.

Optionally, the merging the payment bill data located at the same preset storage address according to the merging rule, to generate the payment modification data includes:

determining transaction sum data and application values of the payment bill data positioned at the same preset storage address; wherein the transaction sum data is the sum of transaction data of all the payment bill data, and the use value is a set value corresponding to the payment element;

supplementing the transaction sum data and the use value according to the merging rule to obtain transaction supplement data;

And merging according to the transaction supplementary data and the payment bill data, obtaining the payment modification data, setting the processing state identification of the payment modification data as a first processing state, and setting the processing state identification of the payment bill data as a first merging state.

Optionally, the modifying the payment modification data according to the payment element, to obtain the statement data includes:

determining an operational status identification of the payment modification data;

when the operation state identifier is a first operation identifier, modifying the processing state identifier of the payment modification data into a second processing state, and updating the processing state identifier of the payment bill data corresponding to the payment modification data into a second merging state;

when the operation state identifier is a fourth operation identifier, modifying the payment element, and modifying the payment modification data according to the modified payment element to generate the statement data; wherein the processing state of the payment modification data is identified as the second processing state and the processing state of the payment receipt data is identified as a third consolidated state.

Optionally, after modifying the payment modification data according to the payment element and obtaining the statement data, the method further includes:

determining an operation state identification of the statement data;

when the operation state identifier is a fifth operation identifier, updating the processing state identifier of the payment bill data corresponding to the payment bill data to be a second merging state;

and when the operation state identifier is a sixth operation identifier and the clearing note data is verified, updating the processing state identifier of the payment note data into a fourth merging state.

A second aspect of an embodiment of the present application provides an order processing system, including:

an acquisition unit configured to acquire payment order data corresponding to a payment order of a user in response to a payment request of the payment order; wherein the payment order data at least comprises a payment type and a payment element of the payment order;

the determining unit is used for determining a merging rule of the payment bill data according to the payment type, and merging the payment bill data based on the merging rule to obtain payment modification data;

and the modification unit is used for modifying the payment modification data according to the payment element, and acquiring the statement data so that the user pays the payment order according to the statement data.

The second aspect of the embodiment of the present application provides a method for executing the order processing method described in the first aspect.

A third aspect of an embodiment of the present application provides an order processing apparatus, including:

the device comprises a central processing unit, a memory, an input/output interface, a wired or wireless network interface and a power supply;

the memory is a short-term memory or a persistent memory;

the central processor is configured to communicate with the memory and to execute instruction operations in the memory to perform the order processing method of the first aspect.

A fourth aspect of the embodiment of the present application provides a computer-readable storage medium, which includes instructions that, when executed on a computer, cause the computer to perform the order processing method according to the first aspect.

From the above technical solutions, the embodiment of the present application has the following advantages: according to the order processing method disclosed by the embodiment of the application, firstly, payment order data corresponding to a payment order is obtained in response to a payment request of the payment order of a user; the payment order data at least comprises payment types and payment elements of the payment order; determining a merging rule of the payment bill data according to the payment type, and merging the payment bill data based on the merging rule to obtain payment modification data; and finally, modifying the payment modification data according to the payment elements to obtain the statement data so that the user pays the payment order according to the statement data. Therefore, compared with the one-by-one payment of a plurality of payment orders, the method reduces complicated operation and is simpler. And combining a plurality of payment orders into a final settlement list, and only using the combined settlement list to pay, thereby improving payment efficiency.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for the description of the embodiments will be briefly described below, and it is apparent that the drawings in the following description are only some embodiments described in the present application, and other drawings may be obtained according to these drawings for those of ordinary skill in the art.

FIG. 1 is a schematic flow chart of an order processing method according to an embodiment of the present application;

FIG. 2 is a flow chart of another order processing method according to an embodiment of the present application;

FIG. 3 is a diagram showing an interface of a bill page according to an embodiment of the present application;

FIG. 4 is a diagram showing an interface for adding or modifying an interface according to an embodiment of the present application;

FIG. 5 is a diagram showing an interface of a merge rule add page according to an embodiment of the present application;

FIG. 6 is an interface display diagram of an operation display page according to an embodiment of the present application;

FIG. 7 is an interface display diagram of another operation display page disclosed in an embodiment of the present application;

FIG. 8 is a diagram showing an interface display of statement data, according to an embodiment of the present application;

FIG. 9 is a schematic diagram of an order processing system according to an embodiment of the present application;

Fig. 10 is a schematic structural diagram of an order processing device according to an embodiment of the present application.

Detailed Description

The terms "first," "second," "third," "fourth" and the like in the description and in the claims and in the above drawings, if any, are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate such that the embodiments described herein may be implemented in other sequences than those illustrated or otherwise described herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.

It should be noted that the description of "first", "second", etc. in this disclosure is for descriptive purposes only and is not to be construed as indicating or implying a relative importance or implying an indication of the number of technical features being indicated. Thus, a feature defining "a first" or "a second" may explicitly or implicitly include at least one such feature. In addition, the technical solutions of the embodiments may be combined with each other, but it is necessary to base that the technical solutions can be realized by those skilled in the art, and when the technical solutions are contradictory or cannot be realized, the combination of the technical solutions should be considered to be absent and not within the scope of protection claimed in the present application.

Based on the prior art problems described above, a page is designed to configure the merge rule. Specifically, some basic merging bases are configured, and the user configures own merging rules for different payment types according to own requirements. And secondly, a page is newly added for displaying the manually added or pushed payment bill data, and a user can select the selected payment bill to carry out operations such as merging and returning. When the combination operation is carried out, the selected payment bill data is traversed, all combination rules are obtained, the data consistent with the combination rules are classified into one type, and a new payment bill and own use information are generated. After the data merging is completed, the user can query the merged data on the payment modification page and return and carry out operations on the merged data. If the operation is carried out, the user supplements or modifies the bank elements according to the needs of the user to generate a new statement, then the statement is approved, and finally payment is carried out.

In short, the user selects from the elements preset by the system, and configures different merging rules for different types according to own requirements. And selecting the data to be combined on the interface, classifying the selected data through a combination rule, generating a new payment data by dividing the data into the same type, and generating own use information for each data. And subsequently, operating the newly generated payment data, and supplementing or updating the payment element to generate a new statement to pay.

The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.

It should be noted in advance that the embodiment of the present application is mainly performed on the client. For ease of understanding, this will not be described in detail later.

Referring to fig. 1, fig. 1 is a flow chart of an order processing method according to an embodiment of the application. Including steps 101-103.

101. In response to a payment request for a payment order from a user, payment order data corresponding to the payment order is obtained.

A user submits a payment request for a payment order at a front end interface of the client, whereby the client may obtain payment order data corresponding to the payment order. It is understood that the user needs to import the payment sheet data into the storage space in advance, so that the client can extract the corresponding payment sheet data from the storage space based on the payment request. The payment order data at least comprises payment type and payment element of the payment order.

In one particular embodiment, the payment element includes a plurality of, for example: the payment type may also be one of the payment elements, such as a payer name, a payee account number, a payee name, a data source, a settlement means, a guest number, a predetermined type, a source bill number, a payment account number, a currency, a business number, or a desired payment date. In another description, the payment element is also called a merging element, and details thereof are not described herein. Correspondingly, the payment type, payment account number, currency, enterprise number and expected payment date are combined according to the basis, and the selected elements are needed for each combination rule. It will be appreciated that each payment type has its own configured merge rule. The merge rule contains at least five of these. For example, if there are six merging elements in the merging rule, the corresponding six elements must be the same, and the rest may be different. Therefore, when describing the merging rule in the following description, it can be simply understood that the merging elements satisfied by the merging rule at least include the five elements, which are convenient for the following description and are not repeated in the following description.

102. And determining a merging rule of the payment bill data according to the payment type, and merging the payment bill data based on the merging rule to obtain payment modification data.

After the payment bill data is determined, the corresponding merging rule can be determined according to the payment type of the payment bill data. Thus, the payment sheet data is combined based on the combination rule, and payment modification data is obtained.

In one specific embodiment, the client may obtain a locally set merge rule set, where the merge rule set includes all merge rules preset by the client. Then, the bill data determined in the above is traversed. The payment type of such payment sheet data is determined such that a merge rule corresponding to the payment type is obtained in the merge rule set, whereby the payment sheet data is merged based on the merge rule, resulting in payment modification data.

Based on the above embodiment, in another specific embodiment, the client may combine the payment bill data of the same payment type, so as to implement data combination based on the combination rule corresponding to the payment type. Specifically, the transaction amount in the payment bill data of the same payment type is added to serve as the transaction total amount of the follow-up payment modification data, and then the transaction total amount and other information are supplemented according to the merging rule corresponding to the payment type, so that the payment modification data are generated.

103. And modifying the payment modification data according to the payment elements, and acquiring the statement data so that the user pays the payment order according to the statement data.

When the payment modification data is generated, the payment modification data can be modified according to the payment element, so that the bill data is obtained. Thus, the user can make unified payment for the payment order according to the statement data.

In one particular embodiment, the user may supplement or modify the payment element at the operations page, thereby modifying the payment modification data to corresponding statement data. This will be described in detail later for ease of understanding.

According to the order processing method disclosed by the embodiment, firstly, payment order data corresponding to a payment order is obtained in response to a payment request of the payment order of a user; the payment order data at least comprises payment types and payment elements of the payment order; determining a merging rule of the payment bill data according to the payment type, and merging the payment bill data based on the merging rule to obtain payment modification data; and finally, modifying the payment modification data according to the payment elements to obtain the statement data so that the user pays the payment order according to the statement data. Therefore, compared with the one-by-one payment of a plurality of payment orders, the method reduces complicated operation and is simpler. And combining a plurality of payment orders into a final settlement list, and only using the combined settlement list to pay, thereby improving payment efficiency.

For convenience in describing the order processing method described in the foregoing, please refer to fig. 2, fig. 2 is a flow chart of another order processing method disclosed in the embodiment of the present application. Including steps 201-215.

201. And acquiring payment type, payment elements and payment bill data to be combined selected by the user in the payment request.

Step 201 in this embodiment is similar to step 101 in fig. 1, and detailed description thereof will be omitted herein. However, it should be noted that in this embodiment, the user selects the relevant payment type and payment element from the front end interface of the client, and then the user obtains the to-be-combined payment order data for the payment type and payment element in the payment order by importing the relevant payment order. The payment element may refer to step 101 in fig. 1 for the description of this part, and details thereof will not be described herein.

Based on the above embodiment, further, the payment bill data to be combined may be pushed or manually added by a third party. It is to be understood that when pushing or manually adding the to-be-consolidated bill data by a third party, the to-be-consolidated bill data may be directly understood as bill data described later.

In another specific embodiment, the corresponding payment element is an element of a bill, but not all of the bill elements. The payment list has some empty elements and some filled elements, and the payment list can be selected or filled according to actual needs.

202. And determining the operation state identification of the payment list data to be combined, and processing the payment list data to be combined according to the operation state identification.

Therefore, the operation state identification of the current payment list data to be combined can be determined, and the payment list data to be combined is processed according to the operation state identification.

In one specific embodiment, the to-be-combined payment sheet data to be operated may be selected in the predetermined payment sheet inquiry processing page, and adapted to the corresponding operation state identifier, so as to perform the corresponding operation processing. For easy understanding, please refer to fig. 3, fig. 3 is a diagram showing an interface of a payment bill page according to an embodiment of the present application. Fig. 3 may be understood as the predetermined bill query processing page described in the above. Wherein the page has multiple functions.

Specifically, 1. Query: and inquiring the data of all the payment sheets (the data is derived from data pushed by a third party system or data newly added on an interface; the data state of the payment sheets is divided into pending, combined, approved, paid back or submitted payment and the like). 2. And (3) newly adding: filling in the newly added data of the elements (refer to fig. 4), and the data state is to be processed after the newly added data is completed. 3. And (3) importing: and newly adding data through the template, downloading the imported excel template, filling elements (same as elements of the newly added button popup frame page) according to requirements, clicking for importing, and taking the newly added data as a data state to be processed. 4. Modifying; and manually modifying the data to be processed and the played back of the newly added and imported buttons, wherein the interface is the same as the newly added bullet frame page. The original data state is to be processed, and the state is to be processed; the original data state is returned, and a piece of data to be processed is newly added on the basis of original data modification. 5. And (3) combined payment: after the data to be processed is checked, merging the checked data according to a merging rule (refer to fig. 5), wherein the merged state of the data is merged; the consolidated data is payment modification data (the payment modification data state is now pending) and is viewed and manipulated on another page (see fig. 6). 6. And (5) returning: the data to be processed is put back, and the state of the data after put back becomes put back. 6. Downloading an import template: and downloading an excel template for data import. For ease of understanding, a detailed description is not provided herein.

As can be seen from fig. 3, in this page, there are a plurality of payment elements (or merging elements) such as organization names, collection account numbers, factory names, line numbers, payment amounts, etc., based on the left part of fig. 3, it can be seen that the payment sheet data to be merged to be operated (operations such as recall, modification, merging, etc. can be performed) can also be selected, and then step 203, step 204, or step 205 can be performed based on different operation types.

203. And when the operation state is identified as the third operation state, acquiring the payment bill data according to the processed payment bill data to be combined, the payment type and the payment element.

And when the operation state identifier is the third operation state, acquiring the payment bill data according to the processed payment bill data to be combined, the payment type and the payment element.

In one particular embodiment, the third operating state may be understood as the merge operation described in the foregoing. Specifically, if the merging operation is selected, the payment sheet data to be merged may be adapted to the payment type and the payment element, so as to be classified into a specific payment type and payment element, thereby obtaining the payment sheet data, and step 206 is performed.

Further, in another embodiment, if the new payment bill data is pushed by a third party (other system), step 206 may be performed. However, if the newly added bill data is manually added, reverse verification is required. After verification is passed, step 206 may be performed. If the reverse verification is not passed, the third party system is required to pull the relevant payment bill data and update the reverse verification information and the payment information, thereby performing step 206.

204. When the operation state is identified as the first operation state, the data of the payment list to be combined is returned, so that the user pushes the data of another payment list to be combined.

When the operation state is identified as the first operation state, the data of the payment list to be combined needs to be paid back, so that the user pushes the data of another payment list to be combined. It should be understood that in another embodiment, the payment bill data to be combined at this time may also be understood as payment bill data, that is, payment bill data that is pushed directly or added manually by a third party. It should be noted that, the payment list data to be combined may not be adapted to the payment type or the payment element, and the payment list data to be combined at this time is also payment list data.

In one embodiment, the first operating state is the recall operation described above. Specifically, the state of the payment bill to be combined with the payment bill data is updated to be paid back, and the user pushes the payment bill again according to the needs of the user.

205. And when the operation state is identified as the second operation state, modifying the payment list data to be combined until the operation state is identified as the third operation state.

When the operational status is identified as the second operational status, then modification of the to-be-consolidated payment order data is required so that when the associated operational status is identified as the third operational status, then step 203 may be performed.

In one specific embodiment, the second operation state may be understood as the modification operation described in the foregoing, and the user may modify the manually added data. Specifically, for the manually added data, the data may be directly understood as the payment bill data or payment bill data to be combined, specifically depending on whether the adaptation or modification is performed according to the payment element or payment type. For easy understanding of the manual new data, refer to fig. 4, and fig. 4 is an interface display diagram of a new or modified interface according to an embodiment of the present application. Specifically, the user may manually add or select the relevant payment type or payment element in the display interface of fig. 4, and the content selected or added by the user is not limited herein. Specifically, for bill data that completes the addition or modification, step 203 may be performed when the operation status is identified as merge.

206. When the payment bill data meets the preset combination condition, determining a combination rule according to the payment type of the payment bill data, determining a payment element of the payment bill data according to the combination rule, and setting a payment identification mark according to the payment element.

And obtaining all the merging rules, determining the corresponding merging rules according to the payment types of the payment bill data when the payment bill data meets the preset merging conditions, obtaining the payment elements of each payment bill data according to the merging rules, and setting the corresponding payment identification marks according to the payment elements.

In one specific embodiment, all the payment list data in the steps are traversed, so that whether each payment list data meets the combination requirement is judged, when the payment list data meets the combination requirement, a combination rule is obtained through the payment type of the payment list data, then a value corresponding to each payment element of each payment list data is obtained according to the combination rule, and the value is assembled into a mark.

Based on the above embodiment, it should be noted that, the value corresponding to each payment element is the usage value, and the relevant combination requirement can be understood as whether the corresponding combination rule is satisfied, for example, whether the relevant payment element includes the selected element, whether the relevant payment data is legal, or the like. In particular, there is no limitation to the combined requirements.

Correspondingly, the sources of the relevant use values are in particular:

step 1: whether the preset purpose exists or not is searched according to certain elements of the payment bill data. Such as the payment organization and the customer number for certain elements. At this time, the payment organization in the payment bill data is 0001, the number of the guest is 1001, whether 0001-1001 has the corresponding preset use or not is checked, if yes, the preset is taken, otherwise, the step 2 is carried out.

Step 2: and taking a certain element in the payment bill as a use value according to the certain element of the payment bill data. For example, some elements are customer numbers, and some elements are source list numbers. At this time, the number 0002 of the customer in the bill is the same as the number of the customer, and the value of the source bill number in the bill data is used as the value of the application, otherwise, step 3 is performed.

Step 3: and taking a certain element in the payment bill as a use value according to the payment type of the payment bill data. For example, the payment type of the payment bill data is payment A, and a certain element is a summary field. At this time, the payment type in the payment bill is payment a, and the value of the abstract in the payment bill data is used as the value of the application if the payment type is the same as the set payment type, otherwise, step 4 is performed.

Step 4: a certain element in the payment sheet is taken as a use value according to a predetermined type of the payment sheet data. For example, the predetermined type of the bill data is Z, and a certain element is a summary field. When the predetermined type in the bill is Z, the same as the predetermined type is set, the value of the abstract in the bill data is used as the value of the application, otherwise, step 5 is performed.

Step 5: and acquiring a certain element of the bill as a use value according to the type of the customer, the service sign and the data source. For example, when the payment ticket data vendor type is C, the service flag is not 03 or 04, the predetermined type is not Z, and the data source is not OTH, then a certain element is the recipient account name. The account name of the receipt of the payment sheet element is processed as the use value (the account name of the receipt of the payment sheet element is "account of some kind", and "pay account of some kind or the like" is used as the use value), otherwise, the process proceeds to step 6.

Step 6: and acquiring a certain element of the bill as a use value according to the number of the customer, the service sign and the data source. For example, when the bill of payment data is numbered ZZZZZZZ and the business flag is 04, the predetermined type is not Z, and the data source is not OTH, a certain element is a summary. If the digest of the bill element is processed as the usage value (if the digest of the bill element is "account" and "account is paid" is used as the usage value), step 7 is performed.

Step 7: the characteristic value is used as a usage value according to the payment type, the service sign, the customer type, the preset type and the data source. For example, when the payment bill data service type is service D, the service flag is 03, the customer type is E or P, the predetermined type is not Z, and the data source is not OTH, the "proxy" is used as the usage value, otherwise, step 8 is performed.

Step 8: the payment bill is retrieved as a usage value based on the data source. For example, when the bill data source is OTH, a certain element is a summary. In this case, the data source in the bill is OTH, and the same as the set data source, the value of the abstract in the bill data is used as the value of the application.

Based on the usage values described in the above, the relevant usage values are assembled into one sign, i.e. a payment identity.

207. Classifying the payment bill data meeting the preset merging condition according to the payment identification mark, and storing the payment bill data of the same payment identification mark into a preset storage address.

Thus, based on step 206, the payment bill data satisfying the preset merge condition is classified according to whether the payment is marked, so that the payment bill data of the same payment identification is stored in the preset storage address.

In one specific embodiment, the payment bill data selected in the foregoing description is classified according to the flags, and the flags are placed in the same array in a consistent manner, and the corresponding array may be understood as the same bank or the same storage address, which is not limited herein.

208. And determining transaction sum data and application values of the payment bill data positioned at the same preset storage address, and supplementing the transaction sum data and the application values according to the merging rule to obtain transaction supplementary data.

Then, the payment bill data at the same preset storage address can be combined according to the combination rule to generate payment modification data. Specifically, the transaction sum data and the use value of the payment bill data at the same preset storage address are determined, and the transaction sum data and the use value are supplemented according to the combination rule to obtain transaction supplementary data. Wherein the transaction total data is the sum of transaction data of all payment bill data.

In one particular embodiment, all transaction amounts in the selected payment sheet data are added as the total amount of the new data. And then supplementing the generation purpose and other information according to the merging rule to generate new data, namely transaction supplementing data. Specifically, after the payment receipt data is determined, relevant transaction supplemental data may be generated based on the usage value (generation usage or other information) described in step 206.

209. And combining the transaction supplementary data and the payment bill data to obtain payment modification data, and setting the processing state identification of the payment modification data as a first processing state, and setting the processing state identification of the payment bill data as a first combining state.

Based on step 208, the transaction supplemental data and the payment receipt data are combined to obtain payment modification data. Then, the processing state identification of the payment modification data is set as a first processing state, and the processing state identification of the payment sheet data is set as a first merging state.

For easy understanding, refer to fig. 5, and fig. 5 is a diagram showing an interface of a merge rule add page according to an embodiment of the present application. The left side is the optional merging basis, and the right side is the final merging basis. The data is consolidated according to the consolidation rules described in fig. 5, whereby payment modification data is generated based on the consolidated payment elements. At this time, after the bill of payment is merged, the new payment modification data state is set to be in process, and the state of the bill of payment is set to be merged. It will be appreciated that at this point the first processing state is in process and the first merge state is merged. For ease of understanding and description, this will not be described in detail later.

210. An operational status identification of the payment modification data is determined.

An operational status identification for the payment modification data is then determined. Thus, step 211 or step 212 is performed according to the operation state identification.

In one particular embodiment, the payment modification data is manipulated (may be manipulated: back or done) in the payment modification page selection of newly generated payment data (i.e., payment modification data). Specifically, referring to fig. 6, fig. 6 is an interface display diagram of an operation display page according to an embodiment of the present application. As can be seen from fig. 6, the user can select payment order data over a period of time in the interface, wherein the corresponding payment elements can be selected so that the operational status identification of the payment modification data can be modified based on the relevant query conditions. The functions are described below for ease of understanding. Querying: all payment modification data (data state pending or processed) is queried. And (5) carrying out: operating the payment modification data to be processed, supplementing elements or modification data by a bullet frame (see fig. 7), and finally generating the bill data (see fig. 8). And (5) returning: and carrying out a return operation on the payment modification data to be processed.

211. When the operation state identifier is the fourth operation identifier, the payment element is modified, and the payment modification data is modified according to the modified payment element, so that the statement data is generated.

Thus, when the operation state identifier is the fourth operation identifier, the payment element is modified, so that the payment modification data is modified according to the modified payment element, and the statement data is generated.

In one particular embodiment, the corresponding fourth operation identifier may be understood as a sponsor. The customer supplements or modifies the payment element on the page to generate new statement data. At this time, the processing state of the payment modification data is identified as the second processing state, and the processing state of the payment sheet data is identified as the third merge state. It will be appreciated that the second processing state is processed and the third merge state is under approval. Specifically, the update payment modification data is processed, and the data of the payment bill is in approval. Then, step 213 is performed.

Referring to fig. 8, fig. 8 is a diagram showing an interface of the bill data according to the embodiment of the present application. As can be seen from fig. 8, the user can select the statement data within a period of time in the interface, wherein the corresponding payment element can be selected, so that the operation status identification of the statement data can be modified based on the relevant query condition. For ease of understanding, the relevant functions are described below. Inquiring; and inquiring all the bill data. Overrule: and the approval of the statement is denied. By: after the approval of the bill passes, some logic is carried out, and finally the bill is paid to the bank, and the state of the bill is changed into submitted payment. It will be appreciated that the statement data may be subject to other operations such as revocation.

212. When the operation state identifier is the first operation identifier, modifying the processing state identifier of the payment modification data into a second processing state, and updating the processing state identifier of the payment bill data corresponding to the payment modification data into a second merging state.

Thus, when the operation state identifier is the first operation identifier, the processing state identifier of the payment modification data is modified to the second processing state, and the processing state identifier of the payment sheet data corresponding to the payment modification data is updated to the second merging state.

In one specific embodiment, the first operation identifier is a return, specifically, the processing state of the payment modification data is updated to be processed, and the merging state of the corresponding payment bill data is updated to be the return, so that the client performs the subsequent operation according to the own needs. It will be appreciated that the second merge state is a callback.

213. And determining the operation state identification of the bill data.

Based on step 211, an operational status identification for the statement data is determined. Thus, depending on the operational status identification, either step 214 or step 215 is performed.

In one particular embodiment, the newly generated statement data is manipulated (operable: revoked or approved, etc.) at the statement-related page. Referring specifically to fig. 8, step 214 or step 215 is then performed based on the associated operating state identification.

214. And when the operation state identifier is the sixth operation identifier and the clearing data passes the checking, updating the processing state identifier of the payment bill data into a fourth merging state.

Thus, when the operation state identifier is the sixth operation identifier and the clearing data passes the audit, the processing state identifier of the payment bill data is updated to the fourth merging state.

It will be appreciated that the sixth operation is identified as approval and the fourth merge state is committed. Specifically, if the operation state identifier passes the approval, it may be determined whether to make bank payment, if the bank payment is selected, the bank payment is made, and the state of the related data is updated, for example, the state identifier of the payment bill data is set to be submitted.

Correspondingly, if the bank-enterprise payment is not selected, off-line payment is carried out, and correspondingly, after the payment is completed, the state identifier of the payment bill data can be set as submitted.

215. When the operation state identifier is the fifth operation identifier, the processing state identifier of the bill data corresponding to the settlement data is updated to the second merge state.

Thus, when the operation state identifier is the fifth operation identifier, the processing state identifier of the bill data corresponding to the settlement data is directly updated to the second merge state.

Specifically, the fifth operation is identified as canceling or overruling the approval, whereby the status of the synchronous update payment sheet data is identified as having been paid back if the canceling or overruling is selected.

According to the order processing method disclosed by the embodiment, the data with the same payment account and elements are combined through a certain rule to generate one or more payment data, and each data generates application information according to own configuration, so that the operation steps are reduced, and the fund management is facilitated. Meanwhile, if the follow-up payment rules are changed, the merging rules can be adjusted in time, so that the method is more efficient and concise. In short, the merge rules can be custom configured to make the merger of payments. Compared with the way that a plurality of repeated data are paid one by one, the method reduces complicated operation and is simpler. Meanwhile, a plurality of pays are combined with one or a plurality of pays, and only the combined data is concerned, so that the payment efficiency is improved. And a plurality of payments are combined with one or a plurality of payments, so that the fund management is facilitated.

It should be understood that, although the steps in the flowcharts related to the embodiments described above are sequentially shown as indicated by arrows, these steps are not necessarily sequentially performed in the order indicated by the arrows. The steps are not strictly limited to the order of execution unless explicitly recited herein, and the steps may be executed in other orders. Moreover, at least some of the steps in the flowcharts described in the above embodiments may include a plurality of steps or a plurality of stages, which are not necessarily performed at the same time, but may be performed at different times, and the order of the steps or stages is not necessarily performed sequentially, but may be performed alternately or alternately with at least some of the other steps or stages.

If the scheme involves sensitive information (e.g., user information, business information), it should be noted that the collection, use and handling of the sensitive information requires compliance with laws and regulations of the relevant country and region, and needs to be performed with approval or consent of the corresponding subject (e.g., user or business, etc.).

Referring to fig. 9, fig. 9 is a schematic diagram of an order processing system according to an embodiment of the application.

An acquisition unit 901 for acquiring payment order data corresponding to a payment order in response to a payment request of the payment order of a user; the payment order data at least comprises payment types and payment elements of the payment order;

a determining unit 902, configured to determine a merging rule of the payment bill data according to the payment type, and merge the payment bill data based on the merging rule to obtain payment modification data;

the modifying unit 903 is configured to modify the payment modification data according to the payment element, and obtain the statement data, so that the user pays for the payment order according to the statement data.

Illustratively, the system further comprises:

an obtaining unit 901, configured to obtain a payment type and a payment element selected by a user in a payment request;

The acquiring unit 901 is further configured to acquire to-be-combined payment order data corresponding to a payment type and a payment element in a payment order;

the determining unit 902 is specifically configured to determine an operation status identifier of the payment instrument data to be consolidated, and process the payment instrument data to be consolidated according to the operation status identifier.

Illustratively, the system further comprises: an execution unit 904;

an execution unit 904, configured to, when the operation state is identified as the first operation state, send back the payment data to be consolidated, so that the user pushes another payment data to be consolidated;

the modifying unit 903 is specifically configured to modify the payment to be consolidated bill data when the operation state is identified as the second operation state, until the operation state is identified as the third operation state;

the execution unit 904 is further configured to execute the step of obtaining the payment bill data according to the processed payment bill data to be combined, the payment type and the payment element when the operation state is identified as the third operation state.

Illustratively, the system further comprises: a classification unit 905 and a generation unit 906;

a determining unit 902, specifically configured to determine a merging rule according to a payment type of the payment bill data when the payment bill data meets a preset merging condition;

A determining unit 902, configured to determine a payment element of the payment bill data according to the combining rule, and set a payment identification flag according to the payment element;

the classifying unit 905 is configured to classify the payment bill data meeting the preset combining condition according to the payment identifier, and store the payment bill data of the same payment identifier into the preset storage address;

the generating unit 906 is specifically configured to combine the payment bill data located at the same preset storage address according to the combination rule, and generate payment modification data.

Illustratively, the system includes:

a determining unit 902, configured to determine transaction sum data and usage value of the payment bill data located at the same preset storage address; the transaction sum data is the sum of transaction data of all payment bill data, and the application value is a set value corresponding to the payment element;

the acquiring unit 901 is specifically configured to supplement the transaction sum data and the usage value according to the merge rule, and acquire transaction supplemental data;

the obtaining unit 901 is further configured to combine the transaction supplementary data and the payment bill data, obtain payment modification data, and set a processing state identifier of the payment modification data as a first processing state, and a processing state identifier of the payment bill data as a first combined state.

Illustratively, the system includes:

a determining unit 902, specifically configured to determine an operation status identifier of the payment modification data;

the modifying unit 903 is specifically configured to modify the processing state identifier of the payment modification data into a second processing state when the operation state identifier is the first operation identifier, and update the processing state identifier of the payment bill data corresponding to the payment modification data into a second merging state;

the modifying unit 903 is further configured to modify the payment element when the operation status identifier is a fourth operation identifier, and modify the payment modification data according to the modified payment element, so as to generate statement data; wherein the processing state of the payment modification data is identified as a second processing state and the processing state of the payment receipt data is identified as a third consolidated state.

Illustratively, the system further comprises: an updating unit 907;

a determining unit 902, configured to determine an operation status identifier of the statement data;

an updating unit 907 for updating the processing state identification of the bill data corresponding to the settlement data to the second consolidated state when the operation state identification is the fifth operation identification;

the updating unit 907 is further configured to update the processing status identifier of the bill data to a fourth consolidated status when the operation status identifier is the sixth operation identifier and the bill data is approved.

Referring to fig. 10, a schematic structural diagram of an order processing device according to an embodiment of the present application includes:

a central processor 1001, a memory 1005, an input/output interface 1004, a wired or wireless network interface 1003, and a power supply 1002;

memory 1005 is a transient memory or persistent memory;

the central processor 1001 is configured to communicate with the memory 1005 and to execute the instruction operations in the memory 1005 to perform the order processing method in the embodiment shown in fig. 1 or fig. 2 described above.

The embodiment of the application also provides a chip system, which is characterized in that the chip system comprises at least one processor and a communication interface, the communication interface and the at least one processor are interconnected through a line, and the at least one processor is used for running a computer program or instructions to execute the order processing method in the embodiment shown in the foregoing fig. 1 or fig. 2.

It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, which are not repeated herein.

In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in part or all of the technical solution or in part in the form of a software product stored in a storage medium, including instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a read-only memory (ROM), a random access memory (RAM, random access memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

Claims

1. A method of order processing, the method comprising:

2. The order processing method of claim 1, wherein the acquiring payment order data corresponding to the payment order comprises:

acquiring to-be-combined payment order data corresponding to the payment type and the payment element in the payment order;

3. The order processing method according to claim 2, wherein the determining the operation status identifier of the payment sheet data to be consolidated and processing the payment sheet data to be consolidated according to the operation status identifier includes:

4. The order processing method according to claim 1, wherein the determining the merging rule of the payment sheet data according to the payment type, and merging the payment sheet data based on the merging rule, to obtain payment modification data, includes:

5. The order processing method according to claim 4, wherein the merging the payment sheet data located at the same preset storage address according to the merging rule to generate the payment modification data includes:

6. The order processing method according to claim 1, wherein the modifying the payment modification data according to the payment element, obtaining the clearing order data, includes:

7. The order processing method according to claim 1, wherein said modifying said payment modification data according to said payment element, after obtaining settlement sheet data, the method further comprises:

determining an operation state identification of the statement data;

8. An order processing system, the system comprising:

9. An apparatus, the apparatus comprising:

the memory is a short-term memory or a persistent memory;

the central processor is configured to communicate with the memory and to execute instruction operations in the memory to perform the order processing method of any of claims 1 to 7.

10. A computer readable storage medium comprising instructions which, when run on a computer, cause the computer to perform the order processing method of any of claims 1 to 7.