Ⅰ 电子商务系统设计
电子商务系统包括：电子商务系统应具有广告宣传、咨询洽谈、网上订购、网上支付、电子账户、服务传递、意见征询、业务管理等各项功能，我们公司用的是上海威博的，他们就包括这些。
Ⅱ 订单整理设计
针对订单系统领域划分
核心域：下单、支付
通用域：用户管理、支付路由、红包、优惠券
支撑域：履约（运营服务、供应链发货）、售后（开发票、退款、结算、收入）
（1）订单DDD
（2）事务一致性 TCC
（3）状态管理：状态机
由于订单系统属于交易系统的中间枢纽环节，所皮陪局有业务逻辑会比较复杂，调用方比较多。
├── interface ## 用户接口层
│ └── assembler
│ ├── dto
│ ├── facade
├── application ## 应用层
│ └── event
│ │ └── publish
│ │ └── subscribe
│ ├── service
├── domain ## 领域层
│ └── aggregate1
│ │ └── entity
│ │ └── event
│ │ └── repository
│ │ └── service
│ ├── aggregate2
├── infrastructure ## 基础层
│ └── api
│ └── driver
│ └── eventbus
│ └── mq
事务一致性实现 -
[[Seate]]
[[rocketmq事务一致性]]
订单状态：订单子状态（订单主状态燃让、货物状态、交易状态）
要点一：分清主次
订单状态：订单主状态、子状态（货物状态、交易状态）
主表子表：订单主表、子表
查询接口：精粒度接口（状态查询）、中精度接口（基本信息查询）、细精度接口（外部查询）
消息通知：胖消息（瘦消息+查询）、瘦消息
复杂查询增加查询域乱码：不过违背了（单一职责原则）
要点二：是否拆单？视情况而定
1、京东拆单：京东建设了拆单服务以仓库维度进行拆单
2、拆弹增加了支付的复杂度（需要多单合并支付）
要点三：退款场景支付
红包、优惠券均摊到sku上（使用银行家四舍五入算法拆分）
如何系统地理解“交易平台”？
Ⅲ 简谈订单管理系统(OMS)
订单管理系统即处理订单的系统，主要管理订单的输入，处理，输出。其在一般电商系统中或在有交易功能的系统中，都是核心系统/功能之一，有一定的复杂度；但是虽然复杂，并不代表理解起来困难。
关于商品的文章里面，我们已经从商品的输入、维护、输出的流程来介绍了商品系统，那订单也一样，我们本文把订单看成一个流程即订单流来理解。
订单系统会与购物车、商品系统，营销系统、会员系统、支付系统、物流系统、仓库系统、财务系统、内容系统，具体请看示例图：
1. 购物车 ：个人认为是订单的起点，商品会被加入购物车，然后会被提交
2. 商品系统： 在提交订单页面会看到该订单所包含的商品信息，例如商品名称、所购买数量、价格、售后信息等
3. 营销系统： 会显示商品是否优惠信息，例如满减、优惠券
4. 会员系统： 会显示该会员是否有基于会员等级的折扣信息(如淘宝的88会员)，或是否有可抵扣金额的会员点数(如京豆)；会显示该会员下面的收货地址信息、也会显示该会员下面是否有充值卡、运费券等。
5. 仓库系统： 基于收货地址信息显示发货仓库，自提地点等，并且订单最终会流转到该系统进行发货操作。
6. 支付系统 ：显示支付方式(如货到付款、在线支付等)、并且在支付的时候计算该会员实际应付的金额，以及显示银行卡信息等。
7. 物流系统： 显示配送时间、配送方式、运费等，并且在订单发货后会显示实际的配送路径。
8. 财务系统： 显示开票信息等，在订单完成后会生成发票。
9. 内容系统： 显示订单留言等
个人认为订单的输入(亦可称之为来源)可分为内部和外部两种方式：
1. 内部： 即自建商城传输过来的订单；
a. 自建商城的订单系统涉及的其他系统比较多，基本上上图所示的系统都涉及到了。
b. 自建商城订单在订单创建时有着更多的判断逻辑，如是否需要事先拆单的、优惠信息是否可用、商品库存是否满足要求、会员是否正常等
c. 内部订单由于存在支付的动作，所以会有多出待付款，待评价这2个状态，
d. 内部订单由于涉及支付和营销，所以对订单系统的并发能力、负载能力以及支付能力有相当高的要求，每一步都不允许出错，一旦出错就意味着营业额的损失和用户的流失。
e. 订单数据计算和处理的要求更高，商品多少金额，优惠了多少金额，抵扣了多少金额，实付多少金额等都需要准确计算，在财务报表内能够清晰展示。
2. 外部： 即第三方系统传输过来的订单，一般代表性的就是分销订单，如供应商的订单系统会接收外部系统的订单，
a. 第三方系统传输的订单，由于订单比较独立，所以涉及的相关系统会少很多。
b. 第三方订单在订单接收时主要判断传输方是否有资格，商品是否上架状态，库存是否满足，收货人信息是否完整等。
c. 由于该类订单相对来说不需要很高的实时性(意思是该类订单对于消费者来说已经付款了，现在只是后端处理)，所以对接口负载性能等要求相对就没有那么高。
d. 订单数据处理方面，一般都是线下核对账单，线下结算款项，所以主要在数据记录和处理的准确性方面有很高要求。
以上就是订单的输入，接下来我们聊订单的处理。
个人认为主要有3种处理方式：
1. 流转处理
在订单系统内，系统会对订单进行各种逻辑规则判断，判断后就会根据业务规则分发订单，可简单看示例图：
基本上订单的流转处理是秒级，甚至是毫秒级就能处理完毕的，不能处理的或者处理失败的都会把订单归类到异常订单。
下面是订单各状态的流程图：
2. 发货处理
订单一般流转到仓库进行发货操作，发货后仓库会把物流信息回传到订单系统，订单系统接收消息后会对订单进行发货：
a. 如果是内部订单则订单状态直接改变(消费者端也会同步看到订单状态变化)；
b. 如果是外部订单则会通过接口告诉第三方系统该订单的物流信息；
3. 特殊情况处理
在特殊情况下，就需要对订单进行人工处理，例如订单无法流转到下一级、订单有备注等。人工处理的结果可能是跟消费者协商后让其退款，也可能是手动的传输订单等。
1. 内部订单：
内部订单的完成并不在发货后就完成，一般来说在客户接收到订单商品后即算完成。但是对不同类型的商城有所区别：
a. 自营商城：一般客户收货后就完成订单，例如京东。
b. 非自营商城：客户需要自己点击确认收货或经过一段时间后系统自动确认收货。
2. 外部订单：
外部订单系统订单一般在发货后就算完成。
1. 在我们设计订单系统的时候应该先思考下公司业务类型和逻辑，理清业务上订单流的起止。理清后从订单源头开始设计订单系统：
a. 如果是自建商城类的那么订单模块会涉及到其他系统，需要与其他系统的产品经理(如多人)去讨论，如何让订单系统与他们负责的系统进行对接；如果是供应链类型的订单系统，则需要考虑如何让订单能够从外部顺利传输到系统，是我们提供统一标准的API呢还是我们去各自对接第三方系统等等。
b. 考虑输入方式后，我们就要依据公司业务运营方式来考虑订单的处理逻辑，订单进入系统后如何 让系统自动处理订单，依据什么规则；同时也要考虑对异常订单的处理。
c. 在考虑好订单处理逻辑后，就要考虑如何输出订单，是直接输出给WMS还是会再输出给其他ERP等等。由于是自动化的输出，也就要考虑与其他系统的对接方式。
d. 最后，我们就要用把公司业务代入到系统内，看看是否能行程闭环，是否还有欠缺或者是否遗漏了细节等。
2. 订单管理系统涉及的其他系统比较多，所以在系统设计上应该具有独立性、拓展型和准确性，独立性代表订单系统的维护或者异常不会影响到其他系统；拓展型代表订单系统在以后增加功能的时候方便快捷；准确性是指订单数据涉及到财务方面，所以应该严谨和准确。
3. 后台系统订单页面的设计：
a. 订单列表页面的设计
根据公司业务需要来设计列表页展示的数据和布局，以及筛选查询的关键字段，具体可看示例图：
b. 订单详情页的设计
订单详情页一般来说是模块化的展示设计，订单基础信息、商品信息、物流信息、支付信息等都需要有所区分，这样设计有利于详情快速查看以及在系统研发的过程中让开发小哥哥不容易搞错哦，具体可看示例图：
c. 订单规则设计
订单规则根据业务的大小有简单和复杂，所以具体需要看业务规模。如果公司现阶段刚起步，则订单规则可直接写进订单系统；如起步有一段时间了或者发展比较快，则可事先就开发好订单规则模块，以后有新的订单规则直接通过运营人员设置即可，更加的方便和更快速的适应业务的发展。
Ⅳ 如何从0到1进行电商订单系统的搭建
搭建电商订单系统，你可漏悄兄以在大平台上开个店，也可以借用一些云平台付费开店，当然如果你有开发团队，也可以自己开发搭建出一个电商订单系统出来。
1、在主流平台上开店铺
比如淘宝、天猫、京东、拼多多、当当等，外贸则在亚马逊、速卖通等平台。
2、借助云平台开店
比如在微盟等云平台上开个店铺，利用云平台提供的系统进行运营。返袭
3、自建电商平台
找专业系统开发公司自建电商平台，自己有开发团队，也可以自己开发系统。
我这里着重讲下自建电商平台，如何从0到1进行搭建：
1、开发系统或购买系统
开发系统首先要选用开发语言，市面上主流的有JAVA、PHP、.NET等；数据库选型主要有MsSQL、MySQL、Oracle等。
选好了开发语言和数据库类型，我们来看下B2C电商系统主要包含运迹哪些功能是需要开发的。所谓B2C就是商家自营销售商品给终端客户，主要模块包含：系统配置、商品管理、会员管理、订单管理，营销管理、库存管理、内容管理、财务管理、数据报表。
（如果是直接购买的电商系统，请忽略这一步）
2、购买服务器或空间
服务器用于存放你的电商系统和数据库文件
3、购买域名
域名可以给客户访问，或用于接口调用
4、域名备案
国家规定域名都需要备案
5、系统部署
将开发或购买好的电商系统部署到服务器上
6、域名解析
将域名解析到服务器上
7、申请在线支付
申请微信支付、支付宝等第三方在线支付账号，集成到电商系统里面
8、其它
如果使用的是小程序，则必须申请SSL证书，才能调用接口
这些搭建完后，你就可以在系统后台去配置各种参数和内容了。
Ⅳ 如何自己做一个订单管理系统
自己做订单管理系统的方法如下：
一、设计思路
首先，先明确订单相关的业务流程，设计要保证每个流程环环相扣。在这个基础上，为了能从【采购订单入库】，到【签订发货】，再到后续的【财务收付款对账】，整个的流程一气呵成，再对财务单独收付款部分进行功能设计，以帮助我们实现一站式管理。
4、库存管理：简化流程，解决进销存难题。库存管理包括库存出库、库存盘点、实际库存三部分，其核心是确保与订单相关的业务流程（销售+客户+财务+产品+库存+采购），把每个流程推得动、用得了。
5、财务管理：财务明细分析，明朗彻底。采购订单若是现结清，系统自动生成付款单待办，由财务去结款；若是月结，则会在固定时间提醒财务去付款；销售发货若是现结清，系统会自动生成回款单待办，由财务去核对入账账目，若是月结，固定时间提醒财务收款。
Ⅵ 订单系统：看似简单的“订单售后”，背后竟隐藏这么多的设计细节
订单的售后类型可分为退款、退货退款及换货。下面分别说明各类型的售后申请。
单纯的退款一般发生在用户支付后，订单还未发货的中间过程，此时用户可申请仅退款。用户申请退款后，系统直接校验通过，不需要人工审核干预，系统直接进行支付通道的原路退款。
用户申请退款时，可选择需要退款的商拿衫品及数量，即支持用户申请全部货物退款，也可以申请部分货物退款。用户需要选择退款原因，退款原因由后台系统提供。单纯性退款的原因一般为型号/参数选错、不想要了等原因。申请退款的页面根据用户选择退款的商品及数量，自动计算退款金额。如果用户申请的的是整单货物全部退款，此时退款金额包含了商品金额+运费金额。优惠券、积分抵扣等各类优惠减免的费用是不会退还的。
商家发货后，无论用户是否收到货物都可以申请退货退款。退货退款一般需要经过商家后台的人工审核，用户方能退回货物，系统在进行原路退款。
用户申请退货退款时，同样需要选择退货的商品及数量，系统支持整单货物全部退货退款，也支持部分货物退货退款。系统根据用户选择退货的商品，计算退款金额，运费与各类优惠金额不执行退款，系统仅退还商品金额。退货退款时，用户也需要选择退货原因，退货原因一般为后台定义并提供给前端系统。退货的原因一般为：型号/参数选错，质量问题，参数与商品描述不符、其他原因等几种原因类型。申请退货退款时，用户还需要上传商品照片（用于商家确认货物是否损坏）。用户申请退货时，系统还支持用户填写退货说明的备注信息，用于和商家沟通，方便商家审核尽快给出审核结果。
用户收到货物，如果对货物质量不满意，可申请换货。换货申请提交后，需要经过商家的审核，审核同意后用户寄回货物，商家重新发货。
用户申请换货时，同样需要选择商品及数量，支持货物全部退换和部分退换。选择换货原因，换货原因一般为后台系统定义并提供。常见的换货原因为：型号选错/参数选错、质量问题、参数与商品描述不符、其他原因。申请换货，用户需要上传货物的照片（无图无真相）。
单纯退款用户提交申请后，系统生成退款售后工单，此类售后退款不需要经过系统审核，系统直接予以原路退款。若用型敏坦户申请的是整单退款，则退款金额包含商品金额+运费，不退款优惠金额及其他抵扣金额。
1、买家填写信息，提交退货退款申请，系统生成退货售后工单。
2、商家通过管理后台审核退货工单，审核时商家可以根据实际情况收取用户一定的服务费（需要与买家沟通），从而修改退款金额。若审核通过则进入下一步，若审核不通过，则换货流程终止。审核不通过，商家可以通过后台编辑不通过原因，告知买家不通过的原因。
3、买家寄回货物，买家可以通过商城预约快递上门取件（商城与第三方快递服务商完成技术对接），完成货物退回。
4、货物寄回后，系统根据商家审核后的退款金额，执行原路退款。
1、买家填写信息，提交换货申请，系统生成换货售后工单。
2、商家通过管理后台审核换货工单，审核通过进入下一步，审核不通过换货终止；
3、家寄回货物，买家可以通过商城预约快递上门取件（商城与第三方快递服务商完成技术对接），完成货物退回。
4、商家收到货物，进行退货入库，挑选商品重新发货
5、买家收到货物，确认收货，换货流程正常结束，完成换货。
每一步的售后操作都会产生一个对应的状态，下面分别说明各类型售后的状态。
买家填写信息，提交退款申请后，生成退款售后单，流程进入待退款状态，系统执行退款后，工单变更为已完成状态。
1、买家填写信息，提交退货申请后，生产退货售后工单，工单进入待审核状态。
2、商家通过后台审核，审核通过，工单则进入待退货状态。
3、买家通过商城发货寄回货物，工单则进入待退款状态。
4、系统进行原路退款，工单则进入已完成状态。
1、买家填写信息，提交换货申请后，生成换货售后工单，工单进入待审核状态。
2、商家通过后台审核，审核通过，工单则进入待退货状态。
3、买家通过商城发货寄回货物，工单则进入待换货状态。
4、商卜桐家挑选货物重新发货，工单则进入换货中状态。
5、买家收到货物，确认收货，工单则进入已完成状态。
在前台商城，售后工单的展示一般分为售后列表展示和售后详情页展示。
售后列表页展示所有的售后工单，列表页的售后单支持按售后类型、售后申请时间、售后状态等条件进行筛选，支持按售后编号、订单编号搜索售后工单。售后类型包含全部、退款、退货退款和换货。售后申请时间为一个日期时间段。售后状态包含全部、待审核、审核通过、审核拒绝和已完成。
售后列表展示的信息主要包含：店铺名称、商品标题、商品规格、商品图片、商品数量、退款金额（换货不展示）、售后类型（退款/退货/换货））、售后状态（待审核/审核通过/审核拒绝/已完成）、售后申请时间、售后编号、订单编号等。大家可以根据自己实际业务需求进行展示。
售后详情页展示售后工单的完整信息，向用户展示了售后商品信息、售后工单信息、售后流程、甚至商家信息等。
商品信息包含申请售后的商品名称、规格、数量、图片，各商品申请的退款金额，该工单商品累计退款金额。售后工单信息包含申请售后时间、售后编号、订单编号、售后类型、售后原因、售后单状态。售后流程清晰的向用户展示该笔售后工单需要经过的流程步骤、以及每一步的时间节点，每一步操作后订单所处的当前状态。商家信息则展示店铺名称、商家的联系方式、与商家的沟通记录等内容。
退货、换货类的售后单详情页还应展示退货、换货的快递方式、快递单号及物流轨迹信息。物流轨迹信息可通过与第三方快递服务商（如快递100）进行技术接口对接，抓取物流轨迹信息。
平台作为连接商家与买家的纽带，应努力为买家与商家之间搭建一个有效沟通的桥梁。售后处理的中间过程，免不了有很多需要沟通的事宜。平台方可以根据自己的资源与实际开发情况为买家与商家之间提供以下沟通渠道：
1、平台展示商家的有效联系方式、联系人或地址信息。
2、鼓励商家将售后、售前咨询的问题整理成FAQ问题脚本，供买家查阅。
3、平台为商家与买家提供在线客服等沟通工具，方便商家与买家能够实时的在线交流，提高沟通的效率。在沟通的过程中，能够支持买家与商家选择特定的售后单、订单发起进行沟通，提升沟通的质量与效率。
售后服务作为订单履约服务的重要一环，各电商平台都很重视订单的售后服务，尽可能的降低用户售后的操作门槛、尽可能快速的解决用户的售后问题。无论是在售后的流程、售后的操作、售后的沟通上，各电商平台都应为用户提供良好的售后服务体验。线上流量已进入存量维护环节，各电商平台都应重视老用户的订单履行体验。做好售后服务，为留住存量用户，提升用户复购贡献一份力量。
有关订单系统的前台设计目前已经基本完结，后续再与大家讨论分享有关订单系统的后台设计。
Ⅶ 电商订单系统设计原理主要用了什么技术
电子商务系统的总体结构设计是在系统体系结构的基础上，针对企业电子商务的目标，界定系统的外部边界和接口，刻画系统的内部成及其相互关系，明确目标系统的各个组成部分、各个组成部分的作用及其相互关系。 系统总体结构设计包括如下内容： 1．确定系统的外部接口 通过分析，将电子商务系统与其外部环境区分开来，从而使总体设计有一个明确的范围。系统与其外部环境的接口包括以下方面： （1）与企业合作伙伴之间的接口； （2）与企业内部既有信息系统的接口； （3）与交易相关的公共信息基础设施之间的接口； （4）其他接口如态烂，如企业与政府或其他机构之间的接口。 2．确定系统的组成结构 系统组成结构主要说明目标系统内部的组成部分，以及系统内部与外部环境的相互关系。 方法： 随着Internet技术的发展，人们的日常生活已经离不开网络。未来闭陪社会人们的生活和工作将越来越依赖于数字技术的发展，越来越数字化、网络化、电子化、虚拟化。电子商务也随着网络的发展日益和人们的生活贴近。本设计尝试用ASP在网络上架构一个动态的电子商务网站，以使每一位顾客不用出门在家里就能够通过上网来轻松购物。在本设计中，我主要完成了后台功能的实现，实现了登录功能，图书管理，图书分类管理，订单管理，用户管理等功能。 本文中所做的主要工作如下： (1)简单介绍了电子商务，分析了电子商务的现状； (2)介绍了IIS+ASP系统的一般原理； (3)阐述整个系统的系统结构及工作原理；分析了系统实现中的特殊性、难点和重点； (4)分析并解决实现中的若干技术问题； 附： 方案设计主要依靠设计者的经验，作出技术和结构的选择，并以有组织的文档反映，作为与客户交流论证方案，交付系统开发人员实施的依据，方案设计的基础是业务环境说明书。业务环境说明书重新组织系统需求，给出解决方案的业务运作方式。在系统需求相对简单时不一定需要，如果系统需求较为复杂时，以文字和图表的方式系统地说明业务环境可以使系统需求更加清楚，业务环境说明书可以采用三种文档结构。 * 业务流程图：业务流程图描述企业的业务在新系统中如何运作，说明新系统的业务运作模式如何解决客户的要求，指出客户的业务流程因为新系统的应用而作出那些更改。业务流程图是一种直观的工具，向客户解释新系统的作用，征求使用者的配合与支持，能提高新系统的实际效能。 * 操作规程说明：相对于业务流程图这种较高层概括的文档，普通用户可能更需要一份详细的操作规程说明，以便更好地理解系统的功能与使用。操作规程说明以易被最终用户理解的词语描述，避免使用过分专业的词语。操作规程说明仍属于高层设计文档，不是最终的操作步骤说明。操作规程说明规定了系统活动的框架， * 处理流程图 ： 细化操作规程中描述的活动，由事件和处理流组成。事件是活动开始的条件，处理是活动中的具体工作。处理流程图的描述层次接近详细设计。以客户在网上购货为例，最后一步是确认付款，操作规程说明只需简单地说明：“客户检查付款额后确认”，处理流程图的说明比较详细，激发活动的事件是客户按下“付额”按钮，处理是付款总额从数据库中统计出来，显示在浏览器上，最后由客户按“确认”按钮确认。 当前普遍采用对象技术描述复杂的应用结构，电子商务系统一般用Java,EJB,CORBA等对象技术实现，在系统设计阶段，编制业务环境书时采用面向对象分析和设计方法可以提高实施阶段的效率。业务环境说明书中的设计文档完成后，召开第二次项目会议，在会上以图表的形式向客户和项目开发人员介绍系统设计的概貌。着重与客户讨论两个问题，检查系统设计是否满足客户需求： 系统设计在多大程度上解决了用户的需求？是否准确地实现了客户的期望，既没有过分简单化，也没有过分复杂化。 系统设计的功能范围是否包含了用户提出的所有需求？ 应用开发人员参加项目会议，可以更好地了解客户的业务环境与方案设计的总体结构，与客户和系统设计者直接交谈，减少沟通的误差，提高效渣漏率。 IBM为电子商务系统定义了一套完整的电子商务应用框架，基于三层次体系结构集成企业核心系统与互联网服务，多层次结构使企业内部应用系统无需作重大更改，通过与互联网服务器的连结就可以在互联网上提供服务，实现电子商务系统的目标。 基于电子商务应用框架的电子商务系统体系结构共有八个主要部分。直接支持应用程序运行的模块有六个：客户端、网络连接、互联网服务器、应用逻辑、中间连接件、核心数据与应用，其余两个模块安全性和系统管理与这六个模块都有关联，系统设计者可相对独立地设计安全性体系和系统管理体系，在应用程序运行支持模块的实现中加入相应的技术与处理。安全性和系统管理的效率是系统的整体性效果，应用系统运行的每一个环节都能影响系统总体的安全性和可管理性。
Ⅷ 业务梳理-电商-订单管理模块
Java工程师知识树
订单中心是一个电商后台系统的枢纽，在这订单这一环节上需要读取多个模块的数据和信息进行加工处理，并流向下一环节；因此订单模块对一电商系统来说，重要性不言而喻。
同时，订单是一个公司生存甚至盈利的核心，而电商系统中的订单系统则是支撑订单处理的载体，因此订单系统的设计则十分重要。
要了解订单系统，首先我们要从订单系统的信息架构上去认识订单系统，从而对订单系统建立整体认知；
定义：为适应组织分工的需求和提升效率，系统将整个交易业团如务流程拆分成若干个可控的环节。
1.在订单过程中进行安全校验，主要是为了检测用户是否在黑名单上，用户购买行为是否正常等，当检测到不正常时终止下单；
2.从商品中心获取塌轿启商品信息（SKU，规格，价格等）
3.从营销中心获取商品，订单促销信息（优惠券,促销活动）,判断是否满足优惠条件，计算出优惠金额。
4.在会员中心获取会员权益，例如平台抵扣积分，优惠券折扣条件等。
5.在调度中心检验销售层库存，按照调度规则锁定区域库存。
6.根据拆单规则（商家，仓库，订单类型等）将订单拆分成若干个子订单，根据运费模板计算运费，根据商品金额，运费，优惠金额计算应付金额（实付款）。
定义：是指在实际销售中将订单的优惠去分摊到每一件SKU中去结算。
订单实付金额=商品金额（SKU金额总计）+运费-总优惠金额
总优惠金额=促销活动优惠金额+优惠券优惠金额+虚拟币抵扣金额
按照商品比例分摊。
案例：
订单中有甲乙两店的商品A、B、C、D、E 包邮。商品A，D参加跨店满200减40的活动（活动1），商品B，C参加满100减10的活动（活动2）另外用户还使用了100元现金券。
订单优惠金额=40+10+100=150元.
依据优惠分摊原则：则各项的优惠金额为：
定义：为了方便订单的发货与结算，系统依据一定的规则（物流、仓库等因素）将用户订单拆分成若干个发货单。
不同店铺：在电商平台类架构下，由于商品归属权不同，涉及财务结算和物流发货的问题，需要根据店铺归属问题对订单进行拆单。例如淘宝，天猫的商品在下单时会将订单根据不同店铺进行拆分成若干个子订单。
不同仓库：若同一订单分散在不同仓库，则应按照仓库归属进行拆分订单。当一件商品在多个仓库有货时，应根据物流的区域的时效选择仓库进行拆单。
不同品类：由于商品的属性不同一样会产生拆单需求，例如易碎品需要特殊包装，超大物品（钢琴，座椅）需要单独包装。有些商品不能放在一起，同样需要拆单。
物流因素：不同物流公司对单个包裹的重量或体积都有特殊要求，需要根据帆洞SKU的毛重和体积来计算包裹的总重量和体积，超出物流公司限制的也需要拆单。
商品价值：根据商品价值需要拆单的主要涉及海淘和跨境的商品；国家对每笔跨境订单有单次限额，对年度跨境商品订单总金额也有限制，当单次购买金额超过限制金额时，也需要对订单进行拆单。
订单正向流程相对常规，业务虽然从商品中心，物流，会员，仓库，内容等各大模块进行数据交互，但涉及的业务逻辑易于理解，所以难度并不大。
但在订单逆向流程中，业务流程和逻辑则相对复杂。因为在订单正向流程中，每一个环节都有可能触发逆向订单任务流；而在订单正向任务流中，每一个子环节上的商品在后台出库发货流程中所处的具体节点不一致，所以不同节点触发的订单逆向流程的处理规则则有差异。
定义：订单逆向流程是为了解决在订单流程中出现的退货退款的业务流程。在前端订单状态下，各个环节都有触发的可能，而订单的不同节点触发订单逆向流程的处理方式不同。订单触发订单逆向流程，可以按照主体与客体划分，可分为用户端触发和商家端触发两种。
1. 待付款取消订单
说明：待付款订单取消订单分为两种情况：
在待付款订单状态下，取消订单无需客服审核。流程图如下：
2. 待发货取消订单
说明：在待发货订单状态下取消订单时，此时应根据订单此时所在的节点作出处理。
由于订单在支付完成后，发货单可能已经推送至WMS，甚至已经交接发货，状态未及时回传更新。为避免货款两失，要先暂停订单出库，在调度中心查询订单是否推送至仓库。
若尚未推送至仓库，则停止推送至仓库；若已经推送至仓库，则去wms中心去拦截，拦截成功则暂停出库。
3. 待收货/交易成功退货
说明：在用户提交退货申请后，需经过客服审核。审核通过则回到原有状态，审核通过后则进入退货流程并告知用户退回地址及收件信息，此时进入退货流程。系统生成退货入库单，当仓库收货后，进行退款。
在待收货状态下平台设计者仍需考虑退货是否全退的问题。当SKU全退时，原订单则中止进入交易关闭状态。当订单中发生部分退货时，原订单的状态不变，维持待收货或交易成功状态，同时退货的部分生成交易售后订单。剩余未退货部分仍然允许申请售后。
注意：在订单流程逆向流程中，涉及到财务数据的处理时 ，为了保证财务数据的真实性及可追溯性（这与会计数据的处理原则有关，具体问下会计或者财务同学），都不能直接在原订单状态下修改，因此在设计订单逆向流程时应注意这一点。
Ⅸ 基础平台设计-订单系统（一）
在互联网公司里，都会涉及到中台管理端，或被称OSS，或称Console。它主要承担的职责是对底层的基础模块、数据等进行可视化，便于管理端的业务操作人员更加简单、高效、便捷的处理事务。本文重点介绍【订单系统】的框架结构、流程、状态机扭转、字段设计，作为【订单系统】系列文章的开篇。
订单系统处于承上启下的关键位置
1.1、 对于用户端，如APP、小程序、PC等，用户对订单的增删改查（查询订单、确认订单、取消订单、支付衡亮纯订单等等），均需要向订单系统发出请求并由其来完成对应的操作。
1.2、 对于底层公共服务，如用户系统（用户的基础键隐信息，如姓名、昵称、手机号等）、交易系统（微信支付、支付宝支付）、消息系统（向用户触达消息，APP PUSH、短信、弹窗等）。则听令于订单系统的调遣，协助订单系统完成闭环流程。
1.3、 另外。咐咐不同类型的订单涉及的相关模块也不尽一致。如电商类订单，则必然涉及商品模块；为了营销目的而产生的各类优惠券，也会属于订单的一个属性。当然，订单必不可少是是发起订单的主体，也就是用户，所以与用户模块息息相关。
订单系统可简可繁，随着业务的处在不同的阶段，订单系统也会随之发生改变。从流程上看，一般可以认为基础的流程有4大块：订单创建、订单支付、订单确认、订单完成/关闭。
以下通过几类常见互联网商品的订单，展示订单的流程及状态机扭转：
2.1、虚拟商品（如会员卡、在线课程、名师咨询等）
2.2、实物商品（涉及物流，商家发货、买家确认等）
一笔订单涉及到的字段，基本上可以由下述脑图概述完整。一般我们考虑：用户信息、商品信息、支付信息、状态信息、促销信息、配送信息、时间信息等。
我们在设计时，可引入中台的概念，做好字段拓展，如【 订单渠道 】。这样，即使后续业务越来越多，从一开始设计的订单系统，通过订单渠道进行区分，也可大大的对不同业务进行兼容和拓展。