校园外卖平台有不同档口、不同抽成比例，还有部分退款和跨期售后时，逐笔对账需要保存每笔订单当时的费用规则、原收款、退款及后续调整。报表应能沿订单号和退款单解释一笔金额，不能每次导出都拿当前费率重新计算历史订单。
微订公开产品资料包含校园外卖、多学校多校区、商家及配送员结算、平台抽成与提现等业务范围。本文由微订整理，以校园档口的经营问题说明一种云上账务设计；示例费率、分摊与报表模型用于讨论，不是微订统一收费政策、客户结果或现网实现披露。
一、先约定抽成基数，才能讨论比例
同样写“按比例抽成”，可能指商品原价、优惠后商品金额或其他约定基数。配送费、包装费、平台补贴、商家承担优惠及渠道手续费，也可能由不同主体承担。费率相同却基数不同，结果仍可能不同。
| 需约定的内容 | 订单侧应保留的依据 |
|---|---|
| 商家与档口范围 | 商家主体、学校或站点、适用规则标识 |
| 抽成条件 | 基数、比例或固定费用、生效时间及规则版本 |
| 优惠与配送 | 各方承担金额与核对口径，避免混进同一收入 |
| 退款规则 | 是否退佣、如何分摊、舍入与末次退款尾差处理 |
| 结算条件 | 账期、结算批次、调整方式及渠道结果 |
计费节点可按业务约定为支付、完成或其他明确事件。重要的是同一合同口径下固定依据。不同档口在不同时点变更规则时，应生成新规则版本，并让订单保存它实际使用的快照；历史交易不随着配置页面一起变化。
二、用一笔部分退款说明逐笔核对
假设一笔订单收款100元，按10%计平台佣金，商家应收90元；暂不包含配送费、补贴和渠道手续费。结算后退款30元，并约定按原比例退佣，则本次平台佣金冲减3元、商家应收冲减27元。调整后平台累计7元、商家累计63元，合计70元，与收款减退款一致。
这组数字只在上述条件下成立。其他档口若采用固定服务费、优惠由平台承担或退款不退某项费用，就需按各自规则计算并保存明细，不能一律把退款金额乘当前比例。多次部分退款还应明确按次计算还是按累计结果求差额，最后一次如何处理舍入尾差。
若原90元已经付给商家，账面追加负27元并不表示资金自动回到平台。后续抵扣、追收或其他处理需按约定和支付产品执行，保留执行状态。财务明细正确、渠道退款成功、商家款项追回，是三个不同的核对结果。
三、原结算单与后续调整分开保存
结算单记录当时确认的订单集合、金额与规则版本。结算后发生退款，保留原单，在后续账期追加关联原订单、退款编号和原批次的负向调整。这样可以解释为什么上期已结90元，本期出现一条负27元，而不是静默改掉已经交付的旧报表。
建议区分业务发生时间、系统收到时间和记账时间。支付渠道的退款事件可能迟到，若只按订单创建日期导出，就可能遗漏本期才确认的跨期调整。原始渠道结果、业务记账明细和商家报表分别保留，差异处理有来源可查。
四、在阿里云上按交易与报表职责组织数据
校园下单 / 商家后台 / 平台财务
↓
应用服务：身份范围、订单费用快照、退款处理
↓
RDS MySQL：原交易 + 退款 + 结算明细 + Outbox
↓
可靠投递任务 → RocketMQ → 对账投影与差异任务
↓
冻结批次或可复现报表 → 私有OSS导出文件
ECS等计算资源可以承载应用与任务进程，RDS保存需要关联和事务约束的明细。这里是可选架构，不意味着微订采用了这些云产品。规模尚小时，先在同一数据库明确表、索引与账号职责，通常比未经测量就拆很多服务更容易核对。
采用Outbox时，退款业务变化和待发送事件在同一事务写入；事务提交后再投递。投递结果未知可能重发，消费侧按处理器、所属平台、事件类型及退款业务编号去重。去重记录和账务明细同事务提交，再确认消费；不能先标记已处理却尚未写入账单。
同一订单可以有多次有效退款，因此去重键不能只有订单号。同一退款编号出现不同金额，也不能当普通重复静默忽略。退款先到、原支付投影后到等乱序情况，则需要依赖等待、查询和差异任务，不能用“消息可靠”略过。
五、导出报表要固定范围与完整性口径
一次导出任务保存学校或站点、商家范围、账期、退款与调整口径，以及本次使用的数据版本或处理水位。分页应来自同一可复现结果，或已冻结的批次明细。只有一个业务时间截止条件，仍可能漏掉截止后才收到的早期事件。
迟到事件可按约定进入后续差异单或新报表版本，保留与旧版本的关联。只读实例能分担某些查询，但可能有复制延迟，导出前仍要判断数据是否处理完整。不能因为文件生成成功，就宣称财务数据已经全部核对。
商家下载时由服务端确认其商家与角色范围，文件存入私有OSS后再提供短期签名访问。敏感流水、签名链接及个人信息不要进入公开日志。云数据库备份也需配合恢复演练，确认恢复后交易、退款与结算批次之间仍可关联。
六、把抽成与对账做成可重复演示的任务
| 测试情形 | 应核对的结果 |
|---|---|
| 两个档口采用不同规则 | 每单保留自己的快照，合计可拆回单笔 |
| 账期中修改费率 | 旧单按原快照，新单按约定生效节点 |
| 同单两次部分退款，通知各重复一次 | 每次有效退款分别记账，重复不增加明细 |
| 商家结算后确认退款 | 原结算单保留，后续关联调整可解释 |
| 导出期间收到迟到退款 | 说明报表版本、水位和后续差异去向 |
| 商家访问其他档口账单 | 权限拒绝，不能下载其他商家的导出文件 |
使用微订的校园及结算相关模块时，可以将这些问题对应到已开通模块、支付通道和实际配置，并明确财务人员如何从汇总跳转到订单、退款与批次。公开功能说明用于确认业务范围；具体费率设置、退款分摊及跨期处理，仍需在本项目中逐项演示，不由产品名称自动推定。
校园外卖抽成对账的核心，是让不同档口都能看懂自己的应收、退款和调整来源。云上的事务、消息与对象存储负责承载和传递这些记录，业务规则与资金结果则需要各自的核对依据。本文给出设计与验收方法，没有执行真实渠道交易或云上性能测试。
资料依据：微订产品与业务全景公开资料、阿里云RocketMQ基本概念及OSS签名URL说明。
作者：微订（上海逊柯计算机科技有限公司）。
