GSX RPR.COM.008: Choose a Ship-To location

We are having the exact same issue. Nothing additional to add, but you aren't the only one.

me three

I'm not certain if it would apply in this situation, but I recently went through the GSX certificate signing process and the requirements have changed notably since the last time I did this song and dance. Check out the "What are the instructions to follow when generating the CSR?" section here: https://gsxwsut.apple.com/apidocs/prod/html/WSFaq.html

Getting a similar message:

"ATH.LOG.14: Sold-To entered is not valid. Please enter a valid Sold-To."

@james179 fwiw, I've seen that ATH.LOG 14 error as the result of an inactive GSX account, too.

Hi all

Today, (May 16, 2016) AppleCare released an update to their API which requires not just the Sold-To, but your Ship-To as a part of the Warranty Lookup process.

What you're seeing here in the RPR.COM.008 is the result of the JSS not having this information, or using it in your lookup. Ensure that your JSS is up to date, or reach out to Casper Support for an update.

(We're shipping the update to our own Warranty Updater today)

Hope this helps!
Allen Hancock

Thanks everyone for your help with this! It's at least reassuring to know you're not alone.

I reached out to GSX Web Services Support: "Please contact JAMF Support for guidance.
Once you speak with JAMF please reach out to me with any actions that are required on my side.
There was an update this past weekend in GSX, that now requires the Ship To location to be included in the Warranty Status Request."

We are running 9.81, with plans to upgrade to 9.91 two weeks from now. I reached out to our TAM to see if the upgrade would fix it. I'll keep you updated. Thanks again!

@jedfrye @Yager @CasperSally @aurica @james179 @watchmanmonitor This is a known issue with the current GSX integration that prevents the collection of Purchase and Warranty Expiration Date for hardware records. You can reference "PI-002276" to keep track of this Product Issue. In our next release, we will resolve the handling of this "Ship To" address when interacting with GSX to collect Purchase and Warranty Expiration Dates. In the meantime, you can access this data directly through GSX.

Thank you for posting this and bringing the issue to our attention. The feedback from our community is incredibly valuable as we constantly work to make our products better.

Hopefully, the specific GSX fix maybe able to be dropped in place, then restart tomcat? This could be a sort of "hot fix" to apply while sticking with current JSS version.

These are the likely GSX components needing updates on RHEL:

ls -1 /usr/local/jss/tomcat/webapps/ROOT/WEB-INF/classes/com/jamfsoftware/jss/gsxws/
AuthenticateRequest.class
AuthenticateResponse.class
GSXCertificateException.class
GSXException.class
GSXFault.class
GSXService.class
GSXSession.class
GSXUtils.class
GSXWSRequest.class
GSXWSResponse.class
LegacyAuthenticateRequest.class
LogoutRequest.class
LogoutResponse.class
PartDetail.class
StandardAuthenticateRequest.class
WarrantyRequest.class
WarrantyResponse.class

As @watchmanmonitor and OP noted, seems GSX API now requires <shipTo> data in the request.
Click on the GSX Production reference for AASP, then flip-down "Repair Creation" > "Warranty Status". In the Warranty Status Request area, click "Sample SOAP Request XML" and you'll see an example, which includes a dummy tag for reference...

<shipTo>33523</shipTo>

Compare that GSX example to what you see on your JSS webapp (using RHEL)...

cat /usr/local/jss/tomcat/webapps/ROOT/WEB-INF/classes/com/jamfsoftware/jss/gsxws/WarrantyRequest.class

# Snippet of output on JSS 9.82.  Notice it's missing the <shipTo> entries.
<soapenv:Body><glob:WarrantyStatus><WarrantyStatusRequest><userSession><userSessionId>
                                   ]^
                                     _</userSessionId></userSession>
</unitDetail></WarrantyStatusRequest>8</glob:WarrantyStatus></soapenv:Body>

I recently updated to 9.92, this did not correct the issue.

@seabash i would like to attempt what you have suggested, however I am not as advanced and probably require a step-by-step.

@lee.smith GSX lookups definitely not resolved in any current Casper release. I only identified the suspected resource paths. I don't plan on editing any specified class resources; mainly just awaiting JAMF support reply about possibility of future hotfix for those of us who prefer not to wait/be tied to any full Casper point release.

Guess I could backup specified class files on Test JSS, make edits, then restart tomcat and see if I guessed correctly? If I get time to try or hear back from JAMF support, I'll reply back here.

Quite a bad time for this issue to be occurring considering we are starting to get shipments of all of our new hardware for setup over the summer and having all the warranty info is very important to our overall workflow.

Gabe Shackney
Princeton Public Schools

Me too!

Yeah, I just got GSX setup on our JSS and now I'm seeing the same error here. :-(

Hey Everyone!

If I understand correctly JAMF is aware of the issue and working on correcting the problem in their next release.

When is 9.9.3 coming out? I don't have this information.

We are having this issue with 9.92 but I have tested the current beta of 9.93 and it appears to be fixed.

For us GSX test was working last week but no lookup.
This week GSX test is coming up with "AUTH.UPL.003: Invalid URL for this SoldTo." and of course the gsx lookup is not working as well.

Today, we shipped a maintenance release for Casper Suite 9.92. This release resolves the GSX Ship-to error [PI-002276] encountered when looking up warranty and purchase information. Thank you to everyone who helped raise awareness of this issue!

I've installed this maintenance release and now GSX lookups just timeout and error now shows:
org.apache.http.conn.HttpHostConnectException: Connect to gsxapi.apple.com:443 [gsxapi.apple.com/17.151.129.22] failed: Operation timed out

Anyone having success or problems with this new 9.92 release?

Gabe Shackney
Princeton Public Schools

I just upgraded to the new 9.92 maintenance release and the GSX Ship-to error is now fixed and GSX lookups are working again.

@gshackney I'd bet the IP address your JSS is trying from isn't white-listed.

Use whatsmyip.org to verify & ask gsxws@apple.com to confirm.

We just updated to 9.92, but we're still getting this error:

ATH.LOG.14: Sold-To entered is not valid. Please enter a valid Sold-To.

UPDATE: I followed the suggestion on this post (https://jamfnation.jamfsoftware.com/scripts/article.html?id=26) and made sure the email address was one that has been used recently to sign into GSX, and now it's working.

Hi

Why I get this error always..

Traceback (most recent call last): File "new_script.py", line 7, in <module> imac.warranty(ship_to=822519,date_received=None) File "/usr/local/lib/python2.7/site-packages/gsxws/products.py", line 94, in warranty self._gsx._submit("unitDetail", "WarrantyStatus", "warrantyDetailInfo") File "/usr/local/lib/python2.7/site-packages/gsxws/core.py", line 437, in _submit result = self._req._submit(method, ret, raw) File "/usr/local/lib/python2.7/site-packages/gsxws/core.py", line 335, in _submit raise GsxError(xml=xml, url=self._url)
gsxws.core.GsxError: u'Cannot lookup serial number as there are no valid subscriptions for this ShipTo location.'