阅读排行榜

评论排行榜

最新评论

总感觉那个叫啥晓峰的回复,总是不那么切题,貌似只看到了最基础的用处 --【匿名用户】:E-works热心网友
这是个好建议! --【匿名用户】:E-works鐑績缃戝弸
所以国内企业要的就是灵活不是标准。 --【匿名用户】:E-works热心网友
写进BOM的都是标准成本,实际业务中按照标准成本来的有多少啊。 --【匿名用户】:E-works热心网友
这个有这个复杂? --【匿名用户】:E-works热心网友
建议还是挺好的。 --苌晓峰
这个分享还是蛮不错的吗! --苌晓峰
太简单了啊 --苌晓峰
分享 --苌晓峰
真正用得时候,谁还会想到这个啊 --苌晓峰

在OINM表如何设置过滤条件能只得到库存收发货明细
本文标签: SBO中查询交易帐 OINM 

在SBO中要查询详细的交易账,通常我们都会选择OINM表来查询,这个表中存放有详细而全面的交易明细账,但最近在客户这对账时,却发现了以下问题:
我们知道在SBO中,生产收发货及库存收发货所用表是一样的,期objtype(均为59,60)也是一致的,因此在oinm表中transtype为59,60的交易明细为生产收发货及库存收发货的总和。
但如果在OINM表要查询生产收发货表的交易明细信息时,我们只需设置以下条件:{oinm.transtype} in (59,60) and applobj=202(TransType\Applobj的数据类型均是“int”),这样查询出来的交易明细确实是生产收发货的明细账,与库存审计报表中查询出来的信息亦是一致的。
但如果我们要查询库存收发货的交易明细呢?或许我们都认为只要设置条件跟生产收发货相反就行了。但是奇怪的是,我将条件设置为:{oinm.transtype} in (59,60) and applobj<>202(或applobj=0),SBO系统却一条记录都查询不出来,而其实是有记录的。我曾经也想过找其它条件,比如设置{oinm.IOffIncAcc}(库存抵销 - 增加科目 )<>'' or  {oinm.DOffIncAcc}(库存抵销 - 减少科目 )<>'' ,这应该可以了了吧?最后检查却发现,如果有{oinm.transvalue}=0,{oinm.IOffIncAcc}(库存抵销 - 增加科目 )与{oinm.DOffIncAcc}(库存抵销 - 减少科目 )的值便亦为空,而它们实际却是库存收发货。
这或许是SBO的一个bug吧?我们无法直接地从OINM表中单纯地全面地查询出库存收发货的交易明细账。
这让我走了不少弯路,因为客户这生产领料明细账中:生产数量=生产收货(这很方便就能求出来),但生产领料=生产发货+库存发货-库存收货。最后我不得不先求出“生产数量”(:{oinm.transtype} =59 and applobj=202)的oinm.inqty的和与“生产及库存总出库数”(所有{oinm.transtype} in (59,60)的((oinm.outqty)-(oinm.inqty))的总和)的各组小计数,生产领料的数量=“生产及库存总出库数”+“生产数量”,这也算是曲线救国,解决了这个数据问题,不然数据的勾稽关系(期初+生产-领用=期末)是永远无法对平的,跟财务对报表数据,我算是见识到了,还真有点心有戚戚焉,一条明细数据出错都逃不过他们的眼睛,我实在佩服(使用oinm.IOffIncAcc与oinm.DOffIncAcc做条件时,自己挑了几个明细、小计、总计对账时发现都是正确的,发给他们,却能让他们对出那仅有的一条oinm.transvalue=0的数据勾稽关系不平)。
发表于: 2009-08-24 13:37 秋声 阅读(2456) 评论(0) 收藏 好文推荐

发表评论(网友发言只代表个人观点,不代表本网站观点或立场。)

您尚未登录,请先【登录或注册