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

Q: How to use contract modules for managing subscriptions? #977

Closed
Rad0van opened this issue Jul 24, 2023 · 3 comments
Closed

Q: How to use contract modules for managing subscriptions? #977

Rad0van opened this issue Jul 24, 2023 · 3 comments
Labels
enhancement stale PR/Issue without recent activity, it'll be soon closed automatically.

Comments

@Rad0van
Copy link
Contributor

Rad0van commented Jul 24, 2023

Sorry for doing it this way but I am trying to port product_contract to 16.0 (see #959 ) but found it behaves differently than 14.0 so got stuck there for hours now trying to figure out my scenario...

Any help would be appreciated solving the following: I would like to sell some sort of subscription service on yearly (or monthly - doesn't matter much) basis where customer upon initial purchase and payment gets the contract activated for a that perios (which can then be checked from module providing the actual service). So it would be something like sale.order with product marked as is_contract=True and type pre-paid to ensure automatic contract.contract and contract.line creation. When the end of current period is nearing, new contract.line would be created as successor to the previous one and invoice or sale order gets created (that works it seems).

What I am struggling with is this: it seems that state of the contract.line does not at all depend at state of the linked account.move. I mean I'd want the contract to be "active" after the payment for the first period has been made. If the period ends without the next invoice (or even better sale.order) being paid, the contract should "expire".

Would anyone kindly share some insights on this? Am I missing something very obvious here? Or am I trying to bend the module into something it has never been intended to be used like? Any help, suggestions is greatly appreciated.

@pedrobaeza @sbejaoui @ibuioli @rousseldenis @victoralmau @ygol

@rousseldenis
Copy link
Contributor

@Rad0van

What I am struggling with is this: it seems that state of the contract.line does not at all depend at state of the linked account.move. I mean I'd want the contract to be "active" after the payment for the first period has been made. If the period ends without the next invoice (or even better sale.order) being paid, the contract should "expire".

In fact, the contract (or lines) state (there is no state field) don't depend on payment status. We just manage for time being the dates (so, the period of time) the line or the contract is active.

During the active period of time and depending on the recurring type (daily, weekly, ...), invoices (or sales) are generated and live their life independently from the contract.

The common use case is having a contract confirmed and should always go to the end date (and has no dependency on the invoices payment status - as this is a purely accounting flow).

The contract (or lines) stops or pauses are currently supported. This operation is manual.

I mean I'd want the contract to be "active" after the payment for the first period has been made

I don't understand the use case as if the contract is not active, the first invoice is not generated... and cannot be paid.

Using product_contract flow could support your use case if you call https://github.com/OCA/contract/blob/14.0/product_contract/models/sale_order.py#L82 on sale order payment. So, said differently, I would generate the contract only if the sale order (which is the entry point) is paid (for time being this is manual action).

@Rad0van
Copy link
Contributor Author

Rad0van commented Jul 25, 2023

@rousseldenis thank you for quick answer. Let me try to describe the use-case better. The ideal way for this to work for me would be this:

  1. The customer goes to e-shop and buys a yearly subscription product - creates Sale Order.
  2. When the customer pays the Sale Order, Invoice is created (for the first year) and sent to the customer.
  3. Also when the first payment is made, Contract is created and is somehow marked as "active" - i.e. customer can use the service (I'll send them a token associated with the Contract that will be used when requesting the service)
  4. When the first year is nearing to an end, new Sale Order is created and sent to customer to renew the subscription. I'd prefer Sale Order because issuing Invoice has got various tax implications here. Also Customer may simply decide not to continue subscribing and it is a hassle to withdraw/cancel the Invoice once sent.
  5. If the customer pays before the first year is over, the Contract remains "active" - i.e. customer can use the for another year
  6. If the customer doesn't pay before the end of first year, the Contract should become "inactive" - i.e. the requests for service will be denied. When he pays afterwards, the Contract get re-activated.

I'm talking about "active/inactive" Contract (or Contract Line - doesn't really matter) because I want to have a way when Customer invokes a service request (very similar to IAP - it just doesn't consume tokens) to have a way to check whether the Customer is eligible for his request to be handled. I believe that the flow I described is how Contract module works it's just missing that easily accessible "active/inactive" flag.

Now that I have described this I am thinking of adding something like "Payment State" which could be used for that purpose. Any ideas/suggestions?

Copy link

There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.

@github-actions github-actions bot added the stale PR/Issue without recent activity, it'll be soon closed automatically. label Jan 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement stale PR/Issue without recent activity, it'll be soon closed automatically.
Projects
None yet
Development

No branches or pull requests

2 participants