快捷搜索:
您的位置:bv1946伟德入口 > 互联网 > 从0到1设计思路,如何搭建电商订单系统

从0到1设计思路,如何搭建电商订单系统

2019-12-08 22:19

以一个通用B2C商城的订单系统为例,根据其实际业务场景,其订单流程可抽象为5大步骤:订单创建>订单支付>订单生产>订单确认>订单完成。

随着阿里、京东的崛起,中国电子商务的大门渐渐打开,越来越多的行业使用线上支付,无一例外地会用到电商系统,今天为大家介绍一下订单系统在垂直行业间的应用以及需要注意的细节。

Reference

1.图片来源:京东,淘宝,达观科技,2017.12

2.刘志远,《电商产品经理宝典 电商后台系统产品逻辑逻辑全解析》,电子工业出版社

3.电子商务网站中订单号设计有什么规则和依据吗?,知乎,詹仕波


浅忆

一个年轻的产品经理。立足微信生态圈,熟悉公众号平台、开放平台,探索小程序相关业务领域ing.....

文章同步更新于简书淺忆

转载联系,学习交流请加微信:Albert__luo(两个_)

电商前后台订单系统,虽然更多的是对订单信息和状态的展示,但这些订单信息和状态在后台各业务系统中如何有效流转,订单系统和其他系统如何高效合作,最终将信息完美呈现在前后台订单系统中,是非常重要和复杂的。

  • 一种是用户挑选的商品来自于不同渠道(自营与商家,商家与商家);
  • 另一种是在SKU层面上拆分订单:不同仓库,不同运输要求的SKU,包裹重量体积限制等因素需要将订单拆分。

1.订单系统的介绍

【订单拆单】

订单拆单有两种情况,第一种是用户提交订单后,在支付前进行拆单。这种是为了区分商家,方便系统进行财务结算。第二种拆单则是手动拆单,发生在用户下单后,商家发货前。这种则是因为订单里面包含了不同仓库或不同运输要求的sku,另外则是包裹重量体积限制了一个包裹装不完商品,必须拆开订单发货。

关于拆单的流程可以这么进行设计:

1、不同店铺、代发供应商的商品,拆开发货。

2、订单里面sku发货的仓库不同,拆开发货。

3、不能存放在一起的品类,拆开发货。

4、超过一定价值的商品,拆开发货。(减少意外造成损失)

优惠分摊比例;

订单修改:可梳理订单内信息,根据信息关联程度及业务诉求,设定订单的可修改范围是什么,比如:客户下单后,想修改收货人地址及电话。此时只需对相应数据进行更新即可。

3、某垂直电商设计思路

笔者的公司属于某个垂直行业的电商,主要以B2B转单为主,将线上的订单转给线下门店进行配送,所以暂时不涉及商品、库存、仓库等;

以下是我司的订单流程,线上商家将订单转给线下门店,涉及的状态有待派单、待支付、待接单、待配送、待转账和交易完成;

在设计主流程的时候并不复杂,根据业务场景进行设计即可,真正复杂的部分在订单的逆流程与系统间的交互;

由于旧版的系统过于臃肿,没有办法在其上进行迭代,加之流程上有很多问题,所以打算从业务流程、系统框架、视觉设计等方面做个大改版,即解决用户使用流程中的问题,也便于后期业务功能的实现;

图片 1

我司状态机

未完待续......

二、订单信息

订单信息

用户信息:用户账号、用户等级,在这里如果商家看到一个用户的等级比较高,有可能他会多送一些小礼品以回馈用户。

订单基础信息:父订单子订单、订单编号、订单状态。其中订单编号一般是一个10多位数字或是由英文与数字混合组成的一串字符,用于给订单编号,一般是后端自增的。而订单状态则是随着交易的过程,根据前后端操作而进行状态更新。在这里要注意的就是关于父订单与子订单了。举个例子:我在淘宝选择了多个店铺的商品,那么购买行为会把这些商品拆分成三个店铺的订单,而整体购买行为记录则在父订单下,结算的时候是针对父订单进行的,但是更新状态、物流追踪则是针对子订单。

收货信息:收货地址、收货人姓名、电话、邮编。一般而言,这里的收货信息就是电商运营人员在发货的时候和快递公司对接要填写的信息,有一点要注意的就是,收货地址在存储的时候,最好按省-市-区-详细地址进行存储,因为方便运营人员对区域订单进行分开发货,或者是在后台导出订单数据的时候,会要求进行地址拆分。

商品信息:sku信息、规格、商品数量、价格、图片、商家。在这里,一个订单最重要的便是写清楚sku到底是什么,也就是说订单需要告诉卖家和买家我到底买了一件什么样的商品,这样卖家才好发货,买家才知道自己有没有下错单。

优惠信息:优惠券、促销活动、虚拟币抵扣金额。当我的商品有优惠的时候,那么涉及的内容就很多了,比如结算的时候要减扣优惠金额,退款的时候,要涉及优惠金额无法退款,退款优惠优惠券是消失了还是直接给回原用户。

支付信息:支付方式、支付单号、总金额、实付、运费、虚拟币抵扣金额、促销优惠金额、优惠券优惠金额、总金额。做生意的一个前提就得要明算账,只有算清楚了金额,系统才能稳定的运行,不然财务可饶不了你。一般来说,小电商的支付方式只有一种,以微信生态里面的商城为例,支付方式也就只有微信支付一种,而像大型的电商淘宝,就有银联体系的,支付宝体系的等等。关于支付单号,如果你接的是第三方的支付,那么一般都是由第三方支付平台通过接口将支付单号返回给你,也就是这笔订单的结算、退款都会跟着这个支付单号走,在自己的电商后台能看到这个订单的支付单号,然后再去第三方的支付平台则可以找到这个支付单的全记录。

物流信息:物流公司、单号、状态。在这一方面,国内快递公司做得十分完善,基本数据都可以通过数据接口获取得到,像菜鸟物流,顺丰物流等等,只要你的产品接入了api,那么关于订单的物流信息基本能做到实时更新。

其他信息:发票信息、下单平台、分销渠道。这里其实算是一种附加字段,也就根据各个产品的需要进行设计的。

销售订单处理流程;

  1. 付款前再次校验库存,如确认订单要付款时再验证一次,并友好提示用户库存不足;
  2. 增加提示信息:在商品详情页,订单步骤页面提示不及时付款,不能保证有库存等。

今天分享将会分为以下三个环节来阐述:

四、订单数据统计

数据统计可分为常规统计,即财务统计等,一般统计销售额、毛利、成本、纯利润这些信息。流量分析,用户行为、订单流量等。

如果你觉得比较宽泛的话,我们可以从三个维度进行订单数据的分析

前后端订单系统,以及订单业务流程中,各业务系统之间的紧密交互。

(2)逆向流程

3.垂直电商订单系统设计思路

三、跨境电商

跨境电商三单对碰

关于跨境电商领域,接触得不太多,但是跨境电商最大的不同就是它需要过关。也就是商品需要订单、支付单、运单与进口清单一致(报关)。也就是说这里的数据交互至少涉及了电商企业的订单、物流企业运单、支付平台的支付数据、清关公司的进口清单、跨境通关服务平台(电子口岸)给予各方的海关回执,最终其实所有的数据都是和海关总署进行交互。

跨境电商有两种:1、保税仓备货;2、海外直邮。它们的区别在于保税仓备货的是商品到港以后,检查完毕以后是囤放在保税区的,只有用户下单了才会清关进行国内的配送。海外直邮则是用户下单以后,商品是从海外的仓库发货到港以后再转关进行国内配送。

主要因素是退款;财务对账;核算成本。

  1. 订单系统在企业中的角色

二、订单系统解构

1.订单字段

图片 2

订单字段

订单的主要信息包括支付信息 、配送信息、状态信息、促销信息、商品信息、用户信息等;

支付信息:涉及支付的字段信息,主要包括支付方式、支付金额、订单金额、优惠金额等;

促销信息:涉及促销的字段信息,主要包括优惠方式、优惠面额、折扣等;

商品信息:涉及订单中的商品字段,主要包括商品名称、单价、数量、所属店铺等;

时间信息:涉及订单流转中各个时间戳的字段,包括下单时间、支付时间、发货时间、完成时间等

状态信息:涉及订单流转中状态变更的字段,主要包括订单状态、物流状态及退款状态等;

用户信息:涉及用户的信息,比如买家姓名、注册手机号、收件人等信息;

配送信息:涉及订单配送的基本信息,比如配送方式、物流单号等;

以上这些字段构成了订单所需要的大部分信息;

2.订单体系

图片 3

订单体系

可以从三个层面来了解电商的订单管理体系,分别是用户层、系统层和底层;

用户层

这个比较好理解,就是用户日常使用的功能和页面,主要有订单列表、订单详情和退款详情等C端用户购买时会使用到的页面,系统层和底层模块为其提供支持;

系统层

在订单管理体系中,和订单最息息相关的交互系统主要有支付系统、订单系统、仓储系统;

1.支付系统

主要作用就是为订单提供支付支持,方便用户使用各种支付方式进行支付,用户支付后会将支付信息给到订单系统;

2.订单系统

作为订单管理体系的核心,起着至关重要的作用,在订单系统中会生成订单,审核订单,取消订单,还涉及到复杂的订单金额计算以及移库操作;

仓储系统:主要用来管理库存以及发货,订单到达一定状态后给到仓储系统,用于管理对应订单的打包、分拣、

备货、出库等;

底层模块

主要包括商品、支付、用户、营销、订单和消息等模块,这些模块共同组成了对上层业务、系统的支持;

大公司一般会将底层框架模块化,比如商品,会构建对应的商品中心,代码、数据库等相对独立,由商品中心开接口和soa,其他模块需要使用商品中心相关功能的时候调取接口,这样做的好处是使各个模块底层相对独立,便于管理及改动;

3.状态机

图片 4

状态机

下面来说说状态机,一般电商平台用户直观能看到的状态有上图中列举的几个,包括待支付、待配送、待收货、交易完成、退款中;

O2O没有电商中庞大的仓储系统,自然比电商的流程简单些,我将从正流程分别从正流程和逆流程来介绍;

主流程

在电商中,无论是买家端还是卖家端,都会将交易主状态分为待付款、待发货、待确认收货、交易完成,但是买家端与买家端的展示逻辑稍有不同;

在买家端,买家关心的状态无非就那么几个,即待付款、待发货、待收货和待评价,所以淘宝并未像商家端那样将全部的状态一一罗列出,而是保留了买家最关心的状态,保持整个买家端的简洁性;

而买家端中,主要解决的是商家效率的问题,所以在订单列表中会将所有的状态(即待付款、待发货、已发货、退款中、需要评价、交易完成、交易关闭)的订单全部拉出,考虑到商家订单较多的情况,出于对服务器查询的考虑以及并发的考虑,增加了三个月内订单与三个月前订单的查询区分;

首先说说待付款状态,待付款状态主要是买家下单但是没有支付的情况,待付款状态下淘宝的商家也可以进行一系列操作如改价等,买家也可以申请代付、批量操作;

待发货,该状态下会展示所有已支付,待发货的订单,淘宝目前支持的发货方式主要有四种,在线下单、手填快递单号、无纸化物流以及无需物流,操作配送之后交易状态会变更为待确认收货,大型电商平台已经采用无纸化发货的形式进行发货,即使用中端叫单,成功后会展示在已发货(商家端)和待收货(买家端)中;

待确认收货,该状态出于物流阶段,一般会根据业务、活动等来设定自动确认收货的时间,一般电商默认值是在发货后的10天为自动确认收货时间,在双十一、双十二等节日,这个时间会延长到15天,另外海外购、天猫国际等海外购物的订单自动确认时间也会相对较长,为25天;

交易完成,该状态由系统或者用户触发,在订单确认收货后,订单状态变更为交易成功,此时系统会根据是否评价过判断是否将订单展示在买家端的待评价下来引导用户对商家进行评价反馈;

退款/退货流程

一般电商中订单的逆流程主要分为退款流程和退货流程,这里简单地介绍下,后续会有专题来讲述;

发货前的逆流程

发货前的状态一般有待支付和待发货两个,待支付的订单发起逆流程后无需商家确认,直接关闭订单;

而待发货的订单发起后需要走商家的审核,商家同意后订单变为交易关闭,触发退款;

发货后的逆流程

发货后的逆流程主要包括待确认收货和交易成功的逆流程;

大致分为需要仅退款和退货退款;

仅退款:未收到货或与卖家协商同意后的申请,卖家同意后无需物流;

退货退款:已收到货需要退换的情况,卖家同意后需要走物流;

Po上我司的退款流程作为后续专题的引子吧,敬请期待...

图片 5

引子

封面

【2017-12-15更新】昨天文章发出来以后,我们服务端的大神跟我说订单号没有这么简单的,我那样设计会暴露我们自己平台的业务量,订单流水的。所以我上网查了其他订单编号实现方案,现更正如下。

下单渠道1位 支付渠道1位 业务类型1位 时间信息4位 下单时间的Unix时间戳后8位(加上随机码随机后的数字) 用户user id后4位。然后你会说,这样算下来就订单号就19位了啊,一点都不精简啊,不好记不好念不好输的。但我说的上面的这些业务标记,你不一定要全部加上啊。

你看淘宝/天猫那么大的订单量,16位订单号就搞定了。细心的网友已经发现了,订单号的后4位是取自用户user id的后四位,前12位中有10位可能是由Unix时间戳加随机规则生成的。

当然了,也有按我的方案进行设计的,比如宅妈妈APP的订单号,4位纯自增的数字,极其精简。

参考:

搭建电商订单系统需要考虑几个模块,只有所有模块都考虑清晰了,才能保证订单系统的稳定性和可扩展性。

将两种方式带入到销售场景中,关联商品类型、促销类型、供需关系等,灵活使用,以充分发挥计算机系统的优势。

图片 6

4.1交易分析(订单层面)

(1)统计周期的订单销售额(周期可以自定义,如7天、15天、一个月、一年)

(2)订单量:统计周期内的订单量

(3)客单价:已支付订单平均金额

(4)下单用户与支付用户数

(5)支付新用户数和老用户数

(6)订单金额分布:指的是各个价位区间占的比例,比如100元以下,100-300,300-600,600-1000这些常见金额区间

(7)地域分布

  1. 拆单的处理细节点

流程是指从平台角度出发,将订单从创建到完成的整个流转过程进行抽象,从而行程了一套标准流程规则。而不同的产品类型或交易类型在系统中的流程会千差万别,因此为了方便对订单流程进行管理,会组建流程引擎模块。

一、什么是订单系统?

订单管理系统(OMS)是物流管理系统的一部分,通过对客户下达的订单进行管理及跟踪,动态掌握订单的进展和完成情况,提升物流过程中的作业效率,从而节省运作时间和作业成本,提高物流企业的市场竞争力。顾名思义,电商系统就是用户、平台、商户等对于订单的管控、跟踪的系统,衔接着商品中心、wms、促销系统、物流系统等,是电子商务的基础模块;

简单地说订单管理系统作为整个电商的核心,管理着所有的交易进出,可以说没有订单系统电商就无法流畅地运转;

一个好的订单管理系统需要有很好地扩展性和流畅性,在一个电商产品从0-1的过程,订单系统作为其基础模块需要提前考虑到各系统的扩展,订单系统如果在前期就能考虑到后面的扩展,相信对于电商的壮大会非常有帮助;

流畅性指的是整个交易链路需要很流畅,早期我司的订单系统做的非常庞大,但是却没有考虑到流程的通畅性,导致连基础的订单流程都没有办法正常走下去,所以,在从0到1地做一套订单系统时,需要有一些前瞻性,但落地时,以MVP去试错;

【异常流程】

如果订单处于待发货状态,用户申请取消订单。那么WMS就会拦截发货,系统会判断用户是退订单里面的部分sku还是全部sku,如果是全部sku就好办了,直接交易关闭,但是如果只是退部分sku,那么就会在原订单上生成部分商品的售后订单。

如果订单处于待收货或者交易成功的状态,用户不满意申请退货。这时候客服会审核给不给这个用户进行退货,审核通过以后,系统会返回用户退货的信息(往哪里寄回商品,有什么注意事项)。这里系统也需要判断用户是退部分sku还是全部sku。

订单系统在数据库设计层面至少需要存在以下几个表:订单表、订单明细表、售后订单表、售后订单明细表(也可以把售后订单和销售订单结合起来设计表结构),分别需要定义各个不同表的字段及其含义。

  1. 现态:是指当前所处的状态。
  2. 动作:动作执行完毕后,可以迁移到新的状态,也可以仍旧保持原状态。
  3. 次态:动作满足后要迁往的新状态,“次态”是相对于“现态”而言的,“次态”一旦被激活,就转变成新的“现态”了。

2.订单系统的解构

一、订单状态

在电商产品中,核心的模块便是商品模块和订单模块,而订单模块里面,最重点的就是根据你的产品,因地制宜的归纳出合理的订单状态,并且进行订单状态扭转设计。

订单状态有哪些

订单的状态基本可以归纳为:待付款、待发货、待收货、交易成功、售后中、交易关闭。而交易关闭其实是一个订单的终结,但是如果一个订单如果出现了异常,例如要退货售后什么的,那就必然会有一个异常流程:待审核、待退货入库、待退款、待换货入库、换货出库中、售后成功等等。值得注意的是,因为用户在前端下单会锁定商品的库存状态,所以在待付款状态时候,超时取消的机制很重要。

以12306购买火车票为例,选择了坐哪躺火车,就进入到确认支付的页面,而在右上角会有一个30分钟的时间限制,超过了就会自动取消该订单,释放座位,为的就是防止有用户长期占据这个位置不付款。

12306截图

至于关于订单状态的小细节,这里还有两个:第一个是订单允许多次进行售后,第二个则是发货7天后自动确认收货,交易成功15天售后通道关闭。

订单扭转过程

上图是我根据一般的用户下单流程制作的一个流程图,基本上电商的套路就是这个样子的。

生成订单;

为了使订单系统能够对订单进行高效、精准的管理和跟踪,订单会储存关于产品、优惠、用户、支付信息等一系列的订单实时数据,来和下游系统,如:促销、仓储、物流进行交互。

4.3订单来源分析

(1)每单来源,比如来自哪个用户端,如h5、小程序、客户端

(2)每单产生流程,用漏斗分析统计关键步骤的流失情况

客户同时在多家店铺下单,不同的店铺的商品在正常情况下是要拆开的,否则无法跟踪物流信息,无法分开收款和对账。

这里要注意的是订单类型,随着平台业务的不断发展,品类丰富、交易方式丰富后,需要对订单进行多维度的分类管理,同时订单类型利于订单系统的扩展性。每种订单类型将会对应一套流程及一套状态,便于对订单进行分类管理和复用。

4.2商品分析(从商品层面分析)

(1)被下单商品数

(2)被支付商品数

(3)被访问商品数

(4)被访问商品数

(5)商品的收藏数

(6)商品的销量统计

(7)加入购物车的次数

订单推送的触发依赖于状态机的改变,涉及到的信息包括:

因此未来的订单系统可拆分为订单中心与业务订单系统两个模块,以管理公司所有订单数据,并为各个模块提供统一服务。

需要根据电商平台的实际情况,确定拆单的维度,是根据不同的店铺进行拆单还是根据不同的包裹拆单,还是两者都需要。

解决办法:

图片 7

这种状况的出现,将会给平台带来非常大的发展瓶颈,如:

​ 电商系统最终的目的还是下单支付,所以对于如何搭建订单系统也成了重中之重,订单系统作为电商系统的“纽带”贯穿了整个电商系统的关键流程。其他模块都是围绕订单系统进行构建的。订单系统的强壮决定了平台的稳定性。

订单拆分一般分两种:

、商品优惠分摊

状态机是管理订单状态逻辑的工具。状态机可归纳为3个要素,即现态、动作、次态。

1、订单列表:

  1. 订单系统上下游关系
  1. 订单字段

(1)订单服务

前端订单系统主要包括2大块的展示:订单信息和订单状态。

订单支付:

按照最小粒度进行分摊;

增减库存规则是指订单中的商品,何时从仓储系统中对相应商品库存进行扣除,目前主流有两种方式:

、前端订单系统:

订单取消:用户提交订单后没有进行支付操作,此时用户原则上属于取消订单,因为还未付款,则比较简单,只需要将原本提交订单时扣减的库存补回,促销优惠中使用的优惠券,权益等视平台规则,进行相应补回。

订单价格体系;

图片 8

订单列表以序列形式显示所有用户的下单记录,列表中主要展示某笔订单的一些核心信息,比如订单编号、下单时间、下单用户、商品信息、实付金额、订单状态、维权状态等。

用户下单后,系统需要生成订单,此时需要先获取下单中涉及的商品信息,然后获取该商品所涉及到的优惠信息,如果商品不参与优惠信息,则无此环节。

  1. 为什么需要拆单?

图片 9

售后订单处理流程。

以一个B2C商城的订单系统举例如下:

  1. 为什么要对订单金额进行分摊?

业务系统架构如下:

订单状态超时。

(1)对外系统:

后台订单系统和前端订单系统展示的信息相对应,包括订单列表以及订单详情的展示。

(2)订单逻辑

拆单的价格。

订单创建:

其实呈现在界面上的订单信息,都是由各种订单字段组合而成。订单字段齐全从某个程度上代表着订单流程的完整。

退款:用户支付成功后,客户发出退款的诉求后,需商户进行退款审核,双方达成一致后,系统应以退款单的形式完成退款,关联原订单数据。因商品无变化,所以不许考虑与库存系统的交互,仅需考虑促销系统及支付系统交互即可。

  1. 订单流程
  • 优势:减少无效订单带来的资源损耗;
  • 缺点:因第三方支付返回结果存在时差,同一时间多个用户同时付款成功,会导致下单数目超过库存,商家库存不足容易引发断货和投诉,成本增加。

、销售订单处理流程

(3)状态机

误差处理。

本文由 @sleeping 原创发布于人人都是产品经理。未经许可,禁止转载返回搜狐,查看更多

推送对象;推送方式(站内消息、push、短信、微信);推送节点。

对于企业订单系统的搭建,并不是要做的大而全、也不是要小而精。而需要结合市场、公司、业务的实际情况来最终制定系统设计方案和产品迭代计划。

售后订单的状态及操作按钮设计的思路与销售订单基本一致,值得重点注意的是:售后流程的设计需要结合实际的需求去考虑。

(1)正向流程

支付后订单拆单处理;

图片 10

管理订单类型、订单状态,收集关于商品、优惠、用户、收货信息、支付信息等一系列的订单实时数据,进行库存更新、订单下发等一系列动作。订单系统业务的基本模型涉及用户、商品、订单、付款,订单基本流程是下订单——>减库存,这两步必须同时完成,不能下了订单不减库存,或者减了库存没有生成订单。超卖商家库存不足,消费者下了单买不到东西,体验不好;少卖商家库存积压或者需要反复修改商品信息,反复麻烦,体验也不好。

退货:用户支付成功后,客户发出退货的诉求后,需商户进行退款审核,双方达成一致后,需对库存系统进行补回,支付系统、促销系统以退款单形式完成退款。最后,在退款/退货流程中,需结合平台业务场景,考虑优惠分摊的逻辑,在发生退款/退货时,优惠该如何退回的处理规则和流程。

2.订单详情:

付款减库存——即用户支付完成并反馈给平台后再减少库存数量

小猪电商称,订单所涉及到的后台系统:包括订单系统、库存系统、仓库系统、物流系统、风控系统等。订单业务的流转主要依靠完善的后台系统。

图片 11

付款成功;

而每个步骤的背后,订单是如何在多系统之间交互流转的,可概括如下图:

该部分是贯穿整个订单流程中最核心的部分,订单相关信息在需要展示在不同操作系统,如:平台总后台、商家端、APP、PC端、小程序、公众号,需要结合数据库的结构一起设计。

  1. 流程引擎
  1. 订单推送

所有给企业外部用户使用的系统都在这一层,包括官网、普通用户使用的C端,还包括给商户使用的商家后台和在各个销售渠道进行分销的系统,比如与银行信用卡中心合作、微信合作在合作商的平台露出本企业的产品。这类系统站在与客户接触的最前线,是公司实现商业模式的桥头堡。

发货;

信息化建设达到一定程度的企业,一般会将公司公共服务模块化,比如:产品,会构建对应的产品系统,代码、数据库,接口等相对独立。但是,这也带来了一个问题,比如:订单创建的场景下需要获取的信息分散在各个系统。

、订单价格体系的设计

  • 优势:用户体验友好,系统逻辑简洁;
  • 缺点:会导致恶意下单或下单后却不买,使得真正有需求的用户无法购买,影响真实销量;

一个伟大的订单系统背后一定站着一大堆伟大的其他系统。订单系统的演变也是随着电商平台的业务变化而逐渐演变进化着,从起初的进销存软件,到订货、电商B2B系统,再到新批发系统。

图片 12

、售后订单处理流程

概述

分摊顺序;

  1. 设置订单有效时间,若订单创建成功N分钟不付款,则订单取消,库存回滚;
  2. 限购,用各种条件来限制买家的购买件数,比如一个账号、一个ip,只能买一件;
  3. 风控,从技术角度进行判断,屏蔽恶意账号,禁止恶意账号购买。

在设计好各个订单处理环节及订单状态之后,需要定义不同状态下的操作按钮,操作按钮包括:立即付款、申请售后、确认收货、查看物流,当然需要注意一点就是用户操作的界面与后台商家或平台处理订单的按钮是不一样的。

订单系统核心功能 1. 订单中所包含的内容信息

取消订单;

(3)底层服务

分别从以下几个方面讲解:

除此以外,随着电商平台的不断发展,不同的业务类型,所对应的订单状态都会有所区别。所以,订单系统中一般会储存多套状态机,以满足不同的订单类型来使用。

此外订单流程往往需要涉及电商系统与ERP对接的问题,这一块也比较复杂,后面单独再聊聊开放平台的设计经验。

状态机的设计需要结合平台实际业务场景,将状态间的切换细化成了执行了某个动作。

商品优惠分摊;

最终,和公司整体发展相互协调,相辅相成。

对于订单流程的设计,是电商系统设计中最基础的环节,不同业务场景的订单流程会有不同,最终核心离不开以下几个点:

该模块的主要功能是用户日常使用的服务和页面,主要有订单列表、订单详情、在线下单等,还包括为公共业务模块提供的多维度订单数据服务。

前后台订单系统相对于其他系统来说,在页面上的展示比较简单,但其背后的逻辑以及与其他业务系统的交互是非常复杂的,要保证一个商品从前端用户下单到最后送达用户手中,需要各系统的完美配合。

用户支付完订单后,需要获取订单的支付信息,包括支付流水号、支付时间等。支付完订单接着就是等商家发货,但在发货过程中,根据平台业务模式的不同,可能会涉及到订单的拆分。

申请售后;

由此可见,订单系统对上接收用户信息,将用户信息转化为产品订单,同时管理并跟踪订单信息和数据,承载了公司整个交易线的重要对客环节。对下则衔接产品系统、促销系统、仓储系统、会员系统、支付系统等,对整个电商平台起着承上启下的作用。

、后台订单系统:

图片 13

收货;

每套订单流程中会包含正向流程及逆向流程,正向流程可以比作一次顺利的网购体验过程中,后台系统之间的信息流转。逆向流程则是修改订单、取消订单、退款、退货等各种动作引起的后台系统流程,同时每个流程触发的条件又可分为系统触发和人工触发两种场景。

搭建电商订单系统时包含几个大的方向需要考虑,这些内容决定了订单系统的稳定性和可持续性。

订单系统的主体框架,和主要业务模块已基本讲完,那么随着企业的发展,业务量和业务形式不断变化,企业有可能形成多个订单系统并存以满足不同的业务需要的情况。

  1. 优惠金额分摊逻辑

订单开发目前分到事业部,各个事业部只会考虑自己的逻辑,不会考虑公共架构,只会越走越远。碰到像无线这样的项目,需要对接各个事业部,无线侧应用上线进展慢。

正向流程就是一个正常的网购步骤:订单生成–>支付订单–>卖家发货–>确认收货–>交易成功。而逆向流程则是各种退款流程。

综上所述,两种方式各有优缺点,因此,需结合实际场景进行考虑,如:秒杀、抢购、促销活动等,可使用下单减库存的方式。而对于产品库存量大,并发流量没有那么强的产品使用付款减库存的方式。

图片 14

订单拆分也是一个相对独立的模块,这里就不详细描述了。

电商订单系统的作用:

在搭建企业订单系统之前,需要先梳理企业整体业务系统之间的关系和订单系统上下游关系,只有划分清业务系统边界,才能确定订单系统的职责与功能,进而保证各系统之间高效简洁的工作。

、支付后订单拆单处理

三套后台订单系统与公共业务系统如会员中心、支付与财务、促销工具、客户分单等系统都需要对接一遍,公共业务处理逻辑不统一,一旦逻辑变更多个系统统一个接口都要修改一遍,接口的重复维护开发工作量大。

订单流程是指从订单产生到完成整个流转的过程,其中包括正向流程和逆向流程。

图片 15

拆单的节点;

责任编辑:

下面小猪电商电商介绍下,从0到1的角度上概述订单系统搭建时,需要重点处理的功能点。

(3)公共服务系统:

订单业务流转

以一个通用B2C商城的订单为例,梳理其包含的信息如下:

订单列表主要展示核心的订单信息,所以可从订单列表中点击某个订单查看它的详情,订单详情可分为三部分展示:订单信息、支付信息、物流信息。

下单减库存——即用户下单成功时减少库存数量

订单系统的核心,起着至关重要的作用,在订单系统负责管理订单创建、订单支付、订单生产、订单确认、订单完成、取消订单等订单流程。还涉及到复杂的订单状态规则、订单金额计算规则以及增减库存规则等。在4节核心功能设计中会重点来说。

(2)管理中后台:

业务系统架构如下:

三个订单系统,每个订单系统处理不同类型的订单,没有统一的订单销量、订单状态信息,网站前台对订单的状态展示与控制不统一,只能是在网站前台会员中心硬代码维护一套面向会员的统一订单明细与状态数据。而无线侧上线后,由于不了解前台网站会员中心的订单状态管理逻辑,所以需要把前台网站的订单明细及状态管理再在无线应用侧再实现一遍。

随着企业的发展,信息化建设到达一定程度后,企业需要将通用功能服务化、平台化,以保证应用架构的合理性,提升服务效率。这类系统主要给其他应用系统提供基础服务能力支持。

图片 16

图片 17

如果需要从各个公共服务系统调用:一是会花费大量时间,二是代码的维护成本非常高。因此,订单系统接入所需的公共服务模块接口,在订单系统即可完成对接公共系统的服务。

接着获取该账户的会员权益,这里要注意的是:优惠信息与会员权益的区别,比如:商品满减是优惠信息,SUPER会员全场9.8折指的是会员权益,一个是针对商品,另一个是针对账户。其次就是优惠活动的叠加规则和优先级规则等。

每个C端的业务形态都会有一个对应的系统模块,如负责管理平台交易的订单系统,管理优惠信息的促销系统,管理平台所有产品的产品系统,以及管理所有对外系统显示内容的内容系统等。

  1. 订单系统的业务架构

因此,订单状态模块中,通常会维护状态映射表,以不同的用户角色对系统订单状态进行重新划分,以满足不同用户的需求。

上面说到逆向流程是各种修改订单、取消订单、退款、退货等操作,需要梳理清楚这些流程与正向流程的关系,才能理清订单系统完整的订单流程。

对于订单系统来说,订单状态细分的颗粒度越细、越明确,订单系统管理的精度和可靠性就越高,比如:在待付款和待发货两个状态中,订单系统后台会细分为订单超时取消、订单支付失败、订单付款完成等。

图片 18

  1. 订单系统与各业务系统的关系

本文主要讲述了在传统电商企业中,订单系统应承载的角色,就订单系统所包含的主要功能模块梳理了设计思路,并对订单系统未来的发展做了一些思考。

订单确认:收到货后,订单系统需要在快递被签收后提醒用户对商品做评价。这里要注意,确认收到货不代表交易成功,相反是售后服务的开始。

订单系统的发展

文章主要跟大家分享在订单系统承载的角色,以及梳理了主要功能的设计思路,一起来文中看看~

订单系统为了高效的对订单进行跟踪和管理,会对订单流程当中的关键节点,抽象出订单状态。而订单状态从不同用户的角度可分为,系统订单状态、商家订单状态、买家订单状态等。

订单生产:订单生产,是指产品从企业到用户这一流程的概述。如电商平台中,商家发货过程已有一个标准化的流程,订单内容会发送到仓库,仓库对商品进行打单、拣货、包装、交接快递进行配送。

解决办法:

订单完成:订单完成是指在收到货X天的状态,此时订单不在售后的支持时间范围内。到此,一个订单的正向流程就算走完了。

原标题:订单系统:从0到1设计思路

最后

本文由bv1946伟德入口发布于互联网,转载请注明出处:从0到1设计思路,如何搭建电商订单系统

关键词: