电商后台设计：基本功能架构

文章对电商系统的基本功能架构进行了梳理，主要包括：系统管理、账号管理、内容管理、用户管理、商品管理、商品搜索、运营管理、订单管理、售后管理、采购管理、供应商管理、商户管理等，希望通过此文能够加深你对电商后台设计的认识。

《电商后台设计》主要讲解电商后台功能模块设计以及内部逻辑，每个模块涵盖需求收集、功能设计、数据分析。所涉及的功能模块如下：系统管理、账号管理、内容管理、用户管理、商品管理、商品搜索、运营管理、订单管理、售后管理、采购管理、供应商管理、商户管理等。本系列文章主要适合从事互联网产品设计、技术研发以及产品运营人员学习。

互联网时代网上购物已经成为大家生活的一部分。当我们打开购物APP或者网站，可以看到种类繁多的商品、满屏闪动的促销活动。我们只需要轻轻松松点几个按钮，过几天就有快递送货上门，这种足不出户就能买遍全球商品，实在有点让人不能控制。比较遗憾的是，在这里我们不准备讨论购物的快感[^_^]，而是深入去了解每个按钮是如何为我们提供如此快捷的功能的。

在《电商后台设计》这一系列文章中，我将带领大家一点点揭开每个功能的设计原理。这里我们不过多的讨论需求分析、PRD撰写、UI设计、交互体验等，而是把重心放到每个功能的内部逻辑、数据分析上，让每位产品都能清晰的了解每个字段的设计意义。同时我也会将自己在开发中和功能设计相关的体会写出来。

在一个完整的电商系统中，通常会涉及三个参与方：用户、服务商、商户。其中服务商所使用的系统，在功能是最全面的，用户和商户所使用的系统，在功能只是服务商系统的一小部分，所以后期的功能设计我们更多的集中在服务商系统，用户系统和商户系统只是简单说明一下。

下面我列出了服务商系统通常会涉及到的功能模块，后期的文章将从0到1为大家讲解每个模块的设计过程以及其中的业务逻辑。我们先来看一下架构图：

（1）系统管理

系统管理包含：菜单管理、组织架构、权限设置、审核流设置、系统消息通知等。它是整个系统的最基本功能，后期的许多功能模块或多或少都会依赖这些功能。

（2）账号管理

账号管理包含：职员管理、账号管理。主要用来管理系统职员登录账号信息。通常来说，职员管理会放在OA系统里面的人事管理模块中，但是我们这里不涉及OA系统，所以在这里我们做一个简单的职员管理模块，录入职员的基本信息就可以了。

（3）用户管理

用户管理包含: 账号管理、数据统计。主要用户来管理用户的基本信息，账号是否违规等操作、以及对用户数据做一些数据分析。

（4）商品管理

商品管理包含：商品维护、品牌管理、品类管理、商品属性维护等。这些功能主要维护商品的基本信息，以及日常上架、下架等数据。

（5）搜索管理

搜索管理包含：纠错词、敏感词、搜索跳转、搜索词统计、权重设计等。它主要负责电商的搜索入口和统计关键字流量信息。

（6）运营管理

运营管理包含：日常活动运营、商品活动运营、动态页面构建。不论是日常活动还是商品活动都包含数十种玩法，除此动态页面构建工具通过自定组件方式，为运营人员提供更加丰富和多样化的页面组合方式 对电商来讲无疑是最重要的功能模块。

（7）订单管理

订单管理包含：订单信息、订单分析。订单模块的意义不言而喻，它是衡量整个业务收入的指标，同时在整个电商系统中也起到一个非常关键的桥梁作用，它将整个系统中各个独立的模块关联了起来，形成了一个完整的业务线。

（8）售后管理

售后管理包含：工单管理、业绩考核等。主要用来处理客户订单反馈问题、订单赔偿申请，以及客服人员的KPI考核功能，同时也是企业与用户沟通的桥梁。

（9）商户管理

商户管理包含：商户基本、商户合同。主要用来管理商户的入驻、基本信息维护、以及返利内容的设置。

（10）财务管理

财务管理包含：订单核销、采购核销、经销商核销、渠道核销等。系统中凡是涉及到账款、现金、票据的功能，都需要经过财务核算。

（11）供应商管理

供应商管理包含: 供应商信息、合同管理。主要用来维护供应商基本信息，以及采购价格等信息。

（12）采购管理

采购管理包括：采购单管理、货运管理、入库单申请等。主要维护采购信息的申请、入库、退返等信息。

（13）仓库管理

仓库管理包括：仓库设置、入库、出库、盘点、调拨、拣货、复核等。主要维护了商品在仓库中的各个流转周期。由于整个仓储业务管理比较复杂，<<电商后台设计>>这一系列文章中我就不做说明了，后期我会再出<<仓储管理设计>>系列具体讲解。

（14）数据分析

数据分析报表通常都是企业的保密信息，所以通常都会将数据分析单独做个模块或者一个系统，只有有权限的才能访问。但是由于<<电商后台设计>>是按照模块设计，所以我就将数据分析和基本功能设计在一起，有需要的根据自己的需求，后期自己划分一下模块就行了。

本篇文章主要梳理了电商系统的基本架构情况，接下来我们将进入各个功能的设计。非常欢迎每位小伙伴的关注与交流。

本文由 @Jack 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。

电商系统：记账设计之订单管理、流水管理

本文所描述的记账，非企业ERP等专业财务软件记账场景。适用于公司自研以及采购的类电商系统后台记账设计。在电商场景下，涉及订单管理、交易流水、资金流水等多种不同口径的管理需求。

平台型电商记账特色

常见平台型电商如淘宝、拼多多、美团，京东、亚马逊也有一部分业务为平台型。所谓平台型电商就是搭建一个电子商城，引商家入驻。平台主要起着撮合交易的角色。常见模式如下图：

平台型电商的这种业务模式也决定了其必须要适应不同商户角色的不同需求。

运营关注订单流水（订单支付成功与否）店主关注交易流水（收入多少，支出多少）财务关注资金流水（实付金额、手续费等）

三者概念模型关系如下：

（三者都可以加上支付渠道属性）

订单流水

常见支付订单有如下几种状态：待支付、支付失败、支付成功、部分退款、已退款、已撤销。

待支付：下单成功，唤起支付后，尚未完成支付。支付失败：密码错误或者余额不足引起的渠道扣款失败。支付成功：扣款成功部分退款：发起退款，但没有退全款。已退款：退全款已撤销：传统POS系统中，指的是交易撤销，退全款；线上交易，指使预支付失效。 订单状态流转关系

业务含义：以客户与商户之间达成交易的状态为核心，表达交易是否完成。

生成条件：和业务订单发起支付同步生成。

案例A商户订单支付成功，无分账。B商户交易分账，分账接收方分别为C、D。E商户的订单已经退款。 交易流水

店铺的经营情况的主要指标。交易流水不关心卖了什么，只关注各个商户收了多少钱，退了多少款。交易流水不关注订单的状态和订单的交易时间，只关注交易的类型和时间。

交易流水类型为：

‘1’：支付‘2’：退款

（不计算费率因素）

业务含义：商户经营情况。

生成条件：以订单结算商户为核心，参考支付订单、分账订单、退款订单、撤销订单为触发条件。

案例

根据上述“订单流水”的例子，可生成如下交易流水信息。

B商户虽然有订单，但是因为其分账给C、D，所有其无交易流水。C、D商户参与B订单的分账，所有C、D商户各有一条交易流水。E商户的订单支付成功后，又退款成功，所以涉及两条交易流水。（如果是部分退款，就会关联多条退款流水） 资金流水

资金流水是我们财务意义上真正的“记账”。

资金流水要在交易流水的基础上考虑费率的因素。在每个结算周期结束时，根据资金流水来计算应结算金额。以目前支付行业相关规定，支付成功的订单在1年以内都可以操作退款。且渠道会退回手续费。我们以常见费率0.6% 为例，请看案例：

（注：应结算金额=收入-支出）

案例A商户加上费率因素，涉及两条资金流水；B商户无资金流水；C、D各涉及两条资金流水；E涉及4条，因为其订单在支付和退款两个状态切换时，各会涉及两条记录；

资金流水信息一般要同步到企业财务系统。在退款时一定要记录手续费的收入。因为支付渠道在操作退款时，会用之前所收取的手续费抵扣掉今天所产生的手续费。

总结

做电商系统后台时，切不可把订单流水、交易流水、资金流水混为一谈。否则会陷入无止境的数据核对和口径问题中。最好的办法就是三者解耦和，根据事件触发去保证三者的关系。三者各司其责，各有独自的业务含义和统计意义。

订单流水、交易流水、资金流水 此为作者本人习惯叫法，切勿去扣订单、交易、流水等词汇标准含义。因为支付行业是发展很快，词汇含义也同步演化。大家可以根据各自系统特点叫不同的名称均可。

本文由 @侠之大者 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。

电商ERP后台OMS模块设计

订单要做到集中处理需要用到OMS系统，本文主要讲了电商ERP后台OMS模块设计。

01

订单是电子商务体系当中最重要的一部分， 有了订单交易才能盈利 有业绩，企业才能持续发展，

订单中包含商品，优惠、用户、收货信息，支付信息等一系列订单实体实时数据。

通过订单中心，实现对线上订单、线下订单以及第三方订单的管理，支付订单接受、订单自动合并和拆分、自动匹配仓库、库存控制自动匹配快递、结算与支付等一系列订单协同作业。

订单生成后，随着订单的流转更新状态。不同业务类型的订单状态，例如：机票、服务订单、商品服务订单等和最常见的纯实物商品订单会有所区别。

以下讲解的主要是实物订单的状态流转：

待付款：用户刚提交订单，尚未付款，等待用户支付。由于待付款状态会锁定库存，一般 会设置库存超时后释放（例如唯品会的30分钟后倒计时库存释放）功能。待发货，用户付款后，等待商家发货。待收获。商家已发货，等待用户收货。交易成功，用户确认收货后，订单 已完成交易。已取消，付款之前取消的订单，超时未支付的订单或者用户主动取消的订单都会产生这种订单状态。售后中；用户在付款后发货前申请退款，或商家发货后用户申请退款退货，都会产生这种状态。订单售后状态又分许多种。交易关闭：当售后完成后的订单状态。“已取消”的订单状态可以合并到“交易关闭”中，

订单状态的正常流转是：

待付款；待发货 ；待收货；交易成功。

但订单会有逆向流程，和发生的时间节点以及类型相关，情况也很复杂多变。

02

订单的售后状态主要有以下几种：

待审核：用户提交退货，退款申请之后，等待审核的状态。在用户已支付待发货状态下，订单未推送至仓库或者在仓库拦截发货成功，系统可以审核通过，当审核不通过时，回到正常流程中，待退货入库：退货申请审核通过，等待用户退货入库。待退款，退货入库成功后，等待退款给用户。待换货入库，换货申请审核通过，等待用户换货入库。换货出库中； 换货入库后，生成换货出库单，订单出库，售后成功；当退货，退款成功或者换货成功后，流转至“售后成功：状态，退货，退款的售后成功在主流程序下属于交易关闭，

在售后流程中，如果多次售后，当换货成功后，在流程上还是允许客户有售后环节的， 产品设计中应该考虑允许用户多次发起售后，另外要设置申诉的周期，保证卖家的利益。

比如发货之后，15天确认 收货，交易成功，10天后售后通道关闭。

03

订单下单过程：

商品下单后流程：

在订单过程中进行安全校验，主要是检测用户是否在黑名单上， 用户购买的行为是否正常等，当检测到不正常时，终止下单。从商品中心获取商品信息（SKU、规格、价格等信息）从营销中心获取商品、订单促销信息（优惠券、促销活动、判断是否满足优惠条件，计算出优惠金额）。在会员中心获取会员权益，例如平台抵扣积分，折扣条件等。在调度中心校验销售层库存，按照规则锁定库存区域。根据拆单规则（商家，仓库，订单类型）将订单拆分为若干子订单。根据运费模板计算运费，根据商品金额，运费，优惠金额计算应付金额。生成订单，订单状态为待付款 。

在存储订单信息中，主要包含以下内容：用户信息、订单基础信息、收货信息、商品信息、优惠信息、支付信息、物流信息、其他信息等等。

订单内容复杂精细，在存储时，除了表结构的设置，还应该注意信息冗余 。特别是商品信息，由于商品的内容不断发生编辑变化，要保存下单快照，避免过长时间后，商品信息丢失。

04

订单包含的信息如下：

用户信息：用户帐号，用户等级。订单基础信息：父订单与子订单、订单编号、订单状态。收货信息：收货地址、收货人姓名、联系电话、邮编，商品信息：SKU信息、规格、商品数量、价格、商品图片、所属商家。优惠信息：优惠券、促销活动、虚拟币抵扣金额，支付信息：支付方式、支付单号、商品总金额、实付金额、运费、虚拟币抵扣金额，促销优惠金额、优惠卷优惠金额、总优惠金额。物流信息：物流公司、物流单号、物流状态。其他信息：发票信息、下单平台、分销渠道。 05

父订单和子订单：

如果从购物车选中多件商品时，例如选中三个商家的商品，会将这次购买行为拆分为三个订单，这次整体购买行为记录在父订单下。

当系统首次提交订单结算时，会合并自订单，针对父订单进行结算，当提交提交订单后 ，结算中断，或者结算之后，系统在更新订单状态，物流跟踪，针对的是子订单。

作者：谢先生，知名电商产品经理，微信：devin1922，微信公众号：衫莎石塔克

本文由 @谢先生 原创发布于人人都是产品经理，未经作者许可，禁止转载。