- Share outstanding accounts between multiple journals
- Create payment for each of them
- Go to dashboard
=> "Outstanding Payments/Receipts" amounts are wrong
closesodoo/odoo#70564
Ticket: 2517499
X-original-commit: 39fb6b2990e5d6fda0d5f12dbd64d26ef77b9d0c
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
What are the steps to reproduce your issue ?
1. Go to Account/Journal Items
2. Open a posted item
3. Change product
What is currently happening ?
The product is changed in the account move
What are you expecting to happen ?
The account move lines cannot be changed when the status is posted
How to fix the bug ?
Make the field read-only when the status is posted
opw-2517325
closesodoo/odoo#70533
X-original-commit: 1b8f7ad00e9274b4b8f82ef77864997286611593
Signed-off-by: Achraf <abz-odoo@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Since the payment refactoring, the structured reference of a payment is stored in its ref field, not payment_reference like for invoices. This caused payments never to be matched with highest priorities, as payment_reference_flag was always false, and only communication_flag could match.
To reproduce:
- Have a reconcile model with match_total_amount=False.
- Create a statement line with communication a1b2c3 for 1000
- Create 3 payments:
> 500, with memo a1b2c3
> 500, with memo a1b2c3 (so, the same one)
> 500, with memo d1e2f3
- Open the reconciliation widget for your statement line
===> The 3 payments are matched, while only the two first ones should have been, as they were exact matches for the communication, and should hence have received higher priority.
closesodoo/odoo#70394
X-original-commit: b5800c9d2088df2bb9c4fbe0fed91c7ef24299c5
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
To reproduce the bug:
1) Create a cash basis tax for 42%
2) Make an invoice with two lines at 100$, each using this tax
3) Post and register full payment of the invoice
==> An exchange difference has been generated, doing +100 -100. One of its two line has tax_ids set, while the other does not. This makes the base amount shown in the generic tax report wrong: 100 instead of 200.
Actually, this exchange difference entry shouldn't have existed in the first place, as there is no rounding issue to compensate for here. It happens because the grouping keys computed for the two base lines are the same, and the second line overwrites the totals of the first one instead of adding them to its own.
closesodoo/odoo#70283
X-original-commit: 60770f0b99bedd3dcb695e2191dc83c45ef0b594
Related: odoo/enterprise#18107
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
When the user creates a new account analytic line, he should not be able
to create a new journal item.
To reproduce the error:
(Use demo data)
1. In Settings, enable "Analytic Accounting"
2. Accounting > Configuration > Analytic Accounts > Administrative >
Cost/Revenue
3. Create a new one
4. Click on "Journal Item" list
Error: the list contains the "Create and Edit..." option. Such an action
should not be possible.
OPW-2481197
closes#69881closesodoo/odoo#70399
X-original-commit: f3ef533ed18c996f7f87c9596135e450479a8c19
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>
- Create an invoice with an empty fiscal position
- Create a line with a product having 100.0 as sale price and 21.0% price-included tax
=> price_unit equals 99.99
This is because 100 / 1.21 ~= 82.64 but 82.64 * 1.21 ~= 99.99 != 100.0.
The bug only appears when managing a fiscal position because the code is trying to adapt the product price_unit to the newly computed taxes.
closesodoo/odoo#70276
X-original-commit: 3470a3c94e06d92afcd8a8129f80e4dfea14efe4
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When the same sequence is used in different journals (i.e. BNK1 in two
different companies), a clash might happen in the grouping optimization
of the `_compute_name`
closesodoo/odoo#70152
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
This replaces the setup of the attribute 'currency_field', which depends
on the presence of other fields on the model, and may therefore vary
from one registry to another. This is necessary to make monetary fields
shareable across registries.
The attributes field.depends and field.depends_context are problematic
for sharing fields across registries, because they depend on the model's
registry class, which may vary from one registry to another. In order
to make computed fields shareable, we have to move those values away
from fields.
For the same reason, field.recursive should not be inferred, because its
value may depend on the registry, although it is generally not the case.
Moreover, the flag recursive=True is set on a field when field triggers
are determined (on the registry). A compute method may be called before
the flag is set (if no update has been done yet), and that can lead to
incorrect computations.
This happened in test TestUsers2.test_reified_groups in module 'base'.
The user groups view was apparently determined without the flag being
set, and the view depends on the recursive field 'trans_implied_ids',
which was not correctly computed.
We thus force developers to be explicit about recursive computed fields.
The code now logs a warning when the flag is not set up properly.
Steps to reproduce the bug:
Create an accounting entry AE with $ as default currency
Add a line L1 with 10 € and a tax of 15%
Bug:
The added tax line was 0.75€ instead of 1.5€
opw:2510338
closesodoo/odoo#69995
X-original-commit: 28e85cdbbd499b3fa826c15d4058aa4b83b993c9
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Co-authored-by: smetl <las@odoo.com>
Have a Fiscal position FPOS which map tax A to tax B
Have products DEMO with tax A and DEMO2
Allow FPOS in POS, Open a session, activate FPOS, sell DEMO and DEMO2
Close POS
Go to Orders, select the last one, hit return, edit, delete DEMO2 line
Tax will be wrong.
This occcur because the fiscal position mapping fail an equivalence
check with a virtual record, so the tax is calculated as A and not B
opw-2485399
closesodoo/odoo#69952
X-original-commit: 983797e626f742e84710de7ec8487824d6eaa7f1
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>
The domain for the fiscal position in the carryover lines was incorrect,
missing the required quotes.
closesodoo/odoo#69921
X-original-commit: 85c07f0f93d664bf7f6028a1dfa0f663e2999c3d
Signed-off-by: William André (wan) <wan@odoo.com>
Task 2352493
When the user is asked to fill in the label on the invoice, the tooltip
tells him that the label can be auto-filled by configuring its products.
This leads the user to configure products. But then, as he doesn't fill
in the label, the tour is "broken".
closesodoo/odoo#69871
X-original-commit: 78b5536a4c6fa7a20d8fd182fcd85726c2a8555f
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Steps to reproduce the bug:
- Let's consider two companies C1, C2 and a partner P in C2
- Let's consider an customner invoice I in C1 with P as customer
- Go to Accounting > Accounting > Partner Ledger and select I
- Click on Reconcie
Bug:
An access error was raised due to the ir.rule res.partner company
opw:2446242
closesodoo/odoo#69833
X-original-commit: 2279d84b4aefc8e488ccc33c30b816e988867589
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
- Create an invoice for a portal user
- Add a credit note for that invoice
- Connect with portal user
- On Invoices & Bills menu, the correct count is displayed (i.e. 2)
- Open Invoices & Bills page
The "All" filter only displays out_invoice and in_invoice, making impossible to view
the other types (out_refund, in_refund, out_receipt, in_receipt).
opw-2486471
closesodoo/odoo#69792
X-original-commit: 159bc7b0c081fd54df2f2396b18e9a63892caa2e
Signed-off-by: William André (wan) <wan@odoo.com>
For customer invoices:
* do not set default date because if you prepare an invoice (and it gets
a default date), then validate it the next day, the date will be wrong
* set the date when posting if it wasn't set, because why not?
For vendor bills:
* do not set default date because you rarely encode a bill at the bill
date. Forcing the user to enter it reduces risks of user error
(duplicated vendor bill)
* do not set it when posting, same reason.
opw-2492862
Related #68368Closes#68367closesodoo/odoo#69639
X-original-commit: 41041d8016d11f017d92d28f32ab2cf42f1349a9
Related: odoo/enterprise#17866
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.com>
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>
*, purchase, sale, stock.
Before, the warning messages, if any, were always visible below the
warning option (emplty selection, No message, Warning, Blocking Message),
making it unclear for the user when selecting No message and seeing
the error message just below (as readonly).
Now, make the message invisible if the message option is empty or No Message.
Therefore the user is not confused by not relevant message, and it eases
the message editing process (before, user could see readonly message and
change selection field value before editing).
Task ID - 2481450
COM PR - odoo/odoo#68417
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.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>
- Hide "A second payment will be created automatically in the destination journal." message when
a payment is posted. Used to only check if payment has a paired_internal_transfer_payment_id,
but posted pre14.3 do not have a value for this field.
- Render "destination_journal_id" only required when payment is draft. As it might be NULL on
pre 14.3 payments, and trigger “invalid fields” error when the user interacts with the view.
closesodoo/odoo#69410
X-original-commit: f942e132dc3b5a37f649e0ab2c11627b497d641c
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, when exporting move lines via for example the partner ledger,
we are not displaying the currency in any way in the xlsx.
For some company, this can be limiting since they may want to do
post-treatment inside the file after export, which can require such
information.
This change will add the 'always_set_currency_id' field as optional
into the list view of the amls, allowing to keep the information about
the currency when exporting if needed.
task id #2381355closesodoo/odoo#68911
X-original-commit: 62bad5e50aa1fe579ecc07242a22ec6ab6031e71
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Signed-off-by: Nicolas Viseur <vin-odoo@users.noreply.github.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>
The resequence wizard should consider that the sequence is shared for
invoices, journal entries and receipts; only refunds have a separate
sequence.
You could have journal entries in the purchase journal for expense
reports for instance. In that case, we want to be able to resequence all
of it at once.
closesodoo/odoo#68871
X-original-commit: 365da2a0aca1503133433f9dc66b6866e7867974
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: William André (wan) <wan@odoo.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>
Steps to reproduce the bug:
1/ Create an opening balance Journal Entry with debit 100$ "121000 Account Receivable" and credit 100$ on another account
2/ Create an invoice for 150$
3/ Register a payment of 250$ for this invoice
4/ Reconcile the Journal Item of the payment (with "121000 Account Receivable" as account) with the opening balance => this line should be now fully reconcile
5/ Go to the payment and try to print the payment receipt
Bug:
The opening balance was shown as an invoice
opw:2448349
closesodoo/odoo#68809
X-original-commit: fda784cd6a831fb799767a486320574e754d20df
Signed-off-by: Laurent Smet <smetl@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
This way, the bank account can be easily and immediately configured so that QR-codes can be generated on invoices without any additional setup (for Switzerland and SEPA).
This configuration step is hidden if full accounting features are enabled, since it will then appear in the "main" setup bar, on the dashboard.
Task 2412391
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.
Laurent Smet