一张电商营收明细表应该有哪些字段？（附字段清单模板）

说明：这里给出的是一份「通用模板」，方便你和团队讨论与落地。不同公司有不同业务特点，可以在此基础上增减字段，但建议 保持结构清晰、字段含义稳定。

一、为什么先要有一张「营收明细表」？

很多团队上来就想做「漂亮的营收驾驶舱」，结果发现：

• 同一个指标在不同报表里的值对不上；
• 有的报表按订单算，有的按结算算，有的按回款算；
• 一改口径，就要改一堆 SQL / 报表配置。

根本原因往往是：缺少一张结构清晰、含义统一的「营收明细表」作为底表。

这张表的目标很简单：

• 一行表达一条「营收相关记录」（通常是一笔订单或订单明细行）；
• 在这一行上，把 订单主信息 + 金额字段 + 各类费用 + 汇率 + 维度字段 都粘在一起；
• 上层任何报表和驾驶舱，只是在这张表的基础上做聚合与切分。

---

二、表结构总览：可以分成 5 大类字段

推荐的字段分组思路：

1. 主键与来源字段：唯一标识一条记录 + 来自哪个系统；
2. 订单与时间字段：订单号、下单时间、发货时间、结算时间等；
3. 金额与费用字段：销售额、退款额、平台费、运费、广告费等；
4. 汇率与币种字段：原币金额、币种、汇率、折算后金额；
5. 分析维度字段：平台、站点、店铺、渠道、品类、SKU 等。

下面按类别给出一个可直接参考的字段清单。

---

三、主键与来源字段（确保一行记录可追溯）

建议字段：

• id：本表内部主键（可用自增或 UUID）；
• source_system：来源系统（如：Amazon、Shopee、ERP、财务）；
• source_order_id：来源系统订单号；
• source_order_item_id：来源系统订单明细行号（如有）；
• data_date：本记录对应的数据日期（如每天快照，可以填「快照日期」）。

设计要点：

• 保证 (source_system + source_order_id + source_order_item_id) 逻辑上能唯一定位到来源数据；
• 不要把多个来源系统混在一个字段里，否则后面排查异常会很痛苦。

---

四、订单与时间字段（为后续口径讨论留好空间）

常见字段：

• order_date：下单时间；
• payment_date：支付时间 / 账款确认时间；
• ship_date：发货时间；
• settlement_date：平台结算时间；
• cancel_date：取消时间（如有）；
• refund_date：退款完成时间（如有）。

为什么要留这么多时间字段？

• 不同团队关注的周期不同：
  • 运营常按「下单日」看 GMV；
  • 财务按「结算日 / 回款日」确认收入；
  • 客诉/仓储可能按「发货日」统计工时与 SLA。
• 只要在底表里把各个「关键时间点」都留出来，之后在视图层就可以灵活选择口径，而不必每次重拉数据。

---

五、金额与费用字段（收入 + 各类扣减与成本）

可以按「收入 / 扣减 / 成本」三大块来设计。

1. 收入相关

• gross_revenue：原始订单金额（含税、含运费、未扣折扣）；
• discount_amount：优惠券 / 满减 / 活动折扣金额；
• shipping_income：向客户收取的运费；
• tax_amount：销项税（如有单列）；
• net_revenue：净销售额 = gross_revenue − discount_amount − 退货相关金额。

具体公式可以根据你的会计与管理口径来约定，这里给的是字段建议。

2. 平台与履约费用

• platform_fee：平台佣金、交易费等；
• fba_fulfillment_fee：FBA / 平台履约费用；
• storage_fee：仓储费、长期仓储费；
• other_platform_charges：其他平台扣费（如罚款、服务费等）。

3. 广告与推广费用

• ad_spend：站内广告花费；
• coupon_cost：优惠券成本（如由商家承担的部分）；
• external_marketing_cost：站外投放成本（如达人佣金、联盟返佣等）。

4. 商品与物流成本

• product_cost：商品进货成本（可按 SKU 维护）；
• inbound_logistics_cost：头程运费、清关、关税等与备货相关的成本；
• last_mile_shipping_cost：尾程发货成本（如由商家承担的部分）。

这些字段不一定都要在第一期就做到「逐单精确」，但建议至少在设计上 预留位置，便于日后逐步精细化。

---

六、汇率与币种字段（为「统一口径」打基础）

常见字段：

• currency：原币种（USD、EUR、THB 等）；
• exchange_rate_to_cny：折算成人民币的汇率（可带版本号或日期）；
• amount_cny：按统一汇率折算后的金额（可对 net_revenue 或其他字段折算）；
• 如有需要，还可以加入 exchange_rate_source（汇率来源：平台、ERP、自建表等）。

设计原则：

• 计算字段 vs 源字段分离：
  • 源字段保留平台原始金额与币种；
  • 折算字段只负责「按照当前约定」计算出的结果。
• 当汇率口径调整时，只需要重算折算字段，不必动原始明细。

---

七、分析维度字段（决定你能怎么切盘）

维度字段决定了你在报表和驾驶舱上能够「怎么切这个盘」。建议至少包含：

• 平台与站点：
  • platform（如：Amazon、Shopee、自建站）；
  • site / country（如：US、UK、TH、VN 等）；
• 店铺与渠道：
  • store_name / store_code；
  • channel（自营、经销、代理、直营门店等）；
• 商品相关：
  • sku / msku / asin 等（按你系统习惯选择）；
  • category_level1 / category_level2（一级类目、二级类目）；
• 客户与订单类型（如有）：
  • customer_type（新客 / 复购 / 批发 等）；
  • order_type（普通单 / 活动单 / 清仓单 等）。

维度字段不一定都来自同一系统，可以通过「维度表」做映射，比如：平台类目 → 自定义类目、店铺 → 事业部 等。

---

八、如何在现有系统中逐步落地这张表？

可以按下面三个步骤渐进式推进：

第一步：先拉出「最小可用」字段集

• 从你现在最依赖的平台 / ERP / 财务系统里，先选出：
  • 订单编号 + 下单时间；
  • 净销售额相关字段；
  • 商品成本 / 简化后的费用字段；
  • 平台 / 店铺 / SKU / 类目等核心维度。
• 先在飞书多维表或数据库里拼出第一版营收明细表，哪怕字段不完美，也要先跑起来。

第二步：和财务 / 运营一起补全「关键缺口」

• 举例：
  • 财务觉得：需要加上平台费、仓储费字段，才能看出真实毛利；
  • 运营觉得：需要加上广告费、优惠券成本，才能评估投放效果。
• 每补一个字段，就在文档里写清楚：含义 / 来源 / 刷新频率 / 负责人。

第三步：稳定后，才考虑性能优化与拆表

• 当表结构和口径稳定下来后，再考虑：
  • 按月份或年份分表；
  • 为常用维度加索引；
  • 把部分计算字段下推到 ETL 层等。
• 不要一开始就过度设计，否则会拖慢整个项目节奏。

---

九、小结：一张好用的营收明细表，长什么样？

一张「好用」的营收明细表，通常具备这些特点：

• 字段含义清晰：每一个字段都有文档说明，知道是从哪来、怎么算的；
• 结构稳定：可以在不频繁改结构的情况下，支持新增报表与驾驶舱；
• 维度丰富但不混乱：平台 / 国家 / 店铺 / 类目 / SKU 等维度各司其职，而不是塞进一个「备注」字段里；
• 能支撑不同口径：同一张表，既能按 GMV 口径汇总，也能按结算 / 回款口径重新聚合。

建议你把这份字段清单当成一个「讨论模板」，和财务、运营、数据同事一起评审：
哪些字段必须要有？哪些可以先空着？哪些需要结合你们的实际业务再细化。只要底表打好了，后面的营收驾驶舱、利润分析、预算回顾都会轻松很多。