Skip to content
Snippets Groups Projects
Select Git revision
  • 14.0
  • 14.0-__main__-sbi
  • 15.0
  • 18.0
  • 17.0
  • 16.0
  • 16.0-__main__-sbi
  • 12.0-suds
  • 12.0 default protected
  • 13.0
  • renovate/configure
  • 9.0
  • 10.0
  • 7.0
  • 8.0
  • 11.0
  • 9.0-ocabot-merge-pr-1088-by-pedrobaeza-bump-nobump
  • 8.0-ocabot-merge-pr-831-by-pedrobaeza-bump-nobump
  • 12.0-old
  • 11.0-ocabot-merge-pr-882-by-pedrobaeza-bump-nobump
  • 17.0_2025-03-14
  • 16.0_2025-03-14
  • 16.0_2025-02-14
  • 17.0_2025-02-14
  • 15.0_2025-02-14
  • 15.0_2025-03-14
  • 14.0_2025-02-14
  • 14.0_2025-03-14
  • 16.0_2025-01-14
  • 17.0_2025-01-14
  • 14.0_2025-01-14
  • 16.0_2024-12-14
  • 17.0_2024-12-14
  • 15.0_2024-12-14
  • 15.0_2025-01-14
  • 15.0_2024-11-14
  • 16.0_2024-11-14
  • 17.0_2024-11-14
  • 16.0_2024-11-05
  • 16.0_2024-10-14
40 results
Search by author
  • Any Author
  • Administrator Administrator coopdevs-admin
  • Adrià Pallejà Adrià Pallejà adriapalleja
  • Angels Angels Villar
  • César López Ramírez César López Ramírez cesar.lopez
  • CoopBot CoopBot coopbot
  • Daniel Palomar Daniel Palomar danypr92
  • Eugeni Chafer Eugeni Chafer eugenichafer
  • Isaac Carbajal Isaac Carbajal Isaac
  • Jordi Isidro Llobet Jordi Isidro Llobet jordiisidro
  • konykon konykon konykon
  • Pelayo García Pelayo García lai
  • Quim Rebull Quim Rebull quim.rebull
  • Rebeca Rodríguez Rebeca Rodríguez Rebeca
  • Unai Gorrotxategi Unai Gorrotxategi unai
14 authors
  1. Nov 08, 2022
    • Nshimiyimana Séna's avatar
      [FIX] account: set correct account on cash basis tax line · afe87957
      Nshimiyimana Séna authored 
      
### Steps to reproduce
* go to Accounting > Settings and activate 'Cash Basis'
* got to Chart of Accounts and create a new  account of type
  `Current Assets`. We'll call it `A`.
* create a new tax, we'll call it `T`, with the following parameters:
  * Tax type: Purchases
  * Tax computation: Percentage of Price
  * Amount: 22%
  * Distribution of invoices:
    * add a line with the following parameters:
      % = 40, Based On = 'of tax' and Account = the tax paid account.
    * add a second line with the following parameters:
      %= 60, Based On = 'of tax'
  * Distribution of Credit Notes: Add the same lines as
    'Distribution of invoices'
  * In the Advanced Options tab, set :
    * Tax Eligibility = 'Based on Payment'
    * Cash Basis Transition Account = `A`
* create a new vendor bill and add a product line to it and set
  Taxes = `T` on that line
* confirm and register payment

Now go to Accounting > Journal Items, group by Journal. Look through the
'Cash Basis Taxes' group and find the entries related to the vendor bill
you just made. One of the debit lines on account `A` is not correct.
Here, the account should be the one specified on the invoice line.

opw-2796727

closes odoo/odoo#103631

Signed-off-by: default avatarLaurent Smet <las@odoo.com>
      afe87957
    • Jinjiu Liu's avatar
      [FIX] sale_stock: lot number not shown in refund invoices · 012e25f2
      Jinjiu Liu authored 
      
This commit is to compute correct lot number for serial/lot tracked
products on refund invoices

Reproduction:
1. Install Sale, Accounting, Inventor. In setting of Inventory, enable
Lots & Serial Numbers, Display Lots & Serial Numbers on Invoices,
Display Lots & Serial Numbers on Delivery Slips.
2. Create a product with lot/serial number
3. Create a order of this product, confirm. Click the delivery and
validate it.
4. Back to the SO, create an invoice, confirm and print it, the serial
number shows.
5. At the invoice, click “Add credit note”, choose “Full refund” (2
invoices for the SO) or “Full refund and new draft invoice” (3 invoices
for the SO), the lot number doesn’t show in new draft invoice or the
refund invoice

Reason: the current lot number tracking workflow focused on invoicing
different numbers of products and making sure it gets the correct
lot/serial number. It doesn’t include the refund invoice case.

Fix: since the current working logic works great with invoicing products
which are delivered from the warehouse to the customer, we can reuse
this logic for refund invoices for products which are returned from the
customer to the warehouse. In the refund and return case, we switch the
calculation of warehouse and customer. Thus, a return can be seen as a
delivery from the customer to the warehouse.
In the code, we set a new variable, return_source_usage, to check if the
account move type is a delivery or a return. If it’s an invoice for
return, we take the opposite of the previous invoiced product quantity.
Because in a refund, previous invoiced is now considered as refunded.
In the original workflow, when sml.location_id.usage is “customer”, it’s
a return and we update the returned_qty and the related quantities. In
the new workflow, if the invoice is a refund one, we do the same steps
when sml.location_id.usage is “internal”, e.g. when the stock move line
is a delivery, we consider it a return.

For refund invoices. There are two choices of refunding:
1. refund and a refunding invoice: 2 invoices for the order, one is the
original one, another is the refund
2. refund and create a new draft invoice: 3 invoices for the order,
original one, a new draft one and the refund.

In the second case, we will create a new draft invoice. If we simply
apply the original work logic, the lot number will not be printed on the
draft invoice. This is because the previous amls list includes its
original invoice. We have to filter out the duplication of the same
invoice to print the right lot number for the new draft invoice.

Added the report test for two refund cases, one for cancel (Full refund)
and another for modify (Full refund and new draft invoice)

opw-2879714

closes odoo/odoo#99691

Signed-off-by: default avatarLaurent Smet <las@odoo.com>
      012e25f2
    • David (dafr)'s avatar
      [FIX] stock_account: Use correct company for SVL account_move creation · 33fa9cff
      David (dafr) authored 
      
The valuation field of the product_id is company-dependent.
If the user validate the picking in multi-company context with his current company != picking company, then the checks may fail, and the account move can not be created.

closes odoo/odoo#105149

X-original-commit: f2a4d537
Signed-off-by: default avatarWilliam Henrotin (whe) <whe@odoo.com>
      33fa9cff
  3. Nov 07, 2022
  5. Nov 06, 2022
  7. Nov 04, 2022
  9. Nov 03, 2022
    • MerlinGuillaume's avatar
      [FIX] mrp: change date_planned_finished when starting workorder · 0edeed2f
      MerlinGuillaume authored 
      
The scheduled end date of a work order is not consistent with its
scheduled start date when starting the work order

Steps to reproduce:
1. Install Manufacturing
2. Go to Settings > Manufacturing > Operations and enable Work Orders
3. Create a manufacturing order for any product, with any component and
   a work order
4. Confirm and plan the MO
5. Edit the scheduled start date of the work order to the next working
   day and save
6. Start the work order
7. The scheduled start date changes but the scheduled end date doesn't

Solution:
When starting a work order, change the `date_planned_finished` according
to the new `date_planned_start`

opw-3005767

closes odoo/odoo#102809

Related: odoo/enterprise#32619
Signed-off-by: default avatarWilliam Henrotin (whe) <whe@odoo.com>
      0edeed2f
    • Julien Van Roy's avatar
      [FIX] l10n_fr_fec,[l10n_]account_edi_ubl_cii[_tests]: fix factur-x tests and... · adbf4dc2
      Julien Van Roy authored 
      [FIX] l10n_fr_fec,[l10n_]account_edi_ubl_cii[_tests]: fix factur-x tests and use `default_move_type` key

Fix broken tests due to 2 different commits:

* https://github.com/odoo/odoo/commit/51609d19177c080835116f0ad9c04c33536d926a is adding the `ram:DefinedTradeContact` tag and should thus be added in the test files

* https://github.com/odoo/odoo/commit/de55cfa7098fc1fa07398044cb977f20d213f6da is using the context key `default_move_type` to import any ubl_cii document (and being able to
distinguish between invoice and vendor bills). This key should therefore be added in the tests as well.
We essentially backport the missing code from https://github.com/odoo/odoo/commit/5f78893ad6cf199ce0da72335ce65835d9cd37d9
which was forgotten in 14.0.

Also fix a broken test in l10n_fr_fec due to the renaming of the taxes:
https://github.com/odoo/odoo/commit/85a634c7527f20b56b15c2da90a37dfd637da63b



closes odoo/odoo#104792

Signed-off-by: default avatarNicolas Viseur (vin) <vin@odoo.com>
      adbf4dc2
    • qsm-odoo's avatar
      [FIX] web: restore dialog callback calls (e.g. cloning a website page) · 7d7960df
      qsm-odoo authored 
      Commit [1] broke some confirm dialogs because the confirm and cancel
callbacks are not called with the same `this` anymore.

E.g.:
- Install website
- Go to the page manager (/website/pages)
- Clone a page (choose a name and confirm)
=> Crash (this.$ does not exist).

Note that this flow was quickly fixed with [2] by changing the local
code instead of fixing the root cause (this commit here actually
technically reverts that change so it keeps working).

The work done at [1] actually needed some more rework than that to
handle two other potential usecases:

- If the confirm dialog handlers' promises are rejected, the dialog is
  not closed (rightfully, like for example allowing to fill an empty
  required input)... but [1] prevented to click on the button again
  forever. With the same example as above, it can be reproduced: if the
  RPC to clone the page fails, I cannot retry.

- If not both confirm_callback and cancel_callback were given, [1] only
  prevented to multi-click on the related button (e.g. if you click on
  "Ok", a RPC which takes 10 seconds is made, you click on cancel
  immediately afterwards -> the dialog is closed while it should be
  prevented (and would be if cancel_callback was given, following [1])).
  That may not be entirely stable to make this change though but it
  seems to make sense and be better (just keeping what [1] wanted here).

Note: this adds some more tests to check all of this + some more things
that were found during development. For example: [1] relied on the fact
that callbacks returned a Promise or nothing... while developers
actually were returning random things (for no reason as no way to get
the result anyway). Adding a test for this prevents to break that in
stable (the first iteration here crashed in such cases).

[1]: https://github.com/odoo/odoo/commit/4b8b079a7d9991a8dc481fe71a45185d672135c9
[2]: https://github.com/odoo/odoo/commit/8216341f5ad8d82ad0bcb0d1f01d874477d2de7b

Closes https://github.com/odoo/odoo/pull/103712


opw-3033878
opw-3043224
opw-3046485
opw-3042542

closes odoo/odoo#104220

Signed-off-by: default avatarAaron Bohy (aab) <aab@odoo.com>
      7d7960df
    • Huy Le's avatar
      [FIX] website: missing seo name character · bb43d4db
      Huy Le authored 
      
Currently entering custom urls will be missing characters if they contain unicode.

Steps to reproduce:
1. Open Promote dialog
2. Enter a custom url that contains unicode (e.g. `Nội dung có Dấu`)
3. Output: `n-i-dung-c-d-u`

Expected output after this commit: `noi-dung-co-dau`

closes odoo/odoo#104572

Signed-off-by: default avatarRomain Derie (rde) <rde@odoo.com>
      bb43d4db
    • Paolo Gatti's avatar
      [FIX] l10n_it_edi: self-invoices require fiscal regime RF18 · a066a8b1
      Paolo Gatti authored 
      When the seller is foreign, the Fiscal Regime of the seller must
be set to 'RF18', as per:
https://www.fattura24.com/manuale/altri-documenti/autofattura-fornitori/

Task: https://www.odoo.com/web#id=3010849&model=project.task


opw-3010849

closes odoo/odoo#104780

Signed-off-by: default avatarJosse Colpaert <jco@odoo.com>
      a066a8b1
    • Guillaume (guva)'s avatar
      [FIX] account_check_printing: print check from expense · d005fd85
      Guillaume (guva) authored 
      
When printing a check that comes from an expense,
the check has no reference to the move from which
the payment has been created.

The reason is that we filter the move by taking
only outbounds to complete the check informations,
but moves from an expense are of type entry.

With this commit, we allow moves coming from
expense to be taken into account by adding a
check on line_ids.expense_id.

opw-3044141

closes odoo/odoo#104493

Signed-off-by: default avatarJohn Laterre (jol) <jol@odoo.com>
      d005fd85
    • JordiMForgeFlow's avatar
      [FIX] mrp: ensure only active BoMs are considered on product2bom · e53f7ef1
      JordiMForgeFlow authored 
      
When executing the product2bom method it is possible that an active_test
context is present in self. However, the method should not consider
archived BoMs.

closes odoo/odoo#104495

X-original-commit: 5e07b367
Signed-off-by: default avatarWilliam Henrotin (whe) <whe@odoo.com>
      e53f7ef1
    • Alvaro Fuentes's avatar
      [FIX] mrp: improve perf of `_skip_bom_line` · 04553b92
      Alvaro Fuentes authored 
      
The main motivation for this change is to improve performance of BoM
`explode`, which heavily rely on checking the lines to skip. `explode`
is also called from product `compute_quantities_dict` which is called
multiple times during upgrades. With this fix we improved the running
time of an upgrade _test_ from 3h:30m to 2h:55m which gives a 16%
performance improvement.

The goal of `_skip_bom_line` is to check that for each attribute present
on the line, at least one value associated to that attribute must be in
the attribute values of the product(*). If none is found then we
consider that we can skip the line.

The previous implementation was inefficient. It grouped all values by
attribute, then checked one by one if at least one value is on the
product. In case one attribute does not have any value on the product it
skipped the line.

The implementation we propose here is to take the intersection of the
product and line values, then check that their attributes are the same.
The later can be done with a simple length check. In case they are
different the line must be skipped. Note that this works because only
one value is possible per attribute in a product.

Both implementations are equivalent. The second is more efficient
because does not branch and relies on (record)set operations.

For example, let's consider a product with two attribute values
`a` and `b`, and a line with multiple values `a`,`y` for
attribute 1, and `z` for attribute 2.
```
Product                      Line
+---+                      +-----+
| a | <- same attribute -> | a,y |
+---+                      +-----+
| b | <- same attribute -> |  z  |
+---+                      + ----+
```
This line must be skipped. The reason is that the value `b` is not
among the list `[z]` of values for attribute 2 on the line. The new
implementation would get the intersection of attribute values as `[a]`
from there the comparison of the attributes will fail because `[a]` has
only one attribute while the line has two.

Let's consider a second case, where there is no value on the line for
attribute 2.
```
Product                      Line
+---+                      +-----+
| a | <- same attribute -> | a,y |
+---+                      +-----+
| b | <- same attribute -> |     |
+---+                      + ----+
```
This line is not skipped because there is no value for attribute 2 on
the line. Therefore the condition(*) per attribute is not violated for
this product. The new implementation gets `[a]` as intersection of values,
but now the attributes coincide: they are both attribute 1 for the
intersection and the line.

Finally,
```
Product                      Line
+---+                      +-----+
| a | <- same attribute -> | a,y |
+---+                      +-----+
|   | <- same attribute -> | z,w |
+---+                      + ----+
```
This line is skipped because none of `[z,w]` are in the product. The new
implementation would get again `[a]` as intersection which does not
match the attributes on the line.

closes odoo/odoo#99047

Signed-off-by: default avatarWilliam Henrotin (whe) <whe@odoo.com>
      04553b92
    • Tom De Caluwé's avatar
      [FIX] purchase_stock: ignore tax calculations in tests · 70f7e2d7
      Tom De Caluwé authored 
      
The tests in the purchase_stock module include some tests that make sure or
depend on the fact that the price_unit from the generated move lines equals the
price_unit from the purchase order line from which they were created.

However, the price_unit in the move lines exclude taxes (at least those that
have an account set, it uses the total_void computed from the purchase order
line). This means some tests will fail if an installed localization defines
taxes that are included in the price.

The problem is resolved by explicitly creating the test product used in those
tests without supplier taxes.

opw-3033340

closes odoo/odoo#104672

Signed-off-by: default avatarAdrien Widart <awt@odoo.com>
      70f7e2d7
  11. Nov 02, 2022
  13. Oct 31, 2022
    • maximilien(malb)'s avatar
      [FIX] char_template: avoid duplication of reconciliation model · 7cd2207d
      maximilien(malb) authored 
      In some cases it is possible that a plan is the parent of other plans, for example in Spain. Without this condition, the generate_account_reconcile_model method will be called multiple times and create multiple identical reconciliation models, which is not the expected behavior.

This error has already been fixed in 16.0 in another PR (see: https://github.com/odoo/odoo/pull/99581

), but not in 14.0 and 15.0.

closes odoo/odoo#103260

Task-id: 2982600
Signed-off-by: default avatarOlivier Colson (oco) <oco@odoo.com>
      7cd2207d
    • David (dafr)'s avatar
      [FIX] purchase: Add 'price_total' & 'price_tax' to the order lines tree · 70878ed4
      David (dafr) authored 
      
# Description
The absence of those fields can generate a log note spam & performance issue when updating an order line value.

# HOW TO REPRODUCE
- Create PO with 40+ order lines (50 recommend) (* SA to reproduce would be nice)
- Confirm PO (state needs to be "purchase")
- Update the Ordered Quantity of the first line.
- Save
=> PO Lines from page 2 and beyond have each created the following log message:
"The ordered quantity has been updated."

# Explanation
The purchase.order.line onchange will not save any update on 'price_total' because it is not on the onchangeSpec.
Then a purchase.order onchange is done, and this one does have 'order_line.price_total' on the onchangeSpec, forcing the onchange method to return the field 'order_line' (aka ALL the order lines) as updated.
When saving the changes, the JS framework, who does not have the data for the order_lines on the 2nd page, will not correctly filter the fields with real changes, and add the 'product_qty' field (and more) to the "write" call for every order_line not in the 1st page.
Then the write method, without checking if there is any real change on the product_qty, for each lines that has product_qty in the Write's values, will write in the log note and call a performance intensive method: _create_or_update_picking()

OPW-2982004

closes odoo/odoo#104490

X-original-commit: e99cdd64
Signed-off-by: default avatarWilliam Henrotin (whe) <whe@odoo.com>
Signed-off-by: default avatarDavid <dafr@odoo.com>
      70878ed4
    • Florent de Labarre's avatar
      [FIX] point_of_sale : wrong api · 2abeb8cc
      Florent de Labarre authored 
      
Before this PR when you select a pos.payment in custom, it raise.
It doesn't make sens to use api.model here

closes odoo/odoo#99237

Signed-off-by: default avatarTrinh Jacky (trj) <trj@odoo.com>
      2abeb8cc
  15. Oct 30, 2022
  17. Oct 28, 2022