一篇文章搞懂一个系统之电商系统

不可分类者 2024-08-27 12:14:48

电商系统应该是近20年最有代表性的软件系统，基于互联的普及使得电商系统对现如今各个领域的交易形式都产生的巨大的影响，也因为电商系统的出现让各个领域的交易模式的创新层出不穷，也让以“客户为中心”这句口号最大限度的各类企业中成为现实，这篇文章我们就整体来聊聊电商系统。

01 电商系统的相关概念

从百度上我们找了下对电子商务系统的定义，如下：

电子商务系统，广义上讲是商务活动中各参与方和支持企业进行交易活动的电子技术手段的集合。狭义上讲，电子商务系统则是指企业、消费者、银行、政府等在Internet和其他网络的基础上，以实现企业电子商务活动的目标，满足企业生产、销售、服务等生产和管理的需要，支持企业的对外业务协作，从运作、管理和决策等层次全面提高企业信息化水平，为企业提供具备商业智能的计算机网络系统。

在MBA智库中对电子商务系统的定义如下：

电子商务(Electronic Commerce)是指利用计算机技术、网络技术和远程通信技术,实现整个商务(买卖)过程中的电子化、数字化和网络化。

电子商务系统是保证以电子商务为基础的网上交易实现的体系。

上面的定义我们知道电商系统就是让你人们在网络上进行交易的软件系统，在我们对交易进行描述时一般会从人、货、场和四流（信息流、物流、资金流、发票流）这几个角度出发，现有比较流行的电商模式也是这几个要素之间的不同组合而形成的。

C2C模式，即Consumer to Consumer，是电子商务中的一种模式，主要涉及个人之间的交易活动。个人直接通过平台销售自己的商品或服务，另一个消费者可以在平台购买商品或服务。典型的平台是早期的淘宝、咸鱼等。
B2C模式，即”Business to Consumer”，直译为”企业对消费者”，是一种电子商务模式，其中企业（Business）直接向消费者（Consumer）销售产品或服务。这种模式是现代电子商务中最常见和直接的一种形式，它允许消费者通过互联网直接从企业购买商品或服务。典型平台是淘宝、天猫、京东等
B2B模式，即”Business to Business”，直译为”企业对企业”，指的是一种商业模式，其中企业（Business）向其他企业（Business）销售产品、服务或技术。这种模式主要针对企业间的交易，而不是面向最终消费者。典型平台是1688、震坤行、欧冶云商、找钢网等
BBC模式，即Business to Business to Consumer：这种模式下，一个企业（B1）生产产品，然后通过另一个企业（B2）分销给最终消费者（C）。B1通常专注于产品的制造和创新，而B2则负责销售和市场推广，将产品提供给C。这种模式较为传统，常见于制造商通过分销商或批发商销售产品的情况。
S2B2C模式，即Supply Chain Platform to Business to Consumer：这种模式中，S代表供应链平台或服务提供商，它为B（企业或商家）提供必要的支持和服务，如物流、支付、数据等，帮助B更好地服务于C（消费者）。S2B2C模式强调的是供应链平台的作用，它通过整合资源和服务，帮助B端企业提升效率和服务质量，从而更好地满足C端消费者的需求。S2B2C模式是近年来随着电子商务和供应链管理技术发展而兴起的一种模式，特别适用于那些需要强大供应链支持的行业，如跨境电商、新零售等。
即时零售是通过线上即时下单，线下即时履约，依托本地零售供给，满足本地即时需求的零售业态。即时零售填补了线上线下融合的“真空地带”。“本地化”是即时零售的显著特征，实现交易流程线上化，履约配送便利化，提升本地供给能力，拓展消费者需求。

02 电商系统的一般架构

上面说到交易主要由人、货、场和四流组成，而电商系统就是这些要素以及他们之间的关系在网络空间的映射，人主要包括：买家、卖家、配套服务提供商（物流、资金或其他服务商）、平台建设和运营方等；货主要指的是商品，但需要站在整个生产、供应链、营销等全环节，线上、线下全渠道去进行考虑，当然既包括实物商品也包括虚拟商品（服务）；场主要指的是发生交易的场所以及促成交易的相关因素，在电商系统里面包括店铺、展示商品的相关页面以及各种各样的营销活动。

一篇文章搞懂一个系统之电商系统

2.1 作为平台建设和运营角度

我们站在平台建设和运营方的角度看整个电商系统的架构，具体如下图：

一篇文章搞懂一个系统之电商系统

面向买家（2C、2B）的商城，主要包括客户选品、下单、支付、签收、售后等业务所需的功能操作

如果是平台模式则还需要提供面向卖家的管理后台，主要包括商家进行商品管理、库存管理、订单管理、财务管理等所需的功能操作，如果平台相对成熟，且卖家有一定的研发能力，还需要提供开放平台，让商家能够通过系统对接的方式直接集成其内部的管理系统，实现高效的业务运营

面向平台运营方的后台管理系统，主要包括对商城上的页面装饰、内容运营、流量分发、商家及店配管理、规则配置等业务所需的功能操作

以上如果是自营商城则会把卖家的管理后台和平台运营的管理后台统一成一个管理后台。具体架构图如下：

一篇文章搞懂一个系统之电商系统

在平台发展到一定规模后会衍生出来客户服务平台、广告投放平台、物流集成平台、仓储管理平台、支付平台等。

2.2 作为商家角度

而如果是作为商家的角度来看，如果是小微商家则基本使用平台提供的系统功能即可开展业务，一般无需额外建设相关系统功能。

如果是中型商家，一般可能会拓展多个渠道，且内部协同处理业务场景角度，会涉及到到运营、客服、仓储、物流、财务等相关人员和配合合作，此时企业需要考虑建设或采购电商ERP来与各个平台渠道进行集成完成业务处理，当然也有些企业可以直接使用OMS系统进行履约管理，而对于客服、仓储物流、财务等业务的支撑较弱。

对于大型企业或对于数字化要求较高的中型企业则可以建设完善的软件系统，包括全渠道管理系统、WMS、CRM、ERP等相关系统，把全业务流程均管理起来，提升整体的业务效率以及对用户需求的感知能力。当前还有一些企业本身就是研产供销服一体化企业，则其内部系统则更为复杂

03关键功能设计

电商平台的整体业务流程如下：

买家视角的流程：选品、加购、下单、支付、收货、开票、售后
卖家视角的流程：开店、上架商品、营销、接单、发货、开票、结算、处理售后；如果站在卖家内部整体业务的角度来看的话，还包括品类规划、供应商管理、采购、库存管理、物流发货、财务管理等相关业务
平台运营方的流程：基础维护、招商、引流、会员管理、活动运营、结算、售后管理

在这其中商品、订单、支付这几个模块的设计相对关键，会串联买家、卖家、平台运营方，下面分块进行总体介绍。

3.1 商品管理设计

商品管理是电商系统中的关键基础信息，而对商品的理解不同的环节、角色甚至于不同的人都会有差异，一个手机是一件商品，一个iPhone手机也是一件商品，一个iPhone 16 pro 也是一件商品，那具体怎么样描述商品、管理商品才是最合适的呢？这里没有标准答案，但基于现有的主流的电商平台来说主要还是以下结构是比较主流的：品类品种、品牌、SPU、SKU、商品属性。

1）品类和品种：类，是指大类，大的功能、特性、利益定位，国家标准分为45个大类。各企业也可以基于自己的业务规划进行品类的划分。

品种是分类下的产品组合细分，品种和品类的意思基本一致，稍有差别的是品类强调大类，品种强调小类。例如日用品是品类，下面的品种可以是洗发水、沐浴液等。再例如粮食、蔬菜、瓜果是品类，单说蔬菜，也有很多品种。对于不同的业务环节对分类的要求会有差异，所以我们一般会在电商平台设计前后台两套类目，前台类目较为灵活，以满足运营需求为主，能够让流量顺畅的流转到对应的商品详情中形成转化。

2）SPU指一个商品集合，在一个品种下面的商品的集合，一般来说一个SPU就是人们认知一种商品的基本元素的组成，例如：iPhone 16 PRO，联想ThinkPad L13，优衣库圆领印花T恤。

3）SKU即Stock Keeping Unit（库存量单位）。即库存进出计量的基本单元，可以是以件，盒，托盘等为单位。是用来定价和管理库存的，不同的颜色、尺码、容量等影响销售的属性组合而成的最小商品单位，能够贯穿整个销售、供应链以及统计分析的唯一标识。例如：iPhone 16 PRO 有不同的颜色不同的容量不同的通讯方式，这几种属性的组合就是具体的一个SKU，iPhone16 Pro 白色 256G 全网通。再比如：优衣库圆领印花T恤有不同的颜色、尺码，圆领印花T恤黑色 L码。一个SKU才是能够准确描述一件商品的，能够准确的表述用户选择的商品也是能够指导供应链准确把货物发送给客户。

在上面这些基础概念之下，组合商品也是很多电商平台需要考虑的场景，组合商品这个概念可以包括两种场景：

一是商品的搭售，只是在两个商品之间建立关系，买A的时候会提醒客户还可以买B，对商详、价格、库存等内容没特殊要求；

二是套餐商品，需要把A和B组合到一起形成一个新的商品，这种场景下对整个商品体系都是有挑战的，套餐商品在细分下去还要看套餐是有独立的包装在仓库就统一进行管理，还是只是组合关系只是下单、发货时需要按套餐要求进行处理

另外就是套餐商品的价格问题，因为是一个新商品肯定是需要进行单独定价，但套餐商品里面的子商品本身也是有价格的也有可能去进行毛利分析的，还有就是库存的问题套餐商品是单独设置库存还是根据子商品的库存情况去进行控制也是需要关注的。

在考虑套餐商品时还需要考虑特殊场景就是AB商品是可能存在不同的套餐中，那此时我们需要在原有的SPU+SKU的体系下在增加存货的概念，才能较好的解决这类问题。

不管商品管理中有多少个概念，我们需要能够有一个统一且唯一的标识去贯穿整个供应链和营销环节，要保障供应链和营销环节能够用统一的标识去识别商品，客户选购的商品和我们发出的商品也要是一致的，这些都是最基本的保障。商品管理总体来说可分为这么几个阶段“引进来、管理好、卖出去”，我们设计的系统也要能够支撑业务完成在这几个阶段的任务。

3.2. 订单管理设计

商城中与订单管理相关的业务是从加入购物车环节开始，到发货截至，当然也包括售后相关的业务流程。交易也是电商中最为核心的环节，需要把会员、商品、营销、支付等不同的业务进行整合，让用户完成下单，站在一个完整的交易模型的角度来看（见上述“交易模型”）订单中需要记录清晰交易双方信息、交易商品信息、物流服务信息以及资金支付信息等内容，订单管理要能够很好的衔接上下游。

用户浏览商品后可以加入购物车，从购物车开始进入了交易流程，在购物车中我们需要考虑根据营销相关的因素去计算价格，通过优惠和时效引导客户尽快进行成交转化。

功能层面还需要考虑购物车中商品的状态，是否有库存、是否已下架等。在从购物车进入结算环境时，我们还需要考虑某一些特殊的校验，包括：不同店铺不能合并下单、限购校验、用户资质校验等，不同的电商平台会稍有差异。

在有些电商平台为了缩减交易流程或者是业务模式特性的考虑没有提供购物车的功能，例如拼多多；也有部分电商平台则是按店铺+用户的组合维度去进行购物车设计，例如美团。

订单的设计从订单确认页说起，订单确认页是用户对交易信息做最后确认的步骤，交易中所有的要素都需要在这个步骤中进行确认，确认完即生成交易凭证——订单。所以在订单确认页中有一个非常之关键的业务处理逻辑，就是成交价格的计算，计算的结果决定了最终这笔交易需要支付的金额（包括各类资产的扣除）。

在计算价格时需要以商品的基础价格为准，综合考虑营销活动、优惠券、会员身份、增值服务（运费、保险等）等因素，按一定的逻辑去进行计算，在这其中我们常说的分摊逻辑是其中重要的一个环节，在进行分摊设计时我们需要考虑不同的优惠、费用之间是否有计算先后顺序的关系，互相之间是否有互斥的关系，是订单中部分商品需要计算还是整单需要计算等。

而在设计订单时从资金的角度看我们需要依次从订单、订单明细以及单品三个维度进行设计（如涉及到套餐商品，还需要在明细维度增加类型以进行区分），对应的字段名称一般为合计金额、小计金额、单价，也需要区分含税、未税（这部分在B2B模式和内部管理时尤其重要）等不同情况。

以上是订单管理模块提供的计价服务在订单确认页的实现，而在订单确认页中用户提交订单后则是真正生产订单，而在生成的过程中我们需要做许多的检验、业务逻辑处理，整个订单提交过程涉及的逻辑大体如下图所示

一篇文章搞懂一个系统之电商系统

在生成订单时我们需要能够全面的考虑订单所需要记录的信息，这其中我们还是需要以上述交易模型为基础去进行考虑，订单中需要准确记录买卖双方的信息（如果涉及到第三方也需要记录）、标的物信息也就是商品信息（包括商品基本信息、价格、优化信息等）、交付信息（收货信息、自提信息等）、资金信息以及其它辅助完成交易的信息

当然订单作为电商系统中最重要的实体，订单的状态也是一个非常重要的信息，需要能够准确的表达订单的什么周期，一般在设计状态时既要兼顾用户使用能够易于理解，也要考虑逻辑的完善性不能出现状态表达不了的情况出现

在设计状态时我们要遵循操作（可以是人工出发，也可以是自动触发）驱动状态流转的逻辑，操作和状态应该是有严格的对应关系，在设计时我们可以使用“状态机+状态操作对应表”方法去进行梳理，如下实例：

一篇文章搞懂一个系统之电商系统

订单生成时还有一个需要重点关注的逻辑，就是拆单逻辑，由于订单本身是一个比较宽泛的概念，不同的企业对拆单的逻辑也有不同，像淘宝、天猫更多的是以店铺或者是商品属性进行拆单，而像京东则是除店铺拆单会把履约环节的拆单也整合到下单的逻辑中进行拆分，订单为什么需要拆单，主要就是为了让后续环节履约和结算能够更加清晰、便捷，跨店下单时我们需要记录清楚每个店结算多少金额，不同属性的商品由于发货地不一样或者是物流履约的方式存在差异所以需要拆单进行处理。

拆单是为了让管理方面更加便捷，但是如果不进行特殊处理用户侧的体验则会大大降低，用户下单可能不会立即支付，在我们进行拆单处理后用户将会在列表中看到多个订单，那会对用户支付造成困惑，同时由于一些优惠活动存在门槛，如果不能整单一起支付也会存在优惠异常的情况发生。

为了避免上面的情况出现，有些同学会选择在支付后再进行拆单，这是否是一个好的解决方案呢？

我想并不是，我们在用户的角度看确实应该如此，在支付后进行拆单，但是如果我们站在卖家的角度看这种方案就非常不可行，整单中的商品可能是属于不同的卖家的，不进行拆单的话那么我们在支付前这一段时间则无法给卖家提供订单信息，这也是我们要解决的问题。

以上是订单拆单中所需要注意的点，具体怎么设计功能则需要根据实际情况而定。

3.3 支付管理设计

对订单进行了整体的介绍后，我们再聊聊支付相关的内容。在大多数的电商系统中支付管理其实并不复杂，只需要市场上常见的几种支付（微信、支付宝）即可，而且也是直接使用支付平台的能力调起接口完成支付并在订单和支付流水中能够准确记录相关信息。

但对于平台型电商系统、大型的自营电商系统给你以及SaaS类电商系统来说则不一样，虽然不需要一个完整的支付系统，但是这些类型的电商系统关于支付管理至少也要涉及如下的模块：收银台、支付渠道管理、支付路由管理、商户管理（平台型和SaaS类）、清账以及对账管理。

在设计收银台时我们需要考虑以下几类支付方式：优惠券（有些不认为是支付方式）、积分、礼品卡、信用、现金（微信、支付宝、网银或其它）。

对于优惠券、积分和礼品卡，大多数的电商系统都会在进收银台之前处理掉，但需要注意的是进收银台之前处理这些资产的话，需要考虑订单未支付取消时要进行返还，并需要对这部分的资产要进行冻结处理，以防被重复使用。

对于信用支付部分相对来说比较特殊，需要有一个账期费用需要展示，对于用第三方的信用支付我们只需要通过接口进行集成即可，但如果是在B2B电商平台中有可能是电商平台把原本在线下的账期模式沿用到线上（关于B2B电商平台支付相关的内容给可见这篇文章《B2B电商平台支付及金融模块设计》），那对大部分的平台来说是需要把这部分的利息直接算如商品价格，这种处理也许从业务逻辑上看并不十分合理，但从业务实操层面来看确实最能被买卖双方接受的，此时我们可能也需要在进收银台之前去进行信用支付的处理。

最后就是对于你现金类的支付来说可以统一在收银台中进行处理，用户可以选择平台提供的不同的支付渠道进行支付，再由平台去调起三方支付平台的页面完成支付。当然现在很多平台中也逐渐打破了订单确认页和收银台页面的界限，把两个页面进行融合。

收银台是支付管理直接呈现给用户的功能，在这之前平台运营方和卖家还需要做很多准备工作，包括接入不同的支付渠道，现如今很多三方支付公司都提供了聚合支付的能力，银行和大的首单机构也直接提供支付能力，许多平台都是回去对接多个支付渠道，这里没有业务层面的考虑也有系统稳定方面的考虑。

对于不同的支付渠道我们需要能够在平台上进行管理，并能够对各个渠道的支付方式、费用、支付并发数等基础参数进行管理，方便在支付路由中进行使用，以选择最优的支付方式为用户提供服务。

商户管理主要是给系统上卖家直接申请开通商户号的，像支付宝、微信等都是能够提供平台级的支付能力的，电商平台的运营方在支付平台中开通平台商户号，并进行相关功能的对接后平台中的商家可以直接在商家管理系统中直接申请支付商户号，支付平台审批通过后就可以创电商平台商户号下的子商户号，当然如果支付平台不提供直接通过系统给你对接的方式申请子商户号，也是可以手工进行维护的。

为什么需要这种主子结构的账户体系呢？主要是从平台运营方和卖家收款两个方面进行综合考虑的。

电商平台需要能够对其上的卖家有一定的约束力，那自然是需要能够对交易的资金进行一定的管理，但国家法律法规又不允许电商平台运营方形成资金池，所以需要借用第三方支付平台。而卖家有需要能够把钱直接收到自己账户，不希望自己的资金完全的交由电商平台进行管理。商户的管理也是电商平台中比较重要的一个基础性的管理。

最后我们在说说清帐和对账，首先对于清帐主要处理的交易过程中涉及的资金和费用的计算和划分，那些是平台承担的，那些是商家承担的。

一般来说平台都会按商家成交的金额的一定比例收取交易费用，另外对于支付渠道收取的费用可能包含在交易费用中也可能单独签订协议进行约定。

其次平台经常也会组织大型的促销活动，通过优惠的方式吸引顾客，而这个优惠的费用则也是需要在促销活动开始之前平台与商家进行协商确定的，这些费用最终也是需要在清账时计算出来。另外像积分属于平台为提高用户忠诚而统一去进行管理、运营的，在交易过程中用户如果使用，则一般是由平台进行支付结算给商家的。

还有就是像礼品卡这一类的预付卡，如果是能够用于第三方店铺的则也是需要进行平台和商家之间的结算。当然在清账环节可能还有更多需要考虑的因素在这里就不一一列举了，总之我们在这个环节需要能够对一个周期内发生的所有的交易计算清楚各方能够获得的收入和承担的费用。

根据清账计算的结果，我们周期性的行程对账单由双方进行确认，这里面包括了平台和支付平台之间的对账，也包括了平台和商家之间的对账，对账还需要区分汇总级对账和明细级对账，完成对账后即可进行开票、付款等相关操作。