WO2023226799A1

WO2023226799A1 - Invoice request processing method, apparatus and device

Info

Publication number: WO2023226799A1
Application number: PCT/CN2023/094046
Authority: WO
Inventors: 舒杰
Original assignee: 支付宝(杭州)信息技术有限公司
Priority date: 2022-05-27
Filing date: 2023-05-12
Publication date: 2023-11-30
Also published as: CN114997938A

Abstract

Disclosed in embodiments of the present description are an invoice request processing method, apparatus and device. The solution comprises: after obtaining an invoicing request message for requesting a first participation party of a target transaction to provide invoice information corresponding to the target transaction to a second participation party, determining whether the first participation party provides the invoice information within a first duration after an initiation time of the invoicing request message; and if not, processing the first participation party.

Description

An invoice request processing method, device and equipment

Technical field

The present application relates to the field of invoice technology, and in particular to an invoice request processing method, device and equipment.

Background technique

With the continuous advancement of Internet technology, e-commerce has developed rapidly. People gradually began to conduct various business activities based on transaction applications and payment applications in the open network environment of the Internet to realize transactions between consumers and merchants. Currently, after consumers complete a transaction with a merchant, they may need to ask the merchant to provide the consumer with corresponding invoice information to ensure the rights and interests of the consumer. However, some merchants delay providing invoices.

Based on this, how to improve merchants' processing efficiency of invoice requests has become an urgent technical issue that needs to be solved.

Contents of the invention

The embodiments of this specification provide an invoice request processing method, device and equipment, which can improve merchants' processing efficiency of invoice requests.

In order to solve the above technical problems, the embodiment of this specification is implemented as follows: The embodiment of this specification provides an invoice request processing method, including: obtaining an invoicing request message for a target transaction; the invoicing request message is used to request the target The first participant in the transaction provides the invoice information corresponding to the target transaction to the second participant; determines the initiation time of the invoicing request message; and determines whether the first participant provides the invoice information to the second participant within a first period of time after the initiation time. The second participant provides the invoice information and obtains a first judgment result; if the first judgment result indicates that the first participant does not submit a request to the second participant within the first period of time after the initiation time, If the first party provides the invoice information, the first party will be processed.

An invoice request processing device provided by an embodiment of this specification includes: a first acquisition module, used to obtain an invoicing request message for a target transaction; the invoicing request message is used to request a first participating direction of the target transaction and a second Participants provide invoice information corresponding to the target transaction; a determination module is used to determine the initiation time of the invoicing request message; a first judgment module is used to determine whether the first participant is after the initiation time The invoice information is provided to the second participant within the first period of time, and a first judgment result is obtained; a processing module is configured to: if the first judgment result indicates that the first participant has not entered after the initiation time The invoice information is provided to the second party within the first period of time, and then the first party is processed.

An invoice request processing device provided by an embodiment of this specification includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores information that can be executed by the at least one processor. instructions that are executed by the at least one processor to enable the at least one processor to:

Obtain the invoicing request message for the target transaction; the invoicing request message is used to request the first participant of the target transaction to provide the invoice information corresponding to the target transaction to the second participant; determine the initiation time of the invoicing request message ; Determine whether the first participant provides the invoice information to the second participant within the first time period after the initiation time, and obtain a first judgment result; if the first judgment result indicates that the third If a participant fails to provide the invoice information to the second participant within the first period of time after the initiation time, the first participant will be processed.

At least one embodiment provided in this specification can achieve the following beneficial effects: after obtaining an invoicing request message for requesting a first participant of a target transaction to provide invoice information corresponding to the target transaction to a second participant, determine whether The first participant provides the invoice information within the first time period after the initiation time of the invoicing request message. If not, the first participant is processed. This will help the first party to provide the invoice corresponding to the target transaction to the second party within the specified time period, and reduce the delay in providing invoices by the first party. In order to improve the first party's processing efficiency of the second party's invoice request, it is also conducive to improving the first party's response rate to the second party's invoice request to ensure that the second party obtains the target Invoice for transaction.

Description of the drawings

In order to explain the technical solutions in the embodiments of this specification more clearly, the drawings needed to be used in the description of the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some implementations recorded in this application. For example, for those of ordinary skill in the art, other drawings can be obtained based on these drawings without exerting creative efforts.

Figure 1 is a schematic diagram of an application scenario of an invoice request processing method provided by an embodiment of this specification;

Figure 2 is a schematic flowchart of an invoice request processing method provided by an embodiment of this specification;

Figure 3 is a schematic diagram of a swim lane flow corresponding to the invoice request processing method in Figure 2 provided by an embodiment of this specification;

Figure 4 is a schematic structural diagram of an invoice request processing device corresponding to Figure 2 provided by the embodiment of this specification;

FIG. 5 is a schematic structural diagram of an invoice request processing device corresponding to FIG. 2 provided by an embodiment of this specification.

Detailed ways

In order to make the purpose, technical solutions and advantages of one or more embodiments of this specification more clear, the technical solutions of one or more embodiments of this specification will be clearly and completely described below in conjunction with specific embodiments of this specification and the corresponding drawings. . Obviously, the described embodiments are only some of the embodiments of this specification, but not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts fall within the scope of protection of one or more embodiments of this specification.

The technical solutions provided by each embodiment of this specification will be described in detail below with reference to the accompanying drawings.

In related technologies, consumers and merchants can conduct transactions based on transaction applications and payment applications. Consumers can also communicate with merchants on invoice issuance matters to agree on the invoice information that merchants need to provide. However, some merchants delay or even refuse to provide invoices, which not only seriously affects the rights and interests of consumers, but also affects consumers' experience in using e-commerce technology. Based on this, how to improve merchants' processing efficiency for consumers' invoice requests to ensure that consumers can quickly obtain invoices has become an urgent problem to be solved.

In order to solve the deficiencies in related technologies, this solution provides the following embodiments: Figure 1 is a schematic diagram of an application scenario of an invoice request processing method provided by the embodiment of this specification.

As shown in Figure 1, the device 101 of the second participant (for example, a consumer) of the target transaction can be equipped with a payment application and a transaction application, and the second participant can communicate with the first participant (for example, based on the payment application and transaction application). For example, a merchant) conducts a target transaction, and sends an invoicing request message for the target transaction to the target server 102; the invoicing request message can be used to request the first participant to provide the invoice information corresponding to the target transaction to the second participant. .

The target server 102 may generate invoice order information according to the invoicing request message, and send the invoice order information to the device 103 of the first participant, so that the first participant knows and processes the invoice order information, thereby responding to the invoicing request. The message provides invoice information to the second party.

The target server 102 may also determine the initiation time of the invoicing request message; and determine whether the first participant provided the invoice information to the second participant within the first period of time after the initiation time. If so, then There is no need to process the first party and jump to the end; if not, the first party can be processed. The target server 102 may also send the processing result for the first participant to the device 103 of the first participant, so that the first participant knows the processing result.

Next, an invoice request processing method provided in the embodiments of the specification will be described in detail with reference to the accompanying drawings.

Figure 2 is a schematic flowchart of an invoice request processing method provided by an embodiment of this specification. From a program perspective, the execution subject of this process can be the target server, or the application program installed on the target server. This item The target server may be a server of a target application, wherein the target application may include: a payment application used by the second participant to pay for the target transaction, or a transaction application used by the second participant to perform the target transaction.

As shown in Figure 2, the process may include the following steps 202 to 210.

Step 202: Obtain an invoicing request message for the target transaction; the invoicing request message is used to request the first participant of the target transaction to provide the invoice information corresponding to the target transaction to the second participant.

In the embodiment of this specification, the first participant is usually a merchant, and the second participant is usually a consumer. After a target transaction occurs between the second participant and the first participant, the second participant may request the first participant to provide an invoice corresponding to the target transaction, so that the target server obtains the invoicing request message for the target transaction.

Among them, invoice can refer to the business vouchers issued and collected by units or individuals when purchasing and selling goods, providing or receiving services, and engaging in other business activities. Under normal circumstances, the printing, purchase, issuance, acquisition, custody, and cancellation of invoices will be managed and supervised by an authoritative organization.

In practical applications, the second party can either request the first party to issue an invoice for all the transaction contents of the target transaction, or it can also request the first participant to issue an invoice for part of the transaction contents of the target transaction. There is no specific limit on this. .

Step 204: Determine the initiation time of the invoicing request message.

In the embodiment of this specification, the target server needs to identify whether the first participant has provided the invoice corresponding to the target transaction to the second participant within a specified time period. Therefore, it needs to determine the start time and end time of the specified time period. Normally, the initiation time of the invoicing request message can be used as the starting time of the designated time period, and the time after the initiation time and separated by a first length of time can be used as the end time of the designated time period. Among them, the first duration can be preset according to actual needs, and there is no specific limit on this. For example, the first duration is 10 days, 15 days, etc.

Step 206: Determine whether the first participant provides the invoice information to the second participant within the first time period after the initiation time, and obtain a first judgment result.

In the embodiment of this specification, the first participant can use the merchant client to provide the invoice information to the second participant, or the first participant can upload information on the merchant client to indicate that it has provided the invoice information to the second participant. Proof information of the invoice information is provided, so that the target server can determine whether the first participant provided the invoice information to the second participant within a first time period after the initiation time. Among them, the merchant client can be an application provided by the service provider of the transaction application to the first party for use to manage the target transaction, or it can be a payment application used by the second party to pay for the target transaction, or, The merchant client can also be an application or applet developed and deployed by the first party to manage target transactions; in actual applications, the merchant client in the form of an applet can be installed in a transaction application or payment application.

Step 208: If the first judgment result indicates that the first participant has not provided the invoice information to the second participant within the first period of time after the initiation time, perform a check on the first participant. deal with.

In the embodiment of this specification, if it is determined that the first participant does not provide the invoice information to the second participant within the first period of time after the initiation time, it usually indicates that the first participant has delayed An invoice is provided so that the first party can be processed according to a preset processing policy. Among them, the preset processing strategy can be set according to actual needs, and there is no specific limit on this. For example, the preset processing strategy may be to punish the first party, and/or compensate the second party, etc., thereby prompting the first party to provide invoices to the second party as scheduled to ensure that the first party Efficiency in processing invoice requests.

In the embodiment of this specification, step 206 may also include: Step 210: If the first judgment result indicates that the first participant provides the second participant with the Invoice information, you can prohibit processing of the first party and jump to the end. This is because, in this case, it can usually be said that the first party provided the invoice as scheduled within a reasonable period, so there is no need to process the first party and no compensation to the second party. At the same time, since the first party has provided the invoice to the second party, it can be indicated that the invoice order for the target transaction has been completed, that is, the response to the invoice request message has been completed, so that it can jump to the end.

In the method in Figure 2, after obtaining an invoicing request message for requesting the first participant of the target transaction to provide the invoice information corresponding to the target transaction to the second participant, if it is determined that the first participant is in the If the invoice information is not provided within the first period of time after the initiation time of the invoicing request message, the first party may be processed. This will help the first participant provide the invoice corresponding to the target transaction to the second participant within the specified time period, reduce the delay in providing invoices by the first participant, and improve the first participant's response to the second participant's invoice request. Processing efficiency, and at the same time, it is also conducive to improving the response rate of the first party to the second party's invoice request, so as to ensure that the second party obtains the invoice of the target transaction.

Based on the method in Figure 2, the embodiments of this specification also provide some specific implementations of the method, which will be described below.

In the embodiment of this specification, there are many ways to execute the target transaction between the second participant and the first participant.

Transaction method one

The target transaction may be a transaction initiated by the second party using the transaction application with the first party. Specifically, the second party may call the payment application based on the transaction application to utilize the personal resources at the payment application to make payment for the target transaction. Wherein, the transaction application includes: an e-commerce platform and a small program deployed by the first party at the payment application.

Transaction method two

Target transactions can be offline transactions. Specifically, the payment application can be used to generate a payment code image of the second party, and the payment code image is displayed to the first party to make payment for the target transaction.

In a practical application, the second party may generate a first payment code image for payment using resources in the second party's personal payment account at the payment application to make payment for the target transaction.

Alternatively, if the second user obtains the permission to use the resources in the first user's payment account at the payment application, the second user can generate a payment using the resources in the first user's payment account at the payment application. Secondary payment code image to pay for the target transaction. For example, the first user can be the company where the second user works. If the target transaction is a transaction performed by the second user for work and can apply for reimbursement from the first user, the second user can use the payment method based on the first user. The second payment code image used for payment by resources in the account is used to make payment for the target transaction to simplify the reimbursement process. At this time, both the first user and the second user can serve as the second participant.

In the embodiment of this specification, since there are multiple ways to execute the target transaction between the second participant and the first participant, the second participant can use multiple ways to request the issuance of invoice information for the target transaction. Correspondingly, obtain The invoicing request message for the target transaction can also be implemented in multiple ways. To facilitate understanding, this is explained.

Implementation method one

Step 202: Obtain the invoicing request message for the target transaction, which may specifically include: acquiring the first invoicing request message for the target transaction; the first invoicing request message is based on the first invoicing request message for the target application by the second participant. The first invoicing control is generated after the target transaction is in a completed state. The first invoicing control is used to request the issuance of invoice information corresponding to the target transaction.

Correspondingly, step 204: Determining the initiation time of the invoicing request message specifically includes: determining the occurrence time of the triggering operation.

In the embodiment of this specification, the target application may include: a payment application used by the second participant to pay for the target transaction, and/or a transaction application used by the second participant to perform the target transaction.

This is because, typically, the target transaction will be in a completed state after the money paid by the second party for the target transaction has been released to the first party. The transaction information display page of the second party's transaction application and the bill information display page of the payment application can display the transaction information of the target transaction for review. At this time, the transaction information display page and bill information display page also The first invoicing control corresponding to the transaction information of the target transaction can be displayed.

When the second party needs to ask the first party to provide an invoice corresponding to the target transaction, the first invoicing control can be triggered so that the server of the e-commerce platform obtains the first invoicing request message for the target transaction. specific, If the target server monitors the trigger event for the first invoicing control, it can be determined that the first invoicing request message for the target transaction is obtained.

In the embodiment of this specification, since the first invoicing control is displayed after the target transaction is in the completed state, and after the target transaction is in the completed state, the first participant can issue an invoice for the target transaction. Therefore, when After the second participant triggers the first invoicing control, the invoicing time can be timed to subsequently determine whether the first participant has provided the invoice information corresponding to the target transaction to the second participant within the specified time period. Based on this, the occurrence time of the second participant's triggering operation on the first invoicing control can be used as the initiation time of the invoicing request message for the target transaction, that is, the second participant's triggering on the first invoicing control can be The time when the operation occurs is used as the starting time of the specified time period.

In a practical application, the end time of the specified time period may be a time interval of a first duration after the occurrence time of the triggering operation for the first invoicing control. The time interval between the current moment and the end time of the specified time period can be used as the remaining time for the first party to provide invoice information corresponding to the target transaction. To improve the experience of the second party, the remaining time can also be displayed on the target application of the second party.

Implementation method two

Step 202: Obtain the invoicing request message for the target transaction, which may specifically include: acquiring the second invoicing request message for the target transaction; the second invoicing request message is based on the status change operation of changing the target transaction to the completed state. Generated, the target transaction is a transaction in which the second participant performs a triggering operation on the second invoicing control at the target application, and the second invoicing control is a control displayed before the target transaction is in a completed state. .

Correspondingly, step 204: Determine the initiation time of the invoicing request message, which may specifically include: determining the occurrence time of the status change operation.

In the embodiment of this specification, the second party can also perform the operation of requesting the issuance of invoice information corresponding to the target transaction before the target transaction is completed. Subsequently, after the target transaction changes to the completed status, the invoicing time can be timed. This is to facilitate subsequent determination of whether the first party has provided the invoice information corresponding to the target transaction to the second party within a specified time period.

In practical applications, a second invoicing control can be set on the product display page of the second party's transaction application, so that when the second party initiates the target transaction, it can trigger the second invoicing control to execute the request for invoicing. The operation of the invoice information corresponding to the target transaction is convenient and fast.

Alternatively, the transaction information display page of the second party's transaction application and the bill information display page of the payment application can display the transaction information of the target transaction for review, and the transaction information of the target transaction can be set. Corresponding second invoicing control, so that the second participant can trigger the second invoicing control to execute the request to issue the invoice information corresponding to the target transaction after paying for the target transaction but before releasing the money to the first participant. operations to improve the execution flexibility of users' application for invoicing operations.

In practical applications, after the second party pays the money for the target transaction to the first party, the target transaction will change from the uncompleted state to the completed state, which is equivalent to executing the target transaction. A state change operation that changes to the completed state, so if the target server listens for an event that releases the money paid by the second party for the target transaction to the first party, or listens for an event that indicates that the target transaction has completed, then It can be determined that the second invoicing request message for the target transaction has been obtained.

Correspondingly, the occurrence time of the state change operation that changes the target transaction to the completed state can be used as the initiation time of the invoicing request message of the target transaction (that is, the time when the target server monitors the above event is used as the initiation time of the invoicing request message for the target transaction) , in order to subsequently determine whether the first participant has provided the invoice information corresponding to the target transaction to the second participant within the specified time period. The starting time of the designated time period may be the occurrence time of the state change operation, and the end time of the designated time period may be a time interval of a first length of time after the occurrence time of the state change operation.

In practical applications, the time interval between the current moment and the end time of the specified time period can be used as the The first party should provide the remaining time of the invoice information corresponding to the target transaction. In order to improve the experience of the second party, the prompt information of the remaining time can also be displayed on the second party's target application.

In the embodiment of this specification, both the first invoicing control and the second invoicing control may include a single control or multiple controls, which are not specifically limited. For example, when the second party has entered the buyer's name, buyer's taxpayer identification number, invoice type and other relevant information in the target application, the target application can set a single control as the first invoicing control or the second invoicing control. This enables the one-click invoicing function, which is conducive to simplifying the invoicing operations of the second party. Alternatively, the first invoicing control and the second invoicing control may both include controls and confirmation controls for inputting relevant invoice information, so that the second party can input relevant invoice information in real time based on the above controls, and trigger the confirmation control to Request the invoice corresponding to the target transaction. This method is more flexible.

In practical applications, the display of the first invoicing control and the second invoicing control at the target application of the second party can be controlled according to the setting information of the first party. For example, based on the setting information of the first participant, the second invoicing control can be displayed on the product display page of the target application; or based on the setting information of the first participant, the second invoicing control can be displayed on the transaction information display page of the target application. The first invoicing control and the second invoicing control. Alternatively, based on the setting information of the first participant, both the first invoicing control and the second invoicing control are displayed, which is not specifically limited.

In the embodiment of this specification, when the second party performs the operation of requesting to issue an invoice, it usually needs to provide the buyer information, invoice type and other information in the invoice. In practical applications, the second party may have the need to modify the above information. , if the second party makes changes to the above information, the time limit for the first party to provide the corresponding invoice needs to be re-determined to protect the rights and interests of the first party.

Based on this, step 202: After obtaining the invoicing request message for the target transaction, it may also include: obtaining the invoice change request message of the second participant for the target transaction; the invoice change request message is based on the second Generated by the invoice information change operation performed by the participant at the target application, and the invoice information change operation is used to request changes to the invoice information.

Determining the initiation time of the invoicing request message specifically includes: determining the occurrence time of the invoice information change operation.

In the embodiment of this specification, the invoice information modification operation performed by the second participant at the target application may include: a partial refund operation for the target transaction, and a modification operation for the variable information in the invoice information.

Specifically, when the second party makes a partial refund for the target transaction, it will affect the goods information and tax amount information in the invoice information, so the invoice information of the target transaction needs to be modified. Based on this, when the target server monitors the partial refund operation of the second participant for the target transaction, it can be determined that the invoice change request message of the second participant for the target transaction is obtained. Of course, the first participant may also take the initiative to partially refund the target transaction. At this time, if the target server monitors the first participant's partial refund operation for the target transaction, it can also determine that it has obtained the second participation policy. Invoice change request message for the target transaction.

Alternatively, the transaction information display page of the transaction application and the bill information display page of the payment application can also be provided with an invoice modification control. The second party can modify and submit the available information in the invoice information by triggering the invoice modification control. change information. Based on this, when the target server monitors the operation information of the second participant on the invoice modification control, it can be determined that the invoice change request message of the second participant on the target transaction is obtained. Among them, the variable information in the invoice information may include but is not limited to: buyer's name, address, account, taxpayer identification number, invoice type and other information.

Since the invoice information needs to be modified when the invoice change request message for the target transaction is obtained, it is equivalent to the second party reinitiating the invoicing request message. Based on this, the invoice of the target transaction can be provided to the first party. The time consumption of the information is reset to zero and the time is reset to ensure the rights and interests of the first participant. Specifically, the occurrence time of the invoice information change operation can be used as the initiation time of the updated invoicing request message. Correspondingly, step 206 can determine the first participant's time after the occurrence time of the invoice information change operation. Whether the invoice information of the target transaction has been provided to the second party within a period of time to obtain the first judgment result.

In practical applications, the second party can execute the issuance before obtaining the invoice corresponding to the target transaction. Change the ticket information to avoid the problem that the invoice issued by the first party does not meet the needs of the second party. Alternatively, the second participant can also perform the invoice information change operation after obtaining the invoice corresponding to the target transaction to ensure that the second participant obtains the required invoice; and for the invoice that the second participant has obtained Invoices can be voided by the first party through invoice hedging operations to ensure the normal operation of the invoice business, and there are no specific restrictions on this. However, if the invoice information change operation is performed after step 208, since the solution in Figure 2 has been completed, there is no need to use the occurrence time of the invoice information change operation as the initiation time of the updated invoicing request message, and there is no need to To change the processing results for the first participant to ensure the rationality of the processing for the first participant.

In the embodiment of this specification, if the first party identifies that there are obvious errors in the variable information in the invoice information submitted by the second party, the first party can also refuse to issue the invoice and ask the second party to respond to the invoice. The variable information in the message is modified to ensure that the first party can issue the correct invoice.

Based on this, before obtaining the invoice change request message of the second participant for the target transaction, the method may further include: obtaining the invoicing rejection instruction of the first participant for the target transaction.

In response to the rejection of the invoicing instruction, invoicing change prompt information is sent to the device of the second participant; the invoicing change prompt information is used to prompt the second participant to change the invoice information.

In the embodiment of this specification, the merchant client of the first participant can display the invoice order information of the target transaction, so that the first participant can perform invoice management based on the invoice order information. In practical applications, the merchant client can also display an invoicing rejection control corresponding to the invoice order information of the target transaction. The first participant can trigger the invoicing rejection control to send an invoicing rejection control to the target server for the target transaction. Reject the billing instruction.

In practical applications, the first party usually needs to provide a reason for refusing to issue an invoice, so that the second party can clarify the information that needs to be modified. Based on this, the invoicing change prompt information sent by the target server to the second participant can reflect the reason for rejecting invoicing and/or modification suggestions, so that the second participant can refer to the invoicing change prompt information to perform the invoice information change operation.

In practical applications, if the second party needs to modify the relevant invoice information because the first party refuses to issue an invoice, the second party is usually required to make the modification within the preset time limit. If the second party fails to do so within the preset time limit, If it is modified internally, it can be considered that the second party no longer requires the issuance of invoices, so it can jump to the end without processing the first party.

Based on this, after sending the invoicing change prompt information to the device of the second participant, it may also include: determining whether the invoice change request message is obtained within a second period of time after the rejecting the invoicing instruction is generated, and obtain The second judgment result.

If the second judgment result indicates that the invoice change request message is obtained within a second period of time after the invoicing rejection instruction is generated, step 204 may determine the occurrence time of the invoice information change operation corresponding to the invoice change request message. Determine the initiation time of the updated invoice change request message, and step 206 may determine whether the first participant provided the invoice of the target transaction to the second participant within the first period of time after the occurrence time of the invoice information change operation. information.

If the second judgment result indicates that the invoice change request message is not obtained within a second period of time after the invoicing rejection instruction is generated, processing of the first participant is prohibited and the process jumps to the end.

In the embodiment of this specification, there can be multiple implementation methods for the first participant to issue invoices, and there can also be multiple types of invoices. Correspondingly, the target server verifies whether the first participant has provided the second participant with an invoice implementation method. There can also be multiple types.

Based on this, step 206: Determine whether the first participant provides the invoice information to the second participant within the first time period after the initiation time, which may specifically include: determining whether after the initiation time Within the first period of time, according to the invoice issuance instruction of the first participant, the invoice information corresponding to the target transaction is generated; and/or, it is determined whether within the first period of time after the initiation time, the invoice information corresponding to the target transaction is generated. The first party submits invoice information corresponding to the target transaction.

In the embodiment of this specification, there are many ways to implement invoice issuance by the first participant. For example, the first party can issue an invoice based on the invoice issuance function of the merchant client. Specifically, the first participant needs to input an invoice issuance instruction into the merchant client, so that the merchant client and the target server can automatically issue invoice information corresponding to the target transaction based on the invoice issuance instruction. Since the generation process of this invoice information can be controlled and identified by the target server, step 206 can determine whether within the first period of time after the initiation time, according to the invoice issuance instruction of the first participant, an invoice issuance instruction related to Invoice information corresponding to the target transaction.

Alternatively, the first party can also issue invoices based on enterprise management software (Enterprise Resource Planning, ERP). Of course, it can also issue invoices offline based on other methods. At this time, the first party needs to issue invoices to the merchant client and target server. Submit the invoice information corresponding to the target transaction to prove that it has generated the invoice information, or to transfer the invoice information to the second party. In actual use, enterprise management software can use the Application Programming Interface (API) to obtain the second party's invoice application details and accurate invoicing amount and other information from the target server, and after issuance of the invoice Return the invoicing results (for example, invoice code information, electronic invoice image, paper invoice image) to the target server through API. Based on this, step 206 may determine whether the first participant submitted the invoice information corresponding to the target transaction within the first period of time after the initiation time.

In the embodiment of this specification, in step 206, in addition to determining whether the first participant has generated the invoice information corresponding to the target transaction, it may also be necessary to determine whether the first participant has actually delivered the invoice information to the second participant.

Based on this, step 206: Determine whether the first participant provides the invoice information to the second participant within the first time period after the initiation time, which may also include: determining whether after the initiation time Within the first period of time, the first party submitted proof of delivery information for the paper invoice.

In the embodiment of this specification, the invoice information corresponding to the target transaction can be either an electronic invoice or a paper invoice. If it is a paper invoice, the paper invoice can be transmitted to the second party by mail, or the two parties can also agree on other offline delivery methods. Of course, both parties can also agree that there is no need to deliver the paper invoice. Based on this, the courier number, mailing voucher or delivery agreement information between the two parties can be used as delivery proof information to avoid cheating by the first party, thus helping to further protect the rights and interests of the second party.

In practical applications, if the invoice information corresponding to the target transaction is an electronic invoice, the electronic invoice image can be sent to the target application of the second participant based on the target server, or it can also be sent to the target application based on email, SMS, instant messaging tools, etc. Second party. Since the target server is utilized to perform the operation of delivering the invoice information, there is no need to provide delivery proof information for the invoice information. Of course, emails delivering electronic invoices, screenshots of application pages, etc. can also be used as delivery proof information for electronic invoices. Based on this, step 206 can also include determining whether the first time period after the initiation time is reached. The participant submitted proof of delivery information for the electronic invoice, thereby further protecting the rights of the second participant.

In the embodiment of this specification, if the target server obtains the first participant's invoicing event, input invoice information event, or input delivery certificate information event within the specified event period, it can determine the first participant's event in the specified event period. The second party provided the invoice information. Thus, event monitoring technology is used to decouple the invoice application process from the delayed invoicing compensation process.

In the embodiment of this specification, if the first party delays in providing invoices, in order to reduce the losses suffered by the second party, some of the resources of the first party can be transferred to the second party, thereby conducive to reducing the losses suffered by the first party. Delaying the provision of methods will also help protect the rights and interests of the second party.

Based on this, step 208: Process the first participant, which may specifically include: determining the amount of resources to be transferred based on the transaction information of the target transaction.

The amount of resources to be transferred is deducted from the resource pool of the first participant.

Release the amount of resources to be transferred to the account of the second participant.

In the embodiment of this specification, the first party usually needs to transfer a certain amount of resources to the target server in advance. To generate the first party's resource pool, the first party can also pre-authorize the target server's transfer permission for the resources in the resource pool, so that after it is determined that the first party has not provided the invoice on time, the first party can The amount of resources to be transferred is transferred to the account of the second party, which is convenient and fast.

In practical applications, the amount of resources to be transferred can be a preset proportion of the transaction amount of the target transaction. For example, assuming that the transaction amount of the target transaction is 100 yuan and the preset proportion is 10%, the amount of resources to be transferred can be 10 yuan. . Alternatively, the amount of resources to be transferred can be a specified value corresponding to the numerical interval within which the transaction amount of the target transaction falls. For example, if the transaction amount of the target transaction falls into (0,100], the amount of resources to be transferred can be 10 yuan, and If the transaction amount of the target transaction falls into (100,1000], the amount of resources to be transferred can be 20 yuan. Alternatively, the amount of resources to be transferred can also be a specified value. For example, no matter what the transaction amount of the target transaction is, the amount of resources to be transferred can be The amount of resources to be transferred can all be 10 yuan. In the embodiment of this specification, the calculation method of the amount of resources to be transferred can be set according to actual needs, and is not specifically limited.

In practical applications, when the amount of resources to be transferred is released to the account of the second party, the funds of the amount of resources to be transferred can be released to the payment account of the second party at the payment application. Alternatively, points can also be used to distribute the points for the amount of resources to be transferred to the registered account of the second party at the trading application, so that the second party can use the points in the registered account at the trading application. There are no specific restrictions on purchasing goods or enjoying other rights and interests.

In the embodiment of this specification, before performing the processing operation on the first participant in step 208, interception verification is also required to avoid penalty errors and damage to the rights and interests of the first participant.

Based on this, step 208: Before processing the first participant, it may also include: judging whether the invoicing request message meets the interception conditions and obtaining a third judgment result; the interception conditions include: participant identity conditions, prohibition At least one of invoicing conditions and deduplication conditions.

Correspondingly, processing the first participant may specifically include: if the third judgment result indicates that the invoicing request message does not meet the interception condition, processing the first participant.

At the same time, if the third judgment result indicates that the invoicing request message satisfies the interception condition, processing of the first participant may be prohibited and the process will jump to the end.

In the embodiment of this specification, there may be multiple opportunities to intercept and verify the invoicing request message, that is, there may be multiple opportunities to determine whether the invoicing request message satisfies the interception condition. For example, the invoicing request message can be intercepted and verified after being obtained in step 202, and step 204 and subsequent operations can be performed after it is determined that the invoicing request message does not meet the interception conditions, thereby reducing unnecessary invoicing request messages. processing to save device resources. Moreover, it is also possible to perform interception and verification after determining in step 206 that the first participant has not provided the invoice to the second participant within the specified time period, and then process the first participant after determining that the invoicing request message does not meet the interception conditions. , thereby avoiding the execution of wrong penalty operations and protecting the rights and interests of the first participant.

In the embodiment of this specification, the interception conditions involved in interception verification may include: at least one of a participant identity condition, a prohibition of invoicing conditions, and a deduplication condition.

The deduplication condition may refer to the existence of multiple identical invoicing request messages for the target transaction. In actual applications, due to factors such as system jitter, multiple identical invoicing request messages may be repeatedly initiated for the target transaction. To ensure the normal operation of the business, only one of the invoicing request messages is required (for example, the invoice with the earliest receipt time request message) without responding to other invoicing request messages.

The participant identity condition may mean that the first participant is in the blocked merchant list. In actual applications, the target server may only need to deal with the delay in providing invoices by some merchants. Based on this, the identification information of other merchants can be added to the blocked merchant list, regardless of whether the merchants in the blocked merchant list are within the preset time limit. Invoices provided will not be processed by these merchants. Specifically, the merchants in the intercepted merchant list may include merchants that have not participated in invoicing supervision activities, or may include some merchants that have suspended participation in invoicing supervision activities due to special circumstances, for example, merchants that currently do not have an invoicing quota, Or, merchants that are unable to provide invoices due to force majeure, etc.

There can be multiple conditions for prohibiting invoicing, and the conditions for prohibiting invoicing required for interception verification at different times can also be different. For example, if interception and verification are performed after obtaining the invoicing request message in step 202, it is prohibited to The conditions for stopping invoicing may include: the completion time of the target transaction is earlier than the initiation time of the invoicing supervision activity, the target transaction is in an uncompleted state, the first participant has been processed based on the target transaction, the invoiceable amount is 0, and the invoice is valid Blue ticket etc.

If it is determined in step 206 that the first participant has not provided the invoice to the second participant within the specified time period and then intercepts and verifies, the conditions for prohibiting invoicing may include, in addition to the above conditions, the following: when the invoice request message is initiated The first participant's full refund instruction for the target transaction is obtained within the first time period after the time, and the second time period is obtained within the first time period after the initiation time of the invoice request message. The participant's unbilling request message for the described target transaction. Therefore, when the target transaction has been fully refunded or the second party no longer requires the issuance of invoices, processing of the first party is prohibited to protect the rights and interests of the first party.

In practical applications, when the target server obtains the full refund instruction and cancellation request message for the target transaction, it can also determine that processing is prohibited for the first party and jump to the end without executing the steps. 206 and step 208, thereby conducive to saving equipment resources. Specifically, if the target server obtains a full refund event for the target transaction, it can determine that the full refund instruction for the target transaction is obtained. If the target server obtains the invoicing cancellation event for the target transaction, it can determine that the invoicing cancellation request message for the target transaction is obtained. Thus, the invoice application process and the invoice request processing process are decoupled through event monitoring technology.

In the embodiments of this specification, when the target server executes the invoice request processing method in Figure 2 and its embodiments, it can be implemented using a workflow engine, for example, OSWorkflow, an open source workflow framework with better flexibility and higher operating efficiency. The target server can trigger the execution of the invoice request processing method by monitoring transaction-related events, buyer and merchant application operation events, and invoicing events. In addition, the target server can also intercept when an event triggers a new invoice request processing process, and/or intercept when an event triggers an intermediate state flow, thereby reducing unnecessary invoicing request messages based on preset interception conditions. The processing can not only save equipment resources, but also avoid executing wrong penalty operations to protect the rights and interests of the first participant.

FIG. 3 is a schematic diagram of a swim lane flow corresponding to the invoice request processing method in FIG. 2 provided by an embodiment of this specification. As shown in Figure 3, the invoice request processing process may involve execution entities such as the first party, the second party, and the target server.

In the stage of applying for issuance of invoices, the second party can perform a triggering operation on the first invoicing control at the target application. The first invoicing control is a control displayed after the target transaction is in a completed state. Based on the triggering operation, the target server The first invoicing request message for the target transaction can be obtained. Alternatively, the second participant can also perform a triggering operation on the second invoicing control at the target application. The second invoicing control is a control displayed before the target transaction is in the completed state. Based on the triggering operation, the subsequent target server obtains After the status change operation changes the target transaction to the completed status, it can be determined that the second invoicing request message for the target transaction is obtained.

In the invoice request processing stage, the target server can first determine whether the first/second invoicing request message meets the interception conditions. If so, it can jump to the end, and if not, it can determine the initiation of the first/second invoicing request message. Time, for example, the occurrence time of the trigger operation performed on the first invoicing control can be used as the initiation time of the invoicing request message, or the occurrence time of the status change operation that changes the target transaction to the completed state can be used as the initiation time of the invoicing request message. time.

Subsequently, if the target server obtains an invoicing rejection instruction sent by the first participant for the target transaction, it may send invoicing change prompt information to the second participant in response to the invoicing refusal instruction. The second participant can perform the invoice information change operation at the target application based on the invoicing change prompt information. Of course, the second party can also actively perform the invoice information change operation without obtaining the invoicing change prompt information. However, in the above two cases, the target server can update the initiation time of the invoicing request message to the time when the invoice information change operation occurs.

The target server may also determine whether the first party has provided the target transaction to the second party within the first period of time after the initiation time of the updated invoicing request message based on the updated initiation time of the invoicing request message. For the corresponding invoice information, if yes, you can jump to the end. If not, you can judge again whether the invoicing request message meets the interception conditions. If it is determined that the invoicing request message meets the interception conditions, you can jump to the end. If it is determined that the invoicing request message does not meet the interception conditions, you can determine the amount of resources to be transferred based on the transaction information of the target transaction; from the resource pool of the first participant , deduct the amount of resources to be transferred; and release the amount of resources to be transferred to the account of the second participant.

In practical applications, if the first participant's full refund instruction for the target transaction is obtained within the first period of time after the initiation time of the target server's invoicing request message, or the second participant's instruction for a full refund is obtained The invoicing cancellation request message of the target transaction can be directly jumped to the end (not shown in Figure 3) to save equipment resources.

Based on the same idea, the embodiments of this specification also provide devices corresponding to the above methods. FIG. 4 is a schematic structural diagram of an invoice request processing device corresponding to FIG. 2 provided by an embodiment of this specification. As shown in Figure 4, the device may include the following modules.

The first acquisition module 402 is used to obtain the invoicing request message for the target transaction; the invoicing request message is used to request the first participant of the target transaction to provide the invoice information corresponding to the target transaction to the second participant.

Determining module 404 is used to determine the initiation time of the invoicing request message.

The first judgment module 406 is used to judge whether the first participant provides the invoice information to the second participant within the first time period after the initiation time, and obtains a first judgment result.

The processing module 408 is configured to, if the first judgment result indicates that the first participant does not provide the invoice information to the second participant within a first period of time after the initiation time, then Processed by the participating parties.

Based on the device in Figure 4, the embodiments of this specification also provide some specific implementations of the device, which will be described below.

Optionally, the first obtaining module 402 may be specifically configured to: obtain the first invoicing request message for the target transaction; the first invoicing request message is based on the first invoicing request message from the second participant to the target application. The first invoicing control is generated after the triggering operation of the invoicing control. The first invoicing control is a control displayed after the target transaction is in a completed state.

Correspondingly, the determining module 404 may be specifically configured to determine the occurrence time of the triggering operation.

Optionally, the first acquisition module 402 may be specifically configured to: acquire a second invoicing request message for the target transaction; the second invoicing request message is a status change operation based on the target transaction changing to a completed state. Generated, the target transaction is a transaction in which the second participant performs a triggering operation on the second invoicing control at the target application, and the second invoicing control is displayed before the target transaction is in a completed state. Control; correspondingly, the determination module 404 can be specifically used to determine the occurrence time of the status change operation.

Optionally, the target application may include: a payment application used by the second participant to pay for the target transaction, or a transaction application used by the second participant to execute the target transaction.

Optionally, the device in Figure 4 may also include: a second acquisition module, configured to acquire the invoice change request message of the second participant for the target transaction; the invoice change request message is based on the third Generated by the invoice information change operation performed by the two participants at the target application, and the invoice information change operation is used to request changes to the invoice information.

Correspondingly, the determination module 404 may be specifically used to determine the time when the invoice information change operation occurs.

Optionally, the device in Figure 4 may also include: a third acquisition module, configured to acquire the first participant's instruction to reject invoicing for the target transaction.

A sending module, configured to send invoicing change prompt information to the device of the second participant in response to the invoicing rejection instruction; the invoicing change prompt information is used to prompt the second participant to change the invoice information.

Optionally, the device in Figure 4 may also include: a second judgment module, used to judge whether the invoice change request message is obtained within a second period of time after the rejection of invoicing instruction is generated, and obtain a second judgment result. .

A prohibition processing module configured to prohibit processing of the first participant if the second judgment result indicates that the invoice change request message is not obtained within a second period of time after the rejection of the invoicing instruction is generated.

Optionally, the invoice information modification operation may include: a partial refund operation for the target transaction, and a modification operation for the variable information in the invoice information.

Optionally, the first judgment module 406 may include: a first judgment unit, used to judge whether an invoice issuance instruction is generated according to the first party's invoice issuance instruction within the first period of time after the initiation time. Invoice information corresponding to the target transaction.

The second judgment unit is used to judge whether the first participant has submitted the invoice information corresponding to the target transaction within the first period of time after the initiation time.

If the invoice information includes a paper invoice; optionally, the first judgment module 406 may also include:

The third judgment unit is used to judge whether the first party has submitted the delivery proof information for the paper invoice within the first period of time after the initiation time.

Optionally, the processing module 408 may include: a determining unit configured to determine the amount of resources to be transferred based on the transaction information of the target transaction.

A deducting unit configured to deduct the amount of resources to be transferred from the resource pool of the first participant.

An issuing unit, configured to issue the amount of resources to be transferred to the account of the second participant.

Optionally, the device in Figure 4 may also include: a third judgment module, used to judge whether the invoicing request message meets the interception conditions and obtain a third judgment result; the interception conditions include: participant identity conditions, prohibition At least one of invoicing conditions and deduplication conditions.

The processing module 408 may also be configured to process the first participant if the third judgment result indicates that the invoicing request message does not meet the interception condition.

Optionally, the prohibition of invoicing conditions may include: obtaining a full refund instruction from the first participant for the target transaction within the first period of time after the initiation time, or, within the initiation time A cancellation request message for the target transaction from the second participant is obtained within the first period of time thereafter.

Based on the same idea, the embodiments of this specification also provide equipment corresponding to the above method.

FIG. 5 is a schematic structural diagram of an invoice request processing device corresponding to FIG. 2 provided by an embodiment of this specification. As shown in Figure 5, the device 500 may include: at least one processor 510; and a memory 530 communicatively connected to the at least one processor; wherein the memory 530 stores information that can be executed by the at least one processor 510. The instructions 520 are executed by the at least one processor 510 to enable the at least one processor 510 to: obtain an invoicing request message for the target transaction; the invoicing request message is used to request the invoicing request message for the target transaction. The first participant provides the invoice information corresponding to the target transaction to the second participant; determines the initiation time of the invoicing request message; and determines whether the first participant provides the invoice information to the second participant within the first time period after the initiation time. The second participant provides the invoice information and obtains the first judgment result; if the first judgment result indicates that the first participant does not provide the invoice information to the second participant within the first period of time after the initiation time, The invoice information is processed by the first participant.

Each embodiment in this specification is described in a progressive manner. The same and similar parts between the various embodiments can be referred to each other. Each embodiment focuses on its differences from other embodiments. In particular, for the equipment shown in FIG. 5 , since it is basically similar to the method embodiment, the description is relatively simple. For relevant details, please refer to the partial description of the method embodiment.

In the 1990s, improvements in a technology could be clearly distinguished as hardware improvements (for example, improvements in circuit structures such as diodes, transistors, switches, etc.) or software improvements (improvements in method processes). However, with the development of technology, many improvements in today's method processes can be regarded as direct improvements in hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement of a method flow cannot be implemented using hardware entity modules. For example, Programmable Logic Device (PLD) (such as Field Programmable Gate Array) Programmable Gate Array (FPGA)) is such an integrated circuit whose logic functions are determined by the user programming the device. Designers can program themselves to "integrate" a digital character system on a PLD, instead of asking chip manufacturers to design and produce dedicated integrated circuit chips. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in program development and writing. Before compiling, The original code must also be written in a specific programming language, which is called Hardware Description Language (HDL). There is not only one type of HDL, but many types, such as ABEL (Advanced Boolean Expression Language) , AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., are currently the most commonly used The most popular ones are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that by simply logically programming the method flow using the above-mentioned hardware description languages and programming it into the integrated circuit, the hardware circuit that implements the logical method flow can be easily obtained.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (eg, software or firmware) executable by the (micro)processor. , logic gates, switches, Application Specific Integrated Circuit (ASIC), programmable logic controllers and embedded microcontrollers. Examples of controllers include but are not limited to the following microcontrollers: ARC 625D, Atmel AT91SAM, For Microchip PIC18F26K20 and Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic. Those skilled in the art also know that in addition to implementing the controller in the form of pure computer-readable program code, the controller can be completely programmed with logic gates, switches, application-specific integrated circuits, programmable logic controllers and embedded logic by logically programming the method steps. Microcontroller, etc. to achieve the same function. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the means for implementing various functions can be considered as structures within hardware components as well as software modules implementing the methods.

The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device Or a combination of any of these devices.

For the convenience of description, when describing the above device, the functions are divided into various units and described separately. Of course, when implementing this application, the functions of each unit can be implemented in the same or multiple software and/or hardware.

Those skilled in the art will understand that embodiments of the present application may be provided as methods, systems, or computer program products. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment that combines software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each process and/or block in the flowchart illustrations and/or block diagrams, and combinations of processes and/or blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing device to produce a machine, such that the instructions executed by the processor of the computer or other programmable data processing device produce a use A device for realizing the functions specified in one process or multiple processes of the flowchart and/or one block or multiple blocks of the block diagram.

These computer program instructions may also be stored in a computer-readable memory that causes a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable memory produce instructions that include instructions. An article of manufacture that instructs the device to implement the functions specified in a process or processes in a flowchart and/or in a block or blocks in a block diagram.

These computer program instructions may also be loaded onto a computer or other programmable data processing device, causing a series of operating steps to be performed on the computer or other programmable device to produce computer-implemented processing, thereby executing on the computer or other programmable device. Instructions provide steps for implementing the functions specified in a process or processes of a flowchart diagram and/or a block or blocks of a block diagram.

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

Memory may include non-permanent storage in computer-readable media, random access memory (RAM) and/or non-volatile memory in the form of read-only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.

Computer-readable media includes both persistent and non-volatile, removable and non-removable media that can be implemented by any method or technology for storage of information. Information may be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), and read-only memory. (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage , magnetic tape cassettes, magnetic tape disk storage or other magnetic storage devices or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.

It should also be noted that the terms "comprises," "comprises," or any other variation thereof are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements not only includes those elements, but also includes Other elements are not expressly listed or are inherent to the process, method, article or equipment. Without further limitation, an element defined by the statement "comprises a..." does not exclude the presence of additional identical elements in a process, method, article, or device that includes the stated element.

Those skilled in the art will understand that embodiments of the present application may be provided as methods, systems or computer program products. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The application may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The present application may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including storage devices.

The above descriptions are only examples of the present application and are not intended to limit the present application. To those skilled in the art, various modifications and variations may be made to this application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of this application shall be included in the scope of the claims of this application.

Claims

An invoice request processing method, including:

Obtain an invoicing request message for the target transaction; the invoicing request message is used to request the first participant of the target transaction to provide the invoice information corresponding to the target transaction to the second participant;

Determine the initiation time of the invoicing request message;

Determine whether the first participant provides the invoice information to the second participant within a first period of time after the initiation time, and obtain a first judgment result;

If the first judgment result indicates that the first participant does not provide the invoice information to the second participant within the first period of time after the initiation time, then the first participant is processed.
The method according to claim 1, wherein obtaining the invoicing request message for the target transaction includes:

Obtain a first invoicing request message for the target transaction; the first invoicing request message is generated based on the second participant's triggering operation on the first invoicing control at the target application, and the first invoicing control is at The control displayed after the target transaction is in a completed state;

Determining the initiation time of the invoicing request message includes:

Determine when the trigger operation occurs.
The method according to claim 1, wherein obtaining the invoicing request message for the target transaction includes:

Obtain a second invoicing request message for the target transaction; the second invoicing request message is generated based on the state change operation of changing the target transaction to the completed state, and the target transaction is the target of the second participant The second invoicing control at the application executes the transaction that triggered the operation, and the second invoicing control is a control displayed before the target transaction is in a completed state;

Determining the initiation time of the invoicing request message includes:

Determine when the state change operation occurs.
The method according to claim 2 or 3, after obtaining the invoicing request message for the target transaction, further comprising:

Obtain the invoice change request message of the second participant for the target transaction; the invoice change request message is generated based on the invoice information change operation performed by the second participant at the target application, the The invoice information change operation is used to request changes to the invoice information;

Determining the initiation time of the invoicing request message includes:

Determine the time when the invoice information change operation occurs.
The method according to claim 4, before obtaining the invoice change request message of the second participant for the target transaction, further comprising:

Obtain the first participant's rejection of invoicing instructions for the target transaction;

In response to the rejection of the invoicing instruction, invoicing change prompt information is sent to the device of the second participant; the invoicing change prompt information is used to prompt the second participant to change the invoice information.
The method of claim 5, after sending the invoicing change prompt information to the device of the second participant, further comprising:

Determine whether the invoice change request message is obtained within a second period of time after the rejection of invoicing instruction is generated, and obtain a second judgment result;

If the second judgment result indicates that the invoice change request message is not obtained within a second period of time after the invoicing rejection instruction is generated, processing of the first participant is prohibited.
The method of claim 4, wherein the invoice information modification operation includes: a partial refund operation for the target transaction, and a modification operation for the variable information in the invoice information.
The method of claim 1, wherein determining whether the first participant provides the invoice information to the second participant within a first period of time after the initiation time includes:

Determine whether within the first period of time after the initiation time, according to the invoice issuance instruction of the first participant, Invoice information corresponding to the target transaction is generated; or,

Determine whether the first participant has submitted invoice information corresponding to the target transaction within the first period of time after the initiation time.
The method of claim 8, wherein the invoice information includes a paper invoice;

Determining whether the first participant provides the invoice information to the second participant within a first period of time after the initiation time also includes:

Determine whether the first party has submitted delivery proof information for the paper invoice within the first period of time after the initiation time.
The method of claim 1, wherein processing the first participant includes:

Determine the amount of resources to be transferred based on the transaction information of the target transaction;

Deduct the amount of resources to be transferred from the resource pool of the first participant;

Release the amount of resources to be transferred to the account of the second participant.
The method according to claim 10, before processing the first participant, further comprising:

Determine whether the invoicing request message satisfies the interception condition and obtain a third judgment result; the interception condition includes: at least one of a participant identity condition, an invoicing prohibition condition and a deduplication condition;

The processing of the first party includes:

If the third judgment result indicates that the invoicing request message does not meet the interception condition, the first participant is processed.
The method according to claim 11, the invoicing prohibition condition includes: obtaining the first participant's full refund instruction for the target transaction within the first period of time after the initiation time, or, in The second participant's invoicing cancellation request message for the target transaction is obtained within a first period of time after the initiation time.
The method of claim 2 or 3, wherein the target application includes: a payment application used by the second participant to pay for the target transaction, or the second participant executes the target transaction Trading application used.
An invoice request processing device, including:

The first acquisition module is used to obtain the invoicing request message for the target transaction; the invoicing request message is used to request the first participant of the target transaction to provide the invoice information corresponding to the target transaction to the second participant;

Determining module, used to determine the initiation time of the invoicing request message;

A first judgment module, used to judge whether the first participant has provided the invoice information to the second participant within a first period of time after the initiation time, and obtain a first judgment result;

A processing module configured to, if the first judgment result indicates that the first participant does not provide the invoice information to the second participant within a first period of time after the initiation time, then the first participant side for processing.
The device according to claim 14, the first acquisition module is used for:

Obtain a first invoicing request message for the target transaction; the first invoicing request message is generated based on the second participant's triggering operation on the first invoicing control at the target application, and the first invoicing control is at The control displayed after the target transaction is in a completed state;

The determination module is used for:

Determine when the trigger operation occurs.
The device according to claim 14, the first acquisition module is used for:

Obtain a second invoicing request message for the target transaction; the second invoicing request message is generated based on the state change operation of changing the target transaction to the completed state, and the target transaction is the target of the second participant The second invoicing control at the application executes the transaction that triggered the operation, and the second invoicing control is a control displayed before the target transaction is in a completed state;

The determination module is used for:

Determine when the state change operation occurs.
The device of claim 15 or 16, further comprising:

The second acquisition module is used to obtain the invoice change request message of the second participant for the target transaction; the invoice change request message is based on the invoice information change performed by the second participant at the target application. Generated by an operation, the invoice information change operation is used to request changes to the invoice information;

The determination module is used for:

Determine the time when the invoice information change operation occurs.
The device of claim 17, further comprising:

The third acquisition module is used to acquire the first participant's rejection of invoicing instructions for the target transaction;

A sending module, configured to send invoicing change prompt information to the device of the second participant in response to the invoicing rejection instruction; the invoicing change prompt information is used to prompt the second participant to change the invoice information.
The device of claim 18, further comprising:

The second judgment module is used to judge whether the invoice change request message is obtained within a second period of time after the rejection of invoicing instruction is generated, and obtain a second judgment result;

A prohibition processing module configured to prohibit processing of the first participant if the second judgment result indicates that the invoice change request message is not obtained within a second period of time after the rejection of the invoicing instruction is generated.
The device according to claim 14, the first judgment module includes:

A first judgment unit configured to judge whether invoice information corresponding to the target transaction is generated according to the invoice issuance instruction of the first participant within the first period of time after the initiation time;

The second judgment unit is used to judge whether the first participant has submitted the invoice information corresponding to the target transaction within the first period of time after the initiation time.
The device according to claim 20, the invoice information includes a paper invoice; the first judgment module further includes:

The third judgment unit is used to judge whether the first party has submitted the delivery proof information for the paper invoice within the first period of time after the initiation time.
The device according to claim 14, the processing module includes:

A determining unit configured to determine the amount of resources to be transferred based on the transaction information of the target transaction;

A deducting unit configured to deduct the amount of resources to be transferred from the resource pool of the first participant;

An issuing unit, configured to issue the amount of resources to be transferred to the account of the second participant.
The device of claim 22, further comprising:

The third judgment module is used to judge whether the invoicing request message satisfies the interception condition and obtain the third judgment result; the interception condition includes: at least one of the participant identity condition, the invoicing prohibition condition and the deduplication condition;

The processing module is also used for:

If the third judgment result indicates that the invoicing request message does not meet the interception condition, the first participant is processed.
The device according to claim 15 or 16, the target application includes: a payment application used by the second participant to pay for the target transaction, or the second participant executes the target transaction Trading application used.
An invoice request processing device comprising:

at least one processor; and,

a memory communicatively connected to the at least one processor; wherein,

The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to:

Obtain an invoicing request message for the target transaction; the invoicing request message is used to request the first participant of the target transaction to provide the invoice information corresponding to the target transaction to the second participant;

Determine the initiation time of the invoicing request message;

Determine whether the first participant provides the invoice information to the second participant within a first period of time after the initiation time, and obtain a first judgment result;

If the first judgment result indicates that the first participant does not provide the invoice information to the second participant within the first period of time after the initiation time, then the first participant is processed.