Clean the action for reconciliation view for the correct handling of it.
Removes the group by Matching in the Journal Items reconciliation
list.
Now includes all linked reconciliation account_move_lines for a better
representation of spaghetti reconciliation.
task-2959808
closesodoo/odoo#98827
Related: odoo/enterprise#30702
Signed-off-by: Laurent Smet <las@odoo.com>
We added trigram index for char fields since https://github.com/odoo/odoo/pull/83015.
But if `unaccent` is installed in the database (and isn't force to
`False` on field), these new trigram indexes are pointless and cost a
lot for nothing (almost nothing, it still can be used for equality
operator but in this case a btree will be far more efficient).
The simple way to fix it is to add `unaccent(<column>)` in the index
trigram definition, but unfortunately `unaccent` is not immutable and
may therefore not be indexed. In order to make `unaccent` indexable, we
must declare it as immutable (see
https://stackoverflow.com/questions/11005036/does-postgresql-support-accent-insensitive-collations/11007216#11007216
for more information and how to do that).
With this patch, trigram indexes are created with `unaccent(<column>)`
if the function `unaccent` is available in the database, and for the
fields that are not declared with `unaccent=False`. Moreover, we issue
a warning when `unaccent` is available but is not immutable, in which
case most trigram indexes will be useless.
odoo/upgrade#3736
task-2551518
closesodoo/odoo#95943
Signed-off-by: Rémy Voet <ryv@odoo.com>
Some countries, such as mexico, require a seller to be able to
generate an invoices from a ticket from a sale done in a shop,
even after a few days.
This change aims to allow this, by allowing to create an invoice at
a later date after the POS has been closed.
This is done by partially reversing the POS closing entry, and then
generating an invoice the same way it would be done at the POS closing.
The customer can scan a QR code if enabled in order to request the
invoice by himself, requiring him to fill a for to give the customer
information required for the invoicing.
Allows to fill additional fields dependent on the localization that are
required to be set on the partner or the invoice.
Task id #2946604closesodoo/odoo#97675
Related: odoo/enterprise#30599
Signed-off-by: Laurent Smet <las@odoo.com>
This commit improves the payment terms by:
- making the payment terms lines editable on-the-fly removing the need for a wizard
- refactoring the computation of the payment terms
- adds new demo data for payment terms
- adds an example section where the user can test and preview the due dates and amount of its payment terms
- adding a new parameter "Display terms on invoice". If set, the payment deadlines and respective due amounts will be detailed on invoices.
The refactoring:
- adds a field `months` (months to add after the invoice date)
- adds a field `end_month` (if True, switch to the end of the month after having added months or days)
- renames the field `day_of_the_month` to `days_after` (days to be added after the switching to the end of the month, only if `end_month` is set)
- deletes the field `option` which was too restrictive
- modifies the calculation of the payments terms taking into account these new fields
This allows some combinations that were not possible before.
Example: The French payment terms "30 jours fin de mois le 10" (which should be interpreted as "10 days after the end of the next month") can be encoded as
```
months = 1
days = 0
end_month = True
days_after = 10
```
Task id 2852814
closesodoo/odoo#91490
Related: odoo/enterprise#29661
Related: odoo/upgrade#3524
Signed-off-by: Laurent Smet <las@odoo.com>
The current taxes computation method defined in account_edi has been moved to account on account.tax to be usable on any models.
closesodoo/odoo#99401
Related: odoo/enterprise#30967
Signed-off-by: Laurent Smet <las@odoo.com>
On a bank statement line:
If a foreign currency is set and the amount in currency is not set, the line is reconciled automatically (because the amount is 0) and this should not be the case.
Add a constraint on `account.bank.statement.line`: raise an error if the foreign currency is added, but the amount in currency is not.
This conflicts with the tests that allow this behaviour, so the related tests are deleted as this should not be allowed anymore.
task-2956422
closesodoo/odoo#99028
X-original-commit: 1dfa3d074c7368abb51df56cb7fd1ee5115399b1
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Aliya Tastemirova (alta) <alta@odoo.com>
Current task is not covered the whole cash discount feature. For now, we decided to revert the current feature and make a new more complete one later.
This reverts commit 7482aff6d7.
closesodoo/odoo#98986
Related: odoo/enterprise#30783
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
- Remove FEC from res.config.settings - everything is now linked in the import guide (in enterprise)
- Compute debit and credit from opening_balance
- Update import templates for account.account, account.move, res.partner
- Small UI changes in base_import: add an action title and improve the template button design
task-2888243
closesodoo/odoo#96291
Related: odoo/enterprise#29627
Related: odoo/upgrade#3794
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
This commit adapts account's model to the new report engine introduced for v16, and updates the data files accordingly.
account.report model is now declared in community, together with the other models used by the reporting. This is done so that the tax tags can properly be created by the tax report and used on tax templates. All the actual computation logic stays in enterprise.
See enterprise commit for full details.
Task 2524389
Part-of: odoo/odoo#94125
The aim of this commit is to improve UX by helping the user to find duplicate
bills in a more convenient way.
With this commit, when a user create a bill or credit note on bill that might
be a duplicate, a warning banner is displayed on the Form view of the
account.move.
On this banner there is a button that leads to the list of the duplicate
bill/credit note.
The previous warning message on post is also replaced by a RedirectWarning
Context:
Previously, the warning for duplicated bills was thrown when the bill was
saved. This was changed with https://github.com/odoo/odoo/pull/81748
It made the blocking warning being delayed until the bill is posted.
Previous to this commit:
A duplicate bill can only be detected automatically when posting the bill with
a non convenient blocking warning preventing the user to post his bill(s).
After this commit:
- A warning banner is displayed on the bill form during the bill creation.
- The banner contains a button leading to the list of duplicates.
- The blocking warning is improved by providing redirections to the duplicate
move.
closesodoo/odoo#81765
Community-pr: https://github.com/odoo/odoo/pull/81765
Task: #2612299
Signed-off-by: William André (wan) <wan@odoo.com>
Current behavior:
In the PoS if you use 2 differents payment methods (cash and customer
account), and that the cash amount given by the client require you to
give some money back, the amount due on the customer account would be
incorrect on the invoice.
Steps to reproduce:
- Start a PoS session
- Add the 750$ desk to the order
- Go in the payment screen
- Add customer account with 300$
- Add cash with 460$
- Click on invoice
- The invoice show that the client need to pay 290$ which is not
correct
Before the fix calling `_prepare_reconciliation_partials()`
with the sorted lines we had 2 credit lines (750€ and 10€)
and 1 debit line (460€).
Debit lines | Credit lines
460€ | 750€
| 10€
The function would reconcile the 2 first lines and stop after that
because the only debit line was fully reconciled
After the fix we have this
Debit lines | Credit lines
460€ | 10€
| 750€
After reconciling the 2 first lines we have this
Debit lines | Credit lines
450€ | 750€
And after reconciling the 2 last lines we have the correct amount left
to pay by the customer (300€)
opw-2857064
closesodoo/odoo#98828
X-original-commit: 1201123e272012b7b5ab65eebfd12a911ecc6c1a
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@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>
Fix the accounting date in a few scenarios, such as exchange difference
or CABA moves reversal.
Also avoid updating the currency rate when reversing exchange difference
moves.
closesodoo/odoo#98543
X-original-commit: 2b8df0c111a785a9e51dc2f528ac5b00cb0eadb9
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Nicolas Viseur <vin@odoo.com>
Currently there is no simple way of finding if an invoice is a
downpayment.
Downpayments can be created from a sale order. An invoice is generated
representing the downpayment. When the sale order is used to generate
the complete invoice, the downpayment is deducted.
There is no fast way to distinguish a downpayment invoice. The only way
of knowing is that the lines of the invoice will have sale_line_ids for
which 'is_downpayment' (a boolean field on the sale order line) is true.
(also, by default, the product 'Downpayment' is used for the invoice
line representing the downpayment)
This commit adds a helper method '_is_downpayment' to the account.move
model, which will return False if sale is not installed, and True if
sale is installed, and is_downpayment (the boolean field on
sale.order.line) is true of all the sale lines associated with all the
lines of the invoice.
Another method '_get_downpayment_lines' is added to the
account.move.line model which, for all sale lines associated with the
move line upon which it is called, returns the invoice lines of the sale
lines for which their move_id._is_downpayment() is true. This
distinguishes between the downpayment lines in the final invoice (which
aren't retrieved by this method), and the downpayment lines in the
downpayment invoice (which are retrieved by this method).
Part-of: odoo/odoo#98534
This revision is to make uniform the behavior of the `groups` attribute
on the Python model fields
and on the node in the view architecture.
In both cases, remove the node from the view completely.
Before this revision,
in a back-end view:
- In the Python model, if a field has the `groups` attribute set
and the user is not part of
the groups, the field is removed, completely, from the view.
- In the view architecture, if a node has the `groups` attribute set
and the user is not part of
the groups, the node is made invisible (not completely removed, just
made invisible).
in a front-end view:
- if a node has a "groups" or "t-groups" set and the user
is not part of the groups, the node is removed from the view.
So it's 2/3 cases removing nodes restricted to a group.
and 1/3 case making invisible nodes restricted to a group.
It's simpler to have a uniform behavior for the 3 cases,
simpler to understandard for developers.
In addition, this will help for the goal to cache back-end views.
It makes possible to convert views using the `groups_id` field
by moving the content of these views directly
in the view to which they add content which is suppose to be completely
removed when the user has not the according group.
By getting rid of the `groups_id` many2many field on `ir.ui.view`,
it makes possible to cache the view architecture without
requiring to use the groups in the cache key.
Currently, if we want to cache the view architecture,
it would be required to use the intersection of the user
groups with the `groups_id` groups of the view,
making it costly to compute the cache key,
therefore altering the performance point to cache the view
architectures.
closesodoo/odoo#95729
Related: odoo/enterprise#29592
Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>
Create an invoice in date1 with a tax due based on payment (cash basis)
Create a credit note in date2 for the invoice (with date2 > date1)
Set tax lock date in date3 (with today > date3 > date2 > date1)
In the invoice add the credit note as payment
The system will block the action, because the created cash basis
entry would use as date the most recent between invoice and credit note,
which is previous to the lock date.
opw-2730106
closesodoo/odoo#98425
X-original-commit: 087e967f6ebf6e5829ec1d72a672841f8d543d4a
Signed-off-by: William André (wan) <wan@odoo.com>
Have a sequence of bank statement out of order
i.e.
|id| date |
|--|--------|
|01|20/07/22|
|02|21/07/22|
|03|22/07/22|
|04|18/07/22|
|05|17/07/22|
|06|16/07/22|
|07|15/07/22|
Adding more out-of-order bank statement will trigger recomputation in
all the next (chronologically) statements.
As the records to recompute are ordered by id, it may occur that the
first statements to recompute have the highest date and cause a
recomputation recursion exceeding the limits
opw-2925984
closesodoo/odoo#98373
X-original-commit: f675222786a9f57199117d38fca529dd1b0c2104
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The model had name_get, but not _name_search, which leads to difference between
what user sees and what he get as search results.
This patch doesn't fix the issue completly, but adds more search results on
searching just by account move (e.g. invoice) name.
STEPS:
* open menu Analytic Items (account.analytic.line)
* make custom filter *Journal items contains "INV/"* (
`[["move_id","ilike","INV"]]` )
BEFORE: no items found even if you see such analytic items
---
opw-2691495
closesodoo/odoo#98289
X-original-commit: 84f440c7b0d18c3c9f9dd57d5352f1da10fedf00
Signed-off-by: William André (wan) <wan@odoo.com>
Purpose :
Improve multiple use cases while handling the Accounting part of Cash Discounts in Odoo.
When creating a Payment Term, the user can now specifically design an early payment discount through an additional part in the wizard.
This will, amongst other things, allow the user to choose in which way the tax should be computed on the discounted invoice (tax included/excluded).
The discounted amount and the conditions to fulfill are printed below the invoice PDF, as well as the details.
Registering a payment while filling the condition for an early payment discount will prefill the fields accordingly.
Reconciliation --> In the reconciliation widget, the logic of Early Payments Discounts are also applied.
Related : odoo/enterprise#28607
Task:2729038
Part-of: odoo/odoo#94050
To reproduce
============
Enable "Qr Codes" under Accounting Settinsgs > Create Invoice > set "Payment QR-code" method (tab "More Info")
> issue Credit Note > try to "Send and Print" credit note > Error:
` The chosen QR-code type is not eligible for this invoice. `
Specification
=============
Generating QR code on Credit Note doesn't make sense, so the field `qr_code_method` is set to `False`
when creating a Credit Note.
opw-2900112
closesodoo/odoo#97889
X-original-commit: cdc564d8b31d7691bb1a6faaef940bc5fd3eb8f0
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
Task 2888341
After the OWL update the drag and drop feature doesn't work anymore.
This little change does both things mentioned in the task: fixes the upload + shows the list view when the documents are uploaded
closesodoo/odoo#97671
Signed-off-by: William André (wan) <wan@odoo.com>
Using named attribute 'start' in sum function is not compatible with
python 3.7, it is also set as 'start=0' which is useless as it is the
default value of start argument.
Part-of: odoo/odoo#97862
There can be many accounts in self and the "search_read" is currently breaking because of self.company_id in the domain.
This commit addresses two problems:
- Creating accounts in a multi-company environment
- Setting a default account_type when there is no parent found.
Account codes should however be still limited to the current company even though for performance reason we batch the searching part.
closesodoo/odoo#96832
Signed-off-by: William André (wan) <wan@odoo.com>
TLDR:
* invoices are implemented using computed methods instead of onchange
* the synchronization only happens when switching tabs in the Form view
to improve perfs.
_______________________________________________________________________
The whole engine of the synchronization of Invoices to the Journal
Entries has been refactored
* by using computed fields instead of onchange functions
* by synchronizing only from invoice to journal entry in `create` and
`write`
* by saving when switching tabs on the Invoice form, to synchronize
before showing the values
This comes with numerous advantages:
* no need to call the onchange methods manually
* no need to use the Form emulator to build invoices (i.e. EDI, OCR,
intercompany, ...)
* the performance for invoices with many lines improves drastically, going
from 2 minutes to 4 seconds to create an invoice with 500 lines
* the model is more declarative, we can now see how the values are computed
instead of having the values being copied from various places.
* remove the hack in `onchange` that disabled the recursivity of it,
which was unexpected and needed to be managed manually in all the
onchange methods
This means that:
* Some fields need to be exclusively computed on journal entries values
or invoice values, more specifically the Tax Summary widget.
It is now
- computed from entry lines, when opening the view
- computed from invoice lines when changing those, because the tax lines
will need to be recomputed anyways, erasing previously set values
- set with an inverse function when saving; after the sync has been done
* Some possible operations previously possible have been dropped.
(i.e. look at the removed test test_in_invoice_line_onchange_accounting_fields_1)
This is because such a behavior was undefined (how is changing the balance going
to affect the unit price? How is the amount currency going to affect it?)
_______________________________________________________________________
Implementation Details
----------------------
The "dynamic lines", meaning the payment terms and the tax lines are now
only created in the `create` and `write` functions.
In order to reduce code duplication, it has been implemented using
context managers used in both `account.move` and `account.move.line`
These context managers help comparing the values before/after, acting
like a local `onchange`, but getting benefit from the dirty flags from
the `compute` dependences.
This is relying on computed fields on the move (`needed_terms`) and on
the lines (`compute_all_tax`) which contain the values needed for the
related move.
Depending on the needed values and the existing values (`term_key` and
`tax_key`, respectively) the context manager will determine what needs
to be created/updated/deleted.
Some related changes are to produce a `dict` instead of a `str` for the
`tax_totals` (previously `tax_totals_json`) fields, by simplicity to
reduce the complexity of IO, and simplicity of debugging, because the
logic of the field needed to change (cannot be computed at the same time
anymore since it needed the lines to be synced)
By simplicity, and also because it makes more sense, some boolean fields
have been merged into `display_type`:
* `is_rounding_line`
* `exclude_from_invoice_tab`
* `is_anglo_saxon_line`
The `price_unit`, `quantity` and other "invoice fields" are now not set
anymore on lines that are not product lines since it didn't make any
sense to have it.
Performances
------------
You have to keep in mind that a simple `create` didn't compute a lot of
fields, for instance not taxes were set, no payment terms,...
Now it does.
```python
import random
from timeit import timeit
from odoo import Command
domain = [('company_id', 'in', (False, self.env.company.id))]
products = self.env['product.product'].search(domain).ids
partners = self.env['res.partner'].search(domain).ids
taxes = self.env['account.tax'].search(domain).ids
def create(nmove, nline):
self.env['account.move'].create([
{
'move_type': 'out_invoice',
'partner_id': random.choice(partners),
'invoice_line_ids': [
Command.create({
'name': f'line{i}',
'product_id': random.choice(products),
'tax_ids': [Command.set([random.choice(taxes)])],
})
for i in range(nline)
]
}
for j in range(nmove)
])
# After | Before
print(timeit("create(1, 1)", globals=globals(), number=1)) # 0.11 | 0.09
print(timeit("create(100, 1)", globals=globals(), number=1)) # 2.76 | 2.50
print(timeit("create(500, 1)", globals=globals(), number=1)) # 14.56 | 12.34
print(timeit("create(1, 100)", globals=globals(), number=1)) # 1.03 | 5.52
print(timeit("create(1, 500)", globals=globals(), number=1)) # 3.99 | 125.02
print(timeit("create(50, 50)", globals=globals(), number=1)) # 19.44 | 79.55
```
Another metric that can be used is running the test suite with
`--test-tags=/account` (only `account` installed)
* before: 404s, 267127 queries (366 tests)
* after: 318s, 232125 queries (362 tests)
Why this commit title?
----------------------
Someone told me that this was the perfect way of naming your commits.
c04065abd8
task-2711317
closesodoo/odoo#96134
Related: odoo/upgrade#3715
Related: odoo/enterprise#29758
Signed-off-by: Laurent Smet <las@odoo.com>
The render API was confusing as mixing the access to the report and
the rendering env.
The ambiguity was present for code such as
`report.sudo()._render(record_ids)` where it was not clear if the
`sudo()` is needed to access to `report` or to `record_ids`. For low
priviledge users (such as portal or public), it was common to use
`report.with_user(SUPERUSER_ID)._render(record_ids)`.
This PR changes the render methods signature to be `api.model`. The
`report_ref` can be:
- ir.actions.report external id
- ir.actions.report id
- ir.actions.report recod
- `report_name` value
This will allow to call the report methods with any user and no longer
need to use `with_user(1)` to render reports as public user.
Task-id 2670865
closesodoo/odoo#91341
Related: odoo/upgrade#3650
Related: odoo/enterprise#27323
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
This commit aims at removing unuseful help message to:
1/ reduce translators work, to focus on more useful translations
2/ not sending unuseful information in load_views
3/ reduce help message to useful messages, so that we can mark
fields having a tooltip in the future UI.
4/ some cleanup of existing messages too
The main use cases:
- REMOVED: help redundant with the field name, providing no extra info
- MOVED TO COMMENT: technical help messages, that should not be in UX
closesodoo/odoo#97279
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
We keep the statement line note when changing
the partner in reconciliation widget
Steps:
- Create a Bank Statement, a Bank Statement
Line BSL with a note (field narration)
- Save, edit, change partner on statement
line and save.
-> The note on BSL is empty
With this commit we allow narration computation
only for sale documents.
opw-2832287
closesodoo/odoo#97125
X-original-commit: 19394d1971259933c5158139c56344c9c35bdaed
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
As we allow editing balances in processing state, we do not want
to check balances before the validation of the bank statement
(only in case of a bank journal).
Commit about editing balances: 03f83eb87da00938b9d2df78651c1e06cf8a6d58
This fix split the _check_balance_end_real_same_as_computed into
2 functions. One to check "bank" bank statement and one to check
"cash" bank statement. It allows to keep the same behavior for
a "cash" bank statement when we post the bank statement, and
having the right behavior for a "bank" bank statement.
opw-2835728
closesodoo/odoo#97153
X-original-commit: 2d97efb4c84f647be3eb03f249c52b236bf00d55
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Until now, an invalid PDF file would generate a traceback
during the export, which is not very user friendly.
The export happens when on the vendor bills list view,
by selecting one or more bill(s) that were generated
by the OCR (via the 'Upload' button),
clicking on 'Print' then 'Original Bills'.
The goal here is simply to catch those errors and display
a slightly more helpful message.
closesodoo/odoo#96935
X-original-commit: 7e7bd50403b6f5e2dabc39caf5fddb57d7052ebc
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: John Laterre (jol) <jol@odoo.com>
When using the wizard to add a bank account, it should be added to
an existing journal only if the journal has no bank account set
and no journal entries.
We also want to be able to remove a set bank account.
When using the wizard to add a bank account (Create it button ;
not Connect button), it should be added to an existing journal
only if the journal has no bank account set and no journal entries.
We remove an unwanted constraint on the bank journals that
prevented the removal of an Account Number (IBAN).
Some UX changes. In the Journal Items list view, specific views
open depending on their move type. This commit also changes
the "View" button of the invoice payment widget on the Journal Entry's
form view in order to align behaviours.
The core open_move method is also moved from the account move line
model to the account move's one for more flexibility.
The "1 Statement" button of the payment's form view now links to the
new reconciliation widget.
The Journal Items lists accessed from the Journal report now show
the partner by default.
The "Unreconciled" filter now filter out partial reconciliations which
have a residual amount != 0.
The Partner column should almost always be shown by default in a
Journal Items list view.
task-2893208
closesodoo/odoo#94923
Related: odoo/enterprise#29092
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
When using _prepare_analytic_distribution_line, it would take
the company for the line from the distribution, then the env.
This would cause multicompany issues in some case, creating the
line for the wrong company. By using current the move line to
get the company before falling back on the env, we can avoid such
an issue.
OPW-2900827
closesodoo/odoo#96465
X-original-commit: 8c10324f062e4cd239494545cdfce7cde7ffadbb
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Task 2888204
- Name is automatically split into code and name
- account_type is computed based on the closest parent of the code prefix (and can be changed)
- _onchange_name is needed to split name into code and name when creating from a related model's form
closesodoo/odoo#94171
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
When an invoice line has a display_type, account addon is expecting
account_id=False in vals. Replacing the normal dict access with a
`get` will fix the error when invoicing with note/section lines
without explicitly specifying the `account_id` to be false.
closesodoo/odoo#95894
Signed-off-by: Masereel Pierre <pim@odoo.com>
Deprecated method _get_default_invoice_date is no longer used and can therefore be safely removed.
closesodoo/odoo#95820
Signed-off-by: William André (wan) <wan@odoo.com>
Task: 2856281
- Remove user_type_id, account.account.type model, internal_type
- Add account_type that is a simple selection field
- Move internal_group and include_initial_balance to account.account
- Because of these changes, type_control_ids on account.journal is also removed
closesodoo/odoo#93212
Related: odoo/documentation#2223
Related: odoo/upgrade#3595
Related: odoo/enterprise#28205
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Since Odoo v15, user can rename invoice to a custom value. Odoo automatically
detects `sequence_number` for the new name. If no number is detected, the
`sequence_number` is set to zero. In this edge case, method
`_is_end_of_seq_chain` doesn't work and raises an exception, because `last_rec` is
empty, while `_get_last_sequence` has constrain `self.ensure_one()`.
Fix it by allowing `last_rec` with zero `sequence_number`.
STEPS:
* Create invoice
* Confirm
* Reset to Draft
* Rename invoice to "Test"
* Save
* Try to delete the invoice
BEFORE: ensure_one error
Once it's fixed, we face another problem: User Error *You cannot delete this entry, as it
has already consumed a sequence number and is not the last one in the chain. You
should probably revert it instead.*
It happens because `sequence_prefix` is computed as empty string, while
`_get_last_sequence` method ignores empty values. Fix it by allowing search by
empty string too.
AFTER the two changes user can delete draft invoice
opw-2861841
closesodoo/odoo#95614
X-original-commit: 301b499b9d0ce189dc5d0433e55ce654d212927b
Signed-off-by: William André (wan) <wan@odoo.com>
By trying to avoid concurrency issues while assigning the sequence [1],
we are locking too many operations even when not in the process of
assigning a new number.
* when computing `highest_name`, we don't need to lock as this is mostly
an information on the form that can possibly change anyway while the
form view is open (without any lock anymore)
* when computing the accounting date, we don't need to lock, the only
information we want is the format of the sequence (yearly, monthly, no
reset), which is not likely to change on a same journal.
* when changing the `journal_id`, it is only a helper for encoding, if
there is a concurrency error it will be shown during the post anyways.
Also same argument as for `highest_name`
[1] https://github.com/odoo/odoo/commit/ba6ee0b75d66d6f22a592b1b6a7c5158461bec41closesodoo/odoo#95480
X-original-commit: 809557cdd02fe6581ed573b58158a927aabe0694
Related: odoo/enterprise#29212
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Step to reproduce:
- Create a SO, save and confirm it
- Create an invoice, on edit mode, change the journal and click on save
Issue:
- If the invoice is the first one in the current month, a sequence
number is automatically assigned and an error is displaid.
forwardport of https://github.com/odoo/odoo/commit/b8328e45d526d276b5781da3523a0d5874da64bd
opw-2660571
opw-2879716
closesodoo/odoo#79084closesodoo/odoo#95386
X-original-commit: 7b296982139518460405fa63eca6774bd82ba7b1
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Minet Adrien (admi) <admi@odoo.com>
Purpose
=======
possible values of Default Bank Supense Account (in accounting settings) are Current Liabilities
when they must be Current Assets.
Specification
=============
to solve the issue we added Current Assets to the possible values of this field.
opw-2855788
closesodoo/odoo#95233
X-original-commit: 2730b80942d3d32f72bae922cb06a61ecfa38c0f
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: abla001 <abla@odoo.com>
Laurent Smet