Hello GP Forum,
I have a frequent and recurring issue where the HITB table is not being populated with with inventory transactions. This happens a lot - like 2500 rows in April alone. This makes the HITB report completely useless. I've tried running the HITB reset tool (as recently as 3/31/14) and we continue to have challenges around reconciling inventory as a result of this. I cannot keep up with manually inserting records into this table. Is there a way to figure out why it is not updating properly? If I watch transaction posting, it appears to work perfectly every time. But when I'm not watching it seems to fail frequently. I'm not sure what to do about it or how to find the issue. Any thoughts or suggestions appreciated.
-Trevor
PS: GP2010 SP3, heavy manufacturing use and multi-bin. No customizations or 3rd party apps.
*This post is locked for comments
Hi Mahoumd, thanks for the post. I am having the same issue and this has reassured me that someone isn't deleting things in the database. This originated from an SOP transaction missing, it had 10 lines, 7 were in HITB and 3 were missing. I will look myself into inserting them into the database. I wrote a quick script to identify which SOP transactions were missing, I will have to do the same for IV transactions too.
select SHH.DOCDATE, SLH.SOPNUMBE, SLH.ITEMNMBR, SLH.ATYALLOC, SLH.LOCNCODE, hitb.DOCNUMBR from SOP30300 SLH with (nolock) left join SOP30200 SHH with (nolock) on SHH.SOPTYPE = SLH.SOPTYPE and SHH.SOPNUMBE = SLH.SOPNUMBE left join IV00101 IM with (nolock) on IM.ITEMNMBR = SLH.ITEMNMBR left join SEE30303 hitb with (nolock) on hitb.DOCNUMBR = shh.SOPNUMBE and hitb.ITEMNMBR = slh.ITEMNMBR and hitb.DOCTYPE IN (5,6) where SHH.SOPTYPE IN (3,4) and SLH.NONINVEN = 0 and SHH.VOIDSTTS = 0 and IM.ITEMTYPE IN (1,2) and SHH.DOCDATE >= '2017-07-01' and SLH.ATYALLOC <> '0.00000' and hitb.DOCNUMBR IS NULL order by SHH.DOCDATE desc, SLH.SOPNUMBE, SLH.ITEMNMBR
Hi Jonathan. No solution yet. Just a lot of angry accountants and a frustrated ERP/IT guy.
Any update on the resolution? This is a post that is getting a large number of views so we would like to get a confirmed resolution.
Thanks Mahmoud. Actually, we do practice batch only postings. The GP client and server are two VM's on the same server, so there are no network issues to speak of. It's very frustrating to not be able to use this table. I guess I'll just pretend it doesn't exist and build everything from the other tables. -Trevor
From an inventory posting perspective, the HITB table is the last table to be filled out when posting an inventory-related transactions. All the tables get populated including IV10200, IV10201, IV30300 ..etc.
I have seen several cases in which a minor posting corruption due to any common reason results with missing records on the SEE30303, all the tables are correctly posted including even the GL20000 while the records on the SEE are missing. I had to manually intervene and insert records on a continuous base on the SEE30303 table accordingly.
Therefore, I would ask for something that could hardly be doable, can we leave all the transactions saved by the users to be posted all at once on the server to exclude any potential network related issues.
Your feedback is highly appreciated,
Hi Frank. Thanks for the reply. The only integration we have is a payroll integration straight to the GL. Everything else is manually keyed. -Trevor
Do you have any integrations running transactions in?
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
André Arnaud de Cal... 291,151 Super User 2024 Season 2
Martin Dráb 229,993 Most Valuable Professional
nmaenpaa 101,156