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

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

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

互联网时代网上购物已经成为大家生活的一部分。当我们打开购物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协议。