本申请涉及数据处理领域,尤其涉及一种资金追偿的方法及装置。
背景技术:
随着互联网支付的日益普及,通过第三方支付系统进行的各种业务层出不穷。在一些业务场景中,业务系统在特定条件下会为用户或商户先行垫付资金,然后通过支付系统向预授权的账户进行资金追偿。
例如,当具有极速退款资质的用户退货时,处理退货的业务系统可以从商户的保证金账户中先行将需要退还的款项通过支付系统支付给用户,然后向支付系统提交追偿申请,请求支付系统从商户的预授权账户中追偿保证金不足的部分。
现有技术中,每个业务系统分别进行各自的资金追偿,这样每个业务系统都需要实现资金追偿的功能,造成了大量的重复劳动。另外,支付系统在针对某个业务系统的追偿请求进行资金操作时,需要对一些与欠款金额或账户金额相关的变量加锁;随着进行追偿请求的业务系统数量的增加,资金操作因这些变量处于加锁状态而失败的可能性也不断提高,重复进行追偿请求会降低业务系统和支付系统的性能。
技术实现要素:
有鉴于此,本申请提供一种资金追偿的方法,包括:
接收并保存业务系统发送的欠款明细;
筛选满足追偿申请条件的欠款明细,生成追偿申请单;
根据追偿申请单进行资金操作;
按照预置的资金回填规则,将获得的资金分配给用于生成追偿申请单的欠款明细。
本申请还提供了一种资金追偿的装置,包括:
欠款明细接收单元,用于接收并保存业务系统发送的欠款明细;
追偿申请生成单元,用于筛选满足追偿申请条件的欠款明细,生成追偿申请单;
资金操作单元,用于根据追偿申请单进行资金操作;
资金分配单元,用于按照预置的资金回填规则,将获得的资金分配给用于生成追偿申请单的欠款明细。
由以上技术方案可见,本申请的实施例通过将各个业务系统的欠款明细集中后统一进行追偿,不再需要每个业务系统分别实现追偿功能,避免了大量的重复劳动,提高了业务系统的性能;根据欠款明细生成追偿申请单后进行统一的资金操作避免了针对支付系统的来自多个业务系统的大量并发追偿申请,降低了支付系统的负荷。
附图说明
图1是现有技术中一种实现资金追偿的网络结构图;
图2是本申请实施例中一种实现资金追偿的网络结构示例图;
图3是本申请实施例中另一种实现资金追偿的网络结构示例图;
图4是本申请实施例中一种资金追偿方法的流程图;
图5是本申请应用示例中一种追偿系统的功能模块示意图;
图6是的一种服务器的硬件结构图;
图7是本申请实施例提供的一种资金追偿的装置的逻辑结构图。
具体实施方式
现有技术中,每个需要进行资金追偿的业务系统都包括用于追偿的软件 模块,如图1所示,这些软件模块通过与支付系统交互来实现所在业务系统的资金追偿。本申请的实施例提出一种新的资金追偿方法,通过统一的追偿机制来为各个业务系统提供资金追偿接口,不再需要由每个业务系统分别实现追偿功能。
本申请实施例中的追偿方法可以独立运行在逻辑服务器(如虚拟机、服务器集群等)或物理服务器上,例如,在图2所示网络中,应用本申请实施例的追偿系统连接在业务系统和支付系统之间,为业务系统实现资金追偿。本申请实施例中的追偿方法也可以作为支付系统中的一个组成部分来运行,例如图3所示的网络中为多个业务系统进行追偿的软件模块。为表述方便,以下将运行本申请实施例方法的主体称为追偿系统。
本实施例中,资金追偿方法的流程如图4所示。
步骤410,接收并保存业务系统发送的欠款明细。
当业务系统发生需要进行资金追偿的业务项目时,生成欠款明细发送给追偿系统。欠款明细的格式通用于各个业务系统,每条欠款明细包括欠款金额、以及扣款的预授权账户或者其他用来确定从哪个预授权账户扣款的信息,此外还可以包括其他信息,如业务类型、欠款发生的时间、追偿时限等。欠款明细中的具体内容可以根据实际应用场景的需要来确定。
各个业务系统可以随时将生成的欠款明细发送给追偿系统,也可以以一定时间为周期、或以一定欠款明细条数为周期向追偿系统发送欠款明细。追偿系统保存从各个业务系统收到的欠款明细。
步骤420,筛选满足追偿申请条件的欠款明细,生成追偿申请单。
管理员可以设置并保存追偿申请条件,追偿系统读取这些追偿申请条件,在从业务系统接收的欠款明细中将符合追偿申请条件的欠款明细筛选出来,根据筛选出的欠款明细生成追偿申请单。
通常可以利用欠款明细中的内容来设置追偿申请条件,例如,追偿申请条件可以是欠款时间条件、业务类型条件、或欠款金额条件,也可以是以上各个条件的组合。具体而言,追偿申请条件可以是欠款时间为某个月,可以 是欠款金额小于某个设定值,可以是设定业务类型和欠款时间为设定区间等等。
在一些应用场景中,可以预置调度规则,由追偿系统按照调度规则,从欠款明细中筛选满足追偿申请条件的明细条目,来生成追偿申请单。例如,调度规则可以包括设定的时间频率和设定的预授权账户数量,当调度周期到时,追偿系统从满足追偿申请条件的欠款明细中取出针对设定数量的预授权账户的欠款明细,用取出的欠款明细来生成追偿申请单。
追偿申请单中包括追偿系统通过支付系统追索资金所需的信息,如预授权账户、以及某一个预授权账户在本次追偿中需要追偿的总金额。在追偿系统将筛选出的欠款明细生成追偿申请单的过程中,可以将针对一个预授权账户的多个欠款明细的欠款金额进行汇总,这样追偿系统与支付系统之间只需进行一次资金操作即可完成多个欠款明细的追偿,减少了支付系统的操作,提高了支付系统的性能。
步骤430,根据追偿申请单进行资金操作。
根据追偿申请单,追偿系统向支付系统提出追偿申请,与支付系统之间进行资金操作,获得追偿资金。提出追偿申请以及资金操作的过程可以参照现有技术来进行,不再赘述。
步骤440,按照预置的资金回填规则,将获得的资金分配给用于生成追偿申请单的欠款明细。
如果预授权账户中的余额小于在一次追偿申请中该预授权账户需要扣除的总金额,这次追偿将无法获得足额的资金。根据实际应用的需求,对这种情况可以扣除预授权账户中能够扣除的最大金额,也可以不扣除。
对获得的追偿资金,追偿系统按照预置的资金回填规则分配给用于生成追偿申请单的欠款明细。资金回填规则可以根据实际应用的需求来设置,例如,可以是优先偿还欠款时间长的欠款明细,可以是优先偿还欠款金额小的欠款明细,或者还可以是优先偿还设定业务类型的欠款明细。
在一种实现中,可以将分配到足额资金的欠款明细从追偿系统保存的欠 款明细中删除,并将未分配到足额资金的欠款明细的欠款金额修改为还未追偿到的数额,这样每次生成追偿申请单时,从所有保存的欠款明细中进行筛选即可。
在另一种实现中,可以为每条欠款明细设置追偿状态,包括未追偿、已追偿和部分追偿三种,其中,未追偿表示该条欠款明细尚未用于生成追偿申请单或者曾经用于生成追偿申请单但未被分配追偿资金;已追偿表示该条欠款明细已经获得足额追偿资金;部分追偿表示该条欠款明细已被分配追偿资金但尚未足额,对部分追偿的欠款明细还需记录已分配的金额或者还需追偿的欠款金额。在这种实现中,生成追偿申请单前,在追偿状态为未追偿或部分追偿的欠款明细中筛选满足追偿申请条件的欠款明细;当根据追偿申请单获得资金后,如果追偿系统分配给某条欠款明细的资金足额,则将这条欠款明细的追偿状态更改为已追偿;如果不足额则将这条欠款明细的追偿状态更改为部分追偿,并记录或更新已分配的金额或者还需追偿的欠款金额。
本实施例中,通过将各个业务系统的欠款明细集中后统一进行追偿,不再需要每个业务系统分别实现追偿功能,避免了大量的重复劳动,提高了业务系统的性能;根据欠款明细生成追偿申请单后进行资金操作避免了针对支付系统的大量并发追偿申请,降低了支付系统的负荷,提高了支付系统的性能。
追偿系统可以对追偿申请和资金分配的过程进行记录。为了便于业务系统了解追偿的具体情况,追偿系统可以生成根据获得资金的分配结果生成对应于欠款明细的追偿明细,记录一条欠款明细进行了几次追偿,每次获得的金额是多少,以及其他信息,如追偿时间等。一条欠款明细对应于一条追偿明细(例如一次足额追偿的情形)或一条以上的追偿明细(例如多次部分追偿的情形)。
追偿系统可以采用多任务或多线程的方式,来生成追偿申请单以及进行资金操作。为了避免不同的任务或线程同时对同一条欠款明细进行追偿,生成追偿申请单前,在未被标记为追偿中的欠款明细中筛选满足追偿申请条件 的欠款明细;当筛选出用于生成追偿申请单的欠款明细后,追偿系统将这些欠款明细标记为追偿中;在将获得的资金分配给欠款明细后,清除这条欠款明细的追偿中标记。这样,在一个线程或任务从发起到完成对一条欠款明细的追偿操作时,可以确保这条欠款明细不会被其他线程或任务选中。
在本申请的一个应用示例中,运行本申请实施例中追偿方法的追偿系统包括4个功能模块:追偿设置模块、欠款登记模块、调度模块和追偿执行模块,如图5所示。
追偿设置模块向管理员提供接口,由管理员对追偿系统所采用的追偿申请条件、资金回填规则和调度规则进行设置。其中,调度规则包括以怎样的频率和幅度进行追偿,比如每10分钟追偿20个预授权账户;追偿申请条件包括按欠款时间、业务类型、欠款明细条数、最大申请金额、是否部分追偿等条件来筛选欠款明细以生成追偿申请单,如将当月未追偿完成的欠款明细形成追偿申请单;资金回填规则用于确定如何将根据追偿申请单获得的资金分配到用于生成追偿申请单的欠款明细,或者说在部分追偿的情况下优先偿还哪些欠款明细。
当业务系统发生垫资或保证金使用等需要进行追偿的业务时,向追偿系统发送消息,登记欠款明细。欠款登记模块接收并保存来自业务系统的欠款明细,每条欠款明细包括已追偿、未追偿、部分追偿三个追偿状态,处于部分追偿状态的欠款明细还会记录已追偿金额;处于追偿过程中的欠款明细还会被追偿执行模块标记为追偿中。
调度模块根据预置的调度规则,调用追偿执行模块来进行追偿。
当追偿执行模块被调用时,从追偿状态为未追偿或部分追偿、并且未被标记为追偿中的欠款明细中筛选出满足追偿申请条件的欠款明细,根据筛选出的欠款明细生成追偿申请单,追偿申请单中记录需要追偿各个预授权账户的金额、以及追偿的总金额。追偿执行模块按照追偿申请单向支付系统发起追偿申请,进行真实的资金操作,如转账、冻结等。追偿申请可能部分成功,即如果账户余额不足,则按实际账户余额进行追偿。获得追偿资金后,根据 预置的资金回填规则,追偿执行模块将获得的资金分配给用于生成追偿申请单的欠款明细,将这些欠款明细的追偿中标记清除,并生成追偿明细。追偿明细对应于欠款明细,通过追偿明细可以查找到对应的欠款明细,同时通过欠款明细也可以查找到对应的一条到多条追偿明细。根据资金分配的结果,追偿执行模块更新用于生成追偿申请单的欠款明细的追偿状态,若欠款金额足额分配,则将欠款明细的追偿状态改为已追偿;未足额分配则将欠款明细的追偿状态改为部分追偿,并更新欠款明细的已追偿金额。
与上述流程实现对应,本申请的实施例还提供了一种资金追偿的装置。该装置可以独立应用在服务器上,也可以应用在支付系统所在的服务器上。该装置均可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为逻辑意义上的装置,该装置是通过所在服务器的CPU将对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言,除了图6所示的CPU、内存以及非易失性存储器之外,该装置所在的服务器通常还包括用于实现网络通信功能的板卡等其他硬件。
图7所示为本实施例提供的一种资金追偿的装置,从功能上划分,包括欠款明细接收单元、追偿申请生成单元、资金操作单元和资金分配单元,其中:欠款明细接收单元用于接收并保存业务系统发送的欠款明细;追偿申请生成单元用于筛选满足追偿申请条件的欠款明细,生成追偿申请单;资金操作单元用于根据追偿申请单进行资金操作;资金分配单元用于按照预置的资金回填规则,将获得的资金分配给用于生成追偿申请单的欠款明细。
可选的,所述追偿申请生成单元具体用于:根据预置的调度规则,筛选满足追偿申请条件的欠款明细,生成追偿申请单。
可选的,所述欠款明细的追偿状态包括未追偿、已追偿和部分追偿;所述追偿申请生成单元具体用于:筛选满足追偿申请条件、并且追偿状态为未追偿或部分追偿的欠款明细,生成追偿申请单;所述装置还包括:追偿状态维护单元,用于当分配给某条欠款明细的资金足额时,将所述欠款明细的追偿状态更改为已追偿;当不足额时将所述欠款明细的追偿状态更改为部分追 偿。
可选的,所述装置还包括:追偿明细单元,用于根据获得资金的分配结果生成对应于欠款明细的追偿明细;一条或一条以上的追偿明细对应于一条欠款明细。
可选的,所述追偿申请生成单元具体用于:筛选满足追偿申请条件、并且欠款明细未被标记为追偿中的欠款明细,生成追偿申请单;所述装置还包括追偿中标记单元和标记清除单元,其中:追偿中标记单元用于将筛选出来用于生成追偿申请单的欠款明细标记为追偿中;标记清除单元用于在将获得的资金分配给欠款明细后,清除所述用于生成追偿申请单的欠款明细的追偿中标记。
从以上各种方法和装置的实施方式中可以看出,相对于现有技术中在各个业务系统上分别实现资金追偿的功能,本申请的实施例通过将各个业务系统的欠款明细集中后统一进行追偿,不再需要每个业务系统分别实现追偿功能,避免了大量的重复劳动;统一进行资金操作避免了针对支付系统的大量并发追偿申请导致的请求不成功,提高了业务系统和支付系统的性能。
在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其 他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。
还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本领域技术人员应明白,本申请的实施例可提供为方法、系统或计算机程序产品。因此,本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
以上所述仅为本申请的较佳实施例而已,并不用以限制本申请,凡在本申请的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本申请保护的范围之内。