Adding preview of expenses attachment to journal view.
When creating an expense, files can be attached (e.g. scanned receipts).
Those attachment files where not displayed in "Accounting > Accounting > Journals > Purchases" move_line list.
They now appear in the document preview.
Task = 2176443
closesodoo/odoo#44161
Related: odoo/enterprise#8002
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Properly set the transfer account in the company taking account the accounts defined in th company domain. We found this error because in l10n_ar module we have 3 chart of accounts based on the company AFIP responsability which actually have same transfer_account_code_prefix. For that reason it was setting a transfer account to the company which is not belongs to the current company.
closesodoo/odoo#44586
X-original-commit: d38228836b8944740f04ca355c997c4b6a346e48
Signed-off-by: Josse Colpaert <jco@openerp.com>
Before this commit, Creating New Template from "Send Invoice" wizard doesn't update template_id on the Wizard.
In this commit, We write newly created template_id on the wizard.
closesodoo/odoo#44561
X-original-commit: 454e6ed9d956ac131d6476c95e59b2ab390df5b6
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Fixes#43705
Before this commit, There will be tracback on converting currecy if there is not date on tax line.
Now we use current date to as fallback to convert currency.
closesodoo/odoo#44559
X-original-commit: 2b88d71c6e4815334f0edaa24d6041c5facd811e
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
The computation was incorrect, the answer was 10, not 110 with the
previous formula
Courtesy of Frederico Freire Boaventura
closesodoo/odoo#44514
X-original-commit: 577e1ad8314cac6e61f60f997f338df4b7a1da38
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
The default journal depends on the company define in the context or the company in the environment
In case of online signature/payment of a SO in a different company then the public user
The company will be wrong and the journal_id as well
It lead to a fail of the payment since the payment could not be reconciled with the invoices
This is happening because the force_company is not taken into account for the default journal
This commit take the force_company into account, it take the precedences on the default_company
closesodoo/odoo#44238
X-original-commit: 8158e286b0020daa994b593377a2c99234e66086
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
-When 'Product Description' on several line in sale.order.line.
In that case, In 'Sale Order' report description print as it is but
In 'Invoice' report lines are all fitted into one single line.
-By this commit solved this issue.
task- 2127652
closes- odoo#42006
closesodoo/odoo#42006
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
There is nothing left preventing to delete an account.move.line making
the related account.move unbalanced.
closesodoo/odoo#44341
--issue: 2185112
X-original-commit: 92364270d21cc4688471597f04fe25206b320a58
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
`action_invoice_paid` should be called when the computed field
`invoice_payment_state` is set. However, the recomputation doesn't go
through `create` or `write` (since the field is protected).
A workaround is to call it at reconciliation. Indeed, an invoice can
only be paid when it is reconciled. For invoices with an amount of zero,
we call the method at posting.
closesodoo/odoo#44331
X-original-commit: 97b00da953f7860d51326a160c38fab0354458a8
Signed-off-by: Nicolas Martinelli (nim) <nim@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>
Steps to reproduce the problem:
- Have user A with B2B group.
- Have user B with B2C group.
- Add simultaneously on both - via write - another group (or call `_check_one_user_type`).
Expected result:
- No problem
Got result:
- Error "A user cannot have both Tax B2B and Tax B2C..."
That's because the check is performed for more than one user each time, while it has
to be record per record. The implementation of `_has_multiple_groups` actually
checks if the passed recordset is only one record, and if not, it looks directly for all
existing users, so also the case of both users A and B being in the same B2x group, but
having a 3rd user in the other group will fail.
Revisiting the query in `_has_multiple_groups`, there's a hidden error when you use it
for only one ID because a missing space.
closesodoo/odoo#44300
X-original-commit: 83f104b2f2fc1345ad067430466c004697a91db9
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Task 2081612
* Add as an optionnal field "balance" (simple debit -credit)
- usefull for "group by"
- usefull when selecting several lines (in the footer total)
- Hidden by default for journal view
- Diplayed by default for ledger view
* Cumulative balance only for ledger views
closesodoo/odoo#38174
Related: odoo/enterprise#8024
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
match_total_amount_param on account.reconciliation.model is not
respected when paying a vendor bill through bank statement because
the amounts from both the statement line and the move line that
are used in the comparison will be negative.
closesodoo/odoo#44234
X-original-commit: 1a9221584f78fc7619277c2c0e9b9659e7c80ee2
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
When having an invoice in foreign currency and a partial payment in
domestic currency (in a different date with a different exchange rate),
the computed amount due is incorrect. When computing the
amount_residual_currency the payment (in domestic currency) is converted
to the foreign currency using the exchange rate of the invoice date, and
not the one of the payment date (see 56d92213b8).
If the account.partial.reconcile line will have a currency_id and a
amount_currency the amount_residual_currency will not be converted but
simply added.
This behaviour was introduced with e130606602
and backported to version 11.0 with 3363d7235137f286458c734a1a0417beeb1f66bb.
In version 12.0 this behaviour was partially reverted in d3d2612061.
opw-2156001
closesodoo/odoo#44181
X-original-commit: 94d34e052f3757c21884fd5a57cc68ea8c51aafb
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Task 2168197
Especially when writing out checks we would like to track the value of
the state of the vendor payment in the chatter. This way we can see who
prints it, cancels it, etc and at what time this happened. It's
important for traceability. I think we can just enable it for all
payments in general, I can't think of any downsides and payments are
usually sensitive documents so I imagine people want as much info as
possible.
closesodoo/odoo#43505
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
When simply need to parse a domain, it is easier
Add .strip() on ir.ui.view as ast.literal_eval produces an syntax
error if the node starts with spaces (as done in the xpath of
hr_attendance.view_employee_form_inherit_hr_attendance)
closesodoo/odoo#43831
Related: odoo/enterprise#7894
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When we had multiple journal items with the same account in either debit or credit on the opening move, only the last one was taken into account. This could happen when the opening entry had modified manually (not through the list view opened by the setup bar).
We now take multiple lines into account when computing the opening balance. Also, this multiple lines case is also now supported by the setup list view allowing editing the opening balances : when multiple lines exist for the same account, we group them into one and edit the total just like before.
closes https://github.com/odoo/odoo/issues/43736closesodoo/odoo#44088
X-original-commit: c5a8051a2c840b2be545eee2f173261a908de737
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>
Without any access rights on the 'account' module, a salesperson should be able to
create a new invoice from a sale order.
Since the merge of account.invoice with account.move, we need to manage carefully the
access rights when dealing with invoices. A salesperson must not be able to manage the
journal entries except the one being an invoice created for a sale order.
To make such restriction on the journal entry's type, we need additional record rules
- in sale: to restrict the access to invoices.
- in account: to exit such restrictions when having billing access rights.
closesodoo/odoo#44023
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Suppose a price_unit of 2300 with a 5.5% price-included tax applied on it.
The computed balance will be computed as follow: 2300.0 / 1.055 = 2180.0948 ~ 2180.09.
Since accounting / business fields are synchronized, the inverse computation will try to
recompute the price_unit based on the balance: 2180.09 * 1.055 = 2299.99495 ~ 2299.99.
--issue: 2168073
PostgresSQL TRIM function does not trim line return and other space characters
that are not white space.
For references having a non trimmed character regexp_split_to_array would create an array
with an empty element. Such element could be matched to a counterpart with no numerics in
the reference.
TRIM(' \n001') => '\n001'
regexp_split_to_array('\n001') => {"", "001"}
By replacing the TRIM function by a substring using a regexp we
also remove the other space characters such as tab and line return.
closesodoo/odoo#44026
X-original-commit: 93f63c331781179fc6b81c14563a97b1d6a9b300
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Since commit odoo/odoo@43db60d `<notebook>` elements
have also a wrapper element (with class `o_notebook_headers` around
their tabs.
Since account module reuse the markup and styling of the `<notebook>`
but without using the tag itself (cf. done by hand) the reconciliation
line's tabs style was broken.
This commit adds the missing wrapper element and set the
margin-{left,right} reset to the that element.
closesodoo/odoo#43959
X-original-commit: 8d45e3d52a7312addb05dd6cb39d68f9d61144da
Related: odoo/enterprise#7941
Signed-off-by: Pierre Paridans <pparidans@users.noreply.github.com>
Before this commit, in the list of invoices the customers were displayed
using only their names and not the company that they belong.
For instance, if 'Brandon Freeman' is part of the 'Azure Interior'
company, only his name was shown.
Now, the company names is also shown. In our example, the customer will
be displayed as : 'Azure Interior, Brandon Freeman'.
This behaviour was already the case in version 12.
opw-2179722
closesodoo/odoo#43824
X-original-commit: ca57cdeb80729a3e3b4bc2cc91376b625e1934ed
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Main
-----
For Huge Amount Invoices with small residual being paid and the Invoice and the
initial payment which almost paid, the invoice in full can render the
reconciliation of the Tax Entry Lines as fully reconciled.
Description
-----------
In case of multi-currency transactions where CABA Journal Entries are involved,
there could be a case where, in Mexican Localization, so far, a small entry
line cannot be reconciled with their counterpart because the previous
counterparts are already reconciled. (Though this is still unproved in a lab,
i.e. UnitTest, can be seen in the wild, i.e.Customer's Production Instance)
The following is an hypothetical case yet to be proven:
Test to validate tax effectively receivable
My company currency is MXN.
Invoice issued two days ago in USD at a rate => 1MXN = 0.80 USD.
Booked like:
Receivable 1450 1160 USD
Revenue 1250 -1000 USD
Taxes to Collect 200 -160 USD (Hypothetical Fully Reconciled with A1)
Payment issued today in USD at a rate => 1 MXN = 1.25 USD.
Booked like:
Bank 927.99 1159.99 USD
Receivable 927.99 -1159.99 USD
And a Tax Cash Basis Entry is generated for the ratio being paid
Booked like:
Tax Base Account 800 1000.00 USD (sometimes this base can be rounded up and instead of being 999.99 it ends up as 1000.00 which leads to taxes to be as fully reconciled)
Tax Base Account 800 -1000.00 USD
Taxes to Collect 128 160 USD (Hypothetical Fully Reconciled with A1)
Taxes to Paid 128 -160 USD
I will neglect to depict here the FX Journal Entry for Tax to Collect account for the hypothetical reconciliation A1. And any other FX Journal Entries.
At this moment Invoice has a USD 0.01 residual which on same date will be tried to write-off manually.
Write-off 0.01 0.01 USD
Receivable 0.01 -0.01 USD
At this moment Invoice has a USD 0.01 residual which on same date will be tried to write-off manually.
This small amount will create while running in run-time following CABA Journal Entry:
Tax Base Account 0.01 0.01 USD (sometimes this base can be rounded up and instead of being 0.00 it ends up as 0.01 which leads to taxes to be created and be tried to reconcile)
Tax Base Account 0.01 -0.01 USD
Taxes to Collect 0.01 0.01 USD (Hypothetical This will be tried to reconcile with the items in Full Reconciliation A1 but raise an error)
Taxes to Paid 0.01 -0.01 USD
closesodoo/odoo#43819
X-original-commit: 00861974c259fbbf381a597ed9d233525185a005
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
Steps to reproduce:
- install accounting
- go to accounting > configuration > charts of account
- create a chart of account with a code containing leading zero's
(ex: 000022)
- duplicate the previously created chart of account
Previous behavior:
leading zero's are not kept trough duplication
Current behavior:
the new code is padded with leading zero's to keep the same length
opw-2172816
closesodoo/odoo#43802
X-original-commit: c458c8ecee6b544b4056ccf5a9af591622238182
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Task 2092079
Accounting firms that want to give access to their customers avoiding
mistakes and risks will love this profile that can't do anything
wrong... Maybe as well as companies auditors..?
closesodoo/odoo#39860
Related: odoo/enterprise#6576
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
The `ref` field on `account.move` is not required and can yield a falsy
value. This produces a TypeError while doing the comparison in sorted().
closes#42434closesodoo/odoo#43674
X-original-commit: 3bb4c0c99b29bb85916af95361b86e9dc3287546
Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>
1- create a group payment (10 ~ 15 invoices);
2- Open the created journal entry.
The first issue we see is that the breadcrumb is too big to the size of
the screen.
3- Open the 'Reconciled Entries'.
Before this commit, the screen was completely shifted and not visible.
This occurs also because the breadcrumb is too big.
Now, the references added to the name of the entry is limited to 50
characters.
opw-2166551
closesodoo/odoo#43644
X-original-commit: d679c75bbeaf3e41dcdb8c91996a89ea5080669f
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Create multiple tax and assign them to the same tax group.
Create an invoice, with two lines, each one with one tax of the group.
Save and click on "Preview" or print invoice.
The tax group will be reported applied on just the first line
This append because of 4d62a94a31c3967bfd34396a3448a3e925422634.
Reverting commit to restore the former behavior in which the tax base
amount is added for every line in which the tax group component is
found. While this other behavior could be an issue for some user the
behavior is more consistent accounting-wise and the template could easily
be changed to adapt to user needs.
opw-2170069
closesodoo/odoo#43553
X-original-commit: 43de214bf2d0da20b7609e392d800b49465b483d
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
This wizard also reconciles automatically entries done on reconcilable accounts. It can hence for example be used to "move" the balance of a receivable account into a payable account (or the opposite), using the generated transfer entry to do as if the receivable and payable accounts were directly reconciled together.
[IMP] account: display 'P' as matching number when account.move.line objects are partially reconciled
For this, we introduce a new matching_number field, used in account.move.line's tree views instead of full_reconcile_id, which used to be shown directly.
Was task: 2037318
closesodoo/odoo#39415
Related: odoo/enterprise#6544
Signed-off-by: Laurent Smet <smetl@users.noreply.github.com>
- Create a 10 % purchase tax with price included
- Create a Purchase Receipt with a price unit of 100 and the 10 % tax
The total is 90.91 + 8.26 = 99.17.
The root cause of the issue is that... actually I have no idea. For some
mysterious reasons, in case of an `in_invoice`, `in_refund` and
`in_receipt`, we go through `_compute_base_line_taxes` when the price is
changed. In case of the `in_receipt`, we compute the tax based on the
`balance` (= 90.91) rather than the price unit, which screws things up.
Note that in case of `out_*` moves, we simply don't go through
`_compute_base_line_taxes` at all, so Sales Receipts are fine.
opw-2170975
closesodoo/odoo#43475
X-original-commit: 1bbf66937c2b4fdb45318652e3ed1147f1edd29b
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The creation of an account with a single character code crashes.
opw-2176764
closesodoo/odoo#43455
X-original-commit: 7b1e881e60d6424f7b3a676c06a4b5b8a222d025
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
PURPOSE
=======
When the customer and supplier boolean fields were dropped
from res.partner in 13.0, the 'customers' and 'vendors' filters
were removed as well.
Two new 'customers' and 'vendors' filters have since been added
in the account module.
They might look identical to the former ones at first, but those
are instead based on two brand new 'rank' integer fields:
customer_rank and supplier_rank.
Those fields start off at zero and are increased by one each
time an in_invoice/out_invoice line is posted for the res.partner.
This means that, to be considered as a customer, a res.partner
has to have at least one invoice line posted.
This has stem confusion in both former and new users of Odoo:
- users do not have a clear idea of how this filter actually
works. (I personally had to go through xml and python code to
understand how to turn a res.partner into a 'customer')
- to the users that were used to the 'customer/supplier' boolean
fields, it simply looks like the old filters stayed while the
boolean fields were removed
- one of the reason why we got rid of the 'is a customer' field,
is that there is no unanimous definition of what a customer
actually is
- is it when the lead is won? when the quotation is
created/sent/confirmed? when the invoice is
created/sent/confirmed?
- here, we decided that is it when the invoice is posted,
but whether the user agrees or not with this definition,
there is no way for him to know this is where we decided
to draw the line
A simple way to clarify all this is to rename the 'Customers' and
'Vendors' filters to make it obvious that they are based on the
customer invoices and vendor bills.
closesodoo/odoo#43349
Taskid: 2166410
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.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>
Purpose
=======
Fix multi-company access issues following the big changes that happened
(the 13.0). Make the usability better in order to avoid potential
multi-company issues for the user.
Specification
=============
Check the related commits to see the different fixes that have been
made. For more information about the technical/functional considerations,
check the related task.
closesodoo/odoo#43321
Taskid: 2088891
Forward-port-of: odoo/odoo#43230
Forward-port-of: odoo/odoo#42418
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
Description of the issue:
Transfer between Bank1 (550001) and Bank 2 (550002) of the same company via the intercompany bank account (580000) :
Bank 1: minus 1000 EUR, we create the following accounting entry via the reconcile widget
account 550001 credit 1000
account 580000 debit 1000
Bank 2 : Plus 1000 EUR
When we select the counterparty 580000 entry of the Bank 1 statement via the reconcile widget
than the statement_line_id of the entry from Bank 1 statement is replaced by the one of the Bank 2 statement.
Hence this account.move.line is linked to the wrong statement line.
closesodoo/odoo#43371
X-original-commit: 3d74e7397e15311f1e9189589a435d9683376317
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Purpose
Fix multi-company access issues following the big changes that happened
(the 13.0). Make the usability better in order to avoid potential
multi-company issues for the user.
Specification
Check the related commits to see the different fixes that have been
made. For more information about the technical/functional considerations,
check the related task.
Taskid: 2088891
X-original-commit: 5c8df3a5e5f7960e5eab6439e0a32a06224ba826
Before this commit, bank accounts tab on partner view is available directly
in base whereas it should not, as it contains information useful only
for accountants. We therefore move them directly to account.
Task ID: 2172260
closesodoo/odoo#43322
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Before this commit:
If neither Invoicing nor Accounting are installed, users are stuck with menus
items to create bank-related informations (Banks and Bank accounts). They won't
be able to set these information directly on their contacts.
After this commit:
The Bank Accounts part of the Invoicing tab has been moved from the `account`
module to `base`, so it's now visible in the partner form even when only
`contacts` is installed
Task ID: 2126832
closesodoo/odoo#40563
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
When switching a invoice to a refund, the bank account to which the move
should be paid should be removed: while it (might) contain the partner's
bank account before, when becoming a refund it makes no sense to keep
the partner's bank account as the recipient.
closesodoo/odoo#43176
X-original-commit: e94234f435622b7de00c917ca7c6302fd6c92881
Signed-off-by: Damien Bouvy (dbo) <dbo@odoo.com>
Before the merge of account.invoice with account.move, a group of taxes was
expanded on journal items and not on invoice lines. Since both are now the
same thing, we only get the group of taxes when using the 'tax_ids' field.
To correctly handle this new behavior, we need to call 'flatten_taxes_hierarchy'
every time we use the 'tax_ids' field to get the children taxes instead of the
group of taxes itself.
[FIX] account: Wrong unit price with included tax and fiscal position
Steps to reproduce the bug:
Let's consider a sale included tax T1 of 10% and a sale excluded tax T2 of 0%
Let's consider a product P with T1 and a sale price of 110€
Let's consider a fiscal position FP that mappes T1 to T2
Let's consider a customer C with FP as fiscal position
Create a customer invoice for C
Add P on the first line and T1 is replaced by T2
Bug:
The unit price of P was still 110€ instead of 100€ because the included tax was not removed from the base
price of P.
Same behavior as in 11.0 and 12.0
opw:2150564
closes odoo/odoo#43100
Co-author: simongoffin (sig@odoo.com)
Forward-port-of: #42926
Forward-port-of: #42188
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
If the opening entry is balanced, the auto-balance line is unlinked.
However, before unlinking we test if it is balanced, which it is not. A
solution is removing the line from the move and it will be unlinked
automatically.
closesodoo/odoo#43045
X-original-commit: 56ecc9c4c2e9dcc3e06ee0a388d439845ddeedfc
Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>
Activate Multicurrency
Create a Journal Entry with default currency (USD)
Save
Error will trigger because of the sql constraint
'check_amount_currency_balance_sign'
The currency_id and company_currency_id are the same while they
shouldn't because company_id should be unset if it is the same as the
company_currency.
Fix to update the error message to let the user know that it's best to
keep the field empty so the company_id would not be set
opw-2169523
closesodoo/odoo#43082
X-original-commit: 6a420921818d741d48bf873e0a62a220c135fbfa
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
jbw