高度概括配置化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 "老人"，带"新人"方式，来加快开发速度。

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

引用 4 楼 神话jsh 的回复:

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

肯定用到算法了，而且算法比较很多，提炼出来的，就是核心算法。
开源erp是开源了，但遇到不同客户，就要二次开发，
这个二次开发工作量，随着用户需求变多，是很惊人的。

所以开源免费的，并是容易入门的，但并不是节省开发和实施成本的。

  比如做一个部门级的进销存系统，和做一个公司或集团级别erp系统，

  那用户需求，后者比前者大很多，随着软件规模扩大，

  就要考虑分析 开发 测试 维护的成本，想办法，
  去提高软件功能，同时又大力降低IT企业的成本。

  如果仅仅是拿来主义，拿别人施舍的开源系统，
  那就默认就要进行大量二次开发，而且二次开发的东西，
  仅适合当前客户，并不能大量重用给其他客户，商业上单位成本太高。

  erp系统，采用人工智能方法来开发的前提条件是很多的：
  1 熟悉较好的平台，网页版为先，三层CS系统为次，还有手机版。  
  2 了解具有企业管理 财务管理等知识和经验。然后再熟悉某些行业。    
  3 善于与人沟通，因为只有善于沟通，才能为客户提供个性化服务。
  4 较好的理财能力，因为erp系统是需要持续改进的，需要资金、人员、技术来维持，都要较多资金。
  5 身体要健康，能很久的工作，而不是做着就转行了。

  因为 研发 具有人工智能的erp系统的条件比较苛刻，所以 基本上没有人或公司去尝试。
  但前途是很光明的。
  
  人工智能流行起来，也是在围棋alphaGo打败了围棋世界冠军后，变为家喻户晓，
  所以推广到各个各业需要时间，
  但人工智能的核心思想就是算法和数据，可以拿来应用到erp系统开发上，
  谁主动去做，就赢得发展的先机。


  但如果继续按照常规方法开发，就会重复和别人一样的生活。

来学习一下，看看

重要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 老爷子。