电子商务

电子商务软件 — 一套系统，保存商品、价格和库存数据，通过互联网接收订单，完成支付，并把订单交给仓库、配送和财务去执行。

它与普通网站的区别在于：处理的不是页面，而是业务记录——商品、价格、库存、订单、支付、发货、退货，每一项都有自己的状态和历史。同一笔订单可能来自应用、售货机、业务员，也可能来自电商平台。

它是门店前台背后的业务记录层，而不是门店前台本身。更换前台或再加一个前台，都不必重写底层记录。

系统由哪些部分构成

• 前台 — 面向顾客的界面：网站、移动应用、售货机屏幕或自助终端
• 数据核心 — 商品、类目、属性、价格、库存、客户和订单
• 业务逻辑 — 定价、折扣、商品可售性、运费和税费的规则
• 流程层 — 订单状态、库存预留、支付操作、发货和退货
• 对接层 — 与 CRM、ERP、仓储、收银、支付和物流系统的数据交换
• 管理后台 — 内容运营、订单客服和类目运营的工作台
• 数据分析 — 覆盖销售、转化漏斗、库存和退货的数据视图

自动化不是「用机器人取代售货员」，而是把重复操作变成规则，由系统一致地执行，并把结果写进历史记录。

规则一直生效，直到条件被修改。控制并没有丢失：每一个自动动作在日志里都有操作者、时间和修改前的数值。

转为自动执行的操作：

• 商品上架与下架
• 按规则和加价率重算价格
• 促销按计划启动和结束
• 优惠码的校验与核销
• 为订单预留库存
• 订单状态流转
• 扣款与退款
• 计算运费
• 生成发货单据
• 把订单发给配送服务
• 在每个环节通知顾客
• 拒收后把商品退回库存
• 向 CRM 和 ERP 推送数据
• 收银台开具税务凭证
• 更新报表和数据看板
• 发送库存偏低告警

价格 — 它不是商品页上的一个字段，而是请求发生时按规则计算出的结果。同一件商品可以同时存在多个价格，系统会选出适用的那一个。

因此不必到上千个商品页里改价：改一条规则或基础价目表就够了。

定价的层次：

• 基础价 — 来自财务系统或手工录入
• 价目表 — 零售、批发、伙伴和区域价目表
• 加价规则 — 在采购成本上按百分比或固定金额加价，按类目或供应商设定
• 专属价格 — 按客户分层或按具体合同设定
• 阶梯价 — 价格随订单数量变化
• 币种与取整 — 按汇率折算，并取整到便于顾客理解的档位
• 税费 — 每个商品的税率，以及含税价与不含税价

每一次价格变动都写入历史：谁改的、何时改的、依据哪条规则、原值是多少。毛利报表和争议订单的复盘都依赖这段历史。

应用顺序

规则按优先级裁决，而不是盲目叠加。单个商品的价格通常按以下顺序计算：

• 确定该顾客适用的价目表
• 从该价目表取出商品的基础价
• 按数量套用阶梯价
• 叠加合同中的专属条件
• 套用优先级最高的促销
• 若优惠码与该促销兼容，则套用优惠码
• 累计并抵扣会员积分
• 计算税费和该商品的最终金额

兼容关系写得很明确：哪些折扣可以叠加、哪些互斥、允许的最低价是多少。最低价规则可以避免多个单独看都合规的折扣叠在一起，把商品卖成亏本。

购物车 — 订单的草稿：一组商品，对顾客和商家都还没有产生义务。其中的商品没有被预留，价格也没有锁定，因此每次打开购物车都会重新计算。

重新计算会检查四件事：商品仍在售、库存足够、价格没变、折扣仍有效。任何变化顾客都在付款前看到，而不是在扣款之后。

购物车必须做到：

• 跨设备保留 — 在浏览器里加好的购物车，登录后能在应用里打开
• 未注册也能用 — 访客可以直接下单，只有在结算时才需要登录
• 登录时合并 — 访客购物车与已保存的购物车合并，而不是覆盖它
• 遵守限制 — 最低订单金额、整箱起订倍数、单客户数量上限
• 分开显示不可购买的商品 — 已下架和已售罄的商品单独归为一组
• 把账算清楚 — 总额拆分为商品小计、折扣、运费和税费

订单 — 一份单据，锁定了购买内容、下单时的价格、顾客本人、配送和支付条件。此后订单在一组有限的状态中流转，每一次流转都会被记录。

价格和折扣在下单时锁定：之后的调价或促销结束都不会影响已生成的订单——否则应付金额就会和小票金额对不上。

下单结算的步骤：

• 购物车：重算价格，校验可售性和限制
• 识别顾客：登录、注册，或不注册直接下单
• 选择配送：地址、自提点、时间段、费用计算
• 选择支付方式并使用优惠码
• 为订单商品预留库存
• 生成订单及订单号，发送确认信息
• 完成支付，或确认为货到付款
• 转入执行：拣货、发货、配送

可售库存 — 此刻可以卖出的商品数量。它不等于仓库里的实物数量：一部分被订单预留，一部分在途，一部分作为残次品被锁定。

可售数量 = 实物库存 − 预留 − 锁定 + 已确认的在途到货（在允许预售的场景下）。

当有多个仓库和门店时，库存按每个仓库分别计算，前台展示的是能配送到所选地区的那些仓库的合计数。

数据交换的方式：

• 全量导出 — 按计划导出整份库存台账，通常在夜间
• 增量交换 — 只传上次同步之后的变化，每隔几分钟一次
• 事件推送 — 财务系统在变化发生的那一刻主动上报
• 消息队列 — 仓库系统或网站临时不可用时，数据不会丢失
• 冲突裁决 — 出现差异时以谁的数值为准，事先就已经定好

预留一定有有效期：未按时付款的订单会把商品释放回可售——否则弃购的购物车会把可售库存全部吃掉。

库存记录准确带来什么

• 顾客不会下单买到根本没有的商品
• 客服不必花时间打电话取消订单
• 不会因商家自身的库存错误而产生退款
• 采购能看到各商品真实的消耗速度
• 预售和到货提醒可以给出诚实的时间
• 库存周转报表基于可信数据

差异常见的来源

• 线下门店的销售没有及时进入数据交换
• 弃购购物车留下的、没有有效期的预留
• 退货实物已到，但入库记录晚了
• 在财务系统里手工调整，却没有重算预留
• 套装商品的组件扣减配置有误

仓库员工 — 实际搬运商品的员工：验收到货、放入货位、按订单取货、把打包好的箱子交给配送员。系统了解这些动作，靠的不是员工口述：每一步操作都由扫码确认。

这个区别很关键。在清单上打勾确认的是意图，扫码确认的是事实：具体的货号、具体的货位、具体的员工，精确到秒的时间。货号打错一个月后才在盘点时暴露；条码不对，应用当场就不接受。

仓库员工一个班次要做什么：

• 收货 — 按行逐项核对到货与送货单。缺货、错发和破损在收货当场记录并转为对供应商的索赔，而不是等到拣货时才发现
• 贴标 — 条码不可读的商品打印内部标签。没有标签的商品不予入库
• 上架 — 扫商品再扫货位，把两者绑定：系统由此记住每一件货放在哪里
• 拣货 — 应用按货位规划路线并逐点引导；每个货位扫一次码，确认取的是对的商品、对的数量
• 打包 — 箱内清单靠扫码生成：没扫过的，就没有装进箱子
• 发货 — 箱子扫码交给配送员，责任随这一次扫码一并转移
• 移库与补货 — 在货位之间、以及从存储区到拣货区搬运，让畅销品放得更近
• 盘点 — 按货位逐个盘，不停工：一个货位只在盘它的那段时间被锁定
• 扣款 — 破损、摔坏、过期：附原因、照片和责任人

个人中心 — 顾客无需找客服就能查看自己的数据：订单、单据、地址、支付方式、退货。个人中心解决的每一个问题，都是一通没有打进客服的电话。

个人中心并不另存一份数据：它展示的就是客服在管理后台看到的那些记录，只是限定为这位顾客的记录，以及他被允许执行的操作。

它包含：

• 订单历史 — 每笔订单的内容、金额、状态、单据和凭证
• 物流追踪 — 当前的履约环节和承运商的运单号
• 再来一单 — 把上次的订单内容放回购物车，并校验当前价格和库存
• 退款 — 按商品逐项提交申请，附原因，并可追踪处理进度
• 地址与收货人 — 已保存的收货地址、联系人、自提点
• 支付方式 — 已绑定的银行卡以令牌形式保存，不保存卡号
• 积分与等级 — 会员积分余额、过期时间、可用优惠
• 订阅与授权 — 通知渠道和数据处理授权，均可一键撤回

企业客户的个人中心

B2B 的个人中心更复杂：一家企业里有多名权限不同的员工。采购负责下单，负责人审批，会计取结算单据。订单只有一笔，动作却是分开的。

• 一个企业账号下有多个用户
• 合同价格和专属的账期条件
• 订单在转入执行前需要审批
• 发票、验收单和送货单集中在单据栏目里
• 支持按货号清单下单和上传文件下单

登录与保护

支持一次性验证码或密码登录，涉及资金和更改联系方式的操作需要二次验证，会话日志可以踢掉陌生设备。更换邮箱或手机号需要在新旧两处同时确认。

系统对接 — 与外部程序约定好的数据交换：传什么、用什么格式、多久传一次、数据归谁所有、出故障时怎么办。

常见的对接对象：

• CRM — 客户、咨询、商机，以及用于专属价格和营销触达的客户分层
• ERP 与财务系统 — 商品主数据、价格、销售单据、往来结算
• WMS 与仓库 — 各仓库库存、预留、拣货任务、退货收货
• 收银机与税控设备 — 销售和退货凭证，以及与线下门店的数据交换
• 支付服务商 — 预授权、扣款、退款、用于对账的流水
• 配送服务 — 费率、时刻表、创建运单、状态回传
• 电商平台 — 商品导出、订单接收、库存更新
• 营销 — 邮件和即时通讯触达、网站分析系统、商品数据源

销售与资金

• 收入、订单数、客单价、单均件数
• 按商品和类目统计的成本、毛利和毛利率
• 折扣的影响：折扣总额，以及含折扣与不含折扣的收入
• 各支付方式的构成，以及支付失败的占比

商品与库存

• 销量排行，以及毫无动销的「死货」
• 库存周转，以及以天数计的需求覆盖
• 错失的需求：库存为零时被访问的商品
• 没有结果的搜索词，是选品最直接的线索

顾客与行为

• 新客与回头客，购买频次与最近购买时间
• 结算漏斗：订单在哪一步中断——配送、支付还是注册
• 弃购的购物车：内容与金额
• 按原因、商品和供应商统计的退货

扩容是指在不重写的前提下扛住增长。会增长的有三样：商品目录规模、同时在线人数、每小时订单量。

商品目录的瓶颈在搜索和筛选，流量高峰的瓶颈在页面响应，订单洪峰的瓶颈在数据库和外部对接。对应的办法也不同，按需要逐步引入。

实践中常用的手段：

• 缓存 — 目录页和重查询结果从缓存返回，并在商品变更事件发生时刷新
• 独立搜索 — 搜索索引单独运行，按几十个属性筛选不会压到主库
• 读写分离 — 前台从只读副本读取，订单写入主库
• 横向扩容 — 负载均衡后面挂多个应用实例，实例数随负载调整
• 队列 — 重操作放到后台执行，下单结算不必等它
• CDN — 图片和静态文件由离顾客最近的节点提供
• 模块化 — 搜索、推荐和支付可以各自独立扩容和升级

高峰之前要验证什么

• 对「商品目录 → 购物车 → 支付」全链路做压测，而不是只压首页
• 支付服务商或配送服务不可用时系统的表现
• 整个商品目录重建索引的速度
• 从备份恢复所需的时间
• 外部系统的上限：ERP 和仓库每分钟能扛多少请求

增长的方向

• 新销售渠道：应用、售货机、电商平台、自助终端
• 新的仓库和自提点
• 新的币种、语言和法人主体
• 新的销售模式：订阅、预售、B2B 合同