fix(subscription): add cancellation and date validation

[Jatin3128]

Prevents subscription periods from extending past the end date and handles cancellation correctly at period end.

[coderabbitai]

📝 Walkthrough

Walkthrough

This change modifies the Subscription.process method to enforce end-date boundaries during invoice generation. After creating a new invoice, the code now checks whether the next billing start date would exceed a configured end-date. If so, the subscription is either cancelled (when cancel_at_period_end is true) or its status is updated via set_subscription_status. The method then saves and returns early, skipping the update_subscription_period call for that cycle. Existing post-check logic for end-date scenarios remains in place.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Single file modification but introduces a new control flow path that may interact with existing logic
• Requires understanding of subscription lifecycle and when period progression normally occurs
• Need to verify the early-exit path doesn't bypass critical state updates for other scenarios
• Potential interaction between cancel_at_period_end flag and set_subscription_status behavior requires scrutiny
• Edge cases around end-date boundary conditions (exact date matches, timezone handling) warrant testing consideration

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: adding cancellation logic and date validation to prevent subscription periods from extending past the end date.
Description check	✅ Passed	The description directly relates to the changeset, explaining how the fix prevents subscription periods from extending past the end date and handles cancellation at period end.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: Path: .coderabbit.yml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 260e6fb and 00c9e20.

📒 Files selected for processing (1)

• erpnext/accounts/doctype/subscription/subscription.py (1 hunks)

🧰 Additional context used

🧠 Learnings (1)

📚 Learning: 2025-12-16T05:33:58.723Z

Learnt from: Abdeali099
Repo: frappe/erpnext PR: 51078
File: erpnext/accounts/doctype/financial_report_template/financial_report_engine.py:486-491
Timestamp: 2025-12-16T05:33:58.723Z
Learning: In ERPNext/Frappe codebase, query.run(as_dict=True) returns frappe._dict objects that support both dict-style access (obj["key"]) and attribute-style access (obj.key). Therefore, attribute access on query results is valid and will not raise AttributeError. When reviewing Python code, prefer attribute access (obj.key) for readability where the key is known to exist, but ensure existence checks or fallback handling if there is any doubt about missing keys.

Applied to files:

• erpnext/accounts/doctype/subscription/subscription.py

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: triage
• GitHub Check: Summary

🔇 Additional comments (1)

erpnext/accounts/doctype/subscription/subscription.py (1)

564-574: No action needed. The cancellation logic is correct and complete.

The early return at line 574 does not create gaps in the cancellation logic. The new code (lines 564-574) and existing code (lines 579-583) handle complementary scenarios:

• New code (lines 564-574): Runs immediately after invoice generation. It proactively checks if the next billing period start would exceed end_date. When this condition is met, it cancels the subscription and returns, preventing further processing.

• Existing code (lines 579-583): Only reaches this point if the early return didn't trigger (meaning next_start <= end_date). It then checks if posting_date >= current_invoice_end or posting_date >= end_date to handle other cancellation scenarios.

These conditions are distinct and serve different purposes. There are no edge cases where cancellation should occur but neither path triggers. The logic flow ensures that once cancelation_date is set, can_generate_new_invoice() will return False, preventing further invoice generation.

[codecov]

Codecov Report

❌ Patch coverage is 12.50000% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 79.01%. Comparing base (8b1fd74) to head (00c9e20).
⚠️ Report is 15 commits behind head on develop.

Files with missing lines	Patch %	Lines
...next/accounts/doctype/subscription/subscription.py	12.50%	7 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##           develop   #51199   +/-   ##
========================================
  Coverage    79.01%   79.01%           
========================================
  Files         1175     1175           
  Lines       120213   120246   +33     
========================================
+ Hits         94981    95008   +27     
- Misses       25232    25238    +6     

Files with missing lines	Coverage Δ
...next/accounts/doctype/subscription/subscription.py	82.26% <12.50%> (-1.67%)	⬇️

... and 9 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.