联营结算闭环：周期生成、返点扣点、审核与打款核对｜云上订货系统

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

沿原商家子单、生成周期及原资金记录，分清应付、退货抵扣与真实到账。

1. 在原商家结算设置分清可结天数与生成周期

平台PC管理端在“联营→商家管理”打开原商家资料，核“结算设置”的返款比例、订单完成后可结算天数及结算周期。这里的可结天数以原联营订单完成时间接续，不以提交日期或发货日期替代；表单允许零至三十天。零天也只是完成后可进入候选，不表示下单立即结算，更不表示客户支付成功后商家银行已经收款。

每天、每周指定日、每月指定日决定自动生成的日期条件。选择每周时填写对应星期，选择每月时填写一至二十五日；切换周期会清原指定日，应重核必填值再保存。每周或每月不是只收刚过去七天或一个自然月的订单，原来尚未结算、现在满足条件的订单仍要纳入候选核对。

配置保存与结算生成是两个环节。改可结天数或周期后，先核当前原商家资料和下一次实际生成记录，不把原列表空白认成设置已生效或后台已运行。原结算单保存当时的周期、天数和收款资料，后续修改商家档案不应被解释为已生成单头、旧付款和全部历史金额自动重算。

图1：原完成条件、可结天数与日周月生成日期分层核，不代银行到账。

2. 按原完成时间和待结状态核本次候选订单

平台在“联营→联营订单”按原商家、原平台主单和商家子单定位，核订单是否有效已完成、原联营关系是否有效、结算状态是否仍待结算。商品已发货或客户已付款不能替代订单完成；商家子单与平台客户主单是两层原交易，结算候选按本次原商家子单核，不直接拿主单总额结给任意一家。

历史列表显示一张商家子单金额一百元、订单已完成而结算待结算，说明订单履约与结算状态分开。画面里的提交时间不是完成时间，不能仅根据提交日期算可结天数。自动候选还要核完成后经过的天数和当前周期条件；有多家商家时分别核所属平台、商家及候选原单。

人工生成与自动生成并非相同条件。人工处理的原范围及岗位授权另核，不能把人工记录出现就当自动周期已正常运行，也不为了补漏强行提前结算。生成后打开原结算与明细，确认本批原订单已进入结算中；部分商家生成异常不应推成全部商家都失败，先保各自原结果再定位剩余。

图2：历史商家子单一百元已完成但待结算，提交日期不代完成日期。

图3：自动候选与人工生成原范围不同，生成后逐商家核原结果。

3. 分清销售价格比例、原扣点与已分账金额

商家档案的“销售价格比例”与结算设置的“返款比例”不同。历史资料显示销售价格比例百分之一百二十，它不是结算扣点百分之一百二十，也不能直接用销售额减供货额当本次扣点。结算核原商品供货价与数量，再看各原订单实际扣点及原已分账金额，避免只认档案当前比例。

原订单已经保存扣点金额时，生成使用这笔原扣点；没有原扣点金额时，才按相应返款比例与供货结算金额计算。原扣点零元与未保存不是同一种情况，不能为使账平而把零改成当前比例再扣一次。修改商家当前比例不保证已存扣点的旧订单全部重算，每张原订单的实际扣点应逐项保依据。

示意供货结算一百元、原扣点十元、原已分账二十元，生成应付为七十元。十元和二十元是讲解算例，不是历史截图的实值。已经分账的部分在原应付基数中扣除，不在完成打款时再付一次；分账应用下还要核原分账状态和记录，不靠按钮名称承诺真实资金已全部分出。

图4：历史商家资料销售价格比例120%，不是返款扣点或周期证据。

图5：示意供货100、原扣点10、已分账20应付70，非历史实值。

4. 从原商品明细核销售金额、结算金额与应付

在原联营结算详情切到“订单明细”，按订单号、客户名称、商品与规格编号、数量、单位、销售价、结算价和小计核本批。商品同名不等同一规格，箱和件沿原单位，不能把销售数量当基本库存数量。明细下单时间帮助找原单，不用它替代生成采用的完成时间。

历史商家子单商品表显示两件、供货价五十元、小计一百元；这是这张原供货订单的商品金额，不是平台客户销售总额，也不是商家已收现金。结算金额按原数量乘供货价汇总，销售金额按原数量乘原销售价汇总，两列可以不同。原订单优惠或其它费用不能只因单头有金额就承诺全部进入这两个商品汇总。

应付金额进一步扣原扣点与原已分账。单头扣点比例只帮助查看生成配置，不保证每笔原订单都按同一比例重新计算。详情保当时结算单头和原关联明细，核差额先逐单逐行认原保存值；导出明细另保同一原结算和筛选范围，不能一张明细表证明后续价格、当前资料、付款和外部到账都永久一致。

图6：历史原商家子单两件供价50、小计100，单位与客户销售价分开。

图7：销售、供货结算、扣点、应付和本次实际打款各认原来源。

5. 核原待审核状态、银行资料与驳回后的再结范围

平台打开待审核原结算，核联营商、销售金额、结算金额、扣点、分账和应付，再核开户名称、开户行、银行账号或支付宝资料。银行资料可在允许的原状态编辑，原单已完成后不再用编辑旧收款资料替代一次付款更正。商家本方在对应平台的“对账结算”查原结算，不把平台员工和商家身份混用。

只有原待审核结算进入审核处理，通过后为待打款；通过不是银行打款，仍要核实际渠道和付款依据。驳回保原结算及备注，同时原关联订单回到待结算范围，可在后续符合条件时再结。驳回不等删除原单或原款退回，也不保证下一轮一定成功，原有效关系、完成条件和配置仍需核。

审核备注用于交接本次差异、金额和账户依据，不应从“请填写备注”就说驳回原因必填。原单不存在、当前不能审核或资料已经变化时，先刷新原结算确认状态和最近处理人，再按真实待办继续。看见旧待审按钮不能证明当前仍待审，更不能连点通过来试图覆盖另一岗位刚处理的结果。

图8：审核通过待打款，驳回原订单再待结，不删除原结算或证明到账。

6. 分别办理完成打款登记与线上转账

平台列表按联营商、单据状态和单号关键字定位原单；顶部待审核、待打款汇总沿各自应付，已打款沿实际打款。历史空列表显示三组零值和销售、结算、扣点、应付及实际打款列，零值只说明当时当前列表没有可展示记录，不能证明全企业全部结清、周期没有运行或商家银行余额为零。

“完成打款”弹窗核联营退货预览，再默认以原应付减这组退货金额填写实际打款，核付款时间、付款账户和备注。实际打款需为正且不超过原应付；如果扣退货后为零或负数，应核原退货余额和财务处理方式，不以任意正数凑一次完成。这里登记原资金付款和后续往来，不能认为点完成就自动向银行卡转账。

“线上转账”是另一入口，要求相应结算服务与商家账号，核可用余额，默认金额为原应付，不能套普通弹窗的退货扣减默认值。渠道成功后接续平台付款、商家收款及相应流水；明确失败有失败反馈，未取得明确最终结果时回查原记录和渠道凭据。系统已完成与外部实际到账分开，不因一条成功提示就承诺所有银行和退货都闭合。

图9：历史空列表三类汇总及金额列，零值不代全账结清或当前失败。

图10：完成打款登记与线上转账默认金额、原渠道及结果分别核。

7. 沿原联营退货、返款预存款及欠款查抵扣

普通完成打款接续本次原商家往来：平台原付款及资金账户变化，商家原返款余额和原欠款抵扣另核。返款账户与预存款账户分开，不把所有结算付款统一说成充预存款或现金到账。核原商家客户档案、原结算单号、金额和实际抵扣的订单，不能拿客户商城账户余额代商家与平台的这笔往来。

联营退货按当前平台、原商家及有效原关系选取，允许范围可以包含待入库、部分入库、待付款和部分付款，不只入库全部完成才出现。每张原总额减已付和在付，只有正余额继续处理；在付部分不是本次再次可退额。普通付款后接续原退货预存款及相关欠款，同时保本次关联退货清单，不代表平台客户退货已自动退款。

例如原退货总额三十元，已付十元、在付五元，本次正余额十五元。详情关联退货文字可能显示原退款总额三十元，不能把它直接当本次十五元或再扣三十元。普通预览、实际付款及退货账户记录逐笔核；线上转账不等同这一退货处理链，客户退平台的款仍回原客户退单和真实渠道核剩余。

图11：普通结算原返款、退货预存款和原欠单接续，客户退款仍独立。

8. 从原结算和付款结果定位空表、失败及差额

未生成先核原完成时间、可结天数、周期指定日、原有效商家关系及原待结状态；查不到先确认平台、商家、状态和关键字，不能只按相似单号认为记录丢失。原商家停用或关系不再有效可能改变列表范围，空表不意味着原资金账消失，也不用重新录一批相同订单补结算。

审核或付款反馈原状态不能处理时，回原结算核最近审核、实际打款、相关付款和原订单结算状态。页面资料过旧先重查再决定，不能推全部失败必然回滚，或旧版本任何情况下都一定被拒。应付少于预期先沿原供货明细、原扣点、原分账及付款阶段退货余额分层查，不直接回改当前比例抹平差额。

线上结果未知尤其要保原结算、付款账户、原金额、时间和渠道记录序号，核平台付款与商家收款是否已经生成，再继续剩余待办；不重复转账来试探上一笔结果。最后分别核原余额流水、原欠单抵扣、关联退货和真实收款凭据。当前岗位授权、定时生成记录、跨企业同一原单及全部资金结果仍需核对，历史画面不代替本笔结算和真实收款结果。