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

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

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

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

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

text 复制代码

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

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

订单最小字段与业务标识

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

python 复制代码

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",
}

def export_ledger(rows, biz: str):
    """按账本过滤；禁止无 biz 全量混导后靠人工拆。"""
    return [r for r in rows if r["biz"] == biz]

表结构示意：

sql 复制代码

CREATE TABLE order_main (
  order_id   VARCHAR(32) PRIMARY KEY,
  biz        VARCHAR(16) NOT NULL,
  amount     INT NOT NULL,
  discount   INT NOT NULL DEFAULT 0,
  status     VARCHAR(32) NOT NULL,
  paid_at    DATETIME NULL,
  INDEX idx_biz_paid (biz, paid_at)
);

CREATE TABLE order_ext (
  order_id   VARCHAR(32) PRIMARY KEY,
  payload    JSON NOT NULL
);

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

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

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

python 复制代码

ALLOWED = {
    "ops_waimai": {"waimai"},
    "ops_all": {"waimai", "paotui", "shangmen"},
    "finance": {"waimai", "paotui", "shangmen"},
}

def list_orders(actor, biz_filter=None):
    allow = ALLOWED[actor.role]
    target = allow if biz_filter is None else (allow & {biz_filter})
    if not target:
        raise PermissionError("biz not allowed")
    return query_orders(biz_in=target)

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

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

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

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

python 复制代码

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

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

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

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

验收清单

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

成品怎么接住

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

财务对账日怎么跑更稳

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

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

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

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

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

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

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

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

纯技术小结

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