我的天

从粉到黑其实完全不需要经过什么大波澜，可能只是无意之间等一件事而已。一直以来，我都是Office的粉丝，非常拒绝WPS，现在我依然不喜欢WPS，尤其当我有点迷恋上VBA以后。之所以VBA，因为数据透视表已经在某些方面无法满足我懒的需求了。但我只是一个新手，所以即便是很简单的东西，我的VBA脚本也要经过很长时间才能琢磨出来。

爱上周我突然发现自己Microsoft 365上面的Power Pivot不能用了。昨天，我又突然发现，原来自己连Power Query也不能用。这两个不能用，意味着所有高端的Office功能全部歇菜。这些东西全部都不能用以后，我付费的Microsoft 365和从前不用钱，而且体积还很小、几乎不出错的Office 2003，仅仅只剩下界面比较好看，公式多了一些而已。从Office 2003到Office 365，我花了很长时间，因为一直以来我都不觉得自己必须改变。因为工作上某些公式打不开，某些功能很厉害，但我做不到。在深思熟虑以后，我才终于换到了Office 365，但是当我的Office 365。用了不到两年之后，Office 365，变成了Microsoft 365，进而发生了Office软件里最强大的功能居然失效这种事。这是我电脑自己的问题吗？但我又不能完全保证这只是某台电脑的问题，为什么单位这台机就不能开，家里那个就没问题呢？两台机都是64位的Win7，理论上应该差不多。之所以会发生这种事，是不是因为家里那台机我没有进行升级呢？虽然微软说2020年1月他们已经停止对Win7的支持，从那里以后，Microsoft 365仅仅能得到安全更新，但实际上不是这样的，因为他们新的函数，我通过更新也能使用了，而且在我完全没有察觉的前提下，插入界面也多了一个叫做加载项的东西，那里的内容一定是新的，之前我没见过，不仅仅是我没见过，我之所以判定那是新的东西，因为那个功能居然还没有翻译成中文，部分东西是英文的。这就意味着这个功能并不完全成熟，就像在Office 2016的家庭及学生版里，Power Query用的是英文界面，到了Office 365，那个东西已经是内置功能，不再是加载项了，那已经融入到了软件本身。既然微软条款上说，只对Win7系统下的Microsoft 365，进行安全更新、没有新功能，但实际上新的函数可以用，界面上也有一些不知道是什么东西的家长进怎么理解？我非常有可能相信，两个强大的Power数据处理是为他们故意屏蔽掉的，但这只是我的猜测，或许真的是我的电脑出了状况才导致那两个不能用呢。我需要回家好好验证一下。功能不能用，我把错误代码拿去搜索，得出的结果很少，而且通常都是Power BI的。数据合并这种东西如果不用Power Query，就自己写个VBA。至于Power Pivot的思路，应该能在其它更强大的数据分析软件里用，因为这可是Office 2010就可以插件使用的功能啊！

微软的作死，只会让他死得更快！

对别人来说，做某件事就是从系统上读取某些数字，抄在纸上，然后不断地敲计算器，得出某些数据，然后再按照某些格式整理成别人要的样子。之前我也是这么干的，但是我觉得，这实在是太累人了。我要做的不仅仅是读取系统上的数据，我做的是读取我自己的数据，然后跟系统上的做比对。做的东西必须是最小单位。明细对好了，后面的汇总是水到渠成的事。我觉得，汇总数据这种事，规则我定下来，结果应该是自动生成的，管好我的明细数据，汇总数据就不会出乱子。汇总数据出来了以后，还得按照某些格式整出来，这其实是一个填坑的过程，但是应该怎么填呢？逻辑的思路就是，如果有数据就展示出去，如果没有数据，就为空。这是主要思路，但某些细节问题其实也是需要考虑的，比如说数据与数据之间的标点符号：逗号，分号，句号，冒号等等。没有数据的时候，那个地方是空，但是在连接两个数据之间，有些人默认带入了标点符号，于是就会出现一个神经质的状态。数据与数据之间有一大堆莫名其妙的标点符号，正常情况下，那些东西都不应该存在。按照人的思路，那些东西根本不可能存在，但为什么有那些东西呢？显然是那个做判定的人没有把标点符号写到判定里。什么时候应该逗号，什么时候应该句号，当没办法判定哪个才是最后一个的时候，标点符号怎么办？其实真的不能判定吗？肯定是可以的，当某个元素的序号等于这个数组的最后一位，显然那个东西就是最后一个了。在Excel的世界里。尤其是不考虑VBA，只考虑前台的公式，这个逗号的判定在我现在的能力范围之内，的确有点难，所以遇到这种情况，我干脆每个数据给它一行，每行数据的末尾，不加任何标点符号。

昨天我突然意识到，Excel的公式编写是可以插入空格和回车的，当然，空格和回车要加在恰当的地方。比如加在数据连接的地方，不要加在某个函数里。又或者其实加在某个函数里面也是可以的，但是如果你在表达字符串的地方加入了很多空格，最终的结果肯定会哭。也正是因为回车的加入，让我的公式看上去更整洁了，我不用纠结不断地眼睛急转弯。复制粘贴也变得相当的容易。的确复制粘贴很简单，但是粘贴得多了，每一行的数据框架都是一样，只是修改了里面的部分内容就会让我自然而然想到使用循环。如果Excel的公式里有for或者while这种循环该多爽。换句话说，为什么就不能有循环呢？之所以这样，大概是因为Excel，没想过你要么在某个单元格里面展示一堆合并起来的字符串。这种字符串的合并，理论上更应该出现在Word或者普通的txt里面。

我首先写了个索引，然后写了个数据，接着对数据进行数据透视表，最后写了个很长的公式。根据数据透视表和数据透视表以外的一组数据，生成了两段字符串。字符串里面所有数字的格式全部都严格按照我需要的模样输出。这样做的确实现了我想要的功能，但我感觉还是有点麻烦，如果写个VBA，加入数组，这些东西很容易就能表达出来。从前前台看来，也会干净利落很多，但问题是，加入VBA的话。Excel的保存格式就得改变。对小白来说，VBA是个洪水猛兽。他们不知道该不该允许宏这个东西。如果我是他们，我不了解这个东西。这个东西的确有安全隐患，我肯定不会主动打开，即便我知道这个东西可能很强大。

开源的东西用起来得花一些步骤。组装好的东西用起来的确用很爽，但问题是，万一里面有猫腻呢？归根到底，还是自给自足、自娱自乐比较好。

不知不觉好像我已经快一个星期都没有碰python了，原因是在家的时候我懒惰，在单位的时候，一心在整理各种各样的数据，也正是因为我正在整理数据，所以其实在我的骨子里是念念不忘想使用python这个大招的。在数据处理方面。我觉得，我正在用Excel人肉操作的那些，如果以一个正确的方式丢给python，那绝对是几秒钟就能完事。明明我知道可以这么干，但现在我还没到达那个境界。

昨天我整了一个巨长的公式。在最开始的阶段，我在普通的Windows记事本里折腾，但是当公式嵌套得越来越多以后，显然普通的记事本把我直接看晕了。我把那个东西放回Excel，但实际上Excel这个怪物根本不给我显示到底那些一对又一对的括号谁跟谁匹配。我也试过把那条长长的公式放到VS Code里，我随便打了个py文件往里面放Excel公式。虽然某些地方高亮了，但是括号匹配还是很不行。如果那不是一个Excel公式，而是一个python文件，我早就给它写很多注释、搞很多回车了。不就是个嵌套了三层的if嘛。但实际上，如果这是在python，完全可以不嵌套，用三组平行的if就解决问题了。最终，我把那条很长的公式贴到了Notepad++里。经过一番折腾，我觉得Notepad++才是最适合编辑Excel长公式的工具。虽然Notepad++不能自动生成成对的括号，但是在判断括号对应性方面，我感觉已经足够了。他们会把成对的括号用加粗的红色显示。当你选择这一边的括号的时候，那边的括号就红色加粗了，这样我就能搞清楚自己编辑到了哪一层括号。习惯了用python之后，什么括号，什么使用范围之类的东西全部用冒号、用缩进就解决了，回到Excel里要用一句话表达，本来用三句短话就能表达清楚的东西的确挺烦人。为什么Excel编辑公式就不能用回车，不能用缩进解决问题呢？如果有几个回车的话，显然那条公式到底在表达什么就很明白了。在Excel的某个单元格里回车，那就是要执行公示的节奏。如果是数组公式，你还得用组合键结束。有时我实在不明白他们为什么非得一定要用组合键呢？为什么不能在公式外面加一个什么函数包裹，让软件明白就在执行数组公式呢？

习惯了python的简洁与人性化后，回到Excel让我各种不习惯。在python里，单引号和双引号都可以用来表达那是字符串，但Excel要表达字符串，要表达某些固定格式，必须用双引号。另外一个人让我不习惯，因为我已经彻底忘记的就是在Excel里面不等于用的是<>，而在其他编程语言里面，不等于的表达方式是!=。所以当我在Excel里使用!=的时候，Excel懵逼了。于是我不得不去搜索，进而发现是我自己搞迷糊了。还记得小学的时候，家长们总担心孩子如果一边学汉语拼音一边学英语会不会张冠李戴，用汉语拼音来读英语或者用英语来读汉语拼音。这是两种彻底不一样的东西，虽然他们的最终结果就只是个发音而已。我是小学一年级开始学汉语拼音的，三年级的时候开始学英语口语。在我开始在学校正规接触英语之前，我的汉语拼音已经很熟练了，而在我接触编程语言之前，我接触过Excel，但只是接触过而已。对二者的深入了解几乎可以说是平行发展的，所以混淆二者的某些基础用法我觉得可以理解。

最终，我把那个我想做到的效果用一条很长的公式表达了出来。那条公式针对的不是具体的某些单元格里面的东西，所指代的位置全部都是相对的。所以根本不存在拖拉以后会出现状况。有了这条公式我就彻底做到了对某个仓开始入库、结束入库以及期间库存精准定筛选定位。

那条长公式在成功整出来之前，我先在纸上列出了几个条件。代码这种东西是非常讲究思路的啊啊啊。

要实现某个功能，有非常多的做法，到底要怎么做才能避免出错呢？Excel的函数非常牛逼，把那些公式弄好了，简直就是天下无敌的节奏。公司的原理很简单，但是套用起来做着做着就傻瓜了。有可能是手贱，标点符号按错了，更大的可能性是单元格引用出错。我已经不记得用Office 2003的时候是个什么状态了。反正在Office 365下面，如果在一个工作簿里面应用了别的工作表，把带公式的工作表复制到另外一个工作簿里的时候，那些引用的单元格会以绝对地址的形式继续指向原来工作簿的某个表。显然，如果只是指向本工作簿的话，找不到地址，顶多显示错误，但是如果那东西继续指向原表，会引发很多问题。因为那是一个绝对地址，即便你把工作放在同一个文件夹下面，还是不能解决问题。恐怖的绝对地址会导致云同步、在多人协作的时候，发生状况。为什么Office 2003下就没有绝对地址和相对地址这个烦恼呢？在Office 365下，数据透视表的绝对地址算是终于改正过来了，但我想不到公式居然也这样。这是一个令人非常崩溃的事情！如果工作表里面的公式是大量的，这将是一个灭门灾难。如果某一个工作表里面的公式是大量的，而另外一个工作表里面的源数据也是大量的，外加还有一个数据透视表指向了源数据。无论是动哪一个，都会导致另外的那个上的工作推倒重来。为什么就不能设置某个工作簿里面的链接采用相对工作簿内的连接，而不使用外联呢？停止了外联，就意味着那个单元格的数据从一个动态的东西变成了静态的。绝对地址这个问题，在云同步、在多设备协作的情况之下，根本是无法操作的，为什么微软会犯如此低级的错误呢？数据透视表的傻逼是发生在Office 2010版之后的。公式上的傻逼，之前貌似我还没遇到过。可能并不是因为不存在，而纯粹是因为我没有用到这种功能。

但Excel不能一次性满足我所有想要的东西的时候，我就会想到要不要自己写个脚本解决一切难题。人想得到的逻辑，用脚本都能实现，前提是必须考虑出一种能够包容所有例外的规则。如果不能包含特殊情况，脚本写出来是毫无意义的，因为最终还是得人手去加工，这非常不科学。所以一定程度上，我更喜欢用数据透视表，自动处理那些东西，而不是手动设置公式。设置公式理论上是一个一劳永逸的过程，但实际上只要你手动在上面修改了一些东西以后，就像蝴蝶效应一样，后果不堪设想。某一次的修改，会导致往后半天都找不出原因。如果用数据透视表的话，双击单元格就会到达最基础的那个数据。查错是非常简单的，但是，用了公式以后，然后你又因为某次犯傻在某个你以为设置了公式的单元格里面输入了常数，那将导致一次令人绝望的debug。不要问我为什么会知道……

与其让我查找错误，还不如让我总结特点制定规则，让他们不犯错误。当然，不犯错误，是根本不可能的。

很多人听到审计的要去查，就会非常紧张。审计到底有多厉害？如果我对自己的业务非常自信，我会怕吗？的确我没什么好怕的，但是我的队友不知道自己要怕。昨天我见识到了一份审计发过来的罪证单。当然这不是直接发给我的，是发给我领导的，但要我去研究该怎么答复上面提到的问题。接到那个文件的时候，我震惊了。因为那是一个宏的Excel。这样的保存方式，就意味着里面一定有一些牛逼的东西。我自己也是一个写脚本的人，我当然知道其中暗藏武功秘籍。那个文件看上去数据不多，但是却非常大，这让我挺震惊。后来我发现可能是我想多了，因为之所以大，是因为里面贴了几个图片，所以很大，并不是因为里面的数量非常恐怖。

拿到那个文件的时候，我不是对数据感兴趣，而是对里面的脚本感兴趣。到底他们写了什么脚本，可以在那么短时间之内汇总校对出我们的数据，然后发现问题呢？后来我发现，其实，他们没有在里面写脚本，我一页一页地翻查过了，但是他们用了宏函数。他们把那些东西隐藏起来，比如说把带公式的工作表隐藏起来。隐藏工作表很好破解。起码他们没有用带密码的方法到锁定工作表，完全不让我把隐藏了的东西取消隐藏。让我觉得有点惊讶的是，他们居然就这么坦荡荡地把他们的研究结果发过来了。他们就不怕我们偷师吗？正常人见到这样的文件早就已经瑟瑟发抖得无以言表了。其实我更想知道他们在得出最终的这份问题清单之前是怎么快速的处理我们的数据的。在数据的汇总以及财务业务处理方面，他们实在是精英，不只是这样，他们对所有东西都非常好奇。他们简单来说有学者的脑袋再加几岁小孩十万个为什么的心。一定程度上，我应该害怕这些人，但是实际上，我却挺喜欢他们的工作风格。他们做的事情跟警察探案没什么区别。他们把一些我们这里的人害怕去面对、囫囵吞枣应付的事情非常有条理地罗列出来，得出结论，并告诉你你犯了那个天条。那种细致和博学简直是到达了一种让我莫名崇拜的地步。

崇拜归崇拜，最终我的领导把那个文件发给我就是要解决上面的数字问题。让我兴奋的是，我居然发现有一些我们的数据跟他们的数据有很大差别的地方原来是他们的公式写错了。明明是应该乘0.6的地方，他们用了除。我不知道他们为什么会犯这种错误，是手误吗？因为其他工作表的同一个公式没有问题，唯独其中两个出差错了。也正是因为那个问题的存在，所以我们的总数在那一块跟他们相差了好几万块钱。在阶梯式计费方面，我觉得他们的公式已经用得很好了，但是即便你厉害到天上去，还是难免会发生某些疏忽。于是，这就启发了我要去研究到底用什么样的计算方式才能减少这种问题的发生，甚至是杜绝这种问题再次出现。

在遇到审计之后，我有种相逢恨晚的感觉。