一、退货这件事，难的不是收了，是"收了之后"
做过电商、做过经销商、做过设备销售的团队，几乎都被同一类问题反复咬过：
- 入口散：客服在企业微信里答应退货，业务员在电话里答应换货，客户又在店铺后台提了一次——三条线各自成立，仓库一次货到了三箱，谁也不知道哪个箱子对应哪个承诺。
- 货到没人认：快递把箱子丢在月台，仓库签收了但不知道是谁的、属于哪张订单；等客服问起"我那个退货到了没"，只能去翻监控。
- 判定靠吵：销售说"这货擦一擦还能卖"，质检说"外观不合格"，最后以"让步接收"糊过去，谁签的字、依据是什么，纸上没有。
- 换补发靠催：答应客户换新，出库单没人开，客户第三次来问才知道"还没发"。
- 账对不上：一个月答应了几笔退款、实际退了几笔、原订单冲减了没有，三个数字永远凑不齐；更麻烦的是提成还按原单全额在算。
这些现象看起来是"部门配合不好"，其实是同一个缺口：一次退货没有一条从头到尾的记录。它没有编号，没有当前状态，没有明确的责任人，也没有谁在什么时候做过什么判断。于是每一次退货都变成一次临时协调，协调的人一换，事情就断。
要补的不是"更勤快的沟通"，而是一套退货与返修模块：客户申请退货先建单，货到登记实收，质检逐项判定去向，判定结论触发换货、补发或入库，整条线有状态、有责任人、有时间点、有留痕。下面按"数据怎么建 → 页面怎么用 → 自动化怎么接 → 手机怎么配合 → 上线查什么"分开讲，每一段都可以直接拿去做给 AI 构建器的需求描述。
二、这套模块长什么样：业务数据 + 管理页面 + 流程审批 + 移动端伴同
用 Inkwell AI 构建器做这类模块，你不需要先学数据库或写代码：把上面那段业务描述提交给 AI 构建器，它会生成一套完整的业务模块——数据表结构、列表页与表单页、审批节点、以及自动适配手机端的伴同页面。这份方案讲的是可交付的模块形态，不是某个现成系统里已经存在的功能。
退货返修这个场景特别适合这么干，因为它同时具备四个特征：要登记数据（退货单、判定结论）、要走判断与审批（谁批准退款、谁批准报废）、要有台账可查（这单走到哪一步）、要在手机上随时录（仓库收货、质检拍照、业务员在客户现场提交申请）。
三、数据怎么建：先定三件事，再定表
很多团队一上来就画字段，结果表建完发现统计不出来、改起来很疼。做退货模块，先定三个设计决定：
决定一：退货单代表"一次退回"，不是"一行一个物料"。
客户一次退回来往往是三件商品、两个批次；如果按物料一行建单，就会出现"同一件事三个编号"，物流单号、客户诉求、退款金额要重复录三遍。正确拆法是：主表记这一次退回（客户、原订单、物流单号、期望处理方式），明细子表记每件货（物料、数量、批次）。一张单一个编号，客户、客服、仓库、财务都认这个号。
决定二：数量是这套模块的核心数字，判定只能追加、不能覆盖。
退回 10 件，最终可能是 6 件合格入库、3 件返修、1 件报废；也可能是先判 8 件合格，第二天复检改成 7 件。如果判定结果写在主表的一个"处理方式"字段里，那么修改就意味着历史消失，事后说不清"当初谁判的、为什么改"。所以判定要另立子表，一行一次结论：判定人、判定日期、处置方式、处置数量、判定意见——只增不改，改判就新增一行。
决定三：主表只记"应退"，实际退款与冲减在财务侧记一次。
同一个金额如果在退货单里记一遍、在应收应付里再记一遍，早晚会出现"两边各算一次"的放大。稳妥的做法是：退货单只记应退金额与退款方式，实际退款凭证、账务冲减走财务侧的单据，退货单通过状态与关联单据表示"已退款"。这样退货台账不会变成第二本账。
主表：退货单（RMA）
一行一次退回，字段按"谁认什么"来分：
- 退货单号（自动编号）：客服、仓库、财务共用的唯一号，客户回执上也印它。
- 客户与联系人：直接引用客户档案，不重复录入名称电话。
- 原订单号：引用销售订单，退货必须有来处；原订单之外的退货（老客户年久退换）允许手工登记为"无原单"。
- 退货类型（字典）：质量问题、七天无理由、错发漏发、运输破损、其他。"其他"这个选项一定要有，否则一线会乱选。
- 寄回方式与物流单号：客户自寄、快递到付、上门取件；单号手工录入，方便仓库按号找箱。
- 期望处理方式（字典）：退款、换货、补发、维修返修、仅检测。这是客户要什么，与后面质检判定的实际能给什么分开两个字段，二者不一致才是需要沟通的点。
- 实收日期、实收数量、当前状态。
- 应退金额：只记一次，注明按原订单单价还是协商金额。
- 客户诉求描述：客户原话，别让客服翻译。
状态链：每个状态都要有出口
建议这样一条链：
待收货 → 已收货待判定 → 判定中 → 处理中 → 已关闭
同时必须给三个例外留出口，否则单一辈子关不掉：客户取消（货没寄回来）、拒收退回（判定为不予受理，原货退回客户）、超期未回（约定时间没收到货，客服关单）。状态不要临时加，做之前就用数据字典把这几态一次定死——仓库和客服对着同一张列表说同一套话，比什么都重要。
明细子表：退回明细
一行一件货：物料（引用产品档案）、原订单行、退回数量、批次号或序列号（手工填或选择）、外观与包装描述、客户提供的凭证（照片、聊天记录截图）。批次号与序列号这两个字段值得现在就留：等哪天要查"这个批次一共退回来多少件"，你会发现它有用了，后面在延伸篇里讲到批次追溯还能接上。### 判定子表：质检结论一行一议
这是整套模块里唯一真正需要"专业判断"的表，也是事后最容易扯皮的地方。建议字段：
- 关联退货单与退回明细行（判定要针对到具体那一件货，不是针对整单）
- 判定人、判定日期
- 判定结论（字典）：合格入库、可再销售（折价）、返修、报废、退回客户、转供应商索赔
- 判定数量
- 检验项与结论摘要（外观、功能、配件齐全度，按行业自有标准定）
- 处理责任方（本公司承担 / 客户责任 / 物流责任 / 供应商责任）
- 判定凭证（照片，挂在这一行上）
这里有两个容易踩的坑：
坑一：判定数量之和必须等于实收数量。 退回 10 件，判定加起来只有 9 件，那一件去哪了？这类差额靠人核对永远核不完，正确做法是把它交给平台的数据流规则（条件触发的数据变换规则，可以理解为"保存时自动执行的检查与计算"）：判定行保存时自动汇总已判数量，超过实收数量直接拦下，全部判完才允许主表进入"处理中"。规则是系统执行的，不依赖谁记得。
坑二：附件必须挂在明细行，不能只挂主表。 一张退货单可能有六张照片，挂到主表就再也分不清哪张对应哪件货。凭证挂在明细与判定行上，才能实现"按票据反查所属业务"——这是仓库与质检对账时最常用的入口。
执行表：换货、补发与返修任务
判定"换货"和"补发"之后，事情还没结束：真正让客户满意的是货发出去。所以判定通过后要生成一条执行记录：
- 关联退货单与判定行
- 执行类型（换货出库 / 补发出库 / 返修任务 / 退款申请）
- 新出库单号或返修任务号（引用库存出库单据，或生成一条返修工单）
- 承诺发货日期与实际发货日期、快递单号
- 执行人、状态（待执行 / 已发货 / 已完成）
最省事的做法是让审批通过后自动生成下游记录，交给数据流规则或审批流的后续动作去写，而不是让客服"记得去开一张出库单"。人工补单这一步，就是漏发的来源。
返修这一类还要注意：返修不是终点，返修完成要能回到判定。返修回来后应当新增一行判定（复检），合格才允许入库，否则"修了但没修好"的货会悄悄回到可售库存里。
平台能力怎么帮上忙
这套表能省事，靠的是平台上几个已经有的能力，逐一说明：
- 数据字典：退货类型、期望处理方式、判定结论、责任方这些只有固定几个选项的字段，集中在一处维护，改了全公司同步生效。一线只做选择题、不做填空题，这是月底能按原因排序的前提。详见 数据字典：管好下拉选项的统一口径。
- 引用引擎：跨模块的软关联。客服在退货表单里选客户、选原订单、选产品时，下拉选项直接取客户档案与销售订单模块的数据，不重复录入，也不会出现"同一个客户三种写法"。原订单这条引用是整条线的锚点——退货台账要按订单核对、财务要按订单冲减，都靠它。
- 数据流规则：数量一致性校验、判定完成后自动改主表状态、审批通过后自动生成执行记录，都归它管。
- 审批流：退款、报废、超金额让步接收这几类需要签字的动作，挂审批节点，谁批的、什么时候批的、批注写了什么，全部留痕。
- 操作审计日志：敏感动作（改判定结论、删明细行、改应退金额）的留痕在平台侧有独立记录，配合模块内的判定子表，事后复盘有两条证据链。
一句话总结这三张从表：明细记"退回了什么"，判定记"谁判了什么"，执行记"给客户办了没有"。 三者都只增不覆盖，退货这件事才不会在系统里二次消失。
四、页面怎么用：让每个角色只处理自己那一段
一套模块好不好用，看的是每个角色打开的那一页，是不是刚好是他今天要处理的事。同一个数据表，可以做出四五个入口：
退货台账（客服/售后主管主界面）。 默认按"待处理"优先排序，一眼能看出卡在哪：待收货 / 待判定 / 处理中 / 待关闭。顶部筛选按客户、退货类型、原订单、日期区间、责任方组合。这一页要解决的是"我现在手上有多少单没走完、哪几单快到承诺时限了"。
收货登记台（仓库）。 只显示"待收货"的单子，输入快递单号或退货单号即定位，录实收数量、拍开箱照片、点"已收货"。仓库同事不该被迫理解整套流程，他只需要三件事：找到单、登记数量、拍照。
判定工作台（质检）。 只显示"已收货待判定"，左侧看客户诉求与照片，右侧录判定行；判完自动算差额，差 1 件也提交不上去。
换补发执行页（客服）。 判定通过后自动出现在这里，显示承诺发货日期，可跳转到出库单。超期未发货的标红——这一页是"答应客户的事有没有做到"的唯一账本。
统计视图（管理层）。 按退货类型与判定结论做分布，看"哪类问题最多、哪个产品退得最多、返修率是多少"。注意：这些数字只写系统里记录的事实，不做预测，也不作为对外的服务承诺。## 五、自动化：把"要有人记得"的四类动作交给系统
退货流程里最脆弱的一环是"有人记得"。四类动作可以直接配置成自动执行：
第一类，审批把关。 退款、报废、超权限让步接收（例如判定"合格入库"但客户已要求退款）挂审批节点。审批链按金额或责任方分档，不要一条链走到底——一万元的单子和五十元的单子不该让同一个总监签。
第二类，状态推进。 全部判定行提交后主表自动进入"处理中"；执行记录完成并录入快递单号后，主表自动进入"待关闭"；这些推进由数据流规则执行，人只做判断，不做状态维护。状态一旦靠人手动改，就会有人忘记改。
第三类，超期催办。 用平台的定时任务（Cron 配置的周期性执行，可理解为"每天固定时间自动跑一遍的事"）跑三类检查：收货超期（约定 7 天没收到货）、判定超期（收货后 48 小时未判定）、发货超期（承诺发货日未发出）。超期即通过站内通知或消息推给责任人与其主管。这里的时限数值按企业自有标准定，正文只提供机制，不内置法定或行业默认值。
第四类，归档与留痕。 关闭后的退货单不再允许修改明细与判定（只能新增更正行），审计日志记录所有敏感动作。这一步在客户投诉、平台介入或财务稽核时才显出价值。
六、移动端：三个现场场景，一台手机就够
PC 上建好的模块会自动适配出手机端页面，仓库、质检、业务员不用回办公室补录。真正值得放到手机上的，只有三个场景：
- 仓库收货：扫不了码没关系，输入快递单号或退货单号找到单子，录数量、拍开箱照片、点收货。这是整套流程里最需要"当场做"的一步，一旦拖到下班后补录，数量就永远是估的。
- 质检判定：现场看货、现场拍、现场判；判定行在手机提交，照片随之挂到明细行。拍照留证比事后写描述有用得多。
- 业务员现场提交：在客户处当场建退货申请，客户诉求直接照着念录进去，避免转述失真。
一个务实的提醒：手机端适合"录事实"，不适合"看大盘"。报表、批量判定、审批多单，仍然在 PC 上做效率更高。另外，仓库、地下室这类网络不稳的场景，请按"现场拍照留底、回到有网位置补录"的常规做法安排，不要把它当成可以离线长期作业的系统。
七、上线前查这六项
模块在沙箱里能跑通，和"能上线用"是两件事。发布前建议逐项过一遍：
- 字典值定死了吗：退货类型、期望处理方式、判定结论、责任方、状态，五个字典的选项是否覆盖一线真实会遇到的情况？特别是"其他""无法判定"这类兜底选项，缺了它们，一线就会乱填。
- 状态出口齐了吗：客户取消、拒收退回、超期未回三个例外状态有没有出口？随便找三张真实的历史退货单，在系统里走一遍，看能不能关掉。
- 数量校验真的会拦人吗：拿一张"判 8 实收 10"的单子试着提交，系统必须拦住。拦不住的校验等于没写。
- 权限分对了吗：仓库能不能改判定结论？客服能不能改应退金额？用角色与权限把"看得见"和"改得动"分开，敏感动作只给指定角色。
- 下游连上了吗：换货/补发是否真的生成了出库单（与 通用库存管理 的库存扣减能对上），退款是否流转到 应收应付 侧登记，两边不要各记一遍金额。
- 手机端同步过没有：在手机上真的收一次货、判一次定，确认照片能上传、列表能刷新；预检与发布流程见 模块的测试与发布。
历史数据不用一次全搬。常见做法是先把"当前在途的退货单"录进系统跑起来，历史单子在需要查证时再补——从 Excel 起步也可以，平台支持按现成表格结构起步建模块，具体见 用 Excel 一步建模块。
八、之后怎么延伸
退货台账跑顺之后，往下接的路径通常有四条：
- 接质量侧：判定为"质量问题"的退货，可以自动生成不合格品处置单，走评审与返工返修闭环，避免质量数据与退货数据两张皮。见 不合格品处置。
- 接投诉侧：客户投诉与退货往往是同一件事的两面，投诉单可以关联退货单，看"哪些投诉最终变成了退货"。见 客户投诉与质量异常。
- 接现场服务：需要上门维修的返修件，可以引出工单派工与回访。见 售后工单。
- 接追溯与提成：批次退货率可以接到批次追溯台账；退货冲减后销售提成的计算口径，见 销售目标与提成核算。
九、这套模块不做什么
诚实地划边界，比夸大能力更省事：
- 不做扫码识别与硬件接入：平台没有原生条码/序列号扫描识别能力，批次与序列号靠手工录入或从下拉选择；需要扫描枪的团队请把它当独立硬件方案评估。
- 不做外部系统自动同步：与电商平台、ERP、物流公司的订单与轨迹接口对接，不在本模块范围内；物流单号以手工录入为准。
- 不做自动退款：退款动作发生在支付渠道或财务系统，本模块只记应退金额、退款方式与是否已退，不承诺对接支付渠道自动打款。
- 不替代判定标准：什么算合格、让步接收的红线在哪，由企业自己的检验标准决定，系统只负责记录与留痕，不做判定结论的自动生成。
- 不承诺退货率下降：这套模块能保证的是"每一单查得到、追得回、对得上"，不是结果指标。
退货与返修的真正价值，不在系统多漂亮，而在于：客户问"我的退货到哪一步了"，你能在两秒内答出来；财务问"这个月退了多少、冲减了多少"，台账能直接给；质检问"这批货为什么判返修"，判定行上有签名和照片。这三点做到了，这套模块就值了。