BW:关于DSO的RECORDMODE:一个比较棘手的问题

SAP BW 专栏收录该内容
115 篇文章 2 订阅

记得有这么一个问题,话说是DSO里出现了几条很违规的数据,这种数据吧,初始化的时候不会出错,跑D包才会有。  

以凭证号5100011935为例:

 

   

   

这里的0DOC_TYPE是不允许为空的,因为我们从最低层上载数据的时候,就已经限制了0DOC_TYPE=ZJ2

   

考虑到初始化的时候不错,跑D包才错,于是乎,我们抛弃了怀疑SAP BUG的情况,去检查LOG ,重点关注RECORDMODE   

 

   

LOG表是个好东西,这里很清楚,第一条数据是最早的,N镜像,之后又来了两条,X的为先,前镜像,目的是冲掉第一条数据,空的为后镜像,取而代之。之后的两条数据出现了错误,X掉前镜像之后,后镜像的0DOC_TYPE居然为空。

   

我们过去找这条数据的请求ODSR_4JFDA8PJ9IHRRHHHEO0YNNQD8,还好都在…

   

   

这里我们点监控器,回过来点调试。

   

   

这里我们可以得到这160条数据的前因后果。我们怀疑问题出在Start Routine上。

   

在调试请求的地方,选上想看的位置,基本上都是转换前后,Start Routine和End Routine的。

逐行调试之,最后发现,Start Routine调试结果没问题,在转换自身执行以后,就出现了ODOC_TYPE为空的情况。

这时我们就想到了DSO的机制,他会用前镜像冲销之前的记录,然后用后镜像覆盖。

   

几经周折,发现,原来是因为Start Routine里面有这样一句话。

   

    SORT itab_pack1 BY doc_number comp_code.

    DELETE ADJACENT DUPLICATES FROM itab_pack1 COMPARING doc_number

    comp_code.

   

这个看起来没有什么问题,可是我们假设一下,如果这条数据有前后镜像,这次删除会删掉其中的一个,删掉前镜像,后镜像的数量会和原来的数据相加,然后0DOC_TYPE=ZJ2,删掉后镜像,前镜像会和原来的数据做抵消,搞到最后,全为空。

   

PS:LOG表里的"按期履约的标记"的计算时在End Routine里,所以是有值的。

   

这种问题还是有点意思的。难怪最后算出来,履约的比总数都大~~~

  • 0
    点赞
  • 1
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

©️2021 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值