If we select one of those blank rows to open, we are brought back to the Entry screen with nothing at all pulled in. If we try to type one of those PackNums directly into the PackID field, we get the message that it does not exist:
None of those PackNums exist in the database, confirmed via both BAQ and SQL. I’m not entirely sure how they are being created in the first place, but does anyone know how I would remove these from the Search results list?
i have not seen this before… but I have not used Legal numbers (it is rare to use legal numbers in USA)…
Wondering if it is because of those legal numbers that there is an index without data. Thinking that you need to look in the legal number table to see if those packslips exist there. if so, that could explain it. One of the purposes for Legal numbers is to have a sequential number assigned to everything without gaps. (this is just my theory).
Do you actually use Legal Numbers? if not, then you could turn off that feature.
Indeed. Legal numbers are used by countries who collect taxes at invoice time - Italy, Brazil, China, and other countries with VAT. The US does not have a value added tax. Yet.
If you try to open a shipment in the wrong site it won’t show. Maybe the search is not respecting currently logged in user site.
On a side note I have seen change site issues for a long time now. From time to time you have all forms closed change site, then open a form e.g. Sales order and the site in the status bar does not match the site on the home page. (if you have sites selected in your prefences)
It turns out there was a post-processing Method Directive running on CustShip.GetByID that was causing those “phantom” Pack IDs to exist but not be able to fully load. The BPM has Custom Code looking for ShipVia information, but these goofy packing lists don’t have any so it seems to stall out.
I updated the custom code to account for a blank ShipVia, which at least allows the ShipHead to fully load so it can be deleted.
