设置联营价格与结算规则：供货价、销售比例、返点和周期｜云上订货系统
云上订货 · 更新于 2026-10-08
先按原规格分清供货价、平台基础售价与成交价，再沿原订单和结算单核扣点、天数周期、退货抵扣与实际付款；规则保存不代资金到账。
1. 逐规格分清供货价与平台基础售价
商家发布到目标平台时先按规格填写供货价，核原商品、规格、单位和每项金额，不只看商品行的最低价。历史发布画面显示一项商品、一种规格、单位件、销售价与供货价均为五十，只证明当时设置供货价的步骤，没有显示平台最终售价，也没有证明客户已经按此金额成交。多规格时展开每项分别核，不因名称相同就合成一个价格。
新发布的平台对应规格会结合供货价与合作销售价格比例形成基础售价，保存精度按平台价格设置处理。例如供货价五十、销售比例百分之一百二十，基础计算为六十；这是独立算例，实际平台价格须回同一已发布规格核对，不能只由历史供货价五十推定已经保存为六十。商家选择商品时初始供货价还可能结合商家侧平台客户比例形成，仍以确认发布的实际输入为准。
平台基础售价不是每个客户最终成交价，客户价格、促销和订单实际允许条件还需沿原成交明细核。供货价也不是商城客户支付金额，更不能将五十与六十差额称固定净利润；采购、配送及实际费用不由这个比例全部解释。先保存同一平台、商家与规格对应，再核平台价格和客户原单，避免把自有商品上架与联营发布金额混用。
图1：历史发布供货价局部：销售价50与供货价50；规格及单位仍回原发布明细核对，未显示平台最终售价。
2. 销售价格比例按百分数保存回读
从平台PC管理端联营进入商家管理，打开原商家并编辑销售价格比例。表单填写百分数数字，销售价格比例控件范围一百到九百九十九，例如输入一百二十，不是输入一点二，也不把百分号作为数字正文重复填写。历史原资料的百分之一百二十仅说明当时合作值，不作为所有商家统一比例。
销售比例、返款比例和可结时间属于不同字段，修改前由运营与财务核本次协议和生效对象。销售比例用于对应规格售价的形成，返款比例进入结算扣点，天数与周期影响结算候选时间，不能用一个数字替三项约定。编辑整表还需满足当前必填资料，缺经营分类或其他资料时按原提示回对应字段，不能只看比例框有值认保存完成。
保存先进行表单校验，返回成功后沿返回商家编号回读详情，核显示百分数及其余合作规则；失败则保原消息，不把旧详情仍可见当新比例已保存。页面范围不应外推全部后台都采用同样强制边界，按允许控件填写和实际反馈核对。操作中不新增另一同名商家解决比例问题，也不凭名称相近就改别家合作资料。
图2：历史合作资料局部：销售价格比例为120%，不是返款比例或毛利率。
3. 改比例改供货价与原订单分别核
合作销售比例变更后，先分别核之后新发布规格、已发布商品以及原订单。新发布会读取当时双方合作比例并保存到规格关系；已经存在的平台规格仍要核自己的供货价和比例记录，不能承诺只改商家档案就批量重算全部商品。旧未完成订单的金额也不能从当前商品售价直接推成已重新计价。
商家在已发布商品允许入口修改供货价时，变化的规格会按当前合作销售比例更新平台规格价格及参考进价，并触发该平台商品自动下架处理。改价后须回查平台商品和规格价格、审核上下架状态，再决定可售接续；不要把供货价保存提示当客户马上仍可购买。没有改变供货价的规格不能自然当已经套用新合作比例重新算过。
原订单核创建或后续允许业务更正保存的实际数量、单位、单价与金额，已有结算核所存比例和明细；既不机械把历史永远冻结，也不宣称当前规则全量回改。调整前列明原记录和待处理对象，调整后核实际允许结果。价格更新、商品下架、新单成交与历史结算是不同结果，不能只凭一项档案数字证明全部同步成功。
图3：新旧价格范围：发布、改供价、档案比例与原订单分层核。
4. 返款比例在结算中按扣点理解
商家资料的返款比例在联营结算详情中显示为扣点比例和扣点金额，按结算金额计算扣点后减少对商家的应付。它不是客户商城的优惠券折扣，也不是自动汇回商家的额外现金，更不是法定税率或商品毛利率。协议用返点字样时仍应由财务按系统原字段与资金方向确认，避免同词不同对象。
生成结算时逐个商家子订单累计结算金额，按当时读取的商家返款比例计算该订单扣点，再汇总到结算单和明细。例子中结算五百、扣点百分之五，扣点二十五、应付四百七十五；应付并非实付，销售金额可能来自另一原单价。历史返款比例五的资料没有付款流水，不证明已收到二十五或已经打给商家四百七十五。
比例由财务依真实协议在允许字段保存，不凭标题推断一切负数、百分之百上限或所有范围都受同一后端校验。生成后的结算保存比例与金额，回查该单原明细；尚未生成结算的旧订单还要核生成时读取的规则。规则变更应明确哪些原订单已结、哪些未结，不用当前档案数字替已经保存的原结算金额。
图4：历史结算资料局部：返款比例5%；结算详情使用扣点比例与扣点金额口径。
5. 可结天数与周月周期分别填写
订单完成后可结天数与结算周期分别设置。可结天数控件允许零到三十，填零表示完成时间达到天数条件即可候选，不表示刚提交订单就可结，更不等于已经完成付款。查原单时同时核有效状态、实际完成时间和是否未结算，不以发货时间、付款时间或订单创建日期替代完成节点。
周期可以选每天、每周或每月；每周需选星期，每月结算日控件范围一到二十五，不能填写二十八或三十一当统一月底结算规则。切换周期会清空原目标日期，应重新按当前周期填写并保存，不能保上次月日当本次星期。新资料每天默认与既有商家回读值分开，以这次成功保存的详情为准。
历史周期画面选完成后零天、每天结算，同时显示周月输入与月一到二十五提示，只说明原设置。可结天数说明完成后多久具备时间条件，周期说明在什么日历条件汇集候选业务，两者不能合并成银行自动付款日。财务还要核实际生成的结算单、审核状态及后续付款记录，保存周期不会直接完成资金转出。
图5：历史结算周期局部：完成后0天、每天结算，另有每周星期及每月1—25日提示。
6. 结算生成按完成原单与当前规则核
结算候选来自有效、已完成且未结算的商家子订单，并须存在有效平台与商家联营关联。完成时间加当前合作可结天数满足条件后，再按每天、当前星期或当前月日与所选周期日期核是否入选；不同平台和商家分组形成对应结算。尚未完成、已进入结算或关联异常的原单不能只凭日期已过解释成应当生成。
生成时会再读取当时双方合作资料的返款比例、天数与周期，并把这些值保存到新结算单。因此旧订单虽然早已创建，若仍未生成结算，不保证永远用创建时返款比例；协议变动前先查原单结算状态和实际生成批次。已生成的原结算则以它存下的规则和明细核，当前档案不是全部历史统一取值的证明。
没有生成时核原完成时间、有效与未结状态、合作周期回读和实际生成结果，再查对应运行记录；有候选也不保证任务本次成功运行。不要依据历史任务说明宣称当前部署固定几点已执行，或不停改周期催生重复结算。审核驳回会按原关联退回订单待结算接续，新生成仍须核新单规则与原订单，没有永久保持原比例的保证。
图6：结算时间条件：完成、未结算、天数、周期与规则取值。
7. 销售结算扣点退货与实付逐笔拆开
结算详情分别有销售金额、结算金额、扣点比例、扣点金额、应付和实付。沿结算单进入订单明细，核原订单号、商品规格、数量、单位与两种单价，结算累计按原子订单结算单价乘数量，销售累计按原销售单价乘数量；不能把客户订单头所有配送费、税费和其他费用都不加区分纳入同一结算基数。
算例为十件，结算单价五十、原销售单价六十，结算五百、销售六百；百分之五扣点得二十五，应付四百七十五。若另有四十五符合抵扣条件的退货余额，实际打款核对数可为四百三十，但这只作解释算例，需按真实原退货状态和剩余金额回查。退货单总额还要扣已操作及操作中退款，不能把整张原退货再次抵扣。
完成打款另有实际打款金额、付款时间和付款账户的必填资料，页面默认金额会考虑符合条件的联营退货。保存后核付款记录、结算实付及原退货关联，系统资金余额或商家侧平台客户返款余额与抵欠结果也要分别核，不等同银行实际到账。已有分账不能仅凭结算应付判断已自动全额扣除，应沿真实支付来源核，避免重复付款。
图7：独立结算算例：销售600、结算500、扣点25、应付475与退货后的核对金额。
8. 价格周期与付款差异保原结果处理
售价不符先查原规格供货价、合作销售比例和实际客户成交条件，尤其确认是否只改档案或真实供价已变化并下架。结算未生成先查原订单有效完成和未结状态，再核天数、周期日期和本次生成结果。应付与销售总额不同先拆原两种单价与扣点，不凭汇总差额直接认漏款或价格错误。
付款与应付不一致时查可抵联营退货剩余、已操作和操作中退款以及真实付款记录。结算待审核、待打款、完成与驳回分层，添加付款要求原单处于待打款并核版本；状态或原记录异常会返回对应提示。不能把期望金额输入、旧实付栏仍显示或失败后弹窗关闭当本次已付款，也不保证所有错误都没有任何中间记录。
规则保存、价格修改、结算生成、审核与实际支付分别沿同一商家平台原编号回读，保原字段和失败消息，再由允许岗位处理具体差异，不反复改比例和周期或重复提交资金动作试错。实际价格、结算及到账结果须按当前岗位和同一原记录分别核清；历史图不代表自动银行付款或全部历史金额已经同步，未核到的记录继续列待办。
图8：价格结算异常核对：价格、结算时间、实付差额与原返回逐层定位。
下一步学习
设置联营商品发布权限：直接上架或平台审核后上架｜云上订货系统（KC-000270）
商家发布联营商品：选择已有商品、分类品牌与供货价｜云上订货系统（KC-000273）
联营结算闭环：周期生成、返点扣点、审核与打款核对｜云上订货系统（KC-000237）
联营结算单未生成或金额有差异：结算条件、退货与周期核对｜云上订货系统（KC-000583）