|
|
下面的问题是目前我们上线后仍存在的我们认为是不能解决的技术问题,希望能有QAD使用方面比较专业的朋友可以提供帮助,互相交流。谢谢!
1.资信限额与票据维护(27.6.13)
a) 系统进行资信额度控制时不考虑应收票据金额,而应收票据在我公司等同于客户已付款,在资信额度计算时,应该减去其金额。因此按照现在的系统逻辑我们无法真正体现客户发货是否真的超限额。
b) 客户使用银行承兑汇票支付预付款业务无法在系统中进行客户预付款操作。
c) 资信冻结计算时不考虑该客户所有订单的合计金额,只考虑每个订单的金额是否超资信,造成当单个订单金额未超资信控制金额时,可以无限制发货,资信失控。
2. 客户价格单
a) 配置产品无法起用价格单控制,如启用价格单控制,做配置产品的订单时报价格单找不到错误。
3.应付帐预付款
a) 系统28.1中的vo_prepy(预付款)参考字段与系统报告28.15建立联系,不是预付帐款明细帐,预付帐款明细帐如何体现。
4. Consignment 退货
a) Consignment 退货流程在设计逻辑上不能反向操作,导致现有的退货流程过于复杂,具体操作是先对应退物料转移所有权至公司,然后做负数采购单冲回给供应商。负数采购单退货和Consignment 收货没有相应的系统对应关系,也有可能造成虚增债务的风险。
5. 审计轨迹
a) 对于pt_mstr(物料主文件)、pi_mstr(供应商价格单)、pc_mstr(客户价格单)、的更改没有审计轨迹可寻,对于其中的关键参数,包括库存、计划、成本等信息都是审计时必须要提供变更证据的。
b) 对于vd_mstr (供应商维护)、cm_mstr(客户维护)、ac_mstr(帐户)部分字段有审计轨迹,但只能保留最后一次变更的记录,过程中变更无轨迹可寻,不能满足审计要求。
c) 由上面可以看出,系统中对于变更信息的跟踪,即使有的话也是不能满足审计要求的,确实十分勉强。
以上很多要求都是SOX审计所必须要求的,
这个是我们原来的Syteline系统都具备的,系统报表就可以满足要求,而QAD做客户化怕是都很难满足,会复杂一些。 |
|