customer address vat id is not saved on saving address #7668
When customer register an account, and then tries to save address (billing/shipping) vat_id disapears from form every time
Steps to reproduce
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
The text was updated successfully, but these errors were encountered:
Also in Magento 2.1.4 on PHP 7 / Zend Server and reported from customers on Magento Community and Enterprise edition alike.
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.
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:
Hope that this will be included in the next Magento release.
In my case the problem was that vat_id was not included in the DB table
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
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
This is a pretty important feature for our clients selling B2B.
EDIT: I just found a possible fix/workaround. By making sure the
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:
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.
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.
Thanks to @bpoiss for the hint. Spent 1 day searching for this problem.
Migration from v1.6 to v2.3.3 with the Data Migration Tool resulted in not saving the VAT number. Neither in frontend and backend.
Resulted in ID 563 while a fresh install returned ID 2.
ID 563 was not added to table customer_form_attribute so I added 3 records.
Table eav_entity_attribute was also missing ID 563. So query of bpoiss was correct.