电商系统对接模式及优化建议

目前，企业的应用系统越来越多，ERP和其他系统对接的需求也越来越多。

为了更好地服务消费者，节省商家成本，各大电商平台将平台店铺商品、订单、物流等数据开放给合作伙伴，让合作伙伴可以将店铺数据通过接口拉入自有系统进行后续的收发货和财务结算，

也支持将收发货结果等信息回传平台通知消费者，从而达到快速发货、快速退换货，也让商家可以通过系统自动处理订单、退单、记账、报税等，节省大量人力成本。

其中，对接比较多的是前端的电商系统、零售系统。这些业务场景下应用特点是单据金额都不是很大但是单据量大，有些一天万级，一个月百万级。

。这样大的业务量和数据量，高效，可靠，安全的对接是保障正常应用的关键。在进行电商对接项目之前，需要进行一些准备工作。

首先要明确项目目标和需求，确定对接的电商平台种类和数量。其次，要进行需求分析，

了解每个电商平台的特点和要求，以便进行针对性的开发和对接。还需要评估项目的可行性和风险，确定预算和时间进度

系统集成，将不同的电商平台连接到一个统一的管理平台上，实现数据的共享和交换。其次，进行订单对接，确保订单能够在各个电商平台之间互通。还要进行商品同步，

实时更新商品信息和库存，保证商品的准确展示和及时配送。此外，还需要进行支付对接，确保支付的安全和顺畅。最后，进行数据分析和报表展示，通过对数据的统计和分析，提供决策参考和业务优化建议。

      收集了一些自己对接电商的经验以及对接项目的反馈，针对电商/零售等大数据场景下项目的对接总结出一些建议。这些建议包括业务流程优化建议和对接接口性能优化建议。遇到类似场景的做对接的人员可以参考。

场景：前台电商/零售等对接星空供应链系统。

一、业务流程对接建议：

1、流程简单，将ERP作为末端的接收方，减少数据交叉传输。

       这个其实就是要求只对接流程结果。各自系统中尽可能把流程完整跑完，将一个流程的结果传入另外一个系统即可。这样的好处是流程各自独立运行，互不影响，一旦接口出现问题，双方系统还能独立运行。对业务的影响最小。

电商和零售等业务，我们建议流程上只对接电商和零售的销售订单，销售出库单，

2、对接的单据尽可能不要产生跨组织内部交易。

       由于前台电商，零售门店多，业务量大，出库单量非常大。如果这些对接过来的销售出库单需要做跨组织结算，会生成大量的内部交易单据，以及跨组织的明细结算清单，后续对账、核算带来很大的工作量。2C的销售出库单都是针对电商客户的零散的出库，出库单明细非常多，建议业务流程上取消电商与总部之间的销售出库单的跨组织交易，内部通过购销或者调拨的跨组织交易模式进行。即总部与电商通过调拨方式，这样调拨可以定期(如每天每周)成批调拨，降低单据量。这样跨组织交易就变成了2个组织之间调拨单，数量汇总了，单据量少。跨组织交易生成的应收应付清单数据量少，对账对总数即可，简单。而非前端的几十万的明细销售出库单。

3、建议按一定的规则汇总合并后生成星空的销售订单，销售出库单。（一般建议采用T+3，或者T+5模式），如果数据量比较小，采用T+0模式合并

     通过一定的汇总依据传到到星空，生成数量合并的销售出库单。降低出库单的明细分录数量。参考如下的方式，对销售订单，销售出库单进行合并。    

     大数据量下对接数据对接到ERP的中间表中。通常将外围第三方需对接的数据对接到ERP的中间表中，中间表按一定的合并规则(相同物料、相同店铺等)合并。

     前端电商和星空，考虑按一定的条件进行合并（如店铺、物料、仓库、时间等维度），如按天，将同一个店铺，相同的商品前端的出库单进行合并再传给星空。

一般数量可以成倍几十倍的降低(依赖于相同商品的购买频次、合并的时间范围、业务量的等因素，如一个店铺某种商品，一天卖出100笔，正常按数量合并后，只有一笔，数据量约为原来的1/00)。这样的一个好处是，出库单的分录数量大大降低，由于合并数量了，核算、后续的应收应付、对账更加高效，简单(不要从几万，几十万的明细数据中核对，只要对总数量、总金额，效率提升)，另外一块是出库单、应收单之类的日常操作，审批等业务用户的体验会更好。

4、简化模式的对接，如果在不影响业务流程的前提下，可以考虑只对接销售出库（不对接销售订单），如果同时生成销售订单，销售出库意味着销售出库生成会关联销售订单，从而影响销售出库生成的时间

二、    对大数据量接口性能上的优化建议： 

       大数量应用场景下，性能上主要体现在2个方面，一个是对接的单据传输性能，另外一个传输过来后的大量单据后续的核算、应收、应付等单据操作上的性能。

        目前收到部分项目中，由于对接的数据量大（每天几万到几十万销售订单，销售出库单），造成单据传输接口性能瓶颈，以及对接生成的出库单单据量比较大，

因此出库单据的核算、出库单的操作如审批下推生成应收单等都有较大的性能问题，影响用户的体验。

   针对接口的性能优化建议：

1、 生成的单据中取消不必要的服务，不必要的字段赋值。

       服务端收到消息后首先对接受到的客户端数据包中每个字段值进行解析(解析分为取数,赋值,触发值更新事件,调用表单服务等),所以性能优化第一点就是尽可能精简Josn数据包里面的字段;

       针对具体的项目中，不用的功能服务取消。如对接销售出库单，传过来的出库单单价、金额都有的，那么取价服务可以不要。前台2C的用户，信用相关的服务可以不要。库存的锁库与预留等相关的服务都可以取消。这个针对具体的场景，不需要的业务和服务都可以取消，加快单据的传输。可以根据项目和应用具体自行评估可以取消的服务。

2、 考虑批量接口调用及批量合并。

       每次不要一单单传输，按一定的批量传输，数据要分批通过执行计划对接，通过ERP的执行计划插件，少量多次，分批轮询执行，每批次定量从临时表抓取待同步的数据（比如一次200条，控制在5分钟内本批次的全部执行完毕的最优条数，避免超时）。

3、 WebAPI基于安全考虑,要求调用增删查改等接口之前,需要先调用登录接口。 但是同步的数据时候应该避免每次调用保存接口之前都调用登录接口(会话默认超时是20分钟,没有必要每次都调用登录接口,登录接口本身也是一个耗时的操作;

4、 可以考虑多线程传输：客户端可以开多个线程调用。

 接口优化方案可以参考：https://vip.kingdee.com/article/11179?productLineId=1

三、出库单单据量大的优化建议

       由于前台电商，零售门店多，业务量大，出库单量非常大。大批量的出库单后续的核算、应收、应付等单据操作上的性能的问题，建议是可以考虑按一定的措施合并分录/单据。具体建议如下： 

    1、大数据量下对接数据对接到ERP的中间表中。通常将外围第三方需对接的数据对接到ERP的中间表中，中间表按一定的合并规则(相同物料、相同店铺等)合并。

     2、前端电商和星空，考虑按一定的条件进行合并（如店铺、物料、仓库、时间等维度），如按天，将同一个店铺，相同的商品前端的出库单进行合并再传给星空。一般数量可以成倍几十倍的降低(依赖于相同商品的购买频次、合并的时间范围、业务量的等因素，如一个店铺某种商品，一天卖出100笔，正常按数量合并后，只有一笔，数据量约为原来的1/00)。这样的一个好处是，出库单的分录数量大大降低，由于合并数量了，核算、后续的应收应付、对账更加高效，简单(不要从几万，几十万的明细数据中核对，只要对总数量、总金额，效率提升)，另外一块是出库单、应收单之类的日常操作，审批等业务用户的体验会更好。