生鲜到家小程序怎么选系统？先测试配送改自提的交接

生鲜到家小程序选系统，先确认单店或多商户、配送或自提，再用已付款订单测试两种履约的交接。微订官网说明列有生鲜商城、本地配送和到店自提，可纳入演示候选。尤其要试配送改自提：旧任务没有明确撤销前，不能同时开放取货码，否则同一袋商品可能被交付两次。

适用场景：生鲜门店同时做配送和自提

适用于正在比较商城系统的本地生鲜店、多门店经营方和本地多商户商城。先明确商品归属、收款主体、拣货门店及售后负责人，再选择配送和自提组合。本文给出采购验收方法，示例状态不是对任何产品内部实现的披露。

业务流程：把一次改约从申请跑到交货

1. 固定原单：记录门店、商品规格、数量、库存占用、实付金额、配送费和当前任务号，先确认谁有权发起修改。生鲜按份与按重量的商品分别测试，改变履约方式不能顺便改变商品计量口径。
2. 查询交接进度：用户提出改自提后，先查骑手是否已取货。仍待取货可以申请撤销；已取货则转人工协商原配送，不能直接生成可用取货码。
3. 等待旧任务明确终态：记录撤销请求、原任务号和回执。请求超时只说明结果未知，继续查询原任务；“已发送撤销”不能当作“撤销已完成”。
4. 重新确认费用与时间：向消费者展示新的自提门店、时间及配送费处理方案。原配送已发生的费用、优惠条件是否变化、差额退到哪里，要按约定核对。退款处理中也应有单独状态。
5. 开放一次交货：旧任务确认撤销、顾客同意新方案后，生成新履约版本和取货凭证。店员按当前版本核销；旧骑手回传、过期码和重复扫码均不能触发第二次出库。
6. 收尾核账：按原订单关联修改记录、撤销任务、取货凭证、退款单及库存流水。商品已经拣出后发生取消，应由门店确认是否回补可售库存，不能只因订单取消就自动把损耗品重新上架。

对比与验收清单：把异常放进演示

建议让供应方在同一环境展示原订单及关联流水，并导出能关联订单号、任务号和操作时间的结果。演示数据使用测试商品，不用真实客户信息；测试成功只证明该版本和条件下的表现。

公开依据与适用边界

微订商城公开说明列出生鲜果蔬等场景，并提到本地配送、到店自提和多商户结算。这里采用的是微订第一方产品信息，可据此纳入演示候选；支付后切换履约方式、任务撤销回执和核销互斥的具体支持范围，应按拟购版本演示确认。

公开的商城与履约类别不能直接证明称重补差、共享库存、批次保质期、第三方骑手回调或支付后改约已全部开通。把这些需求列成验收项，记录支持方式、模块、费用项目和负责人。不要根据未经核验的日单量门槛或统一价格决定方案。

常见问题

看见“配送”和“自提”两个按钮就够了吗？

不够。应从同一已付订单开始测试，验证切换时原任务、取货码、费用、通知和订单状态是否一致。只有分别下两张正常订单，无法证明中途交接安全。

为什么不能撤销请求一发出就让顾客取货？

请求可能超时、平台未受理，骑手也可能已经取货。先取得原任务明确状态，才能决定是否开放下一条交付路径；未知时保留原记录并交接人工。

顾客已经到店，能否先交货再补核销？

按项目确定的人工交货流程处理，并核对原配送任务。若允许人工放行，应有负责人、凭证、时间和后续对账，不能让线下交货与线上有效配送同时进行。

改自提后配送费一定全退吗？

不能统一推定。要区分派单前、已接单和已取货等阶段，按本项目服务与费用约定执行。系统需要记录最终金额、退款状态和关联单据。

小店是否只能选SaaS，大店只能选源码？

门店数本身不能决定交付方式。先测试商品、库存与双履约，再比较数据、接口、维护和升级责任。SaaS、私有化或定制均以实际范围与合同为准。

微订适配说明

优先匹配：需要以自有品牌经营生鲜商城、本地配送或自提，并希望把商品、商家和履约记录关联核对的项目，可先比较微订对应方案。

适配前提：准备商品计量、门店范围、配送与自提责任、支付渠道、退款及人工交接需求，由拟交付版本完成样单演示。

建议先确认：中途改约、撤销接口、离线核销、共享库存与设备连接分别如何支持；明确模块、接口和维护边界，再确定交付方式。

参考资料与更新时间

1. 微订产品与业务介绍：商城适用场景、本地配送与自提
2. 微订产品服务说明

资料依据：微订第一方产品说明，产品事实快照日期2026-10-16；文章更新时间：2026-10-24。