All taxes change in Luxembourg, we added a script that will create or update taxes so the clients don't have to
manually update everything or ask the support to do it for them. We don't modify custom taxes.
closes odoo/odoo#108699
Task: 3098941
Related: #104833
X-original-commit: c44a33d67065e20c4ded2a229d0663191c91a0a0
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Claire Bretton <clbr@odoo.com>
Improved the tooltip description of the 'Detect automatically' field for fiscal positions. The previous tooltip was "Apply automatically this fiscal position" while the new one is "Apply tax & account mappings on invoices automatically if the matching criterias (VAT/Country) are met."
task id : 3088331
PR number : #107092
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>
The early payment cash discount functionality was merged in 16.0.
This PR allows for the behavior to be as localization specific as possible.
This concerns :
The tax computation (some countries leave it untouched after the discount, some countries discount it, and Belgium has a mixed behaviour)
The account in which the cash difference resulting of the cash discount should be put.
task- 2983913
related to #99572closesodoo/odoo#102032
X-original-commit: 591757902dcdf1e3609d9c5ae23e2b134ee8e4da
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Camille Spiritus (casp) <casp@odoo.com>
Bank statements are now optional in accounting. The users add statements directly and can assign statements for control reasons.
The users can enter end date and end balance real for the statements and attach the bank statement scan.
The system checks if there is a gap (lines without statement) before current statement and warns the user
with decoration, also we check if the ending balance match the accumulated balance of the last line.
Bank statement lines now show an accumulated balance and can be sorted by drag and drop in the same date, if the user drags a line
to a position with lines of another date, it simply doesn't have any effect.
Rename accumulated balance to cumulative balance, a better name
closesodoo/odoo#99092
Task: 2879904
Related: odoo/upgrade#3906
Related: odoo/enterprise#30824
Signed-off-by: Laurent Smet <las@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 for each payment term lines.
The user can choose between three different kind of tax computation for the discount. If the conditions for the cash discount are fulfilled, the tax will either be:
- included : the tax and base amounts will be discounted.
- excluded : the tax will be left untouched, the base amount will be discounted.
- mixed : the tax is durably discounted, the base is discounted if the early payment occurs.
The discounted amount and the conditions to fulfill are printed below the invoice PDF if the option to do so is checked.
Took the opportunity to improve the display of the payment terms on the invoice in general.
Registering a payment while filling the condition for an early payment discount will prefill the fields accordingly.
The Journal Items in the account.move, the payment and the reconciliation are modified as needed to take the discount into account.
Reconciliation --> In the reconciliation widget, the logic of Early Payments Discounts is also applied to allow as often as possible for an automatic reconciliation.
Related : odoo/enterprise#28607
Task-2968644
closesodoo/odoo#99572
Related: odoo/enterprise#31225
Signed-off-by: Laurent Smet <las@odoo.com>
1- throw an error when creating a model with a name already taken
2- Duplicate action button create a new model with (copy) append to then name
task_id: 2971488
closesodoo/odoo#99581
Signed-off-by: Olivier Colson (oco) <oco@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>
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
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
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>
Task ID: 2717840
Currently:
- Generic_coa has country_id US, which is not valid for non-supported localizations. This creates a bug as the country on taxes and account_fiscal_country_id becomes different.
- Users who only have Invoicing installed can't change the fiscal country setting as it's only available in Accounting.
Desired:
- Set account_fiscal_country_id the same as country_id
- Remove base.us from l10n_generic_coa
- Adjust the error message to make the issue more clear for users
- Allow changing fiscal country in Invoicing
closesodoo/odoo#91363
Related: odoo/enterprise#27332
Related: odoo/upgrade#3264
Signed-off-by: Laurent Smet <las@odoo.com>
These helpers are used to create the repartition lines and the taxes in
the upgrade script which upgrades the tags on the taxes.
See https://github.com/odoo/upgrade/pull/3137closesodoo/odoo#89912
X-original-commit: 8927003d0c32e81d28ece68e61c1a737bd7532d2
Signed-off-by: Olivier Colson <oco@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>
Even if ORM normally filters them out, no need to specify .id in domains.
This leads to better and easier to read queries / domains.
Task-2816580
closesodoo/odoo#85648
Related: odoo/enterprise#24911
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Storno accounting is the term used to described the process of recording
a reverse action as a negative amount on the same site instead of a
positive amount on the opposite site of the credt/debit.
For instance, when one creates a credit note for an invoice, the values
of debit and credit will be kept in the same column with negative signs
instead of swapping columns like in non-Storno accounting.
It is a business practice commonly used in Eastern European countries.
Countries where Storno accounting is mandatory or considered as best
practice would be :
Czech Republic, Poland, Romania, Russia, Slovakia, Ukraine, Croatia,
Bosnia and Herzegovina, Serbia, Romania, China, Russia, Slovenia
It is available as an option in the settings and is automatically
activated for some countries which use this type of accounting.
otask-2064899
closesodoo/odoo#79581
Related: odoo/upgrade#3212
Signed-off-by: William André (wan) <wan@odoo.com>
Co-authored-by: william-andre <wan@odoo.com>
Co-authored-by: qdp-odoo <qdp@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>
Currently Bank Suspense Account has "Current Liabilities" type, while it should be "Current Assets"
Task ID: 2702804
closesodoo/odoo#81491
X-original-commit: c6d2a50499744a9ddbb09a9974d6ab52116ef542
Signed-off-by: Laurent Smet <las@odoo.com>
In multivat setup, we need to create taxes in foreign countries to map them with domestic taxes. Before this commit, this was only possible manually, even though all the necessary information lies in Odoo's account.tax.template objects created by l10n modules.
We now display a banner on top of foreign vat fiscal positions with a button allowing instantiating those templates directly from them when it's appropriate.
closesodoo/odoo#75803
Task: 2453325
Related: odoo/enterprise#20553
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
This task aims to both explain supported reconciliation cases and improve the reconciliation model form view.
The form improvement is mainly about label wording and make the options more self speaking.
Also, disable bypass of the matching amount we do in case the statement line's label exactly matches the payment reference.
It can be replaced by just making a final model that is applied whatever the amount and will do the partial reconciliation on everything that wasn't matched by others.
That's cleaner, as users can way more predict what models can do and debug their config.
closesodoo/odoo#73043
Task: 2427089
Related: odoo/upgrade#2729
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
To make the account.account form view usability better, we'll move around the fields,
add a new smart button to link the account to the taxes using it as well as
add a chatter to keep track of changes.
Task id #2481421closesodoo/odoo#69851
Related: odoo/enterprise#17943
Signed-off-by: William André (wan) <wan@odoo.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>
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>
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.
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>
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>
Task 2124952
Extract all the demo data from `l10n_generic_coa` to a new way of
generating the demo data for accounting modules.
Because the data needs to be created multiple times, and right after the
chart template instanciation, it cannot be done the usual way. Instead,
we use python generators to declare the data. It allows us to reference
data that was not created yet at the start of the creation of the demo.
An xml_id is given, prefixed with the id of the company it is created
for (just like the instanciation of the chart template)
To find the correct accounts, a helper method has been added to
`account.account`. It will look for an account with the correct xml_id
(which is the one of the l10n_generic_coa, that we have to put on the
other l10n modules too, in the future). If it didn't find the xml_id, it
will look for an account with the correct type. If it still didn't find
one, just take any account.
The recent changes in misc improvements broke the loading of the exchange accounts in the chart template.
This change aim to fix that by moving the setup of those accounts back where it was originally done.
Taks id #2319601closesodoo/odoo#57351
X-original-commit: ac328eba96c6f2e34f18f3d4671290683a090c08
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Signed-off-by: Nicolas Viseur <vin-odoo@users.noreply.github.com>
Task 2300900
Easier onboarding.
Because we don't have the correct prefix to use, we set a default '999'
code prefix.
closesodoo/odoo#55996
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Task 2292368
Bundle
https://runbot.odoo.com/runbot/bundle/master-reconcile-model-boost-wan-60105
* Search in Notes and References, not only in the statement's
communication.
* Activate the partner mapping for Suggest Counterpart models
* Always show the Amount Matching field
* Do not block the deletion of models with a partner mapping
* Allow to archive models
* Add a button to get back to Processing state from Validated state on
bank statements.
closesodoo/odoo#55031
Related: odoo/upgrade#1619
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
Using a few regex like
\((_\(.*%s.*)(\) % )([\w\[\]][\w .\[\]\(\)'"]*)\)
($1, $3))
Old syntax is still compatible but starts the migration to the new
syntax that catches error.
Help search taxes more easily by adding an applicability field stating
that the tax should be used only on goods or on services. If not set,
can be used anywhere.
This commits refactors the code of the reconciliation, in order to facilitate the process of complex use cases, namely multi-currencies or cash-basis-taxes related (see details below). It also prepares the code for a second refactoring where we will save on each journal items the amount_currency and currency_id field (even in case of operation made in company currency), also in the sake of simplification.
1) Multi-currencies:
- the account.partial.reconcile model now will have dedicated columns to specify the amount of the partial reconciliation in the debit_line_id currency and the credit_line_id currency. That comes in handy when dealing with journal items having different secondary currencies, but also allows some simplification.
- residual_amount_currency computation changed accordingly
- moved models account.full.reconcile and account.partial.reconcile in their dedicated .py file
2) Cash basis taxes
- cash basis entries now handle correctly rounding errors to make sure the exact amount of gets reported when the reconciliation becomes full.
- the account for the base amount of cash basis entries has to be set, now, on the company instead of on each cash basis tax.
- that new 'property' field can be set at the CoA installation via the field property_cash_basis_base_account_id of account.chart.template, or going through the accounting settings.
Was task task: 2243420
Was PR #50308
Related: odoo/upgrade#1121
Related: odoo/enterprise#10252
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Add sudo in base to allow a unpriviledged user to interact with
ir.property in a safe way usingsetters and getters.
By making them callable without sudo, we encourage to use these
methods instead of making CRUD requests on ir.property directly
For other specific search where no native method exists, add sudo
- Create journal entries as soon as bank/cash statement lines are created, temporary booked on a suspense account set on the journal.
- Simplify the management of "blue" lines in the reconciliation widget. A "blue" line is now a journal item using a temporary liquidity account (outstanding payment/receipt accounts, set on the journal).
- Adapt and simplify the bank reconciliation report.
- Remove the bank reconciliation threshold date. The reconciliation report will show the not already reconciled journal entries using a liquidity account and the not already reconciled journal entries using a temporary liquidity account. Without accounting, an account.payment will involve directly the liquidity account and then, will be considered as a statement line directly.
- Remove the post_at bank reconciliation feature. The "paid" state will be set on the invoices only if reconciled with a journal entry involving the journal's liquidity account.
With invoicing, the payment will do that so the "in_payment" state should never be shown up.
With accounting, only the statement lines have the power to move an invoice to the "paid" state.
- Fix various corner cases about the management of multi-currency in bank statement lines.
- Fix the conversion dates in multi-currency: Since the bank/cash is always used on the statement lines, it will use always the real "bank" date instead of the fictive payment one.
- Ensure the 'reconcile' method will raise an error if the involved moves are not posted.
related enterprise PR odoo/enterprise#7019closesodoo/odoo#41301
--task: 2092096
Related: odoo/upgrade#1018
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Claire Bretton (clbr)