We do not use GP Workflow for Payables Management (we're on GP 2016)... but I'm wondering if the Workflow_Status field in the PM10000, PM20000, and PM30200 tables may be used by our custom integration routines.
That is, we have a Payables invoice approval process set up as a SharePoint workflow. When the SharePoint workflow is complete, the payable invoice is approved for payment, and our integration routine takes that invoice off Hold in GP.
What I'm wondering is this: if we also set the Workflow_Status field to 6 (Approved) in our integration routine, might that value be overwritten by GP at some point in its normal operations?
When does GP stick a value in that field if we don't use the Workflow capability?
I've checked the value of that field in all three tables and they're set to either 9 (Not Activated) or 0.
Any advice?
Sincerely,
Steve Erbach
*This post is locked for comments
Béat,
>> Better safe than sorry :-) <<
That is just not the way I live, Béat!
Regards,
Steve Erbach
Good choice..
I'm always a little leary to bend a system and miss-use field that seemingliy dont seem to be used now, but could be changed later on the course of new releases.. Better safe than sorry :-)
Béat,
We've decided to forget about the Workflow_Status field and go with a new table into which we'll insert a row whenever an invoice is approved for payment in our SharePoint workflow. Then when the integration routine runs again it will check against that table and just leave those invoices alone. That is, it WON'T change the invoice HOLD status once the invoice number is in that table.
Sincerely,
Steve Erbach
Hi Steve,
That's an interesting observation.. Indeed, only a SQL trace capture would probably tell the truth.. very strange at least.
If you have the GPPT developper module you could possibly build a trigger that would set the value of that field when a value changes in some tables..
The best is to figure out why the status field gets overwritten in the 1st place..
Bonjour, Béat!
I went ahead and updated the Workflow_Status field to 6 (Approved) for all Open invoices that were not on hold. Then we updated our integration routine (which runs four times a day) to do this for any invoices that made it through the SharePoint approval process:
UPDATE WOW.dbo.PM20000
SET Hold = 0
,Workflow_Status = 6
WHERE VCHRNMBR = @vchNo
AND Workflow_Status <> 6
AND Hold = 1
Pretty straightforward. However, when this ran at 4:00 Friday, the approved invoices had their HOLD status changed to 0... but the Workflow_Status column either remained 9 (Not activated) or was changed from 6 to 9 by GP.
I can't think of any way to see when and where the Workflow_Status field is changed other than by running the SQL Profiler when the integration routine runs. We've come up with a couple other ideas to circumvent the apparent overwriting by GP... but I'd like to figure out why I can make "manual" changes to the Workflow_status with an UPDATE query; but when the integration routine does the UPDATE, something screwy happens.
Sincerely,
Steve Erbach
Hi Steve,
As the WF 2.0 setup is not enabled or completed in your system, it would probably not have any effect.. but why don't you just try it out in a TEST environment by running a full process and see how the WF status field(s) behaves ?
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,240 Super User 2024 Season 2
Martin Dráb 230,149 Most Valuable Professional
nmaenpaa 101,156