Issue when Submitting Creditmemo to AvaTax (Two times capture amount for credit memo)

[rameshramachandran84-zz]

Hi,

We are working on a requirement for a client using Avalara AvaTax. We have noticed an issue when submitting Credit memo to AvaTax. The issue is that even if all the amount is already refunded and Order status is closed, AvaTax extension is again refunding the total amount offline and changing the Status. This causing some issue with our third-party integration since the Status is also getting changed.

The issue is happening due to the following code in the function 'updateAdditionalEntityAttributes()' of the file 'ClassyLlama\AvaTax\Model\Queue\Processing.php'.

$entityRepository->save($entity);

To solve the issue we have commented out the above line if the entity type is 'creditmemo'. Can you please let us know if this line is really needed. Will there any impact if this is commented out?

Thanks
Deffy

[rameshramachandran84-zz]

Is there any update on this? We would really appreciate it if we can get reply for our doubt. There has been no update from your end for the past 4 days. We are awaiting information from your end to proceed with our work. This is really important. Kindly treat this as priority.

Thanks
Deffy

[erikhansen]

@rameshramachandran84 In short, it should fine to temporarily comment out the line below on a production site:

$entityRepository->save($entity);

What that code does is not a critical component of the extension. In order to understand why the AvaTax module currently saves invoice and credit memo records, please read the 6.A UNBALANCED QUEUE ITEMS section on this page.

The the \ClassyLlama\AvaTax\Model\Queue::updateAdditionalEntityAttributes method saves the invoice/credit memo for one of two reasons:

1. The Magento vs AvaTax tax amount is "unbalanced", so it needs to update the avatax_is_unbalanced with a value of 1.

2. The amount of tax that AvaTax calculated for the invoice/credit memo is saved in the base_avatax_tax_amount field in case any future reporting needs to be done to compare Magento vs AvaTax tax calculation.

Here is a screenshot of a local AvaTax testing DB, demonstrating the potential values of the two fields AvaTax adds to the invoice/credit memo fields:

We will be working next week to figure out the core cause of the problem.

[rameshramachandran84-zz]

Hi Erik, Thank you for the update.

Thanks
Deffy

[erikhansen]

@rameshramachandran84 I just merged in PR #41 to the develop branch, which fixes this issue. Before I issue a new release of this extension, can you verify that your issue is resolved by this fix?

[mttjohnson]

FYI: You can use composer to pull in the develop branch this way:
composer require classyllama/module-avatax:dev-develop

[Ian410]

I pulled in the develop branch, validated the code is in use. However, it did not fix the issue. I still get double refunded amount. We are using CE 2.1.2. The payment method is ParadoxLab's Authorize.net CIM.

I did try the original suggestion of commenting out the $entityRepository->save($entity); call and that seemed to fix it. Though, we are missing that non-critical data in the DB which I believe is fine for now.

[rameshramachandran84-zz]

Hi Erik,

We have checked with the latest dev version and seems that the issue is fixed. Thank you very much for the fix.

Thanks
Deffy

[mttjohnson]

@Ian410
We resolved the issues when testing with Braintree issuing online refunds, and it's possible there is something different with the ParadoxLab's Authorize.net refunds, so we are reaching out to ParadoxLab's to try and get their module to test with and reproduce the issue you are seeing on our local development environment.

If you can provide any additional information on what you are seeing when testing this it may help is identify the issue quicker.

The issue is related to some underlying Magento core architecture that expects a credit memo to only ever be saved once when it is created. We add some values to the credit memo during queue processing with AvaTax, and we save the credit memo during that queue processing, but in the latest develop branch we setup some code to bypass the part of the credit memo save that processes related entities and recalculates the totals on the credit memo causing it to duplicate the refund amount.

https://github.com/classyllama/ClassyLlama_AvaTax/blob/84b57042eb6f3ce99e6f1b3a29391327342a9fcb/Plugin/Sales/Model/ResourceModel/Order/Creditmemo/Relation/Refund.php

When the queue processing saves the credit memo this above referenced plugin should get called when it attempts to call processRelation(), and we setup code to bypass the processRelation() call when the specific avatax attributes are changed. It also has a safety check for changes to the totals on the credit memo which shouldn't end up getting changed during queue processing. If for some reason the totals on the credit memo are getting changed by something else when the queue processing attempts to save the avatax attributes it could end up not bypassing the processRelation() call like we are expecting it to.

If I can get everything setup with the ParadoxLabs Authorize.net extension and an account with Authorized.net that I can test CIM functionality I intend to try and reproduce this issue in development and see if the totals on the credit memo are somehow getting altered and causing $prepareDataChanges = true to be set and not bypass the processRelation() call.

[mttjohnson]

@Ian410
I have setup a local development environment with the Paradox Labs CIM extension you had mentioned and have tested creating orders, creating credit memos to issue online refunds with that payment method, and processing the queue to send all documents to AvaTax. I am not able to reproduce the double refund amount appearing on the order.

If you have pulled the develop branch of the AvaTax extension, can you confirm that the vendor/classyllama/module-avatax/Plugin/Sales/Model/ResourceModel/Order/Creditmemo/Relation/Refund.php file exists, and that you have flushed the Magento cache so that it picks up the plugin configuration?

I wouldn't expect it to be necessary to delete the contents of var/generation/ but you may also try that to see if that allows the newest changes in the extension to take affect. Note that if your site is running in production mode, after deleting the var/generation/ contents you'd need to re-run DI Compile to rebuild it, while developer mode will rebuild the var/generation/ contents automatically.

Please let me know if you are still experiencing the issue, and I will work with you directly to try and reproduce the issue on my end so we can get the issue corrected.

[erikhansen]

This issue has been fixed in https://github.com/classyllama/ClassyLlama_AvaTax/releases/tag/0.3.4 Thanks for submitting this issue report. Closing this issue.

@Ian410 If you still experience this issue, please open a new ticket with steps to reproduce this issue.