商城全链路产品设计

斗半匠原有 App 以图书配套音视频为主，已有用户询问能否在 App 内买书。考虑到图书是主营业务，我将一期范围确定为实物商城，虚拟商品上架与售卖留到后续。

我负责整体业务流程、原型与需求设计，并协调运营、研发、测试及 ERP 对接推进交付。方案覆盖运营如何供货、用户如何购买、仓储如何发货，以及取消、退款、退货和补发如何处理。

运营既要按年级、学期和专题组织图书，也要管理不同规格的售卖与交付。我把商品设计分为四项相互衔接的业务任务，让后台配置能持续用于前台选购、订单和仓储售后。

App 通过年级／学期、分类、搜索和运营资源位组织图书，详情承接内容、服务和规格选择。我让立即购买与购物车共用订单确认逻辑，再由订单连接购买后的支付、发货和售后。

购物车保留购买选择，提交时则复核价格、库存、地址、运费及用币条件；变化时让用户调整或重新确认，再保存本次交易记录。订单、支付和售后分别记录进度，避免一次付款或售后变化覆盖整笔订单的其他处理。

支付按后台配置计算本次现金和章鱼币应付。我把用户确认的整单金额与订单保存的商品实付明细连接起来，让付款记录成为后续退款计算的原付依据。

分摊时先按商品金额分配抵扣币量，同时满足账户、整单和单品额度；某商品超限时先锁定其额度，再把余量分给其他可抵扣商品。退款继续沿用商品的原付与已退记录，保持购买和退款的金额依据一致。

正常支付

创建订单时扣币并预占库存；支付成功后扣减库存，订单进入履约。

未完成支付

失败可在时限内重付；取消或超时关闭时返币、恢复额度并释放库存预占。

我将支付完成后的订单交仓、ERP 出库发货、物流回传和 App 收货串成完整履约流程，明确各方处理的动作及需要交回的信息。

订单、商品和包裹保留对应关系，让仓储发出的商品与用户看到的物流一致，也为售后提供发货依据。同单分批发货时，已发商品关联各自包裹，未发商品继续保留待发货进度。

我按发货状态确定售后申请范围，再按仅退款、退货退款和补发安排客服、用户与 ERP 的处理路径。售后单关联原订单商品，资金、仓储和用户侧进度分别承接。

沿原付与已退记录，确定退款和后续处理

计算可退

按申请商品与数量确定原付份额，分别扣除已退现金和币量，得到本次可退上限。

分摊与返还

调整退款总额时，现金与币按各商品对应的可退额度分别分摊；成功后累计已退记录。币按原付数量返还，不随兑换比例变化重算。

后续处理

同一订单商品同时只处理一个售后，结束后可再次申请。退款以资金实际退回为完成依据；ERP 入库不直接恢复商城可售库存，重新售卖由运营调整。

测试资源有限，全部模块开发完再集中提测，会把跨模块问题留到后期。我先推动研发确认整体技术框架，再依次推进商品管理与 ERP 商品对接、App 订单与 ERP 发货、售后流程，让各阶段可以分别提测。

为避免研发只按页面实现、测试只检查单页，我在原型和模块需求之外补充五条核心业务对象的全链路规格，说明库存、支付、订单、售后与 ERP 的前后影响，支持各方沿完整交易过程理解和验证。