跨境知识库数据团队

多站点数据合并手册:时区和汇率先定死,再谈合并

我们有五个站点,报表一直分开看,某天要做全盘对比,把五张表合到一张上。那天合出来的数字漂亮得不像话,美国站和德国站的日销曲线几乎一样平滑,因为时区没对齐,美国站…

多站点汇率时区合并规范

我们有五个站点,报表一直分开看,某天要做全盘对比,把五张表合到一张上。那天合出来的数字漂亮得不像话,美国站和德国站的日销曲线几乎一样平滑,因为时区没对齐,美国站先结算的时段和德国站错开了,峰谷被平均掉。汇率先用了月末汇率,那个月美元跌 3%,跨月同比直接差出两个点。

合并表最危险的地方在于它看起来是对的。

时区和汇率:两条并行的口径

多站点合并的时区与汇率口径与分歧判定
多站点合并的时区与汇率口径与分歧判定

左边四条是时区规则,右边四条是汇率规则,下面是合并前的分歧判断

时区那四条:

项口径不合格怎么办
基准统一按 UTC+0 落库落库时间两套,看的时候还要再折算
切日按站点所在地的本地时间切自然日按统一时区切,跟站点运营日对不上
周口径周一到周日,同一时刻起算跨站比周数据时再讨论谁多一天
记录每张表带 site_timezone 列少这列,换人写 SQL 就算错

汇率那四条:

项口径不合格怎么办
折算时点按订单成交日汇率用月末汇率,涨跌幅直接算错
来源每月固定一份汇率表,月初锁定每月换源,同比断在换源那天
原币保留原币列和折算列都存,不覆盖折算率改了没法用原币重算
差额与财务折算差 0.5% 以内算对齐超这个数说明取数范围或汇率源有问题

两套规则都必须写进表头,不是写在文档里。写在文档里的规则,三个月后没人会去看。

合并前的分歧判定

情况判定怎么处理不合格怎么办
各站口径一致合并按统一时区折算后出表口径没对齐就合,出来的数没法解释
有站点口径不同先统一口径那个站点单独出一版,改造完再合硬合,差异会被当成业绩差距
折算差额超过 1%先对账对齐取数范围和汇率源,再合直接出表,差异下个月会扩大
某站点当月数据没跑完暂缓该站其余站点先合,这站标「数据未到」用昨天的数凑齐,图表上多一段假数据

第二行最耗时间。德国站把退货算在退款月,美国站算在订单月,两个都不是错的。要合就得选一个口径统一改,那不是合并表的工作,是改报表口径。这件事一拖,合并表永远做不出来。

谁做、什么时候做、留什么记录

每月初出上月合并表,数据团队出,时区按各站点本地时间折算、汇率用锁定的那张表。合并前先跑一次对账,把各站单独报表的合计和合并表的分站合计逐站比对,差额写进表头备注。

留四样:锁定汇率表(含来源和生效日)、时区折算说明、逐站对账结果、合并表本身。合并表在共享目录按月命名,同一格式,不另起文件名。任一站点当月口径有变更,合并表推迟到口径统一后出,不出「部分合并版」。

什么时候必须停

五种情况停用:只有单一站点,合并表没有意义;汇率来源当月缺失,这个月不做折算,只出原币分站表;平台刚改完订单状态定义,各站取数状态还乱着,先各自校准;公司刚完成主体并购,两套财务系统的原币口径不同,走并购专项对账;有一站被查出连续两月数据补录,合并表的数据基础不干净,从根上修。

合并表要经得起吵架

全盘对比的价值在于不同站点之间能对质。一个数字被质疑的时候,要能在三分钟内说出它是怎么折算出来的、用了哪个月的汇率表。做不到,合并表就只是一张看起来很完整的图。

← 返回数据团队板块