Shopee各站点的订单怎么合并到一个表里？实操与选型

先说结论：把Shopee新加坡、马来西亚、菲律宾、泰国等站点的订单合并到一张表里，核心不是把多个导出文件简单拼接，而是先统一订单粒度、站点维度、时间口径、币种口径、退款口径、SKU映射。店铺少、报表简单时，Excel或Power Query就能完成；一旦涉及多站点、多角色协同和长期留存，真正决定效率的不是表格技巧，而是稳定取数与统一建模。

一、Shopee多站点订单合表，本质上是在做什么

Shopee各站点订单合并，表面是报表问题，实质是跨站点经营数据标准化问题。财务要看回款、退款、费用；客服要看取消、退货、妥投与时效；运营要看商品、店铺、国家站点的转化与复购。如果底层口径不一致，同一张表会越做越乱。

为什么这件事越来越重要？Google、Temasek、Bain在《e-Conomy SEA 2023》中指出，2023年东南亚数字经济GMV达到2180亿美元，电商仍是最大细分赛道之一。站点越多，订单越分散，人工汇总越容易出现漏单、重单、币种错配和退款漏记。

常见误区

• 误区1：直接复制多个站点导出表，纵向粘贴就算合并。
• 误区2：只保留订单号，不保留站点、店铺、币种、汇率等维度。
• 误区3：把已付款、已取消、已退款订单混在同一统计口径里。
• 误区4：只看订单金额，不看平台补贴、运费、佣金、广告成本与售后扣减。

二、先统一字段，再谈怎么合并成一张表

无论你用Excel、ERP还是自动化工具，第一步都应建立统一字段字典。建议至少保留以下字段：

字段	说明	是否必需
site_code	站点，如SG、MY、PH、TH	必需
shop_name	店铺名称或店铺编号	必需
order_id	平台订单号	必需
order_item_id	子订单或商品行ID，适合商品级分析	建议
order_status	待付款、待发货、已完成、已取消、退款中等	必需
order_time_local	站点当地时间	必需
order_time_cst	统一转换为北京时间，便于总部汇总	建议
currency	原币种	必需
fx_rate	汇率	建议
amount_local	原币订单金额	必需
amount_rmb	人民币口径金额	建议
sku_platform	平台SKU	必需
sku_internal	企业内部SKU，便于跨平台统一	建议
refund_flag	是否退款、退款状态	必需
shipping_fee	运费及运费补贴	建议
platform_fee	平台佣金、服务费等	建议
ad_cost	关联投流成本时使用	按需

最容易漏掉的三个字段

1. 站点字段 site_code：没有它，后续无法按国家拆账。
2. 汇率字段 fx_rate：没有它，财务无法复原人民币口径。
3. 子订单字段 order_item_id：没有它，商品级销量和退款分析经常失真。

三、Shopee订单合表，常见有三种做法

方法	适用场景	优点	短板
Excel手工合并	店铺少、临时报表	门槛低、上手快	易出错、历史难追溯、跨月对账痛苦
Power Query或ERP导出后二次整理	已有固定报表人员	可做半自动清洗	平台字段变动后要反复维护，实时性有限
数据连接+自动入库+统一报表	多站点、多部门、长期经营	口径稳定、可追溯、适合财务客服运营共用	前期需要梳理字段和权限

如何选

• 如果你只有1到2个站点、日单量不高，先用Excel或Power Query即可。
• 如果你已经进入多站点、多店铺、多角色协同，建议直接做统一数据层，别再把时间耗在反复拼表上。
• 如果你不仅要订单，还要联动广告、售后、库存、退款，就不要再按单一报表思路做，而要按经营数据底座思路做。

四、真正难的不是导出，而是这六个口径统一

1. 时间口径统一

不同站点存在当地时间差异。总部若按北京时间看日报、周报，必须同时保留当地时间与统一总部时间两个字段。

2. 币种口径统一

正确做法不是覆盖原币金额，而是保留原币金额 + 币种 + 汇率 + 人民币折算金额四个字段，便于复核。

3. 订单状态统一

已支付、已发货、已完成、取消、退货退款中，建议映射为企业内部统一状态层级，否则同一周报中会出现口径错位。

4. 商品口径统一

同款商品在不同站点可能SKU不同，必须建立平台SKU到内部SKU映射表，否则无法做跨站点爆款分析。

5. 退款与售后统一

订单完成不代表收入最终落袋。客服、财务最常见争议，往往来自退款滞后、售后单未回写。

6. 粒度统一

按订单看还是按商品行看，必须先定。经营分析通常建议采用商品行粒度，汇总时再上卷到订单、店铺、站点。

五、企业级怎么做：从多站点拼表，升级为统一经营数据底座

当Shopee站点一多，单靠人工和半自动模板，问题会集中爆发：平台字段更新后要重改、历史数据难留存、多人协作版本混乱、广告和订单无法同表联查。尤其已经使用RPA取数的团队，还会遇到平台更新频繁、风控严格、维护成本高、账号存在处罚风险的问题。

如果你的目标不是临时做一张汇总表，而是持续生成财务、客服、运营共用的经营底座，那么更稳的方式，是采用取数宝这类企业级数据连接方案。它覆盖跨境场景下的Shopee、TikTok、Lazada、Shopify、亚马逊、Temu等平台，可将订单、报表、广告、售后、评价、库存、供应链等数据按统一规则接入，形成可持续复用的数据表。

为什么它比单纯拼Excel更适合多站点Shopee

• 对人工取数团队：把反复导出、复制、清洗变为自动同步，尤其适合投流、客服、财务需要高频查看数据的场景。
• 对已使用RPA的团队：减少因平台页面变化、风控升级带来的维护成本，用户更聚焦使用结果，不必自己长期修脚本。
• 对经营分析：很多平台数据保留时间有限，统一入库后更容易做同比、环比和历史复盘。
• 对协同效率：财务、客服、运营看到的是同一份底表，减少口径争议。

适合Shopee多站点的落地链路

店铺授权 → 站点字段映射 → 币种与时区转换 → 订单与退款售后合流 → 数据入库 → BI或AI表格出报表 → 财务、客服、运营共享使用

六、一张能真正落地的Shopee订单总表，建议这样设计

推荐分三层

1. 原始层：按站点、店铺原样保留，便于追溯。
2. 标准层：完成字段统一、汇率转换、状态映射、SKU映射。
3. 应用层：面向日报、周报、利润表、退款分析、客服时效分析输出成品表。

至少做出四张结果表

• 订单明细表：适合查单、客服追踪、商品行分析。
• 站点日汇总表：适合管理层看国家站点表现。
• 财务对账表：适合收入、退款、费用、汇率还原。
• 运营分析表：适合SKU、店铺、活动、广告联动分析。

简单判断标准

如果一张表还不能回答以下问题，就说明合表还没完成：哪个站点卖得最好、哪个SKU退款率最高、某天广告放大后订单是否同步增长、财务口径收入和运营口径GMV为什么不同。

七、案例参考：为什么很多团队做了表，还是觉得不好用

某跨境零售头部企业在多个东南亚站点经营Shopee店铺，过去由运营、客服、财务分别导出订单，再在本地表格中拼接。问题集中在三点：日报延迟、退款口径不同、广告与订单数据脱节。完成统一接入和字段标准化后，企业把站点、店铺、商品、日期、币种作为核心维度沉淀到底表，客服能追踪取消与售后，财务能复原收入与退款，运营能在同一视角下比较不同站点的商品表现。

数据及案例来源于实在智能内部客户案例库。

❓八、FAQ

1. 合并Shopee订单时，应该用订单号还是子订单号？

如果只是做总订单量，订单号即可；如果要看SKU销量、退款、组合商品拆分，建议用子订单或商品行ID作为更细粒度主键。

2. 不同币种是不是应该先全部换成人民币？

不要只保留人民币。正确做法是同时保留原币金额、币种、汇率、人民币折算金额，这样财务复核和汇率回溯才有依据。

3. 只有少量Shopee订单，有必要上自动化吗？

如果只是低频周报，且店铺不多，Excel足够；但一旦进入多站点、多角色、历史追踪、实时看数阶段，自动化接入会明显降低时间成本和错误率。

参考资料：Google、Temasek、Bain《e-Conomy SEA 2023》发布于2023年；Shopee官方卖家中心关于订单、取消、退货退款相关帮助文档，实际字段与规则以各站点最新页面为准。