customer address vat id is not saved on saving address

[Styopchik]

When customer register an account, and then tries to save address (billing/shipping) vat_id disapears from form every time

Preconditions

1. Magento 2.1.2
2. php 7.0

Steps to reproduce

1. Enable VAT ID checking for customers
2. Go to customer account
3. add an address, fill correct VAT ID
4. save.
5. Open address again to edit

Expected result

1. VAT ID is not empty

Actual result

1. VAT ID is empty
   

also, when customer is assigned to customer group without tax, prices in catalog displays correctly (without tax), But in order there still is a tax

[pisc-software]

+1
Tracing this into Resource->save() it seems that the VAT ID is not written to the related database table "customer_address_entity", it is present in the model and data model but not being saved to the database table. Hence on page reload the data is lost.

Also in Magento 2.1.4 on PHP 7 / Zend Server and reported from customers on Magento Community and Enterprise edition alike.

[bpoiss]

The feature "Enable Automatic Assignment to Customer Group" is not working because of this issue.

[pisc-software]

Ok we found something out related to this:

We are the developer of the EuVAT for Magento extension and that one also affected our extension. Tracing this back down to the database access level and transactions we found that any module / extension using the "customer_address_save_after" event and causing the customer account to be saved did add a second UPDATE statement to the original address save UPDATE statement into the same transaction.

Saving the customer model of the related address does read the address data from the DB, but it still has the original data as the transaction is still open. When changing over to the "customer _address_save_commit_after" event that one works.

So when using the "Enable Automatic Assignment to Customer Group" feature the customer account is being saved in the "customer_address_save_after" observer of the "Magento/Customer" module when there is the address data save transaction still in pending and uncommitted to the database.

In Magento/Customer/Model/ResourceModel/Customer/Relation the function processRelation(\Magento\Framework\Model\AbstractModel $customer) is called on saving the customer account. And it gets the customers addresses from the DB where the original customer address save is still in open transaction (delivering the original address data from the DB to the model), and adding a second update statement to the transaction (to save the updated customer address relation) that actually resets the address data back to the status before the transaction was started.

So to fix this the following needs to be changed on the Magento Customer module to have the "AfterAddresSaveObserver" being invoked on the "customer_address_save_commit_after" event where the changed address data is commited to the DB:

File:
vendor/magento/module-customer/etc/events.xml

From:

<event name="customer_address_save_after">
        <observer name="customer_addres_after_save_viv_observer" instance="Magento\Customer\Observer\AfterAddressSaveObserver" />
</event>

To:

<event name="customer_address_save_commit_after">
        <observer name="customer_addres_after_save_viv_observer" instance="Magento\Customer\Observer\AfterAddressSaveObserver" />
</event>

Hope that this will be included in the next Magento release.

[bpoiss]

In my case the problem was that vat_id was not included in the DB table customer_form_attribute, and it was also not in the customer address attribute set.

INSERT INTO `customer_form_attribute` (form_code, attribute_id) VALUES ('customer_address_edit', (SELECT attribute_id from eav_attribute where attribute_code = 'vat_id' and entity_type_id = (select entity_type_id from eav_entity_type where entity_type_code = 'customer_address')));

and

INSERT INTO eav_entity_attribute (entity_type_id, attribute_set_id, attribute_group_id, attribute_id, sort_order) VALUES (2, 2, 2, (SELECT attribute_id from eav_attribute where attribute_code = 'vat_id' and entity_type_id = (select entity_type_id from eav_entity_type where entity_type_code = 'customer_address')), 150);

with 2 as entity_type_id, attribute_set_id (from customer address attribute set) and also attribute_group_id (if you have other ids you have to change the values).

To find out your customer attribute set id you can run select * from eav_attribute_set where entity_type_id = 2; and find the right set, in case of data migration there can be multiple.

[pascaladriaansen]

We are having the same issue on Magento CE 2.1.4. Unfortunately, it seems the solution posted by @pisc-software does not resolve this issue.

I'm guessing (also with @pisc-software's 'fix') this is happening because even though the changes to the customer address have already been saved once the Magento\Customer\Observer\AfterAddressSaveObserver::execute() is executed, the customer object inside the customer address object that's passed to the observer still contains the 'old' address. Then, when $customer->save() is called, it re-saves the old address.

This is a pretty important feature for our clients selling B2B.

EDIT: I just found a possible fix/workaround. By making sure the $customer object that's being saved doesn't have any addresses in its _addressCollection, the address won't be re-saved upon the $customer->save() call.
This can be done by adding the line: $customer->getAddressesCollection()->clear(); after line 125 in module-customer/Observer/AfterAddresSaveObserver.php. Of course, it would be better to implement this fix/workaround using a Plugin/Interceptor.

[pisc-software]

That is correct, we later also found out what the real underlying issues was as our "fix" did turn out not to fully work. That is because we opened this one here as the underlying cause:

#8855

We ended up to recoding our function depending on the "customer_address_save_after" event observer into a plugin.

We find it really annoying with Magento 2 that these nifty ideas of separating models and data actually creates a lot of cost on our end to rewrite our extensions as we are converting them to M2. Unnecessary cost, and this one here shows that the data persistency across models (something that simply worked in M1.9) is now starting to be getting compromised by the new code structure that is continuously being introduced by the Magento Developers. And where we need to go through all of our code on every new release to find out deprecated functions and to pull our code up to the status.

We currently are not recommending our customers to use M2, and are still more productive and have higher stability on stores with M1.9.

[heyqule]

I'm not sure if this is related. But it sounds similar to what I saw.

I created a new customer address attribute from admin. It's a yes/no attribute. That attribute's value does not get saved when I save in the address editing forms in either frontend or admin.

The Magento version is 2.1.5.