[12.0][IMP] - Contract: Add a new field to compute the next period end date

[sbejaoui]

An alternative solution for #428 is to make the invoicing period independent from the invoice date. Original idea of @pedrobaeza (see)

This PR add a new filed to store the next period end date. With the field last_date_invoiced the user can easily see and change the invoicing period.

A migration script was added to initialize the new field.

What we can add to this PR:

• add an integer field offset to shift the invoice date
• make the next invoice date a computed field based on
  • invoicing_type: pre-paid/post-paid
  • first and last period dates
  • offset field
• make the monthlylastday a check box to be used to compute the next invoice date

CC/ @pedrobaeza , @sbidoul , @gva-acsone, @carlosdauden

[sbidoul]

I think you can continue simplifying by doing _update_next_period_date instead of _update_recurring_next_date and make recurring_next_date a computed field that depends on next_period_date and recurring_invoicing_type.

[sbidoul]

I'd suggest adding a next_period_start_date too (computed = last_date_invoiced + 1). That will simplify the code a bit. And you can display to the user instead of last_date_invoiced, it will improve the UX.

[sbidoul]

When you have done _update_next_period this _get_period_to_invoice can become very dumb: return next_period_start_date, next_period_end_date

[sbidoul]

So yes 👍 , this PR will be a refactoring of the logic by computing the next period instead of the next invoice date, and making the next invoice date depending on the next period. It will become much easier to reason about the code when this is done, and the UX should be better too by clearly showing what will be the next period to invoice and the invoice date (instead of leaving it to some interpretation of the user as it is now).

And it will pave the way for new features such as:

• end first period at the end of the month in prepaid mode too (similar to monthlylastday which is post-paid now)
• add an offset for the invoice date based on the period to allow, e.g. invoicing a few days before the end of the period
• always invoice at the end of the month even if the period overlaps a month boundary
• etc...

[sbidoul]

As discussed, in a first step, let's make recurring_next_date computed, but with an inverse method for backward compatibility (the inverse method logging a deprecation warning).

[pedrobaeza]

Is this outdated with #434?

[sbidoul]

Is this outdated with #434?

Probably yes. My idea here to make recurring_next_date computed from the next period is raising some backward compatibility issue. I still think it would be easier for the user but there are some edge cases that are not reproducible with this approach.

In any case #434 improves maintainability and readability (IMO), and is fully compatible (except two minor differences that you can see in the test changes in #434).

[sbidoul]

Closing in favor of #434