用设计的思路解读“库存锁定”功能

用设计的思路解读’'库存锁定'’功能---实施顾问需具备的系统架构思维几次在微信中提到用软件架构的思想去学软件，今天更有感触，基于标准产品的交付会越来越少，标准的核算和基础的HR项目也会越来越少，更多的项目一定会向业务延伸，而且延伸的程度会越来越深，这意味着标准产品交付的模式将会受到冲击，基于标准产品下的个性化开发会越来越多，如何在利用标准产品、利用现有系统平台，通过一个好的业务设计实现用户的需求的能力，对实施顾问会越来越重要。要具备这个能力，首先要学会用软件设计的思想对产品功能进行深度剖析，渐渐的你会能站在产品的架构层面看产品，你就会对产品随心所欲。用一个例子来说明，我们用两种思路来学习"销售订单，，这个功能。首先用常规的产品功能层面来学：销住祈单对采购g务、生产W芳的暗响 群等……I段博皆订叩为中心的发货、出作、开票、靖弥业务 帽督订单中客户定制化业务小g销衅瓷4,流程 销售可单的功能 基本订单操作绡答订单客尸信用- 销售订单中何折格策略膏祚订帕与廊存显的控制 销住II单号沓同的美系我们开始一项一项的学习，从订单的基本操作增删改查审开始，到订单的所有相关流程，多订单相关的各种控制，例如价格、合同、信用、收款、库存控制等，再到销售订单对生产、采购的影响功能，甚至订单中个性化的客户定制化的BOM，其实你还是学的很不错。不过我们今天换个思路来学习，除了掌握上述功能，作为一个管理科学与计算机技术交叉的行业，除了产品功能和业务实现外，我们来尝试从软件设计角度学习一下订单，再进一步，就深入理解一下销售订单锁定库存这个功能。我们知道很多流通企业都有一个需求，希望在客户下达订单时，检查仓库是否有货，有货下达订单结束后，能对这些库存锁定，不能挪为它用。我们开始想象如何实现这个功能，先不管软件，我们可以这样分析一下，想到如下两种第一种：库存就像一个水池A，但客户下达订单后，我们把A水池的水移动到B水池中，A中的都是可以随便使用的，B水池中的都是名花有主的，这样我们只要随时检查A水池是否够；第二种：在A水池上增加一个计量刻度，每次下订单后，就将计量刻度按照订货量上升一点，刻度之上的可用，刻度之下的名花有主。这两种方法第一种显然是自由的和锁定的完全隔离，第二种实际上都在一个池子，可以互换，只要整个池子还有水，当然第一个方案属于强硬型方案，可以理解为库存硬锁定，第二种方案实际是通过可用量在控制。从程序设计角度去看，第一种方案简单粗暴型，直接上去把库存给分离出去，所以我们可以想象一定有一个库存分离的过程存在，系统控制的是自由库存中是否还有数;第二种方案比较温柔，没有把库存数据直接分离走，而是通过不停的计算是否还有可用量是否大于0。我们也可以分析出第一种方案，由于有数据分离的过程，所以更加可控，例如我们完全可以控制分离多少出去，可以更灵活的处理一些特殊场景，而第二种只是简单的通过仓库和订单的量来计算，比较理论，从控制的角度看可调节性较差，但从另外一个单据管理的灵活性看，第二种显然比较灵活，因为第二种没有实际的分离动作，数据还混在一起，所以系统不会控制订单与分离锁定数据之间的逻辑关系，第一种方案则需要考虑这个关系，因为对订单的影响也就更复杂，所以一个不太规范的管理，用第一种方案实施难度较大。上面用形式化的语言描述一些一下方案后，我们再想想从系统角度如何实现了，第一种方法把库存都搬走了，剩下的属于可用的，对应NC系统，就有对应搬走的单子（当然不是出库单，只是一种内部的库存锁定单据），就有剩下的现存量，于是系统可以实施记录这个存量，通过这个存量你就可以实现控制。第二种实际并没有被搬走，也没有相关单据反应这种库存的控制，实际上是通过一种总额控制模式，于是你会想到，他应该是通过现存量预计入库-预计出库（订单未出库量）二可用量，可用量大于0意味着还有可用库存。于是你再想到第一种方案可能是通过一个静态的结存数控制库存是否可用第二种通过一个动态的公式计算是否可用。再进一步，我们都可以找到上述业务在NC中对应的操作节点，例如库存的锁定，可用量的计算公式设置等。于是我们可以更深入的思考了，第一种方案我们说搬走了，其实只是一个系统动作，可能并没有实物上的动作，我们所谓的存量这个静态的值，其实也是计算机算出来的，系统是否真需要这个被搬走后的静态值存在？我们完全可以用系统中的数据（入库-出库-锁定）来计算这个值吗？但是系统却真不是这样的，再向后台深入一步，发现后台真有一张独立的现存量表来记录这个实时库存（NC中是ic_onhandnum,U8中Currentstock），为什么需要，再分析，可以想象这是为系统效率着想，想想如果有大量历史数据，每次都从所有的历史数

据中计算库存，需要花多长时间啊，但是每张单保存时把实时库存更新一下是很快的。由此很快我们很快明白了，为什么系统会有一个现存量整理功能，用来修正错误的现存量，冗余的数据库设计，提高了效率，必然造成稳定性下降。当然如果你富有供应链的经验，我们可能曾经发现，这个整理似乎也有点Bug，如果某一个存货结存为0后，一经整理，这个存货在现存量表中的记录就没了，偏偏系统的盘点单中的存货就是取的现存量中的数据，这些没有结存的存货就不出现在盘点单上了，系统中没有结存，并不表示不盘点，于是这里出现了一个小小的难题了，当然你会说那就保存那些为0的记录行不就行了，也许真的可以，不过我们再研究下面的问题后，你会发现这个问题也不那么简单。为什么个现存量

整理对盘点产生

了影响？为什么会有一个

静态的现存量

表？销售订单库存锁

定的实现为什么会有一个为什么个现存量

整理对盘点产生

了影响？为什么会有一个

静态的现存量

表？销售订单库存锁

定的实现♦现存量整理的功能？上面我们研究了一下存量的一些设计思路，不过我们还需要向前一步，从数据的角度，研究一下现存量表的后台存储:

-IT1-甘网陆率自由厕&刍航评手立由1殖略m庆他&刍顷F也自由I页9尊自工臣11：尊浦针旦登互金失勉日期佥•吉出毛亘真垣拿惜凡途敛1金品产苴办月基争毛正导农辰为&核咛■市奠瓯牢村我首［里D定蚤隹字汗学氐'0碍FK*圭¥很7职切巨0皿右旦「卜：尊•星拒寻］■亨挨’0吉出旦冬告出朝呻聿惜旭拿吉兀辅教里金蚯择锹h.望仔存存存存存存雷调调调耳F自由项K编号s量量量量量数数数量4量量数哥费费养量蜘量数数量U8123456ml—-JI-页页贝页页页页页I-I-I-III-II-田田田田日日日日自目目目自自自自我们可以发现两个密码，一是发现现存量是没时间概念的，现存量都是最新的，由于没有时间概念，于是可以理解了为什么系统虽然参数不允许负库存，但是系统有时查看报表却产生了负数，由于控制表无时间概念，所以如果单据时间不规范就可能出现问题，例如用较大的时间做了入库单，再用较小的时期做出库单，所以有时候用户会查库存告诉你某一天出库量大于那一天的库存来证明软件似乎出错了，其实系统就是这样设计的；第二个秘密更重要，从现存量表的字段可以完全可以判断系统对库存的管理维度，因为显然现存量表决定了系统的控制维度，这个维度也显然就是库存系统的管理维度，例如我们看到有库存组织、仓库、存货、主计量、供应商、批号、辅计量，自由项等，这些维度都反映了库存数据的管理维度与精度。很容易我们发现无论NC还是U8没有物料状态（待检、报废、可用等）这个维度的，所以这个需求只能另想办法。所以我们能从现存量表看到整个库存模块的管理粒度，从一个点上你就抓住了整个库存管理。在这个地方我必须出一道思考题了，在现存量表中，仔存存存存存存雷调调调耳F自由项K编号s量量量量量数数数量4量量数哥费费养量蜘量数数量U8123456ml—-JI-页页贝页页页页页I-I-I-III-II-田田田田日日日日自目目目自自自自第一个方案分析了一遍，发现后面隐藏着现存量这个大鳄，分析一下第二种方案，第二种方案是现存量结合一些公式计算，公式计算就有不稳定性，因为公式需要从不同的地方取值，这不是个简单的问题，例如想到了如果订单不发货，订单部分发货，他们会怎么对可用量产生影响，分析一下就明白了订单的关闭等一些列功能是多么的重要了，再开动脑筋，关闭这个操作虽好，但是有时挺复杂的，大宗物资采购经常都有一定量的误差，造成订单处于一个部分完成的状态，如果都去人工处理关闭，多复杂，于是终于明白了为什么系统有自动关闭策略；既然是公式，不同企业的规则就可能不一样，于是就需要设计不同环境下的可用量计算公式。所以，即使一个看着挺小的功能，后面隐藏着不少业务与相对应的系统设计。先就说这多，就一个库存锁定的功能，也许我们随口一说系统支持，但功能的背后却隐藏了现存量这个设计从现存量这个设计我们甚至能够认识整个库存管理对库存的管理程度，甚至找到了各种功能缺陷的真正设计原因。如果我们更深入的研究锁定，销售订单的实例还只停留在销售和成品仓库的锁定，再分析一下生产有关的材料锁定，再向采购与加工环境延伸，怎么从订单环节开始锁定，就一个锁定功能，甚至可以打通整个业务系统。就这样我们从业务推功能，从功能推设计，从设计追数据，再从数据又能发现系统的设计，从这些设计你又能明确系统能实现，能怎么实现那些功能，于是我们愈发清晰和明白了，业务、功能、架构、数据都开始融为一体了，这也许就是气功中所谓的