Steps to reproduce the bug:
- Let's consider a journal J with inbound payment methods PM1 and PM2
- Create an inbound batch payment with Bank = J
- The default payment method will be PM2, change it to PM1
- Create a payment P in the batch content (payment_ids)
- Save
Bug:
A UserError was raised: The batch must have the same type as the payments it contains.
because when setting a partner on P the function _compute_payment_method_id defined in module account_check_printing
was triggered and the first available payment method was set.
opw:2495487
closesodoo/odoo#69683
X-original-commit: 683c3fd267162c93cb278fd903152ac387e6aba6
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Generic chart of accounts such as Syscohada don't have any country_id set. When installing them on a company without any account_fiscal_country_id, no country could be assigned to the account.tax being created, hence crashing, as country_id is required on account.tax. We now prevent that by raising a more comprehensive error.
closesodoo/odoo#69593
X-original-commit: a253bf331b2448194106523b9c3d753fb6ddd04a
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Before this commit, such configuration wasn't allowed.
However, in some countries, this is mandatory, when dealing with eco-tax for example:
Suppose t1, t2 being taxes where:
- t1 is include_base_amount, price_excluded, fixed tax of 10 (eco-tax)
- t2 is include_base_amount, price_included, percent of 21%
The computation on 1210 should be:
price_excluded: 1210 / 1.21 = 1000
price_included: (1000 + 10) * 1.21 = 1222.1
closesodoo/odoo#69449
X-original-commit: 2bb9e68b546db191b2a88b787a865548d8107bcd
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Before this commit, There would be Expected singleton error
on changing Credit/Debit for multile account in single call.
Now, We are proocess one record to set `_set_opening_debit_credit`
closesodoo/odoo#69474
X-original-commit: 8fe9f552ed4591795b449f4d1e32e1563ce43ca2
Signed-off-by: William André (wan) <wan@odoo.com>
When an auto-validating reconciliation model is defined for matching
bank statement lines to invoices, it was possible to get a traceback
when the bank statement lines were in a certain order and matched in a
certain way.
In particular, if the first bank statement line is priority 3
(communication_flag True) and the amount is an exact match with the
invoice, it will be instantly reconciled. If there's a second line
that's a priority 5 match, it crashed because _filter_candidates didn't
take into account that candidates_by_priority could be empty if the
candidates were already reconciled.
Instead we just return an empty list of candidates and priorities when
this happens.
closesodoo/odoo#69331
Ticket: 2507189
X-original-commit: e9538d9cee092e034b85187a2eae857349f42ce7
Signed-off-by: William André (wan) <wan@odoo.com>
Beforehand, users could configure an account as non reconcilable
even when it was configured as a payment credit or debit account
in a journal. This prevented journal items to be reconciled
Now, when a user tries to set an account as non reconcilable,
we check if there is no journal with a payment credit or debit account
set to this particular account. If there is at least one journal,
then we display an error message stating the journals names and ids
that the user would have to modify before changing the account
configuration.
closesodoo/odoo#69317
X-original-commit: 87c207f3a408abb93d9b8378ef4aa1744935d86d
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Julien CHEVREAU <Julien-CHEVREAU@users.noreply.github.com>
Beforehand, if two users independently opened a draft
invoice on their respective sessions, then both of them
clicked on the "Post" button, then the invoice was
posted twice.
On a more general aspect, the view currently "prevents" users
from posting moves several times, but technically speaking,
nothing stops users from posting moves several times.
Now, after checking that the user indeed has the right to post
a move, the next check is about verifying that the move is
not already posted.
opw-2479201
closesodoo/odoo#69178
X-original-commit: b7db7db283d7b9d167201b791e6282b022d59c40
Related: odoo/enterprise#17658
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Julien CHEVREAU <Julien-CHEVREAU@users.noreply.github.com>
1. Reconcile of a bank statement, checking the "To
check" box on the manual operation before validation
2. Go to accounting dashboard
The statement line will not be counted in the "to check" action.
This occur because the action only filter on reconciled moves
This reverts commit 6b0017ffda.
opw-2475663
closesodoo/odoo#69135
X-original-commit: 4f2ba741af913c36dd944070b6cbe5aaf682ced6
Related: odoo/enterprise#17637
Signed-off-by: William André (wan) <wan@odoo.com>
* If `where_clause` is empty, then there will be an error. This commit fixes that.
closesodoo/odoo#69100
X-original-commit: f0a1bb3692e17334850fed4f22444f47992adb78
Signed-off-by: William André (wan) <wan@odoo.com>
Currently, the company_id of an account move is related to its journal.
This means that if you empty the journal field, the company_id is also
emptied.
This is then causing a traceback when adding a new line, for example.
This change will transform the related company_id in a computed field,
making sure to not lose the company_id if the journal_id is emptied.
task id #2392004closesodoo/odoo#68886
X-original-commit: c3c6ec69a0c50daf0b33df62144b6cd2f254a4f5
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Nicolas Viseur <vin-odoo@users.noreply.github.com>
When a tax is deleted,
remove the `account.tax.repartition.line` linked to it as well.
closesodoo/odoo#68847
X-original-commit: 0731976cf0e3c6d47658ed1cbfbb8ace7428994e
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Beforehand, tax exigibility was not systematically recomputed upon
move creation.
Now, as soon as an account move line is created on a move, tax exigibility
is recomputed.
closesodoo/odoo#68832
X-original-commit: df14e157fc7a80a1675b9581e0105891b4228f40
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Steps to reproduce the bug :
- Go to accounting > Configuration > Reconciliation Models
- Create a new reconciliation model
- Select the “Match existing invoices/bills” type
- In the field “Match Invoice/bill with” choose “Label”
- Add a new partner mapping > encode in "Find text in label" an erroneous regex like “*test” > choose any partner
- Go to accounting Dashboard > click on “Bank”
- Create a new Bank statement> add new transaction without selecting “Partner”
- Post the created bank statements > Reconcile it
Problem :
An error is triggered because the regex is wrong.
opw-2473973
closesodoo/odoo#68755
X-original-commit: cd9c071c9357cef14635ef094a9f14fc5431956c
Signed-off-by: William André (wan) <wan@odoo.com>
Demo data is not usually updated. It was also deleting the demo data
when doing a `-i account` when the module was already installed (or
actually the chart of accounts instantiated)
closesodoo/odoo#68802
X-original-commit: 8e4b7db8fe9f7c7cef1939938e9fa3df0dddc1f4
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
- On accounting settings, activate 'Cash Basis';
- Select a 'Base Tax Received Account';
- Modify a purchase taxes, and set the 'Tax Due' to 'Based on Payment';
- Set a 'Cash Basis Transition Account';
- Be sure that the previously selected account allows reconciliation;
- Create a Vendors Bills, using the modified purchase tax;
- Register a payment;
- Reset to draft the vendors bill.
Before this commit, an error was raised : 'Record does not exist or has
been deleted.'
This occurs because when trying to unlink the partial reconcile, it will
first reverse and unlink the tax cash basis partial reconcile moves.
After when trying to access the partial reconcile to unlink the error is
raised because one is already unlink.
Now, the vendors bill is correctly reset to draft.
opw-2477526
closesodoo/odoo#68754
X-original-commit: 72c29b105bdb4da5b306cd3b48a1683c1bf3e620
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: Laurent Smet <las@odoo.com>
Account move view improvement and creation of amount_total_in_currency_signed
to allow display of amounts in company currency and in move currency.
closesodoo/odoo#66069
Task: 2403336
Related: odoo/upgrade#2331
Related: odoo/enterprise#16308
Signed-off-by: William André (wan) <wan@odoo.com>
The Payment form view is simplified for a much less cluttered screen.
A paired internal payment is now created when an internal transfer is posted.
Task: 2403336
In belgian accounting, some tax lines in the tax report must be carried
over to the next period if they are negative.
If the balance for the next period is positive, it will be deduced by
the maximum possible amount that is carried over. If it is negative,
the negative balance will simply be added to the carried over balance.
This process repeats itself from one period to the other endlessly,
until the carried over balance come back to 0.
This is done by putting the carried over balance in dedicated analytic
accounts.
task id #2271978
Before, account_fiscal_country_id was only use for tax operations; and country_id was used for all the other accounting stuff. Now, with the new ability to use foreign tax reports (with foreign VAT fiscal positions), we can generalize the fiscal country, sot that it is the one that needs to be used for the whole accounting. Since foreign tax reports were not supported before, account_fiscal_country_id is already set on existing database as the country for the "main" accounting, so the impact of this change is small.
closesodoo/odoo#68349
Related: odoo/upgrade#2322
Related: odoo/enterprise#17299
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Such fiscal positions define an alternate VAT for a specific region. When foreign_vat is set, a country must be set on the fiscal position; it'll be used to know for which tax report the fiscal position must be available as an alternate VAT (in the tax report; see enterprise branch). Note that it is possible to defined several foreign VATs for the same country, as long as they belong to different states within that country.
Note that this new feature is only for FOREIGN stuff; so, when you have to submit a tax report in different regions than yours. For example if you have a Belgian accounting, have French customers, and have a French VAT in addition to your Belgian VAT, to submit a tax report in France. For domestic operations, simply use your the vat field of your company, just like before.
[IMP] account: add country_id on taxes and filter them on invoices
The invoices now compute the country from which they should accept the taxes: it's either the one defined by fiscal_position_id.country_id (if fiscal_position_id is a foreign VAT fiscal position, i.e. it defines a foreign_vat value), or the company's account_fiscal_country_id.
Taxes from other countries are filtered from the view; we don't want them to be available there. There is also a constraint ensuring that. Same goes for tax repartition lines and tags from other countries.
We don't want to mix taxes, tags and foreign VAT fiscal positions from different countries, as it would break the tax report in enterprise. Doing this ensures the tax report can efficiently discriminate the move lines between the different regions whose report they have to appear in.
[IMP] account: add country_id to account.chart.template
This is done so that the taxes are created in the right country, and the fiscal country is initialized in a consistent way when instantiating the CoA on the company.
[IMP] account: print foreign VAT on invoice instead of company VAT if one is defined
[IMP] web: allow forcing company vat on document templates
This is done to allow the use of foreign vat fiscal position on invoices: in that case, we don't want to use the company VAT, but the value of fiscal_position_id.foreign_vat. So, when such a value exists, the invoice simply set the force_vat variable to the right value.
[IMP] base_vat: also validate VAT of foreign VAT fiscal positions
We generalize the code formerly only done for res.partner so that the foreign_vat field of account.fiscal.position can be checked in the same way.
Before, we only cheked the name to know whether or not there were moves forbidding the deletion of the whole accounting to replace the CoA. This was too strict, as an accounting with only draft moves couldn't do it if some move had a sequence number (which could happend with moves that were reset to draft). If everything is in draft, we want to allow such deletion.
We don't check anymore that a move has been posted before in order to allow its deletion. Instead, we look at its sequence: if it's set and is not at the end of the sequence chain it belongs to, we know removing the move will create a gap, whatever the move state, so we forbid it.
If the user really wants to remove the move anyway, it is possible, by manually emptying the name of the move to delete. This way, he won't have any sequence anymore, and will be deletable. Users should however, rather rely on move cancellations and reversals, just for the sake of a cleaner accounting.
User may use Settings menu just to click "Manage Users" buttons. Such simple
navigation sends ``create`` request, which may trigger a chain of
recomputations. To avoid that we redefine ``create`` method to check if a value
is really changed.
The previous explicit implementation lacks in v14 two fields at least:
* from module `account`
```
qr_code = fields.Boolean(string='Display SEPA QR-code', related='company_id.qr_code', readonly=False)
```
* from module `enterprise/account_reports`
```
account_tax_fiscal_country_id = fields.Many2one(string="Fiscal Country", related="company_id.account_tax_fiscal_country_id", readonly=False)
```
Performance Tests
=================
In this test we click "Manage users" and check stats for
``res.config.settings/create`` request.
Demo database with eCommerce and Accounting app installed:
```
| | Number of queries | Query time, sec | Remaining time, sec |
|--------+-------------------+-----------------+---------------------|
| Before | 707 | 0.325 | 0.215 |
| After | 382 | 0.283 | 0.174 |
```
The same, but with extra 1400 invoices:
```
| | Number of queries | Query time, sec | Remaining time, sec |
|--------+-------------------+-----------------+---------------------|
| Before | 715 | 0.459 | 0.349 |
| After | 382 | 0.176 | 0.107 |
```
---
opw-2489335
closesodoo/odoo#68620
X-original-commit: 5e3f37191a4687b305e2337780c7f10278f6a7aa
Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Before this, due to the order the lines were interated on (their sequence), some lines were duplicated without parent, making the duplicate report's layout different from its parent. We now ensure we treat the lines in an order that guarantees the parent line has always been copied before its children.
closesodoo/odoo#68011
X-original-commit: c815342b986851e0a4733ed5bf9fbcc7f8fb7442
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
It shouldn't be possible to create refunds on misc journals, as the tax report would compute the wrong multiplicator sign, and hence end up being entirely wrong.
Introducing the constraint also allowed finding an issue within _move_autocomplete_invoice_lines_create: some tests directly create an invoice by giving it line_ids instead of using the invoice_line_ids helper. The former implementation of this function made it so that the default type wasn't set in the context properly, and these tests were putting their invoices on misc journals. We fix this here as well.
closesodoo/odoo#67965
X-original-commit: fdc96de0e411760f84a78c36543f9157332346de
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Allow creating a journal entry in the past after having changed the
sequence number reset on newer sequences.
opw-2445559
closesodoo/odoo#67963
X-original-commit: 26a43f23ec2b2490aec0731e25568703729581f0
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
The crash manager doesn't recognize ImbalanceJournalEntryError as
a user error and when creating a journal entry that is not balanced,
a traceback is shown instead of the normal UserError dialog.
In this commit, we fix this issue by getting rid of the new error
and put back the use of UserError when checking the balance of an
account move. We also make sure that the feature in pos where we
show a wizard to unblock the user from closing session with
imbalance amount is intact.
closesodoo/odoo#67743
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Fine tuning of f816c326f348ff78a982f91a736cc005d3e0cd31
We should not look at the `seq` when grouping again.
opw-2472061
closesodoo/odoo#67788
X-original-commit: fd36a69a6ed1484d6b7570dae3ff63d3f12ad035
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Issue:
- Activate "Analytic Tags" and "Analytic Accounting" Settings
- Create an Analytic Tags and select "Analytic Distribution"
- Create Product -> Product type: Storable product, Update Quantity as
100, Sales Price like 100
- Product category -> Costing Method: Average Cost (AVCO)
Inventory Valuation: Automated
- Create Analytic Defaults Rules -> select created Analytic Tags
& Product.
- Create a SO -> Confirm it -> Delivery -> Validate it
then system give validation message message:
"The operation cannot be completed: another model requires the record
being deleted. If possible, archive it instead.
Model: Analytic Line (account.analytic.line),
Constraint: account_analytic_line_group_id_fkey”
But can be validated from the Inventory app.
Technical information:
It is due to the `default_group_id` in context put in
`action_view_delivery` method, it context key allows to create delivery
(tree view of `stock.picking`) with the correct `group_id`
("Procurement Group").
But the this name field is also used in the
`account.analytic.line` model. Moreover, the
the `_prepare_analytic_distribution_line` doesn't return any value for
`group_id` which means, that at the creation of the
`account.analytic.line` the `group_id` (id of `procurement.group`)
which will wrongly used.
Solution:
Because the `group_id` field on `account.analytic.line` is a related
store of `account_id.group_id`. We can set it directly in the
`_prepare_analytic_distribution_line` with the correct value.
opw-2442493
closesodoo/odoo#67780
X-original-commit: c9f55c5ecf174414f8e9ed6df56170ac2c6d6e3e
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce the bug:
- Create an Expense E
- Create a report R from E in the journal J (type=purchase)
- Generate the journal entry JE from R
- Go to Accounting Dashboard and click on J in the kanban view
Bug:
JE was not displayed in the entries filtered for J
PS: When creating a journal entry from an expense sheet, the move_type of the entry
is 'entry'.
opw:2474729
closesodoo/odoo#67674
X-original-commit: 31ca461ee3a6b9560fe6d78642e8fe5017b1085e
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
In India, we need to configure taxes like this:
- 6% applied on base amount
- 6% applied on base amount
- 1% applied on 1.12 * base amount
If both 6% taxes are affected the base of subsequent taxes, it gives the following result:
- 6% applied on base amount
- 6% applied on 1.06 * base amount
- 1% applied on 1.06 * 1.06 * base amount
Thanks to the new 'is_base_affected' field set on the second tax, it gives the expected results.
closesodoo/odoo#66134
Task: 2343958
Related: odoo/upgrade#2254
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Account move synchronization has already taken place during the creation
of the moves. No need for this additional check during the
reconciliation itself.
This commit helps when a lot of move lines are being reconciled at once.
For instance, the duration of the reconciliation of a batch of about 700
payments on a large database took 20 minutes before this commit, and
takes about 4 minutes after this commit.
closesodoo/odoo#67447
X-original-commit: e883fffaebd05727b399b26ca86cc54df79cde93
Signed-off-by: Laurent Smet <smetl@users.noreply.github.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>
Now when duplicating a bank or cash journal, the outstanding accounts are
the same as the original journal.
Added a compute method for payment_credit_account_id and payment_debit_account_id
to retrieve the default value from the company. These default accounts can be
changed in the settings.
Change UI for some settings (Default accounts).
Moving transfer_account_id into account module (from account_accountant).
Changing the tree view of account.journal:
- Edit journal_group_ids: Optional show
- Add currency_id: Optional hide
- Add code: Optional show
- Add default_account_id
- Add payment_debit_account_id: Optional hide
- Add payment_credit_account_id: Optional hide
- Add active: Optional hide
- Edit company_id: Optional hide
Task ID: #2451842closesodoo/odoo#66087
Related: odoo/enterprise#16314
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
In case a yearly sequence is set for out_invoice/in_invoice types and if we set
a monthly sequence on the corresponding out_refund/in_refund type, we will not be
able to validate the refund the next month as it will be wrongly identified as a
yearly sequence. We should include the move type when retrieving the last
sequence name instead.
X-original-commit: 612f453a7424c582ba0f581b241d9a41f8908e2c
When reconciling a statement line from the bank reconciliation widget, the journal entry of the statement line is already posted and then, the analytic lines was never created.
This commit fixes the issue by refreshing the analytic lines at the end of the statement line's reconciliation.
closesodoo/odoo#66850
Opw: 2466236
X-original-commit: 2c38dc6e34ebb8d4590adead74ebf02fee40d66a
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Suppose an invoice of 1200USD = 3600EUR reconciled with a payment 1800USD = 3600EUR.
The generated exchange difference journal entry is:
600USD = 0EUR because 1800 - 1200 - 600 = 0 and 3600 - 3600 = 0
=> Everything is reconciled and all residual amounts are 0.
Remove the reconciliation. The exchange difference entry is reversed in other to cancel it.
Because the current exchange difference entry contains a line of 600USD, the reversal is creating a line of -600USD.
Before this commit:
Because both lines were sharing the same foreign currency (EUR) but have an amount_residual_currency of 0, no partial was created and then, a new exchange difference was generated in order to fix the amount_residual of 600 in USD.
After this commit:
A partial is created to handle the residual amount in USD even the residual amount in foreign currency is already zero.
Note: this issue is also there when the reconciliation is made using the company's currency with different foreign currencies.
In that case, amount_residual is zero but not amount_residual_currency.
closesodoo/odoo#66825
Opw: 2450699
X-original-commit: 07d5735de0e1b3080676ab26e872e55120fa2628
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When printing an invoice, the server tries to register one attachment as
main one (see #65320). However, if there is not any attachment, this
will raise an error.
OPW-2465995
closesodoo/odoo#66755
X-original-commit: 03d2e457b69b07f315187cd7f7299be4c838e177
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
There is only a single mail template for invoices at the moment.
To make things easier to work with, this will add a new template for
credit notes.
Task id #2343331closesodoo/odoo#58244
Signed-off-by: William André (wan) <wan@odoo.com>
Goffin Simon