订单模型思考
零、引子
2017年的时候，搞过一年的订单中后台服务，后来转战销售、营销、渠道侧搞了4年，机缘巧合之下在新入职的公司负责订单业务，虽然是换了个挺大的方向转回2017年搞的事情，但干一行爱一行，还是趁着这个机会沉淀下订单的一些思考。
本文不涉及到任何技术细节，仅从还原业务的视角对订单进行一个模型的归类，以便看者与未来的自己如果用到的时候有一个更好的理解。
一、交易的定义及所谓的三流分离
1、交易是什么
交易这个行为还原到本质，就是一个双方or多方的资源互换的过程。在没有货币化的原始社会，人与人之间以物易物，也是一种交易。随着时代的发展，无论是贝壳还是黄金，到现代社会的纸质/数字货币，或者信用、债券等等一系列的货币等值物的出现，交易也随之变得更加常见。
一次交易的开始可以视为一份合约的签订，而一次交易的结束则伴随着按合约约定的钱货两讫结束。
2、三流分离
早年互联网技术不发达的时候，大家也无所谓系统架构等等一系列的事儿，随着技术的逐渐成熟，越来越多的人开始思考如何做三流分离，即信息流-订单，资金流-支付，货物流-履约。
在这里不对三流分离做过多的讲解，仅从这三流的视角看，一个订单由3个组成部分构成，即合同的签订-订单，交钱-支付，拿到货物-履约。
二、交易模型
1、交易模型是什么
在各式各样的交易过程中，有太多种的形态发生了。举几个常见的例子，如
- 我去楼下的7-11买瓶水，我拿了我要的水，到收银台通过扫描枪扫描水瓶身上的69码，基于711内部的erp自动计算出价格，我看到后打开支付宝付款码，通过扫描枪扫码，支付结束，这一次交易完成；
- 我想买份保险，于是我找了个BD仔细了解了保险的细则，经过慎重的思考我决定买下这份保险，于是我很认真的阅读了保险的合同，签订了这份为期一年的合同（合约的签订）并交了钱，这时这个订单开始进入履约生效期；在之后的几个月里相安无事，结果突然有一天，我不幸得了重感冒需要去医院住院，这时我想起了这份保险，于是我打电话给保险公司要求核保，保险公司要求我提供各种病例，发票等等（按照合约履行），在我都提供完成后，保险公司如约给我进行了报销（该订单下的一次履约），在这之后继续相安无事，直到一年后，我的保险到期了，这一份合同结束了，订单完结了。我觉得保险挺不错的，决定再来一年，重复了上述的动作（可能没有再次仔细的阅读保险合同）后，我重新签订了合同交了钱，第二个订单下单成功并开始生效。
通过对上述2个例子的描述，例1是最常见也是最简单的模型，不存在超长的履约周期，不存在极复杂的支付环节，简单的商品，简单的支付，一手交钱一手交货。而对于例2来讲，如果这份保险的保单金额过大，需要支付的金额超过上百万，传统的在线支付无法满足的时候，则要引入类似对公转账、汇票等等一系列对公支付业务，这块的业务复杂度绝非简单的在线支付能够比拟的；同时，因为保险天然是长周期业务（单次的航空意外险等在此不讨论），其履约周期往往长达一年甚至更长（终身寿险等），其履约的多变性也注定这样的交易模型更为复杂，类似的业务还有包年制订阅（如YouTube的付费会员可以额外看一些视频，在其会员身份下的观看付费视频的行为均可视为对会员这次合同的履约）。
2、抽象交易模型的价值和意义
自我工作开始，绝大多数时间是浸淫在中后台系统的。一个好的中后台系统至少要拥有稳定的满足业务逻辑、需求的能力；进一步需要做到足够的扩展性，在面对业务的变化中可以以极小的时间成本与人力成本满足新的需求；而完美的中后台系统，可以通过对业务的理解梳理做到前瞻性的设计。
在系统设计中，case by case的去解决业务问题极其容易掉入业务的“坑”里，变得为了解决问题而解决问题。比如上文例子中的保险订单，如果针对单次保险（航意险），短保（一年期的医保等等），长保（终身寿险等）独立进行订单体系的设计，那么整个订单系统服务会变得极其臃肿。
进一步长远的看，在复杂多元化的互联网公司中，有许多中交易是可以用类似的交易模型进行抽象达成单一系统复用的。
对业务场景的抽象梳理，变为交易模型可以更好的帮助订单系统的产品设计者对类似的业务场景进行分析，更好的做订单体系的框架设计。
三、一些交易模型
1、标准电商的最为标准简单模型
1）小卖店即时交易
小额单次支付，单次履约，标准先款后货现货交易；线上的标准品类不存在大额支付，不存在跨境物流或其他影响履约（如期货等）的单次履约交易，类似线下去夫妻老婆店、超市、街边摊的线上版；
其特点是整个业务模式极度标准化，线上可以标准化系统化的采集所有信息与数据；
业务逻辑为订单生成→支付完成（三方托管）→订单进入履约环节→履约完成→（客户确认）→订单完成。
2、相比模型1里的衍生态
1）大宗交易
大额支付单次履约的即时交易，先款后货现货交易，如传统经销商从企业大规模采购、企业对公采购一类的采买交易；对比模型1，其存在最大的问题是受限于各种管控，大额支付不易通过线上标准化系统化，虽然目前有银企直连等体系的存在，但其普及程度以及在订单整体流转过程中的系统化关联度仍然没有标准的WeChat/Alipay/UnionPay等生态完善，在诸多偏传统的线下场景仍需财务/运营/客服等人员对支付状态进行确认，并手动对订单进行关联。
其特点是除开资金流部分，其余业务模式相对标准化；
业务逻辑为订单生成→支付完成（人工确认关联）→订单进入履约环节→履约完成→（客户确认）→订单完成。
2）海淘交易
长履约的单次履约的交易，标准先款后货现货交易；对比模型1，在此暂时不考虑支付方式，仅考虑履约环节，其存在的最大的问题是长物流过程中，涉及到各种清关等等跨物流体系的数据，除此以外，本质上与模型1完全一致。（在此不考虑清关额外计费的场景）
业务逻辑为订单生成→支付完成→订单进入履约环节→履约完成（长履约）→（客户确认）→订单完成。
2、O2O业态下的特殊模型
1）剪头发交易
线上支付，线下履约的，比如团购，线上买了代金券，线下进行消费履约；其特殊点在于并无线上完整的履约过程及数据，履约的环节为线下的实际门店的核销。在此场景下，货物流的数据并不是由传统意义上供应链系统的TMS/WMS提供，而是由券码系统提供的券核销来提供。
业务逻辑为订单生成→支付完成→订单进入履约环节→券码核销→（客户确认）→订单完成。
2）线下促销交易
线下支付，线上履约的，比如叮咚买菜/每日优鲜在地推的时候，线下通过BD的二维码扫码购买商品并填写收货地址，无论是否钱是支付给叮咚买菜的，线上该订单已生成并由系统/BD人工进行确认（如在生鲜及时达的业务早期的老年人无完善的手机支付的，或下沉市场的无手机支付的，由BD代收款同时确认订单后续统一汇算至财务处）；在此场景下，支付及选购的行为由线下进行主导，而信息化、履约等由线上完成。
业务逻辑为支付完成（人工操作）→订单生成→后补确认支付完成（人工）→订单进入履约环节→（客户确认）→订单完成。
在信息化越来越完善的现在，这样的场景愈发的少见了，其逐渐消失的原因不仅是操作流程长，更存在极难管控与合规风险。
3）连锁超市即时交易信息化
线下支付，线下履约，但数据线上信息化的，如山姆、物美多点、宜家等，整个选购流程均在线下完成，支付也在线下完成，但支付过程中，通过对会员码的绑定，将线下的订单信息同步至该会员的个人订单数据中，标识为先下订单。
业务逻辑为订单生成→支付完成（即时到帐）→订单履约完成→（客户确认）→订单完成。
对比模型1中的最大的区别是，模型1中的各项操作基本均为客户自主操作，而在此模型中，客户除了展示会员码信息外，并无其他的线上操作。
4、电商模式下的特殊模型
1）堂食交易
先履约，后付款的，类似许多堂食（非快餐简餐）的交易模式；整个交易的形态与模型1很像，但在整个交易过程中，并非付款成功进行履约，而是先行对客户资质进行审核（风控），如满足条件，则可先期进行履约，并设定履约后的时间区间，在时间区间内，客户可随时进行支付，亦或在时间区间结束后自动按照下单约定（交易合约）的支付方式进行自动扣款。
这类的交易模型往往需要强大的客户信息进行支撑，在行业标准解决方案中，可以借用蚂蚁、微信等国民级应用的现成的能力。
业务逻辑为订单生成（合约约定自动扣款方式，阐述明确时间周期）→订单进入履约环节→履约完成→（客户确认）→支付完成→订单完成。
在这里容易和模型1混淆的点在于，如花呗、信用卡、账期等形式的交易，并非先货后款的交易，而是在金融手段上进行延迟还款。
在互联网电商领域中，常见的有京东的货到付款，或拼多多的先用后付的功能。
2）**赠送订单
写在最前面，其实我并不认为这是一种特殊的交易模型，而仅仅是在支付环节使用了特殊的处理，即无需付款即支付完成的；
但在部分传统企业中，由于财务的要求，在财务科目上对于这部分赠送订单的财务处理与常规订单不一致，由于传统企业的金蝶等财务erp的落后，要求订单针对此类单据做单独处理，在此提一嘴。
需要注意的是，电商场景中，即使某个订单最后并未花费哪怕一分钱的等价货币（包括钱、积分、等），也并不可直接认为该订单为零收入的免费赠送订单，订单的模型中，信息与支付是分离的，在支付环节由银行活动或支付渠道活动提供的减免，最终为该订单付款，则该订单应付X元，实付X元，用户实付0元，支付渠道优惠活动提供方实付X元。
5、基金、理财、股票交易模型
我并未在金融类公司里参与过订单的产品设计，此处也仅以自身的理解来写，如有错误，权当贻笑大方了。
金融类的订单从交易链路上看与常规的订单类似，均是与客户签订合约（该基金股票的情况介绍、购买后的持有、售卖等管理规定），客户认可合约进行支付，支付完成。
但不同的是，基金、理财、股票的购买的商品为虚拟商品，且这部分虚拟商品存在损益变动，举例看，某基金在购买时单支净值为1.1（即花11元可购买10支该基金），购买后随着基金的涨跌，单支基金的净值会随之波动。
单纯的从电商订单来看，购买一刻，订单会冗余记录当时的商品详情、价格，订单一旦成交后续价格波动不会影响订单（京东的价保也并非修改原有订单，而是在该订单上产生了一个额外的特殊售后）。但以上交易模型的区别为，购买时以购买一刻的市值，按照购买金额折算对应的数额，后续的涨幅波动会影响该订单售出一刻的价值。
同时，通常意义上的交易可以被认为是由企业向个人出售，或者说货主向购买者的单向行为，逆向则变为售后行为，但股票的整体交易则为双向，即平台撮合模式下，个人对于股票的买入与卖出均视为一次标准交易。（这个地方存疑，如有大牛，还请帮忙勘误）
至于基金的持有周期过短导致的变卖手续费的规定，则不应该在订单内控制，而是通过独立的商品模块进行约定，在售出时，以原有订单作为依据，结合商品模块上的售卖管理属性进行售出手续费的判断。
勘误，后续仔细思考了下，从订单交易的本质看，金融类产品的交易其实与标准品的交易一致，在购买成功持有某金融产品后，每日的涨跌幅的变动应该是按照变动当日的金融产品价值实时计算并展示的。在售卖一刻，该金融产品的价值随售卖时的金融产品价值而变动；同商品二手交易出售时货主对商品的定价逻辑类似。
6、买车买房交易模型
多次支付，单次履约，最常见的是买车、买房这类大宗消费，与其类似的还有预售等线上交易逻辑；在此交易模型中，由于交易品的特殊性（超大额、长周期，或非即刻售卖的），需要客户针对某个商品支付一笔意向金或定金，之后在特殊时间周期内（如有需要可控制），将尾款补齐，该订单视为支付完成。
如不考虑房、车的过户流程（在履约环节内），其业务逻辑可被抽象为订单生成→首次支付→尾款支付=整体支付完成→订单进入履约环节→履约完成→（客户确认）→订单完成。
在诸多预售活动中，往往存在定金一抵多的逻辑，对于该交易模型来讲，定金一抵多与交易无关，更多的是运营活动的能力支持。
7、订牛奶交易模型
在这种交易模型下，无论是标准电商的衍生模型、亦或是O2O业务场景下、甚至保险、金融等非实物交易的业务模型下，均有此类模型的存在，即单次/多次支付，履约生效周期长，多次履约直至订单完结。
以订牛奶的场景示例，我以1天要一次牛奶的要求，直接交付一年的钱，在付款完成后的一年内，我每天都可以收到新的牛奶；又或者是我花钱购买了Amazon的杂志订阅权益，权益约定我可以在限定的时间内免费下载并阅读N次刊物；
与之类似的电商的订单多次发货，O2O场景下的团购某剪发卡10次，或者保险下多次核保、购买股票后的多次派息等（同上，我并未设计过金融型的订单系统，这里如有错误，还请大牛指正），均可视为一次订单的多次履约。
但在此我也会产生一个疑问，或许在不远的将来我有机会亲身进入到金融领域参与订单的建设时可以解答我的疑问，即多次派息是否也可被设计为多次独立的子订单。
业务逻辑为订单生成→支付完成（三方托管）→订单进入履约环节→分批履约→（客户确认）→全量履约完成/合约约定周终止→订单完成。
8、打车交易模型
在这种交易模型下，订单生成的时候仅有一个关于计费模式的约定，常见的如打车、广告投放等。在签订合约时，仅约定单次/单价为X元，在履约完成后，基于消耗的次数/数量进行扣费，后补订单；
而伴随打车交易模型常见的配套设施如客户画像与风控，以及预付储值等均为更好的提供该服务的能力。
其业务逻辑为框架订单约定（以打车举例，通常仅约定固定不变的内容，比如该订单的单位里程计价为X元，约定该订单的起止为A点到B点）→履约完成→详细订单生成（基于实际履约的数据与框架订单的约定计算真实的金额）→支付完成→（客户确认）→订单完成。
至于在打车交易模型下，处于风控的要求，部分超长距离的订单要求客户基于预估值提前支付一笔费用的情况（亲身经历，某次深夜打车距离超50Km，订单费用预估在￥200左右，平台要求我预付￥100），其交易模型本质并未发生变化，仅是订单复杂度变得更为复杂，业务逻辑变为框架订单约定→（部分支付）→履约完成→详细订单生成→支付完成（完整支付/补支付/退款）→（客户确认）→订单完成。
9、手续费交易模型
在上文提到过基金交易存在手续费的问题，对于这种交易的形态我仅发表我个人的拙见。
曾有幸在蚂蚁金服工作过一段时间，在支付结算的能力里，存在分账/返佣的模块，而手续费收取或类似的交易模型更像是在交易的过程中而非结算的过程中，对此，有几种处理方案的猜想。
其一是，在订单中强制自动代入手续费的商品信息，基于系统自动计算形成最终的订单，适用于购买某商品时的正向交易额外付费的情况，其更类似后续提到的配件交易；
其二是，订单按照正常的金额结算，但在真实进行财务提现时，使用分账的逻辑，将应分得的钱通过分账计算变为扣除手续费后的金额，更适用于基金交易；
其三是，单独生成一笔手续费订单，该订单与主交易单据关联，合并计算费用并进行支付，与方案一对比好处在于各订单的数据更清晰更独立，但存在的问题为数据量冗杂等问题。
同模型5与7中谈及问题，我也期待后续的工作中有机会在实战中解答我的问题，给自己和读者一个确切的结论。
四、配件交易模型
无论是在某生鲜O2O公司还是在当前所处的某快消品制造公司的工作过程中，都发现了一些脱离上述交易模型的存在，即附加品的交易。之所以说其为脱离上述交易模型的原因是，这些交易并未孤立存在的，需要依附交易某交易之下，以买卖、租赁、借用的形式出现。
对于此类业务，我称之为配件交易，为了更好的解决这部分业务需求，我对日常可见的一些交易进行了聚类汇总，以求在配件交易模型的设计中帮助自己有更好的认知。
1、啤酒瓶模型
在传统线下业务中，玻璃瓶装在售卖时，部分小卖店会言明啤酒￥3，玻璃瓶￥1，如后期退还瓶身，每瓶可退￥1。
在此交易模型下，该配件视为商品的包装物，强制附带在商品维度，与商品有强绑定关系，商品不可独立售卖（不欢迎杠精说我拿着塑料袋或者桶过去现场拆瓶装到我自己带的容器里）；购买时买一个商品就必须附带买制定数额的配件，商品和配件不可拆分，订单也不做拆分；
举例如啤酒瓶、部分带外包装的生鲜等；
在此业务逻辑下，订单生成时，针对该订单的明细行内，默认生成商品制定数额的配件，至于对应配件的价格（无论买卖或租赁借用），合并计算向客户收款。但如配件以租赁/借用的形式出现时时，在财务结算阶段，需要对该订单内金额进行拆分计算，即商品的计入交易收入，配件计入财务冻结。
2、餐具模型
举例如饿了么外卖，点餐完成在订单确认页有一个选项是选择餐具的数量，从不选择到若干；
在此场景下，餐具数量可以作为订单的一个附加标准信息记录，无需强制关联校验（也可存在校验以防浪费），属于独立的附带信息传递；
实际上，除开饿了么点餐的餐具选择以及阿里系的部分交易外，我迄今为止确未见到类似此类的配件交易模型。
3、安装服务/高速费/额外保险模型（前置交易）-存疑请自行斟酌思考
当在京东或淘宝购买大宗家电，可以额外购买安装服务。事实上，在选择安装服务时，京东的处理方案为将安装服务作为一个独立的商品行明细记录，对比啤酒瓶模型，该新增的商品与订单内的任何商品均无关联关系；对比餐具模型，该安装服务作为一个标准的商品而存在。
或许在我尚未使用的其他电商中，该类交易模型所设计到的服务等会被设计为单独订单的存在，即安装或保险记为独立的订单，与主单据有关联关系。（未来有机会买手机的时候在京东买个碎屏险试试，如果有区别，我会回来更新的）
同样的，滴滴在订单前期约定是每分钟xx元，每公里xx元，如产生高速费额外产生xx元，当实际履约完成后，高速费会记为标准的订单明细行记入订单内。
在此需要特殊说明的有2点。
1，安装服务模型仅在下单时选择会以上述模型运作；而当下单时并未选择安装服务又或安装服务单独收费时（猜测），店家往往会提供另一个独立的商品，拍下即视为购买了安装服务，此时从系统逻辑上，这两笔订单并无任何关联，即后置交易时，该安装/保险的配件交易模型不属于该模型。
2，对于安装服务，另一电商头部巨头的淘宝的方式则与餐具模型类似，记为一项服务权益。
4、**啤酒瓶盖模型
在传统快消品行业，有一个江湖传说-江小白。其在推广的过程中，利用了人性的本质快速增长，成为了白酒品类的一匹黑马。他做的方式也很简单，给餐厅的服务员返佣，一个瓶盖反5毛钱。（在这里不对为什么给餐厅服务员返佣可以获得快速的增长这件事展开讲，未来有机会再单独说）
看上去啤酒瓶盖与啤酒瓶模型很像，均为该配件与商品进行强绑定。但经过与酒类行业的前辈交流获知，其本质有着极大的差异。
啤酒瓶本质上是要回收做二次利用灌装的，所以其逆向的交易（退瓶）往往与正向交易有这强耦合关系（买了一瓶啤酒过去退上百个啤酒瓶这件事儿，也许线下可以搞，但线上电商绝大多数情况下走不通）。
啤酒瓶盖更像是一种营销手段，回收啤酒瓶盖的方式往往以线下BD回收计数（实施成本低，人员/管控成本高）或通过瓶盖内部的唯一识别码线上完成（实施成本高，人员/管控零成本）来实现。
这种回收的机制，已经完全脱离了订单的管理范畴，更倾向于物料与营销活动管理中的事情。故啤酒瓶盖的配件并非通常意义上的配件交易。
五、写在最后
就我的职业生涯来讲，如果我说我对销售、营销领域是擅长的话，在订单侧我只能说自己是一知半解。整篇文章与其说是写给观者的不如说是帮助自己更好的做复盘。
交易作为经济中的最基本也是最常见的一环，其历史从人类有了社会性行为后开始就无时无刻的在发生。随着社会的愈加完善，交易的发生也愈加频繁，仅仅靠我短暂的工作经历是绝对不可能把所有交易模型写全的。
随着对交易的认知的愈发深刻，我会随时更新这篇文章。同时，也还请各位行业大佬不吝指教。