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>
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>
Before this commit some of the <p> elements had no id or name.
This means you need to do uglier or more risky xpath expressions.
By adding names on the elements we can easily xpath to the element itself which results in less changes of breaking or having issues.
closesodoo/odoo#56096
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
* merge report_invoice_document and report_invoice_document_with_payments templates
* define new generic method _get_name_invoice_report that let us to
print a different report, this method can be inherited by each localization
to set their custom report
* change report templates to use the new method.
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>
Steps to reproduce:
- Let's consider a sale tax T of 0% with Tax group Tax 0%
- Create an customer invoice I with one line L of 100€
- Set T on L
- Print the invoice without payment
Bug:
The tax T was displayed as a group with "Taxes on 100€" instead
of Tax 0%.
opw:2268926
closesodoo/odoo#55731
X-original-commit: 3e0defe37ef8d2081e72290d701738e1ab68d3c6
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce:
- install account
- print any invoice
Previous behavior:
the css rule and classes are ignored on the total table
Current behavior:
displays as intended
This PR fixes two issues:
1/ class attribute was not taken into account anymore ( table-sm )
2/ page-break-inside didn't work
closes#48682
opw-2229181
closesodoo/odoo#50259
X-original-commit: d8bfae0a641f43455b594e8ab2b22ce52cd98d70
Signed-off-by: Nicolas Lempereur (nle) <nle@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>
If a user with Sales rights but no Accounting rights is trying to send an already
paid invoice, it will raise an access rights error before this commit while we
should allow him to send it without error.
closesodoo/odoo#48820
X-original-commit: 27cb9197c6b64fb9cb8fe46a20d9557914045e59
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>
Issue
- Install Accounting & Studio
- Accounting > Open studio
- Reports > Invoices
- Add a Field Column in the table
and drag it after "Description"
Some elements are shifted, which
causes inconsistency in the table
Cause
In 924ca78068 we added
a th "source document" with
a td containing the value.
In bc131c0cfb we removed
the td but not the th.
Studio adds hook after each th & td.
Since there is th but no td, there is an
inconsistency in the hooks.
Solution
Remove the th from the view to avoid having
a useless hook.
OPW-2226726
closesodoo/odoo#48798
X-original-commit: 351355c8cb8c64927b5f82d4c1e1deca74353305
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
This new modelling makes it easier to add new QR-code formats, and allows using all of them in website_sale and account.payment's form view as well (so, Swiss QR codes are now available there, while they were restricted to only invoices in the past). All barcodes are now generated as reports, from a dedicated route. This was only partly the case before : Swiss QR added a cross on top of the QR-code directly in the template, it wasn't part of the image returned by the route; now it is.
[ADD] base_qr_code_sepa: new module decoupling SEPA QR-codes generation from the base module
Each new QR-code generation option should thus be done in a dedicated module (or added to a localization) in the future.
[IMP] base_qr_code_sepa: update the generated QR codes to version 2 of the specification
Version 1 is still supported, so no need to backport this.
[IMP] l10n_ch: make Swiss QR-codes compatible with the new version of the specification (the old one is deprecated)
This will be backported to 11.0 and 12.0, as these QR-codes will soon replace ISR.
[IMP] account: make it possible to mark manual payments as sent with a button on the form view
This way, when making them directly with a QR-code (or doing a more classical wire transfer), people can keep track of what they already have asked the bank to do, and what they still have to treat.
closesodoo/odoo#44839
Related: odoo/enterprise#8262
Related: odoo/upgrade#992
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Purpose of this commit is to update incoterms list
base on new incoterms guidlines and add incoterms in RFQ/PO
and invoices/venderbills reports
task-2179236
closesodoo/odoo#43883
Related: odoo/upgrade#922
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
This is done by introducing a new threshold setting, allowing choosing a date before which all invoices and payments have to be ignored by the accounting. Once this is done, all the balances can be reimported directly, easing the migration to Odoo Accounting a lot.
account.move objects having to be ignored because of this are cancelled, and receive the new 'invoicing_legacy' payment state. account.payment objects are moved to the new 'invoicing_legacy' state and their related account.move is cancelled and marked as invoicing legacy as well.
closesodoo/odoo#41416
Task: 2092377
Related: odoo/enterprise#7071
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Task 2176461
* Dashboard: don't show lins if there is no data
* Add new menu for expense reports
* Reorganize notes on bottom of printed invoice
closesodoo/odoo#43787
Related: odoo/enterprise#7880
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
In 13.0, account.invoice.line `name` Text field was transformed into
account.move.line `name` Char field.
So when we want to have this field on several line, we need to specify
the widget `text` instead of `char` explicitely.
opw-2160694
closes#42395closesodoo/odoo#42476
X-original-commit: 18bb3788a9de474c4c5f4aff8d3e51dde547c86a
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Be in multi-company with companies C1, C2.
Let user U1 in company C1 create a vendor bill V.
Then U1 change to company C2.
Another user U2, in company C1, tries to print the vendor bill.
Traceback: Access error trying to access U1 to render the template
opw 2145738
closesodoo/odoo#41977
X-original-commit: 5b7b12c9907d7da03e08df4f5bac2198c3dc9cba
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
When printing an invoice, the order of the lines not always match the
order in the interface.
It occurs because `account.move.line` contains a `sequence` field which
is taken into account in the UI but not used in the report. Note that
commit 0a5955bff6 explicitly removed from the `_order`.
opw-2145878
opw-2147922
closesodoo/odoo#41396
X-original-commit: f4571e2fe0f30d753172ce1fa1dc40d93b87e00a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
- Description is no longer needed since it provides the same info as the header.
- The ref field will be used to set a custom description on any invoice (not just vendor bills).
- Don't display the name on the report if the move hasn't been posted.
closesodoo/odoo#37683
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Update invoice report to add id attribute in vat label and tax lines
elements in order to to be able to make clear/save inherit of this
report in Argentinian localization
Before this commit modifying/extending the information was difficult
After this commit, the id can be used for efficient xpath
<xpath expr="//t[@id='inv_tax_id_label']" position="attributes">
<xpath expr="//span[@id='line_tax_ids']" position="attributes">
Task 2038326
* Tick the credit note sequence by default on the customer invoices and vendor bills journals
* Write Customer Invoice/Vendor Bill/Credit Note/Customer refund at the top of the document
* The reference field should be printed on the credit note pdf (interesting because it gives source and reason)
* If the document is a credit note, there shouldn't be any payment information on the pdf (the customer doesn't have to pay you) (currently you see the "payment communication" the customer is supposed to use)
* Rename Credit Note to Refund on dashboard
* Add tooltip on payment widget
closesodoo/odoo#35231
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>
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 QR code was limited to a set of countries listed from Wikipedia [1],
but the list is incomplete. Any partner from a SEPA country should have
the QR code printed since we don't know which banks support it.
At the moment we simply remove the limitation, and hopefully a proper
filtering will be done in master.
[1] https://en.wikipedia.org/wiki/EPC_QR_code
opw-2052315
closesodoo/odoo#35827
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This commit add an action to merge and print the original vendor bills
through the field 'message_main_attachment_id'.
Was task 2006908
closesodoo/odoo#34023
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
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
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>
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>
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>
with this commit, changed the label of 'Shipping address' => 'Shipping Address' and removed 'Reference'
into the printed invoice report for a portal view
Task ID: 1930087
In described Modules, there are some fields label like Unit of measure, Discount,
Ordered Quantity, etc... in views(list,form), report and portal, that are messy
and barely readable when lots of features are installed.
Purpose of the task is to shorter that all fields label to make clean view in
order to make it more readable without getting labels uselessly spread out on
several lines
Related to task #1933746Closes#31962
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit, the unit price in the invoice's reports, had the
same decimal precision as the currency and not the one specified for the
unit prices.
Now, the reports shows the unit prices with their specific decimal
precision.
opw-1940406
closesodoo/odoo#31314
Following BS4 migration and adding sections and notes.
=====
Document templates:
- Remove margin from <p> in "informations" to allow them to be
correctly centered vertically on their container.
- Also add a mt- and mb- on their <div> to better handle them going to a new
line when there are too many of them.
- Add class for section and note to be able to customize them in layouts.
- Add class for price_total to be able to customize it in layouts instead
of relying on :last-child.
- Add "page-break-inside: avoid;" on the "total" table to not split it
between pages when it can be avoided.
- Fix sale report template "Informations" to use col-auto just like invoice
See 6b8d7bb6d6
=====
Boxed layout:
- fix section & note style
- fix borders in general
- fix the total table
Background layout:
- fix section style
- fix the total table
Clean layout:
- fix page number vertical align
task-1889346
closesodoo/odoo#27782
The invoice lines table in the invoice report was using a `t-attf-class` where
it is not needed. It could be simplified with `class` instead.
This small simplification allows the user to modify the table with the Report
designer in Studio.
closesodoo/odoo#27978
This fix fixes 2 issues:
- the definition of the row/col structure on the document meta-data
- the content of the headers is within a span so it is editable
Bonis Modi