@j-mutter Should we use a flag to allow both the new approach and old approach to sandbox endpoints? Maybe default to sandbox being the new endpoint style, but the flag will force old style still? Thinking some people could want to update their gem version, but still have the old sandbox. At this point there doesn't appear to be a hard cutover to the new style, so there could be a period where people want the latest gem but need to access both sandbox endpoints. Then just have an update requirement for the next version of the gem to set that flag if you still need the old SB endpoint.

Or perhaps we update the gem to use the new style. But we could add a similar config variable to allow for wsdl_domain_sandbox similar to being able to set wsdl_domain if you're on na2 etc. in production.

Thoughts @j-mutter & @iloveitaly ?

@tatecarr The hard cutover is essentially tied to when a user refreshes Sandbox. NetSuite started process in January of 2018. Such a refresh forces the update to use the new domain centered access instead of the old webservices.sandbox model.

It would be best to set the current standard since that's the standard that NetSuite is already on. If a user is using an old version say pre 2017.2 its really on them to maintain. Trying to be data center agnostic is also the way to go if at all possible. It's a chicken/egg problem but since users in my experience don't keep up with the latest in releases in general its good to kind of force them to do so even if it breaks things because the user is using an outdate version.

I like the newer version because its essentially pushing users towards data center agnosticism and essentially forcing the adoption of TBA which is better for everyone.

The best way to determine the correct wsdl url / endpoint for a given account ID (sandbox or production) is to use NetSuite::Utilities.data_center_url('account_id'). The readme has been updated to include more details about setting this up properly.