优惠计算主要包括优惠券和促销活动的金额计算。一般情况后台会有一定的计算优先级，比如计算促销活动的金额，完成后再看是否满足优惠券的满减金额。计算时需要考虑促销范围，如商家还是全场。

　　金额分摊，电商的支付类型发展到如今是越来越丰富。信用卡、汇款、支付宝、微信、白条、积分、礼品卡等等各种各样。考虑到订单逆向（整单退，部分退）的情况，需要将所有支付的金额包括优惠券都分摊到每一个商品上，以便退款时可以保证金额不错。分摊计算有两个要注意的事情，一个是各项支付方式退款的优先级，先退什么在退什么。原则上先退成本低的，在退成本高的。二是当分摊时金额除不尽的时候多余的部分如何分摊，小数后三位的时候四舍五入还是直接舍掉。这个规则要和后端、报表保持一致，避免出现一分钱误差的乌龙。

　　（3）收银台

　　订单生成后要通过支付系统完成支付操作，所以收银台的主要对接系统就是支付系统。对接第三方支付的时候需要注意的是，第三方支付客户端返回的状态原则上不能作为最终支付成功的状态，要通过第三方支付服务端返回信息为准。理论上这两种状态是同步的，但设计时要考虑交互和数据传输异常的情况。

　　售后环节：提高信息透明和服务体验

　　订单详情页

　　订单列表页

　　在线客服

　　售后环节主要是订单生成后到订单交付完成的整个过程。这部分主要的功能就是跟客服和订单打交道。这里就不展开说了。只说一些需要注意的经验。

　　订单列表一般会保留三个月左右的用户显示数据，而用户端的删除不是物理删除只是订单上打标记而已。

　　在处理数据时考虑到历史数据较多，部分O2O的APP会使用历史订单数据和当日订单数据分开的读取的方式。

　　订单详情一般会有再来一单的功能，电商系统只需要判断是否存在可售卖的SKU即可。而O2O则需要增加判断区域属性。

　　在线客服要考虑是否是对接第三方应用，在嵌入对方的SDK时一些通用的标准要符合满足（比如IPV6）。另外对方SDK包是否会对自己APP的大小造成较大影响也需要注意。

　　个人中心：服务中转站

　　个人中心作为用户的统一服务中心，里面承载了所有涉及用户资产和服务的信息。大多数是信息汇总查看的页面（如我的订单、我的积分、我的优惠券等）。

　　这里强调一个小的细节，APP用户端有时候排查问题需要了解用户的基本信息，比如版本号，手机型号。用户的反馈很容易出现信息误差，他们大多会说已经是最新版了。所以获取版本信息的渠道可以在个人中心中。我以前的一个经验可以给大家借鉴。在意见反馈自动增加版本，手机型号信息回传，或通过关于APP的部分让用户一键复制以便提供给客服进行排查问题。

　　用户端的“亲属关系”

　　用户端作为“门脸”，和各个系统有着错综复杂的关系，让我们看下他们之间的关系是如何。

　　在整个电商系统体系里面。用户端需要面对众多系统，而这些系统的数据又相互依存，他们之间通过API进行传输对接。

　　直接对接系统

　　页面系统

　　CMS系统

　　广告系统

　　购买流程

　　交易系统

　　支付系统

　　订单系统

　　规则整合

　　搜索系统

　　推荐系统

　　促销系统

　　用户体系

　　会员系统

　　客服系统

　　这些直接提供数据给用户端，负责用户端的生养问题，用户端对他们有着很强的依赖。在设计时要充分考虑这些系统的数据逻辑情况，下面我们会详细说明下如何考虑这些系统。

　　间接对接系统

　　库存系统

　　商品系统

　　价格系统

　　物流系统

　　商家系统

　　间接对接的系统多是提供基础信息的系统或者平台。他们承担着数据最底层的管理工作，他们的结构决定了前端展示的信息数据项。由于涉及的细分系统众多，这里指列举了部分主要系统。

　　API

　　API主要是传输通道，理论上不做逻辑运算。但现在很多实际的情况下API也需要夹杂很多业务规则的计算和处理。API主要包括几个部分的功能：

　　（1）数据传输

　　API的基本功能，完成基本数据的传输，往往是以页面为单位计算API的数量。

　　（2）数据整合

　　由于数据可能涉及到多个系统之间的调用，所以API内部可能需要进行数据的整合。比如促销活动信息需要调用促销信息和商品基础信息。

　　（3）部分逻辑处理