[16.0][MIG] sale_product_variant_attribute_tax: Migration to version 16.0

[carolinafernandez-tecnativa]

• Depends on: [16.0][MIG] sale_variant_configurator: Migration to version 16.0 #353
• sale_variant_configurator dependency needed otherwise getting error message product_attribute_lines key error.
• Remove sale dependency as sale_variant_configurator already has sale dependency

@Tecnativa
TT46598

@pedrobaeza @pilarvargas-tecnativa

[pedrobaeza]

/ocabot migration sale_product_variant_attribute_tax

[pedrobaeza]

cc @carolinafernandez-tecnativa

[pedrobaeza]

@victoralmau is it OK for you?

[victoralmau]

Thinking again about this functionality, I don't understand not included in sale_variant_configurator (is probably related to i don't understand the need for product_variant_attribute_tax because you could always use the template taxes, but that's another debate).

[pedrobaeza]

Let me explain this feature, that is somehow independent of sale_variant_configurator, but right now it's linked for not doing 2 modules.

The question is that the product taxes are defined at template level, so you can't have some variants with an specific tax. The use case of our customer is that one attribute makes that all the variants with such attribute has different taxes. This module + the other one covers this gap adding the taxes at attribute level for having to define it only once, instead of searching for other solution like having taxes at template level that forces you to define the specific taxes for each of the variants that are affected.

[pedrobaeza]

• Please squash the first 3 commits into one.
• You must split your migration into 2 commits: the pre-commit one + the real migration one.
• Attend the rest of the inline comments.

[victoralmau]

Let me explain this feature, that is somehow independent of sale_variant_configurator, but right now it's linked for not doing 2 modules.

The question is that the product taxes are defined at template level, so you can't have some variants with an specific tax. The use case of our customer is that one attribute makes that all the variants with such attribute has different taxes. This module + the other one covers this gap adding the taxes at attribute level for having to define it only once, instead of searching for other solution like having taxes at template level that forces you to define the specific taxes for each of the variants that are affected.

Ok, now I understand the requirement, thanks for clarifying.

[pedrobaeza]

@carolinafernandez-tecnativa can you please finish this. You can include my previous reasoning as CONTEXT.rst in the readme.

[carolinafernandez-tecnativa]

@carolinafernandez-tecnativa can you please finish this. You can include my previous reasoning as CONTEXT.rst in the readme.

done

[carolinafernandez-tecnativa]

• Please squash the first 3 commits into one.
• You must split your migration into 2 commits: the pre-commit one + the real migration one.
• Attend the rest of the inline comments.

pending to do

[carolinafernandez-tecnativa]

@victoralmau could you please help me with this?thanks!

[carolinafernandez-tecnativa]

ping @pedrobaeza

[carolinafernandez-tecnativa]

ping @pedrobaeza

[pedrobaeza]

/ocabot merge nobump

[OCA-git-bot]

This PR looks fantastic, let's merge it!
Prepared branch 16.0-ocabot-merge-pr-354-by-pedrobaeza-bump-nobump, awaiting test results.

[OCA-git-bot]

Congratulations, your PR was merged at 1056803. Thanks a lot for contributing to OCA. ❤️