Interval calculation about cashier-mollie

[sandervanhooft]

Thanks @robindirksen1

Some good bits in here, we can work in a swappable action class (optionally override this per subscription plan) once the v1 has released.

[robindirksen1]

cc @driesvints @bobbybouwmann as discussed at LaraconEU

[bobbybouwmann]

@robindirksen1 I was going over this and I thought it makes sense that this is broken because februari can have only 28 days. It doesn't make sense that the other months don't work and that the calculations for the other months are broken, but that's a whole other story.

What happens when you always put it on the 28th when it's 29th, 30th or 31st? This should fix in general you problem and makes sense when accounting februari as well!

[robindirksen1]

What happens when you always put it on the 28th when it's 29th, 30th or 31st? This should fix in general you problem and makes sense when accounting februari as well!

Yes that would work, but then nobody can have a subscription that runs from the last days (29,30,31) in a month. When you subscribe to something, let's says Laravel Forge, your subscription runs from the day you started and not a few days before or after that.

[robindirksen1]

Another proposal I've:

Add a method that returns a collection Carbon instances so you can debug/show information about when the next billing day(s) for that specific subscription are.

[mmachatschek]

I was looking into this a little more. Currently I don't see a good solution here because the new billing cycle is calculated with ->modify() (as stated above) which basically can have any string that can be handled by the DateTime::class e.g. ->modify('+2 day first sunday''). This is a bad example but could be set as interval on integrations.

My suggestion would be to allow a more specific interval but also allow the old version e.g.

// 'interval'=> '1 month' //still valid
'interval' => [
    'value' => 1,
    'period' => 'month', //day, month, year
   // 'fixed' => true,
],

This way we could call the corresponding ->addPeriodWithoutOverflow() method, and let Carbon handle the correct interval Date. So the next cycle would not result in a completely different month.

With the fixed entry you can force the next billing cycle to be on the same day or the correspondig last day in the next month.

I made a draft PR for this #194
What do you guys think?