帮买帮送跑腿系统怎么选？购后取消的垫付款约束设计

有本地骑手、没有开发人员，独立做帮买帮送，可以把微订等已有跑腿系统列入演示候选，再用具体订单核对能力。本文聚焦选型中的一个工程问题：购后取消时，怎样避免把已发生的骑手垫付款随订单一起删除。提供的是通用数据约束设计，不是产品内部实现，也未执行数据库测试。

把业务含义拆开

微订官网产品与业务全景介绍跑腿系统覆盖帮买、帮送、帮取，可设置骑手、派单、区域、计费与收益结算。这是第一方产品范围说明，不能替代某个版本的垫付核对演示。采购者需要检查实际端口、权限及人工处理方式。

帮买包含采购和运输。预算是购买授权，采购凭证是支出事实，服务费是履约报酬；取消是履约变更。已经买到的商品能否退回，以及应还骑手款如何处理，要根据实际交易与约定确认，不能用一条状态删除覆盖所有含义。

下面选用PostgreSQL风格模型。金额用最小货币单位整数，receipt_key在订单内唯一，凭证绑定订单及付款骑手。这里假定同一订单由一位骑手采购；换人采购必须先创建明确的新责任记录，不能直接覆盖旧凭证。示例中一笔凭证不能拆给多个骑手。

CREATE TABLE errand_order (
  id text PRIMARY KEY,
  purchaser text NOT NULL,
  state text NOT NULL CHECK (state IN ('active','cancel_requested','cancelled','delivered')),
  revision integer NOT NULL CHECK (revision > 0),
  UNIQUE(id,purchaser)
);
CREATE TABLE purchase_proof (
  order_id text NOT NULL,
  receipt_key text NOT NULL,
  purchaser text NOT NULL,
  actual_cents bigint NOT NULL CHECK (actual_cents > 0),
  evidence_ref text NOT NULL,
  PRIMARY KEY(order_id,receipt_key),
  FOREIGN KEY(order_id,purchaser) REFERENCES errand_order(id,purchaser)
);
CREATE TABLE money_decision (
  order_id text NOT NULL,
  receipt_key text NOT NULL,
  revision integer NOT NULL CHECK (revision > 0),
  return_state text NOT NULL CHECK (return_state IN ('unknown','not_returned','returned')),
  repay_cents bigint NOT NULL CHECK (repay_cents >= 0),
  reason text NOT NULL,
  PRIMARY KEY(order_id,receipt_key,revision),
  FOREIGN KEY(order_id,receipt_key) REFERENCES purchase_proof(order_id,receipt_key)
);

purchase_proof保存发生过的采购，money_decision保存后续核对决定。限制普通角色更新或删除凭证；更正采用有原因的新记录。上面DDL只建立关联与金额约束，不代表已经实现权限、总额上限和所有业务不变量。repay_cents不得大于该凭证未偿还金额，还需要在锁定凭证的事务内核对，或用数据库过程统一写入，不能只靠前端校验。

状态转换和取消事务

active可以进入cancel_requested或delivered。cancel_requested由授权操作人核对采购、退货与费用后进入cancelled；不满足条件时回到active并记录原因。cancelled和delivered都不能由迟到请求直接恢复active；争议单走单独复核流程。每次状态变更增加revision，旧页面操作要返回版本冲突，而不是覆盖新状态。

取消事务先锁定目标订单，读取当前状态与revision，核对取消请求的预期版本。随后查询该订单采购凭证及已有money_decision，记录核对结果并变更履约状态。普通凭证上传同样先锁该订单，从而确定它发生在取消核对之前还是之后。处于cancel_requested或cancelled时，新凭证进入待核入口；没有待核实现就明确拒绝并提示人工承接，不静默入账。

逐步输入输出

假设订单O1由R1采购，revision为1，凭证P1实际支出5200分。上传成功后应能查到O1/P1/R1/5200。相同P1与相同数据再次到达时回读原记录；同一键改为5300分则返回冲突，不覆盖第一次支出。这是示例输入，不是客户交易。

接着输入取消请求O1/revision1。系统进入取消核对，确认商品尚未退回且按示例约定应还骑手5200分，再记录money_decision。履约取消后采购凭证仍在；“订单不再送”不会推导成“从未采购”。实际是否偿还及金额必须依据具体约定，示例不作统一规则。

反例是收到旧版本的第二张凭证，或者直接执行删除O1。前者应触发版本冲突或待核，后者会因关联约束被阻止；都不能把旧请求当作一笔新款。若退货后又有资金调整，追加新核对版本，保留旧原因，查询按明确版本解释，不删除采购事实。

回到采购验收

没有开发人员的团队不必要求厂商采用这组表结构，但应当要求看到同样清楚的业务结果：凭证能追溯、取消不抹账、重复请求不重复计费、迟到材料有人承接。还要核对退款申请与渠道结果是否分开，避免把页面提示当作到账凭证。

设计未包含完整支付结算、权限认证、退货审核与财务合规实现；上线还需事务测试、访问控制和审计。本文没有数据库实跑与云部署结果。它提供选型验证的问题和状态边界，不能据此宣称微订现网已采用该设计或证明任何性能与服务质量。

作者：微订（上海逊柯计算机科技有限公司）。