感谢挚友文心残!!!
t_systemprofile.upstockwhensave [0：审核更新，1：保存更新]
首先谈谈K3的库存效验存储过程CheckInventory。
因为某些异常的发生，系统有可能会发生一些丢单的现象或者库存更新的错误，
这样就导致帐与库存的不一致，这时就可以调用该存储过程，重新通过计算得到正确的库存。
该存储过程计算方法是先得到本期间的期初数据，然后把本期发生的出入苦业务单据按照规则进行计算。
这里抽出其中一段SQL代码进行分析:
Insert Into #RealTimeQty
SELECT t1.FItemID,t2.FDCStockID As FStockID,IsNull(t1.FBatchNO,''),ISNULL(t1.FDCSPID,'') as FStockPlaceID,
case when FKFDate is null then '' else convert(varchar(10),FKFDate,120) end ,ISNULL(t1.FKFPeriod,''),
Sum(t1.FQty) As FQty,0 As FQtyLock
FROM ICStockBillEntry t1,ICStockBill t2
WHERE t1.FInterID=t2.FInterID And (t2.FCheckerID>0 or t2.FCheckerID <0 or FUpStockWhenSave=1)
And t2.FCancelLation=0
And t2.FTranType In (1,2,5,10,40,41) And FDate>=@StartTime
Group By t1.FItemID,t2.FDCStockID,t1.FBatchNo,t1.FDCSPID,t1.FKFDate,t1.FKFPeriod
注意这里其中一个条件:t2.FCheckerID>0 or t2.FCheckerID <0 or FUpStockWhenSave=1,说明这里参加运算的出入库业务单据是审核过的单据
或者是ICStockBill.upstockwhensave=1的单据。如果系统将t_systemprofile.upstockwhensave设为1，即保存时更新库存，
则本期发生的出入库业务单据都在条件范围之内；如果系统将t_systemprofile.upstockwhensave设为0，
也就是审核才更新(像某些公司，它们月底备份盘点数据，但他们的报表可能是备份数据后的几天才交上去，
所以她们就采取备份完数据后以后做的单据就不审核，这样数据就不会乱),
那么只有审核过的单据才会符合该条件(未审核的单据ICStockBill.FCheckerID is null,
审核过的单据ICStockBill..FCheckerID>0 or ICStockBill.FCheckerID<0),
所以ICSTOCKBILL.FUpStockWhenSave要由T_SYSTEMPROFILE.UPSTOCKWHENSAVE来决定，
这样即使以后系统改了设置，库存效验时参与运算单据才不会搞混乱。
|
|
发表于 2008-11-9 16:20:09
