I have a client that we just upgraded to GP 18.4. They have some GP tweaks to print various inventory and packing labels. With their update, they are implementing SKU#s that they are storing in the Inventory Short Description. They also wanted to start printing labels for non-stock items. I have a form where they select one SOP order or invoice, some SOP header information prints, and then they print labels - one label per SOP line that prints the qty, item number, description, and SKU# if it is a stock item. After this, the form restarts. I think these labels are then stuck on bags holding the parts.
Previously I was printing the labels off of the SOP_LINE_WORK. Because I needed to pull a field from the IV_MSTR but could not guarantee a link because of the non-stock items, I opted to create a temp table. SInce they also use kits and needed the items to print in the same order as on the SOP docs, I pulled in the full index set to my temp table (SOP_TYPE, SOP_NUMBE, Line Sequence & Component Seq).
I could get everything to work correctly on the SQL Server using both the sa user and a dexter user that has no access to alternate forms, but when we started to roll out the chunk file, the machines were having different successes. Our primary machine (a machine used for printing the shipping labels) was especially problematic in findng a consistent challenge. The SOP docs printed all the items all the time. The labels, however, were inconsistent in printing labels for the non-stock items. There was an undefined variation based on the user that entered the non-stock items and the machine on which the lines were entered.
The table key is Sop Type, SOP Number, Line Item Sequence, Component Sequence, Item Number. There is no sort on the label (report), and only the body and F1 sections.
Entering on one SOP doc, and always printing on the shipping machine:
Line 1 - entered by the sa user on the Shipping machine - printed a label
Line 2 - entered by the shipping user on the Shipping machine - this label never printed
Line 3 - my notes are fuzzy on this one - but the label printed
Line 4 - entered by mike on mike's machine - printed a label
Troubleshooting Notes:
1 - All users are power-users
2 - We verified all machines were using the same build
3 - We edited the SET file to remove the dexterity solution, deleted the DIC file and reinstalled the chunk
4 - We copied the DYNAMICS.folder from a working machine
5 - We were meticulous about using 'Run as Administrator' for everything, including launching Dynamics when including new code
Today, I received an update from the client, that if the user can't print, logging out of GP and back in then allows the labels to print.
This is not a complicated tweak - but it is really frustrating me that I can't see the issue.
