[19.0][IMP] subscription_oca: compute MRR and ARR

[alvaro-domatix]

Adds MRR/ARR to subscriptions:

• recurring_monthly on each subscription line: price_subtotal normalised to a monthly amount from the template recurrence (30.4375 days/month average for daily/weekly cadences), converted to the company currency so subscriptions in different currencies can be compared and summed.
• recurring_monthly / recurring_yearly on the subscription: sum of the lines, ARR being 12 x MRR.

They are shown as a stat button on the form, optional sum columns on the list view and a "With recurring revenue" search filter.

Supersedes #1443.

[szalatyzuzanna]

I have a question regarding the scope of this feature. Since MRR/ARR are reporting-oriented KPIs rather than core subscription functionality, was a separate extension module considered instead of adding them directly to subscription_oca?

[alvaro-domatix]

Thanks for raising the scope question. I considered a separate extension module, but I kept MRR/ARR in subscription_oca on purpose, for a few reasons:

1. They are fields on the record itself, not a reporting overlay. recurring_monthly/recurring_yearly are computed fields on sale.subscription, exposed directly in the form via stat buttons alongside recurring_total. They are part of the contract's own figures, the same way recurring_total/recurring_next_date already are — both are computed on the model today. Splitting MRR out would mean an extra module for two fields that belong to the same family of native computes.

2. No new dependency is introduced. The rating and SMS features were split into bridge modules precisely because they pull in rating.mixin / the SMS stack. MRR/ARR add none of that — it is a pure Python normalisation of the existing line subtotals (plus a currency conversion). So the usual reason to factor a feature out (to avoid forcing a heavy dependency on the core) does not apply here.

3. Downstream depends on the field. The reporting analysis ([19.0][ADD] subscription_oca: subscription analysis reporting #1471) and the spreadsheet dashboards read recurring_monthly. Moving it to an extension would turn all of those into dependent modules and add an install step for a feature that is just two computed fields.

If anyone feels strongly that the KPI should not be forced on everyone, I can gate the display (stat buttons / list columns) behind a group or a setting rather than splitting the module — but the compute itself stays on the model. Happy to go either way; my recommendation is to keep it as is.