例如我做的或自动生成的报价单审核完成以后即使数据初始化、删除所有动态单据他依旧存在====>报价单会删除, 但报价会留下来. (我们目前认为: 报价属于基础数据部分)
那么《工程-物料数据维护》里面已存在的料号不能删除
====>你可以考虑"改ID"的方式, 把无效的料号,变有新的料号吧.
软件本就由决策者(系统实施人、老板)来控制。是否开放权限,给谁这个权限由决策者决定
====>不行. 如果放开,别人乱删除后, 反过来责问我们数据为何不对, 我们又无法解释.
现在,我们没有放开权限,因此, 用户的任何数据疑问,我们都能解释. 这样, 我们才能把软件越做越好.
如果我们发现有些数据自已也解释不了, 我们自已也会没有开发信心的. 这么复杂一个软件, 由不得半点疑点!
实话告诉你,工厂里,是多人操作数据的, 如果你删除了, 但另一人却不知道,或者,你辞职了,你的后来者,并不知道你删除数据了.
他就会质疑软件, 并会向其它同事传播这种质疑. 最终,全厂都认为"E树数据,有时好像有问题....",
因此,两害取其轻者,我们坚决不开放这个功能出来!!!
例如:A采购报价单使用过采购单,就必须先删除采购单)
===>另外,如果全部支持删除,则软件会太复杂. 软件无法保证逻辑关系的完美.
还有, 最关键是, 如果只是数量加加减减,那都好办, 但如果涉及到成本金额的转移和加权, 就没有办法了.
因此,你删除了过去的单据, 那现在的成本价,该如何解释呢? (重算是不可能的,因为还有月结分摊算法,它不是小小的进销存)
但是,财务凭证,由于它是整个业务的最后一环节, 它不影响其它数据,因此,财务数据,完全支持你自由自在地反审和删除!
让人首先有疑虑是不是软件出错了。这个疑虑扩大化后即使不是软件问题也推在软件上面
====>错了. 正是因为我们有这样的严谨的态度, 才决定我们软件一定是一款非常严谨的软件.
(试想一下, 我们保留历史单据, 就是为了查问题, ===>最终结果就是: 发现一个BUG,解决一个BUG,因此,最终,E树将是一款非常非常少BUG的软件)
因每次MRP运算都会留存,本身就有记录可以查询
====>系统参数设置中,可以设定保留最近10期的MRP计算过程
如果删除单据,做一个自动生成的不可修改的系统日志或存档即可解决.
====>错了, 日志, 不可能做得无限细致, 日志只是一个简单的记录, 它并不是记录真实的修改过程.
它只是记录:谁,何时,改过它. (至于改了什么, 就不再记录了 ,如果记录改了什么,那数据库会暴增, 不划算, 也成本高)
(实际,你可以通过保留30天的数据库备份档, 通过恢复备份档, 来查看问题)