Provide a TaxAdjustment value object for holding additional tax adjustment information

Created on 9 July 2020, over 4 years ago
Updated 15 November 2024, about 1 month ago

We should provide a TaxAdjustment value object which extends Adjustment. In the United States (maybe others) we often need to capture the jurisdiction data for a tax rate.

Jurisdiction, per Avalara, can be:

  • Country
  • State
  • County
  • City
  • Special Tax Jurisdiction

Source: https://developer.avalara.com/api-reference/avatax/rest/v2/models/enums/...

For instance, in Kenosha, WI a merchant may collect the State sales tax of 5.0%. The county has a sales tax of 0.5%. Just to the north, in Racine and Milwaukee, there is an additional 0.1% special tax for the local stadiums which falls under "Special Tax Jurisdiction".

When displaying taxes to a regular customer we may want to just aggregate all of these into a single tax line. However, for invoicing you may be required to display each jurisdiction's tax detail.

Here's a sample from Avalara

[summary] => Array
        (
            [0] => Array
                (
                    [country] => US
                    [region] => NC
                    [jurisType] => State
                    [jurisCode] => 37
                    [jurisName] => NORTH CAROLINA
                    [taxAuthorityType] => 45
                    [stateAssignedNo] => 
                    [taxType] => Sales
                    [taxSubType] => S
                    [taxName] => NC STATE TAX
                    [rateType] => General
                    [taxable] => 1000.71
                    [rate] => 0.0475
                    [tax] => 47.54
                    [taxCalculated] => 47.54
                    [nonTaxable] => 0
                    [exemption] => 0
                )

            [1] => Array
                (
                    [country] => US
                    [region] => NC
                    [jurisType] => County
                    [jurisCode] => 063
                    [jurisName] => DURHAM
                    [taxAuthorityType] => 45
                    [stateAssignedNo] => 32
                    [taxType] => Sales
                    [taxSubType] => S
                    [taxName] => NC COUNTY TAX
                    [rateType] => General
                    [taxable] => 1000.71
                    [rate] => 0.0225
                    [tax] => 22.51
                    [taxCalculated] => 22.51
                    [nonTaxable] => 0
                    [exemption] => 0
                )

            [2] => Array
                (
                    [country] => US
                    [region] => NC
                    [jurisType] => Special
                    [jurisCode] => 1237063001
                    [jurisName] => DURHAM CO TR
                    [taxAuthorityType] => 45
                    [stateAssignedNo] => 32
                    [taxType] => Sales
                    [taxSubType] => S
                    [taxName] => NC SPECIAL TAX
                    [rateType] => General
                    [taxable] => 1000.71
                    [rate] => 0.005
                    [tax] => 5
                    [taxCalculated] => 5
                    [nonTaxable] => 0
                    [exemption] => 0
                )

        )
Feature request
Status

Active

Version

3.0

Component

Tax

Created by

🇺🇸United States mglaman WI, USA

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇩🇪Germany Anybody Porta Westfalica

    Might also be helpful in combination with 🐛 Can't distinguish two taxes of different percentages in the order summary Needs review

  • 🇮🇱Israel jsacksick

    @anybody: I don't think this is related at all... The other issue can be addressed by using the percentage that is stored in the adjustment object.

  • 🇮🇱Israel jsacksick

    Perhaps we need to introduce a "data" array to adjustments... The problem is, serialized adjustments are already taking up a lot of space in DB... On sites with a relatively large number of orders, the order adjustments table is often the table that takes the most space... Might not be a good idea to just allow storing everything.

    Also, with that said, adjustments are currently "final". Marking this as "won't fix" considering nobody expressed interest since this was first opened 4 years ago.

Production build 0.71.5 2024