QA: Feature parity - Taxes & Plugin

[lkostrowski]

QA: Taxes vs. Plugin feature parity

Context

The Taxes App is a replacement for the tax plugins (namely, the Avalara plugin). We must make sure all the features of the Avalara plugin are, in some form, present in the Taxes App.

Because calculating taxes is a critical and complex domain, I would like to invite world-renowned tax experts: @korycins and @szczecha. Before completely deprecating the plugins, we must ensure we didn't miss anything.

I am splitting this task into two subtasks: creating the test suites and the actual testing. If possible, I would like all of us to be involved in the first part. The purpose is to ensure we have no gaps in our test suites. Only the QA team will be involved in the second part (although @korycins if you would like to give Taxes App a look and share your feedback, that would be appreciated).

Test suites

Avatax dashboard

The orders created by the Taxes App should display the same way in the Avatax dashboard. If there are any differences, please note them down.

Tax calculation

The result of the tax calculations performed by the Taxes App should be the same as for the plugin.

Configuration

All the configuration fields from the Avalara plugin should be present in the Taxes App, and should work correctly.

Tax classes

The tax classes created in Saleor should affect the tax calculations. Taxes App achieves it through Tax Code Matcher. I am not 100% sure how it worked before.

Todo

### Tasks
- [ ] https://github.com/saleor/apps/issues/779
- [ ] https://github.com/saleor/apps/issues/780
- [ ] https://github.com/saleor/apps/issues/781

[lkostrowski]

Please involve Ania and Maciek K

[korycins]

• prices provided in net/gross are taken into account by the App
• staff user can assign the app to the specific channel
• staff user can have different tax apps assigned to different channels
• staff user has the possibility to set up different tax codes to the product/product type
• staff user has the possibility to set up the tax code for shipping methods
• staff can prepare the configuration, test it and then activate it with a single button.
• Tax App doesn't allow activate configuration when provided tax provider credentials are incorrect
• Tax App handles the discounts field received from the Saleor (https://docs.saleor.io/docs/3.x/developer/extending/apps/synchronous-webhooks/tax-webhooks#fields)
• Tax App uses the tax code based on the assigned tax group by the staff user.
• Tax App can handle currencies like JPY (JPY doesn't have a decimal number).
• Tax app can handle price rounding correctly. A case like: unit_price 3.66, discount %5, quanityt 3

[szczecha]

• Tax app should Always send all lines to Avalara (including products with metadata {'avatax.code': 'NT', 'avatax.description': 'No taxes'} )
• Staff should be able to update order data for digital orders with Avalara
• Complete checkout with a FreeShipping voucher and Avalara
• Calculate taxes in a channel that has country exception set up to use tax app

[peelar]

Thanks for your input @szczecha and @korycins 🙇. I looked through it and split it up into several groups.

Ready to be tested:

• prices provided in net/gross are taken into account by the App
• staff user can assign the app to the specific channel
• staff user can have different tax apps assigned to different channels
• staff user has the possibility to set up the tax code for shipping methods
• Tax App doesn't allow activate configuration when provided tax provider credentials are incorrect
• Tax App handles the discounts field received from the Saleor (https://docs.saleor.io/docs/3.x/developer/extending/apps/synchronous-webhooks/tax-webhooks#fields)
• Tax app can handle price rounding correctly. A case like: unit_price 3.66, discount %5, quanityt 3
• Staff should be able to update order data for digital orders with Avalara
• Complete checkout with a FreeShipping voucher and Avalara

To implement (for me):

• [ ] Taxes App can handle currencies like JPY (JPY doesn't have a decimal number).
• [ ] Taxes App inherits the tax class from either the product or the product type.
• [ ] Country exceptions in Taxes App

[szczecha]

Tax app should Always send all lines to Avalara (including products with metadata {'avatax.code': 'NT', 'avatax.description': 'No taxes'} )

https://github.com/saleor/saleor/pull/12681

Staff should be able to update order data for digital orders with Avalara

Steps:https://github.com/saleor/saleor/issues/11586

Complete checkout with a FreeShipping voucher and Avalara

Steps: https://github.com/saleor/saleor/issues/11786

[szczecha]

Calculate taxes in a channel that has country exception set up to use tax app

Before: Update tax configuration for default-channel

"chargeTaxes": true,
    "taxCalculationStrategy": "FLAT_RATES",
    "displayGrossPrices": true,
    "pricesEnteredWithTax": false,

Add exception for USA

"updateCountriesConfiguration": [
      {
        "countryCode": "US",
        "chargeTaxes": true,
        "taxCalculationStrategy": "TAX_APP",
        "displayGrossPrices": true
      }
    ],

Update US Country default rate to 20%

Steps: Create checkout with US shipping and billing address Assign shipping method

Verify that taxes are calculated by APP not by flat rate

[korycins]

@peelar

What do you mean by "test it"?

Make a test request to the tax provider. We had a lot of situations when staff users didn't provide the correct pair of username&password. This is something that we can and should validate before allowing users to activate the specific configuration for assigned channels.

You mean via "tax class"?

Yes, I meant tax class. Sorry.

How would a staff user assign a tax code to a product differently than through the tax class?

Right, it should work out of the box. The case that you should double check is the flow, when specific product has overwritten tax class from product type. Like App implementation needs to know that tax group that is assigned to product is more important than the one from productType

[peelar]

Make a test request to the tax provider. We had a lot of situations when staff users didn't provide the correct pair of username&password.

We validate the credentials against the provider API before you create a configuration 👍 .

The case that you should double check is the flow, when specific product has overwritten tax class from product type

Got it, thanks!