Evilom
70 lines
5.9 KiB
Markdown
70 lines
5.9 KiB
Markdown
# BOWJwOqOxiARunkCc9Ac3nKwnZS
|
|
|
|
Source: https://ocnmca6f1o0p.feishu.cn/wiki/BOWJwOqOxiARunkCc9Ac3nKwnZS
|
|
|
|
|
|
## 工作内容概述
|
|
1、参加财务会议并整理会议纪要
|
|
2、规划本周工作内容
|
|
3、初步了解财务取数源及取数方式
|
|
## 一、工具现状与功能演示
|
|
#### **已实现功能**
|
|
研究部已完成一套解决【月度管理报告】的 Python 自动化脚本，具体功能如下：
|
|
- **一键生成月报**：上传 5 张子表及配置表，自动输出其中四份子表【利润表取数源、利润表-按月、利润表-分地区、利润表-分产品】
|
|
- **配置表驱动规则**：取数来源、取数列、条件列、计算方式均在配置表中统一维护，规则变更只需修改配置表，无需调整代码
|
|
- **本地化运行**：全程在本地处理，数据不上传云端，满足数据安全要求
|
|
- **极简操作界面**：选择输出目录、上传子表文件、点击运行，三步完成
|
|
- **操作展示如下：**
|
|
|
|
**第一步：规则配置**
|
|
将子表到总表的映射逻辑、取数条件、计算公式，全部提取并沉淀为结构化的配置表。
|
|
|
|
**第二步：数据导入**
|
|
每月编制时，仅需将当月5张子表底稿文件拖入工具指定目录。
|
|
|
|
**第三步：一键生成**
|
|
脚本自动完成源表数据定位、条件筛选、聚合计算，一键输出总表及三张利润子表(利润表-分产品、利润表-分地区、利润表-按月)。
|
|
#### **Codex AI辅助能力演示**
|
|
会议同步演示了 Codex 在日常表格处理中的辅助价值：
|
|
- **自然语言操作**：通过描述需求，AI 部署python环境
|
|
- **历史变更追溯**：可查询操作历史、回溯历史版本，弥补 WPS/Excel 记录不足的缺陷
|
|
- **介绍功能：**可根据语言描述，自动解决表格类操作问题
|
|
## 二、财务部反馈
|
|
#### **达成一致：**
|
|
- **推进方式：**优先通过python快速解决短期痛点、并通过中长期规划
|
|
- **工具实操测试：**5月份报表（人工与工具）双线并行
|
|
特殊支持：1-4月份有个别预算规则需要修改调整——研究部协助完成
|
|
- **操作界面足够简洁**：非技术人员可直接上手
|
|
#### **继续推进**
|
|
**（一）增加同比、环比计算维度**
|
|
- 提供历史数据作为基准年数据源。
|
|
- 在生成总表及子表后，自动计算同比、环比指标，无需人工另行拉公式。
|
|
**（二）探索在生成报表中保留公式及取数来源**
|
|
- 当前工具输出的报表为静态数值，财务反馈希望在输出表中保留公式链接，以便数据变动时自动更新，同时支持快速溯源。
|
|
- 技术层面需探索：在Python脚本生成Excel时，以写入公式替代写入数值，同时建立子表到总表的公式引用路径。
|
|
- 该需求为当前最高优先级，团队将优先验证技术可行性，若可实现，将显著提升报表的可审计性和下游使用效率。
|
|
## 三、深层痛点
|
|
### 目前工具解决的痛点：
|
|
#### （一）**第三阶段：报表编制与合并**
|
|
该阶段原涉及跨表取数、公式编写、手工汇总等高强度重复劳动。核心体现在以下三个层面：
|
|
- 将原有依赖个人记忆的映射逻辑、取数条件、计算公式，提取并沉淀为结构化的配置表。
|
|
- 通过唯一指标编码建立子表字段与总表单元格的对应关系，使规则可读、可维护、可复用。
|
|
- 基于配置表驱动，脚本自动完成源表数据定位、条件筛选（按游戏分类、收入类型等维度过滤）、聚合计算（SUM/分摊等），一键生成总表及利润子表。
|
|
- 消除手工编写SUMIFS、VLOOKUP等函数及跨表贴数的重复操作。
|
|
- 配置规则一次搭建后可跨月份复用。
|
|
- 当源表结构发生局部变更，仅需调整配置表中的索引参数，无需重新编写计算逻辑。
|
|
### 目前工具暂未覆盖的部分：
|
|
#### （一）第一阶段：数据收集与导出
|
|
数据源获取完全依赖手工，该环节占整体工作量的约1/3。
|
|
源数据分散在金蝶、摩卡、中控后台、BI、广告后台等多个独立系统，系统间无数据接口打通，无法实现自动归集。
|
|
由于部分业务系统未开放程序化访问接口，无法通过脚本或接口自动取数，只能依赖人工登录系统手动导出Excel，构成自动化链条上的硬性断点。
|
|
深圳与厦门两地财务人员共同维护公盘数据，数据变更缺乏通知机制，容易产生版本不一致或覆盖冲突，影响上游数据准确性。
|
|
#### （二）第二阶段：数据清洗与口径统一
|
|
口径差异广泛存在于历史数据与跨部门数据两个维度，清洗工作高度依赖人工。
|
|
2022-2023年数据与2024年后的数据，在表格格式、分摊规则、字段命名等方面均存在显著差异。进行历史累计分析时，需完全手工重新梳理和统一口径，耗时大量时间且结果准确性存疑。
|
|
各项目组对相同指标的命名方式和统计口径不统一，合并报表时需人工逐一识别并翻译映射。直至财务数据交叉比对才暴露问题，少记成本导致整个分析决策链条失真。
|
|
#### （三）第四阶段：验证与校对
|
|
当前仍以人工经验驱动为主，缺乏自动化对账与异常拦截机制。
|
|
目前主要通过人工对比上期数据、凭经验识别异常波动，缺乏系统化的规则校验层。
|
|
与金蝶总账系统的数据交叉比对为当前主要验证方式之一，但金蝶数据产出时间较晚，验证存在滞后性，无法在编报当期同步完成。
|
|
尚无自动化的异常标记或拦截机制，高风险科目完全依赖人工逐项审查，效率低且存在遗漏风险。 |