You’re offline. This is a read only version of the page.
Announcements
32
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.
Hi Cindy
I would not worry about logs if you have it sorted.
Have a read of this article regarding the column error.
Regards
David
Hi David!
Sorry for the delay. I had the client capture the logs after-hours, and I disappeared for a week.
Turns out the problem is duplicate items. The client was entering the same items, and it was throwing out the dups. I was a bit tunnel-visioned on non-stock items.
We also got an "Invalid column name 'desSPRkmhBBCreh'.*/" which I suspect is related.
Was planning on uploading our logs, but I don't see how.
Cindy
Hi Cindy
Now that your post has been restored, we can start working on it.
My first thoughts are can the behaviour be replicated?
I would love to capture logs of it not working and then of the exact same process working.
Maybe when it isn't working they could use GPPT to capture the logs. Then log out and back in and get logs of it working.
If they don't have GPPT yet, you can use the free 30 day trial to start with.
Regards
David
#1
André Arnaud de Cal...
291,359
Super User 2024 Season 2
#2
Martin Dráb
230,370
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (
