郑州商城小程序开发需要哪些功能？商品、订单、支付和售后逐项梳理

商品先写可售规则，而不是只上传图片

商品项至少包括：卖什么、规格或套餐如何区分、价格由谁改、何时上架或下架、库存不足时用户看到什么。只有图文介绍、没有这些规则，商品中心还不能验收。

多规格、多价格或多门店可售范围，要么写进本期，要么明确不做。未写明时，默认每个人理解的“商品管理”都不一样。若价格来自既有系统，要写明以哪一边为准，冲突时谁覆盖。

订单先写状态，再写页面

订单建议写成状态序列：创建、待支付、已支付、履约中、已完成、已关闭或已取消。每个状态写明由谁触发，用户端和后台是否使用同一名称。页面上的按钮必须能对应到一次合法的状态变化。

例外至少包括：超时未支付、重复提交、支付结果未知、履约前取消。没有这些例外，测试只会覆盖顺利下单。履约若分自提、配送或到店，应标明本期做哪一种，未选的不要留在订单状态里。

支付和退款单独列责任

支付要写清本期是否收款、收款主体、用户在哪一步发起、成功和失败分别进入哪个订单状态。材料或商户号未就绪的，支付保持待核验，订单流程就不要把“已支付”写成必经状态。

退款要写清谁发起、退回哪里、失败后订单和售后停在哪个状态、用户看到什么提示。只写“支持退款”，验收时无法判断做完没有。支付回调和退款结果以项目方案及实际对接为准，本文不写成统一实现。

售后要能改同一张订单的状态

售后至少回答：用户在哪些状态下可以申请，申请后订单是否冻结履约，谁同意或拒绝，同意后是退款、重发还是仅记录。售后状态和订单状态要用同一套语言，避免一边叫“退款中”，另一边仍显示“待发货”且没有说明。

仅退款、退货退款、换货若本期不全做，应明确不做哪一种。售后原因、凭证和时限未由业务确认前，不要把一套通用原因列表当成已经定稿。后台里谁能看全部售后、谁只能处理本门店，也属于这项规则。

用一张订单样本把四块串起来验收

验收不要按菜单逐页点开就算完成。至少准备四条样本：顺利支付并完成、超时未支付关闭、支付失败可重试、售后同意后的退款或关闭。每条样本写预期的商品库存变化、订单状态和谁有权限操作。

本期不做多商户入驻、平台抽成或商户独立结算时，要在范围里写明，避免用多商户模板默认带入。营销券、会员价、分销若未进入上述样本，就不要算进本期必做。库存、支付和退款的具体对接范围，仍以方案、合同及实际交付为准。

• 商品：可售范围、规格、上下架和库存规则；
• 订单：从创建到完成或关闭的状态，以及谁能改；
• 支付：是否本期收款、退款由谁发起、失败如何看；
• 售后：申请条件、同意或拒绝、与订单状态的对应；
• 不做：多商户结算、本期不启用的营销玩法。

用同一张订单编号把四块状态对上

梳理时给样本订单一个编号，商品库存变化、支付结果、订单状态和售后状态都引用这个编号。某一块说不出该编号现在处于什么状态，这块就还没写完。不要用四份互相独立的功能清单代替这张对照。

价格、运费和优惠如果本期规则不同，要写明计算顺序，以及退款时按哪一个金额退。顺序未确认，就不要同时把优惠和运费放进必做样本，可先用不含优惠的一笔订单验收支付和售后，把优惠标为以后考虑。

后台权限至少拆成改商品、改订单、处理售后三类。若本期只有一个管理员角色，也要写明，避免上线后临时要求按门店拆分却没有样本。门店只影响履约、不影响商品主数据时，同样写清楚，防止库存被理解成每个门店各算各的。