Variance Report Pre-post Not Matching Posting

[prog_0927]

Progression 7.9.310

We ran a variance report of anything < .01 or > .01 prior to posting the tags from yesterday's count. The posting amount was off by a significant amount versus the variance report. We didn't see but one duplicate tag that we can account for, any thoughts on this? We are unsure of why that didn't match or come closer and now trying to find the source. Any help/best practices, or advice would be appreciated.

 

[prog_0927]

Figured it out! I did a SQL pull on the TAGHST table and found duplicates there that caused the issue Here is the SQL query if anyone is interested (change to your count date and your location as needed in script below; this pulls any rows with a count of > 1 which will need looked at/recounted/potentially reversed:

;
WITH B AS
(select t.item_no, t.count_qty, l.std_cost, t.count_qty * l.std_cost as 'total',
ROW_NUMBER() OVER(PARTITION BY t.item_no order by t.item_no) as 'row_no' from IMTAGHST_SQL t left
outer join iminvloc_sql l on t.item_no = l.item_no where count_dt = '20241223' and l.loc = 'loc1')
SELECT * FROM B where row_no > 1

 

[dgillz]

Can you elaborate on exactly what a duplicate tag means? Do you literally mean the same tag number more than once?

I am facing a similar dilemma right now and we do not know what is causing this.

 

[prog_0927]

Correct, that same tag was counted twice (each had 2 x rows in the DB) but when there are two, at least from what we are seeing, it posts both numbers counted (sum) which will differ from the frz_qty. The SQL will find any item numbers that have more than 1 x row; if there are any, the posting needs reversed and corrected before posting again.

 

[dgillz]

Sorry for the later reply. Is this something you can reproduce?