联营概况与商家经营分析：订单、退货、结算和利润｜云上订货系统

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

先认期间与当前范围，再沿原商家子单、退货及结算核经营数字和剩余待办。

1. 先分清顶部期间指标与下方当前概况

平台PC管理端进入“联营”概况，顶部可切本周、上周、本月、上月，也可在日期框选择自定义起止日期，再选择联营商。刷新后先认页面实际返回的日期范围，记录订单量、订单总金额、应结算金额和预计贡献利润。默认打开本月不等一直保持上次自定义范围，交接报数时保明确的开始结束日期和商家。

顶部期间指标与下方商家、商品、订单、退货、结算待办分开。下方是当前平台各类概况，不统一沿顶部选定日期和某一家商家。选九月某商家后看到下方待办零，不能直接说九月这家商家所有款货已经完成；反过来下方有未处理原单，也不必全部属于顶部期间。

日期取数还沿企业报表的订货、退货状态及时间统计设置，可能按提交或完成时间，不仅看日期框名称。两个人比较时先保同平台、同商家、同日期和统计设置，不拿提交时间清单对完成时间概况强行平账。历史九月一日至三十日画面只展示当时范围，不证明当前配置或本次原单查询结果。

图1：历史本月九月一日至三十日与联营商选择，不能代下方全部卡片同期间。

图2：顶部期间四指标、下方当前待办及进入清单后的范围分别核。

2. 分别看合作商家、上架商品与原子单规模

合作商家卡片按当前平台有效合作记录看数量，商品卡片看原联营发布关系的已上架和待审核数量。历史画面显示合作商家一家、已上架商品一个、待审零，它们不是本期新增商家、下单客户或成交件数。当前商品档案存在也不保证所有客户都可见可购，原商品审核、上架与实际访问范围仍要另核。

顶部订单量按符合统计范围的商家子单汇总，不等平台唯一主订单或唯一客户人数。同一平台主单拆给两家商家时，先认两个子单与原关系，再解释笔数，不认为客户重复下了两次。订单总金额是商品销售金额的相应汇总，不因一列有金额就说客户已经付款或仓库已经全部出货。

商家详情的订货数量来自原明细及原多单位换算比例，不与上架商品数比较增减。多种商品的基本单位仍可能不同，不能只把所有数量都称为“件”，更不能拿数量汇总直接扣库存。认商品规格、原单位、数量比例和明细类型后再核本批数量；套餐展示行、赠品或免费活动与普通行不能只凭商品名称重复累计。

图3：历史合作商家一、已上架一、待审零，不代期间成交数量。

图4：原商家、发布商品、子单笔数与商品明细数量分别认。

3. 从出库发货待办回原子单，部分状态不要重复计算

下方“待商家出库”与“待商家发货”提醒原商家子单交付待办。待出库包含待出库和部分出库，待发货还包含部分出库以及待发货、部分发货，因此同一部分出库子单可能同时在两组提醒中出现。不能将两卡片笔数相加说有两倍订单，也不生成两套相同数量的出库或物流记录。

点击对应卡片进入联营订单清单后，核当前列表的商家、状态、日期与原主子单，不假设顶部选的日期和商家全部自动传到清单。沿原子单查看已出、在出、已发和未完成批次，仓库接续本次实际货，运营补原配送及收货待办；状态提醒不是本次可出库存数量。

历史清单保平台主单与商家子单，原子单金额一百元、订单已完成但结算待结，说明交付完成与结算仍可分开。待出库、待发货零也不代表没有待收货、售后、待结算或另一范围的原单。先沿实际原记录认负责人和剩余，不靠概况一组零值通知所有客户货款全部闭合。

图5：历史原主子单关联、子单100已完成而待结算，货款状态分开。

图6：部分出库可同时在出库发货待办，先回同原单不重复处理。

4. 核首页销售额、应结算估算与预计贡献

首页顶部订单总金额按原商家子单商品的销售价与数量汇总，应结算金额按对应原供货商品额及原联营关系返款比例估算。历史例子两件销售单价六十元形成一百二十元，两件供货单价五十元形成一百元；按百分之五估算返款五元，应结九十五元，顶部预计贡献为一百二十减九十五，得到二十五元。

这组应结算不是已经生成结算单的待付款余额。概况估算与正式结算的原订单扣点、已分账、生成周期、审核状态和付款阶段退货处理不同，不能看到九十五就直接打款。原子单商品表的两件、五十和一百仅核供货价格对象，商品成本价相同也不把它当平台利润或实际到账证据。

顶部预计贡献采用订单金额减应结算估算，不在同一公式直接减原退货，亦不自动扣全部费用、税费和经营成本。原金额包含哪些商品行、其它费用是否承接、多单位处理与企业统计状态分别核，不能保证与普通销售毛利或商家详情每个数字都相等。发现差额先认算法对象和原记录，不把概况二十五说成税后净利润或现金余额。

图7：历史首页订单1、销售120、应结95、预计贡献25，不当现金净利润。

图8：历史商家子单两件供货价50、小计100，与客户销售价格对象分开。

图9：首页应结和预计贡献为经营估算，正式生成扣点分账付款另核。

5. 在商家详情按原期间核订货退货数量和预计利润

平台从“联营→商家管理”打开原商家，进入“商家分析”的“联营订单”区域，选择本周、上周、本月、上月或自定义期间。这一区域同时显示订单数、订货数量、商品销售和结算金额，另有退货单数、退货数量、商品退货及退货结算金额、合计金额和预计利润。它与首页只看顶部四项的范围不同。

订货和退货按各自原单日期与允许状态分别进入期间，不要求退货所属订单也在同一期间。上月订货本月退货可能出现在本月退货中，先回原主子关系和本批明细认，不能简单宣布本月订单丢失。数量与销售、供货金额在这一区域按原多单位比例参与汇总，首页算法不保证具有完全相同的明细与比例处理。

示意订货销售一百二十、退货销售六十，订货供货一百、退货供货五十，当前商家返款百分之五：销售净额六十减供货净额五十，再加订货供货一百乘百分之五，预计十五元。返款项沿订货供货额，不是将退后供货五十乘比例；这只是计算算例，不是已经完成的实际结算。合计金额是销售减退货，仍不是客户实收款或银行余额。

图10：商家期间订退数量金额与预计利润示意15，返款项仍沿订货供货额。

6. 将退货流程待办与原资金待办分开接续

概况“退货待处理”沿原退货流程状态提醒，“待付款处理/笔”沿原退货财务状态提醒，两者不是同一个剩余量。同一退货可以既有实物待办又有资金待办，不能相加当两张独立退货。待确认、待审核、待入或部分入、待付或部分付的流程范围与财务待付、部分付分别核。

两张卡片都可进入联营退货清单，仍要按原商家、原主子单、退货状态和财务状态找本批，不认为点了其中一个就只显示那张卡片对应状态或带齐期间条件。客户退平台与平台退原商家分两层，概况提醒原商家退货不代表客户原退款已经同步完成；实际退货数量和收货仓继续沿原单核。

历史商家退货画面入库步骤已推进，原待付款五十元，原入库记录一件已完成，货与款可以不同步。财务再核原应退、已付、在付和正剩余，安排实际返款、预存款或其它渠道，银行到账另有凭据。仓库不能再入同一件凑资金完成，财务也不因一次已入库画面就通知客户银行卡已退。

图11：历史原商家退货入库推进但退款灰及待付50，不代客户退款。

图12：原退货流程和财务待办可重叠，实物与资金各查原结果。

7. 核当前结算待办与商家已完成结算贡献

概况下方结算待审核与待打款分别看笔数和原应付金额，日期、商家范围不统一沿顶部期间。历史顶部应结九十五，下面待审核和待打款均零，不矛盾：顶部是期间经营估算，下面是实际原结算单待办。零可以与尚未生成、已完成、筛选范围及原有效记录不同有关，不能单据未找到就立刻录九十五付款凑平。

商家详情上方“商家概况”的已结算金额和贡献利润又是原完成结算范围，不能与下方期间“联营订单”的预计利润直接比较。贡献利润按已完成结算单销售额汇总减实际打款，不是首页预计应结算，也不是商品销售额减仓库成本的普通毛利。看已结算金额时回原结算及关联付款核真实实付，页面展示零值不能代银行或原资金记录。

详情上方商家概况不统一沿下方当前选择期间，它还显示订单、退单、商品等整体范围；某些原商品发布记录可能跨合作关系。经营分析先核属于哪家平台、哪张结算及原状态，再保当前实际结果。贡献利润没有自动包含全部企业费用与实际应收应付，所以老板可用它定位经营贡献，不能拿它替代完整资金和成本核算。

图13：历史当前结算待审核与待打款均零，与顶部应结95对象不同。

图14：首页预计、商家期间预计和完成结算贡献三种利润不混同。

8. 用原查询和原单定位零值、跨页差额与失败结果

换日期或商家后部分数字不变，先看顶部期间与下方当前概况是不是两层范围，不急着把所有数字认成筛选失效。查询失败有反馈时，保当前查询条件和原提示，页面可能仍留上次成功值；未得到新结果不能把旧数说成已刷新成功。没有符合记录而显示零，与查询异常、未选商家或部分对象不匹配都要分开核。

总览与商家详情差额先认订退是否相减、原日期轴、允许状态、商品类型、多单位比例、合作返款和结算完成范围，再逐单核销售价、供货价及原数量。原主单拆成多商家子单时保各自原关系，不按同名商品去重成一张，也不修改当前比例或原价格让跨页数字强行相等。原零值缺少凭据时仍沿原业务核。

最后把发现落到原商家、原主子单、退货、结算和资金记录：运营核商品与交付，仓库核本批实物，财务核真实已付在付和到账。当前岗位权限、同一原单的统计结果及进入清单后的范围仍需核对，历史画面不代替本期实际经营结果。需要导出、对账或完整利润核算时，按当前可用入口和实际明细处理，不能只凭概况数字认定全部已完成。