Currently, when the `invoice_date` of an invoice is updated (triggering
the recomputation of `date`) and if a system flush occurs before any
line's date is accessed, the invoice lines' dates do not get updated.
The following test illustrates this issue:
```py
move = self.init_invoice(
move_type='in_invoice',
partner=self.partner_a,
amounts=[1000.0],
)
move.invoice_date = fields.Date.from_string('2024-01-01')
self.env.flush_all()
for line in move.line_ids:
self.assertEqual(line.date, move.date) # will fail
```
Cause
-----
The `date` of a move is a computed field dependent on the move's
`invoice_date`. The `date` of a move line is a related field, pointing
to its parent move's `date` (note: related fields are computed fields).
During a flush, the system recomputes all fields that need to be. Here,
the system first processes 'account.move.date' and calls its computation
(`_compute_date`). However, the `_affect_tax_report()` call within
`_compute_date` triggers a recalculation of `account.move.line.date`,
but as this happens within `_compute_date`, the invoice lines' `date` is
recalculated using the old invoice `date`.
Fix
---
Force a recalculation of the invoice lines' dates whenever the invoice's
date is changed.
opw-3759472
opw-3875405
opw-3872006
opw-3884013
closesodoo/odoo#163530
X-original-commit: e9d955c5a52902cdac86c6285204c54876c68eac
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Steps to Reproduce
------------------
1. Install `sale_management` and `account_edi`.
2. Create a user with admin access in sales but no rights in accounting.
3. Log in as the new user.
4. Navigate to a Sales Order that has been invoiced and attempt to view
its invoice via the 'Invoices' stat button.
Expected Behavior: The user should be able to view the invoice.
Actual Behavior: An access error is encountered when attempting to view
the invoice.
Cause
-----
The access error arises due to restricted permissions for
`account.edi.format` and `account.edi.document`. Prior to commit
604a47ead8, all users had access to these
models. However, this commit restricted access solely to users with the
`account.group_account_readonly` role, as part of a broader security
enhancement to minimize unnecessary access by portal users.
opw-3858685
closesodoo/odoo#163412
X-original-commit: 3be00fa01ed400c2bd7b4fda49871fd14869a48d
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Currently, you cannot send a credit note to Facturae if it was created
from a paid invoice
Steps to reproduce
------------------
* install `l10n_es_edi_facturae`
* create an invoice and register its payment
* created and confirm a credit note from your invoice
* attempt to send that invoice to Facturae
You should be met with the following traceback:
`psycopg2.ProgrammingError: can't adapt type 'account.move'`
Cause
-----
In the function `_l10n_es_edi_facturae_get_corrective_data()`, there is
an attempt to browse the output of a call to
`_l10n_es_edi_facturae_get_refunded_invoices()`. This function is
expected to return a mapping of id to id. However, in certain scenarios,
it may return a mapping of id to recordset instead.
opw-3811170
closesodoo/odoo#161549
X-original-commit: a0172cb5f8efc35c4138aadc56beebca328457f4
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Steps to reproduce
------------------
* install l10n_es_edi_facturae
* create and confirm an invoice
* click on 'Send & Print'
You should see that you are unable to uncheck 'Generate Facturae edi
file'
Cause
-----
In 0d3d6c8, `l10n_es_edi_facturae_checkbox_xml` changed to a non-stored
and read-only computed field.
Fix
---
A proper fix would consist in making the field
`l10n_es_edi_facturae_checkbox_xml` stored. But we can't do that in
stable. So we make it `company_dependent` as a workaround.
opw-3772085
closesodoo/odoo#161433
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Currently, a traceback appears when you attempt to generate a Facturae
document for a credit note created manually.
Steps to reproduce
------------------
* install `l10n_es_edi_facturae`
* create a credit note manually (not from an invoice)
* confirm and attempt to generate the Facturae EDI file
You should be me with a traceback:
`ValueError: not enough values to unpack (expected 1, got 0)`
Cause
-----
To generate the EDI document, the system needs the credit note to have a
link to the refunded invoice. However, in this case, there's no invoice
since the credit note was created manual.
opw-3786219
opw-3772085
closesodoo/odoo#160565
X-original-commit: 202387e518118171051e0db0fe857f44d442fb95
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Currently, attempting to print an unconfirmed Saudi invoice in foreign
currency results in an error. Furthermore, even if the invoice is
confirmed, the exchange rate displayed is not correct, the rate of the
confirmation date is used, instead of the accounting date.
Steps to reproduce
------------------
* install `l10n_sa_edi`
* switch to a Saudi company
* create an invoice in a foreign currency.
* without confirming the invoice, attempt to print it
You should be met with a traceback: `Undefined Function: operator does
not exist: date <= boolean`
* confirm the invoice, ensuring the confirmation and invoice dates have
different currency rates.
* print the confirmed invoice.* print the invoice
You should see that the printed rate does not align with the actual
transaction amounts.
Cause
-----
The system incorrectly uses the `l10n_sa_confirmation_datetime` to
calculate and display the currency rate on the PDF. This field is only
populated upon invoice confirmation, leading to errors when printing
unconfirmed invoices. Moreover, using this date for confirmed invoices
results in displaying an incorrect rate, as it may differ from the
`invoice_date`, which should be used for accurate rate calculations.
opw-3731624
closesodoo/odoo#159698
X-original-commit: 67da9437d3606cb8a291c071214cc30914ce7fb0
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Currently, on sale orders, you cannot access parent's fiscal positions
from a branch.
Steps to reproduce
-----------------
* install `sale_management`
* set up a company hierarchy. Let's say we have two companies P and C
such that C is a branch of P.
* let's say that P has a fiscal position F
* switch to company C
* attempt to set fiscal position F on a sale order
You will see that F does not appear on the list.
opw-3773335
closesodoo/odoo#159386
X-original-commit: fa419e550497b1291930f9fb8215a719de331024
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Currently, if you have an empty MISC journal and receive a document,
that document will be assigned a MISC sequence, regardless of the actual
document's type.
Cause
-----
When a document is received, it is processed in two steps:
1. An empty account move is created and linked with the document.
2. The newly created move is populated with data extracted from the
document.
At stage 1, when the move is created, it is temporarily placed in the
MISC journal. In the event that this journal is empty, a sequence is
assigned to the move. Consequently, even if the move's journal is
subsequently changed, the sequence remains unaltered.
Fix
---
Manually recompute the sequence when the move's type is set.
opw-3663873
closesodoo/odoo#155887
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Currently, if you install the Mexican localization, you are no longer
able to create a new account in the chart of accounts.
Steps to reproduce
------------------
* install `l10n_mx`
* attempt to create a new account in the chart of accounts
You should be met with a traceback: `TypeError: AccountAccount.create()
missing 1 required positional argument: 'vals_list'`
Cause
-----
The `@api.model` and `@api.model_create_multi` decorators in indicate
that a method is intended to operate at the model level rather than on
specific record instances. Without these decorators, the system defaults
to treating methods as if they are meant to be executed on the record
level. This distinction significantly impacts how methods are invoked
through RPC.
In RPC scenarios, Odoo's default expectation for record-level methods is
that the RPC call will include the IDs of the records to which the
method applies, alongside any actual method arguments necessary for the
operation.
Here, `create()` is called through RPC, as a model-level method (i.e,
without record IDs). This makes sense because `create()` is always a
model-level method. However, in our case, create is a record-level
method, so the system expects the RPC call to contain record IDs. This
mismatch produces a traceback.
Issue introduced by 858bf9efdd9fcc29a73336863a51227c15cc19f0
opw-3772520
opw-3772469
opw-3772287
opw-3771854
opw-3771361
closesodoo/odoo#156163
X-original-commit: 59a49bda5607e8a12cf153c4338785de42cde90c
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Steps to reproduce
------------------
* install `l10n_din5008_repair`
* set the document layout to din5008
* create a Repair order and attempt to print it
You should be met with a traceback.
opw-3718479
closesodoo/odoo#155597
X-original-commit: aca5b96a7ffd9811d8b90a04686eeeadc55156f5
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Steps to reproduce
------------------
* install `l10n_sa_edi`
* switch to a Saudi company
* deactivate the "EDI : Perform web services operations" scheduled
action. (this will help ease the reproduction process)
* create and post two invoices for a partner that's an individual (not a
company)
* manually run that scheduled action.
You should be met with a traceback.
Cause
-----
When a ZATCA document is submitted, the system performs several
operations, two of which are important for this issue:
1. Generating a signature (`l10n_sa_invoice_signature`)
2. Using this signature to generate a QR code (`l10n_sa_qr_code_str`)
The QR code generation relies on the assumption that the signature
(`l10n_sa_invoice_signature`) already exists, which is a reasonable
expectation as the signature is typically created prior to the QR code.
However, complications arise when multiple documents are submitted
simultaneously in a batch process. During batch processing, each
document in the batch undergoes the same two operations mentioned above.
The issue emerges due to the behavior of non-stored computed fields .
In Odoo, computed fields are evaluated in batches, meaning that if you
access a computed field for one record, Odoo may also compute the same
field for other records fetched in the same operation. For example, if
you have two records, `A` and `B` such that `B.id in A._prefetch_ids`,
and you access a computed field on `A`, Odoo will also compute this
field for `B` at the same time.
This behavior leads to an issue when submitting two documents (`D1` and
`D2`) together. The system will generate a signature and then compute
the QR code for `D1`. However, when computing the QR code for `D1`, it
inadvertently attempts to also compute the QR code for `D2` due to the
batch computation behavior. Since `D2`'s signature has not yet been
generated at this point, this results in an error.
opw-3696146
closesodoo/odoo#155269
X-original-commit: 97e67514c0e72730882cc093b36cb5477eba496d
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce
------------------
* install `account_peppol`
* open a partner's list view
* select a contact
* on the top middle, click Actions > Verify Peppol
You should be met with a traceback:
`AttributeError: 'bool' object has no attribute 'setdefault'`
Cause
-----
`button_account_peppol_check_partner_endpoint` is expected to return an
action or a falsy value (no action to perform).
opw-3683612
closesodoo/odoo#152817
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce
------------------
* install `l10n_ch_reports`
* switch to a Swiss company
* enable "QR Codes" in Settings > Accounting > Customer Payments
* create and confirm two invoices for a Swiss partner
* on the invoice list view, select and attempt to print the two invoices
at once
You should be met with traceback.
opw-3697569
closesodoo/odoo#154063
X-original-commit: b6cb6b3ecd80d8c919790cc3178dfcb62f6f49fb
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Steps to reproduce:
- Create a child company.
- In the child company, create a new sales journal.
- Create and confirm an invoice using this new journal.
- Attempt to create a credit note from that invoice.
In this scenario, you would encounter an error.
Cause:
The `AccountMoveReversal` wizard is currently setting its company to the
root company of the moves, which in this case is the parent company.
However, its journal is set to the one created in the child company.
This mismatch causes an error due to company inconsistency.
Fix:
The `company_id` of `AccountMoveReversal` will now be assigned to the
company of the moves, rather than the root company. To ensure this works
correctly, we also added a check to guarantee that all moves being
reversed are from the same company.
Note:
This fix also resolves an issue where a traceback occurred if two
invoices were created (one in the child company and another in the
parent company) and an attempt was made to reverse both simultaneously.
opw-3640719
closesodoo/odoo#153396
X-original-commit: cd62e3fcaab3e71e606607308cace739bc480c4f
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Steps to reproduce
------------------
* create the following hierarchy of companies:
```
Company
└── Branch A
└── Branch B
```
* delete `Branch A`
From then on, whatever you do will result in a Bad Request response.
opw-3662711
closesodoo/odoo#153264
X-original-commit: da803db384ec809a9c68dd379bf3c03f00d5a731
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Summary
-------
wkhtmltopdf's "smart shrink" option does not work properly with rtl
languages, unless the direction is specifically set on the body/html
tag.
Steps to reproduce
------------------
* install Accounting and the Saudi Arabia localization
* switch the Saudi Company
* language to Arabic
* print the General Ledger
You should see that a few columns do not appear on the PDF. They are out
of bounds.
Cause
-----
The "smart shrink" option in `wkhtmltopdf` is a feature designed to
automatically reduce the font size of text in order to fit content
within the specified page width. We use this option to help prevent
content from overflowing the designated page boundaries.
However, it seems that "smart shrink" doesn't take into account the text
direction unless it is set on the `body` or `html` tag specifically.
opw-3472357
opw-3567655
opw-3520084
closesodoo/odoo#151049
X-original-commit: 210a529b0b43fe36f7f2e44363dfe039128f7f80
Related: odoo/enterprise#55107
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Steps to reproduce
------------------
* install `l10n_ph`
* switch to a Filipino company
* create a vendor bill with a line with no product and a tax that has a
"Philippines ATC" defined (ex: 5% WI010 - Prof Fees)
* attempt to generate the `BIR 2307 Report` through the action menu
You should be met with a traceback.
opw-3683037
closesodoo/odoo#150566
X-original-commit: c1ab55fd1e0eecb9848392995f91d994ad6d4d4c
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Steps to reproduce
------------------
* go create an invoice for a customer that has outstanding credits.
* in the blue message at the top, click the "outstanding credits" text
in bold.
You should see that you're taken to the home page. We expect to be taken
to the bottom of the invoice, where the outstanding credits are
displayed.
Cause
-----
A static HTML ID was mistaken for a variable in
d682871a8b.
opw-3691932
closesodoo/odoo#150153
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Currently, if you have Spanish POS installed and create a Cash In/Out,
you are met with an error.
Steps to reproduce
------------------
* install `l10n_es_pos`
* start a POS session
* click on the hamburger button in the top-right corner > Cash In/Out
* add any amount and confirm
You should be met with an error.
Fix
---
At first glance, the original condition:
```
partner?.id !== props.data.simplified_partner_id
```
and the revised condition:
```
partner && partner.id !== props.data.simplified_partner_id
```
might seem equivalent. However, they behave differently when `partner`
is `null` or `undefined`.
In the original condition, the optional chaining operator evaluates
to `undefined`, leading to the following `undefined !==
props.data.simplified_partner_id` (which is most likely true).
The revised condition will shorcircuit when `partner` is falsy, ensuring
that the code only executes when `partner` is a truthy object.
opw-3667287
closesodoo/odoo#148688
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Currently, when you attempt to uninstall an industry module, you are met
with a 'record not found' error.
Cause
-----
The list of industry modules is fetched from `odoo.com`. Since they do not
exist in the database, they are all assigned an ID of `-1`.
This ends up causing an issue in case of uninstall because no record
with and ID of `-1` can be found.
Fix
---
When a module is installed, it gets a record in the database (and ID).
The fix simply uses that ID if it exists, instead of `-1`.
opw-3662239
closesodoo/odoo#148456
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Summary
-------
Currently, when you send an invoice, every recipient receives the link
including the access token. Only the invoice's customer and manually
added recipients should receive the token.
Steps to reproduce
------------------
* Create and validate an invoice
* Add a follower `F `to the invoice
* Click on the Send & Print button, then add a recipient `R` who is not
the customer associated with the invoice
* Proceed to send the invoice.
* Access the emails that were sent
* Using an incognito or private browsing window, open the `View Invoice`
link for each of the 3 recipients.
You should see that all the links give access to the invoice.
What should happen is that only partner `R` and the invoice's customer
should haveaccess to the invoice.
`F` should be asked to login.
Cause
-----
Issue was introduced by 95c585f
Fix
---
Add a new notification group for partners that were manually added as
recipients, and give that group access to the invoice.
opw-3385302
closesodoo/odoo#146575
X-original-commit: 755814ea170adbade23692767fcb17b5422863e7
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Summary
-------
Currently, the 'Total amount of invoice in letters' setting doesn't do
anything on GCC invoices.
Steps to reproduce
------------------
* install `l10n_sa`
* enable the Arabic language
* in the settings, enable 'Total amount of invoice in letters'
* create and print an invoice
You should see that the amount in words in not displayed.
Note:
Currently, currency labels are not translatable. Since this isn't
something that can be changed in stable version, it was decided to not
include them in the Arabic amount in words.
opw-3501112
opw-3485691
closesodoo/odoo#146364
X-original-commit: 1fb28f229c701ae1261dc502ef345ffda162f994
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Currently, if you switch to a right-to-left language and open the POS,
the numpad will look like this:
3 2 1
6 5 4
9 8 7
The numpad should stay the same even in RTL languages:
1 2 3
4 5 6
7 8 9
opw-3623228
closesodoo/odoo#146181
X-original-commit: fb0ece3336f53cfba4e7ef9c59f4acbd292da45a
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Summary
-------
Foreign companies that trade with non-enterprises in the EU may have a
VATIN starting with "EU" instead of a country code. However, the tax ID
validation does not account for that.
Steps to reproduce
------------------
* install base_vat and contacts
* create a Canadian company with a tax with the format EU00000000
=> you should be met with a validation error.
opw-3551347
closesodoo/odoo#146049
X-original-commit: 6e11c34c660cecea7e8a0b56f7f8f3baba70b0c9
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Summary
-------
Currently, duplicating a journal results in the new journal's mail alias
name overwriting the original's.
Steps to reproduce
------------------
* install `account_accountant`
* duplicate the "Vendor Bills" journal
=> you should see that the alias name of the new journal overwrites the
alias of the original journal.
Cause
-----
When duplicating a journal, the new journal inherits the alias of the
original. Because of this, a specific code segment intended to generate
missing aliases for new sale/purchase journals, inadvertently modifies
the name of the alias.
opw-3597349
closesodoo/odoo#143771
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Summary
-------
Taxcloud taxes are always 0 on payment page.
Steps to reproduce
------------------
* install `website_sale_loyalty` and `website_sale_account_taxcloud`
* configure taxcloud
* enable 'Detect Automatically' on the 'Automatic Tax Mapping
(TaxCloud)' fiscal position
* go to ecommerce, and add a product to cart
* go to cart
* proceed to checkout
You should see that the taxes are still 0 on the payment page
Cause
-----
The issue comes from the `shop_payment()` override in
`website_sale_loyalty`. The taxcloud taxes are computed with
`res = super(WebsiteSale, self).shop_payment(**post)`,
but they are immediately cleared with
`order._update_programs_and_rewards()`
opw-3539027
closesodoo/odoo#144250
X-original-commit: 051470a16f3a76689eaeb6db57ac3d98a60c1f4d
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Currently, increasing the rounding factor for a currency is not allowed
if accounting entries have already been generated in that currency.
However, the restriction currently only applies to the current company.
And since currency records are shared between multiple companies, a user
can create a new company with no accounting entries and then change the
currency's rounding factor, affecting all companies.
This commit checks for the restriction on all companies, and fixes a few
tests that were broken by this change.
opw-3586785
closesodoo/odoo#144226
X-original-commit: 7f8b76ac7ad3730a662203aa88a03d067c1230cb
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Steps to reproduce
---------
* install the German localization
* create and print an invoice
You should see that the 'total' block and payment reference are not
correctly aligned
opw-3524254
closesodoo/odoo#143830
X-original-commit: da1de44392fb5ffe07bc5ee7244538d5a3056596
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Summary
-------
Currently, when `l10n_latam_check` is installed, third party checks'
number can be non-numeric.
Steps to reproduce
------------------
* install `l10n_latam_check`, and `l10n_ar`
* switch to an Argentinean company
* create and validate an invoice
* register a payment for that invoice using:
- Journal: Third Party Checks
- Check Number: anything that's not a number
The payment is created without issue, but it shouldn't. This ends up
causing tracebacks elsewhere because we expect the check number to only
contain digits.
Cause
-----
The `l10n_latam_check` module overrides `_constrains_check_number`, to
disable it on third party checks. The goal is to allow third party check
numbers to be non-unique. However, the code that checks whether the
`check_number` value only contains digits is in the same method. This
means that by skipping the uniqueness check, the code also skips the
value check.
Fix
---
This commit splits `_constrains_check_number` into two methods (one for
checking the value, and the other for uniqueness), and modifies
`l10n_latam_check` to override the uniqueness check only.
opw-3464012
closesodoo/odoo#141371
X-original-commit: 3e7b1f014af9b34473fe6eba07bc051b38a74c72
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Summary
-------
Currently, adding a CPF tax ID on a Brazilian contact always fails.
Steps to reproduce
------------------
* install `contacts` and `base_vat`
* create a new contact with country Brazil
* enter a valid CPF (ex: 11144477735)
You should be met with an error
Cause
-----
The CPF check is only implemented in `l10n_br`. Without this module, the
default vat check is applied, but it fails for CPF numbers.
Fix
---
Move the CPF/CNPJ check from `l10n_br` to `base_vat`
opw-3421476
closesodoo/odoo#139222
X-original-commit: 5dc5832f438006a9a4b9abeb1f093d7ed520c771
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Summary
------
Currently, when removing a product from an invoice line, the account for
that invoice line is automatically reset to a default value.
Steps to reproduce
------------------
* install `account_accountant`
* create an invoice and add a product
* set a different account on that invoice line
* remove the product from the line
You should see that the account is automatically changed.
opw-3092556
closesodoo/odoo#139361
X-original-commit: 39b44dbfef0d533722ce2c96d375ada113d32b00
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Summary
-------
This commit addresses an issue where fixed taxes were not calculated
correctly when applied to a line with a price of 0.
Steps to reproduce
------------------
1. Create a fixed tax with an amount of 5.
2. Create an invoice with a line having zero price and apply the fixed
tax.
3. Save the invoice. You should have a total of 5.
4. Change the quantity of the invoice line, to something like 2.
5. Save the invoice.
We expect the total to be 10, but we get 5.
opw-3212536
closesodoo/odoo#134762
X-original-commit: 2aafff6a36bd40719de9447a7ab9bf05274ff5d2
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Bug:
When printing DDT documents for a delivery with a pricelist applied, the
total value shown comes from the product's original price and not the
modified pricelist price.
Setup:
- install `sale_management` and `l10n_it_stock_ddt`
- have a product P with a price A
- create a pricelist that where P has a price B
Steps to reproduce:
- activate DDT report printing
- create a quotation set the pricelist you created and the product P
- validate the quotation
- go to the associated delivery and validate it
- print the DDT report
You should see that the price mentioned on the DDT report does not
account for the pricelist. (price A is shown, instead of B)
opw-3171295
closesodoo/odoo#134017
X-original-commit: 9bdb0ed25dcef3f651a65abf0c4a8d9ce4e27851
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
A customer has a gift card product linked to a specific income account.
When sold, the income account associated with the gift card product is
credited correctly. The issue arises when the gift card is consumed
within a sales order. An order line is added using a "dummy product" to
indicate the gift card's usage (one dummy product is created for each
loyalty program). Due to this, when an account move is created from the
sale order, the income account defined on the dummy product is used
instead of the one on the gift card product. This leads to the wrong
income account being debited, causing unbalanced accounting entries.
There's currently no way to link back to the original gift card product
from a `loyalty.card` record. Because of this, the system cannot
identify the correct income account to debit. Fixing this would require
adding a new field, which we can't do in stable.
A potential workaround is to find the dummy product and set the income
account to the same as the gift card product. However, with one dummy
product for each `loyalty.program`, all named "Gift Card", finding the
right dummy product is difficult.
This commit aims to simplify the workaround by adding a link to the
associated dummy product on the `loyalty.program` form view. This change
should ease the process of finding and modifying the correct dummy
product, thus mitigating the issue in the current stable version.
opw-3239720
opw-3373287
closesodoo/odoo#133461
X-original-commit: 767eccb122055cd9a474ce5110cb7296eb9ef4c2
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Steps to reproduce
------------------
* install l10n_de
* switch to a german company
* create an invoice
* add a line such that the account's default tax is different from the
tax set on the line (ex, account: `8400 Erlöse 19% USt` and
tax: `7% Umsatzsteuer`)
Attempt to confirm the invoice, you should see that you can't. The
system requires the account's default tax to be the same as the tax set
on the line. This should not be the case. It's a practice in Germany to
link a tax to an account like this, but it's not a legal requirement.
opw-3324323
closesodoo/odoo#131779
X-original-commit: 4de4a099296be150a8e75ffdbf1321cdee75137c
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
Summary
-------
Currently, the credit limit feature does not correctly take currencies
into account.
Steps to reproduce
------------------
* install `sale_managment`
* enable 'Sales Credit Limit' in the settings
* on a partner's form view, in the accounting tab, enable
`Partner Limit` and set a limit of 50
* have a currency `C` that's weaker than your company currency (we'll
call it `Q`). Let's say that here, `1 Q = 10 C`.
* have a price list in currency `C`
* create a quotation using the partner and price list mentioned above
* add a product with a price of 5, and no tax.
You should be met with a warning indicating that the customer has
reached his credit limit.
opw-3441361
closesodoo/odoo#130652
X-original-commit: f57653a6dcea04f0bca4e5ca73df3e1075e0fe98
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
Summary
-------
Currently, if you try to export FEC, download will work correctly, but
the UI will stay locked.
Steps to reproduce
------------------
* install l10n_fr_fec
* Accounting / Reporting / France FEC
* input a start/end date (ex: 01/01/2022 to 12/31/2022)
* click Generate
=> Report exports immediately, but the UI stays locked.
Cause
-----
This issue is caused by commit d291ef80b726c11486efe6e42d9dcf4968efa518
The intent is to make it so that if an `act_url` action with target
"self" is expected to reload the page, then the UI is blocked and
remains so, expecting the page reload to naturally unblock it. We
rely on the `beforeunload` event as a signal that the page is likely to
reload, usually followed by the `unload` event (actual reloading of the
page).
However, things are different when the new URL points to a file
download. Here, `beforeunload` is triggered, but not `unload`. As a
result, the `env.services.ui.unblock()` function isn't called, and since
the page doesn't reload, the UI stays blocked even after the download
starts.
opw-3344777
closesodoo/odoo#129918
X-original-commit: 23744ba3f992203e36dac59acfc905b018758e25
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
**Summary**
Currently, if you create a credit note/refund and reconcile it directly
with a statement line (without creating a payment), the
credit note/refund ends up in the "reversed" payment state, whereas it
should be "paid".
**Setup**
- Install `account_accountant`
**Steps to reproduce**
- create a credit note/refund and confirm it
- create the corresponding bank statement line
- reconcile those two
Go back to the credit/refund not, you should see that its payment state
is "reversed", instead of "paid".
opw-3328830
closesodoo/odoo#127027
X-original-commit: 2dd3fa7d4d367e38baf529fdde5d18caa2f238cf
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
Bug:
Currently, trying to import a fatturapa XML that has a document discount
doesn't do anything.
Setup:
- install l10n_it_edi and account_accountant
- have a fatturapa XML that has a document discount
Steps to reproduce:
- switch to the Italian company ()
- make sure that the VAT number on the document matches the one on the
company
- attempt to upload the XML bill
You should be met with an empty vendor bill page.
Cause:
The issue comes from here: https://github.com/odoo/odoo/blob/43c9820b1d3020d89b1b7ca016754e29d1fc6b58/addons/l10n_it_edi/models/account_edi_format.py#LL725C21-L729C83
in 16.0, `invoice_form` is not an instance of `Form`, but a record.
opw-3193634
closesodoo/odoo#123445
X-original-commit: 3443f2fbce36f800ebb5a87ce0d393dbcb30f2bc
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Séna Serge Nshimiyimana (sesn) <sesn@odoo.com>
When sending an invoice to a recipient who is not the customer, they are
unable to view the invoice in the customer portal and are prompted to
log in.
1. Create and validate an invoice
2. Click on the Send & Print button, then add a recipient who is not the
customer associated with the invoice.
3. Proceed to send the invoice.
4. Access the email that was sent to the added recipient (who is not the
customer)
5. Using an incognito or private browsing window, open the link
`View Invoice`
=> you should see that you are asked to log in, instead of being
directed to the customer portal.
opw-3114579
closesodoo/odoo#121954
X-original-commit: aabb2e624ef55661549381cea63e6460faa285c9
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Bug:
When the `sale_loyalty_taxcloud` is installed and 'Lock Confirmed Sales'
is enabled, confirming a SO impossible.
Setup:
- install `sale_management` and `sale_loyalty_taxcloud`
- activate Taxcloud (with test credentials)
- enable 'Lock Confirmed Sales' in the settings
Steps to reproduce:
- create a quotation, fill the necessary fields and add a product
- in the 'Other Info' tab, set the fiscal position to
'Automatic Tax Mapping (TaxCloud)'
- attempt to confirm the quotation
You should be met with a message stating that you can't modify the tax
on a locked order.
Cause:
This issue was introduced by odoo/enterprise@ea954b818b
Enterprise PR: odoo/enterprise#40880
opw-3289657
closesodoo/odoo#121410
X-original-commit: d676498902adf2dcd8fa4530fc21e84fb940aad2
Related: odoo/enterprise#41060
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@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>
# 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>
## 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>
# Steps to reproduce
- install l10n_mx_reports
- switch to a mexican company
- create a Vendor Bill, confirm it and register a payment for it
- create a Credit Note for that bill, confirm it and register a payment
too
- go to the DIOT report (called `Transactions with third parties
[ DIOT ]` in the menu )
The amount in the column "Refunds" should be the tax amount, and not the
base amount.
opw-3107102
Enterprise PR: odoo/enterprise#39628closesodoo/odoo#118887
X-original-commit: 8c9cde34ac1fb74a42997b0a1d847ae1c9bb1312
Related: odoo/enterprise#39929
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@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>
Bug:
Currently, creating an intra-community bill and reconciling it with an
early payment can break the tax report.
Steps to reproduce:
1. install the Austrian localization (l10n_at)
2. set `Cash Discount Tax Reduction` to `On early payment`
3. create a €1000 intra-community bill (you can just use the tax called
`IGE 20%`)
4. set the payment term to`2/7 Net 30` and confirm
5. reconcile the bill with a payment within the discount period
(2% discount: €980).
6. check the Tax Report: line 5.4 of the report should be €196. If you
reconciled the bill with a back statement directly, sections
`Innergemeinschaftliche Erwerb` and `Bemessungsgrundlage` will be
wrong as well.
Cause:
Since the intra-community applies here, the bill will produce two tax
lines. And because `Cash Discount Tax Reduction` is set to `On early
payment`, those two tax lines will be reduced when an early payment is
made.
However, because of the way the `is_refund` property of
`account.move.line` field is computed on moves of type `entry`, one of
those *tax reduction line* will be considered a refund and the other
will not. Furthermore, the computed tags are correct only because the taxes
are recomputed again when creating the payment.
After removing this extra taxes computation, both tax_tag_ids/tax_tag_invert
are invalid.
So the solution is to fix the method computing the taxes for cash discount lines.
Note: This commit also fixes the cash discount engine not working with multiple tax repartition lines since:
https://github.com/odoo/odoo/commit/9c134ec379819053e3fdd1e252e3a7ae8a949f42
opw-3112197
Enterprise PR: odoo/enterprise#39181closesodoo/odoo#118588
X-original-commit: de0db2429f7c47d52c1bad37b9d35d425c8d5b74
Related: odoo/enterprise#39775
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>
# Steps to reproduce
* install account_accountant, documents and l10n_it_edi
* Switch to an Italian company
* go to Documents > Configuration > Workspaces and create a new
workspace `W` and it's child `W1`
* under Documents > Settings, activate Accounting and set `Workspace`to
`W`
* save and go back to Documents > Settings, and click `Journals` under
'Accounting'
* add a line with Journals = 'Vendor Bills' and Workspace = `W1`
* go to Accounting > Vendor > Bills and upload a Fattura PA XML bill
* now open the newly generated bill
You should see that the chatter does not load.
# Cause
When uploading a Fattura PA XML bill, a PDF attachment is created and
added to the chatter. The issue is happening because the
`ir.attachment` record ends up in an invalid state where its 'res_model'
field is false.
The 'res_model' field is actually defined when the attachment is
initially created. However, that value ends up being overwritten when a
related `documents.document` is created here: https://github.com/odoo/enterprise/blob/3f53e50989fbb9551565429aede7c0a1e4d6e5a4/documents_account/models/account_move.py#L88
Because of the following line, that `documents.document` will be
assigned a default `res_id` (but no `res_model`).
https://github.com/odoo/odoo/blob/26b2cbd4e5c73ea66456a91ea9cb36d6b174cae7/addons/l10n_it_edi/models/account_edi_format.py#L767
However, setting `res_id` (or `res_model`) on a `documents.document`
will also overwrite the related attachments' values (in this case, the
attachment's `res_model` is set to false because the document's
`res_model` is false).
This behavior happens because of this inverse compute: https://github.com/odoo/enterprise/blob/b4201e6b422e5b0bde1f04db37bcda4941d0665f/documents/models/document.py#L97-L104
opw-3119669
closesodoo/odoo#113299
X-original-commit: 6839abc79a947e30750ec535058828c190c18955
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
# Steps to reproduce
* Have Arabic language installed
* Create an invoice
* Register a partial payment (keep invoice open)
* Switch to Arabic language
* Click the register payment again
=> You should be met with a traceback
# Cause
Currently, the `parseDate` function relies on `parseDateTime`. If no
format is passed to `parseDateTime` (like in our case), the user's
`localization.dateTimeFormat` is used. `parseDateTime` implements
workarounds to allow parsing of dates (without a time).
However, those workarounds do not work with languages such as Arabic.
opw-3133992
closesodoo/odoo#112354
X-original-commit: 869b01da4948775d9a3009426a74cc9207e81374
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>
Co-authored-by: huvw <huvw@odoo.com>
## Steps to reproduce
- install l10n_gcc_invoice module
- switch to a company in Saudi Arabia (SA company)
- create and print an invoice that has a payment term with a translated
note
We expect the payment term's note to be displayed both in English and
Arabic. But instead, the note is displayed twice in the customer's
preferred language.
## Cause
`t-field` does not use the context defined on the field itself. It uses
the rendering context.
opw-3101387
closesodoo/odoo#109330
X-original-commit: 8a3049a63c7e9b13892278784781a793f8e0ab4f
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
# Steps to reproduce
* install eCommerce and Sales
* go to settings and activate `Discounts`, `Pricelists` and
set `Display Product Prices` to `Tax Included`.
* create a pricelist with a discount, making sure to set (in the
configuration tab):
* `Discount Policy` to `Show public price & discount to the customer`
* `Selectable` to `true`
* go to a product's page, select the pricelist you made and add the product
to the cart.
* go to the shopping cart
# The Issue
On the shopping cart page, the pre-discount price should be tax-included
,but it is not.
opw-3112462
closesodoo/odoo#108935
X-original-commit: f4095614e8a875d66efbbb8c579c73c52b8a1c1c
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
## Steps to reproduce
* Using Firefox, Go to Accounting > Invoices > create a new invoice.
* Add a line to the invoice and remove the label.
You should see that there's no indication that the label field is
required. (It works well in Chrome)
## Cause
This is happening because the table borders (that become red when a
field fails validation) are not displayed in Firefox.
opw-3040299
closesodoo/odoo#107564
X-original-commit: 74726c649fa5bddec30573c18acd11020302d093
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
## Steps to reproduce
1. navigate to Settings -> CRM -> Lead Enrichment section
2. change the Lead Enrichment option to "Enrich leads on demand only"
3. click Save button
4. wait for system to save and refresh.
You should see that the change you made was not saved.
opw-3063639
closesodoo/odoo#106891
X-original-commit: 0803775e4a156aa6988453edbbaf799730c996b2
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
### Steps to reproduce
* Enable Dev mode
* Open an email template
* Open Code View of the template
* Click the green button in the top right corner of the content box
You should be met with a traceback.
opw-3045759
closesodoo/odoo#106408
X-original-commit: 01fb9cab941d9055efbeac738490fe53a91ceccf
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Steps to reproduce:
- Activate debug mode
- Go to Sales and open a quotation (actually any form view from any
module will do)
- Start Studio
- Select the "Confirm" button (or any of the top buttons)
- Check the "Set approval rules" box
- Edit the domain by clicking the 'filter' icon next to the 'trash' icon
- Add a condition. You can just keep the default one.
- Click save to save the domain.
- Again, click on the 'filter' icon.
You should see that the domain in the text editor is malformed.
Furthermore, should you change the domain in the text editor (let's say,
change 1 to 2) and hit save, an error message will pop saying the domain
is not properly formatted.
opw-3001622
closesodoo/odoo#106043
X-original-commit: 9535026e00ca07453863d13d68935732cac49bfe
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
### Steps to reproduce
* install the *VAT Number Validation `(base_vat)`* and Contacts module.
* Create a new contact from San Marino and set their Tax Id to SM05426
* Save the contact
You should see that the leading zeros have been removed on the Tax Id
(here, SM05426 became SM5426)
opw-3007722
closesodoo/odoo#105830
X-original-commit: 24207914e9dae4b5f7e100245d4efe964f639415
Signed-off-by: Josse Colpaert <jco@odoo.com>
### Steps to reproduce
* install Live Chat (`im_livechat`)
* Go to Live Chat > click any channel
* Under Widget, Click the copy button for the first link
If you're on firefox, nothing will happen (text won't be copied).
On chrome, you will get a traceback saying `Failed to execute 'write' on
'Clipboard'`.
### Expected behavior
The text should be copied to the clipboard, and a tooltip should appear
to confirm that.
opw-3058357
closesodoo/odoo#105756
X-original-commit: 977f5aacf46c3746380dda33585b407df659e07d
Signed-off-by: Luca Vitali <luvi@odoo.com>
### Steps to reproduce
* install `website_sale` (eCommerce)
* go to any product's form view
* in the 'Sales' tab, click `ADD A MEDIA`
* fill the 'Video URL' field and save
You should be met with a traceback saying that the template
`website_sale.FieldVideoPreview` is missing.
opw-3057118
closesodoo/odoo#105755
X-original-commit: 9cbb0ab0bafa4e05673862d601a7b089bbd2b519
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>
### 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
closesodoo/odoo#105445
X-original-commit: b69fc397aad019cc18bd00975d38dde9ffcc985b
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
BUE
Steps to reproduce
- go to Apps, switch to studio and create and create a new app.
- on the form view, add a Many2one field related to 'Sales Order'.
- add a Ralated Field, related to 'Sales Order > Total'. You will be
presented with a prompt informing you that you need a currency field
on the model. Click 'OK' to add the currency field.
- again, add a Ralated Field, related to 'Sales Order > Total'.
- close Studio, fill the form you just created and save.
- switch back to studio and, again, add a Ralated Field, related to
'Sales Order > Total'.
You will be met with a traceback.
FIX
Actually defining a currency field on currency fields is mandatory. We
don't have to provide a fallback, hence we don't have to fix the fallback.
Simply remove it.
Task-3012648
opw-2951697
Closesodoo/odoo#94831Closesodoo/odoo#94962closesodoo/odoo#102918
X-original-commit: 899f3b4897f34576d502cf442ab7059c489870dd
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Steps to reproduce:
* setup Alipay in test mode (note that Alipay's test node only support
one currency: the USD)
* create an invoice. Make sure the invoice's total has decimal places
* generate a payment link for that invoice
* go to the generated link
* select Alipay as the payment method and click pay.
You should be met with an INVALID_PARAMETER message.
Cause:
Alipay's doc states that the parameter 'total_fee' can only have two
decimal places. Currently, this requirement is not always respected
opw-2996278
closesodoo/odoo#102088
X-original-commit: 2e6e338e8c4e042a671814673c6f3d0e4e4f50dc
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Currently, when creating an invoice from factur_x XML, the vendor is
identified by sequentially checking (in this order) the following
information :
- VAT number
- name
- email
However, when we generate a factur_x XML, we do not include
the partner's email address. This means that in some cases, two odoo
databases are not able to communicate bills/invoices properly.
This commit brings back a behavior that was unintentionally removed in
https://github.com/odoo/odoo/commit/d25fdafcd8eb4cfef14c2ef7ed8ad7785dd01b55
opw-2909408
closesodoo/odoo#99263
X-original-commit: 51609d19177c080835116f0ad9c04c33536d926a
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Steps to reproduce:
- Create a sale order with a product that's invoiced on delivered
quantities.
- Set delivered quantity (partial delivery) and create an invoice based
on the delivered quantity. Set the "Invoice Date" to sometime in the
past.
- Go to the settings and set "Invoicing Switch Threshold" to any date
in the future (so that the invoice you created has a date BEFORE the
new threshold)
- The invoice will get the label "invoicing app legacy".
- Go back to the sales order and change the delivered quantity.
You should see that the invoiced quantity is automatically set to 0.
A similar behavior can be observed with purchase orders.
Why this is happening:
When a new “Invoicing Switch Threshold” is set, all posted invoices
before the threshold are marked as `canceled`. In v15, changing the
delivered quantities triggers the invoiced quantities to be
recalculated as well. However, computing invoiced quantities doesn't
take into account invoices that are marked as `canceled`. This mean
that the newly computed invoiced quantities won't include invoices
posted before threshold.
opw-2896797
closesodoo/odoo#98909
X-original-commit: cc979734bd7ef3f2a94b411cb7b4f3e782b7ddab
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
This PR adds the 'posted' filter by default on the journal items list
view, when coming from an account's form view.
opw-2896728
closesodoo/odoo#99012
X-original-commit: c976a0920dd8d7910c7635cc1e2bbff47edcafa9
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Currently, computing an account's current balance takes canceled and
draft invoices into account. Only posted invoices should be considered.
opw-2896728
closesodoo/odoo#98843
X-original-commit: d3a7115feab9ca1bd8372f4450d3abc3eb52cdb0
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
The URL to the Spanish tax agency Agencia Tributaria's test server was
changed. The one currently used does not exist anymore. This causes an
error when trying to access the server.
opw-2888531
closesodoo/odoo#98114
X-original-commit: 2d8407b0dae262199c1bea3a3437e1175f76a630
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Steps to reproduce:
- Create a quotation
- Add a product that is invoiced on "ordered quantities" and set the
quantity to a negative number.
- Leave 'delivered' to 0
- Confirm the quotation
- Create the Invoice and validate it.
- Go to the SO list view (Orders > Orders)
You should see that the Invoice Status of the order you just created is
'Upselling Opportunity', which is not correct.
Why this is happening:
Here's an explanation on the 'Upselling Opportunity' state (found in
the code):
" upselling: this is possible only for a product invoiced on ordered
quantities for which *we delivered more than expected.* "
In our case, the invoice line's state is set to 'upselling'
because we have a negative ordered quantity and a zero delivered
quantity (i.e. we delivered more than expected)
opw-2895218
closesodoo/odoo#97830
X-original-commit: 5f10583336bf39430a304e2c47dfd0310ee4fa3d
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Steps to reproduce:
- switch to any language other than English
- go to a page where you can use the text editor,
for instance you can try to edit a project's description.
- type `/` in the editor
You should see that some commands are not translated.
Some files modified in this commit are located in the
web_editor/static/lib/web-editor directory.
However, only the JS code located into /static/src/ is considered for
export of translations. This is done to avoid polluting translations for
code not managed by Odoo.
We have to update the .pot file manually. A good workaround is to copy
the web-editor folder inside to static/src, export the
translations and then delete the copy folder.
However, this means that those updates to the .pot file will be lost in
the next translation export.
opw-2918128
closesodoo/odoo#96939
X-original-commit: 0cc5505b27f29d44c25af83653b09b1b49cfec79
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Steps to reproduce:
- go to Inventory > Operations > Inventory Adjustments
- Select at least one product
- Click on Request a count; A dialog box containing a form should appear
- Select a user other than the current user
- Make sure to check "Set Current Value"
- Click "Confirm"
You should see that the user you selected is not the one assigned for
the count. Instead, the count is assigned to the current user.
This is happening because currently, calling
`action_set_inventory_quantity` also sets the user as the current one
if the quantity is not already set.
opw-2924694
closesodoo/odoo#96914
X-original-commit: f2b79bc4c6198aacca33eea8905fd62c629706a1
Signed-off-by: Tiffany Chang <tic@odoo.com>
Currently, two lost buttons will appear, if you go to the form view of a lead that has 100% probability. The difference between the two duplicated "Lost" buttons is that one ask for a "lost reason" before marking a lead/opportunity as lost, the other does not.
After discussing with the PO for CRM, it appears that the button that asks for a "lost reason" should not appear on a lead. This commit makes the necessary changes to reflect that behavior.
opw-2886623
closesodoo/odoo#96486
X-original-commit: 707bddefdc5604db3304afa3633a0b90027f78b4
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Nshimiyimana Serge Séna (sesn) <sesn@odoo.com>
Currently, if you try to create an opportunity through the smart button on a contact form, a lead is created.
A lead created from a customer should be an opportunity.
opw-2886623
closesodoo/odoo#96268
X-original-commit: 415c8393f25ab47da45d15ebc455660bfa440389
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
sesn-odoo