Many country-specific fields were displayed while a company with another country was selected (in case of a multi-company environment).
These country-specific fields are now visible only if one of the selected companies with said country is selected.
closesodoo/odoo#106221
Related: odoo/enterprise#34226
Signed-off-by: John Laterre (jol) <jol@odoo.com>
The aim of this commit is to simplify and standardize the settings archs.
To do this, a small DSL exclusively for the settings was created. This
new DSL introduces 3 tags: `app`, `block` and `setting`.
The `app` tag is used to declare the application on the settings view.
It creates an entry with its logo on the sidebar of the view. It also
acts as delimiter when searching.
```xml
<app string="CRM" name="crm">
...
</app>
```
- `string` : The "display" name of the application.
- `name` : The technical name of the application (the name of the module).
- `logo` *optional* : The relative path to the logo. If not set, the
logo is created using the `name` parameter :
`/{name}/static/description/icon.png`.
The `block` tag is used to declare a group of settings. This group can
have a title and a description/help.
```xml
<block title="Title of group Bar">
...
</block>
```
- `title` *optional* : The title of the block of settings (the old h2),
you can perform research on its text.
- `help` *optional* : The description/help of the block of settings
(the old h3), you can perform research on its text.
The `setting` tag is used to declare the setting itself. The first field
in the setting is used as the main field (optional). This field is
placed on the left panel (if it's a boolean field) or on the top of the
right panel (otherwise). The field is also used to create the setting
label if a `string` is not defined. The `setting` tag can also contain
more elements (e.g. html), all of these elements are rendered in the
right panel.
```xml
<setting string="this is bar">
<field name="bar"/>
...More elements
</setting>
```
- `type` *optional* : By default, a setting is visually separated on two
panels (left and right), and is used to edit a given field. By
defining `type='header'`, a special kind of setting is rendered
instead. This setting is used to modify the scope of the other
settings. For example, on the website application, this setting
is used to indicate to which website the other settings apply.
The header setting is visually represented as a yellow banner on
the top of the screen.
- `string` *optional* : The text used as label of the setting. If it's
not defined, the first field is used as label.
- `title` *optional* : The text used as tooltip.
- `help` *optional* : The help/description of the setting. This text is
displayed just below the setting label (with classname
`text-muted`).
- `company_dependent` *optional* : If this attribute is set to "1" an
icon is displayed next to the setting label to explicit that
this setting is company-specific.
- `documentation` *optional* : If this attribute is set, an icon is
added next to the setting label, this icon is a link to the
documentation. Note that you can use relative or absolute path.
The relative path is relative to
`https://www.odoo.com/documentation/server_version`, so it's not
necessary to hard-code the server version on the arch anymore.
closesodoo/odoo#106425
Task-id: 3081367
Related: odoo/enterprise#34337
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: "Michael Mattiello (mcm)" <mcm@odoo.com>
Due to the deprecation of t-esc to the unique use
of t-out in the rendering template, this replace
every usage of it and ensures everything continues to
work as inteded. Removing deprecation warnings
polluting terminal
deprecation commit: odoo/odoo:9ce5bc8881ae06b613ef61eb07453b224f62bae6
closesodoo/odoo#103731
Related: odoo/enterprise#33037
Signed-off-by: William André (wan) <wan@odoo.com>
This commit adapts account's model to the new report engine introduced for v16, and updates the data files accordingly.
account.report model is now declared in community, together with the other models used by the reporting. This is done so that the tax tags can properly be created by the tax report and used on tax templates. All the actual computation logic stays in enterprise.
See enterprise commit for full details.
Task 2524389
Part-of: odoo/odoo#94125
Current behavior:
The invoice payment term of the report is a p tag with another p tag inside like:
<p name="payment_term">
<span>
<p> This is a payment term note</p>
</span>
</p>
but because nested p tags are not supported in html de result in the browser is something like:
<p name="payment_term">
<span></span>
</p>
<p> This is a payment term note</p>
<p></p>
Similar behavior can be observe for the fiscal position note.
Expected behavior:
The code should respect html format rules and not have nested p tags.
Solution: We replace the parent p tags by div tags, and we modify xml file that have xpath relying
on this tag.
opw-2804933
closesodoo/odoo#88660
Related: odoo/enterprise#26372
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Task: 2817024
1. l10n_cl uses _prepare_tax_lines_data_for_totals_from_invoice() and _get_tax_totals() to prepare invoice totals for exporting invoices in pdf.
After the recent changes these methods no longer exist and invoice totals should be calculated in a different way.
2. Contact widget should not have ```'no_tag_br': True``` anymore to show the address properly.
closesodoo/odoo#88144
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
[FIX] l10n_cl: adds new latam reference document types
[FIX] l10n_cl: add additional document references
[I18N] l10n_cl: translate as T.doc to reduce width of column
[FIX] l10n_cl: add l10n_cl_active to latam document type view
[FIX] l10n_cl: change account 410235 to direct cost instead of expenses
[FIX] l10n_cl: change account withholding of second category to most recent tax rate (-11.5%)
closesodoo/odoo#75865
Related: odoo/enterprise#20565
Signed-off-by: Josse Colpaert <jco@openerp.com>
Adapt the module to calculate removed fields from latam localization
closesodoo/odoo#78296
X-original-commit: 9269ac23e86cfd0218234360ac8271785697a725
Signed-off-by: Josse Colpaert <jco@openerp.com>
Co-authored-by: Juan Jose Scarafia <jjs@adhoc.com.ar>
A new field on tax groups makes it now possible for this group to be displayed under a subtotal label. If not set, this defaults instead to "Untaxed Amount", keeping the traditional behavior. This is intended for withholding taxes, which can now be implemented with negative taxes and a tax group with this field set.
To do that, this commit entirely refactors the way amount_by_group worked, and replaces it with a more complete json field called tax_totals_json. It also streamlines the way taxe totals are displayed on invoices, PO and SO and makes it so that a common code is called instead of copy-pasting the same block 3 times as before.
[IMP] purchase: always display tax totals by groups on purchases orders
Before, tax totals on purchase.order's form were not shown by group, and were instead all aggregated in a single "Taxes" category. The same went for the pdf export. The portal view, though, did show the totals by group. We now display the tax groups in the same way all the time.
closesodoo/odoo#74138
Task: 2457374
Related: odoo/enterprise#19802
Related: odoo/upgrade#2670
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- latam document type was used in l10n_cl_sequence_ids and used the same
table in l10n_cl_journal_ids but it was never used any where
task- 2464212
closesodoo/odoo#71095
Related: odoo/upgrade#2478
Signed-off-by: Josse Colpaert <jco@openerp.com>
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>
Issue
- Install "Accounting" & "Studio" modules
- Go to "Accounting" and switch studio editor
- Go to "Reports" tab and select "Invoices" report
- Click on any block to edit.
Not possible to edit document.
Cause
Studio cannot parse dynamic `t-call` and therefore not able
to render the corrects hooks to edit the report.
The issue has been introduced by this commit: https://github.com/odoo/odoo/commit/5c5710ae8ea045569fd94504f9d8dd5209f7b662
Solution
In the corresponding localization report template,
add an 'Inheritance Specs' (position="after") that will add a condition
where it will retrieve the rigth report name
in case localization enabled.
opw-2362257
closesodoo/odoo#60660
X-original-commit: ee1580a85c9942e9a98748fa568f9f664c67a320
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: bon-odoo <nboulif@users.noreply.github.com>
It is now possible not to format integers according to locale
This is particularly interesting and relevant when a number holds
some sort of code rather than a number
Task 2050119
*: base, fetchmail, l10n_cl
closesodoo/odoo#39767
Related: odoo/enterprise#6964
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
- 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>
There are few fields added on settings and on company form view
by various l10n modules which are meant for particular country's
user and are of no use to others. Such fields should be hidden
from unrelated users. With this commit, it will be the case.
closes odoo/odoo#35755
Task: 2049977
Closes: #35755
Related: odoo/enterprise#5158
Related: odoo/enterprise#5158
Signed-off-by: Josse Colpaert <jco@openerp.com>
Task 2146469
Rework the name computation:
* It doesn't use ir.sequence anymore
* It is an editable computed field
* Add a renaming tool
This allows the user to tweak the sequences more easily than having to
get through the ir.sequence settings.
The sequence depends on a parameter of the journal: continuous, montly
and yearly restart of the sequence. Everytime a new period is started,
try to make a pattern form another period.
The incrementing is done by taking the previous name, ordered
lexicographically, splitting it by taking the digits at the end, adding
1 and re contstruct with the prefix.
** This means there could be cases where the prefix has a big importance
on the next number. For instance, if you have
INVOICE/2019/0001
INVOICE/2019/0002
and then rename the last one to INV/2019/0002, don't expect the next
number to be INV/2019/0003. It will be INVOICE/2019/0002 (again) because
the highest number was INVOICE/2019/0001.
You will then end up with
INVOICE/2019/0001
INV/2019/0002
INVOICE/2019/0002
closesodoo/odoo#41485
Related: odoo/enterprise#7189
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
- 'partial' payment state corresponds to invoices whose payable/receivable move line has been partially reconciled with some other line.
- 'reversed' payment state corresponds to entries that have been cancelled by the creation of a single reverse entry (using the dedicated button on the form view). This state can be set on invoice as well as on regular entries.
=> To stay consistent with the naming conventions, this commit also renames invoice_payment_state field to payment_state, since it's no longer only applicable on invoices.
closesodoo/odoo#41723
Related: odoo/enterprise#7202
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Description:
- Add readonly attribute to partner view for l10n_cl_sii_taxpayer_type field for children res.partner records.
- Fix the tax payer type label to prevent usage of "label for.."
- Optimize document type order to put most used on top of file and in selection of document types during invoicing process
closesodoo/odoo#41372
X-original-commit: 4162b9b618ffe62548e9a1d5ae3c0fdd604a1395
Signed-off-by: Josse Colpaert <jco@openerp.com>
[FIX] add account asignation to taxes
[FIX] Fixes after code review
[FIX] remove default value for taxpayer_type
[IMP] add an empty section in res_config_settings_view as a holder
for any Chilean Localization future configuration setting.
[FIX] change location of Chilean Localization section
closesodoo/odoo#37555
Signed-off-by: Josse Colpaert <jco@openerp.com>
and preparation for the edi module
This module now depends on l10n_latam_base
for the identification types and
l10n_latam_invoice_document for the invoice numbering.
It has its own implementation where you can choose
yourself the sequences you want to add on a journal in
a many2many. By default, you will have the sequences
for the document types of the first journal. But you
can share them on other journals or create new sequences
for a journal.