处理联营退货：审核、商家入库、客户退款与结算抵扣｜云上订货系统

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

沿客户原退货、商家原子单及退货分别核数量金额，再核商家实收入库、客户退款和结算余额去向。

1. 客户原退货先对原主单和应退金额

处理联营退货先在平台客户原退货详情核客户、原销售主单、退货商品规格、数量单位与应退金额。历史客户退货显示五升规格、单位件、退一件，销售单价与退款单价均为六十，小计六十；同一历史客户退货记录还显示原主单编号、已付零、待付六十。这里六十是这张客户退货的金额，不是商家供货退价，也不表示客户已经收到退款。

把原订货明细、原出库和本次实物退回范围放在一起对。商品名称相同仍需对应原规格和单位，退一件是否等于一瓶要按原商品单位资料核。客户多次或分批退回时，各笔保自己的退货编号和原明细，不用某一家商家的退货数量代整张客户原单，也不把原主单所有商品都作为本次退货。

接续前分别看客户退货的提交、退货确认、财审、入库及退款状态。按钮存在和金额显示只提供核对入口，是否已保存、已审核或已付要查看原返回与原记录。历史画面用于识别字段和阶段，当前企业岗位、同一原单的货物流转及实际资金结果仍需在原页面核实。

图1：历史客户原退货局部：件、数量1、销售与退款单价60、小计60；5L规格、原主单和待付金额须回同一客户退货记录核对。

2. 商家退货沿原子单核单位可退量和退款价

平台处理商家退货时，先从原平台订单选择对应联营商及商家原子单，再核要退的原商品明细。选择路径使用商家原销售单作为退货来源，切换平台原订单或商家会要求重新选明细；不能沿用前一家商家的数量和退价。历史商家退货显示退一件、退款单价五十、小计五十，该历史商家退货记录还关联对应商家原子单，和客户原退货六十各有自己的交易依据。

可退范围按原购买明细核：普通退货依据原已出及在出数量，扣去已退和在退，再看该规格、单位和原明细对应的可退量。缺原购买记录或超可退数量会受限，不因实物还在仓库就认为原订单一定可退。前端可编辑退款单价，但应沿双方原约定和原成交记录核，不要求商家供价五十与客户销售价六十相同。

保存前再对明细小计和退货头金额。存在单独填写退货总额的路径时，应核实际保存金额是否被该值覆盖，不能承诺头金额永远等于明细相加。退货说明、照片和其它资料按这张原单及业务模式的实际提示补齐，不把直送实收或普通采购退货的要求一律套给联营退货。

图2：历史商家原退货局部：件、数量1、退款单价50、小计50；5L规格与对应商家原子单须回同一商家退货记录核对。

3. 提交退货确认与财务审核逐个核原关系

商家原退货保存后逐个核提交、退货确认与财务审核。保存草稿不等于财审通过；是否跳过某个确认节点受对应设置和原单条件影响。每一步以同一原退货当前状态、版本和服务返回为依据，成功后重新看详情，不能靠一条审核提示就宣布货物、客户退款和商家结算全部完成。

联营商家退货的原关系应分别保平台原销售主单、商家原子单和商家退货编号。关联保存范围不包含平台客户退货编号，因此两边编号相似或退相同商品，不足以证明客户原退货已经自动绑定到商家退货。客户先退、平台再向商家退的业务事实，也需要沿各自原单证据核清，不能重复审核来替代缺失关联。

财审还会核原订单的联营结算状态，原订单已经进入不允许退货审核的结算阶段会受限。记录原错误提示，再查原结算和原商家订单，不新建无关联退货绕开限制。审核弹窗涉及返款或抵扣的说明应和本张联营路径实际款项核对，不能把普通退货的自动抵欠设置当作所有联营退货审核即退款的保证。

图3：双层退货原关系图：客户退货、商家退货与确认财审分别核原记录。

4. 商家实际收到后按未入数量接续入库

商家实际收到退回货物后，在对应退货待入库阶段核仓库、规格、单位、原退数量、已入、在入和本次数量。历史局部是单位件、原退一、已入零、在入零、本次一；该历史原退货还显示待入库节点和主仓。先验实物，再按尚可入的数量处理，不能把客户手机发起退货当商家已经收到一件。

本次入库要对应这张原退货和本次明细，核实际仓库、商品规格、单位换算及适用的仓位、批次或串号资料。前端会检查本次数量与可入数量，后台还核原退货状态、版本和明细资料；只填备注少收，不等于保存的入库数量已经减少。同名商品或同一个仓库有库存，也不能代这笔原退货明细关联。

创建入库后查生成的原入库编号和状态。入库保存提交可能先到待审核，也可能按该路径设置继续审核，不能把“入库单创建成功”统一解释为库存已增加。仍待审时沿原入库接续验货审核，反馈不明时先查同一原编号，避免再建一张重复入库覆盖原进度。

图4：历史商家退货入库局部：件、原退1、已入0、在入0、本次1；待入库节点和仓库须回同一商家退货记录核对。

5. 入库完成仍要另查退款来源和余额

入库审核成功后，查原入库的完成状态、完成时间、仓库和实际数量，再对原库存流水。历史局部显示入库编号和已完成；该历史原入库显示本次一件、主仓，同时原商家退货仍有待付五十。它说明这笔货物入库已有记录，不能证明五十已退、客户六十已到账或结算已经抵清。

库存按本次入库数量及实际换算进入对应基本单位，再核原规格和仓库流水。企业总量、可用量、批次和串号各有自己的范围，不凭一处库存数字变化推所有库存明细都正确。退货入库的批次接续也不能从普通采购入库规则直接推定，遇到条件差异保本次原记录和实际字段结果。

退款来源另核设置与原款路。入库接续存在按条件把退货金额记到该退货所属客户返款余额的路径，这属于系统余额处理，不能称银行现金退款。联营退货审核、入库后返款和结算时预存入账是不同触发点；以这张原退货的已退、在退及对应余额流水为准，不因开启普通自动退款设置就承诺所有节点都立即返款。

图5：历史原入库记录局部：RK-20260915-0001与已完成；入库数量1、仓库和仍待付50须分别回同一原入库及退货记录核对。

6. 客户手机退款按自己的原退货和款项核

客户在手机商城打开自己的原退货，核原订单、退货商品、退款总计、待退金额以及当前退货状态。历史手机局部显示商品金额六十、退款总计六十、待退六十，该历史客户原退货仍处于待退货。这是客户侧原记录的进度；商家原退货入库完成或商家退价五十，都不能代客户这六十已经处理。

客户款项需沿客户原退货及原收付款来源查。线下支付记录、返款余额、预存款和支付通道退款分别核原关联、金额及状态，实际到账还应对应原支付渠道或账户记录。通道条件符合时有退款接续路径，也不能仅凭页面金额或发起动作宣布原路到账；未核通道最终结果时保待核状态，不把商家侧平台客户的预存款当终端客户现金。

退款可处理金额还要减去已退和在退，正在处理的金额不能再次全额提交。客户询问到账差额时先保原退货号、原收款或支付记录、实际已退及处理中的金额，由对应岗位查原款路。显示待退、请求失败或返回不明确，先核同一原记录是否已产生处理结果，不重复付同一笔，也不通过改另一张商家退货抹掉客户待退金额。

图6：历史客户手机退货局部：商品金额60、退款总计60及待退60；客户单的待退货状态不代商家入库或到账。

7. 结算退货剩额与预存抵扣逐笔对应

平台同商家结算时，逐笔查该平台和该商家范围内有效、财审后可计入的原退货。退货查询并非只取当前结算单一个原订单，也不以客户手机退货金额作为商家退货池的余额。先对每笔原应退、已退、在退，剩额按原应退减已退再减在退计算，原单失效或已完成状态要按此入口的实际范围核。

结算预览把退货剩额与应付相减，预览值和实际处理仍分开。实际接续按正剩额逐笔处理，把对应商家侧平台客户的退货记入预存款，再沿原订单抵扣查结果；结算付款另有进入商家侧返款余额及订单抵扣的款路。这两种余额不是同一个来源，客户原退货退款也不是其中任意一条余额的自动等价结果。

对抵扣保存的原退货编号、原金额、原预存入账和实际扣款订单逐笔核。余额增加不证明银行付款，预存抵扣不证明所有原退货已经付清；负值、零值或预览与保存不同，要查看原状态和实际返回，不能承诺所有预览相减都允许直接付款。结算完成后仍查剩余退货及原资金记录，不仅看总应付变小就认定款货闭环结束。

图7：结算款路核对图：退货剩额预存、原订单抵扣与结算付款返款分别核。

8. 数量状态和款项失败先保原结果再接续

接续受限时先保原单号、企业、商家、商品规格单位、当前状态、版本、金额和原提示，再分别查数量、入库和款项。无购买记录或可退量不足，沿原出库及已退在退明细核；原订单已结算不能审核，沿对应联营结算核；版本改变或已不是待入库阶段，刷新同一原退货后再判断允许动作。

入库反馈不明确先查本次原入库是否已保存、待审或完成，并对原库存流水；退款未清先查已退在退及实际余额来源；结算退货预览有差额先核平台商家范围、有效状态和每笔正剩额。空表、旧金额和旧流程图不证明原业务不存在，不能用另一张普通退货或无关联其他入库补成看似完整的结果。

验收这一笔联营退货时分别收齐客户原退货与退款、商家原子单和退货、商家实收原入库及库存、结算抵扣与原余额流水。哪一步未完成就沿哪一步原允许流程接续，不把货物完成当资金清偿，也不承诺重复审核自动补齐每一条关联。同一原单的岗位处理、通道到账和各项余额抵扣尚未核清时，保留实际业务记录，分别交接仍待处理的环节。