Before this commit, the amount currency could be wrapped on a
second line (on mobile).
To fix this, we had to find a way to have more space:
- Buttons are now displayed at the top (mobile only).
- Amounts can grow (col-auto) and the other column will take the
space left (col) and add "..." when there is not enough space.
(mobile + desktop)
We also had to remove a button from a div tag in order to display
the buttons next to each other on mobile (buttons are "inline-block"
but div is a "block").
The main flow tour has been adapted accordingly and the typo has
been fixed too...
closesodoo/odoo#46680
Task-id: 2184243
X-original-commit: 159e3d4cb8a301c908f7718a56138528033e75d4
Related: odoo/enterprise#8963
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
Before this commit, when two lines belonging to a period that is already
closed a cash basis entry is created at the present date. There are
localizations that could not allow creating the cash basis entry in a
date other than the maximum between the Journal Items being reconciled.
Now, the localizations are able to override and chose the date without
having to override the whole 'create_tax_cash_basis_entry' method.
opw-2195016
closesodoo/odoo#46661
X-original-commit: 2d3ab28c22c8ad5f9ed379e6b49697822e01a002
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Currently, to activate/deactivate records with the 'active' checkbox
user has to switch to edit mode of the form.
So the purpose of the task is to allow the user to activate/deactivate
records from the readonly mode of the form view.
In this commit, we set widget='boolean_toggle' on the 'active' field in form
view.
closesodoo/odoo#46567
Taskid: 2206794
Related: https://github.com/odoo/enterprise/pull/8918
Related: odoo/enterprise#8918
Closes: #46567
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Create a demo fiscal position with automatic detection enabled and
country group assigned (ex. Europe).
Create a new Vendor with such fiscal position assigned.
Create a product in which the product category has an account which can
be mapped with the demo fiscal position
Create a new Vendor Bill, select the partner, create an invoice line,
fill in the product: no fiscal position will apply
In the process of auto detecting fiscal position the company_id may be
enforced by the context and this would conflict when the fiscal position
company is unset. Adding a default False condition fix
the issue
opw-2192733
closesodoo/odoo#46508
X-original-commit: 57a4038554b00a487bf7b176dd780192654b136a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Let's consider a customer C
- Create a customer invoice I for C for 100€ and reference R
- Create a bank statement with a line L for C and the reference R
- Reconcile I and L and go in the jouranl entries
Bug:
The account move created for the reconciliation had no partner set.
opw:2200679
closesodoo/odoo#46332
X-original-commit: c454b661668a54240ff32ede78f0ad963e3fcd25
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Steps to reproduce:
- Go to Invoicing
- Select an invoice
- Add credit note
- Click on "Post"
- Invoice footer is overlapped on mobile
This bug occured because of "float: right".
Get rid of this is too much work (oe_subtotal_footer is already floating),
so we decided to keep it with a "clear: both".
In desktop, this element is on the right of the screen but
on mobile we take the whole horizontal space.
closesodoo/odoo#46007
Task-id: 2184243
X-original-commit: 986152405a0ba6038df7d93c9264a46ee4207dd8
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>
When a field is related, defining a selection or selection_add will
have no effect and the paramater is ignored.
Log a warning and fix all fields badly definied
Closesodoo/odoo#45716closesodoo/odoo#45832
Related: odoo/enterprise#8613
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Incorrect forward-port of e09798098679f made in 51d49517a8b5af2d1c85d9c6.
closesodoo/odoo#45775
X-original-commit: 099d0d6785b85dd67ef091fdaef084713fafb3c0
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This reverts commit db691dbebf because the appropriate solution was to filter lines with 0 debit and credit during the reverse_move before the reconciliation (which apparently has already been done by another patch).
This patch, however, was causing the followup report to show lines on a receivable account with a partner and 0 balance with 0 way to remove them.
X-original-commit: 6a5271b7f4109a4f2a20378698fbe479d73ed9cb
Issue: as salesman you want to send and print the invoice of your customer
but you don't have the access to write on the invoice
and thus you don't have access to create a mail.message and
set the flag invoice_sent to True
Allow to post message on an invoice when you have read access
closesodoo/odoo#45629
X-original-commit: d23d872f885f34bbbd747471e35e6914ac79b6cf
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Purpose:
If the user is not using receipt functionality in his organization then it's can be hidden.
Current behavior before PR:
Sale and purchase receipt by default show when the account module is instaled.
Desired behavior after PR is merged:
Now users can activate Sale or purchase receipt from accounting settings.
closesodoo/odoo#44464
Task: 2028813
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Steps to reproduce:
- install accounting
- go to accounting > accounting > reconciliation (you need at least
one unpaid invoice and one unreconciled payment for the proper screen
to show)
- manual operations > click the cog icon > create model
- create a model with a long name and duplicate it 5-10 times
- go back to the reconciliation tool > manual operations
Previous behavior:
the model buttons leak out of the right of the screen
Current behavior:
An horizontal scrollbar appears if necessary
opw-2185355
closesodoo/odoo#45431
X-original-commit: e24d971ad8d1bfdef8fc55710d99fc29c29a9c31
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
During a forward port, a regression was introduced that broke the
multi-company invoicing flow in Sales.
Create a SO in company 1, use the web client with company 2 as the main
one. The invoice should be in company 1.
This commit fixes that by providing the journal_id in the invoice values
(the company of the account move comes from the journal).
While making this fix (and adding a test for it), I stumbled upon
another multi-company issue when fetching the accounts of the product
where the property field was not accessed with the correct company. I
fixed it as well.
closesodoo/odoo#45551
X-original-commit: 07dbc197007c78633decccef2200a628b7d4a363
Related: odoo/enterprise#8498
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
VAT, NIF in Spanish, is translated NIT in Spanish from Bolivia
Clean and translate the files with the correct translation.
opw-2197155
closesodoo/odoo#45533
X-original-commit: 641c14f08435b1df1d89184cc00855416bf40bc5
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When creating a payment, we are expecting only one destination account.
However, when grouping payment by customer, it can happen that there are
more than one receivable or payable accounts, which can create
reconciliation issues afterward.
opw-2188632
opw-2166551
closesodoo/odoo#45396
X-original-commit: 779699297b9767438797ae3678eb9da1db0ce609
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
The recently added group "Show Full Accounting Features - Readonly" was
shown in the selection of groups of accounting, but the "Show Full
Accounting Feature" wasn't. It was inconsistent and allowed to see the
features too easily (not debug mode needed)
closesodoo/odoo#45419
X-original-commit: ed3adb320c6680bb213965c84b6b7fd5654c8121
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
We don't want a next activity for an invoice to be created for OdooBot
if he is the Salesperson. We also don't want a traceback if the
salesperson and the next activity user are not set.
closesodoo/odoo#45417
X-original-commit: 8bf1b72e2b2bdf026b8eff28a554301a598012be
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
Steps to reproduce:
- install accounting
- go to the accounting main view and hover some of the graphs
Previous behavior:
rounding was inconsistent and would lead to weird js floats
like 65.00000000000001
Current behavior:
floats are rounded to 2 digits after
opw-2172686
closesodoo/odoo#45336
X-original-commit: c00f4962eb790787fffef99595ac14dbef026055
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The t-if condition using "online_sync" couldn't be there...
"online_sync" condition must be present in
account_online_sync module and not account module.
closesodoo/odoo#45263
Related: odoo/enterprise#8404
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
opw-2152644
Do not set the field writeoff_account_id as required if the
payment_difference is zero because there is no writeoff in that case and
the field is invisible.
closesodoo/odoo#45257
X-original-commit: b0939529de5cd4273e64cfe729f1b5f532bbd859
Signed-off-by: wan <william-andre@users.noreply.github.com>
Without at least one field, performing a search in these models' search
view is outright impossible.
closesodoo/odoo#45177
X-original-commit: 0aabfbff3ce5d68bf37e1734ba7aa43f62803f3a
Related: odoo/enterprise#8379
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
* modify client-side domain normalisation to error if the domain is
invalid (not enough terms / segments for the number of operators)
* add better error reporting to attrs / modifiers parsing
* add a few layered error augmentation to provide clearer context
e.g. "error: invalid domain <thing>" is helpful but "error while
parsing modifiers for field foo: modifier invisible: invalid domain
<thing>" is much more helpful
* rework _evalModifiers to deduplicate it in order to more easily
implement this contextual augmentation
* test that improper domains are properly found improper
* fix a bunch of incorrect attrs domains
* also removed an apparently undefined (& unused) "options" argument
to a _applyModifiers call
closesodoo/odoo#44642
Related: odoo/enterprise#8175
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
account.bank.statement.cashbox model is verified at create/write
and updated accordingly but may crash on multiple record creation/update.
The `for` loop on `self` didn't use the specific records yielded but the `self` recordset.
closesodoo/odoo#45116
X-original-commit: af8367734c69dfeb0a1e1f029009f6da98449d0b
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
RATIONALE
Mail template model holds a field telling odoo mail engine to automatically
add the current user's signature to the body. Its use depends on the use
case
* using the template in the composer on a single record: it is displayed
in the rendered template in the composer, meaning people could change it.
This behavior is interesting as it allows to see the email content;
* using the template in the composer in mass mail mode: it is not displayed
as only the raw jinja is displayed. It is therefore not obvious that it
will be appended to the body of the mail. People could add it manually and
have 2 signatures as a result;
A mechanism automatically adding a signature to sent emails when posting a
message is already implemented and is based on template existence. If a
template has been used when posting, no signature is added in sent emails.
Otherwise it is automatically added. This behavior should not change.
Behavior will therefore be
* use a template -> specify signature usage in it manually through jinja;
* do not use a template -> signature added in sent emails;
SPECIFICATIONS
Remove user_signature.
Update template body accordingly. In customer oriented templates that are using
it and do not already contain it, manually add a call to user.signature within
the jinja code. When set to False, just remove its declaration.
Quickly clean some signature integration.
LINKS
Task ID 2089252
Community PR odoo/odoo#39482
Enterprise PR odoo/enterprise#6459
Upgrade PR odoo/upgrate#761
Related: odoo/enterprise#6459
Related: odoo/upgrade#761
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Thibault Delavallée <tde@odoo.com>
Before that, depending on rounding errors on floats, it was possible to end up with a matched percentage of 0.999999999 instead of 1.0 on an account move in case of full reconciliation. This could in turn cause problems with cash basis taxes, when checking what proportion of the move is reconciled.
closesodoo/odoo#45094
X-original-commit: 958bee9cf9f770351fbc346a081cfe059a911b3f
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Go to Accounting / Reporting / Management / Invoices
Select Pivot view
Add "Total" measure
expand results adding "invoice #" and product
Total will be incorrect because it is summing up the value reported from
several lines of the query in which the total is taken as the invoice
total, so it will display total * # lines.
Using the price retrieved from the single lines fix the issue, but it
needs to be converted according to the currency rate of the invoice.
Moreover the test need to be modified because the amount_total variable
of the report should NOT be the move amount_total but the amount from
all the lines converted in company currency
opw-2187369
closesodoo/odoo#45050
X-original-commit: 1558bb2a62cf169e6b19a2aa4dd92fcd8ff1b25a
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Explanation about flushing in action_switch_invoice_into_refund_credit_note:
Because the 'type' is set before 'amount_total', 'amount_total' is recomputed with the
wrong type and then make the condition badly evaluated.
For some reason, the field wasn't badly recomputed before:
https://github.com/odoo/odoo/commit/020e2a5e85036976b309b439582d70b5b775e54fclosesodoo/odoo#44868
X-original-commit: a82e62d1925ebfd4f49360fdc5f3a8d28de5a0d9
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
We only want journal entries with an actual sequence to be used as
reference, otherwise we can't deduce the reset periodicity of the
journal.
closesodoo/odoo#44833
X-original-commit: a57a0edae27a93aadf8fe8c95ae45ab91ec9aa31
Signed-off-by: wan <william-andre@users.noreply.github.com>
- Create the following tax:
Tax Computation: Percentage of Price Tax Included
Amount: 100 %
Included in price
- Create an invoice, add a product with this tax
- Save
A ZeroDivision error is raised.
opw-2186998
closesodoo/odoo#44810
X-original-commit: 0b11474a168037b5469176433256759916e8276b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Create a journal entry
- Create a line L1 with an account A and a partner P
- Create a second line L2 with an account A and a partner P
- Create a third line by clicking on 'Add line'
Bug:
The account A and partner P was not suggested as in saas-12.3
opw:2188921,2152827
closesodoo/odoo#44784
X-original-commit: 31890c4e676f7f4f65221ca66bfd66cc0ceedecc
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Steps to reproduce the bug:
- Let's consider a partner P without property_payment_term_id
- Create a SO for P, confirm it and create an invoice I
- In debug mode, on the SO click on the smart button 'invoice'
- On I, click on the 'Set Default' in the debug menu
- Set a payment term PT as default value (ir.default) for all users
- From this view, create a new invoice
Bug:
The default payment term PT was not set on the new invoice
opw:2184367
closesodoo/odoo#44781
X-original-commit: c258b8a0427bd5aface891ed1f4420174f4afde4
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
to be able to inherit these methods to make it easier to
add fields in the refund wizard e.g.
closesodoo/odoo#44629
X-original-commit: e814374a20de096fd795aec34ab0e3de4977fc85
Signed-off-by: Josse Colpaert <jco@openerp.com>
Because the tax closing entry is created (empty) at the creation of the
CoA, it is not possible anymore to change it later, even if the user
didn't create any journal entry.
By checking that there are no account.move.line instead of account.move,
and also there are no entries with a name different from '/' (to ensure
that the sequences are untouched) we can change the CoA if needed.
closesodoo/odoo#44659
X-original-commit: 8928dfe70867da3e40fa47f50bffa5dfd1976090
Signed-off-by: wan <william-andre@users.noreply.github.com>
Task 2093179
Today, there is nothing that reminds a salesperson that an invoice
becomes overdue.
I propose that activities get created automatically on an invoice based
on the ‘due date’ of the journal items as soon as an invoice gets
validated.
This would greatly help the collection effort and be proactive rather
than reactive.
closesodoo/odoo#44129
Signed-off-by: Laurent Smet <smetl@users.noreply.github.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>
Adrien Dieudonne