pedrobaeza
commented
6 months ago It can't be invoiced on the last day of the previous period, because that day hasn't lasted yet, and thus, there can be concepts to be invoiced that are not invoiced. Think that thanks to modules like contract_variable_qty or contract_sale_invoicing, the idea is to gather, once the period has lasted, all the applicable concepts. You can't do this while the period is still there. For your use case, you want to be invoiced the last day of the period, but that goes against what post-period was created for.
flalexg
Is your feature request related to a problem? Hello! I've been investigating a little the code and I think there's an error in the concept of the pre-paid and post-paid terms, specific in the post-paid term.(or maybe I'm who is wrong :P). I'm going to expose the case:
For me this isn't correct. Explaining in period terms, the periods for this contract are:
Establishing a post-period 'Invoicing Type' means that we generate the contract at the end of the current period (no at the begging of the next one).
If we look on the pre-period 'Invoicing Type', it computes correctly the Date of Next Invoice, setting it at 1st of January in the first period and 8th of January on the second period.
Describe the solution you'd like It's for this that I'm proposing to delete the field 'recurring_invoicing_offset', which is the cause of the error because it established an offset of 1 when it's a post-paid contract. In the new versions it's all controlled with the fields of 'recurring_next_date' and 'last_date_invoiced'.
This change would have a big impact not only for the people who are using this, but for us because we would have to refactor all the test.
I didn't go ahead with the change because maybe I'm the one who is wrong.