Quick Ship will not print a manifest. Error is:
Error in formula RoundWeight:
‘round({Shipment.TotalWeight},0)’
A number, or currency amount is required here.
I have downloaded the shipment summary and do not see any weight that is 0.
Have submitted to Epicor but they have not gotten back
Any thoughts as to what to check?
0 would be fine since this is rounding to 0 places, it is likely bad data either null or string causing the issue.
If you are printing the summery manifest you may be able to print the detail version and possible get an error on the shipment causing the issue.
Thanks. Apparently whatever this is, it is affecting a lot of customers. They are working on a solution.
Well, there is a “widespread” issue. They sent a word doc and .xsd file but no explanation as to how this happened or why. We are on-prem and did not, as far as we know, change the software in the last two days.
Our IT guy asked if it could be related to some sort of Microsoft server update/patch/whatever, so we have asked that question. I think changing (or adding?) a host file was mentioned.
I am not on the technical side, so take any technology terms here with a grain of salt. Just passing along info (such as it is) in case it is useful to someone else.
Note: BACKUP your hosts file before making a change (the instructions have it in the wrong order and our hosts file was blasted away after making the change, losing previous entries).
It appears that QS uses some schema template on Microsoft’s server and that schema was removed. SO, print jobs are failing.
The solution is to essentially locally host the schema template (XSD) and update hosts to point locally instead of to schemas.microsoft.com.
We are having issues with our hosts file saving, so we do not yet know if this will resolve our issues.
This is the explanation I got from Epicor:
This issue for printing crystal reports appears to be due to not being able to access the following URL anymore
http://schemas.microsoft.com/sqlserver/2004/sqltypes/sqltypes.xsd
Is there a new URL to use?
Yeah, that URL seems dead. The fix was to add the XSD to our server, update IIS a bit, change the hosts file to have the QS server look to itself to load the XSD template.
This didn’t work at first, as our hosts file kept resetting itself upon save. Seems the schemas.microsoft.com URL was being flagged by AV. So, we had to turn off AntiVirus on that server to get the hosts file to save, so printing could load the now locally hosted XSD template, and then we were able to print labels.
Our international doc paperwork doesn’t work though. Not sure why that stopped.
Hey Adam,
Could you provide more details on how you resolved this issue? We’re experiencing the same thing and I’m still waiting on a response from Epicor.
Thanks!
Here is the workaround from support. The ZIP file is the XSD template file.
Make sure to backup your hosts file before making any changes (The workaround document has that step in the wrong order and our hosts file reset to default when we first tried this. It seems our antivirus had a problem with the entry and killed our changes, along with our other entries).
In the end, we had to disable antivirus on that server to get the hosts file to stick, then shipments went out.
SchemasErrorWorkaround.docx (303.6 KB)
sqltypes.zip (2.5 KB)
UPDATE
Went back reviewed the setting in the IIS and realized I fat fingered the path. Removed the old “slqserver” application and added the correct path and now it works perfectly!
Thank you again Adam for the quick response.
Cheers!
Thanks Adam. I have applied the work around but still continuing to have issues. The XSD created still holds the old URL location. Still waiting to hear back from EpicCare if they have additional info. Very frustrating.
Yes, very frustrating.
The QuickShip application should now attempt to visit schemas.microsoft.com, but since your hosts file points to your server, that request doesn’t leave your server and instead finds the XSD template file that you added. That XSD template then validates the structure of the request from QuickShip and your label should print.
The fact that the XSD still has that MS url shouldn’t matter since the QuickShip call is only to load the XSD file, which it should now be able to do.
Perhaps restart the default web site in IIS that the XSD was applied to?
Also, did your hosts file stick with your changes?
Yes the host file did stick. I had to “allow” the change. I will be discussing the changes with our network admin tomorrow.
So did Microsoft fix the URL now?
(http://schemas.microsoft.com/sqlserver/2004/sqltypes/sqltypes.xsd)
Looks like it to me. URL works today.