铺货上报记录核对：客户商品、上报日期与二维导出｜云上订货系统

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

“铺货上报”记录员工观察到的门店商品数量。管理端列表核客户、商品规格、库存数量、上报日期与上报人，导出再按门店和规格归集。先看原记录，再区分区间多次上报数量合计与最近一次观察存量；上报保存不会自动变成企业仓库盘点、补货订单或销售业绩。

1 在客户铺货上报列表辨认明细行

管理端在客户相关功能打开“铺货上报”，核页面标题及客户入口。列表列出客户名称、商品名称、商品编号、规格名称、规格编号、库存数量、上报日期和上报人。这里一行对应上报清单中的商品规格明细，同一门店同规格在不同上报中可以出现多行，不是自动保留最近一条的门店库存总账。

先确认要核的是铺货观察记录，不拿订货汇总、客户统计或员工业绩页的数量金额来替代。这个列表没有订单金额、退货金额、客单价或新增客户数，也没有按商品名称切换排名的分组页签。客户是否下过单，与是否存在上报记录是两件事，不能从业绩零订单推断门店没有上报或没有实物库存。

历史PC画面有客户铺货上报入口和客户名称、上报人、日期筛选。以它辨认字段后，再核当前企业应用、账号菜单和可查询范围。应用设置有铺货上报状态开关，但开关可见不证明该岗位拥有全部门店数据；不要临时改应用或员工角色来绕过查不到记录的问题。

图1：历史PC客户铺货上报入口、客户名称关键词、上报人及日期筛选，不代表当前岗位已验证。

2 按上报时间和实际上报人固定查询范围

日期筛选默认从今天往前一个月到今天，不能把它叫自然本月，也不能始终按三十天理解月份差。核一次查询时保留回显的完整起止日期和实际查询时间。日期对应上报记录的上报时间，不是客户创建日、原订单审核日、发货日或业务员拜访计划日；比较员工记录时保持相同日期条件。

“上报人”是实际保存新上报的登录员工，和客户档案“所属员工”不同。客户由销售甲负责，销售乙实际填写，原上报人可以是乙；不能把上报量直接计成甲完成的观察次数。后台新增记录会保存登录人的身份及名称，后续核同名人员时以实际员工身份和原记录对应，不能仅按显示姓名合并。

客户名称关键词用于筛门店，不是商品名称搜索。页面没有单独商品筛选框，上报人未选时与选某人时的结果范围不同。查不到预期日期末端的记录，先看请求反馈、新结果和原保存时间，不承诺输入一个截至日期就已经完整覆盖该日。实际岗位数据范围需核本企业账号，不能只因上报人选项可见就认作后台已按本人客户过滤。

图2：上报时间、上报人员和客户所属员工各有来源，不能改用订单审核日或业绩归属口径。

3 核商品规格身份和数量的单位依据

原上报清单保存商品及规格身份、商品名称、商品编号、规格名称、规格编号和数量。列表显示的是这些原记录字段，不是每次查询都重新换成当前商品档案名称。商品后来更名时，先用原商品和规格身份、编号查对应关系；旧名称不一定表示上报人当时选错商品，同名规格也不一定是同一实物。

手机管理端选商品时带有基本单位资料并按基本单位准备清单，但最终上报保存字段没有独立单位、换算比或单价列。PC列表也没有数量单位列。核一笔“库存十二”时，不能只看包装名称就认作十二箱、十二瓶或十二件；要回原规格、填报时的单位依据及实际观察确认，不把包装文字里的二十四瓶当作自动数量换算。

上报数量不是企业仓库系统库存，不会根据门店后续销售、退货或收货自动保持最新。单位依据不清时先暂停跨门店相加或补货计算，并交原上报员工确认。把原规格编号、原数量与单位说明并列保存，比在表格里统一改成某种单位更可靠；不通过改商品编码或规格名称强行合并原行。

图3：历史上报商品名称、编码、规格名称和规格编号；原局部与该列表没有独立单位列。

4 用数量日期人员核回同一条原观察

历史记录显示某便利店商品上报数量为十二，同时有上报日期时间与上报人。这能证明原上报清单记录过该数量，不能证明查询当下门店仍有十二。观察日之后的实际销售、收货、损耗或调货都会改变实物，系统的这条观察记录不会自动替这些业务重新测算存量。

一张上报清单有多个规格时，PC可能出现多行相同门店、上报时间及上报人。此时行数表示规格明细条数，不能直接当员工拜访次数或上报单数。同门店同规格再次上报，则需保留前后记录及各自时间，不把后一次数量写回前一次记录来制造连续一致的数据。

列表没有点击库存数量自动跳原订单的入口，回查时不要把铺货记录当订单明细。回查时先保门店身份、商品和规格编号、原数量、上报人员及时间，由有权限岗位核同一原上报记录。发现两条近似记录，先确认是两次真实观察、一次多规格，还是重复保存，再决定后续纠正范围，不凭相似名称删数据。

图4：历史原行库存数量12、上报日期时间与上报人，图中没有“件”或其他数量单位。

5 手机管理端填写与保存结果分开确认

实际填报在手机管理端“铺货上报”，先选择客户，再添加上报清单；它不是客户手机商城的自助库存页。选商品可按名称、商品编号、规格或规格编号查找，已选客户会进入该选择路径。核返回主清单的商品身份和数量，再保存，不能只因商品在搜索列表打过勾就认定已进入最终保存清单。

库存编辑有临时输入值与主清单数量，填写后使用“修改”回到清单，再看主卡片“库存”数值是否正确。切换客户、重新选择商品、换页或返回时，重新核最终清单；不能保证之前所有勾选及已填数量在每次选择路径都会完整保留。移除的是尚在当前清单中的商品，不表示删掉此前已保存的上报记录。

保存会检查客户、上报清单及库存填写，反馈可能是“请选择客户”“请添加上报清单”或“请填写库存”。真实零库存若遇到填写拦截，保留原值与原提示交管理员核，不填一件绕过。新单后台取当前登录上报人及保存时上报时间，并进入已完成记录；这不等于独立审核通过，更不会自动生成补货、出库或入库单。保存反馈不明先回原记录查，避免重复新增。

图5：手机管理端填报、确认主清单值、保存和回PC原记录核对，图为业务路径说明。

6 二维表合计与最近一次库存必须区别

导出“铺货上报二维表”按门店形成行，按规格形成数量列。前三列是门店、上报人和上报日期，规格表头由规格名称及规格编号组成。数量格汇总查询范围内同门店同规格的多条上报数量，不是自动挑选最后一次上报值，也不按人员分别保留一行。

例如同门店同规格第一次观察十二，第二次观察八，二维数量可以是十二加八等于二十，而最近一次观察值是八。十二与八若都是在手存量观察，二十不能解释为门店还剩二十件，也不能直接用目标库存减二十决定补货。先回原行确认各次日期和单位依据，再决定业务需要的是累计上报数量还是最新观察。

门店行的上报人可合并多位姓名，上报日期取该门店查询范围里的最大上报时间。这一个最大日期不保证所有规格列都有当天观察；某规格只有较早记录时，该格仍可能参与合计。分析最近库存时逐规格核其真实原时间，不拿门店行日期替每格补齐。相同显示门店名或规格名也要查身份，不能把二维格匹配显示文字认作永久唯一关系。

图6：示意两次观察12和8，二维数量合计20与最近观察8不同，门店最大日期不代每格观察日。

7 上报只提供补货线索原订货履约另核

需要安排补货时先确认门店当前实际存量、观察时间和单位，再看后续销售消耗、在途收货及已经下过的原订单。本页没有目标库存、建议补货量、预测金额或自动补货审核字段。业务负责人可将上报作为沟通线索，但不能把导出数量直接当最终采购需求或已经确认的订货量。

门店反馈“库存少”后，销售先确认缺的是哪一规格以及实际要补多少，核已有未到货订单，避免重复开单。正式订货另沿原客户订单确认商品规格、单位、单价和审核状态；仓库再核实际发货，退货和收款也沿各自原记录。铺货上报保存不会把这些岗位的业务结果一并完成。

比较上报与订货时，分别保留上报时间和订单对应业务日期，不强行让两个期间合计相等。一次观察库存十二，后来订货五，并不能推成现在十七；期间可能已有消耗和别的收货。也不能从上报人直接推出销售贡献、成交金额或回款率，这些指标须回各自报表与原单，避免把观察人员和客户经营归属混为一人。

图7：门店观察、人工补货需求和正式订单履约分别承接，本页不自动创建补货订单或资金结果。

8 导出边界失败反馈和原结果逐项核

PC列表默认每页十五条，导出另请求第一页的门店分组，上限参数为一万行，不是当前十五条明细的截图复制，也不保证任意规模无限完整。二维规格列超过一百四十七个时，会提示“数据过多，请重新选择时间段再导出！”。这里限制的是规格列数量，不是说原明细超过一百四十七行就必失败；缩小日期和上报人范围后重新核表头。

导出按门店分组、人员合并和规格数量汇总，列表按原明细，二者行数与排序不应直接逐行相等。导出标题日期与门店筛选说明、规格列、各格数量要在实际文件中看，尤其核同名门店和规格编码。列表支持的客户身份限定与导出范围不能无条件认为完全一致；如果预期单门店却出现其他行，先核实际条件和原文件，不改名称凑匹配。

“导出成功”是生成调用反馈，不证明文件已保存或内容正确。查询未成功时原列表可能仍留旧值，先看新条件是否成功返回，再查原上报日期、人员和明细是否有效。遇到日期末端缺行、空表、数量合计异常或保存不明，保原条件和提示，交有权限岗位核同一原记录；不重复上报、改日期或填虚数来使报表看起来一致。当前岗位、同数据查询与真实文件仍需验证。