#DeliveryTiem-cancel-subscription-future

1 messages ยท Page 1 of 1 (latest)

clever raftBOT
wicked scarab
#

Hi ๐Ÿ‘‹ can you share the ID of the Subscription that you used for your testing?

scenic bramble
#

Hi toby, yep it is sub_1MNFzEIUwLvVicLYUEmAIYcB

wicked scarab
#

Thank you, working on pulling that up.

scenic bramble
#

We don't use cancel_at_period_end because we set the cancellation date when we create the subscription

wicked scarab
scenic bramble
#

Yep can help you understand, this test clock subscription has 10 instalments (first is a trial)... realized halfway through advancing time that the cancel date was not set. I set the cancel at date before the final instalment was done.

#

For the sake of sanity I can re-create this scenario with the cancel at set at subscription creation

wicked scarab
#

I actually think the approach used here with Subscription Schedules would be more consistent, you can set the desired number of iterations for a phase and then set the end behavior for the Subscription Schedule to cancel the associated Subscription.

#

DeliveryTiem-cancel-subscription-future

scenic bramble
#

oooooh

#

I haven't looked at this yet but this sound like the right way to go, i'll check it

scenic bramble
#

The concept of schedule subscriptions is good however we have no type of implementation for this and we will have an issue with retrospectively applying this to thousands of active subscriptions. I would like to be able to use the cancel_at for now as it is the least invasive approach. I have made a new subscription using the test clock and this time i made the cancel_at date at subscription creation... yet still getting a different amount at the last instalment

#

Subscription is sub_1MNHnWIUwLvVicLYVNFQecWy

ember star
#

Thank you for the ID, will check in to that and get back to you

scenic bramble
#

Thanks Pompey

median condor
#

Hi there. I'm helping Pompey with this. The cancel at date in this case was set to 4:00 UTC on 11/05, but the billing cycle anchor is set to 15:21:50 UTC. Can you try again, matching the cancel at timestamp to the billing cycle anchor's timestamp?

scenic bramble
#

Hey duchess, I will try that with the billing cycle anchor set. that's fair with the schedule attachment. Regarding the schedule, I'll provide an example case we would need to cover. We have an existing subscription that is set to have 10 instalments, currently they currently at instalment #6's period... that means there are 4 future instalments. I can attach the schedule to it but how do I update the schedule to make it so the subscription cancels when the 4 future instalments are completed. Do I update the phase iterations to 4?

median condor
#

Oh I see. Yeah that's a bit tricky since you'll be partially through an iteration

#

It might be easier to just keep existing ones as is but use subscription schedules for future subscriptions

#

That being said, there's nothing wrong with your current approach of using cancel_at with normal Subscriptions

#

It's just a matter of getting the timestamp right

scenic bramble
#

Yeah it's an interesting case, i'll work on that billing cycle anchor... i'm close to EOB here with no space to work overtime so it may be tomorrow I get to complete this... can this thread be kept live or do you advise making another one

median condor
#

Yeah we archive threads after a bit of inactivity just to keep our list of opened threads maintainable. Just message again in the main channel and we'll open up a new thread for you when you're ready