#lolito-subscription-tax-rates

1 messages · Page 1 of 1 (latest)

hearty flume
#

Hello 👋
Give me a moment to catch up here and I'll respond as soon as I can 🙂 Thanks

#

do you have an example subscription ID that I can take a look at?

maiden fern
#

Hey 👋

#

Sure just a sec

#

sub_1Jt7VKKY8Kb7LHIr5coe4NRP

#

The issue started with that subscription, apparently the account owner enabled Stripe Taxes. When trying to add a discount coupon to that subscription it returned this error: One or more prices has a tax_behavior that conflicts with the tax rates that apply to the corresponding line item.

hearty flume
#

can you check if disabling the toggle at the bottom changes anything?

maiden fern
#

Thanks

#

I was checking the subscription attributes and it has "automatic_tax": {
"enabled": false
}

#

The flag says that you still need to set that to true

#

and we are not setting it

hearty flume
#

Sorry got pulled away on another thread.
Are you seeing automatic_tax on a newly created subscription or existing ones?

maiden fern
#

They don't have it

#

That flag is set to false

#

What I'm trying to determine is how is the default_tax_rates array on the subscription being populated

humble brook
#

👋 stepping in here as hanzo has to step away.

maiden fern
#

cause that default tax rate is conflicting with the subscription one

humble brook
#

Taking a look

maiden fern
#

Hey 👋

humble brook
#

Interesting... looks like your price doesn't have a tax behavior at all.

#

And the API doesn't like that

#

There is a tax rate set on the Sub... however it is for 0%

#

Looking more

#

Give me a moment

#

Alright in my opinion this is a bug. I'm conferring with a colleague.

maiden fern
#

Ok, thanks for investigating

#

So here's a summary of the scenario:

  • We set the subscription tax via the tax_percent attribute
  • Customer enabled Stripe Tax in their Dashboard
  • When we try to apply a coupon to that subscription we get the error: One or more prices has a tax_behavior that conflicts with the tax rates that apply to the corresponding line item.
  • I reproduced this locally and was able to fix it by removing the subscriptions's default_tax_rates
humble brook
#

Ah that last bit is helpful, thanks.

#

And did this not happen when the Connected Account didn't have Stripe Tax enabled in their DB?

#

It shouldn't really matter since it isn't enabled for the Sub

#

But curious

#

Also, why are you setting a 0% tax_percent to begin with?

#

Why not just omit that?

maiden fern
#

Honestly I'm not sure if that happened before that or not

humble brook
#

Yeah no worries... enabling that shouldn't really change anything.

maiden fern
#

We are not setting it to 0, in those cases we pass null to the stripe-ruby sdk

#

I'd have to check the Dashboard's logs to confirm that

humble brook
maiden fern
#

Oh interesting

#

I went to the .created event

#

it said null but didn't see this one

#

I'll double check

humble brook
#

Okay so there are a few things here. First, I'll file a ticket internally because I don't think we should stop the coupon update here -- I do think we have stricter validation than we should.

That said, I'd recommend moving to using TaxRates as opposed to tax_percent and not setting a TaxRate or % if 0. I'd also recommend starting to set the desired tax behavior on your Prices so that you don't run into issues like this in the future. Lastly, for now, unsetting the tax rate does seem like the best workaround while we fix up our validation logic here.

maiden fern
#

Sounds great Bismark

#

Im seeing some recent changes in the code where that 0 might be slipping through

#

We definetly need to migrate to prices and tax rates for sure

#

I'll make a stronger case for the product owner 🙂

humble brook
#

Sounds good 🙂

maiden fern
#

Thanks a lot!