Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[16.0] Problem with post-period contracts #1063

Closed
flalexg opened this issue Mar 20, 2024 · 2 comments
Closed

[16.0] Problem with post-period contracts #1063

flalexg opened this issue Mar 20, 2024 · 2 comments

Comments

@flalexg
Copy link

flalexg commented Mar 20, 2024

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:

  1. I create a Post-Paid contract at 1st January (Monday), with a recurrence of every week. I expect the 'Date of Next Invoice' to be set a 7h January (Sun). But is set on 8th January (Monday).
    Recurrence-Week

For me this isn't correct. Explaining in period terms, the periods for this contract are:

  • First period: From 1st Jan to 7th Jan
  • Second period: From 8th Jan to 14th Jan
  • Third period: From 15th Jan to 21st Jan.

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.

Recurrence-Pre-Paid-Week-0
Recurrence-Pre-Paid-Week-1

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.

@pedrobaeza
Copy link
Member

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
Copy link
Author

flalexg commented Mar 21, 2024

That makes sense. Thank you for the response @pedrobaeza. :)

@flalexg flalexg closed this as completed May 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants