It was possible to create inconstancies in accounting entries by forcing to sum apples and pears.
Steps to reproduce
1. create a journal entry using at least one account with a secondary currency set
2. balance and save that move
3. change the secondary currency on the line and force it to a different value than the one on the account
4. save. You'd expect an error pop up but the constraint doesn't trigger and you're allowed to save/post
opw-3340697
closesodoo/odoo#126336
X-original-commit: e6581f39ec5d550db924aa7a86dd12f511f87958
Signed-off-by: William André (wan) <wan@odoo.com>
Because if a tag is still linked to a tax or an account, then it's probably also still referenced in a report line, and it makes no sense allowing to delete such a tag.
closesodoo/odoo#125843
X-original-commit: 3b71689954a941b12d8eda1d08c3ad58aca320d8
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Failing use case: While having purchase_stock installed, create and confirm a request for quotation, received some products but no bill for it. Now select the PO is the list, click on 'Action > Accrued Expense Entry'. Make sure the wizard will effectively create an accrued expense entry (it should be the case if you have some product received and not billed).
Upon confirmation of the wizard, the system will recompute the received quantity on the original PO, logging notes that pollutes, confuses and spams its followers.
The reason is that we use a new record to compute the difference between the received and billed quantities at a given date in the past, and even if track_qty_received is called on a newid, it will find back the original PO where doing line.order_id.
The solution is to check in the context if we're in such use case before logging, because we know that calling the accrued expense entry wizard aims not to change the received quantity in any wase
closesodoo/odoo#122720
X-original-commit: b31f1ad789e92c84f85654b67e6730e413f0e06b
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
This comes as a followup of https://github.com/odoo/odoo/pull/120423 where we restrict unallowed users to toggle the field allow_out_payment when writing on res.partner.bank. Similarly, we'll now do the same check at the creation of bank accounts
closesodoo/odoo#120694
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
All figures coming from the accounting dashboard should be, by default, excluding the unposted entries since this is the default filter when opening the reports.
opw - 3268676
closesodoo/odoo#120424
X-original-commit: fd20e65fbfeadcc477ea7179900741dd6e98cf16
Signed-off-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: LucasLefevre <lul@odoo.com>
Failing use case:
Create a vendor bill and use the auto-complete field to select a purchase order multiple times.
The purchase order gets added to the vendor bill multiple times, this doesn't happen in V15 and was never intended.
The reason is simply that the code was checking on self.line_ids which get only populated after the record is saved and its invoice_line_ids are synchronized. Before that, only the field invoice_line_ids is filled witht new_ids.
opw - 3196149
closesodoo/odoo#119758
X-original-commit: 29d5862d447dd369432b345e43d5875d3b2a4474
Signed-off-by: William André (wan) <wan@odoo.com>
Removed annoying error raised onchange of the date/name if they don't match anymore. This was done during the update, which was dumb since it was popping in case you wanted to change both the date and the name. It now only relies on the constraint that is verified upon posting the invoice. Onchange warning is kept only for the format change.
Ensure the date constraint is always verified no matter if the invoice was already posted before, or if we're in quick edit mode: the date's info located in the name must always match the accounting date. This is ensured when posted.
task-2976499
closesodoo/odoo#108116
Forward-port-of: odoo/odoo#107867
Signed-off-by: William André (wan) <wan@odoo.com>
Previously, the context passed in onchanges calls after a o2m modification in the form view were the one of the parent object, whereas it should have been the context defined on the o2m field itself
closesodoo/odoo#103081
X-original-commit: 31ee570d17db2f5e3e2ff6877a7634ab9be12492
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
How to reproduce:
Have 2 different tabs open on the same draft invoice
Tab 1: add a new invoice line
Tab 2: change the partner
Tab 1: save
Tab 2: save
Before the fix:
The new invoice line from tab 1 has the partner from before the change,
but the other lines have been updated to the new partner.
Expected:
All invoice lines have the same partner as the invoice itself
This use case can be reproduced like this manually, but it can happen
easily even on one tab because the OCR acts like the second tab if users
start to edit the invoice before it is scanned.
Note that in a perfect world, a warning would be raised to prevent any
loss/mischief due to concurrent editions of the same record but that's
beyond the scope of a bugfix made on a stable version.
opw-2777390
opw-2762347
opw-2741859
closesodoo/odoo#91705
X-original-commit: 2c5450af8d6f5934e6ab2095c3307b432fa3036a
Signed-off-by: William André (wan) <wan@odoo.com>
when an account.payment object had no partner and no journal, the computation of is_internal_transfer was wrongly computed as True... and the information banner was displayed accordingly
closesodoo/odoo#77122
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
when removing the bank in an account.payment, the method _get_available_payment_method_lines() was called on an empty recordset which wasn't supported.
Part-of: odoo/odoo#77122
* order lines are now not grouped anymore by account. That allows a more detailed label on the accrual entry line, as it's now directly related to a single order line
* we now create a single accrual entry counterpart, instead of one per order previously. That reduces the 'noise' in the accrual entry, at the cost of not having the sum per ordre anymore easilly but it doesn't seem to be important to audit that account
closesodoo/odoo#76037
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
* the cache_invalidate() was invalidating the changes made in the wizard as well, make it impossible to set any value other than the default one, even though the preview entry was updated accordingly. That also prevented to simply validate the wizard as the accrual account was required but reset anytime we changed its value.
* the preview_data field was incorrectly set as Binary while the widget only supports Text
Part-of: odoo/odoo#76037
This allows to solve the following use case:
* we are in March
* a SO created during January shows currently a delivered quantity (timesheet on service or delivered goods on storable products): timesheets/pickings were done in February
* creating the accrued entry for January 31 should display accordingly an amount of 0 by default since everything was done in February
Invoices invoice_dates are also taken into account:
* day 0 : delivered 10
* day 2 : 5 invoiced
* accrued entries for 10 if accrual date = day 1, accrued entries for 5 if accrual date = day 3,
followup of task 2255642
closesodoo/odoo#75886
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- Add "payment_status" field to be more explicit.
- Turn error message "Expenses must have an expense journal specified to
generate accounting entries." into "Specify expense journal in tab
Other Info to generate accounting entries."
closesodoo/odoo#65528
Task: 2424870
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Flow:
- Make an invoice in foreign currency with a given rate
- Register a payment for that invoice, in company currency, worth the invoice amount_residual but with a different rate
=> The cash basis entry was wrongly taking a rate of 1 to make the conversion between the amount in foreign currency and the company currency (see new test)
=> Additionally, the amounts to report on the tax report should always be equal to the ones from the original invoice when it's fully paid. Some tests were wrong in that regard.
In order to fix the issue, the way the cash basis is handling the percentage and the way used to fix all rounding issues at the generation of the exchange difference entry is different:
=> The condition triggering the exchange difference items for the cash basis entry is now handling correctly the case when the payment is made using another currency but the amount in company currency is fully paying the invoice.
=> The complexe method '_fix_cash_basis_full_balance_coverage' defined in order to manage rounding issues on the tax report when the invoice becomes fully paid is no longer necessary since the balance of each account (base + tax account) is automatically fixed by the extra journal items added to the exchange difference.
Indeed, after the generation of the exchange difference journal entry:
- the balance of tax transfer account is now reset to zero.
- the balance of the tax account is exactly the balance of the tax transfer account defined on the invoice.
- the journal items containing the tax base amount is exactly equals to the balance of the invoice lines.
closesodoo/odoo#65939
X-original-commit: 6db073e8f1865991b79b5b31b4a4a77158aa0d15
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Remove the deprecated 446000 Acomptes reçus account
- Create a new account 461000 Acomptes reçus (Current Liabilities)
- Create a new acompte 460000 Acomptes à recevoir (Current Liabilities)
Was task 2205560.
closesodoo/odoo#46714
X-original-commit: 8d6c5c9a2b576b67692ac1d6970d7711f9695c79
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This reverts commit db691dbebf because the appropriate solution was to filter lines with 0 debit and credit during the reverse_move before the reconciliation (which apparently has already been done by another patch).
This patch, however, was causing the followup report to show lines on a receivable account with a partner and 0 balance with 0 way to remove them.
X-original-commit: 6a5271b7f4109a4f2a20378698fbe479d73ed9cb
The recent refactoring made at 30cf7bc798 introduces a new object for the different writeoff lines that could be created from a reconciliation model. Unfortunately, Billing users were forgotten during that refactoring which made them unable to read/use the reconciliation models anymore.
This patch grants them the Read and Create permission on the new account.reconcile.model.line object, as they already have to the reconciliation model.
closesodoo/odoo#42009
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
Only invoices/bills should create their equivalent credit notes when reversed (with tax tags coming from the related repartition lines), other kinds of journal entries should be reversed as misc entries, to negate them entirely in the accounting
closesodoo/odoo#38547
X-original-commit: cdb3ccf811d69dbd18f196614f380349a1335c9f
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
When the only app installed is 'invoicing', people were getting an error while trying to generate the account.reconcile.model from its template. Could have done it in sudo(), truth is: account.reconcile.model object is not security critical
closesodoo/odoo#37622
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Customer invoices and supplier refunds lines involved with taxes will be credit lines, hence their balance must be inversed when shown in the tax audit field.
The method is_inbound() encloses exactly those documents, whereas is_outbound() stands for customer refunds and supplier bills.
closesodoo/odoo#37092
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Removed a browse on partners made in a loop, for a substantial gain of time and DB queries.
Observed gain for a real data DB with 500 partners to print in the aged report:
time (ms) # queries
Before patch 4583 1623
After patch 2932 553
Gain 1651 (36%) 1070 (66%)
closesodoo/odoo#36488
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
shortened the full_reconcile_id column by re-labelling it 'Matching #'. Asked in 2049120
closesodoo/odoo#36445
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
When hr is installed, with 'private' type, you should be member of
hr/officer group to read them, or you'll face an access right error.
closesodoo/odoo#34587
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
* Sales > Orders > Sales Team > traceback with error 'user_type_id' isn't defined on account.move.line.
* Also the move.team_id has to appear in some group by because we're using an aggregate function.
Both bugs have been introduced by beaa30a (aka accounting-pocalypse)
closesodoo/odoo#34570
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Make sure the move, journal and the accounts will share the same company to prevent undeterministic error in runbot ('Cannot create moves for different companies.')
closesodoo/odoo#32759
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Since the invoice validation is well separated from the account entries creation (and made before), the chatter was showing too much status change upon an invoice validation.
This commit makes sure we never consider an invoice paid when its move hasn't been created yet.
closesodoo/odoo#31100
use cases fixed:
1) go in the journal items, filter on unreconciled lines, pick just one and click on 'Action > reconcile', the manual reconciliation widget opens but you directly get the rainbowman and you can't do anything. It's not possible to reconcile the selected entry with a writeoff (to clear a customer account, for example).
2) go in the journal items, select 2 receivable lines for the same amount but that don't have any partner set then click on 'Action > reconcile', the rainbowman directly shows without processing the reconciliation.
To fix those issues, we now clearly bypass the regular methods in case we have active_ids and active_model == 'account.move.line', since they weren't adapted anyway.
also implement real error message when selected lines don't have the same company or account (currently it's displaying a rainbowman): see error messages in 'reconcile()' in account_move.py
OPW #1919727 and #1930957
Co-authored by wan-odoo
closesodoo/odoo#29771
This is essentially a backport of module l10n_be_intrastat_2019 made for
Enterprise v12 + the refactoring needed on the original v10 module to
allow the changes to apply where needed.
Was requested by opw-1887019
closesodoo/odoo#30400
The aged reports were wrongly taking the previous day of the requested date to compute the different report periods.
E.g: An aged balance requested for the 31-12-2018 was excluding entries made on the that exact date and was starting from the 30-12-2018
closesodoo/odoo#30195
utils.round_precision() is expecting a float as precision (0.01) whereas utils.round_decimals() is expecting the number of digits to consider after the coma (2).
The previous code was totally wrong in that regard, which led to reconciliation wrongly considered as total in foreign currency, as long as the amount_currency difference was lower than the currency precision digits.
closesodoo/odoo#30091
Create a vendor payment of 100€
Create a bank statement line with an amount lower than the payment
Open bank reconciliation view
Reconcile the bank statement line with the blue line of 100€, the triangle for partial reconcile appear.
Current behavior:
If you click the triangle, you can reconcile this payment with the statement line but it becomes unbalanced.
Expected behavior:
The triangle should not appear.
Fixes odoo#29654
closesodoo/odoo#29718
Backport of commit 771f65ecf5
Payments created without partner_type (field not required)
were previously not shown anywhere, as well as internal transfers.
opw 1910590
closesodoo/odoo#29647
Better split of invoice_validate() and action_move_create() functions: the later now only deals with the account.move creation while the former assigns missing values (dates) and gets its number. The move now always receives its name from the invoice, which means there's no need anymore of the 'invoice' arg in account.move post() method.
We now also put the origin of the invoice in the move ref, in order to allow searching on that reference in the bank statement reconciliation widget.
closesodoo/odoo#29343
commit 68dafa0620 introduced a solution to hide the Swiss QR code by default, by conditionning its display on the existence of an ir.config.parameter that one could manually add.
This commits creates the ir.config.parameter and relates it with a field in the accounting settings for more convenience for when we'd need to enable it
closesodoo/odoo#28654
The specifications of this feature have not been frozen yet and the feature is not expected before mid-2020. Merging it in stable was premature.
There's now an ir.config.parameter to hide the feature until really needed: a field in the accounting settings will be added in a next version to show it, in the meanwhile people can manually add the parameter to use/test the QR code.
Also fixed all 3 typos/grammar errors in the single sentence message displayed when some pieces of information were missing while printing the QR code
Also fixed the place where the Swiss options for the ISR are displayed in the accounting settings (under 'invoices' instead of 'fiscal periods')
Also fixed a 'not-a-multiple-of-4' indentation.
closesodoo/odoo#28035
When you run the setup wizard to add a bank from the setup bar, it will write 'file_import' on the field 'bank_statements_source'. But in the module 'account_bank_statement_import', the possible values of the field 'bank_statements_source' was updated with 'file_import' ONLY if additionnal account_bank_statement_import_xxx modules are installed.
So, prior this fix, if you only had the module 'account_bank_statement_import' and no additionnal bank statement import modules, you were getting a traceback.
Fixes#27423closesodoo/odoo#27672
This reverts commit c539311. The default taxes will now be found in the invoice's onchange() which makes more sense and will work on all income/expense accounts without having to set the taxes on all these accounts.
In case of a sale receipt including a tax, the error 'cannot create unbalanced entry' was raised illegetimately. The reason was simply that the tax line was defining a debit instead of a credit.
In case there are multiple companies that need to call create_transit_location() at the installation of module, orm was crashing because expecting a singleton when doing self.partner_id or self.id
Previously, the use case where a cash basis tax and a regular one were combined on the same invoice line (for example) was not supported (technically, there's a single boolean for the tax exigibility of the sale/purchase line). Since it appears this is a real need, this have been improved in the generic tax report (in enterprise repo) in revision https://github.com/odoo/enterprise/commit/f7e33b8114d4d649551a155d0ca8cc4f43f1fc01 and this commit fixes the community side, to copy only the base line of the tax exigibile on payments in the cash basis move
The action 'account.action_invoice_tree2' has been changed into a server action, so we want to open the tree view of invoices by modifying some values of the action we should now use the xml reference 'account.action_vendor_bill_template'.
Additionally, the help tooltip is now completed as would do the server action
Commit https://github.com/odoo/odoo/commit/2eb344f23b3a9daa8e7c7ddaead145a8b05b39bf changed the dependancies of l10n_fr_certification which is not acceptable on stable. Instead, the method to check is now moved in account module (to avoid duplicated) and it is called by l10n_fr_certification and account_lock module.
It was very confusing for the user to distinct account.payment and payment.transaction. From now on, the transactions are
technical objects and, in the backend, we only refer to it in log messages (Front end will be adapted in the same fashion
later on). They are hidden in debug mode in accounting\configuration\payments as their purpose is now purely technical/log
This commit also aims to reduce the gap between the accounting app and the transactions: account.payment objects are
created/validated upon completion of transaction.
To ease the capture/voiding of pending transactions, the related buttons are now displayed directly on the SO/invoice
instead of the transactions.
Was task: https://www.odoo.com/web#id=35857&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
Was PR #24043
[FIX] add domain based on journal to payment tokens
Was opw: https://www.odoo.com/web?debug#id=1828206&view_type=form&model=project.task&menu_id=5200
This commits removes a disambiguation on the choices of the 'Adjustment Type' selection as 'in your favor' could be achieved by debitting the 'Collected Tax' account or creditting the 'Paid Tax' accounts (respectively for 'in favor of the Estate'). The choices now refers directly to the journal item where the tax is gonna be copied
Related to https://github.com/odoo/odoo/commit/c58ef14a01f600d75391f2a9c38bb2b30e0e2528
Related to OPW 1826242
Use case fixed: manual reconciliation through the account.move.line list of items with several currencies, that will create a full reconcilation with several exchange rate entries to balance the amounts in all foreign currencies. Unreconciling these lines was wrongly creating an account.move with a lot of lines with debit = credit = amount_currency = 0.
Use case fixed: manual reconciliation through the account.move.line list of items with several currencies, that will create a full reconcilation with several exchange rate entries to balance the amounts in all foreign currencies. Unreconciling these lines was wrongly creating an account.move with a lot of lines with debit = credit = amount_currency = 0.
We now display all the existing currencies (even the unactivated) instead of a link to activate more of them, and upon the save we make sure to activate the selected currency if it's not yet the case. That's better from a point of view since it avoids jumping off of the screen then come back to make this setting
A whole XML file was missing in the initial import which had as effect to still display 'TIN' instead of 'VAT' in the res.company form view even if the module was installed
qdp-odoo