[18.0][ADD][WIP] project_revenue_recognition

[Saran440]

Concept:
Auto-create Journal Entries to adjust revenue based on the difference between Project Progress and Posted Invoices.

TODO:

• Test Script
• Readme

[alexey-pelykh]

WIP / Draft PR -- Preliminary Observations

This PR is marked as WIP / Draft with open TODO items (test script, readme), so this is not a full review. Sharing preliminary observations to help guide the remaining work.

---

Correctness & Logic

1. _get_amount_sale_invoice filters only non-closed tasks (is_closed = False), meaning completed tasks are excluded from the sale order item fetch. This seems inverted for revenue recognition -- you likely want to include all tasks (or specifically closed ones) to compute total project value and progress. Please verify the intent.

2. _compute_amount_diff only handles invoice_project comparison but has no else branch -- if compare_with is falsy or a future selection value, amount_diff is never set (it will keep its previous stored value or default). Consider adding a fallback rec.amount_diff = 0.0.

3. action_adjust_cost uses self.auto_post on the recordset level, but this is iterating self via _create_moves. If multiple records are processed, self.auto_post will raise a singleton error. Should be handled per-record.

4. action_reverse_cost returns action_reverse() result from the wizard (a dict), but then the caller flow expects to also call self.action_reverse() to set state to reverse. The current flow opens the reversal wizard but never sets the recognition state to reverse until the wizard completes via account_move_reversal.py. This coupling is fragile -- if the user cancels the wizard, the state never transitions.

5. _get_account_mapping silently returns (False, False) when amount_diff == 0 because the else branch handles negative-or-zero. When diff is exactly zero, journal entries with zero amounts will be created. Consider skipping JE creation when diff is zero.

6. project_project.py inherits project.project but adds no fields or methods. This is a no-op file and should either be removed or populated with the intended functionality.

Security

7. .sudo() usage in _get_amount_sale_invoice -- the sudo() call on fetched sale order items bypasses access control. This is common in Odoo for cross-model aggregation, but the scope should be documented (comment explaining why sudo is needed).

8. Record rules look correct -- multi-company rules on both models are properly defined with global scope.

Odoo Best Practices

9. Missing tracking=True on the state field -- since the model inherits mail.thread, state changes should be tracked in the chatter.

10. web_widget_x2many_2d_matrix dependency is declared in __manifest__.py but never used in any view. This dependency should be removed unless there are planned views that use it.

11. No _check_company constraints -- journal_id and the account fields on res.company have no company consistency checks. Consider adding check_company=True on relational fields that should respect multi-company boundaries.

12. Wizard reverse_moves assumes singleton on project_revenue (project_revenue.id, project_revenue.action_reverse()) but mapped() can return multiple records. Add ensure_one() or handle multi-record case.

Missing Pieces (per TODO)

13. No tests -- the PR description confirms this is pending.
14. readme/USAGE.md is empty -- the README Usage section renders blank.
15. No ROADMAP.md or HISTORY.rst for planned improvements.

Manifest

16. "development_status" key is missing from __manifest__.py. The README badge says Beta, but the manifest should declare "development_status": "Beta" (or "Alpha" given WIP state).

Minor / Style

17. The method action_adjust_cost and button label say "Cost" but this module is about "Revenue" recognition. Consider aligning terminology.
18. readme/DESCRIPTION.md is missing a trailing newline.

---

Happy to do a full review once the PR is out of draft with tests and documentation in place. Keep up the good work!

Review posted via CorporateHub OCA review campaign