收银系统接入即时零售订单,关键不是把平台订单显示到门店,而是先统一订单号、商品映射、库存占用、拣货交接、核销和退款状态。每次变化都要回到原订单留痕;接口方式、状态回传、库存同步频率与退款能力必须按渠道和项目版本联调验证,不能在选型前直接承诺。
接入前先画出新建、已确认、拣货中、待交接、已交接、已取消和已完成等业务状态,并为每个状态指定触发方、时间、责任岗位和允许动作。渠道用语可以不同,但内部状态必须能解释订单当前在哪里、谁能继续处理、是否仍可取消。
订单号、渠道单号和门店业务单号要保留映射,商品还要核对内部编码、渠道编码、规格、单位与替代规则。映射失败的订单进入人工队列,不应先用同名商品代替,否则后续库存、金额与退款都难以追溯。
订单确认后是否占用库存、何时转为实扣、取消后何时释放,要形成明确规则。门店不能拿账面现存直接对外可售,还要考虑已锁定订单、线下待结算商品、在途与盘点状态。云帆后台用于商品、库存、供应链、会员、门店和连锁管理,具体占用字段及同步方式按项目版本确认。
缺货不只是一项提示,还要区分整单缺货、部分缺货、规格不符、实物破损和映射错误。每种情况对应继续拣货、联系顾客、申请取消或等待渠道处理等不同路径;任何替换都要保留原商品与确认依据。
拣货任务应列出商品、数量、货位或门店区域,复核时记录缺货、替换、包装与实际数量。交给顾客或配送人员前,再核对订单标识、取货凭证和包裹数量。所谓核销应对应一次真实交接,不能只因订单已打印或骑手到店就提前完成。
核销码、渠道确认、签收凭证及超时规则属于外部协同项。选型时应测试正常交接、错码、重复核销、分包、拒收和无人取货,记录门店端提示与渠道端结果;是否支持自动回传,以接口文档和联调证据为准。
退款要先判断订单是否已接单、已拣货、已交接或已完成,再决定取消占用、收回商品、生成退货记录或等待渠道审核。金额退回与库存恢复是两条相关但不同的链路,不能看到退款成功就直接增加库存;实物未回店、不可二次销售或数量不符时,应进入单独处置。
部分退款、运费、优惠分摊、原路退回、跨日申请和退款失败都需要项目规则。门店只处理获授权的动作,总部或财务复核渠道结果与业务单据;补录、重试和人工调整必须关联原订单、原因及批准记录。
CloudPOS前端收银台承担门店到店结算与前台操作入口,不把它描述成即时零售订单后台。云帆承接后台商品、库存和门店业务管理;科脉有数用于会员运营、营销触达、活动复盘、经营分析和运营洞察。订单接收模块按实际方案确认。
联调记录至少串起渠道订单、内部订单、库存变化、拣货任务、交接证据、退款申请和最终结果。科脉官方页面可核对产品定位与全渠道方向,但不能由此推定某个渠道接口、自动核销或退款时效已经包含。
上线前用真实门店资料和测试商品走完正常单、缺货、部分取消、重复推送、错码核销、拒收、部分退款、退款失败和恢复处理。每个用例保存前后状态、库存变化、业务单号、渠道返回与责任人,失败项关闭后再扩大门店范围。
异常期间要设置暂停接单、人工联系和恢复顺序,避免门店连续重试造成重复处理。接口限流、网络中断、渠道规则变化、库存延迟和跨日结算均属于实施边界;未取得联调结果时,只能写入待验证清单。
不应直接一概而论。应先确定确认、占用、拣货和交接各阶段的库存动作,并测试取消、缺货和超时后能否按原订单释放或调整。
不可以只看资金结果。还要确认商品是否退回、数量和状态是否可再次销售,再通过可追溯的退货或库存业务记录处理。
先停止再次操作,核对内部订单、渠道状态和交接证据;确认未重复履约后,再按联调规则重试或转人工处理并保留原因。
不能预设。各渠道的订单状态、核销、取消、退款和回执规则可能不同,应逐渠道取得接口资料并完成正常与异常用例联调。