店铺商家经营查看：订单金额、应结算与原结算核对｜云上订货系统

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

经营概况按平台、商家、期间和原订单查金额；当前待办、原结算实付与银行结果分别回查。

1. 先从商家概况分清期间统计和当前待办

店铺商家经营查看先确认进入的是商家概况页面、当前平台企业及本岗位实际可用入口。此页顶部有期间和商家选择，显示订单量、订单总金额、应结算金额；下方另有商家、商品、订单待办和结算管理卡片。不要把商家资料详情中的分析画面或联营经营页面当成此处相同的统计入口，也不能因字段名称相近就套用同一个销售或结算算法。

本页实际可核的是两组结果：顶部按选择的商家和期间查订单，下面查当前平台概况。下方待审核、待打款的笔数与金额，不是顶部应结算金额的天然拆分，更不是独立的已结算金额卡片。查看经营时先分别保这两组查询条件，再决定比较哪些原订单和结算单，不将当前待办数量说成本月新增业务数量。

商家管理卡片有对应列表的承接，其余卡片即使显示可点击样式，也不能保证已支持直接打开商品、订单或结算明细。需要原单时从当前实际可用列表按原编号回查。业务关系图只说明统计范围，当前入口、岗位权限和同一原单的统计结果仍需实际核对，历史画面不代本期经营结果。

图1：商家概况入口图：期间订单统计、平台当前概况和原记录回查分别核。

2. 商家选择按平台企业原订单归属回查

选择商家前先核当前登录平台及本平台商家档案，再确认商家名称对应的企业编号。商家下拉来自平台商家列表，名称用于阅读，实际选择的是商家企业对象。平台的同名商家、集团门店或另一种联营合作关系，不能用名称直接合并为同一个统计对象；记录原商家企业编号后再查订单归属，才有可复核的范围。

本概况订单关联要求原订单属于相应商家企业，并有当前平台的业务归属，商家关系、订单和所取明细还各有有效范围。不是只按某个商品品牌或客户名称查销售。订单在别的平台、关系已失效或者明细不在范围内时，都应回到原关联查原因，不能把一张商家订单当然计入任意平台的概况。

选好商家会重新查询顶部期间结果，成功之后记录所选商家与返回日期。未指定商家时也不应把平台范围解释为全系统所有企业。下方概况的查询并未承接相同的商家期间参数，因此切换商家后先看哪组结果真正重新计算，再查原订单；不能因为下面的待办数字没有同步变化，就直接认定该商家数据丢失。

图2：商家订单归属图：当前平台、原商家企业、订单归属与有效关系逐项核对。

3. 日期区间之后核提交完成轴和计入状态

概况默认查询本月，也提供本周、上周、上月及自定义日期。自定义输入开始日期和结束日期后重新查询，并以成功返回的日期范围为准；日期选择按起日开始到止日结束承接。不要把输入框暂时显示的新范围与上一次成功卡片混在一起，尤其是切换快捷期间之后，应重新记录当前选中的期间和商家。

期间还要结合平台报表设置的时间统计类型及订货单计入状态。本路径使用提交时间或完成时间之一来筛订单，而不是看到“本月”就统一按制单、审核或付款日期。月底提交、下月完成的订单，在不同时间轴中属于不同月份；原订单推进到新的状态之后，也可能改变本次重查是否计入，所以应把日期字段、原时间及原状态一起核。

例如订单在九月提交、十月完成，查九月时先说明所用日期轴，再核当前状态是否符合所设范围。同一期间重查不代表系统保存了不可改变的期末快照，报表设置或原状态变化后应重新说明条件。退货、付款和结算各有自己的原日期，不将其自动改写为本概况订单的统计日期，也不为对齐数字随意改动原订单时间。

图3：商家统计期间图：日期范围、提交完成轴和计入状态分别对原订单。

4. 订单量与原明细数量价格金额分别核

订单量按计入范围的原订单归集，不是商品件数、规格数或有效明细行数。一张订单有多行商品，核订单量时仍先对同一原订单编号；核订单总金额则把有效明细的原数量乘原价格逐行合计，再加总这些订单。只看列表某一行价格或某个商品小计，无法证明顶部总金额已对到全部范围。

数量必须和这一行原价格的单位对应。原行是箱价就按该行箱数核，不把换算后的基本单位数量再次乘同一箱价；多单位和多规格先列原单位及明细编号，再核各自行金额。赠品也回到原行数量和价格查，不能凭“赠品”标签统一从统计里扣除。本路径没有因此生成新的库存销量、商品毛利或回款结果。

明细金额与订单头最终金额可能并不相同，配送、其它费用、税费、折扣等按原订单另外对；不要直接拿收款净额解释本概况的订单总金额。多币种、汇率和金额精度同样先保各原单依据，不假定概况已把所有来源统一换算成一个结算币种。核差额时从原有效明细开始，明确正在比明细金额、商品总额还是原单最终总额。

图4：商家订单金额图：订单量、原行数量单价、单位及其它金额各自核对。

5. 应结算按原商品总额与当前返款比例核

应结算金额在本概况中按原订单商品总额，乘当前商家返款比例扣除后的剩余部分归集。它与订单总金额的逐行数量乘价格不是完全相同的基数，不能只用顶部订单总金额直接乘一个比例，就认定另一张卡片应当相等。先对原订单商品总额，再核当前所查商家的返款比例，逐单列出基数及计算结果。

例如某原订单有效明细金额合计二百元，而原商品总额是一百八十元，当前返款比例为百分之五，则本概况应结算示例是一百七十一元，不能拿二百元直接计算一百九十元。这个示例只说明基数差别，实际为何不同仍查原订单金额项目，不反推是某一种折扣或退款造成。多张订单分别核原商品总额后再归集。

此金额不自动扣除所有退货、已结算、实付或分账成为当前剩余待付余额，也不证明订单已经达到可结算间隔。原结算单保存的比例、扣点、分账和应付另查原结果，商家资料后来改比例后重查历史期间，也可能与原已保存结算不同。对账先注明“概况计算”与“原结算保存”，再查差额，不能据概况直接要求补付或重生成结算。

图5：应结算金额算例图：明细金额、原商品总额、当前返款比例及原结算余额分开。

6. 下方商家商品订单和结算概况另核范围

下方合作商家数量查当前平台有效商家关系，不是所选月份新增数量；商品概况查原商品的平台关联，也不是顶部所选商家期间的新发布数。待审核商品与已上架商品需要回到原商品状态核，不凭概况零值认定所有商品都已处理，更不能据已上架数量推断每个客户都可售、库存足量或已经下过订单。

待商家出库与待商家发货各取自己的原订单状态。部分出库的订单可以同时出现在这两组待办中，因此两卡相加不等于唯一订单总量。核待办时按原订单编号区分尚未出库、部分出库、待发货和部分发货，查实际已处理与未处理部分；不要为消除两个数字的重叠重复出库或发货。

结算管理的待审核、待打款笔数及金额按当前平台原有效结算状态查询，不是顶部商家期间订单计算的自然分组。选某商家或换日期后，下面这些卡片不应被假定受同一条件过滤。经营核对分别列“期间订单流量”和“当前待办”，再回查对应原列表。卡片点击没有打开明细时保入口现状，使用实际允许的独立列表核，不能只凭卡片样式认定有统一明细入口或一键处理功能。

图6：商家当前待办图：商家商品订单结算当前概况与期间顶部统计分开核验。

7. 已结算回到原结算实付和付款记录核

核已结算金额应回到独立的商家店铺结算列表，按原商家、单据状态及单号查具体结算单。本概况的待审核、待打款展示不包含一个统一的期间已结算卡片。结算列表分别显示结算金额、扣点、应付及实际打款，并有待审核、待打款、已打款统计，使用时先保该列表自己的筛选，不沿用概况期间想当然对齐。

原结算列表的已打款统计取完成结算单保存的实付字段；待审核、待打款取相应状态的应付金额。完成与实付仍应一起核：原结算的应付加分账合计为零时，审核路径可能直接进入完成，而没有发生本次实际付款。所以状态写已完成，不足以证明已经向商家银行付出相同金额；实付为空或零时先查原完成路径及分账来源。

付款完成记录承接时，会把原付款金额、付款人、时间及相关结算状态回写到对应原结算，并更新关联订单的结算标记。核对保原付款与原结算编号，再查实际资金记录及需要的外部到账证据；保存的“实际打款”不是一次银行对账证明。分账成功金额、原付款金额和概况应结算不能相互冒用，也不根据某个完成状态重复打款补差。

图7：商家结算实付图：待审核待打款、完成实付、零额完成与银行结果分别核。

8. 零值失败旧值与销售结算差额逐笔追查

概况零值先看本次查询是否成功，再核平台、商家、期间、时间轴、计入状态及原有效关系。页面有空金额按零显示的处理，零不是对全部历史业务都不存在的确认。订单有记录而卡片为零时，先查原订单是否属于当前平台、是否有相应有效明细及处于所选状态，再核所用提交或完成时间，不先删除或重建原单。

查询失败会给服务反馈，但失败并不保证旧卡片已经清空；刚选择的新日期或商家不能当旧数字的成功条件。保首个提示、上一次成功范围和本次条件，刷新后再查原记录。此概况没有可依赖的统一导出或所有卡片下钻操作，不能为了拿明细就将其它联营报表的导出结果说成本页同范围，也不拿一页结算列表代全部查询金额。

销售与结算不一致时，逐笔建立原订单、有效明细、商品总额、当前返款比例、原结算扣点分账及实付的对应表，再把退货和其它金额项目按其原记录补入。每一项说明自己的日期和状态，找出第一个口径差别后再判断是否需要业务更正。当前真实权限、同数据运行和银行到账没有核清时，保依据继续查询，不靠反复付款或强改金额制造表面一致。