WO2023226799A1 - Procédé, appareil et dispositif de traitement de demande de facture - Google Patents

Procédé, appareil et dispositif de traitement de demande de facture Download PDF

Info

Publication number
WO2023226799A1
WO2023226799A1 PCT/CN2023/094046 CN2023094046W WO2023226799A1 WO 2023226799 A1 WO2023226799 A1 WO 2023226799A1 CN 2023094046 W CN2023094046 W CN 2023094046W WO 2023226799 A1 WO2023226799 A1 WO 2023226799A1
Authority
WO
WIPO (PCT)
Prior art keywords
participant
invoicing
invoice
target transaction
request message
Prior art date
Application number
PCT/CN2023/094046
Other languages
English (en)
Chinese (zh)
Inventor
舒杰
Original Assignee
支付宝(杭州)信息技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 支付宝(杭州)信息技术有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Publication of WO2023226799A1 publication Critical patent/WO2023226799A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/387—Payment using discounts or coupons
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
    • G06Q30/0222—During e-commerce, i.e. online transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
    • G06Q30/0226—Incentive systems for frequent usage, e.g. frequent flyer miles programs or point systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Definitions

  • the present application relates to the field of invoice technology, and in particular to an invoice request processing method, device and equipment.
  • the embodiments of this specification provide an invoice request processing method, device and equipment, which can improve merchants' processing efficiency of invoice requests.
  • 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 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:
  • 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.
  • Figure 1 is a schematic diagram of an application scenario of an invoice request processing method provided by an embodiment of this specification
  • FIG. 2 is a schematic flowchart of an invoice request processing method provided by an embodiment of this specification
  • FIG 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.
  • Figure 1 is a schematic diagram of an application scenario of an invoice request processing method provided by the embodiment of this specification.
  • 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).
  • the first participant for example, based on the payment application and transaction application.
  • 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.
  • FIG. 2 is a schematic flowchart of an invoice request processing method provided by an embodiment of this specification.
  • the execution subject of this process can be the target server, or the application program installed on the target server.
  • 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.
  • 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.
  • the first participant is usually a merchant
  • the second participant is usually a consumer
  • 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.
  • 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.
  • the printing, purchase, issuance, acquisition, custody, and cancellation of invoices will be managed and supervised by an authoritative organization.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the preset processing strategy can be set according to actual needs, and there is no specific limit on this.
  • 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.
  • 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.
  • 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.
  • the target transaction may be a transaction initiated by the second party using the transaction application with the first party.
  • 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.
  • the transaction application includes: an e-commerce platform and a small program deployed by the first party at the payment application.
  • Target transactions can be offline transactions.
  • 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.
  • 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.
  • 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.
  • the second participant can use multiple ways to request the issuance of invoice information for the target transaction.
  • obtain The invoicing request message for the target transaction can also be implemented in multiple ways. To facilitate understanding, this is explained.
  • 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.
  • step 204 Determining the initiation time of the invoicing request message specifically includes: determining the occurrence time of the triggering operation.
  • 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.
  • 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.
  • 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.
  • the first participant 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.
  • 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.
  • the remaining time can also be displayed on the target application of the second party.
  • 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.
  • 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. .
  • step 204 Determine the initiation time of the invoicing request message, which may specifically include: determining the occurrence time of the status change operation.
  • 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.
  • 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.
  • 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.
  • the target transaction 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.
  • 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.
  • 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.
  • the prompt information of the remaining time can also be displayed on the second party's target application.
  • both the first invoicing control and the second invoicing control may include a single control or multiple controls, which are not specifically limited.
  • 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.
  • 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.
  • 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.
  • 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 are displayed, which is not specifically limited.
  • the second party 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.
  • 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.
  • 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.
  • the second party 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.
  • 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.
  • the first participant may also take the initiative to partially refund the target transaction.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the occurrence time of the invoice information change operation can be used as the initiation time of the updated invoicing request message.
  • 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.
  • 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.
  • 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.
  • 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.
  • the method may further include: obtaining the invoicing rejection instruction of the first participant for the target transaction.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the invoicing change prompt information 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.
  • 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.
  • the target server verifies whether the first participant has provided the second participant with an invoice implementation method. There can also be multiple types.
  • 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.
  • the first party can issue an invoice based on the invoice issuance function of the merchant client.
  • 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.
  • 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.
  • 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.
  • ERP Enterprise Resource Planning
  • 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.
  • 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.
  • 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.
  • 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.
  • emails delivering electronic invoices, screenshots of application pages, etc. can also be used as delivery proof information for electronic invoices.
  • 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.
  • 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.
  • event monitoring technology is used to decouple the invoice application process from the delayed invoicing compensation process.
  • 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.
  • 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.
  • the first party usually needs to transfer a certain amount of resources to the target server in advance.
  • 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.
  • 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. .
  • 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.
  • the amount of resources to be transferred can also be a specified value.
  • the amount of resources to be transferred can be The amount of resources to be transferred can all be 10 yuan.
  • the calculation method of the amount of resources to be transferred can be set according to actual needs, and is not specifically limited.
  • 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.
  • 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.
  • interception verification is also required to avoid penalty errors and damage to the rights and interests of the first participant.
  • 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.
  • 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.
  • 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.
  • 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.
  • multiple identical invoicing request messages may be repeatedly initiated for the target transaction.
  • 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.
  • the target server may only need to deal with the delay in providing invoices by some merchants.
  • 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.
  • 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.
  • the conditions for prohibiting 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.
  • 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.
  • the target server 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.
  • the invoice application process and the invoice request processing process are decoupled through event monitoring technology.
  • the target server 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.
  • 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.
  • the invoice request processing process may involve execution entities such as the first party, the second party, and the target server.
  • 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.
  • 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.
  • 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.
  • the target server 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.
  • the second party can also actively perform the invoice information change operation without obtaining the invoicing change prompt information.
  • 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.
  • 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.
  • 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.
  • 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.
  • the determining module 404 may be specifically configured to determine the occurrence time of the triggering operation.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the determination module 404 may be specifically used to determine the time when the invoice information change operation occurs.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • PLD Programmable Logic Device
  • FPGA Programmable Gate Array
  • HDL Hardware Description Language
  • HDL High-Speed Integrated Circuit Hardware Description Language
  • ABEL Advanced Boolean Expression Language
  • AHDL Advanced Boolean Expression Language
  • Confluence CUPL
  • HDCal Component Description Language
  • JHDL Java Hardware Description Language
  • Lava Lava
  • Lola MyHDL
  • PALASM RHDL
  • VHDL Very-High-Speed Integrated Circuit Hardware Description Language
  • Verilog Verilog
  • 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.
  • 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.
  • the controller 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.
  • a typical implementation device is a computer.
  • 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.
  • 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.
  • computer-usable storage media including, but not limited to, disk storage, CD-ROM, optical storage, etc.
  • 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.
  • a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile 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.
  • RAM random access memory
  • ROM read-only memory
  • flash RAM flash random access memory
  • 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.
  • PRAM phase change memory
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • RAM random access memory
  • read-only memory read-only memory
  • ROM read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • flash memory or other memory technology
  • compact disc read-only memory CD-ROM
  • DVD digital versatile disc
  • 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.
  • computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
  • 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.
  • computer-usable storage media including, but not limited to, disk storage, CD-ROM, optical storage, etc.
  • the application may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer.
  • 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.
  • program modules may be located in both local and remote computer storage media including storage devices.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • General Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Des modes de réalisation de la présente invention divulguent un procédé, un appareil et un dispositif de traitement de demande de facture. La solution consiste à : après obtention d'un message de demande de facturation destiné à demander à une première partie participante à une transaction cible de fournir des informations de facture correspondant à la transaction cible à une seconde partie participante, déterminer si la première partie participante fournit les informations de facture pendant une première durée après un temps d'initiation du message de demande de facturation ; et si tel n'est pas le cas, traiter la première partie participante.
PCT/CN2023/094046 2022-05-27 2023-05-12 Procédé, appareil et dispositif de traitement de demande de facture WO2023226799A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202210593337.2A CN114997938A (zh) 2022-05-27 2022-05-27 一种发票请求处理方法、装置及设备
CN202210593337.2 2022-05-27

Publications (1)

Publication Number Publication Date
WO2023226799A1 true WO2023226799A1 (fr) 2023-11-30

Family

ID=83029093

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/094046 WO2023226799A1 (fr) 2022-05-27 2023-05-12 Procédé, appareil et dispositif de traitement de demande de facture

Country Status (2)

Country Link
CN (1) CN114997938A (fr)
WO (1) WO2023226799A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114997938A (zh) * 2022-05-27 2022-09-02 支付宝(杭州)信息技术有限公司 一种发票请求处理方法、装置及设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1954332A (zh) * 2004-03-11 2007-04-25 Crs国际Ip有限公司 用于预付资金的方法和系统
US20090089209A1 (en) * 2007-09-28 2009-04-02 The Western Union Company Methods and systems for generating invoices
CN114140182A (zh) * 2021-12-02 2022-03-04 拉扎斯网络科技（上海）有限公司 一种信息交互方法及装置
CN114997938A (zh) * 2022-05-27 2022-09-02 支付宝(杭州)信息技术有限公司 一种发票请求处理方法、装置及设备

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140258104A1 (en) * 2013-03-06 2014-09-11 Bottomline Technologies (De) Inc. Automatic payment component for an electronic invoice payment system
US10163082B1 (en) * 2015-10-26 2018-12-25 Intuit Inc. Gamification of fields in online e-commerce documents
CN111199436A (zh) * 2019-12-31 2020-05-26 航天信息股份有限公司 一种基于移动支付的扫码开票方法及系统
CN111461798B (zh) * 2020-03-31 2022-07-26 好活（昆山）网络科技有限公司 基于大数据的个体户的票务处理方法、装置、介质及设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1954332A (zh) * 2004-03-11 2007-04-25 Crs国际Ip有限公司 用于预付资金的方法和系统
US20090089209A1 (en) * 2007-09-28 2009-04-02 The Western Union Company Methods and systems for generating invoices
CN114140182A (zh) * 2021-12-02 2022-03-04 拉扎斯网络科技（上海）有限公司 一种信息交互方法及装置
CN114997938A (zh) * 2022-05-27 2022-09-02 支付宝(杭州)信息技术有限公司 一种发票请求处理方法、装置及设备

Also Published As

Publication number Publication date
CN114997938A (zh) 2022-09-02

Similar Documents

Publication Publication Date Title
TWI756498B (zh) 資產轉移的回退處理方法及裝置、電子設備
TWI725355B (zh) 資金流轉方法及裝置、電子設備
WO2021244537A1 (fr) Transfert de ressources
TW202001747A (zh) 融資貸款方法和裝置
KR102150747B1 (ko) 트랜잭션 정보 프로세싱 방법 및 장치
US20130036047A1 (en) Method, system and process for centralized management and control of a budget and electronic mass distribution of funds
WO2022247961A1 (fr) Traitement de retenue sur la base d'un code de remboursement
WO2023226799A1 (fr) Procédé, appareil et dispositif de traitement de demande de facture
TW201935373A (zh) 退稅方法、裝置及設備
WO2023226847A1 (fr) Procédés, appareils et dispositif de traitement de demande de retard de facturation
TWI701626B (zh) 資料業務處理方法及裝置
CN114926158A (zh) 一种订单支付方法、装置、存储介质及电子设备
WO2024152846A1 (fr) Procédé et appareil de traitement de paiement
KR102063877B1 (ko) 하도급 신탁 계약을 관리하는 방법 및 상기 방법을 실행시키기 위하여 컴퓨터 판독 가능한 저장 매체에 저장된 컴퓨터 프로그램
JP7330412B1 (ja) 情報処理装置、情報処理方法及び情報処理プログラム
WO2023151438A1 (fr) Traitement d'interaction de paiement
US20230222462A1 (en) Digital engagement platform for payment solutions with cash-enabled multipay
US20130212003A1 (en) Mobile money order
US20240094960A1 (en) Systems and methods for real time access to external resource
JP7113955B1 (ja) 情報処理装置、情報処理方法及び情報処理プログラム
WO2021208755A1 (fr) Traitement de données et paiement
WO2021218667A1 (fr) Déclenchement de tâche de transfert de ressources
KR102337429B1 (ko) 가상계좌 기반의 미성년자 결제 서비스 제공장치
CN113159747B (zh) 一种针对电子交通账户的管理方法、装置及设备
KR102236887B1 (ko) 자부담금 및 국고 보조금을 포함하는 집행금 이체 방법 및 그 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23810872

Country of ref document: EP

Kind code of ref document: A1