It seems that this long dereference causes a MemoryError for accounts
with many associated line_ids
```
select count(*) from account_analytic_account a join account_analytic_line l on l.account_id = a.id join account_move_line ml on ml.id = l.move_id where a.id=7
+---------+
| count |
|---------|
| 131672 |
+---------+
```
The solution we propose is to use search_read inverting the order of
dereferences.
Shortened Traceback:
```
Traceback (most recent call last):
...
File "/home/odoo/src/odoo/15.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/15.0/odoo/models.py", line 4249, in _compute_field_value
getattr(self, field.compute)()
File "/home/odoo/src/odoo/15.0/addons/purchase/models/analytic_account.py", line 15, in _compute_purchase_order_count
account.purchase_order_count = len(account.line_ids.move_id.purchase_order_id)
...
File "/home/odoo/src/odoo/15.0/odoo/api.py", line 893, in update
field_cache.update(zip(records._ids, values))
MemoryError
```
Observed during the upgrade of 41031
We can reproduce this pref issue locally.
On the menu Accounting > Configuration > Analytic Accounting > Analytic Accounts, with 1 million account moves
```
test_15.0=> select account_id,count(*) from account_analytic_line group by account_id
+--------------+---------+
| account_id | count |
|--------------+---------|
| 1 | 1000002 |
+--------------+---------+
```
We get (shortened):
```
2021-10-19 07:39:33,807 53565 INFO test_15.0 werkzeug: 127.0.0.1 - - [19/Oct/2021 07:39:33] "POST /longpolling/poll HTTP/1.1" 200 - 9 0.077 50.063
2021-10-19 07:39:33,888 53565 INFO test_15.0 werkzeug: 127.0.0.1 - - [19/Oct/2021 07:39:33] "POST /longpolling/im_status HTTP/1.1" 200 - 4 0.038 0.044
2021-10-19 07:40:05,916 53565 WARNING test_15.0 odoo.service.server: Thread <Thread(odoo.service.http.request.140269940897536, started 140269940897536)> virtual real time limit (178/120s) reached.
2021-10-19 07:40:05,921 53565 INFO test_15.0 odoo.service.server: Dumping stacktrace of limit exceeding threads before reloading
2021-10-19 07:40:06,296 53565 INFO test_15.0 odoo.tools.misc:
File: "/usr/lib/python3.8/threading.py", line 890, in _bootstrap
...
File: "/home/odoo/src/odoo/15.0/addons/mail/models/mail_thread.py", line 410, in _compute_field_value
return super()._compute_field_value(field)
File: "/home/odoo/src/odoo/15.0/odoo/models.py", line 4249, in _compute_field_value
getattr(self, field.compute)()
File: "/home/odoo/src/odoo/15.0/addons/purchase/models/analytic_account.py", line 15, in _compute_purchase_order_count
account.purchase_order_count = len(account.line_ids.move_id.purchase_order_id)
File: "/home/odoo/src/odoo/15.0/odoo/fields.py", line 2605, in __get__
return self.mapped(records)
File: "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1176, in mapped
self.__get__(first(remaining), type(remaining))
File: "/home/odoo/src/odoo/15.0/odoo/fields.py", line 2603, in __get__
return super().__get__(records, owner)
File: "/home/odoo/src/odoo/15.0/odoo/fields.py", line 1081, in __get__
recs = record._in_cache_without(self)
File: "/home/odoo/src/odoo/15.0/odoo/models.py", line 5901, in _in_cache_without
return self.browse(ids)
File: "/home/odoo/src/odoo/15.0/odoo/models.py", line 5149, in browse
ids = tuple(ids)
File: "/home/odoo/src/odoo/15.0/odoo/api.py", line 952, in get_missing_ids
if record_id not in field_cache:
```
closesodoo/odoo#78615
X-original-commit: 6077c9358fe650bcdc23e8d6a9432f639fca1b40
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Instead of using sort + groupby of itertools (which group only
consecutive), use only the groupby of odoo.tools which
decrease the complexity of the code and avoid unmatched keys
between sort keys and groupby keys
task-2648449
Part-of: odoo/odoo#76761
This allows to solve the following use case:
* we are in March
* a SO created during January shows currently a delivered quantity (timesheet on service or delivered goods on storable products): timesheets/pickings were done in February
* creating the accrued entry for January 31 should display accordingly an amount of 0 by default since everything was done in February
Invoices invoice_dates are also taken into account:
* day 0 : delivered 10
* day 2 : 5 invoiced
* accrued entries for 10 if accrual date = day 1, accrued entries for 5 if accrual date = day 3,
followup of task 2255642
closesodoo/odoo#75886
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
A new field on tax groups makes it now possible for this group to be displayed under a subtotal label. If not set, this defaults instead to "Untaxed Amount", keeping the traditional behavior. This is intended for withholding taxes, which can now be implemented with negative taxes and a tax group with this field set.
To do that, this commit entirely refactors the way amount_by_group worked, and replaces it with a more complete json field called tax_totals_json. It also streamlines the way taxe totals are displayed on invoices, PO and SO and makes it so that a common code is called instead of copy-pasting the same block 3 times as before.
[IMP] purchase: always display tax totals by groups on purchases orders
Before, tax totals on purchase.order's form were not shown by group, and were instead all aggregated in a single "Taxes" category. The same went for the pdf export. The portal view, though, did show the totals by group. We now display the tax groups in the same way all the time.
closesodoo/odoo#74138
Task: 2457374
Related: odoo/enterprise#19802
Related: odoo/upgrade#2670
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The raised error currently displays the internal state (e.g. 'purchase'
instead of 'Purchase Order') and therefore is not translated.
Task-2428819
Part-of: odoo/odoo#74364
In this commit some reorganization is performed within mail compose message
code. Purpose is to reorder a bit methods by main usage: onchange, CRUD,
actions, values generation with rendering and template management.
Some renaming is performed on action methods, notably send_mail that has some
impact on sub-addons. Finally we also set onchange and sub-onchange methods
private.
No functional change should be implied by this commit.
LINKS
Task ID-2377974
Community PR odoo/odoo#61467
Enterprise PR odoo/enterprise#14633
When the Product Price precision is greater than the currency precision,
it can lead to incorrect data
To reproduce the error:
(Enable debug mode)
1. Settings > Technical > Database Structure > Decimal Accuracy, edit
Product Price:
- Digits: 3
2. Create a PO
- Add a product:
- Quantity: 12
- Unit Price: 0.001
3. Save, Confirm, Edit the PO:
- Qty Received: 12
- (Note that the total is $0.01)
4. Create a bill:
- Add the PO to the field "Auto-Complete"
Error: The unit price is $0.000 and so does the total
The rounding of the unit price should be based on the Product Price
precision, not the currency precision.
OPW-2601867
closesodoo/odoo#74813
X-original-commit: 1123856c77cce4b69059b63c2bcbb382c7f0719e
Signed-off-by: Rémy Voet <ryv-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Steps to reproduce:
- Install purchase and accounting apps
- Set the database to a language that is not English
- Create a purchase order
- Remove purchase representative from PO (otherwise, no issue)
- Action -> Create Vendor Bill
- From the vendor bill, print invoice
Issue:
The pdf is in English (country names, date labels, etc...)
Cause:
If invoice type is `in_invoice` or `in_refund`, it will use the
`invoice_user_id` language (object.invoice_user_id.sudo().lang).
In the above case, there is no invoice_user_id on invoice.
Solution:
While preparing invoice values, set invoice_user_id to
self.env.user.id if not user_id on PO.
opw-2510134
closesodoo/odoo#74671
X-original-commit: 4b7569ce641a6fb20d5df676bf0b315d9b9d485d
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
Steps to Reproduce Bug:
- Create PO
- Remove default Currency
- Add a Line
Bug:
```ValueError: Expected singleton: res.currency()```
With this Commit, we are using default currency to round amount.
closesodoo/odoo#74234
X-original-commit: d9ff2e8ec7200aa15830e92e5083251c4e81dd1c
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Purpose of this commit is to avoid forcing mail_post_autofollow to True when
it is set to False. It eases inheritance and custom behavior.
Task-2612911
PR odoo/odoo#60792
When adding several PO to a bill, if they don't have the same currency,
it will lead to incorrect amounts
To reproduce the error:
1. In Settings, enable "Multi-Currencies"
2. Invoicing > Configuration > Currencies:
- EUR: Active, Current Rate = 2
- USD: Active, Current Rate = 1
3. Create a PO:
- Currency: USD
- Products:
- One product, no taxes, unit price 1000
4. Confirm PO
5. Edit PO:
- Qty Received: 1
6. Repeat 3 -> 5 with EUR instead of USD
7. Open a new Bill
8. Add the first PO to the field "Auto-Complete"
9. Add the second PO to the field "Auto-Complete"
Error: Both invoice lines are now expressed in EUR and both subtotals
are equal to 1000 even though the exchange rate isn't 1
This commit suggests not to change the currency of the account move if
the latter already has some AML. Moreover, the amounts must be converted
if they come from a PO that uses another currency
OPW-2573748
closesodoo/odoo#73483
X-original-commit: b299e880417026688b2fbde23307bd011de8c44d
Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Issue:
For purchase user, which doesn't have the "Contact Creation" can't
create a purchase, get a AccessError.
The fields `receipt_reminder_email` and `reminder_date_before_receipt`
should be writable also for purchase user which doesn't have access
to write and create `res.partner`.
closeodoo/odoo#64135closesodoo/odoo#73131
X-original-commit: f29b1e81e6adf8532ecf90f9ecb675ec56eb4c61
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Since _filter_included_tax_company filters the taxes of other companies,
there is no need to give taxes from other companies if the filtering was
already done.
closesodoo/odoo#71591
Related: odoo/enterprise#18670
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
On a product form, if the purchase UoM is different from the default
UoM, this will lead to an error when creating a RfQ.
To reproduce the error:
(Need stock)
1. In Settings, enable "Unit of Measures"
2. Create a product P:
- Cost: 100
- UoM: Units
- Purchase UoM: Dozens
3. Create a RfQ:
- Add P
Error: The quantity is 1 and UoM is Dozens, however the unit price is
$14400. The ratio has been applied twice.
When setting the product, an onchange method computes the unit price.
However, the computation is wrong: it first converts the product's
standard price using the purchase UoM of the product. Then, it converts
the result, this time using the UoM of the PO line.
OPW-2519294
closesodoo/odoo#72139
X-original-commit: b37a13d7763e4a69695fdb1567dce5d0f69ff78a
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
When confirming a RfQ, even if a follower is subscribed to "RFQ
Confirmed", he will not receive any email.
To reproduce the error:
(Need a mail catcher)
1. Create a PO
2. Add a follower and edit his subscriptions:
- Check 'RFQ Confirmed'
3. Confirm the PO
Error: No mail has been sent. The user should have been subscribed to
"RFQ Approved" to receive an email.
OPW-2447234
closesodoo/odoo#71892
X-original-commit: b459fc86d895dcd0c4bab8bb8332241fe9a43a6f
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Replace text fields to html fields as we have our own 'OdooEditor'.
Indeed, it gives more options to users in the way they format their
content without weighting too much on the UI
(tools appear on demand and not by default).
Models -> Fields
1) purchase.order -> notes
2) purchase.requisition -> description
Task Id: 2499504
X-original-commit: 43958eff2b9346420104002d628d5ca9225f8090
1. add packaging to PO lines
2. packaging on PO/SO lines can be propagate to MO
3. add package type to packaging
4. on picking types, we can choose to only reserve full packaging. That
means if you want 1 pallet(100 units) and you have 50 units in stock. It
won't be reserved.
5. suggest suitable packaging for PO/SO/MO line according to the product
qty
Task-2357259
PR #68654
UPG PR odoo/upgrade#2444
What are the steps to reproduce your issue ?
1. Create Product with Purchase Vendor(s) set
2. Create Units of Measure that are bigger than (10kg/50kg in tests)
What is currently happening ?
If you put a vendor that is listed in product form, when changing purchase unit from kg to 10/50kg price is updated
If you put a vendor not listed, it gives cost price which is correct, but does not update price according to unit of measure.
What are you expecting to happen ?
Update correctly the unit of measure when the vendor is not listed
opw-2494769
closesodoo/odoo#69196
X-original-commit: d531e8a5e4d84fe6daa9110d076b0fc601a0b4d9
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Show the purchase orders which are in state "RFQ sent" on the portal
using two separate blocks (Requests for Quotation & Purchase Orders)
as done in Sales (Quotations & Sales Orders)
closesodoo/odoo#61035
Task: 2035476
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When adding a variant product, if the option "Variant Grid Entry" is
enabled, it will reset the delivery date of each purchase order line.
To reproduce the error:
(Use demo data)
1. In Settings, enable "Variant Grid Entry"
2. Create an RfQ
3. Add the field "Delivery Date" to purchase order line view
4. Add a basic product (e.g. "[FURN_6666] Acoustic Bloc Screens")
- Keep its delivery date in mind
5. Add a variant product (e.g. "[E-COM12] Conference Chair (CONFIG)")
Error: The delivery date of the first purchase order line has changed
for no reason. Moreover, suppose that in step 4, the user defines a
specific date: the latter will still be changed after the variant
product is added.
When adding a product, the delivery date of the purchase order and its
lines are recomputed. However, an override of `onchange` ensures that
the new delivery date of the lines will be ignored if the `onchange`
concerns the field `order_line`. Here is the problem: when using the
Variant Grid Entry, the `onchange` concerns the field `grid`. As a
result, the new delivery dates are kept. This explains the creation of
`_must_delete_date_planned` in this fix.
However, when returing the result of an `onchange` linked to `grid`, the
result contains the existing lines (on client side) and the new ones
(from the Variant Grid Entry). If the field `date_planned` of the new
lines is deleted, the client will raise an error when it tries to render
these dates (it has no information about their value). Since existing
lines are of the form `(0, <client_id>, <values>)`, this fix only
deletes `date_planned` field for lines with <client_id> defined.
OPW-2454164
closesodoo/odoo#67972
X-original-commit: d2d495bca3e91862470702f1ef07aa27c33d8e2d
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
- Install purchase and stock;
- Activate Units of Measure (uom);
- Create a new storable product;
- Choose a different uom for: 'Unit of Measure' (e.g., Dozens) and
'Purchase Unit of Measure' (e.g., Units);
- Update the Cost (e.g. $ 300.00 per Dozens)
- Create a PO;
- Add the product.
Before this commit, the price on the PO will be 300 and the unit of
measure will be 'Units'.
Now, the price will be adapted to the 'Purchase Unit of Measure', in
this example it will be $25.0 per Unit.
opw-2439506
closesodoo/odoo#65119
X-original-commit: 27d251a17f3ccc597e2cd277b6d40a31dc9889b2
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Related fields are by default readonly and they should be when it
is possible. A editable related field will write on the related
model and will cause extra unwanted write of data. These unwanted write
can cause performance issues in some case (see odoo/odoo#63865).
Then remove the `readonly=False` of some related fields
(where it is useless):
- In 'mrp.workorder' (mrp): `working_state` and `production_date`
should be readonly.
- In 'purchase.order' (purchase): `product_id` should be readonly.
- In 'purchase.order.line' (purchase): `state` should be readonly.
- In 'product.supplierinfo' (purchase_requisition):
`purchase_requisition_id` should be readonly.
- In 'purchase.requisition' (purchase_requisition):
`product_id` should be readonly.
- In 'product.template' (stock):
`route_from_categ_ids` should be readonly.
- In 'stock.move.line' (stock):
`is_initial_demand_editable` should be readonly.
- In 'stock.move' (stock):
`product_tmpl_id` should be readonly.
- In 'stock.production.lot' (stock):
`product_uom_id` should be readonly.
- In 'stock.quant' (stock):
`product_tmpl_id` should be readonly.
- In 'stock.rule' (stock):
`route_sequence` should be readonly.
- In 'stock.change.product.qty' (stock):
`product_variant_count` should be readonly.
- In 'stock.return.picking.line' (stock):
`uom_id` should be readonly and also because it
is forced by `_prepare_stock_return_picking_line_vals_from_move`,
it should be related to the product uom not the one on the move.
task-2424248
The picking_type and currency were taken from the current company, even if the
purchase order is created in another company.
Fixes#35026closesodoo/odoo#64481
X-original-commit: 75936208c6e76a012027952f43b598e9d20180f3
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Do not update the date_planned of section/note purchase lines when the
date is changed on the order.
Based on f3ebab6eb52e3dc8be1f030aecfff348a22f7e09
opw-2429853
closesodoo/odoo#64458
X-original-commit: c1d5a077f26d5cb5f42888f21dafd78e3432853f
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
If a RFQ/PO is created with a specific company, its number must
be assigning using the sequence defined for that company with
disregard to current environment company. E.g. This issue can
easily arise when using aliases to create RFQ's.
closesodoo/odoo#63175
X-original-commit: 5de36feffd0347ff28c8fa35818e7bfc2535df4e
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
With this commit, all instances of errors being raised inside
`BaseModel.unlink` overrides are moved into methods decorated with
`api.ondelete` which is safer.
- Activate Multi-Currency, set a rate for a foreign currency
- Create a product with a cost of 10
- Create a PO
- Add the product
The price remains 10: it is not converted in the foreign currency.
Up to 13.0, a price of zero was set if no seller was found. This was
changed in 6b41dbf683 to set the standard price instead.
However, no currency conversion is performed.
opw-2394076
closesodoo/odoo#62831
X-original-commit: 315b7f822124fcd06c4c6ea7c8ecb8b7411338c5
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Let's consider a product P with purchase UOM = Unit
- Let's consider a UOM called Box such as 1 Box = Units
- P is invoiced according to its ordered quantity
- Create a PO for 1 Box of P and confirm it
- Create the bill B from PO
Bug:
The quantity of B was 10 and its UOM was Box
PS: When creating a bill from a PO, by default the quantities on the lines of B are always expected
in the UOM of their respective PO line
Introduced by: https://github.com/odoo/odoo/commit/d0455ae64ba3800c8a13c60c6b68a5638ed5d552
opw:2391243
closesodoo/odoo#62356
X-original-commit: 669d1ee563ad123a1db417306191c670ea741925
Signed-off-by: Simon Goffin (sig) <sig@openerp.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>
Removes the field `date_order` from the `purchase.order` order because
it tends to make the feeling the PO's sort order is kind of random.
task-2367965
X-original-commit: 4cd45b5baa2d78b059e14fbb61298dcdccacf040
Steps to reproduce the bug:
- Let's consider a company contact C with two children CH1 and CH2
- Create a purchase order for CH1 and a subscription for CH2
- Archive CH1 and CH2
Bug:
The count of purchase orders in C was displaying 0 instead of 2
Same issue for the vendor bills
opw:2360155
closesodoo/odoo#61167
X-original-commit: b3e31f2680534382b048324cfcb8a6f6c457553f
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Currently the delivery date on PO line will always be set to today if
there is no receipt date on PO, which makes the delivery lead time not
working. Fixed this issue in this commit.
Task 2357198
X-original-commit: 147aa4c67fb912a2e62dd8be1fc770db258e28d0
Purchase
- When a RFQ is in "To Approve" stage, on the printed pdf, keep "Request for Quotation" as a title
- "Send Reminder" action should open the composer when triggered manually.
Inventory
- In tree view of transfer, set date_done optional = hide
- In (mobile) picking view, replace button text with 'add a product'
- fix Vendor Group by in Replenishment report
- Warning message when changing product tracking from untracked to tracked
MRP
- Reporting > Manufacturing Orders : change measure for total quantity grouped by scheduled date = month and by product
- Reporting > Work Orders : change measure for Duration per unit grouped by workcenter and by product & add unit (minutes)
- Reporting > Overall equipment effectiveness : group by loss reason added to the current group by workcenter
closesodoo/odoo#57036
Related: odoo/enterprise#12926
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Commit 0f80e69b8d tracked all changes on
qty_received on the purchase order. But did that wrongly by calling
`write` inside a compute.
Commit b7cc3b068f685d1339f9fe7e47d0c564de1708e7 fixed this `write`
by an `=` to avoid error when the compute is called on virtual records.
This fix result on forgetting to track the quantity delivered.
This commit sends a message to post in `write` AND in the
`compute_qty_received` to be sure it is posted. This way, we do not call
write in compute anymore.
closesodoo/odoo#60067
X-original-commit: 3d592649970df3d755ccb57d68c074acdff67894
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
When PO not saved, no mail can be send. Sending a reminder preview will
get traceback. In this commit, we check if the PO is saved before
sending the mail.
Also clean some useless code in the send_reminder_preview() and fix the
issue when no json object is return to the widget because of on mail
send.
Task 2339431
PR #57961closesodoo/odoo#59399
X-original-commit: 83f2cac4b8ba101d6a7736a8ff408a3fdb5422fe
Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>
Previously, when compute on-time delivery, we compare the date_planned
on PO line with the date on stock.move. Since they are both datetime,
the product that delivered on the scheduled date may be considered delay
because of the 'time' part is late, which is normally not what we want.
In this commit, we only compare the date part of them to decide whether
it's late or not.
Task 2346121
PR #58653closesodoo/odoo#59386
X-original-commit: 86af7c647fe56f776c6cebc22dd5856577878980
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
Before this commit vendor's currency wasn't used on creating an invoice if there
is default journal in context. As I understand, the idea was to let onchange("journal_id")
handler to update the currency. It works well, if journal has the same currency
as specified in vendor record (res.partner). But it confuse users in following
scenario:
* there is just one vendor journal
* vendor is configured to invoice in another currency
* then, if you create invoice via "Accounting >> Overview >> Vendor Bills", it
would have journal's currency
* while, if you create invoice via "Accounting >> Vendor >> Bills", it
would have vendor's currency
This commit force to switch to vendor's currency on changing vendor field, even
if it differs from journal's currency. If after changing vendor, you set another
journal, then journal's currency is used (thanks to onchange("journal_id") handler)
opw-2339966
closesodoo/odoo#59162
X-original-commit: 513cc1abe121cd05623be1a6519239f8f4b3fb48
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Create a purchase order P with one line L
- Set a tax of 10%, a quantity of 1 and a unit price of 100€ on L
- Save P
- Edit P and change the unit price of L to 120€
Bug:
The amount_tax was not updated until you saved
opw:2341757
closesodoo/odoo#58912
X-original-commit: d7598086b8ac642f2cfe497ab6e33e380edb244a
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Alvaro Fuentes