Chinaunix首页 | 论坛 | 博客
  • 博客访问: 720939
  • 博文数量: 158
  • 博客积分: 6010
  • 博客等级: 准将
  • 技术积分: 1643
  • 用 户 组: 普通用户
  • 注册时间: 2007-10-11 14:37
个人简介

人法地,地法天,天法道,道法自然

文章分类

全部博文(158)

文章存档

2022年(1)

2020年(3)

2016年(1)

2014年(7)

2013年(4)

2010年(5)

2009年(86)

2008年(25)

2007年(26)

我的朋友

分类: 数据库开发技术

2014-05-07 23:09:18

     SAP标准RFC提供了两个日期时间之间的时间差算法,但是它仅精确到分钟,这么一个不足,足以后患无穷,几近崩溃!另外以一个不足,同  一天无法算出24小时;这很无语。
     举个简单的例子,在生产过程中,机器工时的自动计算,从开始与结束都有日期时间,如果机器状态从一个状态转变成另一个状态,这个过程从开始到结束系统都能迅速捕捉到这个时间段即是机器工时,自动上报到ERP系统产生成本。由于这么个差异,每次都将秒忽略了,每个月累计忽略的秒数非常大,那就不得了。
     假如每次平均有30秒没有统计到位,平均一天发生状态变化100次,100*30=3000秒,100个机台将是100*3000=300000秒,一个月以30天计算将是30×300000=9000000秒=2500小时,每小时25块RMB,2500*25=6.25W RMB;

    我的个天哪,一个月有6.25W的成本没记帐,一年就是75W;爷拼死拼活,一年薪水也不过区区50W。

    当然这只是理论计算,实际不可能。

    下面看看这个RFC,SD_CALC_DURATION_FROM_DATETIME
     E_TDIFF这个变量,由它的数据无素决定了它仅返回时,分,把秒给Cut了。

  

    查到它的Domain,在Output的时候把秒给Cut掉了。      
   

   有关于无法计算24小时的问题,有时间可以研究一下;
   这个应用主要应用于按天报工,比如注塑机连续十天半个月都是正常生产,其产生的机器工时,总不能等它结束后再报,这样带来后果是很突 然一个机器工时非常大,另外,如果是跨月,则牵扯到月结,财务部门肯定骂你爹,所以开发人员是很冤枉~,按天切割,自然切出来是24小时,当然也可以另外处理这个24小时,不按RFC来计算。

  

   改造这个RFC,ZZ_CALC_DURATION_FROM_DATETIME



 
阅读(13002) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~