The uom must be displayed to the customer in any case.
Otherwise a customer couldn't know the modalities of a contract
(ex: a contract of one year or one day)
Fine tuning of 342dd5f
opw:2411108
closesodoo/odoo#65048
X-original-commit: 29fb2f93d218109edd1db1e94555bf4b58d25158
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Currently, When viewing the 'Quotation / Order OR invoice' report in pdf,
the metadata fields are correctly aligned next to one another but not
aligned in html/studio view.
So in this commit, col-auto will apply the width 100% in html
due to that the metadata fields are comes in new line. so apply the
class col-3 so each field should come in single line in html with
flex.
closesodoo/odoo#63013
Taskid: 2369335
X-original-commit: 484bcef82cec785b9917634680dea90cb56247e4
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
For the graph views based on reporting models (e.g sale.report), click
on a group in the chart redirects the user to an "empty" list view. Here
we use the attribute disable_linking to avoid that redirection for those
views.
Task ID: 2336960
closesodoo/odoo#57622
X-original-commit: 0b0ae92b6bdac25843ba24d767dbcab3b75703e5
Related: odoo/enterprise#13192
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Replace wrong usages of any(list|recordset), by any(generator)
to speed up computations, avoiding list creations and/or looping twice on a recordset
for nothing.
any([generator]) => any(generator)
any(filtered) => any(generator)
closesodoo/odoo#55768
Related: odoo/enterprise#12360
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
- Create a product with a very long product description
- Add in a SO and print the quotation
The description overlaps with the table header on the second page.
This is a known issue of wkhtmltopdf (see issues 1770 and 1524 for
example), and there is no known workaround. It can be avoided by
preventing the repetition of the header.
closesodoo/odoo#53990
X-original-commit: f54c73f9a42476e1f0d2de1904644f317ee1dffb
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Due to the row_number in the sale.report view, all queries using this
report were slowed down drastically as soon as there were a large amount
of sale.order.lines.
By using existing columns instead of computing new values at each query,
the queries execute in an acceptable time (even if the CASE statements
introduced by e7d8e26ae7 are still slowing down things a bit).
When there is no sale.order.line, min(l.id) would be NULL, so the
sale.order will be used instead. It is negated to avoid id conflicts.
However, note that addons/pos_sale/report/sale_report.py is not doing
anything to avoid conflicts between the ids of sale.order.line and
pos.order.line when doing its union.
closesodoo/odoo#53750
X-original-commit: 03bd6f5243e189cd05b3fc7ad774cc07ea733e14
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>
Task 2206699
* All the amounts are now expressed in the company currency
- The amounts are taken from debit/credit on the aml
- When opening the report for multiple companies, convert in the
current company's currency
* New default view:
- Group by month instead of category
- Line chart instead of bar chart
- Filter on customers
* Remove useless fields:
- name
- invoice_partner_bank_id
- invoice_payment_term_id
- residual (including taxes)
- amount_total (including taxes)
- nbr_lines as it is a generic feature
* Rename currency_id to the more correct company_currency_id
* Remove useless group_by clause from the SQL query
closesodoo/odoo#47066
Related: odoo/upgrade#1021
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
- Purpose is to include orders that have no lines
in the sales report for consistency
- In report, 'Quotation' filter shows quotation which
is in 'draft' or 'sent' stage.
task-2122948
Closes- #42662
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Steps to reproduce the bug:
- Let's consider a sale tax T
- Allow Pro-forma in Accounting configuration
- Create a SO with a line of 100 and T on it
- Print the Pro-forma invoice
Bug:
The base amount of T was not displayed next to T below the subtotal
Inspired from report_invoice_document
opw:2172383
closesodoo/odoo#43837
X-original-commit: 472918686fcc723cc6bb30aefacadf00b0cdc31c
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The discount_amount didn't consider the quantity on Sales Order Line.
e.g:
100€ | 10% discount | 8 products
--> discount_amount was 10 € instead of 80€
Fixes#43242closesodoo/odoo#43624
X-original-commit: b8a1370c7bebe71b968555a6c9e5137c4e7cda8b
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
The _get_report_values method is an api.model, not an api.multi (on a purely ORM
consideration, it should have no impact on the execution on standard
code).
closesodoo/odoo#39535
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
*:
delivery
hr_timesheet
mrp
sale
sale_coupon
stock
This commit makes the static strings / labels editable with studio
by wrapping them in appropriate tag (mostly span) whenever needed.
Task-Id 2030430
closesodoo/odoo#34685
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
* pos_sale, sale, sale_crm, sale_management, sale_stock, website_sale
Purpose of this commit is replace the confirmation date field with
order date from sale. As order_date and confirmation_date of sale order
are having same value so no need to keep two fields, remove confirmation
field and instead use order date.
cretae_date use as order Date and replace the order_date on confirmation
of the order as confirmation date.
task-2027274
closes: #34571
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
This attribute is misleading as it is insufficient to correctly upgrade
the database. It only renames the column in the database, but other
operations are needed, like updating the corresponding `ir.model.fields`
record (and its xmlid). The default values and the translations are also
lost during the upgrade.
Moreover, this feature was misused. It was:
- left on fields during multiple versions.
- used on reports (SQL views). This would be ok if the feature was
complete, but, as is, it was useless.
- kept unchanged after a second renaming of the field (which can happen
versions later the first rename).
- used, even when the meaning of the field changed. i.e. the field
`archived` has been renamed to the classic `active`, but the value
in the database should be switched.
The group 'group_discount_per_so_line' is used on reports in
point_of_sale but is created in 'sale' module and point_of_sale doesn't
depends on sale. So we've move this group on product to be able to
properly use it in point_of_sale.
TASK-ID: 2008468
closesodoo/odoo#35041
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
Multi is the default api for methods, it is not necessary to explicitly
decorate methods with it, adds clutter and most people use it because
they see that the rest of the code uses it.
Done with `find . -type f -name '*.py' | xargs sed -i '/@api.multi/d'`
This commit merges the following models
* account.invoice and account.move
* account.invoice.line and account.move.line
* account.voucher and account.move
* account.voucher.line and account.move.line
It was the opportunity for a big cleanup of the code, so it also restructures the whole account module, its different models/fields, the tests etc. for a better world and a better code readability.
==== Rationale ====
The rationale of this huge change is that we want journal entries / invoices to be easily edited, and changes reflected in the other model. It's a HUGE feature and very strategic for the fiduciary companies. For example, changing the account of a journal entry needs to be automatically reflected on the related invoice.
The same reasoning applies to sale/purchase vouchers.
==== Changes made in features =====
When creating an invoice, you are now creating a journal entry directly.
--> The object account.invoice no longer exists.
In the same fashion when creating an invoice line, you're now adding journal items directly in the journal entry representing the invoice. If this invoice line has some tax, it may create additional journal items as well.
--> The models account.invoice.line & account.invoice.tax no longer exist
Identically, when creating a sale/purchase receipt with its lines, you are now creating a journal entry directly and there's no more usability difference between encoding a receipt or an invoice.
--> The object account.voucher no longer exists.
--> The object account.voucher.line no longer exists.
--> The whole account_voucher module no longer exists.
Positive side-effects coming from these changes are
* draft invoices/bills/sale or purchase receipts now create a draft accounting entry. Validate these objects now simply post its journal entry. That means that draft invoices/bills/sale or purchase receipt can straightforwardly be included in reporting or budgets.
* opening a journal entry in form view will now always open the correct view: if it's a sale/purchase journal entry we will have a customer invoice/vendor bill view or a sale/purchase receipt view, whatever the menu we're coming from.
* code & business logic simplification. It is also condensed in a single place instead of being partially duplicated on invoices, vouchers and journal entries.
There should be no feature loss, except the one allowing to group multiple journal items together based on the same product during the invoice validation.
==== Changes made in models =====
* account.invoice: model removed. Instead, now use account.move with following mapping
field (account.invoice) field (account.move)
----------------------- --------------------
name invoice_payment_ref
number name
reference ref
comment narration
user_id invoice_user_id
amount_ total_company_signed amount_total_signed
residual amount_residual
state state + invoice_payment_state /!\ selection changed
date_invoice invoice_date
date_due invoice_date_due
sent invoice_sent
origin invoice_origin
payment_term_id invoice_payment_term_id
partner_bank_id invoice_partner_bank_id
incoterm_id invoice_incoterm_id
vendor_bill_id invoice_vendor_bill_id
source_email invoice_source_email
vendor_display_name invoice_vendor_display_name
invoice_icon invoice_vendor_icon
cash_rounding_id invoice_cash_rounding_id
sequence_number_next invoice_sequence_number_next
sequence_number_next_prefix invoice_sequence_number_next_prefix
'invoices' subset of account.move can be accessed by using the selection field 'type' or one of the many helpers like is_invoice()
* account.move: now has a valid state 'cancel' that has to be excluded from all business logic
* account.move: field 'amount' renamed into 'amount_total'
* account.move: field 'reverse_entry_id' renamed into 'reversed_entry_id'
* account.move.line: now has a field 'display_type' that has to be excluded from all business logic, in order to support invoice layouting
* account.invoice.line: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.line) field (account.move.line)
---------------------------- -------------------------
invoice_id move_id
uom_id product_uom_id
invoice_line_tax_ids tax_ids
account_analytic_id analytic_account_id
'invoice lines' subset of all account.move.line from a journal entry can be accessed by using the boolean field 'exclude_from_invoice_tab'
* account.invoice.tax: model removed. Instead, now use account.move.line with following mapping
field (account.invoice.tax) field (account.move.line)
--------------------------- -------------------------
invoice_id move_id
account_analytic_id analytic_account_id
amount price_unit
base tax_base_amount
'tax lines' subset of all account.move.line from a journal entry can be accessed by using the relational field 'tax_line_id'
* account.invoice.confirm: model removed. Instead, now use the 'post()' function of account.move
* account.invoice.refund: model removed. Instead, now use account.move.reversal to reverse the entries with the same options as we had for invoices
* account.voucher: model removed. Instead, now use account.move of type in ['out_receipt', 'in_receipt]
* account.voucher.line: model removed. Instead, now use account.move.line
==== Changes made in functions ====
* on account.move, method _run_post_draft_to_post() renamed into _autopost_draft_entries()
* on account.move, method action_account_invoice_payment() renamed into action_invoice_register_payment()
* on account.move, method action_invoice_reconcile_to_check() renamed into action_open_matching_suspense_moves()
* on account.move, method _get_domain_edition_mode_available() renamed into _get_domain_matching_supsense_moves()
* on account.move, method _get_intrastat_country_id() renamed into _get_invoice_intrastat_country_id()
* on account.move.line, method _get_domain_for_edition_mode() renamed into _get_suspense_moves_domain()
* in account.bank.statement, contextual key 'edition_mode' renamed into 'suspense_moves_mode'
Was task 1917430
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closesodoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
When the sales count on the product form doesn't take into account the
sales done in point of sale.
So we've extend the list of done states to take the ones from point of
sale.
TASK-ID: 1985493
closesodoo/odoo#33422
Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>
In e2e27b41a variable `colspan` and several `<t t-set="colspan"/>` were
removed replacing `t-att-colspan="colspan"` with `colspan="99"`.
- sale_management.sale_order_portal_content_inherit_sale_management has
`<t t-set="colspan" t-value="colspan+1"/>` overidding the portal view
sale.sale_order_portal_content which so may result in error 500
because colspan variable does not exist
- when doing a customization adding a column, adding:
`<t t-set="colspan" t-value="colspan + 1"/>` was the expected behavior
which after colspan change would break
So this changeset reintroduce `<t t-set="colspan"/>` tag up to not
including master, they will have no effect but possible existing xpath
or use of the variable colspan will no longer cause an error.
note: for 12.0 up to saas-12.3 (not necessary in master)
opw-1965886
closes#32539
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
- added the campaign parameters on event_registration.
- added the campaign parameters on sale_order and move the same parameters to the invoice generated for that so.
Task-1929272
Steps to reproduce:
- Install Accounting and Sale
- Enable the developer mode.
- Go to Settings > Users & Comp > Your user, edit to check both "Tax
Display B2B" and "Tax Display B2C" boxes.
- Go to Settings > General Settings > Accounting > Reporting, check the
"Add totals below sections" box.
- Create a sale order in the sale module, the sale order must have at
least one section with several products.
- Print the sale order. The subtotal amounts are wrong.
There are two different subtotals amount to compute, one for the
*Amount* column and one for the *Total Price*. The actual computation
did not store the two amount in different variables. Multiple template
are broken in the same way.
Fine tunning of 716ff76
Co-authored-by: Nans Lefevre <len@odoo.com>
opw-1950833
closesodoo/odoo#32148
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Step to reproduce:
- Install sale (sale_management) and studio (web_studio)
- Change the document template (settings > configuration > general
settings) to select the second one
- Go to an order form
- Enable studio, select "Reports" in the right tab
- Edit the "Quotation/Order" report, add a new colomn
- Back to the order form, enable dev mode and add a section to the order
lines.
- Print the report => the section is not using all the available place.
The section/subtotal are using a colspan to use all the place in the
table, this colspan is hardcoded to 5, the number of columns without
customization. Adding a new column doesn't change that value.
The fix has been to force the colspan at 99, the maximum value for
colspans. Using that value will always render the row to fill the table.
opw-1936088
closesodoo/odoo#31951
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
This partially reverts commit e2e27b41ad.
The commit changes the DOM structure in order to pretty print both
amount (value without tax, B2B setting) and total price (value with tax,
B2C setting). Actually having both (B2B and B2C) is a client
misconfiguration and we do not support that, furthermore changing the DOM
structures can break inherited templates.
The said commit was also fine tunning 716ff76, the fine tune is
related the the removal of the dynamic colspan attribute. The section,
note and subtotal should take the entire width of the table, setting the
colspan to an abritary maximum ensures they fill the entire width.
closesodoo/odoo#32194
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Goffin Simon