[16.0][IMP] account_avatax_[sale]_oca: support multiple taxes appearing on each line instead of one

[xaviedoanhduy]

Context:

The issue addressed in PR involves handling split tax lines from Avalara—where a single invoice line (e.g., $100) might be taxed at multiple rates (e.g., 4% on $75 and 4.5% on $25). however recalculating the rate leads to incorrect rate values as the amounts involved in the recalculation have been rounded by Avalara.

What this PR improves:

This PR enhances the solution with a cleaner and more maintainable approach:

• Uses Avalara API details directly: Instead of calculating an average rate or recaculate rate, this PR reads each component tax (rate, taxName) directly from the API response.
• Creates one Odoo tax per detail: Each tax line in the API response maps to a specific account.tax record in Odoo, improving traceability and avoiding ambiguity.
• Prevents unnecessary tax creation: Ensures tax records are generated with valid, legit names (with absolute rate) (e.g., Local Tax [Code] 4.5%) and prevents issues caused by auto-generating taxes with obscure rate names (e.g., 9.75**).
• More transparent tax totals: Makes the resulting tax structure more aligned with Avalara’s breakdown and more user-friendly - This allows us to easily compare tax information on each line from the API response logs.

Example from PR results and a little review of some issues: We should pay attention to the first line

• Before PR-371 merged: if we sum all percent -> the total percentage will be <=> 7 + 2.75 + 2.25 + 0.5 = 12.5% => total taxes = 750,125 instead of 585,10
• Current state of code (after PR#371): the current code has recalculated the correct tax value for each small detail, but there are some issues with the recalculated rate value not being an absolute and valid number for tax as mentioned above.
• With this PR: Each individual rate is preserved as-is and generates clean tax lines for each line, such as image below

[OCA-git-bot]

Hi @dreispt,
some modules you are maintaining are being modified, check this out!

[dreispt]

@xaviedoanhduy Originally I had concerns this could lead to more rounding issues.
Looking back from a distance, it might be the case this actually helps reducing rounding differences.

I'm in to taking this, and even have it enabled by default.
It should be an option, to not disturb existing users that don't want to change.

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.