Evilom
70 lines
6.1 KiB
Markdown
70 lines
6.1 KiB
Markdown
# MV29wcO5NiMgbWk3AuvcUygqn0b
|
||
|
||
Source: https://ocnmca6f1o0p.feishu.cn/wiki/MV29wcO5NiMgbWk3AuvcUygqn0b
|
||
|
||
|
||
## 工作内容概述
|
||
1、财务取数工具进行对比差异、进行图像化显示、研究可复用性方案
|
||
## 一、 通用Excel报表模板框架开发
|
||
开发通用Excel报表框架时，验证了一个重要的设计原则：**好的框架设计不是寻找完美的工具，而是用简单的方法对冲底层工具的不足**
|
||
最初我低估了问题的复杂度，以为直接使用现成模板引擎就能实现**Excel公式的自动填充**
|
||
结果踩了大坑：**底层引擎会把Excel原生公式识别为普通文本，根本无法生成可计算的单元格**
|
||
### （一）核心问题与解决方案
|
||
- **模板引擎无法正确渲染Excel原生公式**
|
||
- 设计"占位符+后期替换"机制，先在模板中用自定义标记代替公式，渲染完成后统一替换为真实公式
|
||
- 避免了繁琐的逐行拼接代码，以极低的成本解决了核心问题
|
||
- **动态数据展开后，公式引用位置无法自动更新**
|
||
- 增加**行号自动修正机制**，在数据展开的同时实时调整所有公式的引用坐标
|
||
- 确保多月份、多产品线动态报表的计算准确性不受影响
|
||
### （二）框架沉淀
|
||
目前这套"Excel模板+占位符"的方案已初步成型，我后续将它优化为可复用的基础模板框架，具备以下核心能力：
|
||
- 支持复杂Excel公式的**自动生成和动态调整**
|
||
- 支持多维度数据的**循环展开**
|
||
- **完整保留**模板中所有的格式、样式和条件格式
|
||
以前写脚本都是解决一个具体问题，现在沉淀出通用框架，才能批量解决一类问题。能大幅提升未来新报表的开发效率。
|
||
## 二、 财务工具桌面端
|
||
财务自动化脚本的桌面化改造时，有了一个深刻的认知：**技术工具的价值，不在于核心逻辑有多复杂，而在于用户能不能零门槛地使用它**
|
||
过去我总陷入技术人员的常见误区，认为只要**业务逻辑正确**，让用户**装个运行环境、配个参数只是举手之劳**
|
||
但实际落地中发现，对非技术背景的业务同事来说，**任何额外的部署步骤，都是工具被闲置的开端**
|
||
### （一）核心问题与解决方案
|
||
- **原有工具**：只能通过命令行启动，需要用户安装运行环境、手动配置文件路径、修改参数
|
||
- **改造方案**：
|
||
- 采用三栏卡片式简洁布局重新设计界面，**将所有路径选择、参数填写功能整合至同一窗口**
|
||
- 通过自动化编译打包，**将全部依赖项集成到一个轻量独立文件**
|
||
- 增加了**可视化进度提示**和**友好的错误处理机制**
|
||
### （二）改造效果
|
||
- 财务同事**双击即可运行**，无需任何技术配置
|
||
- **彻底解决**了困扰已久的"装环境"痛点
|
||
- 工具从"技术人员专属"变成了"全员可用"
|
||
**关键结论**
|
||
真正的自动化，不该让业务迁就技术，而是技术要主动适配用户的习惯。过去我总将业务逻辑的实现放在首位，如今深刻体会到：**让用户不用折腾就能用，才是工具真正能产生价值的关键。**
|
||
## 三、 项目拆分规则配置化改造
|
||
完成项目拆分规则的配置化改造时，深刻体会到：**财务系统的核心竞争力，不仅在于自动化程度，更在于对业务变化的响应速度**
|
||
这个拆分规则特别繁琐，涉及**账簿名、公司名的精确匹配、模糊匹配，还有各种排除逻辑**
|
||
一开始差点就图省事写一堆if-else硬编码了，但仔细想了想，**业务规则以后肯定还会变，硬编码只会越堆越乱**
|
||
### （一）核心问题与解决方案
|
||
- **原有方案**：所有拆分规则硬编码在代码中，规则变更需要开发人员修改代码、测试、发布
|
||
- **改造方案**：
|
||
- **扩充配置规则的表达能力**，在配置表中增加包含、排除、模糊匹配等常用逻辑
|
||
- **设计通用的打标机制**，所有业务规则都通过配置表实现
|
||
- **核心代码保持简洁**，只负责执行配置好的规则
|
||
### （二）改造效果
|
||
- 业务规则变更时，**无需修改核心代码**，财务同事自己就能在配置表中调整
|
||
- **大幅缩短了规则变更的响应时间**，从原来的1-2天缩短至几分钟
|
||
- 避免了硬编码导致的代码腐化和"屎山"问题
|
||
### （三）数据准确性验证
|
||
财务系统容不得半点差错，一分钱的偏差都可能导致整个系统失去信任。在端到端测试过程中：
|
||
- 发现并修复了后处理模块漏掉一笔费用分摊的问题
|
||
- 全量跑通后，最终结算金额与手工样表**完全一致**
|
||
- 实现了业务数据的**精准咬合**
|
||
只有经过真实业务数据验证的自动化，才是真正可靠的自动化。将业务规则配置化，不仅能提高系统的灵活性，也能让业务人员更深度地参与到系统的维护中来。
|
||
## 四、 Excel报表格式稳定性修复
|
||
排查Excel报表损坏问题时，得到了一个重要的教训：**高度封装的第三方库虽然能提高开发效率，但也可能成为系统中最隐蔽的风险点**
|
||
之前一直用的第三方Excel操作库，在追加辅助列保存的时候，**会悄无声息地删掉模板里自带的透视表底层链接**
|
||
导致输出的所有报表都直接崩溃，而且**这个问题在开发环境中很难被发现**
|
||
### （一）问题排查与解决方案
|
||
- **问题现象**：生成的Excel文件打开时提示损坏，透视表无法正常工作
|
||
- **排查过程**：逐步缩小问题范围，最终定位到第三方库在保存文件时会丢失部分内部结构
|
||
- **解决方案**：**果断回滚原有方案**，改用更基础的方式直接操作Excel文件结构
|
||
- **额外优化**：让引擎能够自动适配新增的列，提高了框架的灵活性
|
||
不要盲目信任成熟的第三方库，高级封装的黑盒一旦出问题，排查起来特别困难。对于涉及用户核心数据的操作，要优先考虑稳定性和可控性。**工具交付给用户用，操作简单是底线，底层稳定才是生命线。** |