Skip to content
+1-888-319-3663

COMMUNITY FORUM

Item Number Modifier PSTL not updating Extender key fields

Tyler asked 5 months ago
Hello everyone, 
We have noticed that when the PSTL Item Number Modifier is used it is not updating Extender with the newly changed item number leaving those records orphaned. We have been manually fixing this in the Extender tables for the time being. 
We have a couple of Extender windows linked to the Item Number to keep track of additional item characteristics. 
Does anyone have any suggestions on the best way to get have Extender update when the item number changes in GP?
We are using GP 2018 and Extender version 18.
Answers
Patrick Roth Staff answered 5 months ago
The PSTL/GP procedures loop through the “known” tables for items such as the SOP10200, SOP30300, etc and will update those directly in most of the cases.
 
But after it does that, it then reads all of the tables in the SQL company db looking for “ITEMNMBR” and then does those.
However since the Extender table key fields are not named that (since generic key fields) they do not get found & updated automatically.
 
But we are in luck – Microsoft thought about “third party integrations” when they wrote this.
If you look in SQL, there should be two “developer” procs for this process.
taItemNumberModifierPre
taItemNumberModifierPost
 
In it, you get passed the same params that the smItemChange1 proc (which is encrypted) used to rename the GP table data.
In our case, I don’t see that it would matter if we used the Pre or Post proc to add our code to it – so I’d use the “Post” script out of habit.
 
So assuming I have my params correct, you’d just modified the taItemNumberModifierPost script and then use @I_charStartItem as the “old value” and the @I_charEndItem as the “new value”.  Then write the SQL Script to update the EXT01100 table with the new key strings value.
 
You will, of course, want to test this in your test/Fabrikam company and make sure the params are what I believe they are before deploying live.
 
The only unfortunate thing about stored procedures like this from a GP perspective is that if you rebuild procs or add any GP updates, it will most likely drop the custom procs and then put them back new again (and default) so you’d lose these changes.  So make a backup of the modified procedures and then remember that you’d need to verify them any time you do any kind of update in GP.
 
 
 

If you would like to submit an answer or comment, please sign in to the eOne portal.