work diary


昨天一天工作紧张,精神高度集中了一天。结果还好,比较顺利。

事情的从前天说起。前天快下班时,突然接到coordinator 的电话,听筒里的声音充满了恐怖与紧张,吓了我一大跳.

 

仔细一问,原来,上月我们把预防性维修的工单类型统一改掉之后,这个月coordinator进入sap去拉工单,突然间发现多了很多重复的工单,而且,有大约20工单几个提早生成了。所以,coordinator大叫大嚷,仿佛我们做了大逆不道的事一样。接着,engineer 接着也急吼吼地跑过来,一口咬定是我们改掉了他们设定的起动时间。我说,作为sap 顾问Julia 不可能会没有这点常识。当然,他们此时过于紧张,什么也听不进去了。

 

昨天一早,我就进入系统,仔细看看,究竟是怎么一回事。

经过和顾问的沟通以及研究,终于知道了问题所在:

1.由于在sap系统中,任何修改的,删除的东西都不会消失,仍旧会存在系统当中。这样,修改过之后,旧的已经作废预防性维修的工单和新生成的预防性维修的工单并存在系统中。如果需要察看生成的预防性维修的工单,就需要设定条件进行筛选,条件选择MANW + PRO ,这样,系统搜索出来的结果范围就小了。而那个Coordinator 仍然按照老办法,只是在function location一栏里面设定了简单的搜索条件,于是,作废的,不相干的工单全部显示出来。内容多多,他们一看,以为系统乱了,推理到是我们干了坏事。所以,以后如果要搜索自己的预防性维修的工单,必须设定条件搜索,不要把范围放大。

2.他们这个小组的确有大约20几张工单的确没有在规定时间生成,提早了。原因是这些设备在08年的时候,被人为地更改过循环设定时间,使得工单按照新的计划生成。而顾问重新运行的时候并不知情,仍然按照原始的设定START 计划。所以,问题就出现了。这个是要解决的。

 

 

后来,我又去到另外两个小组查看过。他们都没有遇到第二种情况。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/15005154/viewspace-586820/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/15005154/viewspace-586820/

SELECT `a`.`id` AS `id`, `a`.`user_id` AS `user_id`, `a`.`diary_date` AS `diary_date`, `a`.`time_id` AS `time_id`, `c`.`dept_id` AS `dept_id`, `c`.`name` AS `name`, `c`.`post_id` AS `post_id`, `d`.`reviewer_id` AS `reviewer_id`, `nw`.`jigou` AS `jigou`,( CASE WHEN ( `a`.`time_id` = 0 ) THEN '上午' WHEN ( `a`.`time_id` = 1 ) THEN '下午' ELSE '晚上' END ) AS `timename`,( CASE WHEN ( `a`.`is_submit` = 0 ) THEN '未提交' ELSE '已提交' END ) AS `submitname`, `a`.`is_submit` AS `is_submit`, `a`.`model_id` AS `model_id`, `a`.`content` AS `content`, `a`.`system_time` AS `system_time`, `a`.`day_state` AS `day_state`, `a`.`time_start` AS `time_start`, `a`.`time_end` AS `time_end`, `a`.`address` AS `address`, `a`.`content_join` AS `content_join`, `a`.`diary_state` AS `diary_state`, `a`.`syfid` AS `syfid`, `b`.`name` AS `modelname`, `e`.`rank1` AS `rank1`, `e`.`review_name` AS `review_name`, `e`.`review_state` AS `review_state`, `e`.`writing_state` AS `writing_state`, `e`.`status_name` AS `status_name` FROM ((((( `work_diary` `a` LEFT JOIN `work_template` `b` ON (( `a`.`model_id` = `b`.`id` ))) LEFT JOIN `sys_user` `c` ON (( `a`.`user_id` = `c`.`id` ))) LEFT JOIN `work_jigou` `nw` ON (( `nw`.`id` = `c`.`dept_id` ))) LEFT JOIN `sys_review` `d` ON ((( `a`.`user_id` = `d`.`user_id` ) AND ( `b`.`type` = `d`.`code` )))) LEFT JOIN `view_my_worklist` `e` ON ((( `a`.`user_id` = `e`.`user_id` ) AND ( `a`.`diary_date` = `e`.`diary_date` ))))优化,只要结果,不要分析和思路
03-20
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值