客户扫码查询商品：序列号与商品信息核验｜云上订货系统
云上订货 · 更新于 2026-10-08
客户扫码查询先回答“手里这一件商品的串号，对应哪件商品和哪个规格”。客户核实物标签和手机结果，商家维护正确号码与商品规格关系，销售核需要验证时的原客户发货记录。普通查询、登录后的串号验证及提交记录分开检查，不能把一个成功图标当成整条履约和鉴定链路已经通过。
先明确适用对象和完成结果
客户从商家提供的实际手机商城入口进入“串号查询”，先确认当前商家，再扫描或输入本件实物的完整号码。查询针对原串号精确匹配，不是按商品名称搜索，也不是扫描任意包装码就直接进入正确商品。若包装上有商品条码、箱号、网址和单件串号，先确认哪一个才是本次使用的原号，避免把同箱所有商品都查成同一个结果。
结果页显示商品图片、商品名称、规格、规格编号以及标为IMEI的号码，客户逐项和实物对应。图片可能使用默认商品图，只能辅助识别，关键是本次返回的规格编号和号码。扫码页面打开、输入框出现号码、确定按钮点击及结果显示是不同节点，最后要确认结果中的号码确实等于本件原标签，不沿用上一件查询画面。
普通查询取得的是该商家有效号码所关联的有效商品规格资料，不以号码必须已出库作为查询成功条件。因此查到商品不证明货已经出库、已交付给当前客户，也不证明产品质量、真伪或售后资格。客户若需要核收货或串号验证，继续沿登录验证和原发货业务处理，不要求公开查询页显示其他客户、采购成本或全部仓库流向。
商家交付入口前先取两件不同原号核验，演示SN1001对应商品G100红色规格P01，SN1002对应蓝色规格P02。即使商品名称相同，也应分别返回正确规格编号和IMEI。再核不存在的演示号失败分支，避免所有码只跳同一商品介绍页。客户完成查询的标准是本件号码及资料对应正确，查询次数和客户验证情况不是本环节的完成条件。
图1：客户手机原号查询与商家有效号码来源分别核对，商品结果、登录验证和提交记录是不同层次。
准备资料并检查数据规则
商家先核企业商品序列号应用、当前商品管理条件及原号来源，确保号码与正确商品规格关联且资料有效。PC应用“商品序列号”的应用设置可配置“序列号查询提示”“查询成功提示”“查询失败提示”，三项必填、各不超过五十字符。提示写清如何输入原号和失败后的核查方向，不把成功文案写成该页面不能支持的鉴定、保修或发货承诺。
“新增商品默认是否开启商品序列号”影响新商品默认设置，不表示会为既有商品补齐所有号码，也不会把错误标签自动变成正确关联。已有原号录错时回商家序列号修正流程处理，真实换仓、退回或出入库则回对应业务单。客户查询页不承担补号码和改仓库工作，不能让客户随意换一个能查到的号码来证明本件商品正确。
准备单件完整串号，保留前导零、字母、符号和实际字符，核空格或扫码夹带的整段网址。输入框接收串号文本，不能承诺会从所有二维码网址中自动提取号码，也不能用商品条码或规格编号代替串号。输入值与原标签有差异时先重新辨认本件标签，不在错误商品结果中挑一个相似名称继续操作。
仅查询商品资料不需要先上传验证图片；登录后需要做串号验证时才准备本件验证图片及备注。验证页最多一张图片且提交前须有图片，备注最多五十字，说明与该原件相关的核对情况即可。客户先确认正确账号及真实收货关系，不替另一客户上传资料，不将无关订单、完整敏感联系方式或别件商品照片作为本号的验证依据。
图2：演示SN1001红色P01与SN1002蓝色P02，逐号核IMEI和规格，查询提示不作为真实结果证明。
按业务顺序完成操作
进入手机“串号查询”，阅读当前商家提示，点击扫描图标后按实际终端完成扫码。App使用原生扫描回调，普通网页返回的表现须核实际输入框，不能认为所有浏览器都具备同样相机能力或自动回填。扫描没有返回完整原号时可按实物标签手输，再逐字符核对；没有输入值不能继续把空白当成已经识别的号码。
输入正确原号后点“确定”，看到本次结果才核商品名称、规格、规格编号和IMEI；出现失败提示则回输入页检查，不把等待加载当成失败完成。查看一件后点“返回”，继续查下一件时主动替换输入框号码，输入框可能保留原值。演示换SN1002后须核结果IMEI也变为SN1002且规格为P02，不只看相同商品图片或成功提示。
登录客户需要验证时，在查询结果页使用“验证串号”。系统先检查是否已有有效正常验证记录，再检查当前客户与该原号有效出库发货客户及号码已出状态是否匹配。“该串号已验证”时回原记录，不重复提交；“验证客户和发货客户不匹配”时回正确客户账号与原发货数据核查，不通过借用其他客户账号或更换号码绕过提示。
允许继续才进入本次原号的“串号验证”页，上传一张对应实物的验证图片，填写必要备注后确认。验证页承接的是前一查询结果，直接打开缺少原号和商品资料的页面时先回查询，不靠手填猜出关联。确认后回已验证串号记录核原结果，页面返回或成功提示只代表这个提交节点有反馈，不能代替原记录与实物的一致性核验。
图3：App与普通网页回填分别核，输入后确定查询才取商品结果，登录验证另核提交及记录。
核对生效范围和后续结果
普通查询结果页的成功与失败提示由商家设置，真实商品结果仍按本次原号查询取得。不能只因为显示“查询成功”就推定已验证、首次扫码或从未被查询过。该页面没有把普通查询自动登记为客户验证的步骤，也不展示一份通用防伪查询次数历史；客户多次查看同号商品资料与重复提交验证是两种行为。
登录验证的“已验证”判断针对当前企业有效、正常状态的原号记录；发货客户匹配另核有效未作废出库关联和号码已出状态。演示客户甲收SN1001，客户乙即使能查到同号商品资料，也不能据此提交客户甲的验证。商品信息可查和客户验证可提交的条件不同，仓库人员调整出库记录后也须重新核原号真实状态及实际接收客户。
进入“已验证串号记录”核当前客户的正常记录，列表显示串号、商品名称、验证时间，可按串号或规格编号及验证时间范围筛选。提交后刷新第一页，确认这次原号及时间在合理范围内，再看后续页记录，不仅凭“暂无数据”就补交一次。查不到时核账号和筛选，加载没有完成或请求失败也不能当成原号没有记录。
记录画面若出现同号同时间重复行，先核它是否对应同一原验证记录，不按屏幕行数计算提交次数或判断冒用。商家核查使用原号、商品规格、客户发货关系、图片与验证时间接续，不把商品查询页变成批量改号或删除验证的入口。涉及售后或实际收货差异，保留原号和原订单，沿对应业务另行处理。
图4：成功商品、无数据、已验证和发货客户不匹配分流；验证提交后按原号和时间回查。
出现异常时逐层排查
扫码图标无响应、扫描页空白或返回输入框为空时，先区分实际使用的App与普通网页，核终端支持的扫码入口和本次扫描内容。不要把系统已有扫描图标当作当前设备一定获得相机权限，也不反复刷新猜测回填结果。能进入原查询页时按标签手输完整号码核验，仍无法查询再交商家检查入口和有效原号。
输入原号后无结果，先核当前商家、前导零、完整字符及扫码是否带入网址或无关空格，再由商家查有效号码、商品和规格关系。结果商品错误则同时保存本次输入、IMEI、规格编号和标签证据，换另一原号复查映射。图片相似或提示相同不能替代编号判断，不让客户用另一个“能查询”的号临时顶替。
没有验证按钮时先核是否已登录及当前界面节点；被提示已验证或客户不匹配时按原分支回查，不把它当普通商品查询失败。验证提交缺图片先补本件一张资料，备注超长则保留关键情况。提交中途断网或无明确反馈，先查原号正常验证记录和时间，再决定后续动作，不反复确认、换账号提交或要求商家删除原记录解锁。
验证记录为空时核当前客户、原关键词、时间范围、页码及加载状态，必要时重置合适筛选并刷新第一页。列表重复显示时查原记录身份与时间，客户反馈保留脱敏原号、规格、操作时段、终端和完整提示。商家排查后用同一原号及另一件号码分别回验商品结果，需要验证的再核原发货客户与提交结果，避免只恢复页面就宣布整条业务完成。
图5：无回填、原号无结果、规格错误、验证受限和记录缺失分别定位，未知反馈先查原记录。