[15.0][FIX] budget_control_purchase_request: account_id resolves wrong company on multi-company PR approval

[Pani-k-folk]

Summary

Fixes purchase.request.line.account_id returning False when the
user's active company differs from the company of the purchase
request, causing budget control to be silently skipped.

Steps to Reproduce

1.Create a Purchase Request (PR) in Company A.
2.Configure the user to have access to both Company A and Company B, with Company B set as the active company.
3.Click Request Approval, then Approve on the PR.
4.During budget validation, the system attempts to retrieve the account_id using the active company (Company B). Since the product does not have an Expense Account configured in Company B, account_id is not found.

As a result, controls is empty, causing the budget check to be skipped and no Budget Control record to be created.

Root Cause

purchase.request.line.account_id is a compute field that calls
product_tmpl_id.get_product_accounts()["expense"]. Internally this
reads property_account_expense_id / property_account_expense_categ_id,
both declared as company_dependent=True (backed by ir.property).

ir.property resolves its value based on the active company of the
env at compute time (self.env.company), not the company the
document belongs to, and not allowed_company_ids in the user's
context. When the user's active company is B but the PR belongs to
company A, the system looks up the property value set for B instead
of A. If no property value exists for B, it resolves to False — even
though company A has the correct property configured.

Other hypotheses were ruled out during investigation:

• Not an ir.rule issue (reproduced even with sudo() and with the rule
  disabled).
• Not a missing/lost allowed_company_ids in context (verified both A
  and B were present).
• Not missing data on purchase_request_budget_move, since that model
  is a SQL view regenerated on every read, not a table with persisted
  records.

Fix

Force the company context to the document's own company
(request_id.company_id) before calling get_product_accounts(), using
with_company():

```python
def _get_pr_line_account(self):
company = self.request_id.company_id
account = self.product_id.product_tmpl_id.with_company(
company
).get_product_accounts()["expense"]
return account
```

with_company() forces ir.property to resolve against the document's
company rather than the user's active company, so account_id is
correct regardless of which company the user currently has active.

Note

Other places computing company_dependent fields the same way (e.g.
property_account_income_id, or other compute fields relying on
get_product_accounts()) should be reviewed for the same risk in
multi-company workflows.

[Saran440]

Hi @kittiu,
some modules you are maintaining are being modified, check this out!

[Saran440]

/ocabot merge patch

[Saran440]

This PR looks fantastic, let's merge it!
Prepared branch 15.0-ocabot-merge-pr-578-by-Saran440-bump-patch, awaiting test results.

[Saran440]

@Saran440 your merge command was aborted due to failed check(s), which you can inspect on this commit of 15.0-ocabot-merge-pr-578-by-Saran440-bump-patch.

After fixing the problem, you can re-issue a merge command. Please refrain from merging manually as it will most probably make the target branch red.

[Saran440]

/ocabot merge patch

[Saran440]

This PR looks fantastic, let's merge it!
Prepared branch 15.0-ocabot-merge-pr-578-by-Saran440-bump-patch, awaiting test results.

[Saran440]

@Saran440 your merge command was aborted due to failed check(s), which you can inspect on this commit of 15.0-ocabot-merge-pr-578-by-Saran440-bump-patch.

After fixing the problem, you can re-issue a merge command. Please refrain from merging manually as it will most probably make the target branch red.

[Saran440]

/ocabot merge patch

[Saran440]

This PR looks fantastic, let's merge it!
Prepared branch 15.0-ocabot-merge-pr-578-by-Saran440-bump-patch, awaiting test results.

[Saran440]

@Saran440 your merge command was aborted due to failed check(s), which you can inspect on this commit of 15.0-ocabot-merge-pr-578-by-Saran440-bump-patch.

After fixing the problem, you can re-issue a merge command. Please refrain from merging manually as it will most probably make the target branch red.