本地生活系统：多业务订单字段怎么分账本导出

本地生活系统多业务并行时，工程上常把「统一后台」理解成「一张宽表倒所有钱」。结果是外卖、跑腿、上门服务的订单字段挤在一起导出，财务对账时还要人工拆表。更好的做法是：订单字段按账本分导出，后台登录与权限仍然统一。

本文讲清：统一管理不等于混账；每笔单如何带业务标识；导出如何按账本过滤；活动分摊字段放哪里；接口层如何挡住越权导出。

结论：统一后台，分账本导出

统一后台解决的是「运营不用切七套登录」。账本解决的是「同一天里不同业务的钱能不能分开核对」。两件事不要焊死成一张超宽表。

admin-portal (一套登录 / 一套角色) | +-- order-query (带 biz 过滤) +-- ledger-export(按 biz 出文件) | order-store order_id | biz | amount | discount | status | paid_at | ...

禁止为每个业务再造一套用户库、商家库；允许每个业务有自己的订单扩展字段，但导出入口仍走统一查询。中台侧用户、商家、营销能力可以共享升级，不等于结算导出可以混成一本糊涂账。暂时不开的业务，菜单可以对低权限岗位先隐藏，但库里的用户商家资料仍建议共用，避免后期叠加业务时重新录入。

订单最小字段与业务标识

教学示意：主表只保留跨业务可对齐的字段，业务特有字段进扩展表或 JSON，但导出时仍按biz切开。

order={"order_id":"O20260913","biz":"waimai",# waimai / paotui / shangmen / ..."amount":3500,# 分"discount":200,"status":"done","paid_at":"2026-09-13T12:01:00+08:00","city_scope":"city_ops_01",}defexport_ledger(rows,biz:str):"""按账本过滤；禁止无 biz 全量混导后靠人工拆。"""return[rforrinrowsifr["biz"]==biz]

表结构示意：

CREATETABLEorder_main(order_idVARCHAR(32)PRIMARYKEY,bizVARCHAR(16)NOTNULL,amountINTNOTNULL,discountINTNOTNULLDEFAULT0,statusVARCHAR(32)NOTNULL,paid_atDATETIMENULL,INDEXidx_biz_paid(biz,paid_at));CREATETABLEorder_ext(order_idVARCHAR(32)PRIMARYKEY,payload JSONNOTNULL);

导出文件命名也建议带业务与日期，例如ledger_waimai_20260913.csv，避免财务同学收到「全量」后仍要二次拆分。金额字段建议统一最小货币单位，并在文件头注明币种与单位，减少「看错小数点」的对账事故。

统一后台怎么接权限与列表

登录与角色一套；列表、详情、导出接口都必须带biz（或岗位允许的业务集合）。前端隐藏菜单不等于服务端可以省略过滤。

ALLOWED={"ops_waimai":{"waimai"},"ops_all":{"waimai","paotui","shangmen"},"finance":{"waimai","paotui","shangmen"},}deflist_orders(actor,biz_filter=None):allow=ALLOWED[actor.role]target=allowifbiz_filterisNoneelse(allow&{biz_filter})ifnottarget:raisePermissionError("biz not allowed")returnquery_orders(biz_in=target)

自检：用只开外卖权限的账号，接口层请求biz=paotui应失败，而不是返回空列表却写审计「已导出」。空列表和拒绝是两回事——前者像「今天没单」，后者才是权限边界。批量导出任务同样要带操作者与业务范围，防止定时任务用超管身份绕过白天的岗位限制。

活动与分摊：不要写进错误的账本

跨业务营销容易把折扣分摊写乱。建议：

• 订单行上保留「本单实付、本单优惠」快照
• 活动主数据单独表；导出对账时按订单快照，不按活动实时规则重算
• 若一笔活动覆盖多业务，分摊结果写入各业务账本行，并带同一campaign_id便于追溯

defattach_discount_snapshot(order,campaign):order["discount"]=campaign.allocate(order)order["campaign_id"]=campaign.id# 禁止导出时再按「当前活动规则」重算历史单

财务夜间对账时，优先核对「快照金额能否加总」，而不是打开活动配置页重新心算。若必须做活动效果分析，另开分析库或只读副本，不要在生产导出链路里「顺便重算」。

数据互通与账本边界如何共存

统一后台的价值是数据互通：同一用户在不同业务的行为可以被运营看见。但互通不等于混账。可以共享用户标识与商家主体，同时在订单与导出层严格按业务切开。这样既避免「多套系统来回切」，也避免「月底三张表对不拢」。

验收清单

1. 同一后台能切换业务列表，但导出文件按biz分开
2. 越权biz请求被拒绝并记审计
3. 历史单优惠与当前活动配置不一致时，导出仍以快照为准
4. 用户 / 商家资料不因业务切换被重复录入
5. 定时导出任务的权限范围与操作者岗位一致

成品怎么接住

光合同城本地生活成品采用中台一体化：多业务共享统一后台与用户/商家资料，订单带业务标识，导出可按账本过滤。暂时不开的业务可先隐藏菜单，后期叠加模块不必再买一套后台。商务结算规则由客户确定；系统侧不抽成客户平台订单。私有化源码交付后，可用「按 biz 导出 + 抽查字段」做验收。

财务对账日怎么跑更稳

对账日建议固定窗口：先按业务导出，再按日期汇总，最后抽查优惠快照。不要在对账窗口临时改活动规则，否则运营与财务会对着两套数字吵架。

若存在跨业务优惠，导出文件里保留活动标识，并另附分摊说明：本单分摊多少、是否与其它业务共担。说明是业务解释，不是让导出程序按新规则重算历史。

权限上，财务导出账号可以跨业务只读，但写结算相关字段仍按岗位拆开。统一后台解决登录成本；分账本导出解决核对成本。批量导出任务也要带操作者与业务范围，防止定时任务用超管身份绕过白天的岗位限制。

中台一体化的体感是：运营同一入口登录，用户商家资料共用，未开业务菜单可隐藏；财务侧仍按业务拿账本。两者同时成立，才叫统一而不混账。后期加跑腿或上门，不必再买一套后台，但导出与权限范围要同步扩展业务标识。

从单业务迁到多业务的迁移顺序

若你现在只有外卖，准备加跑腿，不要先把两套订单表硬合成一张超宽表。更稳的顺序是：先统一登录与用户商家资料，再让新业务订单带上业务标识写入同一订单主表或同构主表，最后改导出与权限范围。迁移期可以双写校验几天，但对外对账以带业务标识的新导出为准。

运营培训也按这个顺序：先学会同一后台切换业务列表，再学会按账本下载文件，最后才学跨业务活动配置。培训颠倒，财务会最先受伤。金额单位、币种、业务标识、支付时间，是分账本导出的四根柱子。缺一根，财务就要靠猜。导出任务失败要告警到人，不能只写日志文件。

中台一体化的体感应是：运营同一入口登录，用户商家资料共用，未开业务菜单可隐藏；财务侧仍按业务拿账本。两者同时成立，才叫统一而不混账。后期叠加业务不必再买一套后台，但导出与权限范围要同步扩展业务标识。

纯技术小结

• 统一后台 ≠ 一张混导出表；每笔单必须有biz
• 列表与导出口强校验业务范围；藏菜单不够
• 优惠以订单快照为准，禁止用当前活动规则重算历史
• 扩展字段可分表，账本边界不能糊；互通的是资料，切开的是账本

适合谁：准备从单业务扩到多业务、又要财务可分账本核对的团队。不适合：仍用多套后台各导各的、月底靠表格拼接的做法。