Empty streetNumber for Receiver isn't updated if present in streetName.

[dyron]

Change description Could you add splitStreet() to UpdateShippingInfoObserver or AppDataMapper if Receiver->streetNumber is empty.

Reason Our customer had the error message "Shipping labels could not be created: Hard validation error occured." because "Alter Berg 6" isn't split.

Additional context After storing the incorrect shippingInfo->receiver, there is only the chance updating the receiver address by manual editing the magento shipping address. Maybe it's more convenient checking for a street number again.

Magento version: 2.2.6 Module version: 0.9.1

[MarcusWolschon]

@dyron if you need a temporary workaround until this issue is fixed and part of a release, look at my code-example at the bottom of https://github.com/netresearch/dhl-module-shipping-m2/issues/36 !

[dyron]

splitStreet works fine on "Alter Berg 6", but isn't called. So no need for your normalization. Thanks anyway.

[muh-nr]

Dear dyron,

are you using a third-party checkout module? Please make sure that the address data is passed on correctly to the default street1 field. Otherwise the _dhlversenden module may not split it correctly.

Best regards Mathias Netresearch Support

[dyron]

Hello Mathias,

the native Magento checkout is used with a slightly reordered address edit form, but id- or name-attributes weren't changed. Other addresses are working well.

[muh-nr]

Hello, sorry, but I have no idea, why splitStreet shouldn't be called on the default address field. As you mentioned, splitStreet works correctly on the example address. Did you try it with a new order or did you change the address later in the admin area.

Please describe how this special address could avoid the validation of the street1 field.

Best regards Mathias Netresearch Support

[ngolatka]

@dyron I think it wouldn't be a good idea to interfere with the address saving while the merchant is editing the shipping address.

Reason: the address editing form is there to give them full control over what goes where, i.e. which value is stored in which field, and correct any errors. An automated process that tried to (again) split the address at this time would probably cause more harm than good, in my opinion.

[ngolatka]

@dyron Any further questions from you about this? Or was this a one-time problem and we can close this issue?

[simonmaass]

I am having the same problem with the streetadress number split:

[ngolatka]

@simonmaass What happens if you create a new order with the same address yourself? Does the problem occur every time consistently?

If yes, can you please post the address (without any sensitive parts, of course)?

[dyron]

@muh-nr @ngolatka I don't think it's a one timer, since our customer made three orders, which contains "Alter Berg 6" street. I don't think they edit the DHL "Street Name" in the adminhtml shipping address edit form three times. Coming from the frontend, it should have been splitted correctly? Running splitStreet() on "Alter Berg 6" directly gives me the expected result. So I think, splitStreet() wasn't run at all and i thought UpdateShippingInfoObserver or AppDataMapper were the right places.

[muh-nr]

@dyron I couldn't reproduce the problem. I created a new order (via shop frontend) with the following address and the split process has been executed properly: Alter Berg 6 07907 Schleiz

I suggest to check your specific shop configuration. Please open a support ticket on http://dhl.support.netresearch.de and send us your shop address.

[ngolatka]

Because there has been no feedback for two weeks, I'm closing this issue now.

Feel free to reopen it if you have something to contribute.