#dan-tax

1 messages · Page 1 of 1 (latest)

worldly umbra
#

hi! yes, you need to create the invoice items with a Price and not just with ad-hoc amounts since the Price contains the information needed for us to know the correct tax treatment to apply

radiant python
#

I wondered if there would be a way around that given the functionality in the stripe dashboard allows adhoc prices like this with a tax behaviour set.

unknown.png
worldly umbra
#

you could try that and see what API request it makes (in the dashboard request logs)

radiant python
#

Good shout, I'll take a look

worldly umbra
#

i.e. you can use price_data to create a new Price object inline if you don't already have one to pass to price

radiant python
#

POST /v1/invoiceitems

{
  "description": "Something",
  "unit_amount_decimal": "500",
  "currency": "gbp",
  "quantity": "1",
  "tax_behavior": "exclusive",
  "expand": [
    "price",
    "price.product",
    "tax_amounts.tax_rate"
  ],
  "include": [
    "tax_amounts"
  ],
  "customer": "cus_L4oQPVALNQ5aia",
  "invoice": "in_1KUAHPIQcApdkoI6sZ3XVWcX"
}
#

that looks like it exists but is undocumented ?

worldly umbra
#

yeah the dashboard has access to things that aren't all in the public API

#

yeah tax_behavior on that endpoint is dashboard-only. You have to pass a Price or use price_data to create one.

#

sorry but this is mostly intentional, we want you to create your product catalogue on Stripe so the reporting and interoperability with other existing and future Stripe products/APIs is more rich, so with Tax we soft-push the use of Prices.

radiant python
#

Ok, and I can see it's flat out disallowed to anything other than the dashboard too, even if I was to provide it Stripe.StripeException: Received unknown parameter: tax_behavior

While what you say makes perfect sense, it's a little frustrating to see the functionality is all there, just blocked from being usable, as this now creates a much larger headache of hooking in one of our other systems that already calculates these prices historically

worldly umbra
#

yep this is something we are debating a lot internally right now, I completely understand

#

as of right now at the time Tax was designed and built initially we were pushing for that direction, but there's a lot of debate over the future direction

radiant python
#

we'd also need to manage some of our volumetric pricing in two places going forward

#

ok, and I assume we're talking a longer timescale than a shorter one?

worldly umbra
#

yes, nothing is planned in the short term

radiant python
#

Hopefully the above provides an argument for this to be exposed as users might expect. But for now we'll need to re-review how we want to approach this aspect of our billing of our existing volume charges.

Much appreciate the fast and detailed response as always.

radiant python
#

After reviewing the price_data part that you highlighted, this looks like a perfectly viable alternative for us to use for the moment, I was a little worried it would be creating hundreds of prices in our dashboard, but it seems to instantly archive it. Would there be any concerns with archived price build up over time ?

slate spindle
#

Hey there 👋 karllekko needed to step away so I'm jumping in. No, accumulating archived prices shouldn't be a problem.

radiant python
#

Perfect, thanks, that should mean this isn't an issue as I first thought. Much appreciated guys.

slate spindle
#

Great to hear! Always happy to help 😄