导读：等着收是什么意思？，电商订单是是如何产生的？交易系统一直是电子商务的核心模块，几乎所有的业务都是围绕它进行的。看似简单的下单流程，实际涉及的模块和内容也很复杂。这次我把下
等着收是什么意思？，电商订单是是如何产生的？
交易系统一直是电子商务的核心模块，几乎所有的业务都是围绕它进行的。看似简单的下单流程，实际涉及的模块和内容也很复杂。这次我把下单的整个环节抽象出来分享给大家。
01关于订单
1.什么是订单？
首先，我们来说说什么是订单。
订单可以简单理解为买卖双方签订的具有法律效力的合同。一般来说，合同的订立有两个程序:要约和承诺。卖方展示商品及其价值的行为是要约；买家确认购买商品并提交订单的行为为承诺。订单提交后，合同成立并生效。所以我们可以简单的理解为，订单其实是客户和商家签订的合同，具有法律上的利益。
2.订单的生成和流通
参考以上，如果从前端的经验来看，订单的生成是加车后结算还是立即购买。进入结算界面，确认订单所有信息无误，提交后生成订单。
但是从内部系统的订单生成过程来看，需要内部各个系统的配合和支持，包括风控系统、商品系统、营销系统、会员系统、库存系统等。，在订单生成之前。以上系统流程只是对主要交易流程的梳理，各个系统中的数据如何交互并没有列出，可见整个电子商务交易系统有多复杂。
02风险控制系统-风险订单检测和拦截
说到风控体系，最容易联想到银行借贷、P2P等金融领域的风控。无论是金融行业还是电商行业，风控的本质都是保证平台利益不受损失。
电商订单风控主要是两防——防刷；防羊毛党。
1.防刷洗
商户计费影响平台流量分配，间接影响商户管理体系建设；商家刷单系统大概经历了野蛮生长和集中刷单两个时期；平台监管，精细化刷单。
电商之初，销量是唯一的英雄，“养成”了商家刷单的习惯。再加上没有平台监管，一个人一台电脑就能刷一天。那时候刷不叫刷，叫刷/刷冠，主要刷的是店级。
然而，“好日子”很快就要到头了。随着平台的流量分配从店铺向单品转变，以及管理规则和风控体系的不断完善，商家的刷单成本越来越高，刷单工作不得不交给“专业”的人。所谓精细化刷单，就是模拟用户真实的下单场景，忽悠系统以为是普通用户下单。如何搜索商品，需要浏览多少商品，每个页面停留多长时间，是默默下单还是协商下单，都有严格的规定。
业内早就公认，没有一劳永逸的反刷单策略，最好的办法就是不断增加刷单成本。
2.反羊毛党
羊毛党薅羊毛的做法直接影响了平台/商家收入，损害了正常用户的购物体验。说到羊毛党，还有一个词:黑产。单打独斗的羊毛党不可怕，系统作战的黑产队才可怕。他们往往分工明确，主要针对电商平台业务(规则)漏洞和系统bug，这样一天就能吃一年。
上面的流程图会经过用户提交订单申请后风控系统的风险检测，但此时的风险检测比较初级，主要是针对某些事件拦截订单，比如用户黑名单、下单环境等。
因为在下单时，风控系统能获得的领域信息较少，缺乏大量的数据支持，很难准确判断用户的下单行为。而且下单过程属于高并发场景，系统反馈需要毫秒级完成，复杂的风控检测会严重拖慢系统进程。所以更复杂的风控会在用户下单成功后异步进行。
异步风控检测后，系统会关闭(取消)触及风控策略的订单。当然，风控不仅仅是拦截订单，还需要有报警机制，以及复杂场景下的人工干预。
1919年1月，拼多多因为息票事件被非法生产了数千万羊毛，原因是缺乏有效的风险控制机制。
03商品系统-商品信息的获取
订单生成时，需要通过商品系统获取商品的基本信息、数量和价格。同时，一些电商平台也会记录交易快照，这也需要商品系统支持。
1.关于事务快照
什么是订单产品快照(交易快照)？从字面上看，很容易被理解为用户下单时所订购商品详情的快照(截图)。其实严格来说，商品快照是静态数据的集合，记录了用户下单时商品的信息，包括:商品的图片、标题、描述、服务等元素。
淘宝是中国较早启用交易快照的电子商务平台。为了解决商家和用户的交易纠纷，用户下单时很难追溯到商品。淘宝的产品经理介绍了交易快照的概念，即用户每次下单，都会对下单时的商品信息做一个记录。快照作为买卖双方交易的凭证，任何交易纠纷或投诉都将以快照为准。
大部分电商平台做交易快照的初衷是为了解决交易纠纷。此外，事务快照还用于法律诉讼。法院对相关诉讼作出裁定时，认可交易快照作为证据，但需要证明快照是用户下单时的商品快照，不可篡改。
2.交易快照记录
交易记录:目前主要有两种记录方式，如图所示:
04库存系统-商品库存核实
1.库存的定义
关于存货的定义，百科中给出的解释是:“实际存放在仓库中的货物”。但在这里我特意提到了虚拟库存，以便与实际仓库库存相区别。
目前商家在电商平台上维护的库存称为虚拟库存。虚拟库存可以简单理解为不存在的库存，与实际仓库库存无关。可以认为虚拟库存是商家指定的平台的渠道可售库存。如果商家有一批货在生产、采购、运输或者仓储，或者商家觉得自己可以承担超售的风险，有办法从其他地方调货，虚拟库存可能比实际仓库库存大。
2.库存预占和库存核实
说到库存预占，电商发展有个经典问题:是下单减少库存还是付费减少库存？
现在想想，什么时候应该减少库存？
线下实体商超是什么样的？
这里不考虑实体店超过仓库库存的情况，只考虑货架库存。库存什么时候会减少？或者说这个库存什么时候会被用户占用？应该是用户把商品从货架上拿下来放到购物车里的时候。
那么，网购过程也是通过加入购物车来减少库存？显然，网购购物车“加车”的操作几乎是零成本的。决定了它更像是一个商品收藏池或者备忘录。用户将备选商品放入购物车，然后进行第二次选择。添加的商品数量远大于用户的实际购买数量，因此扣除购物车中的库存是低效的。
下单时扣除库存怎么办？
相当于用户下单。系统已经为该用户分配了相应的存货，用户付款成功后即可发货。这是一个正常的过程。但会出现不支付恶意预占库存就下单的情况，导致商家的商品无法及时销售，销售受损。
如果我们更进一步，在支付成功时扣除库存呢？
这种方式在一定程度上提高了恶意订单的门槛。但问题也随之而来。当商品供不应求时，大量用户抢购。这时候大部分用户都可以下单成功，但是只有少部分用户可以在支付过程中完成支付。对于支付不成功的用户来说，体验太差了。
以上两种有效的解决方案，无论是通过下单减少库存，还是通过支付成功减少库存，都不是完美的解决方案。那么你应该选择哪一个呢？在苏杰的《淘宝产品十年》中回忆到，当时淘宝的产品经理也在纠结选择哪种方案，最后妥协了，提供了两种方案，商家可以自行选择。
在我看来，对于平台型电商来说，下单降低库存，不如支付成功降低库存。
从体验角度:用户(购物)体验是平台型电商的核心竞争力。下单减库存影响商家销售，付费减库存影响用户体验。所以从购物体验的角度来做取舍，更人性化。从系统层面来说，支付和减少库存比下单和减少库存更复杂。减少库存涉及到订单系统-库存系统-支付系统的交互，而减少库存只能通过订单系统-库存系统来完成。库存减少在高并发场景下容易超卖。
05订单系统-订单信息记录
1.订单打开
1)为什么要拆分订单？
核心点有两点:结算容易；易于运输。
主要是围绕以上两点进行的，常见的打开文档的规则有:
按商家拆单；不同商家间需要拆单按仓库拆单；不同仓库间需要拆单按商品重量、体积拆单；快递公司对包裹最大体积/重量有要求按商品价值拆单；贵重、易损商品单独拆分等按发货方式拆单；如实物商品与虚拟商品混合下单，发货方式不同按配送时效拆单；如正常商品与预售商品混合下单，发货时效不同具体的订单拆分规则根据平台不同，业务场景不同而不同。大多数业务需求可以通过将订单分成两个方向来满足:轻松结算和轻松交付。
2)账单什么时候开？
让我们来看看JD.COM和淘宝分别是什么时候拆分订单的。
京东：用户订单支付成功后进行拆单淘宝：用户提交订单，支付前即对订单进行拆单那么什么时候开账单有什么意义呢？由于经营形式不同，淘宝以商户为主，而JD.COM以个体户为主。所以淘宝的拆迁逻辑比较简单，大部分拆迁诉求都可以通过商家拆迁来满足；但由于JD.COM涉及自营仓+商户，还涉及仓间/仓内分单，分单逻辑更复杂。将分单逻辑过账到支付成功，可以减少无效分单(未支付订单不打开)，提高高并发下的系统性能。
所以在拆分订单时，遵循两个原则:
占用资源最小原则（特别要考虑高并发场景）；订单推送前需要完成拆单（推送至商家/仓库前都需要完成拆单）2.订单折扣计算和折扣分配
淘宝早期，商品只有一个价格，也就是售价，对于商家和用户来说已经足够简单，所见即所得。但这种平衡很快被一个功能打破——购物车。购物车的推出标志着淘宝进入营销时代。后来大家熟知的满减、满折、满赠、M元、N件等促销游戏，都是靠购物车。那么订单折扣是怎么计算的呢？
1)累进阈值计算
现在有促销，有促销就有折扣。你是如何计算这些折扣的？让我们记住【累进阈值计算】这个词，这个词让很多用户疯狂。
问题:买A、B两个商品，单品优惠价100元；b单品优惠价200元，其中店铺促销满300减50，店铺优惠券满280减40；同时还参与跨店满减，满290减50。问:在累进门槛计算规则下，手价是多少？
累进折扣计算的核心规则是根据上一级折扣扣除的金额，判断是否达到下一级的折扣门槛。所以在【累进门槛计算】时期，经常会出现用户看到某个商品参加各种活动，领取各种优惠券，只能使用一种优惠，骂商家和平台虚假营销的情况。
2)并行阈值计算
前面说过，购物体验是平台型电商的核心竞争力。在此背景下，淘宝和JD.COM在18、19年先后用“并行门槛计算”取代了“累进门槛计算”。
采用平行门槛计算规则后，折扣计算清晰明了。在过去，我们不得不与各级折扣的触发阈值作斗争。现在我们只需要盯着各种折扣中门槛最高的那一个，如图:
但这里面有个很大的漏洞，就是平台切换优惠计算规则时产生的促销活动和优惠券怎么办？如果不处理，商家会失血过多，如图。
3.订单状态的定义
我们常见的订单状态有:待支付-待发货-已发货-已完成-已评估(已评估状态有时不作为主状态存在)。
关闭，异常
作为一个电商从业者，你需要经常和订单打交道。大家可以自由说订单状态包含什么，连会网购的阿姨都能说123。订单状态是一个非常成熟的系统。对于缺乏电商经验的产品，可以在定义订单状态时直接复制这一套，大概率不会出错。
但在这里我还是要谈谈对订单状态的思考:
首先说一下地位。这个词产品经理一定很熟悉。日常工作中会用到各种文档和逻辑判断。是什么状态？我的理解是，事物处于一个稳定的状态，没有外力的影响，会一直处于一个稳定的状态。这种稳定的状态可以称为一种状态。
另一方面，在外力的作用下可以改变状态。这里推导出产品设计中的一个规律，就是“动一个状态”，即两个状态之间任何数量级的操作都可以抽象为一个动作。移动状态的好处主要体现在:降低用户的认知成本；便于制定和处理各种状态值。
回到订单状态，如图，用户下单后的一系列操作实际上是由三维状态(支付状态、物流状态、评价状态)组成的，但多维状态的存在容易导致认知混乱。为了解决这个问题，我们倾向于创建一个全局维度状态——订单状态。
总之，我们在创建全局维度状态时需要解决的是降低用户(商家和消费者)的认知成本，知道在哪些步骤中需要进行哪些操作，所以我们总结了订单状态转移时上述相关操作的执行角色:
消费者：支付、签收、评价商家：发货物流公司：揽件、走件、派件我们会发现，消费者和商家需要做的事情只有:付款、发货、收货、评价。我们在定义运动规律的时候说过:任何数量级的运算都可以抽象为一个运算。为了降低用户(商家和消费者)的认知成本，我们可以把【发货、集货、派送、调度】的过程抽象成一个操作——发货。这样就清楚了。
4.订单编号的设计
订单号的设计是一门艺术，能够参与订单号规则的设计是令人兴奋的。这种机会通常只有在电商项目从0到1的时候才有。那么订单号的设计应该遵循哪些原则呢？
1)独特性
作为订单表的主键，订单号需要是唯一的。
2)易读性
这里的可读性主要体现在系统易读性和通信易读性。
要求顺序号不能太长，尽可能是纯数字，不能混有字母、符号和数字。否则，对于系统存储、查询性能和与用户的通信成本都将是一个负担。
3)安全性
特殊情况下，尽量不要将平台运营特征信息，如订单数量带入订单号，以免泄露运营数据。除非你故意想让竞争对手知道你的运营数据。
早前在Luckin coffee，门店的订单量是一个一个增加的，然后增加了一个随机因素，就是外界担心通过订单号获取门店的日营业额。
订单号的设计需要考虑扩展性，比如随着平台业务的发展，订单数量剧增，订单号不够用。
5)语义学
在订单编号规则中加入语义特征信息，可以在一定程度上提高平台人员处理订单的效率和便捷性。
常见的特征信息包括:订单生成时间(年、月、日)、下单渠道、支付渠道、业务类型等。但订单号中不宜携带过多的特征信息，否则不法分子会通过描述订单信息来欺骗用户。
说到语义，细心的同学会发现，他们淘宝订单号的后六位是一样的。订单号的最后六位实际上是用户id的最后六位。那么淘宝订单号使用的用户id后6位是否代表语义呢？答案是否定的，因为只有id的后6位不能准确定位一个用户。
那么淘宝订单号后面的用户id最后六位是什么用途呢？
我搜了百度和知乎，都找不到答案。
一个偶然的机会，我翻到一张淘宝技术进化的PPT，看到订单清单库的逻辑，恍然大悟。
一般平台型的电商，订单量都比较大。为了保证查询和检索速度，他们会在子库中存储海量的订单信息。一般来说，订单系统还维护订单号和用户id之间的关联关系。首先根据订单号找到userid，然后根据userid确定子表得到内容。淘宝在订单号上下功夫，通过订单号的后6位直接锁库表，大大提高了高并发下的系统查询性能。
从这个策略中也可以看出，淘宝用户订单数据库是按照用户id的后6位存储的。例如，XXXX452154格式的用户订单存储在子数据库中。
本文由@ Atie原创发布。每个人都是产品经理。未经许可，禁止复制。
来自Unsplash的图像，基于CC0协议。
总结:以上内容对等待收藏意味着什么？，电商订单是如何生成的详细介绍。文章内容部分转载自网络，希望对你理解等待收藏是什么意思有帮助和参考价值。
版权声明
本站搜集来源于网络，如侵犯到任何版权问题，请立即告知本站，本站将及时予与删除并致以最深的歉意。
