Currently, the UBL/CII format (if enabled on the invoice) is checked by
default, which will trigger the validation checks upon generation. This
can be annoying (feedback: "error message when we want to send invoices
to customer. For some customer, there is a problem with the xml file. To
be able to send the invoice, we uncheck the box for the xml invoice. See
video:
https://drive.google.com/file/d/12IkhqQtHw0EUF3srqRX8uZjCXU2DYpns/view?usp=sharing)
To solve the issue, we add a new field `invoice_is_ubl_cii` to check or
uncheck the UBL/CII checkbox by default.
In addition, rename the field `invoice_is_print` to
`invoice_is_download` since it corresponds to the checkbox 'Download'.
Finally, make the `company_id` of account.move.send a computed field
instead of using the `_default_get`. Indeed, when creating the wizard
and passing a `move_ids` key, this key will not be detected as missing
by the `default_get`, and we will not enter the statement in the
`default_get` in `account_move_send.py` to set the `company_id`. As a
consequence, the `company_id` will not be set, and the subsequent
computed fields will not be correct (e.g.
`wizard.company_id.invoice_is_ubl_cii` will always be False inside
`_compute_checkbox_ubl_cii_xml` if `company_id` is not set).
task-3297308
closesodoo/odoo#119397
Related: odoo/upgrade#4581
Signed-off-by: William André (wan) <wan@odoo.com>
When the record is a draft record (with a NewId), the attachment is not retrieved correctly.
Indeed, `move_vals` contains the real ids.
closesodoo/odoo#121224
X-original-commit: 34ff1d66d5352f36d8d982d868e0b01c929c3c88
Signed-off-by: William André (wan) <wan@odoo.com>
When modifying the accounting date of an invoice in Accounting Firms
mode, Odoo always generates a new invoice sequence number. This behavior
can introduce gaps in the sequences.
1. Activate Accounting Firms mode.
2. Create a new Draft Invoice and save it.
3. Create a second Draft Invoice and save it.
4. Modify the accounting date of the first invoice and save it.
5. Observe that the first invoice's invoice sequence number is updated
to the next sequence, creating a gap.
Recompute the sequence only when the new date falls into a different
fiscal year.
opw-3164537
closesodoo/odoo#121215
X-original-commit: 28c5c37c420eda8f916dc0f031521313ac18ec08
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
When l10n_mx_edi is installed and a payment is posted, the move_name field on account.move.line
being a related to move_id.name is not well computed.
That is because posting a move trigger the computed field in a protected mode due to `flush_recorset`.
This mode prevents any computed field to be recomputed twice.
This flush triggers `_compute_name` calling `sequence_mixin`, itself doing another `flush_recorset`.
This extra flush triggers `_compute_l10n_mx_edi_cfdi_uuid` that access to `move.payment_id.reconciled_bill_ids`.
This access to this field triggers its recomputation and then, `_compute_stat_buttons_from_reconciliation` is called.
This method does `self.env['account.move.line'].flush_model()` that force the computation of `move_name` to `/`.
`sequence_mixin` assigns the new `name` to the journal entry but `move_name` is not recomputed due to the
protected environment.
closesodoo/odoo#121114
X-original-commit: 33198b3443829d6d6e421cf9d6b8033a040b5263
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
the error will occur when adding more than one attachment to draft invoice
chatter and click on send button.
applying these changes will resolve this issue.
sentry-4059207297
closesodoo/odoo#120238
X-original-commit: a2fcf96df23a7eea7ff9ddb94798e8375590ae28
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Smit Nagar (smna) <smna@odoo.com>
When receiving an email on a mailbox with an alias that triggers the
creation of invoices, 4 bugs could occur.
1. If the xml received contains replacement characters (U+FFFD �), and
the charset of the part of the email is "US-ASCII" the encoding of the
string will fail, preventing the rest of the flow to be completed. Be
more resilient, encode the string and ignores these characters if this
case occurs.
NB: sometimes, the charset is omitted for a Content-type: text/xml. This
is valid but not recommended (see:
https://www.ietf.org/rfc/rfc2376.txt). In this case, the default used is
"US-ASCII". This means that any non-ascii char will be lost (they are
replaced by the replacement character: �, see:
https://github.com/python/cpython/blob/3.10/Lib/email/contentmanager.py#L67)
when decoding the attachment.
2. When the xml attachment is created in Odoo, the mimetype is
'text/plain' (rather than 'application/xml'). Thus, the
`_decode_attachment` needs to be more flexible when guessing the type of
the attachment (to know which function to use to read the content of the
attachment and create the invoice).
3. When creating an invoice from an email with an xml attachment, the
xml is attached as the `message_main_attachment_id`. It's only later on
that the content of the xml is read and we possibly find the PDF in
base64 inside. When creating the PDF attachment, it was not set as the
`message_main_attachment_id`, so the PDF was not rendered on the right
part of the invoice form view. Add a clause to replace the
`message_main_attachment_id` in such a case.
4. When the xml attachment represents a credit note, the move_type of
the invoice created by the email alias needs to be changed. Indeed, the
invoice is created before decoding the attachment, so we can only change
the `move_type` later.
opw-3144519
opw-3149649
closesodoo/odoo#121076
X-original-commit: 1e193a92b9c84e75b958985f8067873b90f686e0
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Partial revert of b15116179e71040ffa01bb35161e32b16aac477d .
This fix introduced a new bug: when creating an write-off with taxes from the bank reconciliation widget, signs were all inverted in the tax report, because that commit was forcing the values of tax_tax_invert in a wrong way.
The proper fix is to fix the computation of the is_refund field in community, so that negative repartition lines are taken into account ("debit" is a refund for a "sales" tax only for positive repartition lines, for example).
Community part is in https://github.com/odoo/odoo/pull/120152closesodoo/odoo#120924
X-original-commit: 67e789074cb00b9db6e3fd83ef92ed712b28edfb
Related: odoo/enterprise#40856
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
Cash basis taxes use a distinct transition account on their tax lines; the tax account set on the repartition lines is only used when the payment is received, on the cash basis move.
In enterprise, the bank reconciliation widget allows setting a tax on the manual write-off done for a statement line. When doing so, we expect the tax to behave just like on an invoice. For cash basis taxes, this means the "final" tax account has to be used instead of the transition one ; it wasn't the case.
OPW 3255511
X-original-commit: 991fa46081296c3560bd7ca195996693a81a46b8
Part-of: odoo/odoo#120924
account
1. We introduced a new Production Cost account that can be set on
locations with Production type. When products move into/out of a
production location. The account entry will be post on this account
instead of previous Stock in/out account.
2. On the accounting setting page, we can now set the default values for
all stock accounts. Users can also disable automatically accounting for
stock there.
Task-3046333
closesodoo/odoo#113973
Related: odoo/enterprise#37653
Signed-off-by: Tiffany Chang <tic@odoo.com>
If applied, this commit will solve the issue of the payment terms 'Example Date'
issue while we keep that blank and try to save the Payment Term.
Steps to produce:
- Open any Payment Term.
- Remove the example date.
- Add a line in Due Terms and click on save button.
Added a default value while the example date is not getting.
sentry - 4065889321
see - https://tinyurl.com/2caru9ddclosesodoo/odoo#120234
X-original-commit: 980aa78c0d9228cba665066d08ea7cd2f83e0097
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Parth Solanki (paso) <paso@odoo.com>
The bank statement & transaction demo data has problems:
1. the statement doesn't have a name
2. the creation of the statement lines are postponed causing the opening/closing balances to be invalid (as the order of the statement lines is important)
This is due to the _load_data method in account, which defers the creation of records to ensure that related records are created before they are referenced in relational fields.
This commit adds a condition to avoid deferring fields that have a list of ORM create commands, and fixes the statement name and balances.
closesodoo/odoo#120975
X-original-commit: 1d219de36944685153a77aeeb72920b06728383e
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
When partially reversing a bill and paying the
difference, the payment state should be 'paid'.
In the particular case of having the bank account
as manual outstanding payment account on the bank
journal, payment state was 'reversed'.
opw-3235107
closesodoo/odoo#120967
X-original-commit: eb0baf273980957b522e3e41b5d371ba081c915d
Signed-off-by: Laurent Smet <las@odoo.com>
Co-authored-by: Habib Ayob <ayh@odoo.com> & Laurent Smet <las@odoo.com>
Have an invoice marked as paid
Send by email
Issue:
Email will contain "$ <amount> due <due date>" which is confusing for
the user as the invoice is already paid
opw-3289653
closesodoo/odoo#120905
X-original-commit: 5c66a766abed5142d77835dcfda423abdcb1429f
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
This comes as a followup of https://github.com/odoo/odoo/pull/120423 where we restrict unallowed users to toggle the field allow_out_payment when writing on res.partner.bank. Similarly, we'll now do the same check at the creation of bank accounts
closesodoo/odoo#120694
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Bugfix: at the moment, if the environment's language is not en_US,
loading a CoA doesn't correctly load the translations: the translations
for all languages are created with the en_US terms.
Steps to reproduce:
1. Create a DB and install l10n_be.
2. Switch to French.
2. Create a new company based in Belgium.
3. Install the Belgian CoA on the company.
Expected behaviour: The accounts should be in French.
Actual behaviour: The French translation of the accounts contains
the terms in English.
Analysis:
When the records are created by _load_records(), the language of the
environment is French. As a result, all translatable terms are created
with translations in en_US and in fr_FR.
See https://github.com/odoo/odoo/blob/39292a02ab34ea86abd5601055901eb968006944/odoo/fields.py#L1762-L1771
Later on, when the translations are loaded by _load_translations,
there already exists a name->'fr_FR', so our call to
translation_importer.save(overwrite=False) doesn't want to overwrite it.
See https://github.com/odoo/odoo/blob/2780c37cfdb8560ac7c725fd27f4fe272f1d3072/addons/account/models/chart_template.py#L787
As a result, we end up with the English terms in both the en_US and
fr_FR translations.
The fix:
Set the language to en_US when calling _load_records().
closesodoo/odoo#120863
X-original-commit: 52ef69aa8423a0fd5d78af1ab018a98dba87361c
Signed-off-by: William André (wan) <wan@odoo.com>
Duplicate the default Account Payable (211000)
Set the default Account Payable to Deprecated
Create a Vendor Bill with a line
Save
Error will raise
The account Account Payable (211000) is deprecated.
opw-3199157
opw-3229350
closesodoo/odoo#120799
X-original-commit: 0dc11ed2e4e530ddefe4310fa6bef7001f20ecc1
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Create 3 invoices for customer (A: $100, B: $300, C: $200)
Have a customer payment of $500
Reconcile the payment, in the widget add the line in the order:
- Payment line
- Invoice A
- Invoice B
- Invoice C (partial payment)
Reconcile
Check invoices
Issue:
C will be fully paid, the partial payment will be applied to B
After 5b2c1d243c0dd5b049ceae280dd270fc8a59f955
We order the lines by amount currency but the user provided order is
lost. Moving the original fix to point of sale
opw-3240586
closesodoo/odoo#120779
X-original-commit: 89f9028901a8b43aab605c12e3c7bcc2a7dd8d44
Related: odoo/enterprise#40805
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Display the totals and taxes on pdf invoices in the company currency when the invoice is in foreign currency. This is a requirement from some countries where local authorities need the VAT to be expressed on the invoice in the national currency even if the invoice has been issued in another currency. The tax groups details are also required. The new information is expressed using a rectangle at the bottom right of an invoice. It includes the same information as the detail of totals and taxes above, with the difference that it is in company currency. If cash rounding is activated, the total rounded must not be displayed in company currency.
task : 3256515
closesodoo/odoo#118234
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Some reports require editable expressions to accept other inputs than just a float.
This commit adds support for a string or a boolean.
For string input, we need to specify that formula='text', figure_type='string'.
Boolean input: figure_type='bool'.
task-3098957
closesodoo/odoo#110692
Related: odoo/enterprise#36150
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
The file uploader uses a context key `default_journal_id` to identify the journal to upload to. With commit https://github.com/odoo/enterprise/commit/0d7d1a2994f14b80cd8f3644871f87a472821741, we attempt to reconcile imported transactions immediately. When reconciling, if there is a partner and an account number, the res.partner.bank is created.
Problem:
When creating a partner bank account, the default_journal_id is in the context, and is interpreted as a default value, which causes a stack trace.
Solution:
Explicitly specifiy the journal_id when the partner bank account is created, so there is no invalid value when obtaining defaults.
task-3299109
opw-3291805
opw-3291064
opw-3291024
closesodoo/odoo#120554
X-original-commit: ff4e080d3e006104cf6345d96e56714b0f8be16d
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
# Steps to reproduce
* create two 17% sales taxes. We'll call those taxes `17a` and `17b`.
* set rounding method to global
* create a SO with the following 2 lines:
* Price = `50.4`, Taxes = `17a`
* Price = `47.208`, Taxes = `17b`
* note that the total tax amount on the SO is `16.59`
* confirm and invoice the SO.
You should see that the total tax amount on the invoice is `16.60`. The
invoice and SO should have the same tax amount.
opw-3179228
closesodoo/odoo#120224
X-original-commit: 715d0e269c3d42a5e25f8ddf648d275069354aaa
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Co-authored-by: Laurent Smet <las@odoo.com>
Co-authored-by: Yolann Sabaux <yosa@odoo.com>
Because we are flushing, and because the business code might be flushing
elsewhere (i.e. to validate constraints), the fields depending on the
sequence field might be protected by the ORM. This is not desired, so we
already reset them here.
The symptoms were that sometimes the related field `move_name` on
`account.move.line` would stay at `/` even after the new `name` was
given.
closesodoo/odoo#120488
X-original-commit: e7db87db57e4f98719602502d80948a5ed51adc2
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
How to reproduce:
- Activate l10n_be and go on a Belgian Company
- Activate Quick Encoding on Bills
- Setup account 600000 with taxes 12% (Sales) and 12% M (Purchase)
- Create a Bill
- Put 112 as the amount Tax Incl.
=> Both taxes are put on the line, which makes no sense, resulting
a sale tax on a purchase document.
It was forgotten in https://github.com/odoo/odoo/commit/85d89a986b6adcf9d0ac0ce57599d4b2678b59a3closesodoo/odoo#120486
X-original-commit: 04287db0045eefed1b03e04d745874caf206731f
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Improve some aspects of the recent res partner bank improvement:
- the url toward the docs open in a new tab
- fix the account creation by disabling the readonly when trusted
while the record isn't existing in the database yet
- improve the visual of the setting by putting it in the accounting
section
closesodoo/odoo#120423
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
When posting a move without any taxes, and hashing in version 3,
as in the test `test_account_move_hash_versioning_3`,
there was a case when the move could have its name changed after
posting, and so, after hashing.
The issue came from the order of computation of the name, as
we gave the name in the values when we shouldn't.
closesodoo/odoo#115222
Related: odoo/enterprise#38163
Signed-off-by: William André (wan) <wan@odoo.com>
If there are no default taxes on product or account, or
predictive guess, there should be no default taxes on a new aml.
So the `account_sale_tax_id` (and `account_purchase_tax_id`)
field only concern new products (as specified in the tooltip
of the field).
In Argentina, there is a constraint so all lines should have
a tax. So, we need to add default tax on their demo products.
We also add it to the products in account demo to have taxes
by default on demo invoices for all localizations.
task-3045026
Part-of: odoo/odoo#115222
Import a file with a content like this (specifying the amount in foreign
currency but not the amount in company currency)
```
Journal,Reference,Journal Items/Account,Journal Items/Label,Journal Items/Analytic Distribution,Journal Items/amount in currency,Journal Items/currency
Miscellaneous Operations,EUR March 2023,101000 Current Assets,label,,-29,EUR
,,201000 Current Liabilities,label,,29,EUR
```
The debit/credit were set to 0, but it would have been expected to compute
the amount from the foreign balance instead.
task-3287331
closesodoo/odoo#120022
X-original-commit: 5f2412ac0ebb7e5868fc6c60789914de2c213d3f
Related: odoo/enterprise#40467
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
## Summary
Currently, when using both an early payment discount (upon invoice) and
price-included taxes, the invoice totals are not calculated correctly.
## Steps to Reproduce
1. Set `Cash Discount Tax Reduction` to `Always (upon invoice)`.
2. Create an invoice with the payment term set to `2/7 Net 30`.
3. Add an invoice line with a price of 100 and a 21% price-included tax.
4. Save the invoice: The `Untaxed Amount` should be 100, but it
incorrectly shows 100.35 instead.
## Cause
When calculating the totals, the price-included tax is applied to one of
the early payment discount lines. Since the tax is price-included, the
system recalculates a new base price for the EPD line, which ultimately
leads to an incorrect `Untaxed Amount`.
opw-3239904
Enterprise PR: odoo/enterprise#39007closesodoo/odoo#119892
X-original-commit: 43b78a96a8961b83cf1c18f58bd549dabc90c50f
Related: odoo/enterprise#40404
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Co-authored-by: Laurent Smet <las@odoo.com>
Have 2 Customer invoices journals
Create an invoice
Add a line
Save
Edit product description
Change journal
Product description will reset to default
opw-3171099
closesodoo/odoo#119850
X-original-commit: 43b49f8cacff87e15102993ff4e2d06c9bff8ff4
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
This commit allows the exact search of a text that is searched between dashes.
Examples: 0EUM => VAT 0% EU M.
21M => 21% M , 21% EU M, 21% M.Cocont and 21% EX M.
21 M" => 21% M and 21% M.Cocont.
21" M"co => 21% M.Cocont.
X-original-commit: ad2682c513c82052539cf99a54994b035b2afe6d
Part-of: odoo/odoo#119756
When a product category valuation is set to `real_time`, we use the
stock accounts. However, in the code, to know which account we
should use, we do: "use stock accounts if defined, else use basic
ones" (the best should be "use stock accounts if `real_time`" but
this refactoring task will be done in master). So, here, we need to
ensure that stock accounts are not defined when the valuation is manual.
This is the case when installing `stock_account` module: the
valuations will be set to manual, so we need to force the stock
accounts to `False`. Same when creating a new company, we also need to
ensure that the stock accounts are not defined. This explains the
changes in `_post_load_data`
About changes in `_check_valuation_accouts`, the explanation is in
the method body: the defined values directly depends on the value of
`property_valuation`
Note about test modification: for the tests in `stock_landed_costs`
module, we set the categ to auto so the stock accounts are defined.
Otherwise, when validating the landed costs, it will lead to an error
https://github.com/odoo/odoo/blob/9cd316f038dc95051814ede9474f8f15f7d165df/addons/stock_landed_costs/models/stock_landed_cost.py#L396-L397
OPW-2746384
X-original-commit: 2780c37cfdb8560ac7c725fd27f4fe272f1d3072
Part-of: odoo/odoo#119564
Due to performance issues, the computation of the balance in GL was changed (odoo/odoo#103697)
Since it is computed in `_get_journal_dashboard_bank_running_balance` as the last statement balance (balance_end_real) + transactions (account.bank.statement.line since the last statement), we rename the label on the journal dashboard to "Running Balance".
Also, fix the order clause of the "Last Statement" balance as it has a problem when there are 2 statements on the same day.
OPW-3265511
closesodoo/odoo#119764
X-original-commit: 383f52ac2b75a839469323a1e71b4c2ea76f8393
Related: odoo/enterprise#40334
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Ayob Habib (ayh) <ayh@odoo.com>
Enforce strict types for returned values for
* create
* write
* unlink
* default_get
to make those methods more consistent and reliable.
Also make sure they can be called with empty self/values,
i.e. that they follow the same behavior as the base methods
defined in the main orm Model.
closesodoo/odoo#116809
Related: odoo/enterprise#38880
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
To enable VAT validation (VIES/ simple), the base_vat module needs to be installed.
base_vat extends models where the validation should apply. This means it only works with models in account, unless the module is added as a dependency (base_vat depends on account)
To avoid this dependency (in account reports - see enterprise PR odoo/enterprise#34068), two methods required for VAT validation are added to res.partner so that the enterprise module is able to use this feature with/without base_vat.
closesodoo/odoo#106046
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
The computation of `use_in_tax_closing` was overlooked when refactoring[^1]
the CoA templates. Since it was using a `onchange` with an extra code in
`create` of the `account.tax.repartition.line.template`, it didn't work on
its own after the refactoring.
[^1]: 5125748616closesodoo/odoo#119440
X-original-commit: e51ffcb01be3238338f23946b75f7e034032cf37
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
The lockdate date should not be included in the check
for sequence holes, as it is supposed to be locked
Task-3280680
X-original-commit: 18573b7c47f19933e6a420f8bb8d72687b568a5b
Part-of: odoo/odoo#119427
When you create an entry on Miscellaneous Operations journal and
schedule an activity on that entry, the Accounting dashboard
crashes and gets completely inaccessible because of an untranslated
field on mail.activity.type.
closesodoo/odoo#119318
Task: 3283382
Opw: 3277677
X-original-commit: 14481724cb5d6a164332586eb18f3195c6508b12
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Signed-off-by: Claire Bretton <clbr@odoo.com>
For some reasons, we need to store information about a transaction
in the bank statement line. This commit adds the field to handle
this information.
task-3270965
closesodoo/odoo#118943
Related: odoo/enterprise#39955
Signed-off-by: Laurent Smet <las@odoo.com>
## Summary
The early payment discount (EPD) grouping functionality can break when
using taxes that add tax tags on their base lines.
## Steps to Reproduce
1. Install the `l10n_be` module
2. Ensure that `Cash Discount Tax Reduction` in the settings is set to
`Always (upon invoice)`
3. Create a bill and set the payment term to `2/7 Net 30`
4. Add a product line (`l1`) with any Belgian tax and save
5. Add the same product line again (`l2`) and save
6. Attempt to add another product line or remove an existing one and
save: an error will occur, stating that the move is not balanced
## Cause
The EPD grouping key depends on various factors, including the
`tax_tag_ids` (tax grids) of the product lines. However, the system
currently processes mixed EPDs before taxes. As a result, when saving at
the end of step 5, EPDs are calculated for `l2`. However, `l2` does not
have tags at this stage, while `l1` does, since it was saved earlier.
This discrepancy leads to incorrect EPD grouping.
opw-3129639
closesodoo/odoo#119226
X-original-commit: 044957eac66bad04aa64dd16488843369cd0833e
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Unsupported operand type(s) for +: 'NoneType' and 'relativedelta'
occur when we create payment terms without a preview date (date_ref).
This is because date_ref has no value.
This commit solves the issue by adding a condition if date_ref is not
available, so it adds current date instead of it.
sentry-4068322613
closesodoo/odoo#119187
X-original-commit: a9f556c0d45c32574c94765462d4b59726fc3f19
Signed-off-by: William André (wan) <wan@odoo.com>
If applied, this commit will solve the tuple index out of range error when the
'Percent' value is not set in the Due Terms and the user tries to add 'Fixed'
value in more than one line.
To reproduce this issue, follow the steps.
- Open Accounting -> Configuration -> invoicing -> payment terms.
- Open any payment term, and change the value from 'Percent' to 'Fixed' in Due
Terms.
- Add another line with a value as 'Fixed'.
see-https://tinyurl.com/22e2yj2a
sentry-4072967091
closesodoo/odoo#119131
X-original-commit: fcb3c237e24ec44fd6df0de5f2a0f329efb1bf13
Signed-off-by: William André (wan) <wan@odoo.com>
- Enable Cash Rounding in settings.
- Create the cash rounding as
- Rounding precision: 5.00
- Rounding Strategy: Add a rounding line
- Profit Account: Any
- Loss Account: Any
- Rounding Method: Half-up
- Enable "Lock Posted Entries with Hash" on Customer Invoices Journal.
- Create a draft invoice and set the cash rounding on it.
- Confirm
Error will raise
You cannot edit the following fields: Account, Label, Partner.
The following entries are already hashed
This occurs because cash rounding is recomputed during post,
after hash was written
opw-3235377
closesodoo/odoo#119126
X-original-commit: 5cb044dd8a2385c9a3c09520ed97eb4faa39216d
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce:
- Go to accounting > journal entries > create a new journal entry.
- Add a line with an account.
- Add a second line.
Previous behavior:
We are going to get in the second line a suggestion of the first line
introduced, also even if we don't select the suggestion the taxes of
the suggestion will be applied.
Current behavior:
As discussed with the PO, we only want to get suggestions when we used 2
accounts in a row, so the 3rd line will be the one getting the
suggestion. And we also avoid seting the taxes of the suggestion if we
don't select it.
Related to #39784
opw-3098361
closesodoo/odoo#118865
X-original-commit: 927890d0178c361ef8d80fe6a1ec2ffaefaf73fd
Related: odoo/enterprise#39921
Signed-off-by: William André (wan) <wan@odoo.com>
At the moment, XSD files are automatically downloaded at database
initialization, which is quite unnecessary.
The idea is to change Odoo's use of XSDs from being systematically
downloaded and used for validation to simply being available if desired
(e.g. for development or for customers who want them).
To achieve this, this commit does the following:
- remove the XSD download crons;
- provide a 'download XSDs' button in the Settings (next to the debug
mode button) which is available in debug mode;
- skip XSD validation if any required XSD file is not present; and
- deprecate the 'force_reload' option.
Entreprise PR: odoo/enterprise#38350
Task id: 3010716
closesodoo/odoo#118790
X-original-commit: c8174c7914e567489de74b574b076467440bdb2d
Related: odoo/enterprise#39879
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Antoine Dupuis (andu) <andu@odoo.com>
Julien Van Roy