[FIX] product_replenishment_cost: correct misleading update wizard message

[les-adhoc]

The "Update Accounting Cost from Replenishment Cost" wizard message stated the action only applied to products with the "Standard Price" costing method:

This will apply to all the selected products across company with costing method "Standard Price" and with Replenishment Cost different from 0.

However, _update_cost_from_replenishment_cost() in product_template.py overwrites standard_price for products of any costing method — it only filters replenishment_cost != 0 and never checks the category costing method. This was reproduced on an AVCO category, where the cost went from 0 to a non-zero value on confirm.

Change

The action itself is intentional (useful e.g. for currency-based valuation), so the behavior is not blocked. Only the wizard message is corrected so it no longer restricts the scope to the "Standard Price" costing method:

This will apply to all the selected products across company with a Replenishment Cost different from 0.

Source terms re-exported (.pot). Translations are handled by the usual Transifex sync.

Test plan

• Open a product list, select products in a category using AVCO (or FIFO) with a Replenishment Cost != 0.
• Run Update Accounting Cost from Replenishment Cost.
• The wizard message no longer claims it only applies to "Standard Price"; confirming still updates the accounting cost as before.

Ref: https://www.adhoc.inc/odoo/action-helpdesk.helpdesk_ticket_action_main/123474

[roboadhoc]

[jcadhoc]

@roboadhoc r+ nobump

[roboadhoc]

@jcadhoc you may want to rebuild or fix this PR as it has failed CI.

[mav-adhoc]

@roboadhoc rebuild

[roboadhoc]

@mav-adhoc unknown command 'rebuild'.

For your own safety I've ignored everything in your entire comment.

Currently available commands:

command
help	displays this help
r(eview)+	approves the PR, if it's a forwardport also approves all non-detached parents
r(eview)=<number>	only approves the specified parents
r(eview)-	removes approval of a previously approved PR, if the PR is staged the staging will be cancelled
retry	re-tries staging a PR in the "error" state
fw=no	does not forward-port this PR
fw=default	forward-ports this PR normally
fw=skipci	does not wait for a forward-port's statuses to succeed before creating the next one
fw=skipmerge	does not wait for the source to be merged before creating forward ports
up to <branch>	only ports this PR forward to the specified branch (included)
merge	integrate the PR with a simple merge commit, using the PR description as message
rebase-merge	rebases the PR on top of the target branch the integrates with a merge commit, using the PR description as message
rebase-ff	rebases the PR on top of the target branch, then fast-forwards
squash	squashes the PR as a single commit on the target branch, using the PR description as message
delegate+	grants approval rights to the PR author
delegate=<...>	grants approval rights on this PR to the specified github users
nice	only stages the PR if there's room in the batch after default PRs
default	stages the PR normally
priority	tries to stage this PR first, then adds default PRs if the staging has room
alone	stages this PR only with other PRs of the same priority
cancel=staging	automatically cancels the current staging when this PR becomes ready
check	fetches or refreshes PR metadata, resets mergebot state
remindme:<branch>=<message>	When the PR gets forward-ported to , ping you with . can be quoted if it needs spaces.

Note: this help text is dynamic and will change with the state of the PR.

[mav-adhoc]

@roboadhoc retry

[roboadhoc]

@mav-adhoc retry makes no sense when the PR is not in error.

[jcadhoc]

@roboadhoc r+ nobump