发起联营退货：关联商家订单、选择商品并确认退款金额｜云上订货系统

云上订货 · 更新于 2026-10-08

发起联营退货时，先认回客户原主单和对应商家子单，再按本次退回的规格、单位、数量与商家退价填写。客户退平台与平台退商家分属不同业务，客户申请、商家退货记录、实物退回和退款结果应分别核对。以下历史画面用于识别原字段与处理阶段，不证明当前这一笔已经保存、退回或到账。

1 客户退货请求先回原主单和实际退回范围

客户可在手机商城沿原订单认回退货记录；平台先核客户原主单的原商品、规格和交付，再找承接这部分商品的商家子单。不要只凭客户退货金额猜商家，主单含多家商家时应按原商品归属分开处理。退货原因、原销售单位与实际退回范围一致，才能接续平台对商家的退货。

历史客户退货详情显示一种一件、商品总额六十、退款总额六十和待退金额六十，当前阶段仍是待退货。这些金额用于核客户一侧，不能直接当商家应退额；“待退”也不等于平台已经收到货物。先明确本次货物退到哪里、由谁接收，原主仓显示只说明原单仓库字段，不能代替实物签收。客户反馈申请成功但平台尚未认回原记录时，保原编号和申请时间，回同一客户原单核，不让客户重复申请同一批数量。

图1：客户手机历史原退货编号、待退货阶段及主仓，不是商家联营退货单。

图1补：客户历史商品、退款及待退金额六十；客户金额不代商家应退金额，也不证明已经到账。

2 平台新增先选原主单再选关联商家子单

平台管理端从联营退货进入新增，先选择原客户订货单，再选择其关联商家订单。原主单候选来自本平台有效联营关系，并结合商家订单已出数量扣除已退和退货中数量后的正余量；不是所有客户订单都会进入这份候选。没有候选时先核当前企业、原联营关系及原交付退量，不新建普通销售单来代替原商家子单。

选定商家后，页面取得该商家子单的原商品清单，并带入其客户资料。这个客户可能是平台在商家企业中的内部客户，不能因此判终端客户归属被修改。更换主单或商家时，页面提示清空退货清单，确认后应重新核该商家的明细；取消变更则回原选择。不要把上一家数量、单价和备注保留到另一家。这里只关联原主单和商家子单，客户原退货编号可在备注中追溯，不能以备注或同号认定系统已自动绑定两张退单。

图2：原主单、目标商家子单、本次联营退货与独立客户退货的关系及换单清空边界。

3 原规格和单位对应后再核本次可退数量

联营退货编辑清单取自原商家子单，不提供任意新增商品的按钮；不退的行应删除，不能塞入另一订单的同名商品。原赠品不进入这份选品清单。逐行核商品、规格、原销售单位和原明细，单位名称相同也要认回原规格，不把不同包装或另一行合在一起退。

页面可退量考虑原已出、在出、已退和退货中数量，按“已出加在出，减已退和退货中”显示。本次数量必须大于零且不超过页面当前可退量；带出零值或不需退的行先核后删除，不能把原清单出现就当可以退。历史商家子单两件、每件五十、金额一百，是原订货明细，不直接证明现在仍有两件可退。另一退货已占用、有人同时处理或原出库变化时，应刷新原子单和退货清单再核余量。候选、保存及后续确认各阶段需回当前原结果，不能用一次页面校验替全部后续数量核对。

图3：商家历史原单位件、数量二、成本及单价五十、金额一百；规格编号须回同一原商家子单核对。

4 本次数量乘原单位退价再核退款总额

选定原规格后，核本次退货数量与退货单价。单价带入原商家子单的价格，但最终仍按本次退价约定复核；不要用当前商品档案后来改的价格替原订单。按原选用单位填写数值，商品小计由数量乘单价形成，再合计为商品总额，不另把单位比例乘一次使金额重复换算。历史填写行显示单位件、可退二、本次一、单价五十和小计五十，局部没有表头，应结合原字段含义认回这些数字。

整单“退款金额”可以另填；留空时采用商品合计，明确填写零时总额取零，不等于没有填写。原一件乘五十形成商品合计五十，退款金额空值、零和五十是不同约定，保存前分别核显示的合计。输入文字、带单位金额或负的整单退款合计，页面会阻止相应保存；不能为了通过而把零改空。客户按销售退价六十处理，商家按供货退价五十处理，两边差额并不直接证明平台已收或已退资金。调整整单金额应在备注说明约定并交财务核原应退范围。

图4：历史填写行单位件及二、一、五十、五十；原局部无表头，当前填写结果须按同一原退货记录核对。

图4补：商品小计与退款总额的空、零及五十算例，客户六十独立核，不表示资金已退。

5 退货时间备注附件分别说明本次约定

填写退货时间并核日期，不能用后来审核或入库时间代替本次退货日期。商品行备注限制三十个字符，整单备注限制五百个字符；行备注说明该规格差异，整单备注说明退货原因、客户原退货和金额约定，不把全部说明塞进一行。历史整单备注手工写客户原退货编号及退回一件，便于双方追溯，不意味着新增了自动客户退单关联字段。

页面附件接受图片格式，并显示可选择的图片数量；当前编辑模板最多九张，历史画面提示单个四兆及图片格式。实际文件大小以当前入口反馈核，不把旧提示推广所有后台上传路径。特殊原交付可能要求相应证明图片，不能把某条特殊规则当所有联营退货统一必传。保存前确认原主单、商家和退货商品没有被换掉，再看时间、备注及需要的证明；图片选择或加载失败时先核本次反馈和已选内容，不用空白旧区域判断附件已保存。

图5：历史手工备注客户退货及图片选择提示，不证明自动客户退单绑定或当前附件上传成功。

6 保存成功回实际原单再接续允许的提交

保存前至少有需要退回的原商品，逐项数量与价格符合页面要求，退款合计不为负。后台会核原订单、原商品规格和单位对应、原可退余量及退货仓库资料；原订单强制完成或原商品无购买记录等反馈要回对应原业务处理。出现“退货数量大于可退货数量”先核是否其他退货占用，再重新读取当前余量，不删原单或修改关联绕过。

成功后进入实际返回的联营退货详情，核所属商家企业、原商家子单、原仓库、数量和金额。保存后的阶段受商家企业流程设置影响，可能接续自动提交或审核，不能统一认为每次保存都停在草稿，也不能统一认为已经完成。历史原单保存后仍有提交入口，已付零、待付五十，表示当时尚需接续。若当前是待提交，沿原单提交；已经提交则按原状态继续，不重复发起一张。成功消息后的原详情没有正确加载时，先按实际返回编号回查结果，不将旧详情当本次新保存内容。

图6：历史原退货、商家子单、内部客户及已付零待付五十；能否提交仍看同一原单当前状态和操作入口。

7 提交确认审核与实际入库退款分别认结果

原单待提交时使用提交，待退货审核时按允许的岗位权限接续审核。页面操作依当前状态显示，不能因上一张历史图有按钮就要求所有账号和阶段都能操作。提交前再核本次商品清单与金额，其他人员已处理或资料已修改时回当前原单；收到失败提示保首个反馈，不连续重复确认来猜是否成功。

历史流程条显示提交和退货确认已推进，而退货审核、入库、退款和完成仍是灰色。蓝色节点只说明原界面那一阶段，不证明商家实物已入仓或客户款已退。原可退量在保存与后续确认的取数范围并不完全相同，跨阶段仍核原已发、在出、已退及退货中数量，不能承诺页面通过后全部节点都会用同一公式严格拦截。退货审核、商家接收数量、商家对平台退款和平台对客户退款各认其原业务结果；不要以联营退货已经创建向客户承诺银行已到账。

图7：历史提交和退货确认蓝色，审核、入库、退款、完成灰色，不能解释为整条退货已结束。

8 两边按企业原关系金额和首次反馈核回退货

平台联营退货清单与商家本方销售退货详情分别核同一商家退货记录。平台清单可按商家、客户、原退货状态及时间等条件查询，原订货提交日期和退货提交日期不能混用；关键词按商家退货编号认回，缺行时先核企业、权限及筛选，再回原关联详情。关联列文字被截断时打开对应原记录看完整编号，不能凭局部相似前缀认成另一主单。

历史商家列表显示退货单金额五十、已付零、单据待退货和财务待付款，并非待审核。客户一侧六十仍回客户原退货核，商家一侧五十回商家原退货核；不同企业同号不证明自动关联，也不自动证明重复。最终逐项确认原主单、商家子单、本次规格单位数量、商品合计与退款总额，再看原退货阶段和已付待付。查询失败或提交反馈不明时保脱敏原编号、操作时间与首次提示，先核实际原结果再接续。不通过重复退货、虚报退量或直接改金额抵平差额结束尚未核清的业务。