ERP CRM系统，结合人工智能方法来开发设计和维护。

[披着虎皮 的石头]

ERP CRM系统，结合人工智能方法研发新一代erp系统。
目标，就是开发和维护 实施成本大力降低，软件性能和质量提高很大。
同时更好满足erp的通用型，行业通用型，企业个性化需求。

[披着虎皮 的石头]

高度概括配置化erp平台 应用程序 =算法 +数据 =众多核心微算法 +个性化算法 +业务配置数据 +用户数据 =众多核心微算法 +个性化算法 +业务配置表及数据 +用户表及数据 =众多核心微算法 +个性化算法 +业务配置表定义 +业务配置表数据 +用户表定义 +用户表数据。 其中， 1 众多核心微算法、业务配置表定义，相对少变。 核心微算法，就是软件的精华部分， 需要前期投入很多的精力时间研发测试， 而后续工作量很少，主要是修补问题或增添新的。 2 个性化需求算法，是随机需求算法实现，很少且要硬编码实现。 3 业务配置表数据，可以事先做好模板数据， 遇到实际企业需求，可以根据情况修改数据。 4 用户表定义、用户表数据、可以事先做好模板表， 遇到实际企业需求，可以根据情况修改表。 配置化平台成熟以后， 遇到同类相似客户，经过需求分析以后， 需要二次开发，主要花费较多时间在： 1 修改业务配置数据。比较容易。 2 设计用户表结构。 比较容易。 3 个性化需求算法。 稍微有点难。 而不用反复关注复杂的核心微算法， 这样开发测试上线速度很快。 再往前看，就是预先设定要各种行业的配置化模板， 然后结合用户要求去快速二次定制， 这样扩展发展成本比较低，商业上有很强竞争力。

[披着虎皮 的石头]

配置化ERP是人工智能？ OK: 数我愚钝，你说的我不懂 嗯涉及到计算机原理 软件编程、数据结构 CPU 内存 网络 当然还有企业管理 财务管理 人际关系 资金管理 身体管理 团队管理 要熟悉这么多，才可能出配置化erp系统 简单理解，就是ERP软件企业的精细化，创新发展的思路 程序 =算法 +数据 算法就是就是程序文件和CPU 数据就是数据 程序文件，是特殊的数据文件，送入到CPU后， 就转化为指令，指令去读取各种数据，进行计算，然后输出数据 模拟计算器开始，但离人工智能比较远 配置化ERP，就是精细化软件，有点类似人工智能了 通过微内核算法的强化功能， 然后放入大量各种行业的业务配置数据，定义用户表， 就快速完成erp项目的开发和实施。 所以往大了说，配置化erp平台开发， 就是erp系统在往人工智能方向上发展了，不在‘傻傻乎’走老的开发路了。 配置化ERP平台开发和扩展用途，就是微内核， 大量的不同配置数据，发展思路和人工智能类似的， 比如围棋alphGO类似，都是有核心算法， 然后有大量的棋谱数据。 所以一不小心，就闯入了很前沿技术开发和实践领域 不过肯定也不用太高兴， 最多也是ERP系统的初级人工智能，要达到很高的智能， 需要不断强化核心算法， 也要用大量数据(业务配置表和用户表数据)作为基础。 所以做好erp的初级人工智能，就是很大的进步了。 ERP系统开发，自发 往初级人工智能方向发展 围棋有段位：业余段位 专业段位， 但出来了人工智能alphoneGo， 最厉害的围棋冠军，都败给人工智能了 :erp也有如此发展方向， 从根据用户需求的人工硬变编程，朝着人工智能， 算法和数据分离方向发展。

[披着虎皮 的石头]

1101 Erp配置化设计开发思路 java版erp，主要技术设计，分数据库、中间层、界面层。 1 数据库层，和delphi层类似的设计，以前文档已经说过。 2 界面层。主要js xxx等开源架构。 1 如果采用运行时，生成动态界面， 读取配置数据，来动态创建界面控件、 读取配置数据，调用js的公共代码。 非常依赖前端项目自身功能，技术难度很大。 但研发成功后，就不需要频繁编译和发布界面， 后期开发和维护很简单。 此方案，目前不具备技术能力， 另外动态生成界面文件，也会耗用时间， 让用户等待延时，在客户端多时，并不好。 2 如果据配置数据生成静态界面文件，再编译。 读取配置数据，创建界面控件、和调用js的公共代码， 最后形成各个静态前端文件，再编译、发布。 不太依赖前端项目自身功能，技术难度中等。 主要是写一个独立的程序： 根据配置数据，生成一个个界面文件， 里面有界面控件、调用公共js(vue)的代码。 研发成功后，仍需要频繁编译和发布界面， 后期开发和维护，相比手工编写，简单很多很多， 相比运行时动态生成界面，开发和配置一样的工作量， 只是编译和发布的工作不少。 此方案，目前初步具备技术能力。 另外生成静态界面文件再编译发布，用户访问很快。 3 中间层。主要是java spring mybatis架构。 1 数据访问层的静态数据类，是OR映射而来， 要么手工编写，要么用IDEA开发工具去生成。 2 java语言或控件，目前不支持根据表， 动态创建数据对象类或及其字段属性。 表字段改变时，要手工或工具重新修改数据定义类， 及其衍生的处理过程中的字段名，然后编译和发布。 因此受开发工具限制，修改表字段时， 必须去改中间层的访问层、中间层源代码，并编译发布。 那意思是用户需求变化(表字段)后， 必须修改中间层源代码，并编译、 停用目前系统，再发布程序，再重启中间层。 那这个是冷启动中间层，无法做到热启动。 热启动说明：中间层启动(中途不停止)， 修改配置数据后，刷新客户端网页，就完成功能升级。 3 java 语言为何不开发类似Delphi的数据集对象， 可以动态创建OR映射表的数据集对象， 那样就不用花很多时间，维护中间层的数据定义类。 java中间层，采用大量简单对象的原因： 1 客户端访问数巨量，每次访问消耗要小，必选简单对象。 java项目，面向互联网应用，网页客户端， 几百、几千、几万、几十万用户访问量， 每个用户访问一次，就复制好几MB大的内存， 用来管理数据集对象(含有很多数据区和函数功能)。 那么平均每个用户访问一段时间， 就要耗用至少几十MB大内存，来存放数据访问对象。 那服务器总需要消耗内存，以GB为单位直线上升。 所以考虑服务器内存量限制， 不允许使用万能动态的数据集对象。 2 java 内存非实时释放，而是空闲时才自动回收。 平时白天不能消耗太多内存，否则在回收前，就宕机。 java语言为了减少程序员的工作压力， 和减少内存泄露风险，默认不提供内存即时回收功能， 而是等到系统比较空闲时，去回收内存中的垃圾对象。 这样如果平时访问消耗大量内存，要到晚上才回收， 那很可能白天内存就耗尽了。 而delphi、C++等语言，是内存及时回收的， 这样每次可以创建很大内存空间、也很复杂的对象， 来处理复杂的业务，使用完对象，代码里主动释放内存。 只是实际开发中，尤其是大型系统，多人开发， 代码量大，可能就会有部分代码，并没有及时回收内存， 这样就出现内存泄露，内存利用率低，甚至发生宕机。 所以java中间层，由于客户端访问量巨大，内存垃圾回收慢， 每次访问，消耗内存须极度小，必选简单的数据对象和处理。 那么就不能采用动态的、万能的数据集(OR)映射功能， 数据集里，访问字段，可根据字段名去动态读取和设置， 不用事先定义好。 只能用简单数据类， 那么改表字段时，就要重新改并编译中间层。 另外java是强类型语言，不支持动态创建类的属性。 所以java中间层，不能采用运行时读取配置信息， 来构建最新的数据类及时属性，那么后续的处理也就停了。 那java中间层，还是如其 xxx界面层一样， 是编译前，根据配置数据生成java中间层代码。 另外在delphi unigui开发上配置化erp系统， 则和java开发，在界面和中间层不同， 是可以采用界面 +中间层混杂一起的， 运行时，读取配置数据，完成界面，调用业务逻辑。 其运行的环境条件： 1 客户端不能多(标准200个)，太多了内存耗用量就很大。 要靠负载均衡，增加应用服务器台数。 2 delphi unigui内存回收是实时的， 所以只要写的好，内存不会泄露。 所以经过以上分析，得出erp配置化， 都可以在java、delphi unigui上实现， 都需要依赖配置数据，但后续不同： 1 java版是前端和后端编译前， 把配置数据自动生成为各类程序文件。 再手工加入个别个性化代码，编译，发布。 2 delphi版是运行时，读取配置数据， 自动创建界面和调用处理逻辑。 个别个性化代码，需要预先编写简单程序文件， 再加入个性化代码。 而频繁编译和发布程序，就省掉，因支持热启动。 具体如何开展配置化项目： 根据不同平台的特点， java版服务端内存消耗少，可适应较多客户端访问。 较适合人数众多企业，比如中型、大型企业。 但其缺点，就是前端技术平台切换快， 中间层设计，不支持热启动， 要重新编译和发布，一般是晚上发布， 增加维护和实施工作量。 而dephi unigui版，很多设计以及优缺点，和java版相反。 我们可以预先设想一下应用场景： 1 给小客户(100、50人一下规模)提供java版， 改动一下功能，都要晚上发布， 用户等不耐烦，开发实施的嫌报酬给的少、嫌工作累。 2 给中、大客户提供delphi unigui版， 客户在访问量大时，就会查询和提交速度会变慢， 然后建议用户增加应用服务器台数。 因为网络中断或合上笔记本屏幕， 再回到网页时，就提示系统连接失败，正在连接中。 用户会觉得其他网页版不会这样，这个怎么会这样。 用户会提出安全性问题，要求部署到linux服务器上。 用户会要求开发方技术资质高，比如人员规模要大， 能提供持续服务，那么选择较少人用的delphi， 就不利于人员规模扩大。 所以根据用户不同，应该提供不同的版本系统， 才是对的，当然2个版本，都是依赖配置数据， 具有初级人工智能的(算法和数据分离)。 这样才会满足不同客户的需求。 根据最近一年java版积累、以及以前积累的经验， 要同时启动两个版本的配置化版本开发。 他们的核心思想就是人工智能，配置化， 只是在实现过程，根据应用场景和平台特点而变化了。 那只启用其中一个行不行呢？ 短期可行，长期不可行。 因为2个版本，分别服务于中小型企业，和中大型企业， 放弃任何一个，就意味着放弃一个未来的市场。 两个版本，一起做，肯定比只做一个的，工作量大， 应对方法： 1 放慢开发计划进度，不要搞太快，太累了。 2 "老人"，带"新人"方式，来加快开发速度。

[神话jsh]

ERP要算法做啥呢，是统计库存的吗，还是统计账户金额。我看华夏ERP就没用到算法啊，华夏ERP的源码是开源的，最近才发现的，整个设计逻辑比较清晰。

[披着虎皮 的石头]

引用 4 楼 神话jsh 的回复:

ERP要算法做啥呢，是统计库存的吗，还是统计账户金额。我看华夏ERP就没用到算法啊，华夏ERP的源码是开源的，最近才发现的，整个设计逻辑比较清晰。

肯定用到算法了，而且算法比较很多，提炼出来的，就是核心算法。 开源erp是开源了，但遇到不同客户，就要二次开发， 这个二次开发工作量，随着用户需求变多，是很惊人的。 所以开源免费的，并是容易入门的，但并不是节省开发和实施成本的。

[披着虎皮 的石头]

比如做一个部门级的进销存系统，和做一个公司或集团级别erp系统， 那用户需求，后者比前者大很多，随着软件规模扩大， 就要考虑分析 开发 测试 维护的成本，想办法， 去提高软件功能，同时又大力降低IT企业的成本。 如果仅仅是拿来主义，拿别人施舍的开源系统， 那就默认就要进行大量二次开发，而且二次开发的东西， 仅适合当前客户，并不能大量重用给其他客户，商业上单位成本太高。

[披着虎皮 的石头]

erp系统，采用人工智能方法来开发的前提条件是很多的： 1 熟悉较好的平台，网页版为先，三层CS系统为次，还有手机版。 2 了解具有企业管理 财务管理等知识和经验。然后再熟悉某些行业。 3 善于与人沟通，因为只有善于沟通，才能为客户提供个性化服务。 4 较好的理财能力，因为erp系统是需要持续改进的，需要资金、人员、技术来维持，都要较多资金。 5 身体要健康，能很久的工作，而不是做着就转行了。 因为 研发 具有人工智能的erp系统的条件比较苛刻，所以 基本上没有人或公司去尝试。 但前途是很光明的。 人工智能流行起来，也是在围棋alphaGo打败了围棋世界冠军后，变为家喻户晓， 所以推广到各个各业需要时间， 但人工智能的核心思想就是算法和数据，可以拿来应用到erp系统开发上， 谁主动去做，就赢得发展的先机。 但如果继续按照常规方法开发，就会重复和别人一样的生活。

[m0_54369894]

来学习一下，看看

[披着虎皮 的石头]

重要1：单据 基础资料冗余(单级) 1 对于业务单据主从表中，存在引用基础资料， 如产品、物料、供应商、客户、仓库、部门、人员、 产品类型、物料类型、币种等等基础资料。 一般基础资料信息的编号和名称和其他关联字段， 是随时会被修改的。 所以一般业务单据，引用基础资料表主键值 XXID， 这样就不会直接受修改编号和名称影响。 标准数据库的完美型，即表设计的范式，就是越高越好， 即表字段设计时，不要有冗余字段，防止不一致， 要保持引用唯一性。 从数据准确性角度看是对的， 但任何事情往往有另一面，就是数据准确性高了， 数据（关联）查询就慢(比单表查询)， 尤其表内数据越来越多时，这种业务表和基础资料表、 或者还混在着业务表 +业务表 +基础资料表的关联(视图)， 系统运行越久就会越慢。 而一般ERP的单据数据，是最近3年的数据不清空的， 这样连续三年的数据都存在系统里，关联查询就会变慢。 所以课堂上，老师教的往往是偏向完美型， 而忽视了力量型速度的设计。 尽信书不如无书。偏听则暗，兼听则明。 所以光是课上得来不是最好的， 考试成绩最好，也不是最好的。 只有不要做书呆子，要多看有用的课外书， 理论和实践结合，才是真理。 2 如何实现业务单据上的基础资料表的冗余字段： 1 定义好基础资料冗余字段定义主表： 基础资料表名或视图、字段ID、字段Code、字段Name， 以及Spec 默认额定规格、UnitName单位。 明细表： 业务单据主表或从表、字段ID、字段Code、字段Name， 以及Spec 默认额定规格、UnitName单位。 这个定义表的维护方法： 1 初始手工维护建立。 2 可以点击编辑窗口上的 获取业务表字段 按钮， 来自动收集到各个业务表的字段值。 3 在晚上时，系统爬虫，去检查以后的对应表和字段对应关系。 并可以自动往里增加明细记录。(新建立了业务表，忘记加了)。 并在明细表中，有一个创建日期的字段。 2019-12-18 不可爬虫自动在明细表增加定义记录， 因为可能会出现超级数或死循环。 可以采用爬虫检查到遗漏登记时，发系统消息， 或短信、邮件等通知系统开发人员。 如果业务表没有，或业务表删除修改了该字段，就删除明细记录。 4 遇到特别的定义，比如移库单主从表上，移出入仓库和货位， 主表有OutStoreID、InStoreID， 从表有OutLocID、InLocID， 如果从表是LocCode，那么就不能随意修改货位编号了， 就要去控制货位编号的修改，比较麻烦。 对于业务表中，特别的基础资料字段名的定义， 只能手工去识别和维护，因为电脑还不具有人工智能， 可以识别相似性。 3 如何保证单据的基础资料冗余字段， 和基础资料表的信息的一致性。 1 平时单据保存时，就根据上述单据冗余字段和基础表字段定义， 把单据的冗余值维护好。 2 当修改基础资料记录的编号、名称等信息时， 根据配置定义表去更新相关表的冗余值。 3 再用系统爬虫去晚上检查，根据配置表，检查单据表和基础资料表， 如果有不一致时，就自动给维护好。 一般情况下，不会有差异，但有时因为系统bug、或导入导出的原因， 遗漏了冗余数据维护，就需要爬虫当守门员把好关。 4 有时因为系统新加个性化功能， 比如采购合同，增加了替换功能， 但在选择了替换物料记录时，仅 4 特别说明，为了减少更新影响， 平时修改基础资料时， 增加Update语句 Where (冗余字段1 <>'最新值1') OR (冗余字段2 <>'最新值2') 等 而不是 Where (冗余字段1 ='旧值') and (冗余字段2 ='旧值2')等， 实际两个都可以， 方法1方便，不用取旧值， 方法2经典，是防并发写脏数据的模式，所以选择方法2。 而在晚上系统爬虫检查时，如果发现不对，就直接Update掉， 不加额外的冗余字段1 =旧值的条件。 5 在原基础资料外键定义表的基础上，改为主从表方式管理。 业务表和基础资料表之间的外键及冗余值， 主要支持三层级关系维护，超过的话，树状数据结构， 复杂性高了，不支持 原先老系统是，没有冗余字段， 大量建立视图关联来保证数据一致性。 6 特别说明： 外键及冗余字段存在级联关系， 需要一级一级往下级单据更新，这个涉及到树数据结构。 理论上是任意层级、树状表的外键关系， 但考虑任意树状关系的开发成本高， 不支持任意层级外键关系，仅支持三层表外键关系维护。 所以在基础表等外键维护保存，或定时爬虫检查时， 默认检查层级超标。 比如仓库->产品->销售订单明细表。 而像产品类型->产品->配方主表->配方明细表， 被改为产品类型->产品->配方主表 产品类型->产品->配方明细。 考虑到三级外键关系维护同步冗余字段值， 会涉及到较多表，尤其是修改仓库、物料类型、产品类型表时， 最好修改时，要提醒保存慢，晚上操作。 不建议采用中间层处理。 而是采用调用sp来处理。 1 sp内主要算法是1-2级之间是单循环， 先查询出各个表的满足条件的记录ID， 并写到临时表，用于2-3级更新用。 再根据当前修改值及ID值，去更新对应下级表。 可加并发修改写机制。 2 2-3级采用双循环，分别是2级表、3级表。 根据临时表的表及主表ID值，去读取刚被修改的最新值， 再去更新3级表冗余值， 更新时，加入防并发写修改的条件。 3 其他说明，1-2级更新后，要不要2-3级更新， 方法1：智能识别1-2级关系是否在2-3级中定义。 这个困难就是1-2级关系的字段名，并不一定和2-3完全相同。 方法2：根据每级的定义关系，分别去判断和处理。 方法1，需要比较1-2、2-3之间的定义关系是否匹配，智能复杂。 方法2，方法简单，但需要耗时去判断2-3级需要更新情况。 目前采用方法2。 4 考虑异常情况的追查性，对数据冗余更新，建立专门冗余更新日志表。 5 复杂更新冗余举例： 更新物料类型名称 ->物料表->采购订单明细表、采购入库明细表等等。 更新产品类型名称 ->产品表->销售订单明细表、销售出库明细表等等。 更新仓库名称 ->物料表、产品表， 但物料和产品表的下级，从智能识别来看， 不需要更新因为下级表没有再根据物料产品记录，来冗余仓库名称。 但因为1-2、2-3间，要根据定义字段名，采用模糊法匹配比较，复杂。 比如配方明细表，增加物料-产品类型名称， 字段名来源物料和产品信息表的物料类型和产品类型， 这个冗余字段取名：ResTypeName、或RGTypeName， 但不会取名GoodsTypeName，这样产品类型信息修改时， 1-2、2-3级定义中，字段名是智能模糊匹配才可识别，太复杂。 类似设计也出现在销售订单明细、研发销售明细的物料类型冗余字段， 因为都是一个字段值来源与多个基础资料表时， 冗余字段名就不能兼顾到多个基础资料表， 必须模糊定义，并手工配置。 所以改为仍然较低效率去单独判断2-3级的冗余关系， 担然最后都是不需要更新的。 7 2019-12-18，上面的一些分析设计过于复杂， 再次特别特别说明，来简化设计： 考虑到业务-基础资料多级外键冗余更新，相当复杂， 即使缩减到3级关系，仍然要面对根部的基础资料表记录修改时， 大量无效耗时的更新判断。 所以设计需要改进加强，来适应冗余法设计， 原先CS下采用表间视图关联，维护基础表相当灵活， 可随意修改，但导致后续单据、报表查询非常耗时， 且极端情况下，直接报视图设计复杂，不支持。 比如生产投料工单的明细报表，就直接被复杂的视图拦截， 不能查询，必须去另外简化视图去适应。 为适应ERP单据和报表的快速查询， 对于基础资料表-业务单据表的外键关系， 做一些约束性限制： 1 采用主从表来管理外键及冗余关系。 原先是单表关系，表多时维护很啰嗦。 2 保存外键关系定义表时，要检查是否超出三级关系。 3 任一基础资料表保存时，如果同时满足以下三个条件时： 1 Code、或Name等冗余字段修改时， 2 已被任何下级表引用， 3 当前基础资料表，处于外键定义的三级关系的顶级时， 修改保存被禁止，只能作废或另外新增。 因为如果允许，就存在三级关联，级联更新。 4 这样控制后，任何基础资料表，或一些业务表修改时， 都只是仅需要更新下面一级表的冗余字段， 这样设计和编程就简单很多。 也不会出现多级更新的耗时多或算法复杂。 5 从CS系统来看，三级关系的顶级表主要是： 职员表、部门表、物料类型、产品类型、计量单位表。 这些表的数据，相对来说修改变化较少， 所以限制其冗余字段的修改操作。 6 如果外键关系定义表，只保留2级关系定义呢？ 1 可随意修改顶级基础资料表记录值。不受控制，不对。 2 也违反了定义所有表的外键关系的原则。 所以不能删减外键定义关系。 7 如何确定当前表，在外键定义表的树状层级？ 8 如何防止外键定义的树的死循环。 7、8两个问题，都可以用一个专门的判断sp存储过程来实现。 因为涉及到树的层级判断，查询次数多， 不适合在中间层大量写select语句去查询。 判断sp内，不采用标准的递归算法去判断，很难懂和难写。 仍然按照定次法去判断或生成树。 先建立一个临时表，字段：SID(int 自增)、表名、树的层级(int)。 1 首先往临时表，增加当前判断的表名、层级是1。 2 执行一个限制为5次的游标双循环： 外循环是临时表的某层级的表。 内循环是外循环表的定义表的下级表，写入到临时表。 第一次循环，是根据临时表层级是1的表，到外键定义明细表， 查询下级引用表名，把它们插入到临时表，层级 =2。 第二次循环，类似第一次，但来源的层级和写入的层级分别加1。 3 双循环执行完毕，如果临时表的最大层级： 情况1：>3，表示出现A B、B A相互引用存在死循环， 或表示正常的超3级的定义，这些都不符合设计要求， 不正常。需要提示，并中止保存。 情况2：=3，表示当前表，是三级关系中的顶级，需控制的正常。 需要做修改保存限制。 情况3：=2，表示当前表，是二级关系的顶部，正常。 情况1：=1，表示当前表，无下级关系表。正常。 10 定义表的主表，增加一个类似科目编号的字段， 用于表示定义关系中，存在的树状关系。 并默认按此树状缩进编号排序，而不是制单日期排序。 这样查询定义关系，可有整体树状的概念， 又可以看具体的定义关系。 系统已限制其为3层级。 如001 001.001 001.001.001 11 2020-03-07 发现取消多级基础资料、资料、单据关系， 而是改为单级关系，设计和维护更简单。 12 不支持基础资料作废，而是可直接删除， 因为刚录入的，运行删除。 13 考虑到同步数据的耗时性， 可改实时同步 为定时同步，甚至分步骤同步。 2020-05-07 老爷子。

[披着虎皮 的石头]

重要2：单据 帐接口定义 0 需要单独新增单据和即时库存表、或各类总账接口定义。 1 数据(事先预料增加冗余字段)接口定义、 2 更新即时库存和总账查询程序接口。 3 数据和程序接口定义好后， 系统启用或运行中间，如果发生需求变化时， 可以通过修改数据和程序接口的数据定义， 就完成程序的升级，而不需要硬编码修改程序和sp等， 这样就避免了二次开发的错误和繁琐测试工作。 4 特别说明：老CS中，因为无即时库存表， 所以存在冗余判断，即要判断2个负库存值， 又要判断有无其他库存单据的引用。 新系统只判断有无即时库存表的2个负库存值， 不必再判断有无被其他库存单据引用。 因已对即时库存的2个结余值是否负数，间接判断过。 5 考虑到出库单审核时，会出现重复的库存关键字记录， 所以核心判断负库存的，要模拟全部更新记录后，再判断。 6 更新即时库存表，要有防并发修改，写脏数据判断。 同时修改概率较大，要防范并发。 采用Where 即时表所有逻辑字段 ='刚查询的旧值', 条件之间的关系是 与 and关系。 Update 即时库存表 Set EndQty =888 Where Key_Fld1 ='Fld_old1' and Key_Fld2 ='Fld_old2' and EndQty =Qty_old 或下面的也可以。 Update 即时库存表 Set EndQty =888 Where SID ='旧值' and EndQty =Qty_old 检查返回值，如果返回记录是1，修改成功。 如果返回记录是0，即修改失败，原因是并发修改或其他， 要回滚事务，重新审核或弃审。 一般的写法是， Update 即时库存表 Set EndQty =888 Where SID ='旧值' 默认扔掉了and EndQty =Qty_old， 所以极个别情况下，更新即时记录的结余数错误。 7 同时新增即时库存表的，防并发新增，重复库存关键字记录。 同时新增同一个库存关键字记录，概率小， 但按墨菲定律，会出现的错误，总会出现，要给加上控制。 根据上级业务单据冗余数据，一般上级都有记录， 不存在无记录的情况。 而更新即时库存表记录，会出现新增记录情况， 需要考虑同时新增，而出现重复的库存记录， 违反了即时库存表，关键字不能重复的规则。 一般新增SQL语句: insert table (Fld1, xx ...) values('a', 'b' ...) 防并发新增SQL语句(Key_Fld1、Key_Fld2..仅指所有库存关键字值)： insert 即时库存表 (Fld1, xx ...) Select 'a', 'b' ... From 即时库存表 Where SID Not In (Select SID From 即时库存表 Where Key_Fld1 ='Fld_new1' and Key_Fld2 ='Fld_new2' and ... ) 上述SQL语句，无防并发新增SQL功能，放弃。 改为下面的SQL，测试通过： insert 即时库存表 (Key_fld1, Key_Fld2, EndQty) Select 'Fld_new1', 'Fld_new2', 888 Where 1 <> ( Select count(*) From 即时库存表 Where Key_fld1 ='Fld_new1' and Key_Fld2 ='Fld_new2' ) 检查返回值，如果返回记录是1，新增成功。 如果返回记录是0，即新增失败，原因是并发新增或其他， 要回滚事务，重新审核或弃审。 或改为如下，更完美： insert 即时库存表 (Key_fld1, Key_Fld2, EndQty) Select 'Fld_new1', 'Fld_new2', 888 Where 0 = ( Select count(*) From 即时库存表 Where Key_fld1 ='Fld_new1' and Key_Fld2 ='Fld_new2' ) 8 审核和弃审单据时，要更新即时库存表。 而删除(考虑不给功能)、作废、保存时，不更新即时库存表。 原因： 1 未审核的出库单、领料单、订单少。 用视图：即时库存表 +未审核的单据汇总， 得到预留库存量、可用库存量，比较快。 2 开这些操作的接口，编程比较复杂， 需要当前单据和后台老的单据记录， 一起和即时库存表比较。 从理论上看，有了新增和修改即时库存表的防并发写机制， 可以实现即时数据维护。 无论是硬编码或基类实现功能，算法比较繁琐。 所以在单据上库存预留数据不多情况(如几个、十多、几十个记录)， 通过即时库存表和单据，左关联查询就可，速度并不会低， 所以不做非审核、弃审时的即时库存表更新。 9 锁表后更新，一般是用事务或特别的锁表(或记录)命令， 然后再查询、判断、提交，再结束事务或解锁。 这个过程要简单，要短暂，比如求单据的流水号， 就是这个方法。 而更新即时库存表，判断负库存， 有时会遇到出库单几十个记录，要循环每个模拟记账， 然后再循环判断库存，耗时几百个毫秒是基本的， 这样会影响到即时库存表读取(用户高频)。 所以对即时库存表的更新耗时长，不能提前加事务而锁表， 影响正常用户的高频查询。 只能在修改或新增提交时，加入防并发检查条件。 --2019-12-13 数据库事务内，对表查询后， 就会对表自动加锁，其他用户无法再读取该表, 直到事务回滚或提交后，会解除锁表动作。 数据库事务外，对表查询后， 不会对表自动加锁，其他用户可以读取该表。 10 库存表，加个时间戳或版本号字段。 加创建、修改日期时间，2个字段。 0 为什么要做即时库存表，因为根据库存总账表 不管如何勤快的结账，总是要动态查询1-2个月的单据数据， 有时不勤快时，查询更慢了。 所以用即时库存表。 1 单据和即时库存表的接口，主要分为： 数据接口：定义库存的关键字， 可以定义到系统数据表，或者一个公共自定义函数。 老系统是固化到2个公共自定义DB函数内。 新系统必须单独定义到系统数据表， 且不是可以随意改动。 不能和一般的系统参数设置表混在一起。 否则一个不小心就容易出现误修改， 而是出现大的库存数据查询和录入错误。 也不能写死，因为随着时间或客户不同，要调整。 更新即时库存表的处理函数接口定义。 2 如何实现定义： 1 定义好，具体字段后需再设计。 这个定义表的维护方法：初始手工维护建立。 3 如何保证即时库存数据准确性。 1 平时根据公共函数和配置数据，去更新即时库存表。 2 系统爬虫去晚上检查，根据配置表检查， 如果有不一致时，就自动给维护好。 一般情况下，不会有差异，但有时因为系统bug、 或并发更新关系数据 维护冗余关系数据，就需要爬虫当守门员把好关。 4 特别说明，为了减少并发写脏数据， 新增和修改即时库存表，都要有SQL并发机制判断。 事前的事务等加锁，提交耗时长而且频繁，查询也频繁， 改为带并发判断的sql，检查其执行结果，决定提交或回滚。 而在晚上系统爬虫检查时，如果发现不对，就直接Update掉， 不加额外的上级单据冗余字段1 =旧值的条件。 5 原先老CS，无单据和库存表关系定义表，需要设计和新建。 表格设计不参照简单的公共参数表， 而是较复杂的定义的单表设计。 在写好公共表设计后，来做三个重要的设计表。 6 定义表的主表，增加一个类似科目编号的字段， 用于表示定义关系中，存在的树状关系。 并默认按此树状缩进编号排序，而不是制单日期排序。 这样查询定义关系，可有整体树状的概念， 又可以看具体的定义关系。 系统不限制层级，因为单据和库存接口关系是会调整的。 如001 001.001 001.001.001

[披着虎皮 的石头]

重要3：单据 单据流程定义 1 对于业务单据之间的流程关系，不仅单据数量多，而且模式和种类也有几种 (这里时间有限，不一一举例，有空专题归纳总结)。 有些还存在二次开发的数据流程关系。 老的CS，主要依靠先编写数据流程关联视图， 然后再在上级视图中关联 流程关联视图，来实现业务单据间的关联性数据。 比如常见的单据数据流程关联： 上级单据的个别字段(如客户、供应商),被下级单据引用。上级单据的明细记录，被下级单据引用， 从主表单据来看，是1：1、1：N、N：1，即统称N：N关系。 从从表单据来看，是1：1、1：N，即统称1：N关系。 常见单据关系，如销售订单-销售出库单、采购订单-采购入库单。 有些单据关系，是1:1，比如被要求从标准的N：N，改为1:1。销售出库单-销售发票、销售退货单-销售发票。 好处：效率高了，缺点：系统上很完美，但线下看是完美的。 而销售发票-销售收款单之间，有是N：N关系，用户提出来，不要常规核销，改为两种单据审核和弃审时，自动核销和反核销。 然后又会遇到销售发票是正负值、收款单金额是正负值，是简单的自动核销解决不了，要做传统手工核销窗口，去处理核销。 还有其他业务流程，简要介绍一下，可能还漏了一些，有空再补上。 1 生产任务单(生产投料单，或生产工单)， 生产物料领料单和产品领料单、受托库领料单、产品入库单。 生产任务单新增保存时，自动生成几个领料单。修改保存是，不自动生成，程序太复杂了。 2 生产任务单，保存后，点击生成领料单按钮，然后去修改编辑一些数据，再保存。 3 根据销售订单、或销售出库单的明细记录，去手工生成 出库包装单。 有时是可以无订单记录时，直接根据备货计划或仓库内的合并包装，就创建包装单。 4 产品检测单审核时，根据质量等级，去修改对应产品入库单、销售出库单上的质量等级或批号后缀。 5 而在生产工序较多的场合，一般采用领料单审核时，自动生成对应下个工序的(完工)入库单。 而下下个工工序的领料单输入后审核时，就生成下下个工序的入库单。如此一直到产品入库单。 如果弃审各种工序领料单时，就要对应删除或作废对应的工序入库单。 完了在月底时，需要检查这种流程中领料单和入库单的对应关系。检查时，不能太固定，比如有时会运行产品编号更换一个入库。 然后一般这么长，较多的工序，往往就意味着涉及到了三大类存货库存：原料库、半成品库、产品库。 然后财务部成本会计就会出来提需求，要求做好原料库、半成品库、成品库的成本核算，以及相互之间的结转。 如果月底未完工的半成品库，给算到车间在制品成本，即生产成本里。然后又多出来一个车间在制品成本。 然后财务会计，又继续提要求，成本核算的对象，中间要核算到产品+生产批次，最终产品生产产品，核算到产品。 然后还会告诉你，受制于自动化程度低，设备少，以及工艺等原因，会存在少数物料和产品一次领料某个批次， 月底退回车间，具体分摊算到那个生产产品，要等工艺部事后给出通知。 还有一些销售部送给客户的少了样品等情况，不走销售出库流程，而走产品领料流程，也存在怎么分摊到产品成本问题。 6 一些OA审批流程。比如原料申购、客户产品需求申请审批。 而付款一般都要求纸质方式，按照金额大小，由各级领导签字审批，因为如果系统上来审批付款单。 系统如果存在漏洞，就会出现虚假审批付款单，一旦付款出去，追回资金是非常麻烦的。 客户嫌ERP上OA审批麻烦，要求用户电脑前随时待命，去发现待审批的单据， 所以对于一些常见的采购原料申请单，就采用钉钉上审批。然后要求erp系统去获取钉钉的原料申购单下来。 7 OA 审批比较麻烦，所以对于一些相对重要性低的事务，就采用并发评审，按单据评审流程定义，多人可同时评审， 而不是串联去一级级审批。 8 而对日常经常发生的出入库单据，记录量大，审批流程最短，一般就是仓库、销售、生产部门制单，仓库部门最后审核。 所以ERP系统中，默认的审核流程就是一级审核审批，做在系统的模块权限的按钮权限里(有审核、弃审按钮)。 9 销售发票、销售收款单审核、弃审，都要实时修改销售出库单的客户欠款日期和标志。如果改为定时或保存出库单时才刷新，就不及时了。 10 销售价格、采购价格申请单审核时，生成最新的价格表及历史审批记录。 11 物料信息记录，研发部申请，领导审核后，才生成到物料信息记录，然后可以由领导或采购部员工修改。 12 销售订单、销售出库单的明细记录，来生成出厂单，和根据周生产计划明细记录，生成原料领料单很是类似，可并为同一种业务流程定义。 而一般ERP的单据数据，是最近3年的数据不清空的，这样连续三年的数据都存在系统里，关联查询就会变慢。 2 如何实现业务单据间的流程数据定义： 1 定义好业务单据流程定义，具体字段后需再设计。这个定义表的维护方法：初始手工维护建立。 2 如何保证业务单据间的流程数据准确性。 1 平时下级单据审核、弃审时，就根据上述单据字段定义， 把单据的关系数据冗余值维护好。 2 评审上级单据审核时，不用对下级单据判断， 而在弃审单据时，要判断是否有下级单据引用过，否则禁止弃审。 3 再用系统爬虫去晚上检查，根据配置表检查，如果有不一致时，就自动给维护好。 一般情况下，不会有差异，但有时因为系统bug、或并发更新单据关系数据 (用快的差量法,或全量法)的原因， 维护冗余关系数据，爬虫当守门员。 4 特别说明，为了减少并发写冗余上级单据 脏数据，平时审核、弃审下级单据时，先去根据单据关系的上级单据关键字条件 加上下面条件 Where (上级单据冗余字段1 ='旧值') and (冗余字段2 ='旧值2')等，如果返回更新记录为0，就提示并发冲突，审核失败，审核事务回滚。 而在晚上系统爬虫检查时，如果发现不对，就直接Update掉，不加额外的上级单据冗余字段1 =旧值的条件。 5 原先老CS无业务流程数据关系定义表，需要设计和新建。表格设计不参照简单的公共参数表，而是较复杂的、多业务流程定义的单表设计。 6 设定了业务单据流程后，也可以通过配置决定：是否可在存在下级单据时，弃审上级单据。 7 特别说明：外键及冗余字段存在级联关系，需要一级一级往上级单据更新，这个涉及到树数据结构。 8 定义表的主表，增加一个类似科目编号的字段，用于表示定义关系中，存在的树状关系。 并默认按此树状缩进编号排序，而不是制单日期排序。 这样查询定义关系，可有整体树状的概念，又可以看具体的定义关系。 系统不限制层级，因为业务流程的关系是会不停拓展的。如001 001.001 001.001.001 9 目前来看，单据业务流程，即业务单据的设计模式，有至少4种不同流程，所以需要分表管理， 不能一个(主从)业务单据流程定义表，就可以管好。