A former constraint made it impossible to import bank statements with lines = 0.
The task #2403369 removed that constraint.
But the user could no longer reconcile Bank Statement Lines = 0.
Drawbacks :
- The user is then blocked when setting a lock date.
- The bank statement remains endlessly in Status Processing
A previous fix made a bank statement line = 0 immediately reconciled.
Closes task #2449127.
closesodoo/odoo#65359
X-original-commit: ee4f7df8d34593bdde3fc6f9bd062f6dad238fcb
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Increase the distinction between a journal entry linked to a bank
statement line and another one linked to a payment by adding a smart
button linked to them.
Also improve the navigation from the Bank And Cash view to directly
open the linked bank statement line or payment.
Task id #2448618closesodoo/odoo#65316
Signed-off-by: William André (wan) <wan@odoo.com>
When the suspense account is not reconcilable, 'suspense_lines.reconciled' always gives 'False' leading to a not reconciled statement line.
closesodoo/odoo#65290
X-original-commit: 73ddcfbcc58b7a6542ced4bd8b20dd67c9f446ee
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Steps to reproduce the bug:
- Go to Accounting (module)> Accounting (menu) > Journal Entries
- Create a new account move M
- Remove the default journal
Bug:
Impossible to set a journal
opw:2445553
closesodoo/odoo#65200
X-original-commit: cd1823a1066dd9a820afed8427e3a9abc2faade0
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
commit 31e1322b40 is allowing the
customer to increase is decimal accuracy for currency without
consequences but triggering issue upon lowering it if entries
already exist.
+ Remove the redirection to the support.
Let's ensure that the behavior is consistent and the users are
warned on first modification. To do so, adding an alert msg
in addition of the blocking message in case of lowering the decimal
accuracy after already creating accounting entries.
opw-2428857
closesodoo/odoo#64757
X-original-commit: 66533ebd88ed89c3baae6fdb1d0a28a458fa0cb9
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
In 13.0, some account.move.line fields (amount_currency, debit, credit
and account_id) couldn't have a value when the line is of type 'note'.
Skiping them during line copy for notes is not an issue.
During 12.0->13.0 migration, we were facing issues with "grouped similar
invoice lines in a single move line", because this feature is not
available anymore in 13.0. To avoid any "loss of data" during migration,
we used lines of type note to create "missing" invoice lines in move
lines without altering accounting in any way. As a consequence, we have
13.0 databases with lines of type note having values for fields who
couldn't have ones.
closesodoo/odoo#64962
X-original-commit: 677edafeaf8d691764178f5e7e9639017b0249a8
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
To fully allow f4e67d8ae174d7e2ee75a1de1083b31a6ff2af8b
we need also to disable to check on account when
the constraint field has been used to set the account on
the journal
opw-2394959
closesodoo/odoo#64792
X-original-commit: 655597e9a3637abbaeffddcc78663e8733070db4
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Issue
- Install "Accounting" module
- Create a new bill :
- Set vendor
- Set no payment reference
- Set a bill reference
- Add products to bill
- Confirm and click on Register Payment
Memo field has no value.
Cause
The memo field is based on lines name.
Lines name is computed in `_onchange_payment_reference`
and depends only on payment_referecence.
Solution
If no `payment_reference`, fallback on `ref` to set line name.
opw-2440389
closesodoo/odoo#64692
X-original-commit: 31bc04afc3ed4ea74cd20f71ea10943b1026629c
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
WHY: it's computed field that is not supposed to be editable. In previous task
it was asked to make it visible, not editable.
closesodoo/odoo#64676
X-original-commit: f7788fdf03bcf81710f5b01fbf67a90aa30e1e58
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
When reconciling a statement line with multiple lines in a multi-currency environment, it could lead to a rounding issue due to the currency rates. It could lead to an auto-generated open-balance of 0.01 amount to auto-balance the journal entry but the result is wrong since the partner has an open amount left on the receivable/payable account.
closesodoo/odoo#64636
X-original-commit: 4d4e6e588d14742f153a1c6b67d510e0c21e5d64
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
This use case can happen in case an invoice is imported without recreating all the taxes, only keeping the VAT information.
closesodoo/odoo#64638
X-original-commit: 7ad61842c703ceb031b2f917ad8bbc26d7d0b780
Signed-off-by: Laurent Smet <smetl@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
closes#62536closesodoo/odoo#64627
Related: odoo/enterprise#15031
Related: odoo/upgrade#1983
X-original-commit: 4e8581b6846ef8ee4601c994b0d586734a4fe117
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
- keep track of to_check changes in chatter
- add "set as checked" button
- make the "to_check" field optional in list view
- vendor bill / customer invoice : remove "entry" from "cancel entry" button.
Task: 2389849
When posting an account move before the tax lock date, Odoo will
automatically set its accounting date to the lock date + 1.
This can cause the chronology to be broken, which is not something we
want when automatically setting the date.
This will change that behavior to set the accounting date to today in
such case.
Task id #2411150closesodoo/odoo#62787
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When the name of a partner contains a regular expression operator, such
as grouping parenthesis, +, *, brackets... the resulting regexp may
match wrong names or worse be invalid and lead to an exception.
With this commit, we create a regular expression from only the words
formed from at least 3 of [a-zA-Z0-9], ignoring all other characters,
including those who may have a meaning in a regular expression.
This avoids these issues:
- regexp injection (security issue)
- punctuation resulting in erroneous regular expression ("ABC + SPRL"
resulted in "(?=.*ABC.*)(?=.*+.*)(?=.*SPRL.*)" which is invalid at
the ".*+" part)
- false positives due to words that are too small (\b were added, and
the minimal matching word size is 3)
- accentuation mismatch (both sides are filtered through unaccent)
- special cases in unicode that have a special behavior with lower().
See the discussion on odoo/odoo#63145 for a detailled explaination about
these issues.
OPW-2360687
closesodoo/odoo#64510
X-original-commit: 3c5296863f0030acc5d3dba0ff73a6f1b42d1255
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>
Reconciliation models can now create partial payment on invoices. Because of that, the default behavior is not anymore to fully pay the invoice and create an open balance write off.
In some cases, though, this is what we want (exchange difference, ...). The solution for that is to create a reconciliation model with write off lines (telling it it must only apply if there is a 90% percent match on the amount, for example), and then create another one not checking the amount to just match the things to reconcile partially by using the partner.
However, as it is now, reconciliation models always bypass the check made on the amount in case the statement line's label matches the invoice's payment reference exactly. This can lead to cases where we are matching elements we shouldn't with the rule doing the write off.
Example:
- use only two 'invoice matching' reconciliation models, in the following application sequence:
- model 1, matching partner if with amount matching percentage is 90%, and doing a write-off for the unmatched amount
- model 2, matching partner with no amount matching percentage, and no write off
- create an invoice with payment refrence INV1 for partner A, amount: 100
- create an invoice with payment refernce INV2 for partner A, amount: 200
- create a statement with two lines:
- line 1, with 99 for partner A, label= INV1.
- line 2, with 1 for partner A, label= INV2.
- Open the reconciliation widget
==> Before the fix:
model 1 is applied on both statement lines, as their label match payment references. This is what we want for line 1, but probably not for line 2, which will create a write off of 199, while we'd have wished for a partial payment, leaving the invoice with 199 open.
==> After the fix
The behavior is the same unless the config_parameter is set. If it is:
- line 1 will be matched by model 1 (as 99 - 9,9 < 100 < 99 + 9,9). INV1 will be paid with a write off of 1.
- line 2 will not be matched by model 1 (as 200 is not between 1 - 0,1 and 1 + 0,1), but it will be by model 2 (since line 2 and INV 2 share the same partner). So, INV2 will be partially reconciled with line 2.
OPW 2419030
closesodoo/odoo#64504
X-original-commit: ed023e208736e58d14649aa2fd91fb00510f20c1
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Fine tuning of 78286851034b8f3ef4dcab78e50b7220c0bdd213
The link to view Cash Statements on the dashboard openned the wrong
action.
Also in some cases, removing the context key `search_default_journal`
was not enough so we set it to `False` instead.
closes#64118closesodoo/odoo#64279
X-original-commit: 95ffa9fd122eae82d12d40db3cb7364cf3d3c919
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: wan <william-andre@users.noreply.github.com>
Steps to reproduce the bug:
An account with the type "Credit Card" can not be chosen for the
creation
of a journal with the type "Bank" as the domain for bank account filter
only for accounts with the type "Bank and Cash"
As the filter on the `user_type_id` is too restrictive we remove it in
case the journal is bank or cash
Bug:
Impossible to select the correct account.
opw-2394959
closesodoo/odoo#64288
X-original-commit: f4e67d8ae174d7e2ee75a1de1083b31a6ff2af8b
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Before that, write-offs were simply never created in this case ; only an open balance. This was (obviously) wrong.
Also, the partner set on the statement line was not modified, and kept empty. We fix that so that, when a statement line without is reconciled with lines sharing the same partner, this partner is also assigned to the statement line.
Task 2423231
closesodoo/odoo#64253
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Create an invoice for 100
- Create a bank statement for 95
- Setup your reconciliation model so that it will match them and create a write-off for the remaining 5. Make it auto_reconciled.
=> Doing that, we expect the bank journal move to be created like this:
- 100 on payable/receivable, reconciled with the invoice
- 95 on the bank account
- 5 on the write-off account
This wasn't the case. Instead, Odoo created the following (correct from an accounting point of view, but weird):
- 95 on payable/receivable, reconciled with the invoice
- 5 on payable/receivable, not reconciled
- 95 on the bank account
- 5 on the write-off account
=> So an open balance of 5 was actually created. This was weird, and also caused an additional bug, as only the first payable/receivable line was reconciled with the invoice, making it only partially paid.
This commit restores the expected behavior.
Create two differnt journals for two different bank accounts (A, B).
Create an Internal Transfer in bank A to send money, then reconcile.
Create an Internal Transfer in bank B to receive money, then try to
reconcile
Internal transfers are labeled 'Customer Reimbursement' and 'Customer
Payment' even if no external partner is involved in the process,
opw-2423161
closesodoo/odoo#64258
X-original-commit: 4fcacfac8967a3facbe751f748faff02033ce0ae
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
In the bank reconciliation widget, allow matching a payment (blue lines) owned by another bank journal as the statement line one if both journal are sharing the same outstanding account.
It implies to remove the constraint preventing such accounts sharing.
The purpose is the following.
Suppose you are working with payment acquirers generating payments on a bank journal A.
At the end of the month, the bank journal B is debited to pay the payment acquirer.
At this point, you get a statement line on journal B you need to match with payments generated on A.
closesodoo/odoo#64115
X-original-commit: 8d34e1606f930deaa148563ffd40c69457650305
Related: odoo/enterprise#15577
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Create a new sales journal;
- Start creating a new invoice using the new journal (the name/sequence
will be editable) and before saving, change the journal to the
old one;
Before this commit, the invoice will be on the old journal and will have
the new journal name/sequence and after validate the invoice all the new
invoices on the old journal will have the new journal name/sequence.
Now, when you change to the old journal the name of the invoice came
back to 'Draft'.
opw-2415975
closesodoo/odoo#64146
X-original-commit: 3b64640076af472b64a72c7061696772d0e118de
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: william-andre <wan@odoo.com>
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>
Laurent Smet