#supreeth-subschedule-invoiceperiod

1 messages · Page 1 of 1 (latest)

still deltaBOT
#

Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

tight wolf
formal sorrel
#

Here you go: req_tHaK9nOmyxDYnd

#

I think I deleted the subscription after that, if that matters

tight wolf
#

Okay so you are passing in a new start and end date for the first phase of the schedule? 2/9 - 3/1

formal sorrel
#

yeah, but the start date is same as existing

#

I am trying to modify the end date to March 1

tight wolf
#

I'm confused, the current_phase property in the response to your API request shows an end_date value of 1709280000 or 3/1

formal sorrel
#

yeah that should be correct

#

right ?

#

I want the current billing from 2/9 - 3/1 and then next from 3/1 to 4/1 and so on

#

but the invoice for 2/9 - 3/1 doesnt have correct period_start and period_end in root of invoice, but its correct for invoice line item

tight wolf
#

What is the related invoice? I'm not seeing that.

still deltaBOT
#

supreeth-subschedule-invoiceperiod

formal sorrel
#

I might have to recreate it, maybe because I deleted the subscription

#

give me a few minutes, let me recreate

#

req_rukalukgG74mdy this is the new req ID

#

in_1Ohzt3E0InFu2MN0ANL3OqrA this is the new invoice ID

tight wolf
#

3/1 -4/1 is the interval shown in the invoice item

formal sorrel
#

yeah correct, that is for the coming period

#

but the invoice's billing period is supposed to be 2/9 - 3/1 right ?

still deltaBOT
formal sorrel
#

we cant rely on invoice item's period as well, as shows the next cycle's period

tight wolf
#

That's the latest invoice, which was created when the test clock was advanced

#

Previous to that I see 3 invoices with billing periods for 2/9 - 3/9 all with $0 amounts

formal sorrel
#

yeah correct, this is the latest invoice

#

what we do is, when the invoice is created in draft, we then populate the invoice with line items based on the customer's usage, for this we rely on period_start and period_end of the invoice.

#

it works fine in normal cases, but with subscription schedule the period_start and period_end is getting set wrong

#

let me know if you need any more info from my side.

tight wolf
#

I'm seeing a subscription that is created on 2/9 with a montly recurring price so naturaly the billing cycle starts with 2/9 - 3/9. It looks like you are doing this through the dashboard so what you would want to do is set the Bill starting field to 3/1 and include the proration parameter. That will generate one invoice for 2/9 - 3/1 with a prorated charge

#

The monthly bill will then continue on the 1st of each month

formal sorrel
#

how do we handle this for existing subscriptions ?

#

and generally the subscriptions are created from our backend service

hidden yew
#

👋 hopping in here since snufkin had to head out

#

Just to make sure I understand - your issue is specifically with in_1Ohzt3E0InFu2MN0ANL3OqrA and you expecting a different period on the invoice items, right? You were expecting the period to be 2/9-3/1 but it's 3/1-4/1?

formal sorrel
#

my issue isnt specifically with in_1Ohzt3E0InFu2MN0ANL3OqrA

#

but in general on how to move an existing subscription to beginning of the month billing cycle

#

and yeah, suggestion from stripe was to use subscription schedules for that

#

while trying so, I noticed that the invoice period is not set correctly.

#

in case of in_1Ohzt3E0InFu2MN0ANL3OqrA, it should have been 2/9-3/1, but the period is set as 3/1 -3/1

hidden yew
#

Yeah I see what you mean - let me check on some things

formal sorrel
#

sure

hidden yew
#

I'm checking on this with some other folks as well (Invoice period can be a bit tricky, so just want to be sure we're telling you the right thing)

formal sorrel
#

ok sure

#

thanks!

unborn sundial
#

@formal sorrel okay a few of us paired on this, and we think it's expected with the billing cycle anchor reset that it just has the "current time" as period start/end.
Definitely not what a few of us expected but we had never really tested that edge-case

formal sorrel
#

I didnt understand, is this expected ?

#

If so, Is there any way to achieve what I want to ? To change the billing cycle and have correct period in the invoices

unborn sundial
#

@formal sorrel we think it is expected. And that it's impossible to have the period you want in that case

formal sorrel
#

Is there any workaround ?

#

so how do we migrate existing subscriptions ?

tight wolf
#

@formal sorrel my colleagues exhasted all efforts to attempt to generate an invoice with the period you wanted. We were unsuccessful.

formal sorrel
#

ohhh, Is that a bug in the system ? Because the invoice period is supposed to be correct right ?

tight wolf
#

No, as my colleague explained that is expected behavior. It is the intended outcome and not something that will be changed.

formal sorrel
#

coming back to the initial question, what can I do from my side to handle this migration ?

tight wolf
#

You cannot achieve the outcome you want. That is what my colleague has already explained. In light of this you should consider testing out other options to see if they fit your use case

formal sorrel
#

is it possible for you to suggest me other options ?

#

thanks in advance for looking into this, I really appreciate it.

tight wolf
#

is it possible for you to suggest me other options ?
Not really, that would be up to you and how you want to modify your customer subscriptions going forward.

unborn sundial
#

👋

#

@formal sorrel unfortunately there won't be a way to do this or workaround it

formal sorrel
#

Got it, thanks for looking to.
does this mean our current design of us relying on period_start and period_end to bill usages in not a recommended way ?

unborn sundial
#

I don't fully understand what that could mean

formal sorrel
#

we bill customers for their usage at the end of the month, monthly based on their usages. To achieve this, we rely on invoice.created webhook call during draft phase, and add all the invoice items, and after an hour it gets finalized.

#

to fetch the usage records, we use period_start and period_end of the invoice.

unborn sundial
#

Gotcha, so yeah I would say that's incorrect. If I was building this I'd have "usage records" marked as pending (what hasn't been invoiced yet) and add that instead (and then mark them as billed). I wouldn't rely on the Invoice period.

#

Also important to know that when you call the Update Subscription API and pass billing_cycle_anchor: 'now' it immediately finalizes that Invoice, you can't just add things to it after (it's different with the SubscriptionSchedule API)

formal sorrel
#

how to have items as pending ?

unborn sundial
#

I don't know what that means again sorry.

formal sorrel
#

I mean usage records

#

how to have them as pending

unborn sundial
#

that's impossible. Sorry the way you explained your use-case, I assumed it meant you tracked usage in your own database, is that not the case?

formal sorrel
#

yeah thats correct, we track the usage is our database

#

we want to add them onto invoice

unborn sundial
#

yeah so that's all I meant. Don't rely on the "period" since it's not really relevant. You, as the developer tracking usage, should know what has and hasn't been billed/invoiced yet.

formal sorrel
#

oh got it

#

but its ok to add to the invoice as an item during draft phase right ?

#

Or do you recommend some other way ?

unborn sundial
#

it's fine to do during draft if the Invoice is in draft. I was explaining there are cases where it wouldn't be.

formal sorrel
#

ohh, how do we add to the invoice in those cases ?

unborn sundial
#

You would add it before updating the Subscription

formal sorrel
#

the problem with metered billing is, there is a limit of 50 per invoice and we have different prices for each product

#

its a spot instances market and the price is never constant.

#

metered billing needs a price ID to report right ?

unborn sundial
#

correct

formal sorrel
#

yeah thats the reason we couldnt use metered billing from stripe

#

and had to resort to using our own database

unborn sundial
#

yep that's fair so in that case you approach should work. And in cases where the Invoice gets finalized immediately you would add the pending InvoiceItem first and then make the call to the Update Subscription API

formal sorrel
#

I thought we were supposed to use Update Subscription Schedule API

#

Update Subscription API and pass billing_cycle_anchor: 'now' should be run exactly at the end of the month to resync the billing cycle anchor ?

unborn sundial
#

that's one way yes, or using the SubscriptionSchedule API that you were already doing right?

formal sorrel
#

yeah,

#

so you are suggesting to just not rely on period from invoice at all?

#

whenever an usage record is pushed, mark it as recorded in our database ?

#

with SubscriptionSchedule API the invoice doesnt get finalized immediately right ?

unborn sundial
#

correct (to both questions)

formal sorrel
#

ok thanks

unborn sundial
#

@formal sorrel anything else before I close?

formal sorrel
#

that should be it