CN115345612A - 一种基于电子工牌实现支付和报销的方法及装置 - Google Patents
一种基于电子工牌实现支付和报销的方法及装置 Download PDFInfo
- Publication number
- CN115345612A CN115345612A CN202210845904.9A CN202210845904A CN115345612A CN 115345612 A CN115345612 A CN 115345612A CN 202210845904 A CN202210845904 A CN 202210845904A CN 115345612 A CN115345612 A CN 115345612A
- Authority
- CN
- China
- Prior art keywords
- information
- billing
- bill
- server
- payment
- Prior art date
- Legal status (The legal status 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 status listed.)
- Pending
Links
Images
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
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
- G06Q20/322—Aspects of commerce using mobile devices [M-devices]
-
- 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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
- G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
-
- 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
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- General Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Development Economics (AREA)
- Finance (AREA)
- Economics (AREA)
- Marketing (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
本说明书一个或多个实施例提供一种基于电子工牌实现支付和报销的方法及装置,应用于应用程序的客户端,包括:向服务端发送包含用户信息的电子工牌生成请求,电子工牌生成请求用于指示服务端:确定用户信息对应的企业信息和支付令牌,生成包含企业信息和支付令牌的电子工牌;在通过电子工牌向收款方进行支付操作而产生支付事件的情况下向服务端发起包含企业信息的开票信息推送请求,开票信息推送请求用于指示服务端:将对应于企业信息的开票信息推送至收款方对应的开票系统,以由开票系统根据开票信息开具票据;针对开票系统开具的票据向服务端发起报销请求,报销请求用于指示服务端:根据票据的开票信息,向相应企业提交针对票据的报销审批单。
Description
技术领域
本说明书一个或多个实施例涉及数据传输领域,尤其涉及一种基于电子工牌实现支付和报销的方法及装置。
背景技术
随着经济的飞速发展,支付方式也发生了巨大的变化,从原始的现金支付到刷卡支付再到电子支付,电子支付中的扫码支付已经成为了人们日常生活的主要支付方式。另外,公民为了保护个人的消费权益,在支付完成后通常会选择开具电子票据以作为消费行为的凭证,但是传统的开票方式速度慢、效率低、易出错。
目前,在申请开具电子票据时,需要用户在付款后单独进行开具票据操作以及手动填写开票信息,而且在提交票据进行报销时,也需要用户手动填写报销审批单的信息,这无疑增加了操作的复杂度,影响了用户的使用体验。
发明内容
有鉴于此,本说明书一个或多个实施例提供一种基于电子工牌实现支付和报销的方法及装置,可以解决相关技术中存在的不足。
为实现上述目的,本说明书一个或多个实施例提供技术方案如下:
根据本说明书一个或多个实施例的第一方面,提出了一种基于电子工牌实现支付和报销的方法,应用于应用程序的客户端,所述方法包括:
向服务端发送包含用户信息的电子工牌生成请求,所述电子工牌生成请求用于指示所述服务端:确定所述用户信息对应的企业信息和支付令牌,并生成包含所述企业信息和所述支付令牌的电子工牌;
在通过所述电子工牌向收款方进行支付操作而产生支付事件的情况下,根据所述电子工牌所含的企业信息,向所述服务端发起包含所述企业信息的开票信息推送请求,所述开票信息推送请求用于指示所述服务端:将对应于所述企业信息的开票信息推送至所述收款方对应的开票系统,以由所述开票系统根据所述开票信息开具票据;
针对所述开票系统开具的票据向所述服务端发起报销请求,所述报销请求用于指示所述服务端:根据所述票据所含的所述开票信息,向相应企业提交针对所述票据的报销审批单。
根据本说明书一个或多个实施例的第二方面,提出了一种基于电子工牌实现支付和报销的方法,应用于应用程序的服务端,所述方法包括:
响应于客户端发送的包含用户信息的电子工牌生成请求,确定所述用户信息对应的企业信息和支付令牌,并生成包含所述企业信息和所述支付令牌的电子工牌;
接收所述客户端发送的包含所述企业信息的开票信息推送请求,所述开票信息推送请求由所述客户端在通过所述电子工牌向收款方进行支付操作而产生支付事件的情况下发起;
将对应于所述企业信息的开票信息推送至所述收款方对应的开票系统,以由所述开票系统根据所述开票信息开具票据;
响应于所述客户端针对所述开票系统开具的票据发起的报销请求,根据所述票据所含的所述开票信息,向相应企业提交针对所述票据的报销审批单。
根据本说明书一个或多个实施例的第三方面,提出了一种基于电子工牌实现支付和报销的装置,应用于应用程序的客户端,所述装置包括:
发送单元:向服务端发送包含用户信息的电子工牌生成请求,所述电子工牌生成请求用于指示所述服务端:确定所述用户信息对应的企业信息和支付令牌,并生成包含所述企业信息和所述支付令牌的电子工牌;
第一发起单元:在通过所述电子工牌向收款方进行支付操作而产生支付事件的情况下,根据所述电子工牌所含的企业信息,向所述服务端发起包含所述企业信息的开票信息推送请求,所述开票信息推送请求用于指示所述服务端:将对应于所述企业信息的开票信息推送至所述收款方对应的开票系统,以由所述开票系统根据所述开票信息开具票据;
第二发起单元:针对所述开票系统开具的票据向所述服务端发起报销请求,所述报销请求用于指示所述服务端:根据所述票据所含的所述开票信息,向相应企业提交针对所述票据的报销审批单。
根据本说明书一个或多个实施例的第四方面,提出了一种基于电子工牌实现支付和报销的装置,应用于应用程序的服务端,所述装置包括:
生成单元:响应于客户端发送的包含用户信息的电子工牌生成请求,确定所述用户信息对应的企业信息和支付令牌,并生成包含所述企业信息和所述支付令牌的电子工牌;
接收单元:接收所述客户端发送的包含所述企业信息的开票信息推送请求,所述开票信息推送请求由所述客户端在通过所述电子工牌向收款方进行支付操作而产生支付事件的情况下发起;
推送单元:将对应于所述企业信息的开票信息推送至所述收款方对应的开票系统,以由所述开票系统根据所述开票信息开具票据;
提交单元:响应于所述客户端针对所述开票系统开具的票据发起的报销请求,根据所述票据所含的所述开票信息,向相应企业提交针对所述票据的报销审批单。
根据本说明书一个或多个实施例的第五方面,提出了一种电子设备,包括:
处理器;
用于存储处理器可执行指令的存储器;
其中,所述处理器通过运行所述可执行指令以实现如第一方面或第二方面所述的方法。
根据本说明书一个或多个实施例的第六方面,提出了一种计算机可读存储介质,其上存储有计算机指令,该指令被处理器执行时实现如第一方面或第二方面所述方法的步骤。
由以上技术方案可见,本说明书一个或多个实施例中,应用程序的客户端可以向服务端发送包含用户信息的电子工牌生成请求以生成包含用户信息对应的企业信息和支付令牌的电子工牌,用户可以使用该电子工牌对支付事件的收款方进行支付操作,在此情况下,客户端可以向服务端发起包含企业信息的开票信息推送请求,使得服务端可以企业信息对应的开票信息推送至收款方对应的开票系统,客户端还可以进一步针对开票系统开具的票据向服务端发起报销请求,使得服务端可以根据票据所含开票信息,向相应企业提交该票据的报销审核单。以上过程基于电子工牌实现了企业信息及其对应的开票信息在支付系统、开票系统以及报销系统之间的数据穿透,从而将支付与报销一体化,避免用户手动填写开票信息和报销审批单,简化用户操作复杂度,提升用户的操作效率。
附图说明
图1是一示例性实施例提供的一种基于电子工牌实现支付和报销的方法的系统架构图。
图2是一示例性实施例提供的一种基于电子工牌实现支付和报销的方法的流程图。
图3是一示例性实施例提供的一种电子工牌界面的示意图。
图4是一示例性实施例提供的一种开具发票操作界面的示意图。
图5a是一示例性实施例提供的一种开票信息选择界面的示意图。
图5b是一示例性实施例提供的一种开票信息界面的示意图。
图6是一示例性实施例提供的一种发票夹界面的示意图。
图7是一示例性实施例提供的又一种基于电子工牌实现支付和报销的方法的流程图。
图8是一示例性实施例提供的一种审批单界面的示意图。
图9是一示例性实施例提供的一种设备的示意结构图。
图10是一示例性实施例提供的一种基于电子工牌实现支付和报销的装置的框图。
图11是一示例性实施例提供的又一种基于电子工牌实现支付和报销的装置的框图。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书一个或多个实施例相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本说明书一个或多个实施例的一些方面相一致的装置和方法的例子。
需要说明的是:在其他实施例中并不一定按照本说明书示出和描述的顺序来执行相应方法的步骤。在一些其他实施例中,其方法所包括的步骤可以比本说明书所描述的更多或更少。此外,本说明书中所描述的单个步骤,在其他实施例中可能被分解为多个步骤进行描述;而本说明书中所描述的多个步骤,在其他实施例中也可能被合并为单个步骤进行描述。
为对本说明书一个或多个实施例进行进一步说明,提供下列实施例:
图1是一示例性实施例提供的一种基于电子工牌实现支付和报销的方法的系统架构图。如图1所示,可以包括手机11、服务器12和网络设备13。
手机11是本地用户可以使用的一种类型的电子设备。当然本说明书中所涉及的电子设备并不限于此,例如还可以包括:平板设备、笔记本电脑、掌上电脑(PDAs,PersonalDigital Assistants)、可穿戴设备(如智能眼镜、智能手表等)等,本说明书并不对此进行限制。在运行过程中,手机11上运行有应用程序的客户端程序,使得该手机11被配置为该应用程序的客户端。该客户端程序可以实现向服务端发送包含用户信息的电子工牌生成请求的发送功能,使得手机11可以基于该发送功能指示服务端确定用户信息对应的企业信息和支付令牌,并生成包含企业信息和支付令牌的电子工牌,使得用户可以使用该电子工牌向收款方进行支付操作;该客户端程序还可以实现向服务端发起开票信息推送请求和报销请求的发起功能,该发起功能可以向服务端发起包含企业信息的开票信息推送请求,以指示服务端确定企业信息对应的开票信息,并将开票信息推送至收款方的开票系统,在开票系统开具票据后,客户端可以针对开具的票据向服务端发起报销请求,以指示服务端向相应企业提交报销审批单。服务器12可以为包含一独立主机的物理服务器,或者主机集群承载的虚拟服务器。服务器12上运行有应用程序的服务端程序,使得该服务器12被配置为应用程序的服务端。该服务端程序可以配合手机11运行,譬如可以接收手机11发送的包含用户信息的电子工牌生成请求,生成包含用户信息对应的企业信息和支付令牌的电子工牌,还可以接收手机11发起的开票信息推送请求,将企业信息对应的开票信息其推送至收款方对应的开票系统,或者可以接收手机11发起的针对票据的报销请求,向相应企业提交针对该票据的报销审批单。
网络设备13可以与手机11类似,是支付事件的收款方使用的一种类型的电子设备;也可以与服务器12类似,是收款方对应的具有开票功能的服务器。该网络设备13上可以运行有开票对应的客户端程序,或者可以运行有开具票据对应的服务端程序,上述任何情况都可以使得该网络设备13可以基于服务器12发送的开票信息生成票据,并将该票据返回服务器12以供用户使用。
对于手机11、服务器12和网络设备13之间进行的交互方式,可以包括多种类型的有线或无线交互,本说明书并不对此进行限制。
图2是一示例性实施例提供的一种基于电子工牌实现支付和报销的方法的流程图。如图2所示,该方法应用于应用程序的客户端,该方法可以包括以下步骤:
步骤202,向服务端发送包含用户信息的电子工牌生成请求,所述电子工牌生成请求用于指示所述服务端:确定所述用户信息对应的企业信息和支付令牌,并生成包含所述企业信息和所述支付令牌的电子工牌。
用户信息为客户端对应的用户的信息,例如用户ID等,客户端对应的用户往往为支付事件的付款方,与之对用的是支付事件的收款方。支付事件可以由付款方以电子工牌的方式向收款方进行支付操作而产生,具体使用电子工牌支付的方式有很多,例如收款方使用扫描设备扫描电子工牌进行支付,或者付款方将电子工牌以截图的形式发送给收款方以进行支付,本说明书并不对此进行限制。
电子工牌中包含用户信息对应的企业信息,该企业信息可以包括用户所在公司或者组织的名称,例如xx科技有限公司,也可以包括用户所在公司的ID信息。当然,企业信息的具体内容并不限于此,本说明书并不对其进行限制。
在一实施例中,用户可以对企业信息进行选择,服务端可以根据用户的选择结果生成电子工牌。下面结合图3对该实施例进行详细介绍,图3是一示例性实施例提供的一种电子工牌界面的示意图,如图3所示,该电子工牌界面包括:用户小明302、电子工牌304、企业选项一306和企业选项二308。用户可以通过点击企业选项一306,选择生成xx科技有限公司对应的电子工牌,也可以通过点击企业选项二308,选择生成AA科技大会对应的电子工牌。该实施例通过提供用户企业信息的选项,使得用户可以选择企业信息生成对应的电子工牌,从而提升了用户的使用体验。
步骤204,在通过所述电子工牌向收款方进行支付操作而产生支付事件的情况下,根据所述电子工牌所含的企业信息,向所述服务端发起包含所述企业信息的开票信息推送请求,所述开票信息推送请求用于指示所述服务端:将对应于所述企业信息的开票信息推送至所述收款方对应的开票系统,以由所述开票系统根据所述开票信息开具票据。
在通过电子工牌向收款方进行支付操作而产生支付事件的情况下,可以是客户端自动向服务端发起开票信息推送请求,也可以是用户的某一触发操作触发客户端发起请求,本说明书并不对此进行限制。
在一实施例中,响应于检测到所述票据开具操作,向所述服务端发起开票信息推送请求。上述票据开具操作可以为用户点击应用程序中的“开具票据”选项,或者用户通过语音等方式选择开具票据,本说明书并不对此进行限制。
下面以发票为例,结合图4对该实施例进行详细介绍。图4是一示例性实施例提供的一种开具发票操作界面的示意图,如图4所示,该开具发票操作界面包括:支付金额402、支付方式404、收款方406和开发票按钮408。在用户使用电子工牌进行支付并支付成功后,客户端可以将该开具发票操作界面展示给用户。用户可以在该界面查看支付事件的账单信息,例如此次支付事件的支付金额为12元,支付方式为电子工牌和其他方式,收款方为“某某餐厅”。用户还可以通过点击开发票按钮408,开具针对此次支付事件的发票,该点击开发票按钮408的操作即为发票开具操作。
客户端在检测到票据开具操作后,可以向服务端发起开票信息推送请求。服务端可以基于电子工牌包含的企业信息确定开票信息。开票信息可以根据票据类型不同,包括不同的信息,例如:在票据为发票的情况下,开票信息可以为发票抬头、税号等,关于开票信息的具体内容本说明书并不进行限制。企业管理员在服务端维护有企业信息与开票信息的对应数据列表,企业管理员可以在通过对该列表的修改,实现对开票信息的增加、删除、修改以及查看。企业信息和开票信息可以是一一对应的,也可以不是。为了方便理解,下面的实施例中均以发票为例进行介绍。
在一实施例中,客户端可以接收所述服务端根据所述开票信息推送请求返回的候选开票信息,所述候选开票信息由所述服务端根据所述电子工牌包含的企业信息而确定;根据所述用户对所述候选开票信息的选择结果,将被选取的开票信息发送至所述服务端,以由所述服务端推送至所述开票系统。
下面结合图5a、图5b,对该实施例进行详细介绍,图5a是一示例性实施例提供的一种开票信息选择界面的示意图,如图5a所示,该开票信息选择界面包括:开票选项一502、开票选项二504、勾选圈506、提交发票按钮508和新增发票抬头按钮510。用户可以在该界面中查看电子工牌中包含的企业信息对应的开票信息,如开票选项一502和开票选项二504,每一开票选项的左侧均存在一个勾选圈供用户勾选。如图5a所示,用户点击勾选开票选项一502代表的“xx科技有限公司”,接着用户可以通过点击提交发票按钮508,确定开票选项一502作为开票信息。当然,用户也可以点击开票选项从而打开如图5b所示的开票信息界面,查看开票选项对应的开票信息的具体内容。图5b是一示例性实施例提供的一种开票信息界面的示意图,该开票信息界面包括:开票信息展示区域512和开票信息二维码514。用户可以在开票信息展示区域512中查看开票信息的具体内容,还可以直接向收款方出示开票信息二维码514,以使收款方对二维码进行扫描开票。若展示的开票选项中没有用户想要的开票信息,那么用户可以点击新增发票抬头按钮510,手动输入发票抬头等信息作为开票信息。该实施例提供用户开票信息的选项,使得用户可以通过点击开票选项确定开票信息,从而增加了用户选择发票抬头的自由度,提升了用户的使用体验。
服务端将开票信息推送至收款方对应的开票系统的方式有很多,例如可以直接将开票信息以报文形式发送至开票系统,也可以如图5b所示,通过收款方扫描开票信息对应的二维码的方式推送开票信息,本说明书并不对此进行限制。
收款方对应的开票系统可以接收开票信息,并生成对应的票据,该开票系统可以将开具的票据返回服务端,也可以直接返回客户端。客户端可以获取开票系统根据开票信息开具的票据;其中,获取的票据由开票系统发送至客户端,或者由开票系统发送至服务端并由服务端转发至客户端。针对已开具的票据,客户端可以选择进行报销。
步骤206,针对所述开票系统开具的票据向所述服务端发起报销请求,所述报销请求用于指示所述服务端:根据所述票据所含的所述开票信息,向相应企业提交针对所述票据的报销审批单。
进一步的,所述审批单中还包括:由所述服务端添加的所述票据对应的支付事件的账单信息。服务端不仅可以将票据直接添加至审批单中,还可以将票据对应的支付事件的账单信息直接填入审批单中。该账单信息可以包括:交易金额、交易时间收款方等等,本说明书并不对账单信息的具体内容进行限制。在一实施例中,票据可以被存储于票据夹中,该票据夹中可以存在多次支付事件对应的票据,用户可以针对票据夹中的任一票据进行报销。
依旧以发票为例,结合图6对该实施例进行详细介绍,图6是一示例性实施例提供的一种发票夹界面的示意图,如图6所示,该发票夹界面包括:发票选项一602、发票选项二604、报销情况606和提交报销按钮608。用户可以通过勾选发票选项,对发票夹中的发票进行选择,每一发票选项都包含报销情况606,以供用户查看该发票选项对应的发票的报销情况,若报销情况为已报销,则表明该发票已被报销,无法被提交,若报销情况为未报销,则表明该发票未被报销,可以被提交报销。如图6所示,用户点击勾选发票选项一602,接着可以通过点击提交报销按钮608,确定报销的发票及发票对应的支付事件的账单信息。关于服务端将发票或者账单信息填入审批单的具体内容,本说明书将在后文进行详细介绍,此处不再赘述。
该实施例通过将已开具的发票存储于发票夹中,使得用户可以随时选择发票进行报销,从而增加用户报销操作的灵活性,提升了用户的使用体验。
图7是一示例性实施例提供的又一种基于电子工牌实现支付和报销的方法的流程图,如图7所示,该方法应用于应用程序的服务端,该方法可以包括以下步骤:
步骤702,响应于客户端发送的包含用户信息的电子工牌生成请求,确定所述用户信息对应的企业信息和支付令牌,并生成包含所述企业信息和所述支付令牌的电子工牌。
除企业信息之外,电子工牌还可以包含支付令牌,该支付令牌与用户信息相对应。在后续的支付事件中,用户可以基于电子工牌的支付令牌向收款方进行支付操作。当然电子工牌中包含的信息不限于此,例如用户对应账户的余额等都可以被包含于电子工牌中,本说明书并不对此进行限制。
步骤704,接收所述客户端发送的包含所述企业信息的开票信息推送请求,所述开票信息推送请求由所述客户端在通过所述电子工牌向收款方进行支付操作而产生支付事件的情况下发起。
步骤706,将对应于所述企业信息的开票信息推送至所述收款方对应的开票系统,以由所述开票系统根据所述开票信息开具票据。
如前所述,在用户所属企业对应多个开票信息的情况下,服务端可以基于所述电子工牌包含的企业信息确定候选开票信息,并将所述候选开票信息发送至所述客户端;接收所述客户端返回的被选取的开票信息。
在服务端将开票信息发送至收款方对应的开票系统后,开票系统可以将生成的票据直接返回至客户端,也可以返回至服务端。在一实施例中,服务端可以接收所述开票系统根据所述开票信息开具并返回的票据,并将该票据转发至所述客户端。
步骤708,响应于所述客户端针对所述开票系统开具的票据发起的报销请求,根据所述票据所含的所述开票信息,向相应企业提交针对所述票据的报销审批单。
进一步的,服务端可以将所述票据对应的支付事件的账单信息填入所述审批单。下面以发票为例,结合图8对服务端将发票或者账单信息填入审批单的具体内容进行详细介绍,图8是一示例性实施例提供的一种审批单界面的示意图,如图8所示,该审批单界面包括:报销金额展示框802、报销类别展示框804、费用明细展示框806、发票808、增加报销明细按钮810、审批人812和提交按钮814。服务端可以自动将发票对应的支付事件的账单信息填入审批单中,如发票808对应的账单信息分别被填入报销金额展示框802和报销类别展示框804,除这两项必需信息之外,用户可以选择在费用明细展示框806输入此次支付事件对应的费用明细,还可以点击增加报销明细按钮810新增明细内容,在信息填写完成后,用户可以点击提交按钮814,将该审批单提交至审批人812进行审批。
该实施例通过将发票以及发票对应的账单信息直接添加至审批单,使得用户可以在无需填写交易明细的情况下,直接提交审批单进行报销,简化了用户操作的复杂度,提升了操作效率。
图9是一示例性实施例提供的一种设备的示意结构图。请参考图9,在硬件层面,该设备包括处理器902、内部总线904、网络接口906、内存908以及非易失性存储器910,当然还可能包括其他功能所需要的硬件。本说明书一个或多个实施例可以基于软件方式来实现,比如由处理器902从非易失性存储器910中读取对应的计算机程序到内存908中然后运行。当然,除了软件实现方式之外,本说明书一个或多个实施例并不排除其他实现方式,比如逻辑器件抑或软硬件结合的方式等等,也就是说以下处理流程的执行主体并不限定于各个逻辑单元,也可以是硬件或逻辑器件。
请参考图10,一种基于电子工牌实现支付和报销的装置可以应用于如图10所示的设备中,以实现本说明书的技术方案。其中,该基于电子工牌实现支付和报销的装置应用于应用程序的客户端,该装置可以包括:
第一发送单元1002,用于向服务端发送包含用户信息的电子工牌生成请求,所述电子工牌生成请求用于指示所述服务端:确定所述用户信息对应的企业信息和支付令牌,并生成包含所述企业信息和所述支付令牌的电子工牌;
第一发起单元1004,用于在通过所述电子工牌向收款方进行支付操作而产生支付事件的情况下,根据所述电子工牌所含的企业信息,向所述服务端发起包含所述企业信息的开票信息推送请求,所述开票信息推送请求用于指示所述服务端:将对应于所述企业信息的开票信息推送至所述收款方对应的开票系统,以由所述开票系统根据所述开票信息开具票据;
第二发起单元1006,用于针对所述开票系统开具的票据向所述服务端发起报销请求,所述报销请求用于指示所述服务端:根据所述票据所含的所述开票信息,向相应企业提交针对所述票据的报销审批单。
可选的,还包括:
第一接收单元1008,用于接收所述服务端根据所述开票信息推送请求返回的候选开票信息,所述候选开票信息由所述服务端根据所述电子工牌包含的企业信息而确定;
第二发送单元1010,用于根据所述用户对候选开票信息的选择结果,将被选取的开票信息发送至所述服务端,以由所述服务端推送至所述开票系统。
可选的,还包括:
获取单元1012,用于获取所述开票系统根据所述开票信息开具的票据;
其中,获取的票据由所述开票系统发送至所述客户端,或者由所述开票系统发送至所述服务端并由所述服务端转发至所述客户端。
可选的,所述审批单中还包括:由所述服务端添加的所述票据对应的支付事件的账单信息。
请参考图11,又一种基于电子工牌实现支付和报销的装置可以应用于如图11所示的设备中,以实现本说明书的技术方案。其中,该基于电子工牌实现支付和报销的装置应用于应用程序的服务端,该装置可以包括:
生成单元1102,用于响应于客户端发送的包含用户信息的电子工牌生成请求,确定所述用户信息对应的企业信息和支付令牌,并生成包含所述企业信息和所述支付令牌的电子工牌;
第二接收单元1104,用于接收所述客户端发送的包含所述企业信息的开票信息推送请求,所述开票信息推送请求由所述客户端在通过所述电子工牌向收款方进行支付操作而产生支付事件的情况下发起;
推送单元1106,用于将对应于所述企业信息的开票信息推送至所述收款方对应的开票系统,以由所述开票系统根据所述开票信息开具票据;
提交单元1108,用于响应于所述客户端针对所述开票系统开具的票据发起的报销请求,根据所述票据所含的所述开票信息,向相应企业提交针对所述票据的报销审批单。
可选的,所述推送单元1106具体用于:
基于所述电子工牌包含的企业信息确定候选开票信息,并将所述候选开票信息发送至所述客户端;
接收所述客户端返回的被选取的开票信息。
可选的,还包括:
转发单元1110,用于接收所述开票系统根据所述开票信息开具并返回的票据,并将该票据转发至所述客户端。
可选的,还包括:
填写单元1112,用于将所述票据对应的支付事件的账单信息填入所述审批单。
上述实施例阐明的系统、装置、模块或单元,具体可以由计算机芯片或实体实现,或者由具有某种功能的产品来实现。一种典型的实现设备为计算机,计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
在一个典型的配置中,计算机包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带、磁盘存储、量子存储器、基于石墨烯的存储介质或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
在本说明书一个或多个实施例使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本说明书一个或多个实施例可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本说明书一个或多个实施例范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
以上所述仅为本说明书一个或多个实施例的较佳实施例而已,并不用以限制本说明书一个或多个实施例,凡在本说明书一个或多个实施例的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本说明书一个或多个实施例保护的范围之内。
Claims (12)
1.一种基于电子工牌实现支付和报销的方法,其特征在于,应用于应用程序的客户端,所述方法包括:
向服务端发送包含用户信息的电子工牌生成请求,所述电子工牌生成请求用于指示所述服务端:确定所述用户信息对应的企业信息和支付令牌,并生成包含所述企业信息和所述支付令牌的电子工牌;
在通过所述电子工牌向收款方进行支付操作而产生支付事件的情况下,根据所述电子工牌所含的企业信息,向所述服务端发起包含所述企业信息的开票信息推送请求,所述开票信息推送请求用于指示所述服务端:将对应于所述企业信息的开票信息推送至所述收款方对应的开票系统,以由所述开票系统根据所述开票信息开具票据;
针对所述开票系统开具的票据向所述服务端发起报销请求,所述报销请求用于指示所述服务端:根据所述票据所含的所述开票信息,向相应企业提交针对所述票据的报销审批单。
2.根据权利要求1所述的方法,其特征在于,还包括:
接收所述服务端根据所述开票信息推送请求返回的候选开票信息,所述候选开票信息由所述服务端根据所述电子工牌包含的企业信息而确定;
根据所述用户对候选开票信息的选择结果,将被选取的开票信息发送至所述服务端,以由所述服务端推送至所述开票系统。
3.根据权利要求1所述的方法,其特征在于,还包括:
获取所述开票系统根据所述开票信息开具的票据;
其中,获取的票据由所述开票系统发送至所述客户端,或者由所述开票系统发送至所述服务端并由所述服务端转发至所述客户端。
4.根据权利要求1所述的方法,其特征在于,所述审批单中还包括:由所述服务端添加的所述票据对应的支付事件的账单信息。
5.一种基于电子工牌实现支付和报销的方法,其特征在于,应用于应用程序的服务端,所述方法包括:
响应于客户端发送的包含用户信息的电子工牌生成请求,确定所述用户信息对应的企业信息和支付令牌,并生成包含所述企业信息和所述支付令牌的电子工牌;
接收所述客户端发送的包含所述企业信息的开票信息推送请求,所述开票信息推送请求由所述客户端在通过所述电子工牌向收款方进行支付操作而产生支付事件的情况下发起;
将对应于所述企业信息的开票信息推送至所述收款方对应的开票系统,以由所述开票系统根据所述开票信息开具票据;
响应于所述客户端针对所述开票系统开具的票据发起的报销请求,根据所述票据所含的所述开票信息,向相应企业提交针对所述票据的报销审批单。
6.根据权利要求5所述的方法,其特征在于,所述将对应于所述企业信息的开票信息推送至所述收款方对应的开票系统,包括:
基于所述电子工牌包含的企业信息确定候选开票信息,并将所述候选开票信息发送至所述客户端;
接收所述客户端返回的被选取的开票信息。
7.根据权利要求5所述的方法,其特征在于,还包括:
接收所述开票系统根据所述开票信息开具并返回的票据,并将该票据转发至所述客户端。
8.根据权利要求5所述的方法,其特征在于,还包括:
将所述票据对应的支付事件的账单信息填入所述审批单。
9.一种基于电子工牌实现支付和报销的装置,其特征在于,应用于应用程序的客户端,所述装置包括:
第一发送单元:向服务端发送包含用户信息的电子工牌生成请求,所述电子工牌生成请求用于指示所述服务端:确定所述用户信息对应的企业信息和支付令牌,并生成包含所述企业信息和所述支付令牌的电子工牌;
第一发起单元:在通过所述电子工牌向收款方进行支付操作而产生支付事件的情况下,根据所述电子工牌所含的企业信息,向所述服务端发起包含所述企业信息的开票信息推送请求,所述开票信息推送请求用于指示所述服务端:将对应于所述企业信息的开票信息推送至所述收款方对应的开票系统,以由所述开票系统根据所述开票信息开具票据;
第二发起单元:针对所述开票系统开具的票据向所述服务端发起报销请求,所述报销请求用于指示所述服务端:根据所述票据所含的所述开票信息,向相应企业提交针对所述票据的报销审批单。
10.一种基于电子工牌实现支付和报销的装置,其特征在于,应用于应用程序的服务端,所述装置包括:
生成单元:响应于客户端发送的包含用户信息的电子工牌生成请求,确定所述用户信息对应的企业信息和支付令牌,并生成包含所述企业信息和所述支付令牌的电子工牌;
第二接收单元:接收所述客户端发送的包含所述企业信息的开票信息推送请求,所述开票信息推送请求由所述客户端在通过所述电子工牌向收款方进行支付操作而产生支付事件的情况下发起;
推送单元:将对应于所述企业信息的开票信息推送至所述收款方对应的开票系统,以由所述开票系统根据所述开票信息开具票据;
提交单元:响应于所述客户端针对所述开票系统开具的票据发起的报销请求,根据所述票据所含的所述开票信息,向相应企业提交针对所述票据的报销审批单。
11.一种电子设备,其特征在于,包括:
处理器;
用于存储处理器可执行指令的存储器;
其中,所述处理器通过运行所述可执行指令以实现如权利要求1-8中任一项所述的方法。
12.一种计算机可读存储介质,其上存储有计算机指令,其特征在于,该指令被处理器执行时实现如权利要求1-8中任一项所述方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210845904.9A CN115345612A (zh) | 2022-07-18 | 2022-07-18 | 一种基于电子工牌实现支付和报销的方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210845904.9A CN115345612A (zh) | 2022-07-18 | 2022-07-18 | 一种基于电子工牌实现支付和报销的方法及装置 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN115345612A true CN115345612A (zh) | 2022-11-15 |
Family
ID=83950102
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210845904.9A Pending CN115345612A (zh) | 2022-07-18 | 2022-07-18 | 一种基于电子工牌实现支付和报销的方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115345612A (zh) |
-
2022
- 2022-07-18 CN CN202210845904.9A patent/CN115345612A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10552808B1 (en) | Payment via messaging application | |
US8504450B2 (en) | Mobile remittances/payments | |
US20120221446A1 (en) | E-receipts collection and management system | |
US20090164374A1 (en) | System and Methods for One Time Check Numbers | |
US10430771B2 (en) | Systems and methods for payment processing on platforms | |
WO2022247968A1 (zh) | 数据处理 | |
US20140372288A1 (en) | Methods and systems for electronic monetary payments | |
US8275708B1 (en) | Systems and methods for automatic payment plan | |
EP3588414A1 (en) | Aggregated transaction processing | |
WO2021129188A1 (zh) | 基于图形码的业务处理方法及装置、电子设备、存储介质 | |
US20150363752A1 (en) | Payment network with service provider directory function | |
US20230016065A1 (en) | Frictionless payment system | |
US20210209600A1 (en) | Systems and methods for providing a reputation score for an entity | |
US20130080301A1 (en) | One-step posting for approval-based ledger transactions | |
US11403617B2 (en) | Wallet system and non-transitory storage medium | |
US20100082482A1 (en) | Systems and Methods for Aggregating and Donating Dormant Prepaid Card Amounts | |
US20240029053A1 (en) | Provisioning of payment acceptance to payment account holders | |
CN115345612A (zh) | 一种基于电子工牌实现支付和报销的方法及装置 | |
KR20170103907A (ko) | 연계된 개인 식별 및 계좌 회수 | |
US11954661B1 (en) | Assessing validity of mail item | |
US20210374711A1 (en) | Information processing system, server, and computer readable recording medium | |
CN113094414A (zh) | 流转图谱生成方法及装置 | |
TWI836075B (zh) | 基於圖形碼的業務處理方法及裝置、電子設備、儲存媒體 | |
US20230060707A1 (en) | Systems and methods for including a data acceptance condition in a data transfer proposal | |
CN111522799B (zh) | 用户数据的升级方法及装置、电子设备、存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |