New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

customer address vat id is not saved on saving address #7668

Closed
Styopchik opened this Issue Dec 2, 2016 · 8 comments

Comments

@Styopchik

Styopchik commented Dec 2, 2016

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
    1

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

2
3

@pisc-software

This comment has been minimized.

pisc-software commented Feb 28, 2017

+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

This comment has been minimized.

bpoiss commented Mar 6, 2017

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

@pisc-software

This comment has been minimized.

pisc-software commented Mar 6, 2017

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

This comment has been minimized.

bpoiss commented Mar 7, 2017

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

This comment has been minimized.

pascaladriaansen commented Mar 21, 2017

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

This comment has been minimized.

pisc-software commented Mar 21, 2017

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

This comment has been minimized.

heyqule commented Mar 29, 2017

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.

@magento-engcom-team

This comment has been minimized.

Contributor

magento-engcom-team commented Oct 11, 2017

@Styopchik, thank you for your report.
We were not able to reproduce this issue by following the steps you provided. If you'd like to update it, please reopen the issue.
We tested the issue on 2.1.9

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment