联营版业务总览：平台、联营商家与订货客户怎样协同｜云上订货系统

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

联营业务先把平台、商家和订货客户放回各自的企业与原订单，再核商品、交付和结算。平台对客户的销售单与商家的联营子单有关联，但不是同一金额、同一登录身份或同一款项。以下历史管理画面用于辨认字段；本企业实际开通、岗位权限、客户可见范围和同数据处理结果应在使用时逐层核对。

1 先分清平台商家和订货客户的入口

平台进入PC管理端的联营入口，分别看商家管理、联营商品、联营订单、联营退货和联营结算。商家用自己的企业账号进入“商家联营”，先选合作平台，再进入商品管理、订单管理、退货单或对账结算。名称相近不代表两边是同一工作台，也不代表商家能查看平台全部客户。客户仍从平台手机商城订货和查询自己的订单，不需要借用商家或平台员工账号。

安排交接时先记录平台企业、商家企业、客户原订单以及负责岗位。商家一侧的查询带合作平台，订单范围也与当前商家企业关系对应；若选错平台或没有带入平台，不能把空列表当成客户没下单。平台看联营订单时同样应核商家和原主单关联，不拿另一商家的统计代替本次交易。入口可见之后还要核具体对象与操作权限；页面名称和应用开关不能单独证明全部数据授权已经正确。

图1：平台、商家和客户各自入口与原业务对象；为角色关系图。

2 开通商家先核企业关系和合作资料

平台新增商家时要填写企业名称、登录资料、仓配方式、经营分类、销售价格比例、联营代码和返款等合作资料。保存会建立商家企业、双方联营关系，以及平台在商家的客户关系，并给平台关联一个商家虚拟仓。这里的“客户关系”用于平台与商家的交易，不是把平台最终客户全部变成商家的直接客户；虚拟仓也不证明商家已把实物送到平台。

资料页的销售价格比例允许填写百分比，页面范围为100至999；历史120%只能说明这份原配置，不能替代本次商品价核对。联营代码页面最多4字符，后台检查本平台有效关系中的代码重复并排除正在编辑的原记录。经营分类不能为空，仓配方式要在实际提供的两类中选择。商家数量达到额度时会拒绝新增，应查当前商家关系及额度，不反复建立同一家企业。保存成功后回到原商家详情核企业和合作字段，再由商家本人确认进入正确企业；不能以详情打开就认定客户首单和资金业务已全部跑通。

图2：历史PC详情的企业、仓配、分类、120%和代码局部；联系人与结算还应回原合作资料分别核对。

3 商家自有商品发布与平台可售分开核

商家先准备自己的商品和规格，再从选定平台的商品管理进入发布。发布选择里默认“只显示有库存”，找不到商品时先核这个筛选和商品自身资料，不直接认定平台限制了全部商品。选定后展开规格、核供货价；初始供货价可能按自有销售价与平台在商家的客户比例带入，还可以在允许的填写步骤调整。因此，自有商品列表中的销售价不是已发布供货价，商品在商家上架也不是平台已审核上架。

发布会把商品复制到平台并建立商家商品、平台商品以及对应规格之间的关联。通常先形成待审核记录，合作资料选择免审核时另有批量通过分支。遇到“已发布，不能重复发布”，先查原平台商品与关联，不再用同商品重复提交。历史列表显示一件商品已上架、一个规格，只能证明当时自有档案的状态，不能证明发布弹窗已填写、平台售价已确定或客户此刻可以买到。平台应回查原联营商品状态、实际可售规格和客户条件，商家应回查原供货价；双方分别确认后再让客户核同一商品。

图3：历史自有商品名称编号、上架和规格局部；未显示供货价发布弹窗。

图3补：自有档案、平台复制关联与审核状态分层核；不是系统操作截图。

4 客户主订单与商家子订单沿明细对应

客户在平台下单后，联营明细按商家分组形成对应商家子订单；没有商家归属的自营明细不因此成为某商家的子单。平台应按原订单明细核商家、商品、规格和数量，商家从指定平台的订单管理核自己的原子单。平台主单与各子单的单号、企业和价格分别记录，不以客户主单数量直接当作某个商家的全部任务。多个商家一起出现在一张客户订单中时，每个商家仍只对自己的交付范围核对。

子单使用对应商家供货价作为销售价，原主单客户价则是另一个成交口径。假设供货价100元、平台销售价格比例120%，这个关系用于解释价格层次，不代表每张客户单最终就是120元，也不代表运费、优惠和税费在两端完全相同。出现“客户已下单、商家没有订单”时，先在同一原主单核关联子单是否真实存在、商家与规格映射、应用和当前阶段，再由对应岗位处理首个失败。客户提交成功不代替拆单成功，不能为补商家列表而另建一张客户订单覆盖原结果。

图4：主单客户成交与子单供货价不同，原关联需要逐商家回查。

5 仓配方式决定地址和实物交付责任

商家发货是“不入平台仓”的合作方式，商家子单承接客户原收货地址，由商家按自己的原业务交付。平台代发是“入平台仓代发”，商家子单收货地址取平台相应送货仓，平台再安排后续客户交付。缺少指定送货仓时会使用平台默认仓作为相关地址来源；平台代发遇到仓库收货地址不完整，拆单分支会提示先完善仓库地址再重新审核。应由掌管该仓的岗位核真实联系人和地址，不能仅在商家名称里写一个仓库。

历史下拉选项只证明两类配置名称，不证明仓库已实际收货、商家已经发货或客户已签收。联营拆单还有不能选择上门自提的拒绝分支，客户与销售应按本企业实际允许的配送方式确认，不以普通订单可自提推联营也可用。货已送客户但平台仍待处理，或平台有虚拟仓但没有实物，都要回原单的出库、发货和收货记录逐项核，不能为了让按钮出现临时换仓配方式，更不能把改配置当成已完成货物交接。

图5：历史资料显示商家发货与平台代发两种选项；实际款货结果另核。

6 退货沿客户原单商家关联与真实货流处理

客户售后先从平台原订单核规格、已发量、已退量和退货中量，再确认实物要退给商家还是平台。手机订单里联营主单、子单的未发货退款入口有不同条件，不能照普通订单的未发货取消流程保证一定有同一按钮；已发货相关退货也要核剩余数量与当前状态。平台管理详情的可退提示还受单据阶段、已出库或发货数量、退货占用和允许退货时间影响，提示可退不是每一规格都能退全部原数量。

平台应同时回查客户退货记录与对应商家联营退货，而不是只看一侧成功消息。商家从指定平台的退货入口核原业务，财务分别核客户退款和商家结算里的退货款项。实际退货收妥、系统数量更新、客户退款记录、商家应结金额调整是几项不同结果，一项完成不能代替另一项。申请失败或数量不一致时保留原订单和退货单号，核首个被拒条件及已有占用，不删原明细或重建交易避开限制；退款最终去向需核原资金记录，不把返款余额直接解释为银行到账。

图6：客户售后、商家关联退货和退款结算分别回原记录核对。

7 可结天数周期生成审核和打款逐层核

“订单完成后可结天数”与“每天、每周或每月结算”分开填写。页面可结天数范围0至30，月周期选择1至25日；历史0天、每天、返款5%只是原配置。周期取数要求相关有效子订单已经完成、仍待结算并达到可结时间，再按平台和商家形成结算单。配置每日周期不代表每笔下单当天都结算，更不代表资金自动转入商家银行；生成的结算单首先是待审核，审核通过进入待打款。

核金额时看商家子单商品数量与供货价形成的结算金额、返款扣点及已分账金额。生成时的应付由结算金额扣返款和已分账金额，添加付款的界面还会读取相应退货尚待退款部分形成差额，不能只拿客户主单总价给商家付款。添加付款要求原结算单处于待打款，带原更新时间核版本；状态已经变化应刷新原单，不能用旧弹窗连续确认。普通添加付款链还会在商家侧平台客户的返款账记款并抵扣相应待付订单，系统记账与银行转账仍须分别回查。结算审核驳回会使关联订单回到待结算，之后要核新旧结算关系，不能把旧驳回记录当作已打款。

图7：历史返款比例、可结天数和日周月周期局部；未证明本次生成或付款。

8 按一笔原业务逐节点核准备和失败结果

先选择真实合作商家和实际允许商品，依次核商家本人账号、发布关联和平台审核、客户原主单与商家子单、正确仓配地址、交付状态、退货关系与结算。每一步使用同一商家和原业务身份，各节点都应能回同一平台、商家及原订单关联，不以其他业务的已完成记录代替当前结果。平台工作台的本月金额、待审结算与待打款各有对象范围，统计刷新失败后旧数据还在不说明本次查询已成功；应保留首个反馈并确认原记录更新后再继续。

资料保存被拒先核缺失字段、重复代码或数量额度；商品发布异常先查已有平台关联与本次规格价；平台代发地址异常先查仓库真实资料与主子单；结算版本或状态变化先查最新结算及付款记录。不要通过停用商家清理未结账款：停用涉及商家企业及商品处理，也不能代替原订单、实物和资金的善后。出现未知反馈时把脱敏单号、时间、角色和已确认结果交给负责岗位，由其处理真实业务；只打开商家详情、看见历史上架行或收到保存提示，都不足以证明当前企业三方协同和资金结果已经正确。