Since the fields were rewritten in owl, they all have a width of 100% by
default, which is what we want when displaying a field on their own.
In some places, fields are used as part of a longer block of content (eg
unit of measure behind a number). In those cases, we want to display the
field inline, which requires the addition of the oe_inline class in the
arch.
There was also a missing piece of css for the monetary field, as the
previous rule no longer applied because of the slight changes to the DOM
structure.
closesodoo/odoo#99529
Signed-off-by: Aaron Bohy (aab) <aab@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>
Before this fix, resequencing would use values from _get_sequence_format_() run from an empty model.
This method result is influenced by the sequence_override_regex param of the move journal.
This means that if the journal of the moves that are resequenced has a sequence_override_regex param, it will be ignored in the wizard.
This fix run the _get_sequence_format_() method on the first move to take the journal into account.
Note that the wizard only allows resequencing moves from one same journal.
closesodoo/odoo#98926
Task: opw-2825699
X-original-commit: b22c37a5f173161b4a5f798462ea05142bb9334a
Signed-off-by: William André (wan) <wan@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
Current cut-off entry labels are always "Adjusting Entry", which is unclear, especially when viewing entries from General Ledger.
Adding the Invoice number and adjusting the % recognized within each entry will make the labels easier to understand.
The percentage will be calculated accordingly, the cut-off percentage for the adjusting entry and (100% - cut-off percentage) for the original entry.
Also, the percentage on labels should be rounded.
task-2897292
closesodoo/odoo#97045
Signed-off-by: Olivier Colson (oco) <oco@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
This commit fix a bug noticed when fixing this other
one in v15 https://github.com/odoo/odoo/pull/93943.
We notice that, in addition to not set correctly
the payment type, the payment method was wrong too.
With this commit, when creating payments from batch,
we check for each payment if its type is the same
as the one set on the wizard. If not (which means
that there are payments of differents types), we set
the payment method regarding the payment type.
opw-2852186
closesodoo/odoo#98153
X-original-commit: af1fab8dab141c49d98b431a40a5ce98f2f3249c
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@odoo.com>
When register a payment for a bill an a credit note,
the two payments have the same type.
Steps:
- Create a Vendor Bill, and a Vendor Bill Credit Note
- Select both and register payment without grouping them
-> The two created payments have the same type
With this commit, if the field group_payment is True, we
set the payment type regarding the balance of the move line.
opw-2852186
closesodoo/odoo#98010
X-original-commit: 2ad78818b59350cf5e9367802c41820e36d05db1
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Guillaume Vanleynseele (guva) <guva@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>
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>
Open Accounting>Journal Items
Select 1+ items with 0 credit/debit
Hit Actions>Automatic Entries
In the wizard choose 'Change Period', select an Accrued Account with
'reconcile' flag and confirm
Error will raise 'You are trying to reconcile some entries that are
already reconciled.'
This occurs because new entries, with 0 balance, will be created to match
the selected one. The flow include a reconciliation step in which the 0
balance will raise the error.
With this patch the problematic lines will be created but not reconciled
opw-2909058
closesodoo/odoo#97228
X-original-commit: 2433d5daec851293abcd04332dcbb589ceba92c1
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>
Before this commit : When using the cutoff option (e.g. on journal
entries), the percentage in the wizard is displayed with 6 digits precision
After this commit : The percentage is displayed using only 2 digits precision
opw-2896143
closesodoo/odoo#96876
X-original-commit: d71e46dc8369b4d4c929321277a104f6db3fa7a8
Signed-off-by: Laurent Smet <las@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>
After the change in account_type field in account.account the old selection widget didn't work.
Fixing the selection widget and adding it back on acocunt_type field.
As account types cannot be custom anymore, the account types within the hierarchy can be hardcoded.
closesodoo/odoo#95821
Signed-off-by: Cedric Snauwaert <csn@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>
Currently, the register payment button in the invoice form view is
accessible to any Accounting/Billing user. But in the payment register
wizard, the payment difference related fields are only visible for an
Accounting/Auditor user. This does not make sense as the auditor access
level is a read-only role, and there is no dependency between auditor
and billing rights. We should remove the group (as it is already
restricted in the access rights of the model) in the wizard to allow
billing users to use the functionality without the need for accountant
access rights.
closesodoo/odoo#94380
X-original-commit: 488bda480a38f9c09496f770be8a6f540c541044
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Alex Thuyls (alt) <alt@odoo.com>
Recurring entries are created using the 'auto_post' selection field
- 'no' for regular entries
- 'at_date' for non-recurring auto-posted entries
- 'monthly', 'quarterly', 'yearly' for recurring auto-posted entries
Auto-posted entries can also be posted manually.
For recurring entries, the next one is created upon posting.
See : odoo/enterprise#27798
See : odoo/upgrade#3543closesodoo/odoo#92348
Task: 2855545
Signed-off-by: William André (wan) <wan@odoo.com>
An enterprise module adds the possibility to upload bank statements.
Since the mechanism is exactly the same, we should use the same
functions.
closesodoo/odoo#83639
Related: odoo/enterprise#25123
Related: odoo/upgrade#3460
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
- Create an invoice of 1200 MXN = 300 USD
- Register a payment, select USD at a date at which 1200 MXN = 400 USD
=> The amount is incorrect, a difference is computed but it should be zero.
closesodoo/odoo#91634
X-original-commit: d88f630dcb7f98a45c9efe7f2439a8732832c77c
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Description of the bug :
Registering a payment for two confirmed bills/invoices from different partners would result in a stack trace.
Steps to reproduce :
Create a bill from a specific partner and confirm it.
Create another from another partner, confirm it.
From the list view, select both those documents, click Register Payment.
The StackTrace appears.
FIX :
handled the case by setting the payment_difference field to 0.0 if the wizard contains multiple payment batches.
Modified some tests to detect this behaviour in the future.
closesodoo/odoo#89757
X-original-commit: def467e82b12c5ec7284ed9c966bb13ab3a77298
Signed-off-by: Laurent Smet <las@odoo.com>
Fix a lost condition during a refactoring introduced by:
https://github.com/odoo/odoo/pull/82025
When dealing with payment transactions, a payment could be still in draft even after the call the 'action_post'.
closesodoo/odoo#90235
X-original-commit: 14cdb80774b638a39f430bc49c0c4d5a01925d90
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
Steps to repoduce:
- Accounting > Customers > Invoices:
select several invoices to send
- Action > Send & Print > (deselect Print) > Send & Print
Issue:
- It sends only one invoice per company
Cause:
- the mail_compose_message sets the status of an email as `cancel` when a mail has already been sent to a specific adress mail in the batch
Solution:
- If the use of mass mailing is document-based (e.g.: sending multiple invoices) it will allow to send multiple emails to the same adress
opw-2775121
closesodoo/odoo#88992
X-original-commit: f08685020f6a00d4e10e30ccbcf70c9eb1a764d5
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
* Previously, when reconciling journal items in multi-currencies, the exchange difference entry was created only on the full reconciliation. It will now be created directly at each partial to ensure the ratio between amount_residual_currency and amount_residual is always kept identical.
* Also when reconciling two lines, one with a foreign currency and one expressed in company currency, the reconciliation is now made based on the foreign currency.
==== RATIONALE ====
This patch allows to fix the following use cases (among others)
1) When everything is expressed in foreign currency, the reconciliation is made in that currency:
Suppose EUR is the foreign currency and USD is the company currency. Reconciling:
L1: 120 EUR 60 USD (rate 2:1)
L2: 240 EUR 80 USD (rate 3:1)
..leads to a partial of 120 EUR and min(80, 60) = 60 USD
After the reconciliation, L1 is fully matched but L2 is still open with 120 EUR but only 20 USD.
This is the first problem is the current reconciliation because L2 is supposed to have a rate 3:1 so the residual amount should be 120 / 3 = 40 USD.
Since the rate is no longer consistent on L2, the user will probably close the reconciliation by using another line in EUR or will close manually the reconciliation with 20 USD but without any additional exchange difference journal items explaining where this unconsistency comes from.
2) When the current lines are mixing multiple currencies, the reconciliation is made using the company's currency.
In some countries like Mexico, Ethiopia or Costa Rica, the customer is free to pay an invoice using the company's currency instead of the foreign one.
So, suppose USD is the foreign currency and MXN is the company currency.
The invoice is expressed by:
L1: 120 USD 60 MXN (rate 2:1)
If the customer is paying at a date in which the rate is 3:1, he is free to pay
either L2: 120 USD 40 MXN (rate 3:1), either L2: 40 MXN.
In the second case, he is expecting the invoice to be fully paid because its paiement is equivalent to 120 USD at the payment date.
In Odoo, the second case led to an open balance of 20 MXN and the invoice was not completely paid.
Even this situation could be easily fixed by a manual write-off, this makes the Mexican payment EDI very complicated to fullfil correctly because the government is expecting a complete matching between the invoice and the payment.
When the customer is paying multiple invoices or the invoices are paid using multiple payments, the currently generated mexican EDI file in Odoo was wrong.
==== REFERENCES ====
Original idea suggested by hbto@vauxoo.com. Thanks for the contribution and patience of the many persons having, at some point, helped on that.
github issue: https://github.com/odoo/odoo/issues/37469closesodoo/odoo#84201
Task: 2669371
Related: odoo/enterprise#24268
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
=> Create an invoice in foreign currency
=> Register a payment of 0 using the currency of the company and select "Keep open"
A traceback is raised
closesodoo/odoo#87886
X-original-commit: 14894623029c24230dea92ccef950cff914e1704
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Laurent Smet <las@odoo.com>
- Create an invoice having a foreign currency
- Register a payment of 0.0 using a different currency with a write-off of any account
=> traceback
Task: 2809565
X-original-commit: c86faecc980523fcfa6a3258f4c17bf30b41522c
Part-of: odoo/odoo#87886
Have 3 moves named 0, 1 and 2
Delete move 1 to make a hole.
Resequence, starting the sequence at 2.
Expected: new names are 2 and 3
Result: an error because 1 is renamed to 2 but 2 still exists, leading
to a (temporary) duplicated name, which is not allowed.
We clear all the names to be resequenced before doing it in order to
avoid that.
closesodoo/odoo#87836
X-original-commit: bf5173f64582e2675f4121122ce26cb57624e08a
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Do not allow users to create accrual entries for locked periods.
This would either create an entry for another date, since the date is
changed automatically by `_get_accounting_date` when posting.
Reproduce:
* Set a lock date
* Do an automatic entry for either changing the account or the period
before that lock date
Or it would traceback because the date would be changed automatically
and no matching would be possible when changing the period.
* Set a lock date
* Create an automatic entry to change the period of an entry before the
tax lock date
closesodoo/odoo#87391
X-original-commit: f830b008781c2f6f5644395688654e64edd5c836
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
There were inconsistencies in the calls to `_render`.
* the view context could contain information that misled developers.
Indeed, the context and value of the view are not supposed to be found
in the rendering. Thus by calling `ir.qweb` with the name of the
template, we ensure that there is no unwanted information and in
addition the cache key is that of the name of the template which saves
a query.
* the context used for rendering was modified by a method on
`ir.ui.view`, except this is not information used by this model. There
is now a `_prepare_environment` method residing on `ir.qweb`. This
method allows to modify the value dictionary as well as the context in
which the rendering will be done. This preparation of the data as well
as my security check is done only once per rendering. This also saves
some queries
* Freeze options for rendering were inconsistent. It could be that
options on which rendering depends were not part of the cache key. Thus,
depending on the user who generated the generation of the rendering
function, there was or was not information in the template. For example
for automatic branding. This is no longer possible, because it is the
context that is used. The options serving as a cache key are only
recorded for information (for the profiling system for example). A
simplification of the `ir.qweb.field` models could be made.
The report rendering and call `ir.qweb` instead of `ir.ui.view`.
Part-of: odoo/odoo#85110
Improve the journal audit report by adding information about impacted
tax grid for each computed journal.
Task id #2658937
X-original-commit: 09848ba2ae5bd0f25c20a20e73089a5a0f1c8f74
Part-of: odoo/odoo#85188
The tax adjustment wizard shows tax reports of countries other than the
current company's country
Steps to reproduce:
1. Install Accounting
2. Go to Accounting > Configuration > Management > Tax Reports
3. Create a report for another country than the current company and add
a line with a tag name
4. Go to Accounting > Accounting > Actions > Tax Adjustements (in debug
mode)
5. The created tax report line is suggested but it shouldn't
Solution:
Put the domain of `tax_report_line_id` in python and add a filter on the
country
opw-2760337
closesodoo/odoo#84854
X-original-commit: cc13d20996f1e0a261829ced91cbbe18d6236fb5
Signed-off-by: William André (wan) <wan@odoo.com>
When trying to set up a new bank account using the bank account wizard,
there is an issue with the check company on the linked_journal_id field.
The check will make sure that the company on that field is either false
or the same as the company on the record. But with a recent change in
68f4534aa5 the bank account company_id will be the one from the linked partner.
As the partners for companies have an empty company_id, this check does
not make a lot of sense anymore, as it would be wrong in most cases.
(We expect a journal with the currently selected company, but the bank
account will in most cases have an empty company_id)
closesodoo/odoo#83852
Signed-off-by: Josse Colpaert <jco@odoo.com>
Some html field are not in their ideal style.
As the style for html fields is now dependent of
where you are in the xml view ( in group or not),
we have to adapt some views and flags some fields
to ensure they have the correct look.
This change is only be a visual enhancement
and should not prevent the function of said html fields
even if the views are not updated.
task-2637488
# Conflicts:
# addons/mail/wizard/mail_compose_message_views.xml
# addons/website_slides/views/slide_channel_views.xml
# Conflicts:
# addons/sale/views/sale_views.xml
closesodoo/odoo#83792
Related: odoo/enterprise#23911
Signed-off-by: Antoine Guenet <age@odoo.com>
Signed-off-by: Geelen Sébastien (sge) <sge@odoo.com>
Steps to reproduce:
- Create an invoice and confirm it
- In Accounting Dashboard, on the Customer Invoices card,
click on 'Unpaid Invoices'
- Select the invoice with the checkbox
- Click on button 'Register Payment'
Issue:
- The journal_id is not set by default
Before this commit, the default fields inherited 'journal_id',
if it's not the good one, we delete it in order to compute it..
opw-2729754
closesodoo/odoo#83770
X-original-commit: 9e2f96598f3d62b501e894eab7151af8390937e1
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Guillaume Vanleynseele <guva@odoo.com>
When creating automatic entries for multiple moves on different dates with the automatic entry wizard, the wizard would reconcile all the lines on the accrual account of the destination move with the lines on the accrual account of each accrual move. As this would imply reconciling the same lines multiple times, it triggers a reconciliation error.
What must be done is, for each accrual move, reconcile it’s lines with only the related lines on the destination move.
closesodoo/odoo#83732
Task: 2717578
X-original-commit: 502003ac548d6620374dfbab4fb7be6dee3c1bf5
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Florian Gilbert <flg@odoo.com>
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Sometimes _compute_percentage would return a percentage slightly over 100 due to a rounding error. This would then trigger the constraint asserting that percentage must be >= 0 and <= 100.
Task: 2717578
X-original-commit: 813d52ed7daff408819d8838c8c36fcee825905f
Part-of: odoo/odoo#83732
Currently: "register payment" wizard allows selecting different bank accounts or even creating one when registering a payment on customer invoice/vendor refund.
Should be: the field should be set to partner_bank_id and be set as readonly. When cash journal is selected, "Recipient Bank Account" field should be hidden
Task ID: 2710936closesodoo/odoo#81319
Signed-off-by: Olivier Colson <oco@odoo.com>
Steps to repdroduce:
- install Purchase - Accounting
- Create a new Purchase Order
- Add a product
- Add a section or a note
- in Actions select Accrued Expense Entry
-> traceback rounding error
OPW-2728854
closesodoo/odoo#83057
X-original-commit: 582be68bb5e4d441548a987fda3ff6450faa24ca
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
Before this commit, the field reversal_date was not stored, which lead to inconsistent behaviour when creating entries, as the reversal date was always recompute with the default value.
opw-2722435
closesodoo/odoo#82445
Signed-off-by: William André (wan) <wan@odoo.com>
Three supported types:
- btree (default for index=True)
- btree not null (when >90% of the data are null)
- gin trigram search (for char fields)
Review of indexes on all objects.
closesodoo/odoo#83015
Signed-off-by: Fabien Pinckaers <fp@odoo.com>
Steps to reproduce:
- install accounting (account_accountant)
- go to invoice
- click on "send and print"
-> template is not loaded directly
Solution:
- revert changes of commit #fc5812c327daab4 since the onchange is now called only once
OPW-2732687
closesodoo/odoo#82805
X-original-commit: fa25a3b2b7cdafbce70e39a8a896924f015185a9
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: yosa-odoo <yosa@odoo.com>
If money is withdrawn, we can't tell if it's a transfert to the bank account or if some money has been withdrawn to pay an invoice or some expense.
We then assign the suspense account in order for the accountant to go through the reconciliation widget process in order to dispatch/assign the amount to the right account(s).
This allows all the accounting process to go smoothly without any needs for the accountant to manually create a miscellaneous entry.
Introduced by:
closesodoo/odoo#82616
Pr: https://github.com/odoo/odoo/pull/82123
Commit: https://github.com/odoo/odoo/commit/336656e0e9677ccb2f43935b6f267fa83ed153df
X-original-commit: 04396e0627fd36d28b047e0e122ffb55a3a12ebc
Signed-off-by: Florian Gilbert <flg@odoo.com>
Current behavior:
When cancelling an expense payment, the expense state was not modified and was still 'paid' when it should be 'refused'.
Steps to reproduce:
- Create an expense and post the expense and register a payment for the expense.
- Then go the vendor payments and cancel the associated vendor payment.
- The expense still shows as paid in the expenses page.
opw-2711383
closesodoo/odoo#82496
X-original-commit: 16459957d23f4bdfddfe96d72ef96cbdc6fec539
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Engels Robin (roen) <roen@odoo.com>
Stanislas Gueniffey