The Python constraint method `_check_unique_sequence_number` performs an
SQL query, and therefore needs to `flush()` the some fields before doing
so. However, it uses a generic call to `flush()`. In some situations,
the call to `flush()` ends up into recursive flushing, and that's the
beginning of a nightmare:
- write on account.move.state,
- which calls account.move._check_unique_sequence_number(),
- which calls flush(),
- which computes purchase.order.line.qty_invoiced,
- which reads field purchase.order.line.invoice_lines,
- which calls flush() for account.move.line.move_name,
- which computes account.move.line.move_name,
- which computes account.move.name,
- which calls account.move._check_unique_sequence_number(),
- which calls flush(),
- which computes purchase.order.invoice_status,
- which uses the not-yet-computed value of purchase.order.line.qty_invoiced,
and computes an incorrect value.
We fix it simply by making the call to `flush()` more specific: we only
need to flush 4 fields. This avoids the nightmare above.
X-original-commit: cf5f50a733ddfd87985a39ffe7daffc48cfb582f
This commits adds kanban view for the 'Generated Documents' for better
readability on mobile devices. Also, for consistency, this commit
adds 'Upload' button on the invoice kanban view as well.
Task-ID: 2152183
Before this commit, there was no difference whether multiple invoices
were uploaded or not. The list view was always opened.
Now, the form view is automatically opened when a single bill
is uploaded.
Task-ID: 2152183
As the price_unit and the uom rounding can be more detailed than the currency/accounting rounding (2 decimals as a standard) to cut the number before subtotal is wrong.
closesodoo/odoo#63817
X-original-commit: 1b4005f50ac45b53a73e0b95cfb661e8ccf040cd
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
When deleting an `account_reconcile_model`, it does not delete the
corresponding `account_reconcile_model_line`. Moreover, this may prevent
the user from using the l10n_de_skr04 module.
To reproduce the error:
(Use demo data)
1. Go to Apps
2. Install "Germany SKR04 - Accounting"
3. Change the company
- Select "DE03 Company"
4. Go to Settings > Invoicing > Fiscal Localization
5. Change the package
- Select "Deutscher Kontenplan SKR04"
6. Save
=> A validation error is displayed: "The operation cannot be completed:
another model requires the record being deleted[...]".
When changing for SKR04, the module's installation first deletes some
models, among them: `account_reconcile_model` and later `account_tax`. The
validation error appears on `account_tax` deletion. Since version 14, an
`account_reconcile_model` is composed of `account_reconcile_model_line`
and the latter is linked to `account_tax` (with `ondelete='restrict'`).
Here is the issue: when deleting the `account_reconcile_model` model,
the corresponding lines are not deleted. As a result: later, when trying
to delete all the `account_tax`, since some `account_reconcile_model_line`
are still present in database, it triggers the `ondelete='restrict'`
constraint.
OPW-2416066
closesodoo/odoo#63649
X-original-commit: 8c9a038c6527f06b680d6346ba5569fedce4794d
Signed-off-by: adwid <adwid@users.noreply.github.com>
Using group of taxes with type_tax_use='none' children messed up the sign of the tax_base_amount and line tags.
closesodoo/odoo#63479
X-original-commit: 3642c429899c4d5def27c9ba10ae76c763a8a566
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before that, using an auto-validate reconciliation model to match an invoice with a statement line with a lesser amount resulted in the creation of an payment entry with which the invoice got fully reconciled, and the difference amount was fowarded to the suspsense account in an additional line. This wasn't correct, as we expect the invoice to be only partially paid in that case (with an amount equal to the statement line's).
closesodoo/odoo#63303
X-original-commit: 7393aa3ebcea7b80762b729315f1c890bc677efb
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Field's help doesn't match with field's Usage.
closesodoo/odoo#63249
X-original-commit: a48ba4672e90a7e9f3143de5ede0099a8e28d4cd
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
If you have a move line which was having tag_ids before and you apply a new tax
which has no values defined and result in an empty list, the assignment does not work on a x2m field,
so we do offer the proper notation for such a use case.
Closes#62934closesodoo/odoo#63176
X-original-commit: f7cbbe381950699f2aeb26c454a4a955ed3bf2b4
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
This case shouldn't appear in a normal usage of the statement lines because there is no way to cancel them.
However, this case should be supported in 14.0 due to a choice we made for the migration.
Indeed, we don't want to create draft journal entries in a locked period during the migration but the statement lines that are not reconciled in a locked period shouldn't be deleted in order to keep the statement starting/ending balance consistency.
So, the journal entries created in a locked period for not reconciled statement lines are cancelled and then, we don't want to block the locking of any period because of that.
closesodoo/odoo#63104
X-original-commit: b5e186124de69061e91f657e1a330ba019614256
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Previously, the check to see if a statement ending balance is the same as the computed balance was only done when moving from draft to posted which is wrong as people can modify the balance of posted statement programmatically which is the case when using online synchronization for example. Now perform that check at each change of state: draft->posted and posted->processed. Also the indication in the view to indicate that the balance was not the same was only displayed in draft, we removed that constraints as user should always see if there is a problem.
closesodoo/odoo#62879
X-original-commit: 69fc9b71e991983b5bcddc948ac4c3749e305a3f
Related: odoo/enterprise#15155
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Signed-off-by: Florian Gilbert <FlorianGilbert@users.noreply.github.com>
With this commit, all instances of errors being raised inside
`BaseModel.unlink` overrides are moved into methods decorated with
`api.ondelete` which is safer.
After a migration, if the payment is using the bank account instead of the oustanding one, we shouldn't block the user in any case when checking the payment consistency.
For example, when writing the matching number on a journal item will trigger the check consistency on the payment. So, you are unable to reconcile any journal items until you replace the account by the outstanding.
closesodoo/odoo#62842
X-original-commit: 28bc59e794f15bf4f7de31e24f496e707ba639dc
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Issue
- Install 'Accounting' module
- Create a new 'Tax' X with a fixed price (e.g.: O.O57 $)
- Create a new 'Customer Invoice'
- Add a product P and set unit price to 0 $
- Set tax X to product P
Total tax amount : - 0.06 $ .
Solution
The sign must be forced to a negative sign in case the balance is on credit
to avoid negatif taxes amount.
enterprise PR : https://github.com/odoo/enterprise/pull/15035
opw-2378978
closesodoo/odoo#62758
X-original-commit: 684855529e8aaafa0cb90f958d19c563d6e2a897
Related: odoo/enterprise#15105
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
The sign of tax tags sometimes could get inverted explicitly. It typically happened for misc operations, so :
- manual entries
- CABA entries
- writeoffs created from the reconciliation widget
We had to do things this way in stable to fix those use cases, but it's not ideal, as the tags shown to the user were inverted, so it was a bit confusing, as one would have expected to see the exact same tags as on tax configuration.
We fix that by using a boolean field on account.move.line telling whether or not the sign must be inverted. This allows keeping the same tags as in the tax config, and simplifies the computation of the tax report's multiplicator, making the overall model more intuitive for both user and developper.
Task 2363287
closesodoo/odoo#62536
Related: odoo/enterprise#15031
Related: odoo/upgrade#1983
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Activate Anglo-Saxon accounting
- Set a foreign currency rate to 2.0
- Create a product A:
Inventory Valuation: 'Automated'
Costing Method: 'Standard Price'
Cost: 10.0
Public Price: 100.0
- Create an invoice in foreign currency
- Add 1 unit of A => the total amount is 200.0
- Confirm the invoice
The Amount Due is 100.0 instead of 200.0.
This happens because the Anglo-Saxon lines have the company currency,
while the other lines have the foreign currency. Because of this, the
`_compute_amount` method considers the move as multi-currency to compute
the various amount. However, the Anglo-Saxon lines should be neglected.
This happens from 14.0 because all lines have a currency. In previous
versions, lines in the company currency didn't have the `currency_id`
set.
opw-2390107
closesodoo/odoo#62657
X-original-commit: 9e1aec7873a935b287b4b3c5dbc2688acee5422a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Databases that already have issues are not able to fix the issues
because it is impossible to reset the items to draft in order to change
the date/sequence. Or do anything else, really.
By allowing to bypass the constraint before a certain date, users can
now edit problematic documents.
Disabling the constraint will however make it possible to entirely
break the sequences; use it with the lowest possible date.
closesodoo/odoo#62663
X-original-commit: a35d7e646d7ac419d09d5f97b2886eddc9dee0e0
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
In 13.0, create a statement line and process it by creating a custom journal item in any reconcile account.
At this point, a journal entry has been created and is linked to both a payment and a statement line.
Migrate to 14.0.
Now, try to reconcile manually the custom journal item with anything. Because the matching number is written on the line, it triggers the synchronization between the payment and the entry but it fails because the manual entry doesn't really look a valid payment.
closesodoo/odoo#62621
X-original-commit: 962195d85aa1f2fedb0647a5cd454740c1322281
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
In order to avoid eventual futur issues, this PR add a filter on the
journal field of journal entries to only allow selecting misc journals
task id #2371198closesodoo/odoo#62331
X-original-commit: 1b273d4c11e3e8d8583de302b71b2522a71f4d1d
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Reproduce:
* On a fresh db, create a payment
* Change the date to another month
* Validate
Issue:
* The name is computed before creation because it is the first of
journal/period.
* It is not visible
* It is given to the create vals of the move_id, so it is not correctly
recomputed
* The sequence/name are not in sync.
opw-2390747
closesodoo/odoo#62554
X-original-commit: 3a8247f603a02a05173ef917f9f07189ff5e01db
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
1) forbid deletion of main uoms & categories
2) warn modifications of main uoms data.
Except for the working Hours uom, which isn't a strict UoM
representation and could change between countries (and/or be deleted).
3) Also move the Dozen UoM to demo datas, it's a confusing UoM and isn't
used by the majority of databases.
4) Restrict deletion of used uoms on main models.
On sale orders and account moves the uoms couldn't be deleted thanks to the
SQL constraint covering the display_type logic, but the generic error message
is more clear for a user when deleting an uom.
Fiscal positions shouldn't be deleted if used by existing account moves
closesodoo/odoo#62443
X-original-commit: 6b2d0faf170f7b5061f5facbaa3818e529a2de4c
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
when a Vendor bill in an inactive currency is created (via an an EDI or the OCR,
or when the user create the invoice in an active foreign currency, then desactivate it)
it should not be possible to validate it.
Task ID: #2289537closesodoo/odoo#54096
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The partner is not visible in the form so copying can lead to unwanted
behaviours.
Task 2389917
opw-2388430
closesodoo/odoo#62276
X-original-commit: ef1b3332a523f0afdb954f8eb2abb8f442bdca58
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
- Install Invoicing
- Go to Invoicing > Configuration > Taxes
- Create a Tax 0% with its own tax group
- Go to Invoicing > Customers > Invoices
- Create an Invoice with a line having a normal Tax and several lines with Tax 0%
- Confirm and print Invoice
On the Subtotal section of the printed invoice, for the label of the Tax Group of Tax 0%,
only the amount of the first line having this tax is shown.
(i.e. "Tax 0% on $ XXX", where XXX should be the sum of all lines on which Tax 0% is applied)
opw-2381051
closesodoo/odoo#62106
X-original-commit: 9e244ae3053f46fc22b8e9a75015d57cd70053b8
Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>
This part of the tour can't work with the new online synchronization
module (account_online_synchronization) due to the fact that we are
using an iframe to display the list of institutions and therefore
those steps won't work within the iframe.
Also remove account_plaid & account_yodlee from _auto_install_l10n as
those modules don't exists anymore.
closesodoo/odoo#50267
Related: odoo/upgrade#1780
Related: odoo/enterprise#8200
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
- Install accounting app
- Go to "Charts of Accounts" view by setup panel
- Create a new record
A traceback occurs because `self.ids` is empty in the context of the
creation of a new record.
opw-2379463
closesodoo/odoo#62014
X-original-commit: b325266bc9d3893e037b3fd8d734ac7d3d510c41
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
To reproduce the error:
1. Invoicing > Reconciliation Models > Create
2. Add name
3. (Counterpart Values) Add a line
- Amount Type: Percentage of balance
- Amount: Something bigger than 100
4. Save
=> UserError raised ("The amount is not a percentage")
This is an error. A user should be able to set a percentage greater than 100.
The fix removes the constraint.
OPW-2375462
closesodoo/odoo#62010
X-original-commit: 2776209ba9a437c413dd5670c1695a06da909a5a
Signed-off-by: adwid <adwid@users.noreply.github.com>
Before this fix, the prefix was detected as `045-0` and the year as `1`
instead of no year with prefix `045-001`.
opw-2381351
closesodoo/odoo#61931
X-original-commit: e1b4521e82af1c865d69e9e0cf637713d0b94480
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
When displaying a QR-code on the account.payment form view, we now pass its communication as both structured and unstructured communication, letting the QR-code generator parse it needed. This allows supporting QR-IBANs and QRR communications for Swiss QR-codes.
closesodoo/odoo#61891
X-original-commit: de6e81337d168ef296f7b0aa46aedbea1ea7a82d
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this commit, if a customer/supplier has an invoice address, when
creating an invoice/bill it's the invoice address that will be
identified as the customer/supplier and that will have its rank
increased and not the commercial partner.
Now, the rank increment is done to the commercial partner as well.
opw-2377870
closesodoo/odoo#61778
X-original-commit: dbf042611ccb134a220704d6b775aab650364ca2
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The open_action_with_context was not using _for_xml_id, producing an
error when reading the action content.
In open_action, the action_name was taken from the context and needs
sanity checks. Ensure only actions from the account module can be
read and only if the user has access to the target model.
This is a limitation of the previous behaviour but, at the moment, all
known calls are made refering to an action from the account module.
Limit the scope of this method while the 14.0 is still early to avoid
having a door open to ready any action, and difficult to close later.
Remove old action fetching from the context in create_move that is no
longer used.
closesodoo/odoo#61602
X-original-commit: a39e94f7e4dc74e850650ac90bbc5f85af130bc8
Related: odoo/enterprise#14695
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Co-authored-by: Xavier Morel <xmo@odoo.com>
Create a tax as follows:
* Tax Computation: Percentage of Price Tax Included
* Tax Scope: Purchase
* Amount: 100%
* Included in Price
* Affect Base of Subsequent Taxes
Create a vendor bill with the tax on the line
Change unit price
The total does not change
This occur because when having 100% tax debit/credit are unchanged.
So the onchange `_onchange_mark_recompute_taxes` is not triggered and
the tax lines are not updated, thus not changing the
total (as in this case the invoice total is just the tax value)
opw-2370861
closesodoo/odoo#61555
X-original-commit: 9e203cc016b45875f699ffab24fe3f8382a97303
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
A cash rounding precision must be strictly larger than zero to follow
the restriction introduced in e270e9e0cc.
opw-2341804
closesodoo/odoo#61382
X-original-commit: 563752358d233d4fc9cf1d7e7abd0b1656dc82c1
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
We extract the `price_unit` and `tax_ids` recomputation logic from the
`_onchange_product_id` method. This way, it can be called
programmatically.
opw-2371934
closesodoo/odoo#61477
X-original-commit: ca6f25bef45137c032bc5cafd336c3f16a97a929
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The order to find when to reset the sequence needs to be the following:
* find a sequence used before the date of this move
* if there isn't any, find the sequence of any move
Because we were not looking at the second step for bank statements, we
could have an issue since we were not checking the sequence relative to
the correct date.
closesodoo/odoo#61495
X-original-commit: b863b9cfedb3e7b4d1e3d409c829ffa0bfa1d9bb
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
We need to ensure the name stays consitent with the journal_id and the
date when we try to change one of those fields.
X-original-commit: 634aaeeac36d2371743338536466a0bcc9ad6c69
Steps to reproduce:
- Let's consider a camt file F with Stmt Id > 2147483647
- Import F
Bug:
An index out of range was raised because range of an integer type in postgresql must be
in [-2147483648, 2147483647]
opw:2372401
closesodoo/odoo#61391
X-original-commit: 953d3069fb77605a8d69f80124d011144595d459
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Raphael Collet