我的天

之前说到了某个Power Query的方案，有两列新增需要填写的部分可能不是我想象的那样。之前我的理解是，新增的那两列填写的内容跟前面的进出数据对应。如果没有进出，那两列也就没有数据。因为一直以来，在我印象之中。那套表格需要关注的重点就是期初数以及期间的变化数而已。周四下午的某个时点，我突然意识到，其中一列需要填写仓号的那个部分实际上要求的不是那一天的仓号，而是对应有库存的仓号。如果只是很简单一两个仓，那么即便有变动，填写也不会太困难，但是我们单位与这数据相关的仓号有超过20个。哪怕一天变动几个也不得了。因为一个变动就一味着一段时间都在变动。一个需要在A4纸上打印的表格，一个表格里面的某个单元格要填写20多个仓号。首先，就这个填写方式来说，已经是不是给人看的，没人会去看那么密密麻麻的东西，根本就是瞎整。

在我印象之中，以前去做代储监管别人的时候，代储单位很早以前就需要填写仓号这个东西，他们的操作是什么时候变动就什么时候增加或者减少仓号。对他们来说，绝大多数时候都不会同一时间变动多个仓号。他们代储的数量不多，所以涉及的仓号也不多。没有变动的时候，直接一大片合并单元格。变动的期间可能就那几个仓，所以也是合并单元格。总的来说，因为代储单位需要使用的仓房不多，所以还能表达出来，但显然对我来说就不太行，对那些储存大米的单位来说，一个大仓里还得分到不同堆位，采购成本不一样。同一天，可能有多个堆位发生变动，所以我那二十几个仓以每个单元格都填写的方式去处理是不可能的，对那些一个仓房里面有十几个堆位的大米仓来说，更加是会让人发疯。想到这里的时候，我赶紧给集团公司的相关人员打电话，然后被告知，实际上这个表增加填写内容也是被迫无奈的选择，所以仓房那里实际上并不需要考虑变动这个问题，反正把那个月涉及的所有仓号都写上去就可以了。因为仓号那里主要想考核的内容是那些仓号是不是已备案的账号，有没有把粮食放在别的仓房里，因为如果那样就违反规定了。听到那里的时候，我有种如释重负的感觉，因为要把所有仓号都填上去比较容易，首先我要获得期初有库存的仓号，然后把本期有变动的仓号和期初合并，最后做一个去重，我就可以很容易地获取那一大批的仓号。

另外一个需要填写的内容采购成本，既然仓号得这么操作，采购成本理论上也应该是对应那一天库存的平均采购成本。如果所有东西都没有变动，填这个数据完全没有难度，一旦发生变动，这个数据就变成了无解的难题。你要精确算出那个数据要花费很多精力，首先你得把每天出入的那些单价全部都搞清楚，但这只是一个变化数，其它没有变动的你也要获取，打电话的时候我并没有想到该怎么办，但是电话挂掉以后，我就想到了可以引用一个期初库存值来解决这个问题。基础数据那里，如果有一个期初库存，也有一个期初采购成本，合并每天进出的变化数就能计算出累计库存以及累计库存值，最后再用一个累计库存值除以一个累计库存，就能得到每天对应的那个总库存的平均采购成本。在有系统的前提下得出这个数据是易如反掌的，但是在纯人肉的操作下，要这么折腾计算，那个数据的准确度基本为零。没有人真的能核算出那个数据到底是不是正确。电话这头的我和电话那头的集团公司相关人员都是这么觉得的。在这个管理办法还没有颁布之前，他们就已经为了这个问题去找过粮食局的人，但是最终的管理办法下来后，发现还是没有把采购成本从每日必须填报的数据里去除。

上面某些人的脑残，真的会让下面那些人没法活。

花了一个上午的时间，让某个Power Query的查询更进一步，花了一个下午的时间修改级联下拉网站的一些格式问题。无论是哪一个，我总感觉都不够完美。

Power Query的查询，之所以我感觉不完美，倒不是因为我的数据有什么问题，我或者我的解决方案有哪里不妥，而是需要我们填写这一张报表的人，脑子不知道想不知到底是什么。那是一张信息高度集中的报表，但为什么要把那么多信息在一张表上反映呢？里面要有每天的进出数据可以理解，要有每天的库存数据，也可以理解，因为期初库存加上进出的数据，就可以得出每天的库存。每天的库存是有要求的，必须得表达出来，这个可以理解，每天的进出数据具体来自于哪里，要把那写明白，这也可以理解，但是在2024年7月1日即将实施的某个规定里，要把采购价格也写进去，这个我就很不理解。采购价格跟这些进出有什么关系吗？又或者说任何一笔进出数据，一定就能轻易关联到采购价格吗？如果每天变化的只是一个仓，设定表格的人难道觉得采购价格就应该是一个固定值？实际上某天某个仓按照不同的合同，实际上可能有多个采购价格，那个仓严格来说，我是不是要做一个加权平均？某天多个仓发生了变动，有进的也有出的，进的那些仓一个仓有多个采购价格，出的那些仓，哪怕我已经不按先进先出或者价高先出之类的规则，直接把那统一为一个均价，这也意味着存在着很多采购价格。采购价格这个东西，完全没办法从原始凭证里面得到，每天某个品种要填写进出数量，但是涉及仓号那里，进出都填在一起，采购价格那里如果有多个价格就取一个均价，但是这个均价该如何取舍呢？单仓先做一个均价，然后每个仓房按照数量跟价格再做一个加权平均吗？最后出来的那个采购价格代表了什么？算出那个数很不容易，但是算出了那个数，又能怎么着呢？那不代表任何东西。做出那个是完全没有意义的，为什么非得把那个数给算出来呢？硬是要把那个数算出来以后，最终会导致这张报表采购价格那个地方出来的东西是个四不像，用什么资料去验证？其它数据都是确切可以算明白的，但那个地方的数据却只是一个大概差不多的玩意。不知道这么脑残的决定到底是谁做的。想出这么个招的时候，居然没有人去否定他。如果有一天，信息化程度真的可以实现把报表要求的数据都自动的算出来，我举双手双脚赞成，但是还是那句话，加权再加权得到的平均采购价格到底有什么用？又或者对普通人来说，对正常的人来说，根本没办法做那么仔细的加权平均，所以最终我的暴力解决方式是首先算出那个月变动的仓房有哪些，然后指定那些仓房的采购价格，每天有多少个变动仓房就直接把那些仓房的采购价格算术平均。

工作的时间越久，越让我深切地体会到：上面不正常，会让你憋死；下面不正常，会让你气死，横竖都是死。

又花了半个下午的时间，把前一天已经做出来的Power Query再进一步优化，但是有些细节还是没想到该如何处理，比如说某些品种的价格会发生变动。五个仓本来是三个不同的价格，但是可能到了某个时点，要把它全部都变成一个均价。该如何表达这种东西呢？理论上，那个时点，无论是用三个单价，还是用一个均价，哪一个乘以数量都应该是一样的东西，但是那个时点应该放在什么地方呢？还有就是，那不属于一个出库或者入库，所以不应该有任何的价值变动。如果是完全相等的，还能说得过去，但是如果分明就是直接从一个价格变成了另外一个呢？所以我不知道之前干这个东西的会计到底是如何实现，因为我无论如何用任何单价和数量都得不到她算出来的某个价格。所以到底她用的是什么样的单价呢？又或者说，之所以我算不出，是因为她把一些之前可能没有减掉的东西，也一并减掉了，又或者是反过来，但我完全没有那个信息，所以我没办法完美地把这个模拟出来。

十几年前当我第一次接触数据统计的时候，那个快要退休的老大妈用的方法是在Excel里做一个很大的二维表。因为仓号很多，日期也很多，她选择的是以日期作为横坐标，仓号为纵坐标，她的那张大表得连续用好多张纸才能完整打印出来，然后用胶水把它们粘起来。也有好一段时间，我也在重复着她干的这个事情，不过我再也没有打印出来。因为我没有打印出来，所以我跟她的思路有点不一样，我把横坐标跟纵坐标调换了一下，因为就拖动鼠标来说，纵向比较容易实现。

又过了好多年，他们又把我从一个全职检验员变成了一个全职统计员，所以我又得跟这些数据打交道，但那个时候，我就再也没干这种事情。我已经不记得什么机缘巧合之下我认识了数据透视表，可以肯定的是不是因为任何一个同事教我，也不是因为学校里面有任何相关的信息，但不知道为什么，我就突然间通窍了。在那以后，二维表这种事情都是数据透视表干，我只需要把一维数据处理就可以了，但实际上身边的人，无论他们一直跟数据打交道，还是只是个初出茅庐的人都一直在不断地填写着二维表，不断努力地把二维表的数据更新到新的二维表里面。这个东西我非常反感，因为就数据处理来说，非常容易出错，比如某个地方理论上应该是一个公式，但你却把它贴成了纯数字，那个地方就算是彻底完蛋了。如果你检查的时候没有发现这个问题，这将成为一个永远的系统错误。这种在二维表上原来是公式的地方贴成了纯数字，又是一个非常容易犯的错误。所以我真的很敬佩制作那个国粮局报表一开始电子版的那个人。他把纯数字的地方跟公式的地方用不同的颜色填充。一开始我不知道不同颜色有什么用，但突然我就不小心发现了，填表变得简单。你千万不能动某个颜色的地方，填数就仅仅在某几行或者某几列。这真的是一个很绝妙的事情，虽然接到那张表的时候，没有任何一个人告诉我原来那个东西是这么用的。现在已经有了国粮局的网页直报系统，在某些行里填数，数字会自动汇总到另外一些你不需要填的行里，需要填写的背景是白色的，不需要填写的背景是绿色的。对老司机来说知道该怎么办，但如果老司机带新手的时候不跟他说，汇总的那些不用填会自动生成，估计新手会觉得要把汇总的部分也填上去了，但实际上可能那些绿色的部分根本不允许填数。现在的国粮局系统是这样，以前的电子版大概也是这个道理。会有些人不明所以，会在那些本来是公式的地方，贴纯数字，于是，本来完全不需要你操心的部分就变成了你全部都得兼顾了。可能从前国粮局的那个报表不是单位的某些人发明的，而是上面下发下来就默认带有那些颜色，但是他们又做得不太彻底，比如有公式的部分没有设定为完全不允许修改。

数据的处理，当你真的用心了，才会有真的感悟，而不只是遵循别人的“规则”。

我花了三天时间（但实际上每天都只有半天时间）把二维报表提取数据成以一维数据表。这有什么难度呢？一开始我也认为好像难度不是很大，但开始琢磨以后我发现事情远远没有我想象中的那么简单。我用的是Excel的VBA。如果操作简单的话可以在Excel的数据层面进行操作，但如果我要进行大量的数据清洗显然为了要追求效率，就必定要用到数组，数组这种东西无非就是不断地叠加循环以及判断。循环和判断我觉得几乎可以这么说，是编程的核心。要实现最终的目标，首先你得有一个非常清晰的逻辑，然后用那些循环和判断实现你的逻辑。当我看到某些人逻辑彻底混乱的时候，我心里就会冒出一句话，他们绝对不会懂得编程。也正是因为这样，所以现在的幼儿教育有时会把编程列为一个非常重要的项目，实际上练习编程就是锻炼逻辑，但是逻辑这种东西又分为了既定的规则以及你的自创招式。自创招式都来源于各种规则，但是不同的编摆方式会有不同的效果。成功编程的话效率极高，是秒杀型的，但是要制造那个秒杀效果的过程可能非常漫长。

我需要处理的那个报表，准确来说是一套报表，但是用的几乎都是一个版式。虽然看上去几乎一样，但是有可能某些细节上会有不同。如果我用了一个靠谱的逻辑去抓取数据，无论什么微调，对我来说都毫无影响。所以首先我要确定我要在报表里抓取什么东西，我要用什么方式去除掉那些我不需要的东西。如果用Excel表格的思路去理解的话，我肯定是先做一个筛选，然后把我不要的删除掉。如果不要的东西在行那里我还可以用关键词筛选掉，但如果那些东西出现在列那里，难道我要先做一个转制，然后再做删除吗？更郁闷的是那个表格的表头有三行。就一个现成的要达到最终效果的报表而言，三行的表头没有任何问题，但是如果你要把它按照数据层面去理解，这就很逆天。就更加不用说这三行的表头里面还有不少合并单元格，但幸好的是当我把单元格拆分了以后，实际上每个单元格里其实都有靠谱数据的。

我的思路是先把我不要的行删除掉，然后把我不要的列再删除掉。在删除行这个问题上一步我就搞定了，但在删除列这个问题上，我花了好几步，首先是删除没有数据的列，其次是删除含有某些关键词的列，也就是那些虽然有数据，但对我来说也没什么作用的列。把可以删除的东西都删除掉以后，我进行了一个二维表转化为一维表的操作，接下来就是在那个加工完的表里加一列存放表名。之前我说过我要处理的是一组样式差不多的表格。上面说的一大通，我只是说针对一个表我需要这么处理，所以在这之前我要有一个把文件夹里所有工作簿里面包含某些关键词的工作表汇总到一个工作簿里的步骤。我觉得这个合并工作表的耗时挺长，相对于后面的数组操作来说，这实在太费时了。之所以会这么耗费时间，是因为实际上Excel需要把工作簿一个个打开，抓取里面的某个工作表，然后关掉，不断地重复这个步骤，不断地开关工作簿会非常耗时。

如果之前我没有花过很多时间在账本的合并数据上，现在突然要我整这个的话，我肯定得花好几倍甚至十几倍的时间，但因为现在我是站在曾经自己的肩膀上的，所以虽然期间有过纠结，但总的来说还算是比较顺利。我考虑过要不要进行这种操作，但过去几年我都一直没这么干，因为要合并这些数据，一年只做一遍，有没有必要开发这样一个VBA脚本去实现呢？当那个报表被国粮局修改了，我又得重新修改脚本适应。所以之前我就在那里纠结到底有没有必要进行这个脚本的开发。

最终我做了，而且还做到了。

有种慵懒什么都不想做的感觉。不知道下周的出差会怎样。因为据说另外一组已经出去回来了，理论上是三天，实际上两天就回来。倒不是因为东西真的很简单，而是因为本来要去4个地方，结果两个地方的资料都已经被纪委收走了，没东西可看，当然也就只能打道回府。一开始我根本没想过这些东西可以这么快就结束，但显然可能我有点高估了，但也有可能快乐是别人的，与我无关。我到底要去哪里？到底要去多少天？到底要去做些什么，我都不知道。

今天我把去年已经领回来的一本关于流通统计的书翻了一遍，发现里面只有几页纸是与我有关的，其它的那些和我都没什么关系，更重要的是，与我有关的那几页纸实际情况又跟我们有差别。所以里面到底有多少东西是可以接收的呢？实际上真没有多少，于是这也带出了另外一个问题，为什么我们现在正在做的那些事，居然没有一本教材可以很确切地说明白要做什么，要怎么做，以及为什么要这么做？

检查了一圈下来，发现大家有各种各样的问题，实际上很多时候是因为大家不理解，为什么要那么干。比如为什么要在账本上分来源和去向，而且如果那里的地方不是一个的话，必须要分开。之所以这样是因为那实际上是跟国粮局的报表对应的。进行采购和销售的时候，就会有一个省外的空格，如果你分不清地方，那该怎么填呢？如果你还要填流向的话，那就不仅仅是省外那么简单，就得分清到底是什么的具体哪个地方。即便不需要精确到某个地市，但是省份这个信息还是必需要的。有些人把生产年份全部都混在一起写了，于是数量就一只有一个，但一个公给通单元里生产年份却有好几个，如果把生产年份这么搞，同样也是国粮局的报表。库存数量分生产年份的几列单元格又可以怎么填呢？其实我个人觉得账本跟报表实际上是一个衔接的过程，理论上账本上的数据应该是由原始凭证那里获得，但实际上。原始凭证上面反映的信息往往不足以支撑账本上的内容，比如说我不可能在每一张原始凭证上都写明产地以及生产年度。但是最终国家要求的报表里面就得有这个东西，所以根据原始凭证生成账本的时候，就得把那些之前没有的信息带入。这就让我产生了一个疑惑，实际上生产年份以及产地这个信息是不是应该跟每一条原始记录完全对应上呢？从数据的聚合来说必须得这样，但是实际操作过程中。好像我根本就没办法要求客户把每一车每一船上面的这些信息都写得如此确切，每一条船还相对好一些，每一辆车，每一个集装箱都这么整的话，肯定会让人崩溃掉。但是崩溃归崩溃，实际上这些东西都是应该具备的。所以说最终我们是不是应该把思路反过来，确定我们最终必定要得到哪些信息，然后从那里反推我们最原始的数据结构至少应该具备哪些信息？

我们经常会觉得自己平时用得很溜的那些东西，在别人让你系统讲述到底该如何操作的时候会一脸懵逼。实际上是因为可能我们一直都没有非常完整地去考虑过，那到底那是怎么回事？如果都遵循着某条规则，我们可以完成所有的操作，当然很理想，但在实际操作过程中，我们又有太多的例外，当例外大于规则的时候，自然我们就会处在一个没办法说清楚自己到底在干什么的状态。

彻底的搞清楚工作的全流程，是一个自我升华的过程。