When reversing an invoice linked to a sale order, the value of the new
anglo saxon AML should be based on the value of the returned product
To reproduce the issue:
(Need account_accountant,purchase)
1. Create a product category PC:
- Costing Method: FIFO
- Inventory Valuation: Automated
2. Create a product P:
- Type: Storable
- Product Category: PC
3. For C in [10, 20, 30]:
- Create a purchase order with 1 x P at cost C
- Receive P
4. Create a SO with 3 x P
5. Deliver the products one by one
6. Create and Post the invoice INV linked to SO
7. Return the second delivery
8. Add a credit note to INV01:
- Credit Method: Partial Refund
9. Set the quantity to 1
10. Post the new invoice INV02
Error: The anglo saxon lines are listed in the journal items, which is
correct, but their value is $30 while it should be $20 (i.e., the value
of the returned product)
When delivering the last product, its standard price is updated with the
new value ($30):
https://github.com/odoo/odoo/blob/6b96ed418cb626678f4fa5baec25a903d7a74eda/addons/stock_account/models/product.py#L305-L307
Later on, when posting the credit note, the module gets the anglo saxon
unit price (`_stock_account_get_anglo_saxon_price_unit`). However, it
does not consider that the current account move line is reversing
another one. In the reversing process, the computation of the invoiced
quantity should be based on the invoices lines that are reversing too.
Moreover, when computing the average unit price of the returned product,
the module should use the stock moves that are returning the product.
In the use case, because of the two issued noted above,
`_compute_average_price` does not find any stock valuation layer to
compute the average unit price and uses the fallback, i.e. the standard
price of the product:
https://github.com/odoo/odoo/blob/6b96ed418cb626678f4fa5baec25a903d7a74eda/addons/stock_account/models/product.py#L652-L656
That's the reason why, in the above case, the value is $30 instead of
$20.
Note: a similar use case can be reproduced with a kit
OPW-2646926
OPW-2628215
closesodoo/odoo#82978
X-original-commit: 524d0d5e8817e1c7bcc99204c4cbb90fcfb6074c
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
When reversing an invoice that contains some anglo-saxo AML, the new
anglo-saxo AML should have the same unit price than the original one
To reproduce the issue:
(Need account_accountant,purchase)
1. Create a product category PC:
- Costing Method: AVCO
- Inventory Valuation: Automated
2. Create a product P:
- Type: Storable
- Product Category: PC
3. Create a purchase order PO01 with 2 x P for $10
4. Confirm PO01 and process the receipt
5. Create and Post an invoice INV01 with 2 x P
- As listed in the journal items, the anglo-saxo lines have been
generated with a value of $20
6. Create a purchase order PO02 with 2 x P for $20
- The cost of P becomes $15
7. Confirm PO02 and process the receipt
8. Add a credit note to INV01:
- Credit Method: Partial Refund
9. Set the quantity of P to 1
10. Post the new invoice INV02
Error: The anglo-saxo lines are listed in the journal items, which is
correct, but their value is $15 (the new cost of P) while it should be
$10
When reversing an invoice with the "partial refund" method, the
anglo-saxo lines are generated via the regular flow (as if it were a
"standard" invoice). Therefore, when getting the unit price of the line,
it uses the product's standard price. In such situation, it should use
the unit price of the original line.
OPW-2646926
OPW-2628215
X-original-commit: 87f7e78340dfe553923b2b65f61de06d5778cfbd
Part-of: odoo/odoo#82978
The letterRendering setting was only properly set for the `Printer` class but not for the `EpsonPrinter`.
closesodoo/odoo#82980
X-original-commit: 3bbf4bbcc0e1f81c1eddb91b54c3c863722aea46
Related: odoo/enterprise#23586
Signed-off-by: Masereel Pierre <pim@odoo.com>
If you have some text in your task, the second column will be stacked
closesodoo/odoo#82979
X-original-commit: 60f0d908386cf98a7879c9ad6788299d81d778cb
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Currently, when creating a new course from front-end, placeholder for
the course description is broken because it's split in multi line in
the xml file.
This commit fixes the issue by keeping the placeholder in a single
line in XML file and thus preventing the gap being displayed between
two sentences on front-end.
TaskID-2734524
closesodoo/odoo#82973
X-original-commit: 0db1844ddaf1f4cd46152e356dea10f3fd07169a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
As this test is always red, notably because of the qunit asset bundle, the
threshold is raised for some bundles based on runbot builds
observations.
closesodoo/odoo#82972
X-original-commit: ab8350b5432a6a6d671bcc76413815274f7daaca
Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Steps to reproduce:
Have a 0% Tax
Make an invoice with it
Open tax report
The 0% tax is not present in the report because there is no tax lines generated for them because the resulting balance is zero.
Since the tax details is making a mapping between tax lines and base lines and the tax report is using them to compute the report, the tax report is not able to compute the tax base amount for such taxes.
Explanation:
Until now, the tax line with a zero amount wasn't generated because considered as noisy journal items.
Now we must be able to groupby on the base tax account on the tax report, we are forced to use the tax details.
Injecting dynamically the 0% tax on the tax details sub-queries is really complicated and leads to a huge performance drop.
For that reason, we start to generate the tax lines for 0% tax even the balance is zero.
However, since there is nothing creating the missing lines in the past, it should be fixed case by case if needed.
opw-2711432
closesodoo/odoo#82971
X-original-commit: 65b5ec4ad65f798b1d647978b5b42a49e760139a
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
Each delivery provider, requires some information about the packages
that need to be sent as well as about the commodities (for commecial
invoices). Since this is needed by each provider, and the required
values are very similar, these packages and commodities can be done one
step ahead: in the base delivery module.
These new `_get` functions return a list of custom objects containing
the most important values concerning packages and commodities, and can
be called directly from the child classes.
closesodoo/odoo#82891
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Steps :
- In mobile, go to Task
Issue :
- "Sales Order" stat button is not displayed.
Cause :
- This button's classe are :
- d-md-inline = displayed when size is medium+.
- d-none = or else not displayed
- In the past, there was a field SO in the form,
which made this button unnecessary and taking space.
Fix :
- Now that this field isn't present anymore, delete d-none part.
opw-2722535
closesodoo/odoo#82963
X-original-commit: 16f489ad6b6b9e8118bc806f220cf122e20374a8
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Some aggressive cache invalidation in the middle of method write() where
the model has children models (in the _inherits sense) causes very nasty
errors that are hard to fix.
Consider two models A and B, where B inherits from A. Also consider two
fields a1 and a2 on A, which are thus both inherited by B. Now take a
record from model B, and update both fields as:
record.write({'a1': ..., 'a2': ...})
As both fields appear as related fields on model B, the method write()
puts all values in cache, then it proceeds to call the inverse method of
both fields. The inverse method of a1 is called, and this writes on the
parent record. Now imagine that some override on A invalidates the
whole cache. When the inverse method of a2 is called, the field's value
on B has been invalidated, and this therefore writes the value False on
the record's parent.
This patch removes and adapt such cache invalidations:
- Since 4b1cb41cf7, the cache invalidation
in method write() of product.product is no longer necessary.
- The cache invalidation in method write() of product.pricelist.item
has been removed as well, since field that needs to be recomputed no
longer exists.
Fixes#76946, #77042closesodoo/odoo#82958
Opw: 2657461
X-original-commit: 5a73a8a3697c0f2685471efa252e5eb1af738e83
Signed-off-by: Raphael Collet <rco@odoo.com>
Before this commit, users returning from Buckaroo to Odoo after payment
could see their session renewed, depending on their browser's
implementation of the `SameSite` cookie attribute. This prevented Odoo
from retrieving the transaction from the users' session.
This commit flags the return route of Buckaroo with
`save_session=False`, hence allowing all users to immediately
post-process their transactions when they return to Odoo.
closesodoo/odoo#82938
X-original-commit: b309d3a99f8ff4a43a21c4772c344ed3250e319f
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
- create an SO with dropshipping, confirm. It create a PO 1
- copy PO 1
--> Issue PO 2 is linked with the SO
closesodoo/odoo#82902
X-original-commit: d56f94d7db59f1228ec90ab0e8ab1e89f3a663e7
Signed-off-by: Arnold Moyaux <arm@odoo.com>
The commercial invoice is usually only needed when the country of the
sender is different from the country of the recipient, however, for india,
commercial invoice is mandatory, even if the goods dont leave the country:
https://cleartax.in/s/commercial-invoice/#commercialclosesodoo/odoo#82084
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Usually we want to create commercial invoices in case the warehouse is in a
different country than the recipient. However, some countries like India
need those documents for internal shipping as well.
The added function can easily be overriden in a dedicated module for the
countries that require such a commercial invoice.
Part-of: odoo/odoo#82084
The store_fname is calculated based on the checksum, as for file_size
and checksum, skip during create/write
Avoid replacing in place the attachments in base as this breaks some
tests reusing the vals_list content (e.g. test_complete_me
Set datas in the copy to keep the content when duplicating a record
(e.g. test_14_duplicated_css_assets fails without this)
running twice because of @warmup share the same self.vals)
closesodoo/odoo#82919
X-original-commit: 611e6794376b0d60291dec085485bb2fb4e31a33
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
In some cases, the SM description is incorrect
To reproduce the issue:
1. Create a product P
2. Create a receipt with 1 x P
Error: The description of the SM is incorrect: `<p><br></p>`. It should
be the name of P
Another example:
1. Create a product P:
- Internal Notes: "Lorem Ipsum"
2. Create a receipt with 1 x P
Error: The description of the SM is incorrect: `<p>Lorem ipsum<br></p>`.
It should be "Lorem Ipsum"
Since [1], `product_template.description` is a HTML field.
[1] bea5790713
OPW-2732208
closesodoo/odoo#82917
X-original-commit: 73f05114307b6ec6590da22903751ab79e7efa90
Signed-off-by: Arnold Moyaux <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>
Step to reproduce:
- Create a lead
- go on the smart button meeting
- create a new meeting and edit it
- save
Current behaviour:
- Validation Error
- It seems the default_get apply command in onchange instead of passing the value which lead to missformed argument for meeting
Behaviour after PR:
- Do not send readonly attendee in calendar.event form view
opw-2724372
closesodoo/odoo#82794
X-original-commit: fba25d6982d149a9d5083f993dea7c2091736c58
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Arnaud Joset <arj@odoo.com>
AdditionalDocumentReference is currently injected right after DocumentCurrencyCode.
However, in 15.0, OrderReference is implemented and then, AdditionalDocumentReference is no longer injected at the right place.
To fix this, we inject now this field just before AccountingSupplierReference that must be always there and Signature is not implemented.
For more details, see:
http://www.datypic.com/sc/ubl20/e-ns19_Invoice.htmlclosesodoo/odoo#82897
X-original-commit: ce4d52fbbf400d911901e09d562e06984447639a
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
While posting an invoice, if the transactions linked with the invoice
are failed due to valid reason from the payment acquirer, forcing
reconciliation on transactions' payment will raise an error because such
payment isn't posted.
closesodoo/odoo#82895
X-original-commit: 52937b441432b56994dda857d8cdee06b8128872
Signed-off-by: Laurent Smet <las@odoo.com>
American Express CVC code are 4-digit numbers
Current Behaviour:
Authorize currently only accept numbers up to 999.
Behaviour after PR:
Authorize accept number up to 9999
opw-2727511
closesodoo/odoo#82770
X-original-commit: 9f7821655a2b632f8e36569c438df358c0d23d02
Signed-off-by: Damhaut Florian (flda) <flda@odoo.com>
Prior to this commit:
- The selector used by the FormHtmlFieldExpanderMixin is the generic one
'.o_xxl_form_view .oe_form_field.oe_form_field_html'. This selector, altough
valid, could lead to an undesired behavior if another html field is present
previously (before the description one) in the view.
After this commit:
- The '[name="description"] is added to the selector which reduces the possible
matches only to the one of the description field.
closesodoo/odoo#82926
X-original-commit: db8684055712ec9c5d1acadee60e54a78d87c941
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
The issue:
When creating a fresh DB with demo data, the demo company and
customer are created with l10n_latam_identification_type_id set to
the default, which is 'VAT', rather than 'RUC'.
This creates a problem when we create an invoice with the demo
company and the demo customer and validate it: when the l10n_pe_edi
module sends the invoice to the OSE, the OSE responds with the
following error code:
'1007|El dato ingresado no cumple con el estandar - [...]
error: Error Factura (codigo: 1007): 1007
(nodo: "cbc:ID/schemeID" valor: "0")'
Some observations on how the issue occurs:
Interestingly, when you create a new company or partner using the UI,
the `l10n_latam_identification_type_id` is automatically set to 'RUC'.
This is ensured by the `ResCompany.create()` and
`ResPartner._onchange_country()` methods, see
https://github.com/odoo/odoo/blob/f84dbf63b9354a3c577589178a09c3ffb151cba3/addons/l10n_latam_base/models/res_company.py#L10 and
https://github.com/odoo/odoo/blob/f84dbf63b9354a3c577589178a09c3ffb151cba3/addons/l10n_latam_base/models/res_partner.py#L24
However, when the demo company is created, the `create()` method is
called at the first <field> element, which is `name`, and so,
`create()` does not set `l10n_latam_identification_type_id`.
And because the demo partner is created without the UI, the onchange
is not called when the partner's country is set.
The solution:
Therefore it is necessary to manually set the
`l10n_latam_identification_type_id` in the demo data.
closesodoo/odoo#82920
X-original-commit: 33e174d58e7ad2a5a965f31a23c4b8281fedef79
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
HttpCase.base_url() was introduced with ded278b9c2 but many tests were
using the name attribute already. The tests have been adapted to use the
new method.
closesodoo/odoo#82910
Signed-off-by: Julien Castiaux <juc@odoo.com>
Wrongly defined in #55525Fixes#82834closesodoo/odoo#82907
X-original-commit: 6ece16fbb0ceaced022a2d1b3f0c5769ba827125
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The title's (S)CSS selector was failing to pick up the invoice title,
because it was inside the .swiss_container_v2 while it should be out of that.
opw-2584899
closesodoo/odoo#80873
Signed-off-by: William André (wan) <wan@odoo.com>
Steps:
- Create an Analytic Account AA
- Create an Analytic Default Rule : when Product P > AA
- Create a Quotation including P, confirm and invoice
Issue:
- AA is not set for the invoice line of P
Cause:
- AA is computed on the invoice line when the product is added,
but it is recomputed afterward from cache, where it is None
Fix:
- Not allow it to be recomputed afterward.
opw-2714340
closesodoo/odoo#82639
X-original-commit: 34b7c834cb67e1dc1f3727f103489e084c4788bf
Signed-off-by: Onockx Audric (auon) <auon@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
*: mrp,point_of_sale,purchase,sale,stock
This commit adds the product tag model access to accurate manager groups.
task-2675384
Part-of: odoo/odoo#79296
This commit handle product tags and adds the ability to easily define
ribbons, coupons or Dynamic Snippet for a given tag.
Purpose
=======
Product tags allow users to define a given coupon/promotion program on
chosen products templates or product variants.
Product tags allow users to easily add a common ribbon on product
templates which shares a tag.
Product tags allow users to easily define a Product Dynamic Snippet to
show product variants which uses the same tag as the current product
template.
task-2675384
Part-of: odoo/odoo#79296
This commit adds the product tag model.
Purpose
=======
The product tags allows to easily tag given types of product
independently from their category, following their product range, their
seasonal collection, their theme, etc
Specification
=============
A product template takes tags that are valid for all their variants.
In order to add granularity, product variants can also take additionnal
tags.
A field is defined on product variants to allow searching on both
product template and product variant tags.
task-2675384
Part-of: odoo/odoo#79296
- Go to Email Marketing and create a new one
- Select any template
- In Settings tab, set a Preview Text
- Send a test
The content of the received test email is a text with the html code of the email body.
When sending the test email, the body is retrieved with "render_field" method, which
does not return a Markup object but a simple string.
Then "_prepend_preview" method prepends preview (Markup) to body (str).
opw-2686316
closesodoo/odoo#82886
X-original-commit: 71258f5020a0d1c4581cf85df31be3fb3f95562a
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The fix to add an `overflow: hidden` in order to prevent the browser
from chaning the scroll create a glitch where the scrollbar dissapear
when it is overflow: hidden.
A new css property exists to specify exactly this behavior
(`overscroll-behavior: contain;`).
Task-2728791
closesodoo/odoo#82880
X-original-commit: 4cfa9e786d41a27d1bc850eff4fc89e1c4b32974
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
The removal of existing order lines on template update was unexpectedly
lost in recent code changes.
This commit brings back the old expected behavior.
closesodoo/odoo#82868
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Current behavior:
When archiving a customer contact, the SO linked to this customer where not shown after clicking sales smart button in company
Steps to reproduce:
1. App "Contacts": Have a company and a contact as child of this company.
2. App "Sale": Create a Sale Order for the contact of the company and confirm it.
3. App "Contacts": Archive the contact of the company and switch to the company.
4. App "Contacts": The Smart Button for sale orders says it has one sale order but if you click on it NO sale orders will be shown.
opw-2735060
closesodoo/odoo#82796
X-original-commit: f22364c32ac1438ededd611578b64a69186d7c9c
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
The "Join course" link with additional resources was broken
Task-2735494
closesodoo/odoo#82804
X-original-commit: f59cbca07aff6107a355009b74b336a2860dfe29
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
The dashboard is using a domain `[('move_id.state', '=', self.id)]`
This impacts the performances because we are not joining explicitely on
`move_id`. We can't use the field `state` because it is re-declared on
`account.bank.statement.line`.
X-original-commit: 8b19f0f981fefc6df7c8298b57619c6b9b0a0890
Part-of: odoo/odoo#82807
Prior this commit, the description field of both project.project and project.task
were displayed with the resizable bar and were displayed with a calculated height
which prevented to see the whole field.
After this commit, the resizable option is set to false which displays the whole
field content without the resizable bar.
task-2735599
closesodoo/odoo#82818
X-original-commit: 8acdb9e197eb78ceefec444a245b8b7f01e81fdc
Signed-off-by: Xavier <xbo@odoo.com>
Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>
Steps to reproduce:
- install accounting (account_accountant)
- go to invoice
- click on "send and print"
-> template is not loaded directly
Solution:
- revert changes of commit #fc5812c327daab4 since the onchange is now called only once
OPW-2732687
closesodoo/odoo#82805
X-original-commit: fa25a3b2b7cdafbce70e39a8a896924f015185a9
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
Description of the issue/feature this PR addresses: in version 15,
sometimes Google and Microsoft calendar synchronizations break with error:
Create/update: a mandatory field is not set.
Delete: another model requires the record being deleted. If possible, archive it instead.
Model: Calendar Attendee Information (calendar.attendee), Field: Contact (partner_id)
This is happening, because when Odoo is syncing an event, it will match
attendee with res.partner, if no existing partner is found, a new one
will be created unless:
- the address matches an existing mail alias ([alias_name]@[mail.catchall.domain])
- the address is invalid (eg. in outlook the email address is sometimes
in the form /o=ExchangeLabs/ou=.../cn=Recipients/cn=...
In this case we should not try to add the attendee to the odoo event.
Current behavior before PR: Error when syncing that the customer can
only solve by removing the erroneous attendee or remove the event from
their calendar.
Desired behavior after PR is merged: if the partner cannot be created
we ignore it.
opw-2670002
opw-2683889
opw-2702661
opw-2704631
opw-2711907
opw-2720032
opw-2722028
closes#82109fixes#78678closesodoo/odoo#82667
X-original-commit: 1cd470c8922119d0da0b69ab7d4b4ff746533689
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
Co-authored-by: andro19951 <andro19951@gmail.com>
If money is withdrawn, we can't tell if it's a transfert to the bank account or if some money has been withdrawn to pay an invoice or some expense.
We then assign the suspense account in order for the accountant to go through the reconciliation widget process in order to dispatch/assign the amount to the right account(s).
This allows all the accounting process to go smoothly without any needs for the accountant to manually create a miscellaneous entry.
Introduced by:
closesodoo/odoo#82616
Pr: https://github.com/odoo/odoo/pull/82123
Commit: https://github.com/odoo/odoo/commit/336656e0e9677ccb2f43935b6f267fa83ed153df
X-original-commit: 04396e0627fd36d28b047e0e122ffb55a3a12ebc
Signed-off-by: Florian Gilbert <flg@odoo.com>
Steps to follow
- Go to the contact app for example
- Export some records with a relational field in the import-compatible xlsx format
- Reimport the downloaded file
- Odoo can't find matching records with a name False
Cause of the issue
xlsxwriter will write a boolean false value for empty relations
Solution
If a field is relational, write an empty string instead
opw-2643705
closesodoo/odoo#82803
X-original-commit: 510a498aa71f117975a08ca3d3df6217e3b8a74d
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
Signed-off-by: Hubert Van De Walle <huvw@odoo.com>
This commit introduces a new social_media snippet that allows social
networks to be displayed. This snippet shares the same options as the
share snippet, but also provides a list to edit the URLs of the social
networks in the company data (social_facebook, ...). This list also
allows to manage links to custom social networks (which are not stored
in the DB).
Headers and footers now use this new social_media snippet instead of the
share snippet and in the settings, the urls to the DB social networks
are editable/visible only in developer mode.
task-2687447
closesodoo/odoo#80217
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Co-authored-by: Guillaume (gdi) <gdi@odoo.com>
Co-authored-by: Romain Derie <rde@odoo.com>
Adrien Widart