多校区校园外卖系统搭建流程：校区隔离、权限与对账验收

多校区校园外卖系统的搭建流程可以按“校方准入—组织与账务定规—选系统—单校区配置—商家骑手与履约落地—测试验收—试运营—复制扩校”推进。关键条件是先在一个校区跑通订单、退款和对账，再用两个校区账号做权限互看和跨校区联调，成熟后复制扩校。下面把每一步拆成可核对的技术动作，重点说明校区隔离、订单归属、校园履约状态和资金对账如何验收。

一、先定组织与账务，再选系统

多校区的订单归属、配送范围、退款责任和结算主体如果没有先定清，系统配置会在上线后反复调整。建议先画三层职责：总部管校区创建、通用规则、分账比例和提现审批；校区负责人管本校商家、骑手、配送范围与售后；站点人员只处理当班订单和交接。三层职责要落到账号的数据范围和操作入口，而不是只写在制度里。

权限验收用两个校区账号互看，至少检查四项：订单列表、报表、导出列和提现入口。记录A账号是否能打开B校区数据，结果附在验收单。权限同时写进代理协议和运营制度，人员调整时同步更新账号。

订单归属建议在数据模型里显式表达。下面的结构是项目设计示例，用于说明字段关系，不对应具体产品的内部实现。

campus(id, name, delivery_zone_id)
merchant(id, campus_id, merchant_scope)
rider_group(id, campus_id)
delivery_zone(id, campus_id, polygon, handover_point)
order(id, campus_id, merchant_id, rider_group_id, address_id, status)
settlement(order_id, campus_id, user_paid, goods_amount, delivery_fee, commission, merchant_due, rider_income, discount, refund, settle_status)

其中campus_id是订单归属的主键，商家、骑手组、配送范围和结算记录都围绕它关联。订单写入时校验商家与校区是否匹配，骑手组是否属于当前校区，配送地址是否落在该校区服务范围。这样后续做报表、退款回冲和扩校复制时，口径一致。

二、单校区配置：把校区、商家、骑手组和配送范围建成可复制单元

每个校区单独画配送范围，并处理边界重叠。上线前统一楼栋、宿舍和取餐点命名，避免同一栋楼出现新旧楼号两套写法。校外商户订单进入校门中转，按楼栋分拣后由校内骑手接力；校内商户是否直送、哪些楼栋允许上楼，按校方通行规则配置。

配送范围验收用三类地址：核心区、服务区边缘、跨站地址。分别下一单，检查订单是否进入正确校区、计费是否按该校区规则、骑手组是否只收到本站任务。地址模板能否跨校区复制需要在实际版本中核对；设计上先保持命名规则一致，扩校时再复制可复用部分。

商家和骑手按校区归属：单校区商家只在本校展示；连锁商家可绑定多个校区，但各校区商品和库存独立。骑手组绑定校区，派单池按校区隔离；跨校区支援单走总部协调并单独记账，避免和本站任务混在一起。

三、校园履约的状态机与批量操作

校园履约建议按状态机管理，状态变化绑定校验点。下表给出设计示例，具体状态名称可按项目调整，但订单归属、交接确认和异常分离要保持清晰。

高峰批量操作要按“先实物核对、再批量更新、异常单单独跟进”的顺序。批量中转、批量送达和批量通知可以提升效率，但同一批里少餐、错餐、跨站订单不应混入正常批次。下面为批量送达的伪代码示例。

function batch_deliver(account, campus_id, order_ids):
  assert can_operate(account, campus_id)
  orders = load_orders(order_ids)
  normal = []
  exception = []
  for order in orders:
    if order.campus_id != campus_id: exception.append(order); continue
    if order.status != 校内配送: exception.append(order); continue
    if not actual_delivered(order): exception.append(order); continue
    normal.append(order)
  update_status(normal, 已送达)
  notify_users(normal)
  return exception

这段伪代码只说明验收逻辑：跨站订单、状态不符、实物未交付的订单进入异常列表，不跟着正常批次一起更新。实际系统可能用不同接口和状态名，验收时按同样维度检查。

四、上线测试与按校区对账

上线前至少跑四类订单：正常完成单、部分退款、结算后退款、提现。每类都看商家账、骑手账、平台账是否分开生成，退款是否按规则回冲，提现余额是否与账单一致。对账字段建议包含用户实付、商品款、配送费、平台抽成、商家应结、骑手收入、优惠承担、退款和结算状态，并能按校区查看。

两校区联调脚本可以固定为四步：第一步，A校区下一单，检查B校区骑手端是否出现该单；第二步，用A校区负责人账号打开订单、报表、导出列和提现入口，检查是否能看到B校区数据；第三步，做一笔部分退款和一笔结算后退款，核对两校区账单是否分开回冲；第四步，总部账号查看汇总，确认能按校区筛选。这里写的是验证方法和预期结果，实际记录以测试环境保存的订单和账单为准。

自动分账和提现取决于所选系统、支付通道、主体资质、版本和项目规则。方案中要写清账期、手续费、退款回冲方式、提现审批角色和到账查询方式，避免上线后靠人工补账。

五、复制扩校：复用清单与重配清单

一个校区稳定运行后，再建第二校区做联调。扩校时把配置拆成复用清单和重配清单：品牌页面、类目结构、培训材料、对账方法和操作清单可复用；商家、商品、骑手、班次、楼栋地址、通行规则和结算安排按新校区重新配置。配置变更要留痕，重要规则保留回退方案。

费用问询落到分项：校区数、子账号数、终端入口、部署方式、支付通道、短信通知、培训、售后响应和续费。历史成交价只对应当时的模块和交付范围，当前报价按项目方案确认。把复用项和重配项列清，扩校预算才有可比口径。

常见问题

问：多校区是否要买多套系统？

通常按一套平台、多校区或多分站组织更便于统一品牌和汇总，最终看校区隔离粒度和权限模型。验收时用两个校区账号互看订单、报表、导出列和提现入口。

问：校区负责人能否看到其他校区账单？

默认应按校区隔离。上线前用两校区账号检查订单、报表、导出列和提现入口，并把数据范围写进代理协议和运营制度。

问：先搭一个校区还是同时开？

先在一个校区跑通订单、退款和对账，再做第二校区联调和权限互看。两个校区同时铺开时，问题会混在一起，定位成本更高。

问：预算有限怎样问价？

把校区数、子账号数、终端、部署、支付、短信、培训、售后和续费逐项列入询价；历史成交价只对应当时配置，当前报价按项目方案确认。

上线前的核对动作可以固定为一张验收单：用两个校区账号跑正常单、部分退款、结算后退款和提现四类场景，记录订单归属、骑手组可见范围、退款回冲结果和导出列范围，再把结果附在项目验收记录中。