具体实施方式

现在将参照附图来详细描述本发明的各种示例性实施例。应注意到：除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本发明的范围。

同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。

以下对至少一个示例性实施例的描述实际上仅仅是说明性的，决不作为对本发明及其应用或使用的任何限制。

对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为说明书的一部分。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。

本发明实施例可以应用于计算机系统/服务器，其可与众多其它通用或专用计算系统环境或配置一起操作。适于与计算机系统/服务器一起使用的众所周知的计算系统、环境和/或配置的例子包括但不限于：个人计算机系统、服务器计算机系统、瘦客户机、厚客户机、手持或膝上设备、基于微处理器的系统、机顶盒、可编程消费电子产品、网络个人电脑、小型计算机系统、大型计算机系统和包括上述任何系统的分布式云计算技术环境，等等。

计算机系统/服务器可以在由计算机系统执行的计算机系统可执行指令(诸如程序模块)的一般语境下描述。通常，程序模块可以包括例程、程序、目标程序、组件、逻辑、数据结构等等，它们执行特定的任务或者实现特定的抽象数据类型。计算机系统/服务器可以在分布式云计算环境中实施，分布式云计算环境中，任务是由通过通信网络链接的远程处理设备执行的。在分布式云计算环境中，程序模块可以位于包括存储设备的本地或远程计算系统存储介质上。

下文中将参考附图并结合实施例来详细说明本申请。需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

针对目前现有技术中会导致在用户购买药品成功后，药店侧不能及时接收到该用户订单的结算处理结果，需要等到结算时长到达才能接收到该结果，进而造成药店订单数据的结算处理效率较低的问题。本实施例提供了一种药店数据的处理方法，如图1所示，该方法包括：

步骤101、接收药店的结算请求，结算请求中携带有药店的药店标识。

药店标识可为药店的编号或者ID号等。本实施例针对不同结算时效需求的药店，预先分配不同的药店标识，进而后续可根据该药店标识准确确定该药店的结算时效需求。

步骤102、根据结算请求中携带的药店标识，确定药店的结算周期，并依据结算周期，配置结算处理的参考时间点。

结算周期可对应药店的结算时效需求，如T+0的结算周期可代表当天结算，T+1的结算周期可代表隔天结算，T+N的结算周期可代表当天后第N天结算等。

结算处理的参考时间点可由系统设置，或者人工在操作时在页面中选择设置等。根据不同结算周期，可分别配置各自对应的结算处理参考时间点。

步骤103、获取参考时间点之前预设时间段内药店的订单台账数据。

预设时间段可根据实际需求进行设置，具体可根据业务支付方的支付业务处理时间确定。

订单台账数据中可包含订单ID、支付状态、审核状态、结算状态等信息。

在本实施例中，主要应用了领域驱动模型(DDD)，通过订单与台账的数据结构，将客户端交易侧的服务与药房侧的结算系统解耦，通过订单->台账的方法进行订单数据汇总，药房侧的账目分别依据门店结算系统和实时结算两大系统实现对账和打款服务。

步骤104、按照订单台账数据和结算周期，判断药店是否符合预设结算条件。

预设结算条件可根据实际需求进行预先设置。

步骤105、若判定药店符合预设结算条件，则根据订单台账数据，生成药店的结算单信息。

生成的结算单信息可发送给支付平台，为药店侧进行打款支付处理。

与目前现有技术相比，本实施例可根据药店对结算时效性要求的不同，采用不同的结算周期的结算处理方法对不同药店分别结算，具体的，首先根据药店的结算请求中携带的药店标识，确定药店的结算周期，并依据结算周期，配置结算处理的参考时间点。然后按照参考时间点之前预设时间段内药店的订单台账数据和结算周期，判断该药店是否符合预设结算条件，如果符合，则可根据订单台账数据，生成药店的结算单信息。通过应用本实施例技术方案，如果药店有结算时效需求，可在用户购买药品成功后，药店侧能够及时接收到该用户订单的结算处理结果，无需等待较长的处理时间，可提高药店订单数据的结算处理效率，进而可满足不同药店的业务需求。

进一步的，作为上述实施例的细化和扩展，为了完整说明上述实施例的具体实施过程，提供了另一种药店数据的处理方法，如图2所示，该方法包括：

步骤201、接收药店的结算请求，结算请求中携带有药店的药店标识。

步骤202、根据药店标识，确定药店的结算周期。

可选的，在步骤202之前，本实施例方法还可包括：统计不同药店的药店标识分别对应的结算周期；相应的，步骤202具体可包括：确定与结算请求中携带的药店标识对应的结算周期。通过这种可选方式，可根据药店标识准确确定该药店的结算时效需求。

进一步可选的，本实施例方法还可包括：接收药店变更结算周期的请求；通过变更药店的药店标识，实现对药店的结算周期进行更新。根据药店对于结算时效的变更需求，可做到准确的结算周期变更，满足药店的业务变化需求。

本实施例可将分布在不同地点的传统药房统一链接起来，通过在线购药的方法允许用户在线购买特殊药品，同时，要确保药房侧的资金流健康，在传统的购药方法下，用户本人到药房购药当时付款，药房侧实时收款进入资金池，在线购药，药房侧不能第一时间收到用户的款项，因此需要在当天(T+0)将本平台资金支付给药房侧，从而可以让药房侧在不必改变经营模式的情况下支持用户在线购药。

本实施例方案不仅解决了药房侧当天需要知晓具体的药品售卖情况，还可以当天出账，当天结算，当天对账，做到T+0，满足了当下药房侧对账目实时性的需求。首先台账侧通过异步消息队列的方法同步到门店结算系统相关的数据结构中，在药房侧进行结算的时候无需依赖订单而是进入单独的结算领域，结算方式也更加的灵活，可以做到当天出单，当天结算。

下面分别以T+1的隔天结算(步骤203a至205a)以及T+0的当天结算(步骤203b至205b)为例进行说明。

步骤203a、若结算周期为隔天结算，则配置参考时间点为当天时间的前一天时间，或前一天时间之前的时间。

例如，对于T+1的结算周期，今天处理时，可选择昨天或昨天之前的时间，作为参考时间点。

步骤204a、若结算周期为隔天结算，则获取参考时间点前第一预设天数到参考时间点范围内的药店的订单台账数据。

第一预设天数可根据实际需求进行设定，如可选择7天、10天等。

步骤205a、从订单台账数据中获取对订单用户资料的审核结果，若结算周期为隔天结算，则将审核不通过的时间与当天时间进行比较，如果审核不通过的天数超过第一预设天数阈值，则判定药店符合预设结算条件。

订单用户资料可包括用户的身份信息、处方信息等。第一预设天数阈值可根据实际需求进行设定，如可预先设置为2天、3天等。

与步骤203a并列的步骤203b、若结算周期为当天结算，则配置参考时间点为当天时间、或者当天时间的前一天时间、或者前一天时间之前的时间。

例如，对于T+0的结算周期，今天处理时，可选择今天、昨天或昨天之前的时间，作为参考时间点。

步骤204b、若结算周期为当天结算，则将参考时间点和当天时间点进行对比，根据对比结果，确定预设时间段的目标时间范围，并获取目标时间范围内的药店的订单台账数据。

示例性的，根据对比结果，确定预设时间段的目标时间范围，具体包括：若参考时间点为当天时间的前一天时间、或者前一天时间之前的时间，则将参考时间点前第二预设天数(可根据实际需求进行设定，如可选择7天、10天等)到参考时间点的时间范围，确定为目标时间范围；若参考时间点为当天时间、且是当天预定时间点之前的时间点，则将当天时间的前一天到该前一天之前第三预设天数时间(可根据实际需求进行设定，如可选择7天、10天等)的时间范围，确定为目标时间范围；若参考时间点为当天时间、且是当天预定时间点之后的时间点，则将当天预定时间点前第四预设天数(可根据实际需求进行设定，如可选择7天、10天等)到当天预定时间点的时间范围，确定为目标时间范围。

步骤205b、从订单台账数据中获取对订单用户资料的审核结果，若结算周期为当天结算，则将审核不通过的时间与参考时间点往前推预置天数的时间进行比较，如果审核不通过的天数超过第二预设天数阈值，则判定药店符合预设结算条件。

预置天数可为2天或3天等。第二预设天数阈值可根据实际需求进行设定，如可预先设置为2天、3天等。

步骤206、若判定药店符合预设结算条件，则按照预定时间间隔的时间维度，生成结算周期对应的结算单信息，结算单信息包含预设时间段内每一时间维度、且有订单的结算单信息。

例如，按天的维度生成T+1或T+0的结算单，即一天一个结算单。后续生成的结算单信息可发送给支付平台，为药店侧进行打款支付处理。

为了说明上述各实施例的具体实施过程，给出如下应用示例，但不限于此：

例如，如图3所示，为对于特殊药品(特药)药店结算处理的系统架构示意图。分为三个端体，订单域、结算域、支付平台。在订单域中，可根据订单明细进行订单审核，具体可审核订单用户资料(如用户的身份信息、处方信息等)是否完整。在资料齐全完整时可判定审核通过，在资料不全时可判定审核未通过，可及时告知进行资料补全。在结算域中可包含与订单对应的款项明细，以及订单台账明细(主要信息可包含订单ID、支付状态、审核状态、结算状态等)。根据本实施例提供的方式进行结算处理，生成药店的结算单，然后按照该结算单发起打款，打款成功后可得到付款单。

药店数据结算处理的流程示例可如图4所示。在接收到药店结算请求后，可根据药店标识判断该药店是否T+1药店(是否是隔天结算的药店)。如果是T+1药店，可取出当前业务人员选中日期前十天到该日期范围内的台账，并具体判断订单用户资料是否审核通过，如果未通过是否已超过3天(此处的比较是审核不通过日期与今天的日期比较)，如果未超过3天，可取消结算；如果超过3天，可按天的维度生成T+1结算单，即一天一个结算单。

如果该药店是T+0结算，首先将业务人员选中时间与今天时间进行对比，如果选中时间是昨天或者昨天之前的时间，可取出当前业务人员选中日期前十天到该日期范围内的台账；如果选中时间是今天并且是今天15点之前时间，可取出当前业务人员昨天前十天到昨天范围内的台账；如果选中时间是今天并且今天15点之后时间，可取出今天15点到今天15点之前十天范围内的台账。

后续根据台账数据，具体判断订单用户资料是否审核通过，如果未通过是否已超过3天(此处的比较是审核不通过日期与当前业务人员选中日期往前推三天的日期比较)，如果未超过3天，可确定该订单不参与结算，而其他正常订单仍参与结算；如果超过3天，可按天的维度生成T+0结算单，即一天一个结算单。

基于上述应用场景的实施过程，本实施例可以满足药店对结算时效性的不同需求，由于系统的灵活性、可以接入更多的药店，使患者在购药的构成中具有更多的选择性，达到以患者为中心，提供不同维度的补贴服务，同时让患者从线下购药转移到线上来。提高患者的购药效率，对审核不通过的购药材料及时通知药店重新上传，降低了补贴的成本的同时让患者可以得到更多的补贴机会。

进一步的，作为图1和图2方法的具体实现，本实施例提供了一种药店数据的处理装置，如图5所示，该装置包括：接收模块31、确定模块32、配置模块33、获取模块34、判断模块35、生成模块36。

接收模块31，用于接收药店的结算请求，所述结算请求中携带有所述药店的药店标识；

确定模块32，用于根据所述药店标识，确定所述药店的结算周期；

配置模块33，用于依据所述结算周期，配置结算处理的参考时间点；

获取模块34，用于获取所述参考时间点之前预设时间段内所述药店的订单台账数据；

判断模块35，用于按照所述订单台账数据和所述结算周期，判断所述药店是否符合预设结算条件；

生成模块36，用于若判定所述药店符合预设结算条件，则根据所述订单台账数据，生成所述药店的结算单信息。

在具体的应用场景中，本装置还包括：统计模块；

所述统计模块，用于在所述根据所述药店标识，确定所述药店的结算周期之前，统计不同药店的药店标识分别对应的结算周期；

所述确定模块32，具体用于确定与所述结算请求中携带的药店标识对应的结算周期。

在具体的应用场景中，所述配置模块33，具体用于若所述结算周期为隔天结算，则配置所述参考时间点为当天时间的前一天时间，或所述前一天时间之前的时间；若所述结算周期为当天结算，则配置所述参考时间点为当天时间、或者所述当天时间的前一天时间、或者所述前一天时间之前的时间。

在具体的应用场景中，所述获取模块34，具体用于若所述结算周期为隔天结算，则获取所述参考时间点前第一预设天数到所述参考时间点范围内的所述药店的订单台账数据；若所述结算周期为当天结算，则将所述参考时间点和当天时间点进行对比，根据对比结果，确定所述预设时间段的目标时间范围，并获取所述目标时间范围内的所述药店的所述订单台账数据。

在具体的应用场景中，所述获取模块34，具体还用于若所述参考时间点为当天时间的前一天时间、或者所述前一天时间之前的时间，则将所述参考时间点前第二预设天数到所述参考时间点的时间范围，确定为所述目标时间范围；若所述参考时间点为当天时间、且是当天预定时间点之前的时间点，则将当天时间的前一天到所述前一天之前第三预设天数时间的时间范围，确定为所述目标时间范围；若所述参考时间点为当天时间、且是当天预定时间点之后的时间点，则将当天预定时间点前第四预设天数到当天预定时间点的时间范围，确定为所述目标时间范围。

在具体的应用场景中，所述判断模块35，具体用于从所述订单台账数据中获取对订单用户资料的审核结果；若所述结算周期为隔天结算，则将审核不通过的时间与当天时间进行比较，如果审核不通过的天数超过第一预设天数阈值，则判定所述药店符合预设结算条件；若所述结算周期为当天结算，则将审核不通过的时间与所述参考时间点往前推预置天数的时间进行比较，如果审核不通过的天数超过第二预设天数阈值，则判定所述药店符合预设结算条件。

在具体的应用场景中，所述生成模块36，具体用于按照预定时间间隔的时间维度，生成所述结算周期对应的所述结算单信息，所述结算单信息包含所述预设时间段内每一时间维度、且有订单的结算单信息。

在具体的应用场景中，本装置还包括：更新模块；

所述接收模块31，还用于接收药店变更结算周期的请求；

所述更新模块，用于通过变更药店的药店标识，实现对药店的结算周期进行更新。

需要说明的是，本实施例提供的一种药店数据的处理装置所涉及各功能单元的其它相应描述，可以参考图1和图2中的对应描述，在此不再赘述。

基于上述如图1和图2所示方法，相应的，本实施例还提供了一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述如图1和图2所示的方法。

基于这样的理解，本实施例的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。

基于上述如图1和图2所示的方法，以及图5所示的虚拟装置实施例，为了实现上述目的，本实施例还提供了一种电子设备，具体可以为计算机，服务器，或者网络设备等，该实体设备包括存储介质和处理器；存储介质，用于存储计算机程序；处理器，用于执行计算机程序以实现上述如图1和图2所示的方法。

可选的，该实体设备还可以包括用户接口、网络接口、摄像头、射频(RadioFrequency，RF)电路，传感器、音频电路、WI-FI模块等等。用户接口可以包括显示屏(Display)、输入单元比如键盘(Keyboard)等，可选用户接口还可以包括USB接口、读卡器接口等。网络接口可选的可以包括标准的有线接口、无线接口(如WI-FI接口)等。

本领域技术人员可以理解，本实施例提供的一种电子设备结构并不构成对该实体设备的限定，可以包括更多或更少的部件，或者组合某些部件，或者不同的部件布置。

存储介质中还可以包括操作系统、网络通信模块。操作系统是管理上述实体设备硬件和软件资源的程序，支持信息处理程序以及其它软件和/或程序的运行。网络通信模块用于实现存储介质内部各组件之间的通信，以及与信息处理实体设备中其它硬件和软件之间通信。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以借助软件加必要的通用硬件平台的方式来实现，也可以通过硬件实现。通过应用本实施例的技术方案，与目前现有技术相比，本实施例可根据药店对结算时效性要求的不同，采用不同的结算周期的结算处理方法对不同药店分别结算。通过应用本实施例技术方案，如果药店有结算时效需求，可在用户购买药品成功后，药店侧能够及时接收到该用户订单的结算处理结果，无需等待较长的处理时间，可提高药店订单数据的结算处理效率，进而可满足不同药店的业务需求。

本说明书中各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其它实施例的不同之处，各个实施例之间相同或相似的部分相互参见即可。对于系统实施例而言，由于其与方法实施例基本对应，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

可能以许多方式来实现本发明的方法和系统。例如，可通过软件、硬件、固件或者软件、硬件、固件的任何组合来实现本发明的方法和系统。用于所述方法的步骤的上述顺序仅是为了进行说明，本发明的方法的步骤不限于以上具体描述的顺序，除非以其它方式特别说明。此外，在一些实施例中，还可将本发明实施为记录在记录介质中的程序，这些程序包括用于实现根据本发明的方法的机器可读指令。因而，本发明还覆盖存储用于执行根据本发明的方法的程序的记录介质。

本发明的描述是为了示例和描述起见而给出的，而并不是无遗漏的或者将本发明限于所公开的形式。很多修改和变化对于本领域的普通技术人员而言是显然的。选择和描述实施例是为了更好说明本发明的原理和实际应用，并且使本领域的普通技术人员能够理解本发明从而设计适于特定用途的带有各种修改的各种实施例。