我的天

渐渐地我越发有点明白自己想要的到底是什么。之所以让我纠结了半天，不知道该如何计算的某些数据，实际上是因为两种性质的东西混搭在一起了。我不知道别人是否真的搞得清，他们是有意糊弄我们的吗？是因为他们知道我们算不清这个，所以这么搞吗？这个问题很困扰我，是因为那个东西把正常的批次跟没有写明批次但要先进先出的混搭在一起。有明确批次的数量计算是不分仓号的，因为通常那意味着好几个仓进同一批货，开始计费的日期定在第1个仓刚开始进货的那天。所以，如果同批次还有其他仓，最后一个仓进货的时候可能已经是3天后，那个仓的免堆期等于要减去三天。如果某个客户所有东西都这么弄，不会有烦恼，因为无论进货还是出货，肯定会带入批次。

在Power Query的世界里，这就意味着要以批次和日期分组。各种仓号数据可以全部加在一起，无所谓。但同时，这个客户又有另外一种情况。如果他进货不是用船，而是用车，每天几千几千吨进货的话，我们跟他们签订的合同是按每天为一个批次。一个批次到达免堆期以后开始计费。现在我们的系统总的来说，根本没分清这种批次，计费完全是人肉计算的。但实际上，这种没有批次的批次，理论上也应该自动带入，入库的时候以日期为批次。所以有可能发生同一个批次有几个仓出库的时候，要以先进先出进行批次划分。进货的时候，一个批次可能有几个仓，但是出货的时候肯定是指定的。所以在这里要以仓好为分类，然后在对入库批次分割数量。比如某一个仓里第1个日期批次用完了再开始用第2个，第2个没用完，就留到以后继续分割。据说用SQL和Power Pivot能解决这个先进先出的问题。但貌似，我看到的Power Pivot的例子没有看到我想要的最终结果，也就是把那个出库数量自动分割成入库批次。先进先出是非常经典的会计问题，只不过我们的人从来都是我觉得我要指定这个，没有用过这些规则，当然也就没有思考该怎么自己动手去计算。一开始没有批次，用先进先出的规则，入库的时候自动添加批次，出库的时候按照入库的批次风格，最终得出来的数据，跟之前一开始就已经有批次的东西可以用同样的规则继续演算。

对我来说，有两个点我没想明白。首先，要怎么在PQ里以先进先出的规则，对出库数量进行批次分割呢？第二，因为实际上我们得到的信息是一个入库日期和出库日期。而这些日期通常都是不连续的，在不连续的日子里也要计算每天库存，到达一定时间之后，要每天计算堆存费。所以，该怎么在不连续的日子里插入一些日期，然后向下填充信息呢？之前我想到的办法是先建立一个日期索引。然后把有数据的东西合并到索引里，这就意味着有些日期可能是没有数据的。接着，把这些东西透视展开，把数据为空的那一列删掉，余下的东西向下填充，然后再把零数据替换为空，接下来再用一个逆透视恢复。这个方法比较笨。但可以一次性实现N个批次的插入和填充，至于速度如何，估计跟电脑的性能有关。我总觉得高手一定不需要用到这种先透视再逆透视的方法。他们是怎么插入日期，然后向下填充数据的呢？

想清楚了这些，离我想要的最终结果就会又近了一些。

每天都在论坛解决别人的问题。一定程度上，我是在磨练自己，当自己的工作好像没什么新思路的时候，就需要一些刺激。有些非常弱智的问题，我会懒得去回答，但很高深的问题，又不是我能解决得了的。所以这其中也挺纠结，到底什么类型的问题才最适合让我去练手呢？我自己有问题，尤其是案例类的东西、跟数据直接相关的东西，我就没想过要放在论坛里问高手。通常我都是四处寻找答案，再不行，我就截图问身边的人，但无论如何，我都不会把数据发上去，尤其是工作类的。如果只是我个人的blog，所谓，反正都写了这么多年，根本没有秘密。但其他东西。不能这么随意公开，而我也没有真的遇到一个我自己解决不了的问题。有些时候，我想实现某些功能，但经过一番操作之后发现，即便能做到也很麻烦，所以我就直接绕过去了，因为不一定非得那样做。这条路不通，我就走别的路，直接放弃这条路。这也是我的快乐之处。在别的单位，可能领导会要求你必须得这么干，就要这样的格式，就要这样的数据。不管你用什么方式，但实际上那样的格式、那种模式数据实际上是很逆天的。我运气好，暂时还没遇到这种事。当然我也遇到过类似差不多的事情，比如应该写0的地方他们要写杠。把格式设定为逆天，实在让人觉得非常无语，但幸好我的领导是一些挺懒的人，某些格式一旦定下来就不怎么改，而且因为他们懒，所以定下来的固定格式也不多。

蹲在论坛解决别人问题的时候，我发现自己是一个很没有耐心的人。当别人提出某个要求，我又实现了以后，我觉得就大功告成。但之后那些人居然会在之前的基础上，不断加新要求进去。如果你有很多要求，为什么不一开始就说清楚呢？哪怕可能你根本没想到有人真的能做到你想象中的那样，如果做不到的话，别人会直接告诉你这个思路是错误的。绕了好大一个圈，解决了问题，但事后说这个问题只是开胃菜，还有后续那些。一次两次加料之后，我会觉得那人好烦，这完全是他自己的东西，为什么不一开始就摊出来说呢？遮遮掩掩到最后还是要慢慢的托出，简直在浪费大家的时间。当东西整出来以后，我发现有些时候他们一开始那个思路是错的，一开始因为无法全盘考虑，我就被他们默认带错路了，绕了好多个死胡同。他们自己的数据，他们最清楚其中的来龙去脉。但显然当他们把数据拿出来求助的时候可以看出，其实他们完全是蒙圈的。这些操作对我来说最大的好处是那些教程上面的东西经过一次又一次使用后，我开始有点行云流水了，虽然有些时候还是会很迷糊，但现在总算是有点头绪。之前我觉得，同样是列名，有时用中括号，有时用双引号，莫名其妙，但现在我几乎搞得清是一个什么状况。虽然在使用函数和引用数据的时候我还得不停琢磨。

你们不安排我培训，我就自寻培训的途径。

数据本身没有问题，如果我们不能让它们确立某种关系，只是因为我们对那个东西还不够了解而已。在Excel里做一件事，你可以通过很多方法，比如说函数，比如说VBA，比如说SQL查询，又或者Power Query或Power Pivot。当然，我这里所说的，主要是针对查询，或者说数据清洗类的东西。如果纯粹是针对单元格的格式化，函数以及Power BI系列以及SQL是没办法做到的。

同样一个数据，用不同的方法都可以得出目标答案，但是哪个会更简便快捷一些呢？函数我觉得挺被动的，尤其是在处理大量数据的时候，效率非常低。因为在处理一些复杂东西的时候通常要用到数组函数，即便不需要用到数据函数本身，其实也在运用着数组函数的变体。而且函数这种东西受Excel本身版本的限制，越是低版本的Excel越是没办法轻而易举地实现某些逼格的功能。于是就出现了你不得不为了某个功能升级Excel，又或者因为你的伙伴升级了Excel，用了一些高端的函数，但是你却看不到，工作就没办法继续下去了。SQL和VBA是两个大杀器，很早以前Excel就已经支持。与其说他们是Office软件的一部分，不如说这两个东西更接近于编程语言。我对Excel里面的SQL不是十分熟悉，因为至今为止，虽然已经折腾了不少网站，但是我从未试过操作数据库。SQL在Excel可以用，但我觉得可能在Access里SQL会用得更顺手一些。比如说如果改变数据源，比如移动文件之后，SQL需要重新连接。若没有VBA的帮助，这是无解的。我不喜欢用SQL的其中一个原因是它会在硬盘的某个位置生成某个数据库。

VBA这个东西强大到任何你想到想不到的东西都可以控制，无论是数据本身还是说单元格的格式，一律通杀，它甚至可以让Excel自杀，又或者让你的系统自杀。VBA用得好不好直接决定了某个脚本的运行效率。是对初级用户来说，VBA的学习成本实在是高，除非你从来不打算要建立自己的规则而纯粹只是用别人的东西。

至于Power BI系列的Power Query和Power Pivot现在我仍然处在甚至还不能说入门的阶段，我只是稍微了解了一点这两个东西。在数据清洗和建立关系的时候，它们实在太强大了。但是要使用这两个东西，Excel的版本就必须有要求。所以这也导致了不少免费用户直接绕过这两个强大的东西。我也不知道为什么自己在使用Excel高级函数几乎还没入门的情况下，我就去折腾M语言。我觉得那个东西一定程度上颠覆了我对数据的理解。Power Query对数据的处理方式就像通过各种蹂躏就能得出你想要的东西，其间你没有修改原数据，所以实际上在写M语言的时候就像是手工编写一个宏，而那个宏要比一般的VBA简洁很多。之所以简洁，一定程度是因为那是在高级套用的前提下。Power Query里玩的数据转换实际上是在折叠、删除以及扩充，一定程度上就像是在用类似于递归或者迭代的方式。

别人把时间耗在应付考试上，我把时间耗在折腾自己上。

昨天在设计某个Power Query查询的时候，我遇到了个问题。只需要做一个非常简单的IF判断，但貌似是不能直接用IF处理步骤。那些不过是非常简单的东西而已，如果符合这个条件，用这个步骤，如果不符合这个条件，用另外的步骤。我之所以被拦在那里，大概是因为我还没搞清IF使用的场景关系。判断步骤从理论上说再普通不过了。我该怎么做到这个呢？之所以有这个困惑，因为IF的判断，在举例子的时候，大都用在添加列这个功能里面。如果符合这个条件，就添加这种，否则就是另外一种，当然你也可以添加一大堆筛选。我正在开始构思这篇东西的时候，突然意识到，我要处理的实际上是一个列表。既然是一个列表，在后面引用的时候我就没必要把所有东西都摊开，我在前面就做好判断，后面直接一个判断好的列表扔过去就可以了。有些步骤我进行了排序，但是实际上排不排都无所谓，因为最后这些东西会到达数据透视表。月份参数必须排序，理论上那个参数不仅仅要排序，而且还应该以日期的数据格式展示出来。昨晚上我发现同样引用同一个数据表，如果我在展开的时候，不加以说明，反而会得出正确的东西。如果纯粹用可视化的操作，会有画蛇添足的效果。我的数据必须得用我想要的方式表达出来，如果默认的东西不对，我应该改到对为止。这一次我运气好，我没有解释某一列到底是什么东西，系统读对了，但有些时候情况不是这样的。当然，也会有我昨天下午遇到的那种情况，系统默认的不太靠谱。最终，我忍耐了那个不太靠谱，但是。既然有了晚上的的经历，系统默认画蛇添足的部分根本不应该存在。

一开始我只想实现某个功能，但在实现某个功能的过程中，我发现以前我的那种分类有点想太多了，因为根本没有必要。那些东西都是独立的存在。与其进行二级分类，不如多做几个一级分类。一级分类的非重复计算实际上用的都是一个模板。既然是模板，我当然可以用外部引入数据的方式实现动态筛选。关于非重复计算这种东西，加入了模型的数据透视表能轻而易举地做到，但经过这段时间的摸索以后，我发现Power Query只要能打开，基本上不会出错，但是Power Pivot我搞不懂为什么会出错，为什么会卡机。那个东西卡机的概率我感觉太高了，之所以有这么高的概率，也可能因为我用得比较少。有时我只是写了个非常简单的度量值，出来了以后，度量值不知道为什么选不上，不知道为什么选上了以后电脑就弹出了某些界面，关掉了以后Power Pivot的选项卡就消失了，但是你依然可以进入。关掉Excel，再次打开，Power Pivot的选项卡没有了，你得在加载项那里把那勾去掉，再重新加回去。实在说不准为什么会这样。如果不把那个曾经导致问题的文件的模型删掉，打开那个工作簿的时候永远存在这种问题，其它工作簿不也会被连累。删掉那个错误后，还得重启电脑才能解决问题。很久以前Power Query也是Excel的插件，但后来，那个东西已经不再是独立的选项卡，而直接内嵌到软件了，而Power Pivot在Microsoft 365里依然是个选项卡，依然要借助COM加载下。这就意味着这个东西还没有到非常成熟的地步。所以或许某一天我要玩Power Pivot的时候，我不在Excel里面玩，而会跑到Power BI里折腾。因为起码那样的话，我就不用烦恼Excel的加载项老是消失这个问题了。

越研究就越知道自己什么都不知道。

追加查询这种事，2句话搞定，这实在让人太震惊了，但实际上，两句话里其实暗藏了许多玄机，高手用一句话完成了几个步骤的事。能做到这样，绝对是因为对函数这种东西了如指掌。

source = Table.SelectRows(Excel.CurrentWorkbook(), each List.Contains({“表1″,”表2″,”表3”},[Name]))[Content],
result = Table.Combine(source)

Excel.CurrentWorkbook()这种东西通常我们都是后面搭配{[Name=”某表”]}使用，那是点名使用，一次只能一个，但实际很多时候合并工作簿都是里面同型号的表全部合并，如果全部都用这种，得列多长的清单。高手的代码里，还可以把List.Contains变成Text.Contains，如果是list那就是点名要哪些或者不要哪些表，如果是text那就是直接筛选表的关键词，包含哪些关键词或者不包含，各有所长，都能实现。如果命名很规律，那是简单到爆炸的事，即便命名不规律，也能用排除的方式忽略某些不想合并的表。你或许会说，既然是合并工作簿，为什么不直接用从外部文件的工作簿获取呢，那样直接就到位了，选择的时候也很自由，因为那是可以可视化操作的，而且不需要实现把工作簿加入到表，我觉得最根本的区别在于移动文件的时候，外部获取你还得更换数据源，当然了，这个可以通过自动获取数据源地址的方式实现，但直接CurrentWorkbook是最没有烦恼的。要把工作簿里所有表都变成超级表，这在收集和整理表格的时候其实也是有难度的。所以这种一次性用CurrentWorkbook包揽工作簿的方式我觉得最好不要超过10个，3-5个是最合适的。通常，如果用追加合并，可视化系统生成的是Table.Combine{{“AA”,”BB”,”CC”}}类型的多个表格列表，而高手的代码里，source其实就是一个表格的列表。轻描淡写之前，处处暗含玄机。要做到这样得非常清楚每个函数需要什么数据，可以生成什么数据，玩弄的正是表格、列表、记录的互相转换。

同样是contains的功能，list的是后面跟前面对，对上就true，但text是前面跟后面对，对上就true。对我这种初学者来说，这是很迷糊的事，谁先谁后到底是最定义这些公式的，为什么要这么郁闷呢！有这种吐槽大概因为我不熟悉，对高手来说估计是没有疑问的。到底建立这些M函数的时候，他们是怎么分配工作的呢？类似的功能一个人负责？某个统领下的函数一个人负责？最后有没有对“.”以后相同，功能类似东西做比对呢？对我这种懒人来说，类似的函数能用复制粘帖修改就不会用重写这一招，但显然，他们的脑洞估计不是。

看书对照操作是一回事，融会贯通又是另一回事。