Customer Group Drop-Down Not Working As Expected on Order Form

[joshuaqueenava]

{}Account Name:{} {}Account Number(s):{} {}Company Code(s):{}
{}AvaTax Environment:{} Production {}ERP Version:{} Magento 2 {}AvaTax Integration Version:{} avalara/avatax: 15.5.2 classyllama/module-avatax: 1.4.9 {}AvaTax Adapter Version:{} {}OS/Browser Version:{} Chrome {}Repro Frequency{} When changing customer groups

{}Description:{} When customer is changing their customer group in Magneto 2, during a manual order, they're not seeing tax recalculate when the group is changed.

Their example is one with exemptions - they have a "Taxable" customer group, and change to an "Exempt" customer group while making the order, but tax doesn't update right away.

This may end up being an enhancement for Classy Llama

When creating a manual order, if the customer group is changed while in the order and then products are added to the order, the initial customer group tax shows in the totals.16:05:21

example: I have set up a tax exempt customer group. I start an order with a customer that is in the general group... change the customer group to tax exempt and add products and there is tax generated as if it were still general.16:06:26

when the order is submitted, the correct tax is calculated.16:06:38

if the customer group is changed after the products are added, the tax shows up correctly in the totals area.16:07:20

{}Steps to Reproduce:{} Create manual transaction in Magento 2 While adding line items, update the customer group from taxable to exempt grouping

{}Expected Result:{} Should recalculate tax after customer group change

{}Actual Result:{} Doesn't recalculate tax until order is submitted

{}Attachments/Documentation:{}

[rsisco]

@joshuaqueenava - I am unable to reproduce this problem. These are the steps I'm using:

• In Magento backend, start a new order for a customer in a taxable customer group by default
• Change the customer group on the new order to a tax exempt group
• Add a product to the order

The result is that no tax is displayed on the order. If I then change the customer group back to taxable, tax is calculated and displayed. Are you able to reproduce the issue in a vanilla Magento install?

[joshuaqueenava]

@rsisco See meeting video below. https://avalara1-my.sharepoint.com/:v:/g/personal/joshua_queen_avalara_com/EYcAWlTK0T9Brr6UOqKZgssBhMHszCYxb7arJGmgt3Ywsw?e=c6rzob

[rsisco]

An internal ticket has been opened to look into this.

[joshuaqueenava]

@rsisco are there any updates on this ticket? Customer is considering a cancellation due to length of issue and lack of resolution.

Thank you.

[prestonchoate]

@joshuaqueenava This task is one I plan on taking care of this week. I likely won't get to start it until tomorrow or Wednesday though.

[prestonchoate]

@joshuaqueenava Good news. I was able to recreate this locally. I will be debugging through it today to try to find a resolution. I will keep you updated.

[prestonchoate]

@joshuaqueenava After spending some extensive time debugging this it appears to be a problem with how Magento is updating the Create Order form on the Admin. There are some Ajax calls that happen each time you update a different area of that form, and depending on what you have edited will determine what values are available on the quote model. For this specific instance the only time that the customer group is actually getting passed to the AvaTax extension is when you have changed that field and any subsequent updates to the form will invalidate the totals that were calculated for that customer group and will instead calculate the totals as if the customer had no group at all. I would imagine this bug could effect more things than just tax calculation such as price rules (if they are set up for specific customer groups) or native Magento Tax Rules. I plan to open an issue on the Magento github for this, but as for the extension itself it is working properly with the data it is being given from Magento. If you turn on debug logging you should actually be able to tell that when the tax is being calculated properly the customer group was set as expected, but when it isn't the customer group is blank. All of that being said I have prepared a commit that will add a note underneath the customer group section of the admin form that links to the Known Issues portion of the extension's documentation, where I have documented the issue.

I should also note that all of that issue I described is purely a visual bug on that form. When you actually click the Submit Order button on the form all of the data (including the customer group) is submitted properly and the tax will calculate out as you would expect when the order is actually placed.

[joshuaqueenava]

Will you keep this ticket open in order to keep us updated on the Magento ticket? The customer who reported this is threatening to cancel over this, so I was hoping we can provide her updates as we get them from Magento.

[prestonchoate]

@joshuaqueenava Sure I can do that.

[joshuaqueenava]

I closed the case on my side. If you usually close these types of issues you can close this ticket.

[joshuaqueenava]

Additional info if it may help:

I just ran across a new issue on our dev site. Due to mas fake customer accounts being created we have decided to add using Captcha on the account creation page. I turned that on in the dev site and when I submitted the form to test I got an error. When I tried going into the all customers page I also got the error.

Fatal error: Uncaught Error: Class 'ClassyLlama\AvaTax\Model\Config\Source\CrossBorderClass\Customer\ImporterOfRecord' not found in /home/loren/public_html/vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php:93 Stack trace: #0 /home/loren/public_html/vendor/magento/framework/ObjectManager/Factory/Compiled.php(88): Magento\Framework\ObjectManager\Factory\AbstractFactory->createObject('ClassyLlama\Ava...', Array) #1 /home/loren/public_html/vendor/magento/framework/ObjectManager/ObjectManager.php(57): Magento\Framework\ObjectManager\Factory\Compiled->create('ClassyLlama\Ava...', Array) #2 /home/loren/public_html/vendor/magento/framework/Validator/UniversalFactory.php(36): Magento\Framework\ObjectManager\ObjectManager->create('ClassyLlama\Ava...', Array) #3 /home/loren/public_html/vendor/magento/module-eav/Model/Entity/Attribute/AbstractAttribute.php(551): Magento\Framework\Validator\UniversalFactory->create('ClassyLlama\Ava...') #4 /home/loren/public_html/vendor/magento/module-customer/Model/AttributeMetad in /home/loren/public_html/vendor/magento/framework/ObjectManager/Factory/AbstractFactory.php on line 93

I don’t know if enabling Captcha is what started the errors or if they were there to begin with after I reinstalled yesterday. I’m doing some investigating but figured I’d see if anything about this error is known of.

I’ll update later with any further findings.

-- Thank You Loren McDonald

[joshuaqueenava]

And this: Joshua, It took quite a bit of troubleshooting but I was finaly able to track the issue down to an attribute in the eav_attribute table that uses that ImporterOfRecord class as it’s source model. Since “Seller is Importer of Record Override” is documented in the Customs, Duty & Import Tax (CDIT) section of the documentation, which wasn’t implimented until v2.x of the extension, I’m assuming this attribute has to be a left over from the v2.x install I had done earlier.

I had found removal isntructions in their documentation which lists some tables to remove and a column in the tax_class table, but it makes no mention of removing the attribute.

Anyway, once I deleted the attribute the error went away.

I probably won’t have any time to do testing until next week, at which time I’ll do the customer group testing you mentioned and let you know.

-- Thank You Loren McDonald IT/Web Development

[prestonchoate]

@joshuaqueenava Thanks for the further information. I will look into updating the documentation about removing that attribute when a v2.0 uninstall happens.