商城全链路产品设计
为斗半匠内容学习 App 增加图书购买能力，承接用户在 App 内直接购书的需求。
整体产品方案、业务流程、原型与需求设计；协调运营、研发、测试及 ERP 对接，推动分阶段交付。
一期范围：实物商城
一期优先承接图书等实物商品，覆盖运营配置、用户交易、ERP 履约和售后。方案按上下游关系拆分开发与提测，以下沿实际业务流程展开。
以下图解依据项目方案重构；示例用于说明规则。
配置商品与交易规则
先建立分类与共用配置，再创建实物商品、生成规格并配置价格、库存和售卖方式。商品内容进入 App 展示，交易规则继续约束下单与售后，ERP 关联用于承接实物履约。
从基础配置，到一件可以上架的商品
- 01
建立分类与共用配置
标准分类承接参数模板、服务标签、FAQ 和商品底栏；运营分类用于展示与筛选。运费采用商城全局公用规则，退货地址供商品关联与售后使用。
- 02
创建商品内容
填写名称、简介、主图与详情，选择标准分类和运营分类。参数从模板初始化，保存后成为商品自身数据；服务与 FAQ 等展示内容在页面请求时读取最新分类配置。
- 03
生成规格，配置价格与履约关系
规格值组合生成 SKU，分别维护规格图、售价、限购和上架状态；关联有效的 ERP App 店铺商品，并维护商城本地库存。
同时确定章鱼币抵扣方式
章鱼币是 App 内用于换购或抵扣的账户余额，商品可配置三种方式。
购买兑换比例决定获得的币量；支付兑换比例用于结算换算。固定币值不随比例变化，按价值使用最新支付兑换比例。
- 04
确定售卖方式与展示条件
配置章鱼币抵扣方式、商品上下架、列表显示与预热时间。隐藏控制列表曝光，上下架控制能否购买；两类状态分别生效。
从发现商品，到确认购买选择
用户从首页、分类、搜索或运营资源位进入商品详情，确定规格和数量后，可立即购买，也可先加入购物车统一结算。
发现商品
首页、分类、搜索
查看详情
内容、参数、服务
选择规格
确认数量与价格
立即购买
带入当前商品
加入购物车
勾选商品后结算
下单页
确认地址与金额
提交前复核：加购、去结算及提交订单分别校验。规格失效支持重选，下架商品禁止结算，库存不足需调整数量，价格变化则刷新后由用户重新确认。
从确认金额，到完成下单支付
下单先形成交易金额，再将优惠和抵扣记到商品行，最后按支付结果处理库存与资金。三个环节使用同一笔订单记录，前后承接。
下单总流程
确认商品与地址
立即购买与购物车进入同一下单页。确认规格、数量及收货地址，按地区匹配商城共用运费规则。
确认优惠与抵扣后的金额
展示商品金额、运费、章鱼币抵扣与现金实付；余额、商品抵扣上限及单次、单日额度共同约束可用币量。
提交并由服务端复核
重新核对商品、价格、库存、运费、地址与章鱼币额度，创建订单并保存商品行金额记录。
支持后续优惠扩展的金额计算顺序
- 商品原价
- 商品级优惠后金额
- 扣除订单级优惠
- 扣除章鱼币抵扣
- 加运费
- 现金实付
商品折扣先形成商品行金额；订单级优惠再按各行金额占比分摊。先对商品优惠后金额计算章鱼币抵扣，再加运费，形成现金实付；运费不参与章鱼币抵扣。
金额分摊逻辑
按商品金额占比，分配订单优惠
先算单品折扣，再将整单优惠分到参与商品。分摊后的商品金额，继续用于计算章鱼币抵扣上限。
A、B 已扣除单品折扣，尚未扣除订单优惠；均参与本次优惠。
| 商品 | 单品折扣后金额 | 金额占比 | 分得订单优惠 | 分摊后金额 |
|---|---|---|---|---|
| A | 100 元 | 1/3 | 30 × 1/3 = 10 元 | 90 元 |
| B | 200 元 | 2/3 | 30 × 2/3 = 20 元 | 180 元 |
| 合计 | 300 元 | 100% | 30 元 | 270 元 |
精度处理优惠分摊保留 2 位小数，舍入差额补到参与分摊金额最大的商品行；金额相同时按订单商品顺序。
先计算本单最多可用币量，再接受用户输入
以下可用量计算与分摊示例针对部分抵扣商品。固定币值商品直接读取配置币量；全额抵扣商品先校验完整所需币量，不能通过降低用币量或补现金购买。
计算商品可用上限
对参与部分抵扣的商品，依据各行订单优惠后金额与抵扣比例，按支付兑换比例换算为币量，再汇总可用上限。
叠加账户与订单限制
本单最多可用量同时受商品合计上限、账户余额、单次上限、当日剩余额度和商品优惠后应付金额对应币量（不含运费）约束，取这些限制中最小的值。
限制输入，再计算分摊
页面显示本次最多可用币量，手动输入和步进器不能超过该值；按用户实际选择的币量分摊，修改输入后重新计算。提交时服务端再次复核。
全额抵扣商品仍须满足完整所需币量；币不足时不能通过降低输入来购买。
先按金额比例分配，再处理商品上限
直接按商品金额比例分配，可能超过某件商品允许的抵扣量。方案先按比例预分配，锁定超限商品的可用上限，再把剩余抵扣分给其他商品，直到没有超限。
A、B 均为部分抵扣商品，抵扣上限分别为 20% 和 100%。示例未叠加商品折扣或优惠券：支付兑换比例为 100 币 = 10 元，运费为 0，余额与支付额度充足。
| 商品行 | 商品金额 | 抵扣上限 | 首次按比例分配 | 调整后抵扣 |
|---|---|---|---|---|
| A · 2 件 × 50 元 | 100 元 | 20% / 20 元 | 30 元，超过上限 | 锁定 20 元 |
| B · 1 件 × 100 元 | 100 元 | 100% / 100 元 | 30 元 | 承接剩余 40 元 |
| 保存到商品行 | 现金实付 | 章鱼币实付 | 合计商品价值 |
|---|---|---|---|
| A · 2 件 | 80 元 | 200 币，抵 20 元 | 100 元 |
| B · 1 件 | 60 元 | 400 币，抵 40 元 | 100 元 |
| 整单合计 | 140 元 | 600 币，抵 60 元 | 200 元 |
分摊后同时满足：整单总额一致、商品抵扣不超限、币量不超余额与额度、各项结果非负。
下单分摊的精度与记录
前端预估，服务端复核后记录各商品行的现金实付和章鱼币实付。用户输入章鱼币使用整数；系统分摊保留 1 位小数，差额补到可分摊章鱼币数量最大的商品行，数量相同时按订单商品顺序。下单页只呈现整单抵扣与现金实付。
支付与扣款
| 交易事件 | 库存处理 | 章鱼币与现金 |
|---|---|---|
| 创建订单 | 预占购买数量 | 直接扣除所用章鱼币；现金大于零时调起微信支付 |
| 支付成功 | 实际扣减，解除预占 | 记录支付结果，订单进入待发货；零现金订单无需调起微信 |
| 取消 / 超时关闭 | 释放预占 | 返还原付币量并释放单日额度 |
支付失败时，业务订单在付款时限内仍可继续支付；当前支付结果取最新一次支付单，历史失败记录不会覆盖后续成功结果。
支付后抛单到 ERP，发货结果回到商城
支付完成后，商城将订单抛给 ERP 承接出库发货。ERP 发货消息回传后，商城更新发货信息和订单状态，再使用 ERP 提供的物流单号查询物流，向用户展示包裹进度。
- 01
商城 → ERP：支付完成后抛单
把已支付订单及商品履约信息交给 ERP，衔接后续仓储处理。
- 02
ERP：出库与发货
仓储发货在 ERP 完成，形成发货结果和物流单号。
- 03
ERP → 商城：同步发货消息
商城接收消息，更新商品发货、包裹和订单状态；部分发货与全部发货分别处理。
- 04
商城：根据物流单号查询轨迹
使用 ERP 提供的物流单号查询物流，App 展示包裹进度，承接查看物流、确认或延长收货。
关联状态分别记录，订单主线由业务事件推进
| 对象 | 记录职责 | 关键关联 |
|---|---|---|
| 订单 | 待支付、待发货、部分发货、待收货、已完成、已关闭 | 支付成功、发货消息、收货和关闭事件推进主状态 |
| 支付单 | 每次支付尝试及结果 | 失败不直接关闭订单，当前结果取最新支付单 |
| 包裹 | 商品发货与物流进度 | 已发商品按包裹展示，未发商品单独保留 |
| 售后单 | 本次售后的审核、处理和结果 | 售后处理中保留订单主进度，另行展示售后节点 |
部分发货订单同时承接待发货与待收货列表，详情分开呈现已发包裹和未发商品。
从售后申请，到退款或补发完成
用户从订单选择商品，发起仅退款或退货退款；客服从后台还可发起补发。申请进入审核后，按类型走不同处理路径，再分别记录处理状态和退款结果。
按售后类型衔接 App 进度与处理节点
同一商品行同时只允许一个进行中的售后单；本次处理结束后才能再次申请。售后进度与原订单履约进度分别保留。
仅退款
无需退货；未发货订单仅支持此类型，售后数量与金额不可编辑。
| App 阶段 | 正常处理 | 异常 / 可退出分支 |
|---|---|---|
| 发起申请 | 选择售后商品并提交退款申请。 | — |
| 商家审核 | 待审核，客服通过后进入退款处理中。 | 撤销待审核可取消，显示“售后已撤销”。 拒绝显示“售后不通过”和拒绝理由。 审核通过后退款失败退款处理仍为进行中；临时故障重试，不可恢复或重试耗尽转人工，成功到账后才完成。 |
| 售后完成 | 退款成功到账，记录已退现金和币量。成功到账前不标记完成。 | — |
退货退款
退回商品后退款，按申请、审核、退货、收货及退款结果推进。
| App 阶段 | 正常处理 | 异常 / 可退出分支 |
|---|---|---|
| 发起申请 | 选择商品、售后数量并提交申请。 | — |
| 商家审核 | 承接待审核、待 ERP 审核，通过后进入退货。 | 撤销 / 拒绝两个审核节点可取消；客服或 ERP 审核拒绝时，显示拒绝理由。 |
| 买家退货 | 待用户退货，填写快递公司和快递单号。提交物流后，可按规则修改物流信息。 | 撤销 / 超时此阶段可取消；未按时上传物流则自动取消，可重新发起。 |
| 商家收货 | 待商家收货，收到退货后进入退款处理中。 | 退款失败售后保持进行中，按原因重试或转人工。 |
| 售后完成 | 退款成功到账，更新商品行已退记录。成功到账前不标记完成。 | — |
补发
仅后台客服可发起，App 查看进度；发起后暂停收货倒计时，后台确认补发成功后继续。
| App 阶段 | 正常处理 | 异常 / 可退出分支 |
|---|---|---|
| 发起申请 | 后台客服发起，App 查看进度。 | — |
| 商家审核 | 承接待审核、待 ERP 审核，核实补发信息。 | 撤销 / 拒绝两个审核节点可取消；审核不通过则结束申请并保留理由。 |
| 商家补发 | 待商家发货 → 发货成功，提供补发物流查询。 | — |
| 补发完成 | 记录补发成功，由后台人工确认用户收货后完结。 | — |
退款金额与章鱼币分摊
先确定分摊范围与每行可退上限
选择本次售后商品与数量
依据商品原付金额和本次售后数量确定处理范围。
扣除历史已退，得到本次可退额度
分别读取现金与章鱼币的原付、已退和剩余可退数据，防止多次申请累计超过商品实付。
确认本次实际退款金额与退币数量
退款总额变化后，按各商品可退金额比例分摊；退币数量变化后，按各商品可退币量比例分摊。
一笔混合退款，同时核对现金与章鱼币
商品 A、B 已发货，选中两行全部数量，无历史退款、运费为 0。示例未叠加营销优惠；本次退款额用于演示，不代表固定退款比例。
| 商品行 | 本次可退依据 | 本次退款分摊 | ||
|---|---|---|---|---|
| 现金 | 章鱼币 | 现金 | 章鱼币 | |
| A · 2 件 | 80 元 | 200 币 | 40 元70 × 80 / 140 | 100 币300 × 200 / 600 |
| B · 1 件 | 60 元 | 400 币 | 30 元70 × 60 / 140 | 200 币300 × 400 / 600 |
| 合计 | 140 元 | 600 币 | 70 元 | 300 币 |
现金按可退金额占比分，章鱼币按可退币量占比分；同一商品行的两种比例可以不同，分别核对合计与上限。
处理舍入差额，并更新商品行退款记录
| 处理项 | 现金退款 | 章鱼币退款 |
|---|---|---|
| 计算精度 | 保留 2 位小数 | 保留 1 位小数 |
| 差额归属 | 补到可退金额最大的商品行 | 补到可退币量最大的商品行 |
| 额度相同 | 按订单中的商品顺序处理 | |
| 完成后记账 | 更新各行累计已退现金 | 更新各行累计已退币量 |
前端可以预估，提交时由服务端再次确认；退款成功后更新各行已退记录，后续可退额度扣除已退部分。章鱼币按原付数量返还，不使用新汇率重新折算。
优惠与运费：预留营销模型中，退款沿用下单分摊结果，不追回已享受的订单优惠；整单取消退券，部分退款不退券。未发货订单退运费，已发货订单不退。章鱼币按原付币量返还，不按新汇率重算。
先打通整体方案，再分阶段提测
商城范围较大，测试资源有限。我先梳理完整技术框架和上下游关系，再按“商品管理与 ERP 商品对接—App 订单与 ERP 发货—售后流程”拆分开发与提测。
- 01
商品管理与 ERP 商品对接
先建立商品供给、规格配置与履约关联，为 App 交易提供基础。
- 02
App 订单与 ERP 发货
接通选购、结算、支付、库存变化与物流结果回传。
- 03
售后流程
继续承接退款、退货、补发以及处理失败后的恢复路径。
用跨模块规格，补齐单页需求的前后关系
除页面原型和模块需求外，我整理了跨模块链路规格，让研发能沿订单过程理解库存、支付、履约和售后的影响，也让测试围绕完整业务路径组织验证。
完成实物商城整体产品设计，按商品、交易履约、售后三个阶段推动交付。