Colorado Retail Delivery Fee in Solidus

[kennyadsl]

Starting in July 2022, retailers will be required to charge, collect, and remit a new fee to the Colorado Department of Revenue (CDOR). And we need to support this behavior in Solidus as soon as possible.

More info here: https://tax.colorado.gov/retail-delivery-fee

Highlights

• Begins July 1, 2022
• Applies to all retail sales delivered by a motor vehicle to a location in Colorado
• Includes third-party deliveries
• $0.27 per retail sale for delivery
• Charged to the purchaser
• Collected by the retailer and remitted to CDOR
• Follows sales tax filing frequencies and due dates
• Filed on a separate return, form DR 1786

This discussion started because we would like to find a collective solution to the problem, and verify if we are taking into account all the possible issues related to this new tax.

Possible Solution

We could implement this in the current taxation system, so that it adds the retail tax as a separate tax line in all the order that has Colorado as the state in their shipping address. Being a separate field, it should work no matter what kind of taxation system stores are using (core, Avalara, TaxJar), because those do not currently support this tax out of the box.

This behavior should be easily disableable because external taxation systems could start to support this new tax anytime and we need to be able to promptly disable the core calculation. Depending on how we implement this, it could be a boolean on a tax rate, on the state, or a top-level preference.

What Shopify does?

I found this document from Shopify that explain how they solved the problem, answering some of the questions we may have. Please, note that it's not guaranteed that their solution complies with the regulation and we should still go with the right long-term solution.

---

Did anyone start thinking about this or already implement this in their store?

[mamhoff]

Should it not be as "simple" as adding a tax adjustment to each shipment? With a dead simple "flat rate" tax calculator that always computes to 27 cents, and a state-based zone that only includes Colorado?

[adammathys]

It's not per shipment though. It's per "retail sale" so there should only be one per order regardless of how many shipments it takes to fulfill the order.

[adammathys]

I believe there are two separate issues/areas that will need some work to help accommodate this new fee/tax:

1. Our higher level TaxCalculator::Default and OrderTaxation models will need to be updated to handle order-level adjustments. Since the new fee is per order and not per item/shipment, we'll need to have the ability for those classes to correctly pass along order-level taxes. This work will also help us prepare for third-party tax systems supporting this since they will presumably need to pass along the order-level tax to Solidus to be applied.

2. Come up with a strategy for storing the tax rule and amount. Our TaxRate is unfortunately fairly tightly coupled to items/shipments. So we'll either need to modify it to handle applying tax to an order or come up with a new similar concept we can use specifically for order-level fees/taxes.

[jarednorman]

I wish Colorado had asked me before implementing this tax. Forcing an order-level adjustment on us and requiring it be a separate line item (even if they are being lenient in enforcing that) is not going to play nice with many accounting systems.

[vassalloandrea]

Since the tax is related to the transport of tangible materials on Colorado soil using motor vehicles, are we sure that the tax must be added at the order level instead of the shipment?

If you are right, this solution seems complete but perhaps a third point is missing. Many sites show all the taxes added together inside the cart but this particular tax must be delivered separately. Should we show the order-level adjustments separately?

[adammathys]

From https://tax.colorado.gov/retail-delivery-fee:

Each sale for delivery is considered a single “retail delivery” regardless of how many shipments are needed to deliver the items purchased.

[waiting-for-dev]

Thanks, @adammathys for #4477.

As per the path forward, as @adammathys said in #4452, we need to update the default tax calculator to compute order-level taxes. The problem is that, at this point, it applies the rate in the associated tax rate models to both line items and shipping. I thought about adding a radio button for "order" vs. "line items & shipments" or check boxes for any combination of order, line items & shipments, although not all of them would make sense (we could add validations). About adding yet another model for order-level taxes, I'm not sure it'd be good to generalize it even more. @adammathys, @solidusio/core-team, what are your thoughts?

Besides, we need to update extensions to create the new order taxes.

[adammathys]

@waiting-for-dev Yeah, I've been going back and forth on how best to handle this as well. I finally just settled on an enum on Spree:TaxRate and a radio button on the admin so that we could get something concrete up for discussion.

All of that work is in a draft PR now: #4491. I think it's like 80% of the way there, just needs some polish. But it does currently calculate the delivery fee and applies it to the order in a fairly reasonable way.

[dhonig]

FWIW, I read the requirement very similar to Martin. Why can this not just be an adjustment applied to the order when the state is colorado. I think this could be solved with the current promotions engine without coding.

…

On Thu, Jul 14, 2022 at 12:57 PM Martin Meyerhoff ***@***.***> wrote: Should it not be as "simple" as adding a tax adjustment to each shipment? With a dead simple "flat rate" tax calculator that always computes to 27 cents, and a state-based zone that only includes Colorado? — Reply to this email directly, view it on GitHub <#4452 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZTL5RTWVPANX27L67G63VUBBH5ANCNFSM53SWLRYA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[adammathys]

The current promotions engine could probably be modified to help work for this, but certainly not without some additional code. For starters, there's no "State" rule for promotions so that would need to be added. And this doesn't account for the adjustment needing to be non-refundable.

Also, more importantly, promotions are meant to be used for creating discounts. Not taxes/fees. And you'd run into issues if you had any "regular" discount promotions that should be applied to the order due to the one applied promotion per order logic. I would strongly advise against trying to shoehorn this new tax into the current promotion system.

[dhonig]

Those are probably all fair points....Might be best as a separate concern. Just the promotion system is a set of powerful primitives that work well together. I'd love to see the thinking on it expanded and enhanced to be more than just 'discounts'. Perhaps something simple and generic could be put in place for "Tax Rules" that offers the same level of flexibility.

…

On Thu, Jul 14, 2022 at 4:13 PM Adam Mueller ***@***.***> wrote: The current promotions engine could probably be modified to help work for this, but certainly not without some additional code. For starters, there's no "State" rule for promotions so that would need to be added. And this doesn't account for the adjustment needing to be non-refundable. Also, more importantly, promotions are meant to be used for creating discounts. Not taxes/fees. And you'd run into issues if you had any "regular" discount promotions that should be applied to the order due to the one applied promotion per order logic. I would strongly advise against trying to shoehorn this new tax into the current promotion system. — Reply to this email directly, view it on GitHub <#4452 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABZTL33DLMQHJN55JR5AV3VUBYFXANCNFSM53SWLRYA> . You are receiving this because you commented.Message ID: ***@***.***>

[jarednorman]

It's going to make this conversation hard to follow if you keep responding via email. You're starting a new thread on the website every time you do it. Unlike issues and PRs, GitHub Discussions doesn't play nice with email. (I'm not really even sure why it supports it.)

[jarednorman]

To address your point: @mamhoff has been working on changes to the promotions system to do the opposite, make the promotions system only about discounts and I'm more in favour of that approach. The other stuff it does now either doesn't not really work or doesn't work well. That's probably a discussion for having on those PRs/issues though.

In the other thread we discuss that we already have a really good extension point to handle specialized tax needs, the configurable tax calculator point. We can create a higher-order tax calculator that can make this tax work regardless of whether the customer is using the existing tax system, Avatax, TaxJar, or something else entirely.

[seandawes]

This could be handled the same way shipping insurance works on others. A promotion rule to auto add a line item to the cart when shipping address is in Colorado. For example Route which lot of stores auto add to your cart.

The issue or thing to note would be its not a taxable line item since it is considered a tax. If it cannot be refundable that would be ok as on full order cancels it would cancel/refund it as the item(s) never delivered.

For reporting you can report by product id.

Promotions system should allow for auto adds not just discounts in the event of free bundles. Orders over $x get a free shirt etc which most platforms handle.

Currently retailers could do this automatically by auto adding products to carts post checkout and applying the adjustment to make the order have no balance due if the retailer is paying the fee and not the customer. And no work would be needed to the actual codebase but rather just use the API post order completion to make the changes instantly

[jarednorman]

Solutions involving the promotion system will run into the issue that only one promotion gets applied to the order.

[seandawes]

Ahh yea forgot it limits it.

Would just setup a workflow outside of Solidus to add it as a product via the API.

[jarednorman]

Yeah, that's not a bad strategy as a stopgap for some stores where that won't mess things up for their accounting/fulfillment. That'll not play nice with a lot of ERP and WMS connections on many stores though.