feat(tax): introduce tax override data models

[srindom]

What

• Adds Tax rules to allow overrides of tax rates for certain products, product types or shipping options.

Punted to future PR

• Currently, the creation methods only support bulk operations. A later PR will include support for singular operations, too.
• It should be possible to add products, types, and shipping options to a tax rate after creating it. Add, remove, update will come in a later PR.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
api-reference	🔄 Building (Inspect)	Visit Preview		Feb 20, 2024 4:26pm
medusa-dashboard	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 20, 2024 4:26pm

2 Ignored Deployments

Name	Status	Preview	Comments	Updated (UTC)
docs-ui	⬜️ Ignored (Inspect)	Visit Preview		Feb 20, 2024 4:26pm
medusa-docs	⬜️ Ignored (Inspect)	Visit Preview		Feb 20, 2024 4:26pm

[changeset-bot]

⚠️ No Changeset found

Latest commit: 7a51965

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[carlos-r-l-rodrigues]

If we make them specific for product, shipping, product_type, wouldn't it make sense to have them as link definitions?

If we are to keep them in the module, we could just create a single generic table, where you specify a reference and a reference_id and enable these specific taxes for anything.

[srindom]

If we make them specific for product, shipping, product_type, wouldn't it make sense to have them as link definitions?

I wanted to include them into the tax module because this gives the tax module the feature of having tax overrides. If the rules only exist as relations we make it a task for the consumer to find the right tax rates (as opposed to exposing a taxModuleService.getItemTaxLines(arrayOfItemLikeStructures, calculationContextEgAddress)). It would probably make sense to have readonly links here to make them queriable with remote query, but wouldn't consider it strictly necessary.

If we are to keep them in the module, we could just create a single generic table, where you specify a reference and a reference_id and enable these specific taxes for anything.

Yeah this might actually be better - is it possible to have links like this?

[carlos-r-l-rodrigues]

Yeah this might actually be better - is it possible to have links like this?

Other modules are copying the TaxRate internally at the moment. I am not sure I get which link you mean.
These would be used to calculate a tax rate given a context no? where, type is included.

[srindom]

I am not sure I get which link you mean.

The one I was thinking about was one that could be used in remoteQuery to allow a query like this:

product {
  tax_rate_rules {
    tax_rate {
      rate
    }
  }
}

I.e., if it were possible for remote query to understand a link like "reference_type + reference_id".

But this was more out of curiosity, not something that is required at all.

[carlos-r-l-rodrigues]

Depending on how filters will be passed to fetch data from this table, probably individual indexes on tax_rate_id, reference_id and reference_type will be a better choice than this composite primary key.
Keeping the composite key and adding additional indexes is also an option.

[carlos-r-l-rodrigues]

The one I was thinking about was one that could be used in remoteQuery to allow a query like this:

product {
  tax_rate_rules {
    tax_rate {
      rate
    }
  }
}

I.e., if it were possible for remote query to understand a link like "reference_type + reference_id".

But this was more out of curiosity, not something that is required at all.

This isn't implemented at the moment, but it's definitely doable