CN108564295A - 一种动态进销存核算管理*** - Google Patents

Abstract

本发明涉及一种动态进销存核算管理方法和***，主要通过优化后的分布式服务框架搭建业务管理后台和业务处理***，并在具体场景处理中采用基于控制反转和面向切面的容器框架，提高了***的扩展性、安全性、响应速度及用户体验度。

Description

一种动态进销存核算管理***

技术领域

本发明属于产品电子管理领域，具体涉及产品品进销存核算管理子领域。

背景技术

传统的进销存***是为了对企业生产经营中进货、出货、批发销售、付款等进行全程进行(从接获订单合同开始，进入物料采购、入库、领用到产品完工入库、交货、回收货款、支付原材料款等)跟踪(每一步都提供详尽准确的数据)、管理(有效辅助企业解决业务管理、分销管理、存货管理、营销计划的执行和监控、统计信息的收集等方面的业务问题)而设计的整套方案。随着信息技术的飞速发展，企业进销存的管理应用相应的软件模块、硬件及通讯网络使这一动态的进销存过程更加有条理，应用进销存管理不仅使企业的进销存管理实现了即时性，结合互联网技术更使进销存管理实现了跨区域管理。但是，传统的进销存***往往只关注实体商品或货物的销售信息管理，对于基于互联网新兴业态下的订单交易的销售信息，则没有涉及。当前，随着互联网应用的日益丰富和普及，越来越多的人们采用互联网的方式进行线上商品交易。更加特别的，一些线上交易的主体已经不再是实体的商品或者货物，而是诸如网站会员、卡券、点卡等线上服务。客户线上订购这类服务，并支付相应的费用，这就构成了区别于线下实体商品以外的线上商品。

行业的新发展对管理***的安全性、可扩展性提出了更高的要求。在这种情形下，基于目前进销存***通常并不能适用于行业新的要求。主要有以下几个原因：

1、现有***通常采用的基于模型-视图-控制器的三层架构的软件开发模式，基于这种设计模式的应用框架，采用***的机制来处理用户的请求，通过对***数据模型、用户界面、业务逻辑控制器等的封装，可以方便的给用户搭建信息查询与管理***。但是这样的开发框架却隐含安全漏洞，存在安全风险，恶意的用户可以通过修改请求报文头的值而触发相关安全漏洞，进而执行任意***命令，导致***被黑客入侵。而新的行业需求具有更复杂的业务类型，对安全性要求更高，传统管理***已经不能满足要求。

2、传统的进销存***采用的基于联机服务器和数据库的架构，所有的服务都部署在应用服务器上，数据都存放在数据库中，服务和数据没有拆分，也无法扩展。这样的技术体系，只能支持单点部署，不支持集群部署，也不能做横向扩展。当***因为过载或意外情况出现宕机时，整个对客服务就会中止。也正是因为传统的***无法拆分为多个组件或服务，不能支撑横向扩展，***无法实施分布式部署，使得***的吞吐量较低，一般只能达到30至50区间，随着***吞吐量的持续增大，***的处理性能会显著降低，响应时间缓慢。这种***大多应用于传统实体商品销售中，在面对新的虚拟商品及服务销售时就受到极大制约。而现在市场的变化业务的变化迫使我们必须要不断的提升技术能力和设计能力来满足市场的应用，较低的吞吐量在高并发的时候***会延长响应速度，从而影响客户的体验。

3、管理更多停留在电子***内部，对货品的实际状态没有监控，导致管理不够细致精准，严重时可能出现货物数量无法满足订单要求的情况，导致订单被拖延，影响客户体验。

发明内容

为了解决上述技术问题，及其他在说明书中提及的技术问题，现提出本发明。

本发明的技术方案

一种动态进销存业务管理方法，其特征在于包括如下步骤：

(1)利用业务管理后台中的供应商模块依次进行产品供应商信息维护、产品供应商下的产品信息维护、产品的计费信息管理；

(2)利用业务管理后台中的渠道模块对销售渠道进行管理并维护销售渠道和产品的对应关系；

(3)响应于客户通过业务处理***中的合作方平台发起的订购请求，线上服务分销平台会受理该订购请求，并依据请求生成订单；

(4)在订单计费开始之前，需要进行验证码验证：线上服务分销平台则调用融合计费平台的验证码服务，来下发验证码；融合计费平台会依据和运营商渠道的交易接口，返回验证码的响应结果给线上服务分销平台，而线上服务分销平台则会将此验证码返回给合作方平台，并通过合作方平台反馈给客户；

在此步骤中，线上服务分销平台基于分布式服务框架封装注册了多个服务接口，包含查询接口、订购接口、计费验证码接口、回调处理接口；

在此步骤中，融合计费平台基于分布式服务框架也封装注册了多个服务，包括计费服务和验证码服务；

上述分布式的服务框架，提供了服务消费者，服务提供者和服务注册中心三种角色：服务提供者，负责提供服务，并将服务注册到注册中心；服务消费者，则通过服务注册中心找寻需要的服务并调用；服务注册中心，则是提供服务供需双方服务注册和查询的场所；服务的提供方将大而全的功能，拆分成一个个原子的服务，并注册到配置中心；这些原子服务，可以由不同的服务器提供；其中合作方接入平台作为服务消费者的角色调用服务，融合计费平台作为服务提供者的角色提供服务，而线上分销平台则是作为服务中介的角色；

(5)响应于客户输入的验证码，合作方平台确认订购；合作方平台将用户的确认订购订单的请求，发送给线上服务分销平台；线上服务分销平台则开启对该笔订单的校验子流程；该校验子流程包括：

(5-1)线上服务分销平台接收到确认的订单请求，解析相关的订单参数，并对该订单的参数进行校验，并对订单请求包含的用户签名进行校验，确保该笔订单的真实有效；

(5-2)线上服务分销平台依次开展渠道验证、渠道产品验证、停用验证、黑名单验证、资金池验证；

在步骤(5-2)中资金池验证的实例由云容器生成，并将该实例注入到资金池扣款中供其调用，不同扣款场景就可以复用资源池验证的实例；该云容器是由云上运行的多个容器基于投票机制产生的，即某个云容器声明了对资金池验证的选择控制权，如果得到在云上其他的容器半数以上的同意，则该云容器拥有了对资金池验证的选择控制权。

响应于用户的订购请求，生成采购单；当出现采购单中的产品服务不足时，则需要开启补货流程，即依据客户的需求对采购单中的产品列表和数量进行补货，并更新采购单信息；而当客户对采购单中的产品服务发起退货时，***则会依据客户的退货请求，更新采购单中的产品数量。

根据上述采购单信息计算采购单的订单金额P＝(M-(N<M？N,M)+(L<K？L,K))*D；其中采购单的订单产品数据为M，退货产品数据为N，补货产品数据为L，库存产品数据为K，产品订单单价为D；其中N<M？N,M表示，如果N小于M，则值取N，否则值取M；L<K？L,K表示，如果L小于K，则值取L，否则值取K。

在进行采购单订单金额计算时，若采购单中产品为实体产品，则进行如下流程：

①融合计费平台利用相机对存放某一种类商品的整个货架进行拍照，获取清晰完整的整体图像，并发送给管理***；

②融合计费平台识别图像中相似的单元，对整体图像进行分割，获得多个子单元图像，并统计得到子单元图像个数W；

③融合计费平台对各个子单元图像进行比较，找出与其他子单元图像存在不同的子单元图像并统计其数量Q，并将其在整体图像中的位置发送给管理人员，管理人员根据定位进行查看，确认上述包装箱损坏的数量T，并反馈给融合计费平台。

④融合计费平台确定实际库存产品数据为H＝W-(T<Q？T,Q)，(T<Q？T,Q)表示如果T小于Q，则值取T，否则值取Q。

⑤融合计费平台比较实际库存数据H与管理***中存储的库存数据K，若两者不相等，则P＝(M-(N<M？N,M)+(L<H？L,H))*D。

订单交易发生时，发送异步消息给相关供应商，若供应商无法收到调用消息，则发起手工回调，以手工的方式调用供应商的相关接口。

一种动态进销存业务管理***，其特征在于包括：业务管理后台和业务处理***两个子***，

其中业务管理后台包含供应商模块、渠道模块和报表模块三个模块；

(1)供应商模块，包括供应商子模块、产品子模块、计费产品子模块、采购单子模块；

其中供应商子模块用于实现供应商列表信息查询、供应商信息新增维护、供应商信息修改功能；用于提供针对相关供应商的状态的管理，包含启用和停用；

产品子模块，用于维护该供应商下的产品信息，用于产品列表信息查询、供应商产品信息新增维护、状态维护管理；

计费产品子模块，用于对计费产品信息的查询、增加、维护和删除；

采购单子模块，用于采购单的查询、维护、删除，实现在该采购单下配置产品以及补退货功能。

(2)渠道模块，用于销售渠道的管理及维护销售渠道和产品的对应关系；

(3)报表模块，用于订单交易明细的查询及手工回调的功能。

业务处理***分为四个平台，分别是合作方平台、线上服务分销平台、融合计费平台和线上服务整合平台；平台之间采用分布式的服务框架，按照分层的方式来架构，将各个层之间解耦合，从而实现最大限度的松耦合；

合作方平台是用户访问***的入口，主要为客户提供订购和查询服务；

线上服务分销平台，是作为分布式服务调用的核心处理平台，用以承接客户通过合作方平台发起的产品查询和产品订购请求，并依据客户的请求，进行验证码接口处理、订购确认、业务验证、回调业务处理；其中业务验证包含了渠道验证、渠道商品验证、停用验证、黑名单验证、资金池验证。渠道验证和渠道商品验证，是用来校验该渠道对应的产品是否允许订单交易；停用验证，是校验该产品是否已经被停用，如果停用，则不允许交易；黑名单验证，是校验订单客户是否在黑名单中，如果客户在黑名单中，则交易终止；资金池验证是用来验证资金池余额是否足够支持订单消费的验证；

融合计费平台，是进行订单账务处理的平台，提供计费和验证码服务；融合计费平台作为服务的提供方，在注册中心注册服务，封装服务接口，并提供给调用方调用；

线上服务整合平台，则提供了对接线上服务提供商提供的线上产品和服务，线上服务整合平台作为服务的提供方，在注册中心注册服务，封装服务接口，并提供给调用方调用。

本发明的发明点：

1、不仅能够对实体商品的进销存业务进行管理，而且能够管理虚拟商品及服务。

2、并且采用基于控制反转和面向切面的容器框架，及云投票机制专门解决了管理对象为虚拟商品及服务时带来的安全性问题。

3、并且采用分布式的服务框架专门解决了管理对象为虚拟商品及服务时带来的***不易扩展的问题，提升了***响应处理时间和并发处理能力。

4、同时，对分布式框架进行了进一步改进和优化，创造性地将原子服务数据再次拆分，同时设置了优选的阈值，保证在不过多增加成本的基础上，提高***响应速度。

5、经过***多次测试和实际试验，建立了科学的***补货算法，保证业务管理的精确性。

以上发明点是本发明的主要贡献，但***在细节方面还有更多的改进，因此不排除本发明还包括了其他技术贡献，特别是在实施方式中一些较好的实施例，及细节的改进和完善，都是本发明针对现有技术做出的贡献，均属于本发明的发明点。限于篇幅，在此不再赘述。

本发明达到的技术效果

1、不仅能够对实体商品的进销存业务进行管理，而且能够管理虚拟商品及服务，能够满足客户多种需要，紧跟社会发展需求。

2、极大地提高了***的安全性，防止在最关键的交易环节被篡改攻击，造成损失。

3、在***搭建完毕后，可根据需要方便地增加商品和服务，使得面对新的业务需求时，不再需要整体服务的变更，***扩展更容易。同时，提升了***响应处理时间和并发处理能力。

4、在实体商品补货环节更加精确，防止无效订单产生，造成货品短缺。同时也可以防止额外补货造成的积压。

附图说明

图1为动态进销存及业务管理***处理流程的示意图。

图2为进销存***中资金池扣款退款子流程的示意图。

图3为进销存及业务管理***的功能结构示意图。

图4为在进销存***进行订单处理实例示意图。

图5为资金池扣款基于控制反转容器实例示意图。

图6为进存销***基于分布式服务框架示意图。

具体实施方式

一种动态进销存及业务管理***的处理流程，如图1所示，包括以下步骤：

(1)各内容提供商提供的会员、卡券等线上服务作为一种线上产品，纳入到动态进销存及业务管理的产品范围中，提供相关互联网权益类、计费通道类、运营商类等类型的供应商管理、供应商产品管理、计费产品管理、采购单管理、渠道管理、渠道商品管理、交易明细查询、手动回调等相关功能。本发明方案提供了区别于传统的线下实体商品以外的线上产品的订单、支付、供应商、渠道等全流程的进销存及业务管理流程和方法，并基于这样的流程提供给客户相关的线上产品服务。

(2)后台人员首先维护产品供应商信息，并提供供应商列表信息查询、供应商信息新增维护、供应商信息修改等功能，同时本发明方案还提供针对相关供应商的状态的管理，包含启用和停用。即如果在本***中允许相关供应商提供产品服务，则该供应商的状态为启用。如果在本***中不允许相关供应商提供产品服务，则该供应商的状态为停用。这类线上产品的业务类型分为三类，分别是互联网权益类，计费通道类和运营商类。互联网权益类供应商主要是指提供会员特权服务的互联网线上供应商，计费通道类供应商主要是指卡券、返点等线上计费服务的供应商，运营商类供应商则是指提供网络流量或通讯服务的运营商，主要包含***、***、中国电信、中国广电等。

(3)供应商信息维护完成以后，后台人员则可以针对供应商维护该供应商下的产品信息，并通过供应商产品列表信息查询、供应商产品信息新增维护等功能，同时还提供针对该供应商产品的状态维护管理，包含相关产品的启用和停用。产品类型可以分为卡券类产品、会员类产品、虚拟币类产品、流量类产品、语音类产品等几类，产品形式则包含直冲、券码等形式。如果需要开通相关供应商的某个产品，则需要维护该产品状态为启用。如果相关供应商的产品已经不对外提供服务，则维护该产品状态为停用。

(4)完成维护供应商及其产品后，则进行相关供应商产品的计费信息管理，提供计费产品信息的查询、增加、维护和删除。计费产品管理，是对相关供应商对应的产品，维护管理其产品的订购方式、价格、状态等信息。订购的方式分类点播和包月两种模式。依据计费产品的状态，可以对该计费代码进行封停或启用。

(5)配置了供应商及其产品和计费信息，用户就可以通过合作方平台调用查询供应商、产品和计费信息查询服务，并开展相关采购单的订购。采购单主要包含采购单名称、供应商信息、合同信息、库存信息等内容。库存模式分为资金模式和计数模式两种，付费方式则包括预付和后结两种。采购单下单时，还需要配置采购单中的产品信息，包含产品的基础信息，采购价格、市场价格、折扣价格等。

(6)当出现采购单中的产品服务不足时，则需要开启补货流程，即依据客户的需求对采购单中的产品列表和数量进行补货，并更新采购单相关信息。而当客户对采购单中的产品服务发起退货时，***则会依据客户的退货请求，更新采购单中的产品数量、订单和库存信息。假定采购单的订单产品数据为M，退货产品数据为N，补货产品数据为L，库存产品数据为K，产品订单单价为D，则该笔采购单的订单金额P＝(M-(N<M？N,M)+(L<K？L,K))*D。其中N<M？N,M表示，如果N小于M，则值取N，否则值取M。L<K？L,K表示，如果L小于K，则值取L，否则值取K。

在实体商品管理中，经常发生虽然***中登记了一定的库存商品，但由于流程缺陷或者存储损耗，导致实际库存商品中有一部分已经损坏或丢失，不能作为商品出售。那么就需要对商品的实际状态和数量进行检测。

①利用相机对存放某一种类商品的整个货架进行拍照，获取清晰完整的整体图像，并发送给管理***；

②管理***识别图像中相似的单元(例如一个商品包装箱)，对整体图像进行分割，获得多个子单元图像(每个商品包装箱都是一个子单元图像)，并统计得到子单元图像个数，例如为W；

③管理***对各个子单元图像进行比较，找出与其他子单元图像存在不同的子单元图像(例如子单元图像中包装箱缺角，导致和其他包装箱图片不同)，统计其数量，例如为Q，并将其在整体图像中的位置发送给管理人员，管理人员根据定位进行查看，确认上述包装箱损坏的数量，例如为T，并反馈给管理***。

④管理***确定实际库存产品数据为H＝W-(T<Q？T,Q)，(T<Q？T,Q)表示如果T小于Q，则值取T，否则值取Q。

⑤根据管理***请求，相机通过导轨移动至另一商品货架，重复上述步骤。

⑥比较实际库存数据H与管理***中存储的库存数据K，若两者不相等，则将管理***中存储的库存数据值设定为H。即此时管理***中存储的库存数据K＝H。

根据上述方法，使得***管理更加精准，补货更加科学，这也是发明点之一。而且，采用相机获取图像，进行图像比较的方式，成本更小，效率更高，无需过多使用人工或机器臂进行排查，不仅节约成本(约节约87％)，而且使用寿命更长。而且对整个处理***硬件要求不高，无需额外的存储器等设备，特别适合分布式管理模式。因此这种方式也是本发明对传统管理***的改进点之一。

(7)附加的，***可以提供销售渠道的管理及维护销售渠道和产品的对应关系。即销售渠道是指商品和服务从生产者向消费者转移的过程，包含经销商渠道、代理商渠道等，线上渠道。同时，针对供应商产品，可以配置销售渠道和产品的映射关系，即特定的产品可以在特定的渠道进行销售。

(8)此外，***提供了订单交易明细的查询，即用户可以通过一定的查询条件，比如订单号、产品名称等，查询相关订单交易的明细。同时***还提供手工回调的功能。手工回调，是指，手工发起调用供应商相关接口，比如开通会员服务、购买点卡等。正常的情况，***提供同步和异步两种方式调用供应商的接口。同步回调是指，在交易发生时实时自动调用供应商的接口。异步回调是指，订单交易发生时，***发送异步消息给相关供应商。在一定时间间隔后(一般在1s)回调供应商的接口，查询接口响应结果。在特殊的情况下，异步的消息由于网络阻塞等原因，可能会导致相关供应商无法收到调用消息，进而影响客户服务。此时，***可以发起手工回调，即以手工的方式调用供应商的相关接口。

(9)在维护了供应商、产品、渠道等信息后，客户则可以通过合作方平台提供的服务，进行相关的信息查询和订购。这就开启了进销存***的业务处理流程。本***中的业务处理功能，大致可以分为四个平台，分别是合作方平台、线上服务分销平台、融合计费平台和线上服务整合平台。平台之间采用分布式的服务框架，按照分层的方式来架构，将各个层之间解耦合，从而实现最大限度的松耦合。融合计费平台和线上服务整合平台作为服务的提供方，在注册中心注册服务，封装服务接口，并提供给调用方调用。比如，融合计费平台的计费服务和验证码服务会被线上服务分销平台调用，而线上服务整合平台的线上产品服务(比如开通会员服务)也可能被线上服务分销平台调用。对应的，合作方平台和线上服务分销平台的承担的角色相比有所不同。合作方平台和线上服务分销平台既作为服务的提供方，封装服务，提供给调用方调用，同时也作为服务的消费方，通过调用封装接口的方式访问服务。例如，线上服务分销平台提供的订购接口服务，会被合作方平台调用，而同时用户也会通过查询或订购服务来调用合作方平台的接口。基于分布式的服务框架，进行的服务化设计，将***由大到小进行了服务数据拆分，每个服务数据都具备独立部署开放服务的能力，通过业务主线将这些个服务化的组件进行了编排整合，如图6所示，分布式的服务框架，提供了服务消费者，服务提供者和服务注册中心三种角色。服务提供者，负责提供服务数据，并将服务数据注册到注册中心。而服务消费者，则通过服务注册中心找寻需要的服务数据并调用。服务注册中心，则是提供服务数据供需双方服务注册和查询的场所。服务数据的提供方，不只局限在本地，也不需要提供一个大而全的功能。而是将大而全的功能，拆分成一个个原子的服务数据，并注册到配置中心。这些原子服务数据，可以由不同的服务器提供，甚至可以由不同的外部***提供。而服务的消费方，只需要通过注册中心找寻到所需的服务数据，即可进行相关的服务数据调用。在本发明方案中，合作方接入平台作为服务消费者的角色调用服务，融合计费平台作为服务提供者的角色提供服务，而线上分销平台则是作为服务中介的角色。基于这样的框架，***具备了很高的扩展性、灵活性、可移植性，这样既避免了***单点问题，使得***的高可用性大大提升，同时借由横向的扩展，也很大程度上提升了***响应处理时间和并发处理能力，优化了客户体验。另一方面，灵活的服务编排，使得面对新的业务需求时，不再需要整体服务的变更，而是基于接口和服务拆分，进行局部的优化和改造，极大的提升了***快速响应业务需求的能力。这部分应该作为本发明方案的一个保护点。更进一步，在一些情形下，服务数据较大，或者该服务数据需要调用其他一些较大数据，上述将服务进行分布式规划的方式导致“较大的原子服务数据”在单一服务器上调用处理效率较低。本发明针对这种情况进一步提出了改进：①服务数据提供方将整体服务数据首先拆分成多个原子服务数据；②计算原子服务数据调用处理的平均时间T。由于调用对象、时间、方式不同，每次原子服务数据的调用时间并不相同。因此，需要计算出平均时间，作为最优的划分依据。随机检测上述分布式***的原子服务数据调用处理的时间为Tn，n＝1,2,3…对其中每一个时间Tn均进行如下判断{|Tn-(T1+T2+…Tn)/n|}/{(T1+T2+…Tn)/n}＜0.67，对符合上述要求的时间Tn求和，并取平均值，作为平均时间T。当T大于阈值Q时，该服务数据需要拆分。根据测试，Q通常取值为小于46ms。上述0.67也是根据大量数据进行统计分析得到的最优数据。③根据上述判断结果对原子服务数据再次进行拆分，分别由不同服务器存储执行，同时在注册中心中保存同一原子服务数据的链接关系。经过上述操作，在一些服务数据较大的情形下，响应时间可以缩短34％。同时，根据上述阈值进行合理的判断，防止过度布置服务器带来的成本增加的问题。因此这也是本发明的发明点之一。

(10)客户通过合作方平台提供的查询服务，可以对于供应商产品信息进行浏览查询。当遇到合适的产品服务时，客户则可以通过合作方平台提供的订购服务，发起订购服务请求。

(11)基于分布式服务框架，线上服务分销平台封装注册了多个服务接口，包含查询接口、订购接口、计费验证码接口、回调处理接口等。当客户通过合作方平台发起订购时，线上服务分销平台会受理该服务请求，并依据请求生成订单。

(12)基于分布式服务框架，融合计费平台也封装注册了多个服务，包括计费服务和验证码服务等。按照流程，一笔订单在开始计费之前，需要进行验证码验证。此时，线上服务分销平台则调用融合计费平台的验证码服务，来下发验证码。融合计费平台会依据和运营商渠道的交易接口，返回验证码的响应结果给线上服务分销平台，而线上服务分销平台则会将此验证码返回给合作方平台，并通过合作方平台反馈给用户。

(13)用户收到相关验证码信息后，输入验证码，并通过合作方平台确认订购。合作方平台将用户的确认订购订单的请求，发送给线上服务分销平台。线上服务分销平台则开启对该笔订单的校验子流程。

(14)首先在线上服务分销平台接收到确认的订单请求，解析相关的订单参数，并对该订单的参数进行校验，并对订单请求包含的用户签名进行校验，确保该笔订单的真实有效。

(15)其次线上服务分销平台开展相关业务验证，具体包含以下方面的业务验证，分别是渠道和渠道商品验证，即验证该渠道对应的产品是否允许订单交易。停用验证，即验证该产品是否已经被停用，如果停用，则不允许交易。黑名单验证，即验证订单客户是否在黑名单中，如果客户在黑名单中，则交易终止。同时查询渠道商户配置的采购单资金池列表，验证每个资金池金额是否够消费。如果资金池金额不足，则交易终止。相反，如果资金池金额充足，则发起资金池扣款，并记录扣款日志，生产计费工单。附加开启了资金池扣款退款子流程。

(16)图2示意了进销存***中资金池扣款退款子流程。即在线上服务分销平台确认了订单请求，并通了相关业务验证后，线上服务分销平台依据渠道商户配置的采购单资金池列表，去验证资金池的余量是否够消费。如果资金池余量小于订单金额，表示资金池余量不足，则扣款流程结束。相反，如果资金池余量大于订单金额，表示资金池余量充足，则调用融合计费平台发起扣款。本方案中，上述动态进销存和业务管理的功能，摒弃了传统的基于模型-视图-控制器的三层架构的软件开发模式，而是采用了创新的基于控制反转和面向切面的容器框架。一般的情况下，被调用方的选择控制权应该由被调用方本身来控制，控制反转则是指被调用方的选择控制权从调用方中移除，而转交给第三方容器裁决。本发明方案的资金池扣款场景即是采用了这样的框架。如图5所示，在资金池扣款场景中，资金池扣款需要调用资金池验证的功能，在传统的框架下，每次扣款都需要在资金池扣款中生成资金池验证的实例，并调用其功能，即上一笔扣款生成了资金池验证的实例，在下一笔扣款中还得生成新的资金池验证的实例，没法实现资金池验证的复用。在本发明方案中，资金池验证的实例由容器生成，并将该实例注入到资金池扣款中供其调用。不同扣款场景就可以复用资源池验证的实例，保证了***计算资源的集约，有效提升***运行效率和用户体验。特别的，在本发明方案中，裁决的第三方容器不是本地运行的容器，而是由云上运行的多个容器基于投票机制产生的。即某个云容器声明了对资金池验证的选择控制权，如果得到在云上其他的容器半数以上的同意，则该云容器拥有了对资金池验证的选择控制权。同时，对于扣款日志记录，扣款报文加密，扣款异常后的冲正处理等公共功能，本发明方案也将上述公共功能从原有资金池扣款中剥离，该由容器提供相关的功能。不同扣款场景对这些容器上公共功能进行定制，并通过调用云服务的方式获取这样的功能。基于这样的框架，避免了公共功能的重复开发，也有效了避免传统***机制带来的安全漏洞和风险，提升了***信息安全水平。这部分应该作为本发明方案的一个保护点。

(17)融合计费平台以同步或异步两种方式返回处理结果。如果调用融合计费，计费失败，则调用融合计费平台发起退款。待退款完成，则通过回调合作方平台通知用户已退款，资金池扣款退款子流程结束。如果计费成功，则修改订单状态为已支付，线上服务分销平台调用线上服务整合平台的服务接口，来获取线上服务提供方的产品服务。线上服务整合平台会以同步或异步两种方式返回处理结果，如果调用线上产品服务接口失败，则发起退款。待退款完成，也通过回调合作方平台通知用户已退款。如果调用线上产品服务接口成功，则修改订单状态为已完成，同时回馈合作方平台通知订单完成。

(18)线上服务分销平台调用融合计费平台开始进行计费处理，这里有融合计费平台会依据***配置进行实时或异步响应。同步计费响应是指，在调用计费交易完成时实时返回计费处理结果。而异步计费响应则是，在调用计费交易时，***发送异步消息给融合计费平台。融合计费平台不立即响应处理结果，而是在一定时间间隔后(一般设置为1s)以消息的方式通知调用方的处理结果。不论是同步，还是异步的方式，线上服务分销平台在获得融合计费平台的计费处理结果后，确认计费是否成功。如果计费失败，则通过合作方平台通知用户该笔订单处理失败。如果计费成功，则调用线上服务整合平台发布的线上产品服务。

(19)线上服务整合平台在接收到线上服务分销平台发起的线上产品服务后，会开始进行线上产品服务业务处理。同样的，线上服务整合平台的响应，依据***配置有实时和异步两种方式。同步响应，即接收到线上产品服务请求时即刻处理，并将线上服务处理结果返回给线上服务分销平台。异步响应，则是指接收到线上产品服务请求时，不立即响应，而是在线上产品服务处理完成后，以消息的方式返回处理结果。在线上服务分销平台获得线上产品服务处理结果后，则会通过合作方平台通知用户最终的订购结果。

如图3所示，动态进销存以及业务管理的***包含，业务管理后台和业务处理***两个子***，其中业务管理后台则包含供应商模块、渠道模块和报表模块三个模块。在供应商模块的供应商管理功能，提供了供应商列表信息查询、供应商信息新增维护、供应商信息修改等功能，并提供针对相关供应商的状态的管理，包含启用和停用。在供应商模块的供应商产品功能，则可以针对供应商维护该供应商下的产品信息，并提供供应商产品列表信息查询、供应商产品信息新增维护等功能，同时还提供针对该供应商产品的状态维护管理。产品类型可以分为实体产品、卡券类产品、会员类产品、虚拟币类产品、流量类产品、语音类产品等几类，产品形式则包含直冲、券码等形式。在供应商模块的计费产品管理功能，则提供对计费产品信息的查询、增加、维护和删除等功能。计费产品管理，是对相关供应商对应的产品，维护其订购方式、价格、状态等信息。在供应商模块的采购单功能，采购单主要包含采购单名称、供应商信息、合同信息、库存信息等内容。主要提供了采购单的查询、维护、删除，在该采购单下配置产品以及补退货等功能。***的渠道模块，主要是提供销售渠道的管理及维护销售渠道和产品的对应关系。针对供应商产品，可以配置销售渠道和产品的映射关系，即特定的产品可以在特定的渠道进行销售。***的报表模块，则提供了订单交易明细的查询，即用户可以通过一定的查询条件，比如订单号、产品名称等，查询相关订单交易的明细。同时***还提供手工回调的功能。

业务处理***分为四个平台，分别是合作方平台、线上服务分销平台、融合计费平台和线上服务整合平台。平台之间采用分布式的服务框架，按照分层的方式来架构，将各个层之间解耦合，从而实现最大限度的松耦合。其中合作方平台是用户访问***的入口，主要为用户提供订购和查询服务，例如通过内容提供商、渠道分发平台、互联网服务平台等入口都可以接入访问本***。合作方平台是整合这些入口的接入平台，用以提供用户服务。用户通过合作方平台，浏览查询诸如内容提供商提供的特殊权限会员、卡券、返点优惠等产品服务。在用户形成购买意向时，用户则可借由合作方平台发起产品订购。

线上服务分销平台，是作为分布式服务调用的核心处理平台，用以承接用户通过合作方平台发起的产品查询和产品订购请求，并依据客户的请求，进行验证码接口处理、订购确认、业务校验、回调等业务处理。其中业务验证，具体包含以下方面的业务验证，包含了分别渠道和渠道商品验证、停用验证、黑名单验证、资金池验证等。渠道和渠道商品验证，是用来校验该渠道对应的产品是否允许订单交易。停用验证，则是校验该产品是否已经被停用，如果停用，则不允许交易。黑名单验证，是校验订单客户是否在黑名单中，如果客户在黑名单中，则交易终止。同时资金池验证是用来验证资金池余额是否足够支持订单消费的验证，通过查询渠道商户配置的采购单资金池列表，验证每个资金池金额是否够消费。如果资金池金额不足，则交易终止。相反，如果资金池金额充足，则发起资金池扣款，并记录扣款日志，生产计费工单。除提供了订购接口、验证码接口、回调处理接口、查询接口等接口服务供合作方平台调用以外，还会作为服务消费方调用融合计费平台和线上服务整合平台发布的服务。

融合计费平台，是进行订单账务处理的平台，提供计费和验证码服务。融合计费平台作为服务的提供方，在注册中心注册服务，封装服务接口，并提供给调用方调用。比如，融合计费平台的计费服务和验证码服务会被线上服务分销平台调用。当用户发起订单时，会调用融合计费平台的验证码服务获取验证码，当用户确认订单时，会调用融合计费平台的计费服务，进行扣款，并将处理结果信息通过同步或异步的方式返回给用户。在异常情况下，融合计费平台还需要受理退款请求，并将结果通过消息的方式通知用户。

线上服务整合平台，则提供了对接线上服务提供商提供的线上产品和服务，诸如开通会员及其他特殊权益服务。线上服务整合平台用于对接各个互联网线上平台，整合各家线上诸如会员、特殊权益、点卡等产品服务，统一发布到线上服务整合平台上，供前端线上服务分销平台调用。同样的，线上服务整合平台作为服务的提供方，在注册中心注册服务，封装服务接口，并提供给调用方调用。

图4则示意了在动态进销存***订单处理的实例。在实例中，用户发起了一次订购请求，订购的线上产品是某视频网站的会员服务。在用户发起订购之前，***后台管理人员通过业务管理后台的供应商模块，通过供应商管理功能，维护新增了一条供应商信息，供应商名称为视频网站名称，业务类型为互联网特权类，供应商状态为启用。这条供应商信息储存在业务管理后台数据库中。基于供应商产品管理功能，后台人员维护新增了这家供应商下的一款产品，产品名称为视频网站会员服务，产品类型为会员，产品形式为直冲，产品状态为启用。借助于计费产品管理功能，后台人员维护新增了这款产品的计费信息，这款产品的订购方式是包月，价格是5元，计费状态为启用。此外，后台人员通过渠道模块维护了代理商渠道，并配置了代理商渠道和这款线上服务产品的映射关系，即***允许通过代理商渠道订购该视频网站的会员服务。客户通过合作方接入平台，发起了一笔订单用于订购视频网站的会员服务，在开始计费之前，需要进行验证码验证。此时，线上服务分销平台则调用融合计费平台的验证码服务，来下发验证码。融合计费平台会依据和运营商渠道的交易接口，返回验证码的响应结果给线上服务分销平台，而线上服务分销平台则会将此验证码返回给合作方平台，并通过合作方平台反馈给用户。用户收到相关验证码信息后，输入验证码(为6位数字)，并通过合作方平台确认订购。合作方平台将用户的确认订购订单的请求，发送给线上服务分销平台。服务分销平台接收到确认的订单请求，解析相关的订单参数，并对该订单的参数进行校验，并对订单请求包含的用户签名进行校验，确保该笔订单的真实有效。首先进行渠道和渠道商品验证的业务验证，即验证该渠道对应的产品是否允许订单交易。由于***依据配置了代理商渠道和这款线上服务产品的映射关系，即***允许通过代理商渠道订购该视频网站的会员服务，所以此项业务验证通过。其次进行停用验证，通过查询该产品的开通状态，这款会员服务产品的状态为开通，所以交易验证通过，继续进行。接下来进行黑名单验证，订购该视频会员服务产品的用户A不在黑名单中，所以交易继续。同时查询渠道商户配置的采购单资金池列表，验证每个资金池金额是否够消费。按照采购单中的产品数量、订单和库存信息。假定采购单的订单产品数据为M＝1，退货产品数据为N＝0，补货产品数据为L＝0，库存产品数据为K＝100，产品订单单价为D＝5元，依据采购单的订单金额计算公式P＝(M-(N<M？N,M)+(L<K？L,K))*D，在本例子中N＝0，M＝1，所以N<M？N,M＝0，L＝0，K＝100,所以L<K？L,K＝0，本次订单金额为5元。经查询，资金池余额为100元，大于此次订购的价格5元，即资金池业务验证通过，开始调用融合计费平台生成采购单并发起扣款。由于此前配置了低于100元订单金额的订单均走异步模式，所以本次交易融合计费平台没有立即响应计费处理结果，而是在一定时间间隔后(设置为1s)以消息的方式通知调用方的处理结果。此次计费成功，融合计费平台将计费成功消息告知线上服务分销平台。而线上服务分销平台收到计费成功消息后开始调用线上服务整合平台发布的开通会员服务，线上服务整合平台将此会员开通服务请求发送至视频网站。视频网站确认会员开通完成，再通过消息的方式告知线上服务分销平台。而线上服务分销平台获得会员开通结果后，则会通过合作方平台通知用户该笔订单订购成功。

上述实施例仅是发明的解释和说明，不作为对保护范围的限定。

Claims (6)

1.一种动态进销存核算管理方法，其特征在于包括如下步骤：

(1)利用业务管理后台中的供应商模块依次进行产品供应商信息维护、产品供应商下的产品信息维护、产品的计费信息管理；

(2)利用业务管理后台中的渠道模块对销售渠道进行管理并维护销售渠道和产品的对应关系；

(3)响应于客户通过业务处理***中的合作方平台发起的订购请求，线上服务分销平台会受理该订购请求，并依据请求生成订单；

(4)在订单计费开始之前，需要进行验证码验证：线上服务分销平台则调用融合计费平台的验证码服务，来下发验证码；融合计费平台会依据和运营商渠道的交易接口，返回验证码的响应结果给线上服务分销平台，而线上服务分销平台则会将此验证码返回给合作方平台，并通过合作方平台反馈给客户；

在此步骤中，线上服务分销平台基于分布式服务框架封装注册了多个服务接口，包含查询接口、订购接口、计费验证码接口、回调处理接口；

在此步骤中，融合计费平台基于分布式服务框架也封装注册了多个服务数据，包括计费服务数据和验证码服务数据；

上述分布式的服务框架，提供了服务消费者，服务提供者和服务注册中心三种角色：服务提供者，负责提供服务数据，并将服务数据注册到注册中心；服务消费者，则通过服务注册中心找寻需要的服务数据并调用；服务注册中心，则是提供服务数据供需双方服务注册和查询的场所；服务数据的提供方将完整功能，拆分成多个原子的服务数据，并注册到配置中心；这些原子服务数据，由不同的服务器提供；其中合作方接入平台作为服务消费者的角色调用服务数据，融合计费平台作为服务提供者的角色提供服务，而线上分销平台则是作为服务中介的角色；

在完成上述拆分成多个原子的服务数据的步骤后，计算原子服务数据调用处理的平均时间T：随机检测上述分布式***的原子服务数据调用处理的时间为Tn，n＝1,2,3…对其中每一个时间Tn均进行如下判断{|Tn-(T1+T2+…Tn)/n|}/{(T1+T2+…Tn)/n}＜0.67，对符合上述要求的Tn求和，并取平均值，作为平均时间T；当T大于阈值Q时，对原子服务数据再次进行拆分，分别由不同服务器存储执行，同时在配置中心中保存同一原子服务数据的链接关系；

(5)响应于客户输入的验证码，合作方平台确认订购；合作方平台将用户的确认订购订单的请求，发送给线上服务分销平台；线上服务分销平台则开启对该笔订单的校验子流程；该校验子流程包括：

(5-1)线上服务分销平台接收到确认的订单请求，解析订单参数，并对该订单的参数进行校验，同时对订单请求包含的用户签名进行校验，确保该笔订单的真实有效；

(5-2)线上服务分销平台依次开展渠道验证、渠道产品验证、停用验证、黑名单验证、资金池验证；

在步骤(5-2)中资金池验证的实例由云容器生成，并将该实例注入到资金池扣款中供其调用，不同扣款场景就可以复用资源池验证的实例；该云容器是由云上运行的多个容器基于投票机制产生的，某个云容器声明了对资金池验证的选择控制权，如果得到在云上其他的容器半数以上的同意，则该云容器拥有了对资金池验证的选择控制权。

2.如权利要求1所述的动态进销存业务管理方法，其特征在于：响应于用户的订购请求，生成采购单；当出现采购单中的产品服务不足时，则需要开启补货流程，即依据客户的需求对采购单中的产品列表和数量进行补货，并更新采购单信息；而当客户对采购单中的产品服务发起退货时，***则会依据客户的退货请求，更新采购单中的产品数量。

3.如权利要求2所述的动态进销存核算管理方法，其特征在于：根据上述采购单信息计算采购单的订单金额P＝(M-(N<M？N,M)+(L<K？L,K))*D；其中采购单的订单产品数据为M，退货产品数据为N，补货产品数据为L，库存产品数据为K，产品订单单价为D；其中N<M？N,M表示，如果N小于M，则值取N，否则值取M；L<K？L,K表示，如果L小于K，则值取L，否则值取K。

4.如权利要求2或3所述的动态进销存核算管理方法，其特征在于：在进行采购单订单金额计算时，若采购单中产品为虚拟商品，则直接计算采购单的订单金额P；若产品为实体产品，则额外进行如下流程：

①融合计费平台利用相机对存放某一种类商品的整个货架进行拍照，获取清晰完整的整体图像，并发送给管理***；

②融合计费平台识别图像中相似的单元，对整体图像进行分割，获得多个子单元图像，并统计得到子单元图像个数W；

③融合计费平台对各个子单元图像进行比较，找出与其他子单元图像存在不同的子单元图像并统计其数量Q，并将其在整体图像中的位置发送给管理人员，管理人员根据定位进行查看，确认上述包装箱损坏的数量T，并反馈给融合计费平台。

④融合计费平台确定实际库存产品数据为H＝W-(T<Q？T,Q)，(T<Q？T,Q)表示如果T小于Q，则值取T，否则值取Q。

⑤融合计费平台比较实际库存数据H与管理***中存储的库存数据K，若两者不相等，则P＝(M-(N<M？N,M)+(L<H？L,H))*D。

5.如权利要求1-4所述的动态进销存核算管理方法，其特征在于：订单交易发生时，发送异步消息给相关供应商，若供应商无法收到调用消息，则发起手工回调，以手工的方式调用供应商的相关接口。

6.一种实现权利要求1-5所述的动态进销存核算管理方法的动态进销存核算管理***，其特征在于包括：业务管理后台和业务处理***两个子***，

其中业务管理后台包含供应商模块、渠道模块和报表模块三个模块；

(1)供应商模块，包括供应商子模块、产品子模块、计费产品子模块、采购单子模块；

其中供应商子模块用于实现供应商列表信息查询、供应商信息新增维护、供应商信息修改功能；用于提供针对相关供应商的状态的管理，包含启用和停用；

产品子模块，用于维护该供应商下的产品信息，用于产品列表信息查询、供应商产品信息新增维护、状态维护管理；

计费产品子模块，用于对计费产品信息的查询、增加、维护和删除；

采购单子模块，用于采购单的查询、维护、删除，实现在该采购单下配置产品以及补退货功能。

(2)渠道模块，用于销售渠道的管理及维护销售渠道和产品的对应关系；

(3)报表模块，用于订单交易明细的查询及手工回调的功能。

业务处理***分为四个平台，分别是合作方平台、线上服务分销平台、融合计费平台和线上服务整合平台；平台之间采用分布式的服务框架，按照分层的方式来架构，将各个层之间解耦合，从而实现最大限度的松耦合；

合作方平台是用户访问***的入口，主要为客户提供订购和查询服务；

线上服务分销平台，是作为分布式服务调用的核心处理平台，用以承接客户通过合作方平台发起的产品查询和产品订购请求，并依据客户的请求，进行验证码接口处理、订购确认、业务验证、回调业务处理；其中业务验证包含了渠道验证、渠道商品验证、停用验证、黑名单验证、资金池验证。渠道验证和渠道商品验证，是用来校验该渠道对应的产品是否允许订单交易；停用验证，是校验该产品是否已经被停用，如果停用，则不允许交易；黑名单验证，是校验订单客户是否在黑名单中，如果客户在黑名单中，则交易终止；资金池验证是用来验证资金池余额是否足够支持订单消费的验证；

融合计费平台，是进行订单账务处理的平台，提供计费和验证码服务；融合计费平台作为服务的提供方，在注册中心注册服务，封装服务接口，并提供给调用方调用；

线上服务整合平台，则提供了对接线上服务提供商提供的线上产品和服务，线上服务整合平台作为服务的提供方，在注册中心注册服务，封装服务接口，并提供给调用方调用。