Different GP users yielding different results for same procedure

[Luvsql]

We have an issue where User A creates a PO in Company X. Any user enters a Shipment and posts. The PO status and PO Line status now says "Received."

User B creates a PO in Company X. Any user enters a shipment and posts. The PO STatus and PO Line status says "Released".

I have found a couple more users that behave correctly (ie as User A), but have found a couple users that behave as User B (ie totally and completely wrong).

How can a GP user control the way data is populated in a table? Is that not a stored procedure that is run that does this? Should the User ID who is performing the task ONLY be concerned with permissions on stored procedures?

The only way I have been able to fix the users with the issue is to delete the user completely and recreate with a different ID (ie if I recreate using the same ID, same issue happens). User is recreated with same user class as before.

We have over 90 users setup in GP. I cannot test each and every user. GP Should not be behaving this way. A GP user should not control how the code runs are what parameters are entered into a sp.

We have been running GP for 5 years and GP 7.5 since it was realeased.

 

[jymm]

kinda a stupid quesiton - but does it relate to a user -OR- a computer? The reason I ask is that I had a simlar problem (in payroll of all places) and from my machine with the 'problem' user everything was fine... and it was the temp files that GP was storing on the local box (which had the user ID in it and everything - since other people on that box worked just fine).

 

[Luvsql]

It's definitely a user issue. I can replicate the issue on the same computer with different logins (ie log into GP as user X get issue, then log into GP with different login and no issue; Same computer).

 

[jymm]

this sounds WAY too much like a payroll problem I had.

Get everone out of that company (or do it in the middle of the night from home like me)
I fixed that one by going to File->Maintenance->Clear Data

THEN I had to select JUST the work tables that were TRUELY temporary. This is was where the tricky part came in. Payroll Check WORK was an easy one to find (and clearing those tables did the trick) but in PO I KNOW that there are a few tables in the list that are flagged as 'WORK' but it is not a temporary table it is TRUELY their work space (ok, so this morning I can not find the TK that would tell me which PO table is which - sorry) --- so be careful. personally I prefer looking at the tables and surgically removing the offending records, but...

this give you enough rope?