The aim of this commit is to make the cogs generation multi-company
safe.
2 bugs are fixed in this forwardport commit:
- The product.valuation on the line wasn't evaluated in a company safe
way.
- cogs method weren't company safe either
Before this commit:
- When posting an invoice from company B with both company A and B
selected and A being selected as "main", the cost from company A could
be selected instead of cost from company A to create the anglosaxon
lines.
- If company B's product isn't in real time valuation, cogs aren't even
created.
After this commit:
Whatever the selected companies are, the cost selected will always be from
the company that created the invoice.
closes odoo/odoo#81492
Task: #2686104 and #2713607
X-original-commit: e34caf0ec33a3001bb6343e02d34a6edb5a9f609
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Brice Bartoletti <bib@odoo.com>
When using AVCO and subcontracting without any additional cost, the
valuation of the finished product is incorrect
To reproduce the issue:
1. Create a Product Category PC:
- Costing Method: AVCO
2. Create two products P_compo and P_finished:
- Both:
- Type: Storable
- Category: PC
- P_compo:
- Cost: 10
- Routes: Resupply Subcontractor
3. Update P_compo's quantity: 2
4. Create a Bill of Materials BO:
- Product: P_finished
- Type: Subcontracting
- Subcontractor: a partner P
- Component: 1 x P_compo
5. In Inventory, create a planned Receipt R:
- From: P
- Operations: 1 x P_finished
6. Mark R as To Do
7. Process the delivery of P_compo
8. Validate R
9. Repeat steps 5-8
10. Open the Inventory Valuation
Error: There are two valuation lines for P_finished: one line has a
value of $10, which is correct (this is the cost of the component).
However, the value of the second line is $20, it should be $10 too.
Here are a part of the values used to generate the related MO:
https://github.com/odoo/odoo/blob/2d12fb8fb94c0f2acade7222cfedbec34114a8e9/addons/mrp_subcontracting_account/models/stock_picking.py#L21-L25
In the above case, an extra cost is defined on the MO and is based on
the unit price of the subcontracted SM. However, `_get_price_unit` will
return an incorrect value:
https://github.com/odoo/odoo/blob/251be6b943ea8c3f274bb0863d0af3f7c6b8d10d/addons/stock_account/models/stock_move.py#L39
After step 8, the standard price of P_finished is $10. Also, in the
above case, there isn't any subcontracting cost, so there isn't any unit
price defined on the SM. Therefore, `_get_price_unit` returns the
standard price of P_finished ($10). As a result, when computing the
value of the finished stock move:
https://github.com/odoo/odoo/blob/4fc2ec31861d4602357f130066ec3507b96d8dc8/addons/mrp_account/models/mrp_production.py#L39-L42
It uses the extra cost of the MO + the component cost. This explains
where the $20 come from.
OPW-2641339
closesodoo/odoo#80889
X-original-commit: 0567536f8b66c71f6860041926542f88026793b1
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
On Fifo costing method, the 'value' field of a stock quant was computed using quantity_svl and value_svl of the product_id.
However the method 'with_company()' wasn't used for quantity_svl, resulting in an incorrect 'value' field of stock.quant
This commit add the use of 'with_company()' method to get quantity_svl.
OPW-2652211
closesodoo/odoo#79844
X-original-commit: 0a7709611fbbc983fc5db5dd36ab7716e543bc0f
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The active field of stock_valuation_layer is related to product_id.active.
Adding auto_join = True avoids bloating search/read_group queries in
expression.parse().
closesodoo/odoo#69207
X-original-commit: 2526c640969f462c18ab8a3da7aa0a4e8ed871f8
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
- update MO list status colors: draft = blue, in progress = yellow +
make the WO status colors match (waiting = blue, in progress = yellow)
and make draft MO lines all blue (to follow current design standard)
- cleanup Activity in tree view (no label in tree + "Next Activity" in
column selection dropdown)
- make units of analytic accounting for WO = hours
- make quantity for move_raw_ids products (i.e. components for MOs)
always have positive analytic_account_line.unit_amount (i.e. when
changing a done move's quantity + changing a quantity twice made this
value negative)
- make "Copy Operations" on BOM open the list view in "current" instead
of "new" due to lack of hook to prevent form view (i.e. open BoM in
current view) changing when clicking on lines in the new window's
operations (also ends up being a better UX anyways since being able to
view the operations form view is desired).
Task: 2648460
X-original-commit: 65a2d478197f5b856212225319500ca61b161809
Part-of: odoo/odoo#77897
- Create a product with Category configured with:
* Costing Method: First In First Out (FIFO)
* Inventory Valuation: Automated
- Create a PO to buy 1 unit and receive the product
- Create a SO to sell 1 unit and deliver the product
- Return the product
- Re-deliver the product
- Create invoice for SO but don't post it
- Connect with an user with "Accounting: Accountant" rights only
- Post the invoice
An access error will be triggered when trying to access stock valuation layer.
opw-2623376
closesodoo/odoo#76289
X-original-commit: cc76e76ef2d1cc5a16778bd9440911fd6ec73c9b
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
In multivat setup, we need to create taxes in foreign countries to map them with domestic taxes. Before this commit, this was only possible manually, even though all the necessary information lies in Odoo's account.tax.template objects created by l10n modules.
We now display a banner on top of foreign vat fiscal positions with a button allowing instantiating those templates directly from them when it's appropriate.
closesodoo/odoo#75803
Task: 2453325
Related: odoo/enterprise#20553
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The parent method _get_computed_account in the account module it already forces
the company to get the correct account, but in the stock_account module the method
is overriden when dealing with anglo-saxon accounting. In the latter, the company
is not being forced, so it leads to multi-company errors.
The fix simply enforces the correct company to prevent the error.
closesodoo/odoo#75747
X-original-commit: beba7c5b377e5aaf5ccb1d52e6b8c3bcf49468d3
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Add analytic accounting for MO.
Post expense entries for:
1. raw material cost (change with consumed)
2. work center cost (change with real duration on work order)
Task-2469742
PR #68708
When the cost of a product is set to a value below the currency rounding
the average purchase cost price will be wrongly set to zero.
It can happen for product sold in large quantity, that the cost of one product
must be smaller than the smallest unit of currency.
Instead of doing the zero check with currency precision using the
product price precision, which is the one used for the `standard_price`
fields, makes more sense and fixes the problem.
opw-2601121
closesodoo/odoo#73985
X-original-commit: 251be6b943ea8c3f274bb0863d0af3f7c6b8d10d
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Some field strings are duplicated and raising a warning in the CI.
Solution is to remove duplicated fields and put them in a common module,
or to change the string in the field declaration and put the right one
in the view.
In l10n_latam, creating a debit note with stock_account installed ends
up in stock account checking for a property in a dictionnary that may
not exist.
Using the get property will solves this issue by providing a value.
closesodoo/odoo#73221
Ticket: opw-2580992
Bug-fix: opw-2588504
X-original-commit: 423d2d4ec62312da96c66d000eaabeac4920f68f
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Brice Bartoletti <Levizar@users.noreply.github.com>
- Activate anglo saxon accounting
- Have a [DEMO] KIT product in a category using automated
Inventory Valuation with costing method AVCO
- The KIT is composed by C1 and C2 in the same product category
- Define a cost on both C1 and C2
- Open a POS session, order [DEMO], Invoice and complete the order
- Close Session, Validate and display Journal Items
COGS entries will be missing.
This does not occur when making the order without invoicing
opw-2481518
opw-2545758
closesodoo/odoo#72460
X-original-commit: 659b455aca7a2c7f0cb41bfd6312bca25917d8a9
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
- Create a Product Category: (i.e. Category X)
* Costing Method: Average Cost (AVCO)
* Inventory Valuation: Automated
- Create a Consumable Product with Category X (i.e. Product X)
- Create PO with Product X and receive products
- On Product X form, update Cost
- In debug mode, go to Accounting > Accounting > Journal Items
Account move lines have been created for stock valuation on cost change,
but it shouldn't for a consumable product.
opw-2510315
closesodoo/odoo#71723
X-original-commit: b8e6f77101d28d05dd3d79c5b6de56da4dd5d2e6
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Previous fix f056254d1c5153467b10d9581214ff6d1348be76 didn't take the
situation when production location has its own valuation accounts into
consideration. Fix it in this commit.
opw-2476417
closesodoo/odoo#71064
X-original-commit: 60e83f03b871605b7aa281503269f66ac3ea940b
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Yuchen Huang <yhu-odoo@users.noreply.github.com>
- Create a product with Category configured with:
* Costing Method: First In First Out (FIFO)
* Inventory Valuation: Automated
- Create a PO to buy 2 units at $100 (PO1) and receive the products
- Create a SO to sell 2 units (SO1) and deliver the products
=> COGS of SO1 should be $200 ($100 * 2)
- Return 1 unit from previous delivery
=> COGS of SO1 should be $100
- Create a SO to sell 1 unit (SO2) and deliver product
=> COGS of SO2 is $100
- Create a PO to buy 1 unit at $200 (PO2) and receive the product
- Re-deliver the returned unit from SO1
=> COGS of SO1 should be $300 ($100 + $200)
- Create invoice for SO1 and post it
The journal items (account.move.line) corresponding to the COGS have an incorrect
value: $200 ($100 + $100), instead of $300 ($100 + $200)
The issue comes from the method computing the anglo saxon price unit.
It does not take into account quantities from stock moves that have been returned.
This commit computes the number of units that have been returned for each stock
moves used to compute the anglo saxon price unit and to take the result into account
during the computation (of the anglo saxon price unit).
opw-2501260
closesodoo/odoo#71346
X-original-commit: 83136c8e7569636d38e12fc45f297e4d6f22ad36
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
Creating an account move from a valuation layer is bypassed in
case the product is consumable. Since 7fa9ec2638, the signature
of _account_entry_move() changed. It no longer return an account move
but a list of values to create everything in batch.
Testing the product type should now return `[]` instead of `False` in
order to be added to the existing list.
closesodoo/odoo#70945
X-original-commit: 5d76ce38a8551f430449b997a875ccc3b5a728cb
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Previously when changing cost method, we always add debit to Expense
account when empty svl. This results in an unneutral change for process
that should be neutral. In this commit, we change to use stock input
account to make it neutral.
Task 2481563
closesodoo/odoo#68083
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
_run_fifo_vacuum may take significant time. This will slow down any operations
related to stock (Inventory Adjustment, POS Session closing, etc.) or even
block them due to timeout error. So, decreasing execution time is quite
desirable. This commit is doing it by decreasing number queries:
1. prefetch all_candidates before for-loop to avoid using `search` in each
iteration
2. move code about updating standard_price after the for-loop
---
opw-2499032
closesodoo/odoo#69112
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
This commit removes stock.inventory(.line) and moves its general
functionality into stock.quant. Some features are lost during this
switch as well.
Feature Additions:
- New single list view for inventory adjustments (no more multiple
inventory adjustment records to keep track of!)
- Improved cyclic counts (annual inventory day setting) + next inventory
dates are immediately viewable in view (vs auto-generated inventories
based only on location)
- Specific quants (i.e. counts) can be assigned to users for more
flexibility (vs only able to restrict by location + product
combinations)
- Counts can be requested (i.e. bulk assigned to user/for a specific
inventory date)
Feature Removals:
- Can no longer look at previous inventory adjustments linked to a
specific record. Each quant has a history button to show inventory
related moves. [relevant account moves are also now harder to see via
stock as well]
Other changes:
- Bulk of changes were for demo/test
- Some changes were done to ensure "Update Quantity"/"Inventory Report"
views still mainly function the same as before with the exception of a
new column added to support updating quant quantities in these views.
Task: 2440026
ENT PR: odoo/enterprise#17329
Upgrade PR: odoo/upgrade#2326closesodoo/odoo#68409
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Commit f6b019fcfdd35a693e8af43ae38d10e31e96284a aims to fix the rounding
errors on AVCO valuated product when those exit stock. The issue was we
fixed the value and the unit_cost as it is rounded in the curruncy
precision. This is first wrong then useless.
The wrong part : in case the stock is empty and we make an outgoing
move, self.value = 0 so the unit_cost will be overridden to 0 while it
should stay at the standard price.
The useless part is that the unit_cost will be rerounded right after the
update to be written in database.
opw : 2380529
closesodoo/odoo#67718
X-original-commit: c2074b8c9ebf907f32a72ca6a5fadb4cd242a164
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
This commit makes the product's value computation in sudo mode in order
to be performed even by stock users.
closesodoo/odoo#67118
X-original-commit: a87c7fbad55d987b37a50e2b74b4dd9f9096a349
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
This fix (odoo/odoo#46850) was too permissive and fix too much
stock valuation issues (other than rounding error) under the hood.
The problem of the "too permissive" is will hide some errors
without get any feedback about them. Also, it changes the SVL value
without any explanation.
To avoid the first issue, apply a threshold on the rounding adjustment.
This threshold is '(quantity_out * smallest_value_of_the_currency) / 2'
(`smallest_value_of_the_currency` = `rounding` field of the related
currency).
Also to improve debugging, add a line in the description
about the rounding adjustment done in a SVL
task-2452786
closesodoo/odoo#66725
X-original-commit: a169d62e8999e90743401fcfe85200450ac6c628
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Steps:
- Go to Settings > Companies > Manage Companies
- Create a company (1) with a different currency than the one you're in
- Go to inventory > Products > Products > Create a product (2)
- Storable Product
- Cost: 10
- Click Update Quantity
- Create a new quantity line with 1 in On Hand Quantity
- Switch to company (1)
- Go to Inventory > Products > Products > Edit product (2)
- Storable Product
- Cost: 15
- Click Update Quantity
- Create a new quantity line with 1 in On Hand Quantity
- Go back to the product
- Click the "Forecasted" smart button
Bug:
Traceback here:
https://github.com/odoo/odoo/blob/47bfdf0592a5dd93870ca1a9da326351d70087bb/addons/stock_account/report/report_stock_forecasted.py#L17
ValueError: Expected singleton: res.currency(2, 1)
Explanation:
The amount is the sum of the `stock.valuation.layer`s of a product
across all companies and these companies may have different currencies.
This commit scopes the computation of the amount inside the company of
the current warehouse.
Also the `stock.quant` values displayed in the "On Hand" report are not
correct for the other companies when displaying their data by selecting
all the checkboxes in the global company dropdown.
This commit also fixes the amounts in the On Hand view by using the
standard price per company and attributing the correct currency to the
`stock.quant`.
opw:2444593
closesodoo/odoo#65267
X-original-commit: 67d975be75963678d25ae54289b2f1de639c8bed
Signed-off-by: backspac <backspac@users.noreply.github.com>
To reproduce, product A in AVCO:
- Buy 2 product A at 1.00 $
- Buy 1 product A at 1.01 $
- Sell 3 product A.
- The stock valuation won't be correct: still remain 0.01 in
stock without quantity and the svl related to the sell
have a value of 3.00 (instead of 3.01)
To fix:
In case of AVCO, add the rounding error value to the out
stock move layer.
closesodoo/odoo#65117
X-original-commit: f6b019fcfdd35a693e8af43ae38d10e31e96284a
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Commit 7fa9ec2638 create accounting entries from stock_account in
batch. The test on `self.company_id.anglo_saxon_accounting` is
problematic in case of multi recordset. Instead, this commit evaluate
the company_id for each record of `self`.
closesodoo/odoo#64813
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
This commit groups creation and posting of account moves related to
stock valuation in case of automatic valuation product.
Previously, the account move were created one by one and posted right at
the creation. Which can really slow (for instance running
_run_fifo_vaccum with a large amount of remaining quantity layer)
closesodoo/odoo#62700
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
A `stock.move` can contain thousands of `move_line_ids` (when tracked
by SN). The union of recordset (`|=`) doesn't scale well due
to the N² complexity (for 10000 SML to validate,
). Replace recordset union
by `OrderedSet` of ids + browse (linear complexity).
Before for 10000 SML to validate:
- the `_get_in_move_lines` take 14% time in the pyflame
After in the same condition:
- the `_get_in_move_lines` isn't present anymore in the pyflame
opw-2347525
X-original-commit: 0acbf6f961e4e946c9e487343ad2cc0129400b7f
Stock Valuation Layers are used for the MRP Cost Analysis feature.
Therefore, they are useful for consumable.
opw-2412668
closesodoo/odoo#63404
X-original-commit: c68e572f7c6f5109f1bfc40f9a44fc051f315112
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The creation of a Stock Valuation Layer is useless in case of a
Consumable product. At best it is useless, at worst it causes
inconsistencies when the user switch from a Consumable to a Storable
type.
closesodoo/odoo#62936
X-original-commit: 7e9d052beabe15d932e5d403f8ca2f4837c7d24f
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The open_action_with_context was not using _for_xml_id, producing an
error when reading the action content.
In open_action, the action_name was taken from the context and needs
sanity checks. Ensure only actions from the account module can be
read and only if the user has access to the target model.
This is a limitation of the previous behaviour but, at the moment, all
known calls are made refering to an action from the account module.
Limit the scope of this method while the 14.0 is still early to avoid
having a door open to ready any action, and difficult to close later.
Remove old action fetching from the context in create_move that is no
longer used.
closesodoo/odoo#61602
X-original-commit: a39e94f7e4dc74e850650ac90bbc5f85af130bc8
Related: odoo/enterprise#14695
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Xavier Morel <xmo@odoo.com>
Currently when unbuild a MO, we create journal entries the same as
receiving components (add credit to input account) and deliver
finished product (add debit to output account). But since the
unbuild is just a revesal of the MO, the journal entries should
alse be revesals.
In this commit, when unbuild a MO, for the journal entry about the
component change, we add credit to the output account, and for the
journal entry of the finished product change, we add debit to input
account make sure the journal entries are also reversals.
Task 2312828
PR #58150closesodoo/odoo#60730
X-original-commit: 83a3230706e1e2f4eaf9718156647821341d192b
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
And other reported English mistakes in source string
Courtesy of Transifex translators
And remove leftover from gengo
closesodoo/odoo#59022
X-original-commit: 26efc84c5cac47a2cc83d7b084f8b71528fec6c7
Related: odoo/enterprise#13781
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Create a product category with automated inventory valuation but no
accounts defined for expense/income
Create a stored product with such category but again without expense/income
accounts.
Create an invoice with such product and a jounral on which default
credit/debit accounts are defined.
Save and Post the invoice.
Journal entries related to the inventory move (COGS) are not created
because the accounts are missing, but the system should take the default
defined on the jounral instead of skipping the operation
opw-2339168
closesodoo/odoo#58662
X-original-commit: 3019828c1c101cdbf2f7d61a751ed6d73e40005f
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
The validation of a stock move without quantity done create an empty
stock valuation layer. This is not a wanted behavior as :
1. it create record without useful information (0 value, 0 remaining
qty, 0 remaining value)
2. The landed cost value is set on a wrong layer in case of complete
backorder.
This commit bypass the valuation process on a move if it is validated
without any quantity.
opw : 2328258
closesodoo/odoo#58776
X-original-commit: 01e21735dbf3ac2fe975323cee2f4bb93e4ca747
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Use _for_xml_id to replace all the self.env.ref().read()[0]
This has the advantage of having a single point of control and to add
the fields filtering and model verification.
Add sudo for other operations on ir.actions.*
Add an easy way to not post the entries in the future when calling
post() on it, but rather set it to be auto-posted at accounting date.
This is useful when we are creating a lot of entries in batch and some
might be in the future, some in the past, and we don't want to separate
that in two batch every time. (asset, accrual, transfer,... )
Below is the case of product with automated valuation:
- You bought 8 units @ 10$.
- Then you deliver 10 units of the product.
- You assumed the missing 2 should go out at a value of 10$
but you are not sure yet as it hasn't been bought in Odoo yet.
- Afterwards, you buy missing 2 units of the same product at 12$.
In this case the product has been undervalued when delivered without stock,
the vacuum entry is the following one (this entry already takes place):
Account | Debit | Credit
===================================================
Stock Valuation | 0.00 | 4.00
Stock Interim (Delivered) | 4.00 | 0.00
So, on delivering product with different price,
We should create additional journal items like:
Account | Debit | Credit
===================================================
Stock Interim (Delivered) | 0.00 | 4.00
Expenses Revaluation | 4.00 | 0.00
closes odoo/odoo#52396
Task: 2224025
Closes: #52396
Signed-off-by: Simon Lejeune (sle) <sle@openerp.com>
- Create 2 companies A & B, with different currencies
- Create a product in company B
Set the company on the product
Automated valuation
- Receive some stock in company B
- Switch to company A, and keep B available
- Go to Inventory > Reporting > Inventory Report
The currency on the product is the currency of the product company
instead of the currency of the current company.
The value is computed in the current company currency:
https://github.com/odoo/odoo/blob/bc3d1f2dc408fa91d42743d6a7063042e0f6c42b/addons/stock_account/models/product.py#L115
The currency should be consistent.
opw-2278751
closesodoo/odoo#53426
X-original-commit: 8aa952d18acca5a0ac3b32579e812158e641c13c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Support two new syntaxes with `_()` method:
_("This is so %s") % 2019
_("Text with %s placeholders", 42)
_("Text with %(num)s placeholders %(symbol)s", num=42, symbol="🧀")
The main benefit is to have a fallback on the source string if formating the
translated string fails (e.g. "Foo %s" translated "Foo s%").
This PR converted most (but not all) calls to _ using placeholders to use the
new syntax. Hopefully, the remaining ones will be converted in the future and
avoid technical debt.
Use named placeholders when needed. If more than one placeholder is present in a
string, using named placeholder can be beneficial to reorder the placehodler
position (for languages like Japanese that do not use the same phrase
construction). On some sentences, it also brings clarity on the meaning of the
placeholders.
closesodoo/odoo#52155
Task-id: 1853119
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When more than one parameter is present in a message, it helps the
translation to use named placeholder. This way, the order can be
changed. It also helps the comprehension of the message.
- Create 2 companies A & B
- Create a product with automatic valuation
- Switch to company A
- Create a SO for 1 unit of the product, validate and deliver
- Genrerate the invoice
- Switch to company B, but keep company A allowed
- Post the invoice
An error is raised because of inconsistent company:
> Some records are incompatible with the company...
This occurs because the anglo-saxon lines are created in accounts
belonging to company B instead of company A.
Since the product accounts are property fields, using `force_company` in
the context allows the selection of the right accounts.
opw-2276657
closesodoo/odoo#53183
X-original-commit: 603ce0f408a4479324a0905f5bc569c9f08567dd
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Brice bib Bartoletti