区县创业者搭建同城配送系统,先写清服务范围、业务组合和团队条件,再选择标准SaaS、私有化部署、源码安装或个性化开发;随后用用户、商家或寄件方、骑手、平台后台四端跑通下单、接单、抢派单、退款、提现和转单,最后用真实订单验收。首期订单有限时,先用轻量方案跑通核心链路,再评估升级。
同城配送不一定从多商户外卖开始。外卖围绕商户商品、出餐和取餐组织;同城配送还可能包含帮买、帮送、帮取、代取快递等任务。首期只做纯跑腿,商家端可以简化;做外卖加跑腿,则要提前判断用户入口、骑手和结算是否共用。
业务组合 | 核心对象 | 首期关键字段 | 常见异常 |
|---|---|---|---|
纯跑腿 | 寄件人、收件人 | 取送地址、物品说明、时限、费用 | 无人接单、地址错误、联系不上 |
外卖加跑腿 | 商户、商品、骑手、寄件人 | 店铺、商品、出餐、配送、结算 | 缺货、退款、转单、超范围 |
业务边界写清后,系统选型才有比较基准。纯跑腿重点看取送地址、物品说明、时限和计费;外卖加跑腿还要看店铺、商品、出餐、配送和商家结算。把两类订单各下一笔,比只看功能菜单更容易发现字段和流程差异。
交付方式可按标准SaaS、私有化部署、源码安装和个性化开发比较,判断依据包括团队、数据要求和预算。首期无专职运维时,先用标准产品验证订单、退款和结算;有自有环境或长期改造需求,再评估私有化、源码或定制。
交付方式 | 适用条件 | 首轮核对 | 运维边界 |
|---|---|---|---|
标准SaaS | 首期验证、无专职运维 | 版本范围、数据导出、服务响应 | 服务方承担约定维护 |
私有化部署 | 有自有环境或数据管理要求 | 备份、监控、升级、恢复演练 | 客户或受托团队运维 |
源码安装 | 有开发团队、需要长期改造 | 许可、文档、升级路径、安全维护 | 客户团队负责 |
个性化开发 | 标准流程覆盖不了 | 范围、阶段成果、测试与验收 | 按合同约定 |
比较交付方式时,把版本范围、终端入口、数据导出、升级维护和售后责任列进同一张表。合同里写清已含项与另计项,后续扩容和故障处理才有依据。
系统至少组织用户端、商家或寄件端、骑手端、平台后台四类角色。用户下单支付,商家接单出餐,骑手抢单或接派单取送,平台查看订单、抽成和结算。状态机应固定主链路,把取消、退款、转单作为旁路保留记录。
状态迁移 | 关键校验 | 异常记录 |
|---|---|---|
待支付→已支付 | 支付回调、配送范围、库存 | 重复回调、超时未支付 |
已支付→商家接单 | 接单超时、拒单原因 | 商家未接单、商品售罄 |
商家接单→备餐→待取餐 | 出餐时间、打印成功 | 打印机离线、重复出票 |
待取餐→配送中 | 骑手取餐确认、拍照留证 | 取错餐、骑手迟到 |
配送中→已送达 | 送达确认、收件人反馈 | 地址变更、联系不上 |
任意状态→退款或取消 | 退款金额、优惠冲回 | 结算后退款、重复退款 |
订单、支付、配送任务和结算单通过订单号关联。退款用独立调整记录冲回,避免直接修改原订单金额;转单保留原骑手、接手人、时间点和收益归属。
-- 设计示例:通用关系模型,字段按项目裁剪
CREATE TABLE delivery_order (
order_no VARCHAR(32) PRIMARY KEY,
biz_type VARCHAR(16) NOT NULL,
status VARCHAR(24) NOT NULL,
user_paid_cent INT NOT NULL,
delivery_fee_cent INT NOT NULL,
merchant_id BIGINT NULL
);
CREATE TABLE order_event (
event_id BIGINT PRIMARY KEY,
order_no VARCHAR(32) NOT NULL,
event_type VARCHAR(32) NOT NULL,
operator_id VARCHAR(64) NOT NULL,
created_at TIMESTAMP NOT NULL
);
CREATE TABLE refund_adjustment (
refund_no VARCHAR(32) PRIMARY KEY,
order_no VARCHAR(32) NOT NULL,
refund_cent INT NOT NULL,
status VARCHAR(16) NOT NULL,
UNIQUE (order_no, refund_no)
);上述代码是设计示例,不是任何现成系统的内部实现。上线前用测试库执行建表、写入一笔正常单和一笔部分退款,检查订单状态、事件记录和退款调整能否按订单号对应。
派单不要只看有没有抢单按钮。先按配送范围、营业状态、骑手在线与负载过滤,再看取餐距离和顺路方向;没有候选骑手时进入人工调度池,记录失败原因和重试次数。抢单适合平峰补充运力,派单适合高峰稳定履约,两种方式可以并存。
候选骑手 = 在线 且 未超载 且 在服务区
按 取餐距离、顺路方向、当前负载 排序
若无候选:进入人工调度池,记录失败原因与重试次数
转单:记录原骑手、接手人、责任时间点、收益归属计价至少拆成起步价、距离费、重量或件数加价、夜间或偏远加价。超范围地址要在下单、计费和派单三个环节分别校验,避免用户能下单但骑手无法接。异常单要有接手人,状态和金额变化要留痕。
结算不要只看能不能提现。先把用户实付、商品与包装、配送费、平台抽成、商家应结、骑手收入、优惠承担和退款冲回列成金额表,再用正常单、部分退款和提现核对账单。分账是产品能力,实际开通受支付通道、经营主体、版本配置和合同约束。
金额项 | 核对内容 | 记录方式 |
|---|---|---|
用户实付 | 商品、包装、配送费、优惠 | 订单支付记录 |
平台抽成 | 计费基数、比例或规则 | 抽成设置与账单 |
商家应结 | 商品收入减优惠承担、服务费 | 商家账单与提现记录 |
骑手收入 | 配送费、补贴、转单费用 | 骑手收益与提现记录 |
退款冲回 | 部分退款、整单退款、结算后退款 | 退款流水与调整记录 |
验收用五类订单:正常配送、部分退款、商家或骑手提现、超范围地址、骑手转单。每类记录订单号、业务类型、角色账号、状态时间点、金额变化、通知结果和责任人,异常单要能找到接手人。
验收单 | 操作 | 记录重点 |
|---|---|---|
正常配送 | 下单支付、接单出餐、骑手取送 | 状态、配送费、商家应结、骑手收入 |
部分退款 | 配送前取消或部分商品退款 | 退款金额、优惠承担、账单调整 |
提现 | 商家或骑手申请提现 | 可提现余额、审批状态、到账记录 |
超范围地址 | 填写服务边界外地址 | 下单提示、计费与派单结果 |
骑手转单 | 模拟骑手异常转单 | 原骑手、接手人、时间点、收益归属 |
上线前还要核对账号权限、数据导出、通知渠道和日志留存。权限按客服、财务、调度、商家和骑手分岗设置;导出字段与备份方式写入交付清单。把这些记录和五类订单放在同一份验收表里,团队才能判断系统能否进入日常经营。
问:区县创业一定要定制开发吗?
不一定。首期订单有限、没有专职运维时,可先用标准产品跑通下单、接单、配送和结算;有自有环境或长期改造需求,再评估私有化、源码或定制。
问:外卖和同城配送有什么区别?
外卖围绕商户商品和出餐;同城配送还可能包含帮买、帮送、帮取、代取快递等任务。业务组合不同,用户入口、骑手和结算是否共用要分别核对。
问:有分账功能就等于资金合规吗?
不等于。分账是产品能力,实际开通受支付通道、经营主体、版本配置和合同约束,资金合规需向支付机构和主管部门核实。
问:上线前最少测什么?
正常配送、部分退款、提现、超范围地址和骑手转单五类订单,记录状态、金额、通知和责任人。
作者:微订(上海逊柯计算机科技有限公司)。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。