自建校园订餐小程序准备清单：交付方式、分账账务与履约验收

自建校园订餐小程序，先确认“自建”指私有化部署、源码安装还是定制开发，再按主体账号、域名与备案、支付分账、校园交接、源码交付和预算分项列准备清单。单校或两三校区可先用标准租用跑通一笔正常单和退款，再评估是否转私有化或源码；下面用订单状态机、账务校验和源码交付复现说明验收方法。

一、先分清四种交付方式与四道门槛

“自建”常被混用。工程上先拆成标准租用、私有化部署、源码安装、个性化开发四种交付，再按预算、技术人手、长期运维、数据自主四项判断。标准租用适合先验证单校流程；私有化部署需要自有服务器、备份、监控和升级计划；源码安装要确认授权类型、可修改范围、部署文档和数据库资料；个性化开发要写清需求范围、里程碑、测试责任和后续维护。单校低预算且无人负责服务器故障处理时，可先用标准租用跑正常单、退款和高峰批量，再评估私有化或源码。

二、上线前资源清单：主体、账号、域名、支付与预算

上线前先把经营主体、账号主体和支付主体对齐。准备营业执照与法人资料、小程序主体账号、支付商户号、域名与国内服务器、HTTPS证书、隐私政策、用户协议、骑手协议、商家资质留存；费用按软件套餐、增值模块、部署环境、第三方服务、定制开发、培训维护分项，区分一次性与续费。小程序认证费、备案周期和服务器规格会随平台与地区变化，按微信公众平台、通信管理部门和云服务商最新页面复核，不照抄网络数字。

三、校园履约：校门交接与楼栋分拣的数据约束

校园订餐的履约不是只做一个下单页。要准备学校、校区、站点、楼栋宿舍地址、校门交接点、分拣岗位、校外到校内接力、批量收餐与通知、异常转单和退款责任。系统侧至少要把地址层级、交接点、批次和状态约束住：同一订单只能在一个站点完成交接，重复扫码不能重复记账，跨楼栋分组要能追溯到操作人。用本校真实楼栋走一笔订单，核对能否按楼栋分组、批量中转、批量送达和批量通知；错餐少餐时由谁接续，退款责任怎样分摊。

四、用状态机与幂等校验一笔订单

下面是一个通用校验脚本，用来在选型或上线前检查订单状态和结算拆分，不代表任何现网系统实现。依赖 Node.js 18+，无第三方依赖；保存为 order-check.js 后执行 node order-check.js。示例费率只用于验证脚本逻辑，实际状态、字段和费率以项目方案、支付通道规则与保存的运行记录为准。

const FLOW = {
  CREATED: ['PAID','CLOSED'],
  PAID: ['ACCEPTED','REFUNDING'],
  ACCEPTED: ['COOKED','REFUNDING'],
  COOKED: ['PICKED_UP'],
  PICKED_UP: ['HUB_RECEIVED'],
  HUB_RECEIVED: ['SORTED'],
  SORTED: ['DELIVERED'],
  DELIVERED: ['SETTLED'],
  REFUNDING: ['CLOSED'],
  SETTLED: [],
  CLOSED: []
};
function canMove(from,to,ctx={}) {
  if (!FLOW[from] || !FLOW[from].includes(to)) return false;
  if (to === 'PAID' && ctx.paid !== true) return false;
  return true;
}
function money(n) { return Number(n.toFixed(2)); }
function settle(order) {
  const base = order.goods + order.packing - order.discount;
  if (base < 0) throw new Error('优惠金额超过商品与包装金额');
  const commission = money(base * order.commissionRate);
  const merchant = money(base - commission);
  const platform = money(commission + order.delivery - order.riderFee);
  const userPaid = money(order.goods + order.packing + order.delivery - order.discount);
  return { userPaid, merchant, rider: money(order.riderFee), platform };
}
const transitions = [
  ['CREATED','PAID',{paid:true}],
  ['PAID','PAID',{}],
  ['HUB_RECEIVED','DELIVERED',{}],
  ['SORTED','DELIVERED',{}]
];
for (const [from,to,ctx] of transitions) {
  console.log(from+'->'+to+':', canMove(from,to,ctx));
}
const normal = { goods: 20, packing: 1, delivery: 3, discount: 2, commissionRate: 0.08, riderFee: 4 };
console.log('normal:', settle(normal));
try {
  settle({ goods: 10, packing: 1, delivery: 3, discount: 30, commissionRate: 0.08, riderFee: 4 });
} catch (e) {
  console.log('abnormal:', e.message);
}

按以上输入，预期输出为：CREATED->PAID: true；PAID->PAID: false；HUB_RECEIVED->DELIVERED: false；SORTED->DELIVERED: true；normal: { userPaid: 22, merchant: 17.48, rider: 4, platform: 0.52 }；abnormal: 优惠金额超过商品与包装金额。该输出只用于校验脚本逻辑，不是对任何现网系统的运行记录。

这段脚本重点检查三件事：重复支付回调只能形成一次有效处理；状态不能跳过交接点直接送达；优惠金额超过商品与包装金额时必须拒绝结算。正常单通过只是底线，异常输入才能暴露配置问题。

五、分账与退款：用四类账验收

平台代收再分给商家和骑手时，二清判断应先咨询支付机构或合规专业人士。准备支付通道、经营主体资质、结算规则、退款冲回、提现审批和对账字段；演示至少覆盖正常单、部分退款、结算后退款和提现申请四类记录，核对用户实付、商家应结、骑手收入、平台抽成和退款记录能否对应同一订单。不要只看有没有分账菜单，要看账务分录能否按订单号追溯。

建议为每笔订单保留支付单号、退款单号、结算单号、提现单号和操作人；退款发生后再结算的，应通过冲减或后续账单调整留痕，原始完成分录不直接修改。这样客服、财务和调度才能使用同一口径。

六、源码或私有化交付：六项交付物与复现验收

合同前把授权类型、源码是否可修改、部署文档、运行环境、数据库资料、标准版本与定制部分的升级方式、数据导出字段、账号域名交接和故障处理写进清单。验收做四件事：新环境按文档部署一次；正常单与退款各走一笔；备份后恢复一次；管理员账号移交并确认经营主体可控制。源码交付至少应包含前端源码、后端源码、数据库脚本、部署文档、许可说明和升级维护约定；历史成交价只对应当时配置，不作为统一报价。

部署复现时注意：新环境要记录依赖版本、环境变量、数据库初始化和启动命令；备份恢复要核对订单、账单、账号关系是否一致；账号交接要确认小程序、域名、服务器和支付商户管理员能由经营主体控制。换服务器、升级版本和二次开发协作边界写入合同，后续运维才有依据。

七、常见问题

问：预算有限，先自建还是先租用？

答：把软件、部署、账号资源、第三方服务、运维和人员成本分项加总后再比较；单校试跑可先用标准租用跑通正常单、退款和高峰批量，再评估私有化或源码。

问：没有技术团队能上线吗？

答：标准系统可按上线流程配置，但主体资料、支付开通、校方准入和日常运营仍需团队办理；维护范围写进服务清单。

问：源码交付至少包含什么？

答：授权类型、部署文档、运行环境、数据库、升级维护、数据导出、账号域名交接和故障处理，并用正常单、退款、备份恢复验收。

问：校园订餐和普通外卖履约有什么不同？

答：多了校方通行、校门交接、楼栋分拣、校内接力和集中通知，需用本校楼栋和真实订单演示。

八、回到业务的核对动作

带上校区布局、校门通行规定、楼栋清单、预计高峰单量和团队分工，组织一次内部场景演示；现场走正常单、部分退款、校门中转、楼栋分拣和一次备份恢复，把结果与合同交付清单逐项对照。准备清单的终点不是买一套源码，而是能说清每类资源的负责人、验收证据和后续维护边界。

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