Error: Valid postal code format after UPU

[in-session]

Hello everyone,

We are currently experiencing a problem when creating shipping labels:

Versandetikett konnte nicht erstellt werden: Error 400: 0 of 1 shipment successfully created. 
Bad Request Error (consignee.postalCode): Parameter postalCode must be a valid postal code format after UPU.

We cannot currently see a problem with the delivery address. The delivery address is a regular postcode in Germany with 5 digits.
We had already delivered to the same delivery address several times, there seems to be a small problem since the last update.

Do you have any ideas?

Best Regards Christoph

[ngolatka]

Hello @in-session
Please inspect the request in the log. I suspect there might simply be a white-space after the ZIP code.

This sometimes happens when people use mobile devices. The "keyboard" might automatically put a white-space after the input when using the autocomplete feature.

[in-session]

Hi Normen,

You are right, I had already checked the database but found a whitespace in the sales_order_address.
I guess it wouldn`t be bad to apply a trim here before sending the data to the API?

Greetings Christoph

[ngolatka]

Well, not really, because then the data would still be incorrect for all the other processes inside Magento.

The better approach would be to trim immediately after checkout, so that everything has clean(er) data to work with.

[in-session]

Ok thanks I will have another look at the frontend and adjust the inputs via script so that the problem is solved before sending.

[in-session]

Sorry but I have to open this again, it seems that there is no trim from the core. This means that basically whitespaces are inserted in the DB. Therefore, you should indeed make a trim for the address data in the API query to avoid such errors in the future. Of course, the data will still be in the database, but at least you can avoid the API error.

[ngolatka]

That's correct, Magento does not trim the data out-of-the-box. You need to implement that yourself.

We don't really want to do this in our DHL module, because as I explained, it would not solve the underlying issue, and actually mask a problem. Better fix the problem where it's coming from.

Also, it is not the responsibility of our DHL Shipping module to correct invalid user input. That's the job of the Deutsche Post Direkt Autocomplete module, or even the Addressfactory module.