Closed 11mb closed 5 years ago
I can confirm this function is broken:
$locations = $client->getNearestLocations($zip, false, null, $country);
Results in errors:
I tried to set it manually, but the same error.
This is the same for the confirming webservice. They essentially changed the behaviour of the new endpoints, instead of just different authentication. I've already gotten an acknowledgement from PostNL in this regard.
Maybe, but getNearestLocations($zip, false, null, $country) sets AllowSundaySorting to false (2nd argument). So the error might indicate there is something broken in the library as well.
It should be a string "true"/"false". According to the WSDL, the value is simply a string.
However, looks like the OpeningTime error can't be solved, like #63
Isn't it possible to add the variables dynamicly to the class?
It would mean adding class annotation like @property string $openingTime
and removing the properties. Not necessarily a big deal, but PostNL violates their WSDL so it's a won't fix.
Besides, I have no clue for how many properties I would need to do that
This has already cost us a lot of time.
Do you have contact about this issue with PostNL? Is there something I can support you with?
They acknowledged the issue and apparently they're working on it. I hope to hear news next week.
They made a new release last monday. This should be resolved. Can you test?
I can confirm it is fixed.
Great. Thanks for confirming
Yes it is working indeed. Thanks for your effort @ameenross!
Expected Behavior
When calling
Postnl::getNearestLocations
I Expect a response with dropoff locations.Current Behavior
When executed, the response is an error:
Steps to Reproduce
Workaround
It looks like PostNL doesnt like the empty key
OpeningTime
. A Quick workaround is to disable line 24 in BaseLocation:Version v2.0.0-beta1