We are in the context of anglo-saxon accounting, when selling a product
having an automated valuation. The invoice linked to the `pos.order`
should have its stock output line reconciled with its counterpart in
the stock valuation journal. That is what happens if you create the
invoice directly from point of sale.
Currently, if you do not create the invoice, keep the session open and
then click the "Invoice" button on the pos order, the stock output line
will not be reconciled.
This happens because in `action_pos_order_invoice`, the picking is
created after the invoice. But the reconciliation happens when creating
the invoice. As it doesn't have its valuation counterpart yet (which is
created from the picking), it then do not reconcile with anything.
The fix here is to create the picking before.
opw-3702345
closesodoo/odoo#163157
X-original-commit: abf3f16ea6bb0278b2d44de281d69d3cfc8ac4cb
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
When you create or register a payment, the domain of the payment method
lines is based on a computed field dependent of the selected journal.
The issue is that the interface isn't blocked when waiting for the
onchange return. So if the user changes the journal, then select the
payment method quickly enough while the onchange is still pending, he
will be able to select outdated values.
It is a limitation of the js framework, so to avoid the user encoding
wrong datas, the fix here is to raise a `ValidationError` telling to
re-select the payment method.
To reproduce:
- create second bank journal, with outbound payment method lines having
different names than the ones of the first bank journal (in order to
distinct them).
- slow down the `_compute_payment_method_line_fields` method
- create a vendor payment, switch the journal to the one created and
select the second payment method (before the onchange ends).
- save the payment.
-> The payment has a payment method line from a different journal
opw-3587241
closesodoo/odoo#157872
X-original-commit: 65395bb670ec1dcf534588504057a03513cb94f6
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Arnaud Sibille (arsi) <arsi@odoo.com>
The goal of the `def new` override on `account.payment` is to have the
`journal_id` computed when creating a payment in the form view.
The problem is that it is also called by the onchange when a field is
modified.
This is causing a bug:
- Go the the cash journal and change the name of its payment methods (so
you can distinct them from the ones of the bank journal).
- create a payment (do not save)
- switch the journal to "Cash" then switch back to "Bank".
-> the "Payment Method" is still one from the "Cash" journal.
The fix here is a hacky way of checking this is the call on the
record creation.
closesodoo/odoo#157407
X-original-commit: 816a170a10969a7785fdcf2f9dffe461108ca16c
Signed-off-by: William André (wan) <wan@odoo.com>
Currently, the price difference amls are currently using today's date
(so the date the bill is confirmed) for the exchange rate.
It is weird, as the balance of those price difference amls then depends
on the confirmation date of the bill.
It is also weird, as they may also then use a different exchange rate
than the other amls (that are using the bill date exchange rate).
The fix is to use the bill date exchange rate.
opw-3596209
closesodoo/odoo#149159
X-original-commit: 5bcc8850331b7f211f9d670b2af95ccff1ff5914
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Arnaud Sibille (arsi) <arsi@odoo.com>
a66ac063e01afbcc5bec2e6f56da81340b28aaa7 introduced the use of
`_post_invoice_edi` method on `account.edi.format`, as it is a forward
port of a fix in v15, where this method still existed.
But it doesn't exist anymore in v16, due to
0e5626ca5126e6fea7fb95b694229948540764d7.
The fix is to use the method specific to the spain edi:
`_l10n_es_edi_sii_post_invoices`
opw-3604907
closesodoo/odoo#144385
X-original-commit: 7df4deacd37e4c34d0b276a087467b41dc4cf14e
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Arnaud Sibille (arsi) <arsi@odoo.com>
For a `pos.payment.method`, it is possible to define an outstanding
account, but if this account is not defined as an outstanding account in
the company settings nor in the journal, the payment will not be
considered in the bank reconciliation, nor in the bank reconciliation
report.
Steps to reproduce (demo-data with POS and Accounting installed):
-go to 'Point of Sale/Configuration/Payment Methods'.
-click on the "Bank" payment method.
-add an 'Outstanding Account' which is not the default outstanding
account of the company, nor an outstanding account of an
`account.payment.method.line`. So for example "Liquidity Transfer".
-then open a POS session, sell smth, pay with the Bank method, validate,
then close the session.
-If you go to 'Accounting/Customers/Payments', you can see that an
`account.payment` has been created, with the outstanding account being
"Liquidity Transfer".
->It is not possible to reconcile that payment with a
`account.bank.statement.line`. If you go to the accounting dashboard,
then click the reconcile button of the journal "Bank", then on a
statement line with no partner, you will not see the outstanding line
of that payment.
->If you open the 'Reconciliation Report' of the journal "Bank"
(accessible from the journal dashboard, by clicking the options of the
journal), the line will not show in the 'Outstanding Receipts'
category.
FIX:
Override the `_get_journal_inbound_outstanding_payment_accounts`
method of `account.journal`, to add the accounts from each
`pos.payment.method` linked to the journal. Using the field
`pos_payment_method_ids` from `account.journal`.
opw-3271090
closesodoo/odoo#125238
X-original-commit: c002e6bfbb194b0d609956b36f23a5dbf7acffd4
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Arnaud-Sibille (arsi) <arsi@odoo.com>
In case the journal currency is set on the company currency, we should
compute the 'Bills to Pay' sum on amount_residual_signed as it is
the residual amount in the company currency.
In the current state, you can have differences between the sum in the
dashboard and the sum showed in the list view from the 'Bills To Pay'
button.
Steps to reproduce (clean db with accounting):
-Set a foreign currency with 2 different rates (significant if you want
to see the issue clearly).
-Create an invoice in a sale/purchase journal which has no currency set
(like Vendor Bills), with the foreign currency and with an invoice_date
corresponding to one of the rate.
-Register a payment for that invoice, with a date corresponding to the
other rate and having an amount lower (like half) than the invoice, so
the invoice is partially reconciled.
-> Go to the accounting dashboard, the amount next to 'Bills to Pay' is
different than the amount (the sum of the column 'Amount Due') in the
list view generated after clicking that button.
These two values should be the same. They are currently different
because the dashboard takes the amount_residual, which is expressed in
the invoice currency, and apply the exchange rate to get the residual in
the journal currency.
But if the target currency is the company currency, the field
amount_residual_signed is already the residual amount in the company
currency. Unfortunately, in case of partial reconciliation, it is not
always equal to amount_residual expressed in the company currency
anymore. Because amount_residual and amount_residual_signed are
substracted by the payment amount, expressed in each currency, using the
payment date exchange rate.
opw-3184567
closesodoo/odoo#125150
X-original-commit: d71d8e90667ccc9c5428cc15b927747b4b3556cd
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Arnaud-Sibille (arsi) <arsi@odoo.com>
Problem:
Indian edi doesn't take into account the round off.
Cause:
It is looking for rounding lines in `invoice_line_ids`, but since v16,
rounding lines are no more invoice lines.
`invoice_line_ids` is a subset only consisting of move lines
having a `display_type` in `('product', 'line_section', 'line_note')`
and a rounding line is a move line with a `display_type == 'rounding'`.
Fix:
Rounding lines must be searched in `line_ids` and not in
`invoice_line_ids`.
opw-3202845
closesodoo/odoo#117922
X-original-commit: a07d9683eae9c49cb8a36c6b1781c33d48eb03cb
Signed-off-by: Cedric Snauwaert <csn@odoo.com>
Signed-off-by: Arnaud-Sibille <arsi@odoo.com>
Problem:
It is possible for an `account.bank.statement.line` to have in the
database the field `amount` set to `NULL`. It happens when importing
from the 'bank statement line' list view (Favorites>Import Records), a
csv file that have no column 'amount'.
This causes an issue for the queries accesing that value, as they expect
a number and get a Nonetype (for example in the function
`_compute_running_balance`).
Solution:
As this is stable, we cannot change the attributes of the field.
So here, in the `create` function, we set the amount to 0 if
it is not specified. Like when you create a bank statement line with the
'create' button, where this field is set to 0 per default (client side).
opw-3161652
closesodoo/odoo#111585
X-original-commit: 37b271e777576fbaed6e718bb7cd1c064fdb9a54
Signed-off-by: Laurent Smet <las@odoo.com>
Problem:
In the UI, from the form view of a journal (`account.journal`), you can
set a bank account (`default_account_id`) which is not of the same type
as the journal.
In v15, it was not the case.
Cause:
Since refactor [1], the domain of
`default_account_id` has been changed in order to replace the
`user_type_id` conditions, but it seems like an unwanted '|' has been
left.
Solution:
Remove that pipe.
[1]: https://github.com/odoo/odoo/commit/26b2472f4977ccedbb0b5ed5f08be2c04313fd21closesodoo/odoo#108711
X-original-commit: ee7a4f9afee6cb4f359aea1759246c8c67fb75bf
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Arnaud-Sibille <arsi@odoo.com>
The problem is that when you archive a company and then install
subcontracting, you get a traceback.
Step to reproduce (in a multi-company environment):
-install 'stock'
-archive a company
-install 'mrp_subcontracting'
-->traceback
Explanation:
When installing the 'mrp_subcontracting', there's a search on all
(active) companies in order to add a subcontracting location for each
of them (this is is triggered by
'/odoo/addons/mrp_subcontracting/data/mrp_subcontracting_data.xml').
But there is still a warehouse linked to the archived company.
So when adding routes to all warehouses and looking for the
subcontracting location of the archived company, it is set to
False. Which is not intended and causes the traceback.
Solution:
Add '.with_context(active_test=False)' to the search for the companies
in '_create_missing_subcontracting_location(self)', so the missing
subcontracting location will be created for the archived companies too.
Discussion:
-The ability to archive companies is new to Odoo16 (implemented due to
the new pricing).
-Here I considered that we want to create a subcontracting location for
an archived company instead of taking action on the warehouse linked to
the archived company (like not considering it when creating routes).
I did this because a company can be unarchived and with this fix, it
will not cause issues.
-I think other problems similar to this one (in any app), should appear
in the future.
opw-3039495
closesodoo/odoo#107168
X-original-commit: 1dcdbe9e3cc21af50ed580c032b1927e21c3c24b
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Traceback when computing taxes using TaxCloud.
Steps to reproduce:
-Activate TaxCloud in accounting settings, with valids "API ID" and
"API KEY".
-Create an invoice for a USA customer with an invoice line and
"Fiscal Position" set to "Automatic Tax Mapping (TaxCloud)" (in the
"Other Info" tab).
-Confirm
-->Traceback
Traceback:
File
"/src/enterprise/16.0/account_taxcloud/models/taxcloud_request.py",
line 136, in get_all_taxes_values
for item in response.CartItemsResponse.CartItemResponse:
AttributeError: 'NoneType' object has no attribute 'CartItemResponse
Explanation:
-There's a traceback when CartItem is empty (like if there are no move
lines).
-It is empty because of the filter in the function
'_process_lines(self, lines)'.
--> 'lines.filtered(lambda l: not l.display_type)'.
-The goal is to take only move lines that are not Notes or Sections.
-This worked in v15 because display_type was defined as:
display_type = fields.Selection([
('line_section', 'Section'),
('line_note', 'Note'),
], default=False, help="Technical field for UX purpose.")
-But now in v16 it is defined as:
display_type = fields.Selection(
selection=[
('product', 'Product'),
('cogs', 'Cost of Goods Sold'),
('tax', 'Tax'),
('rounding', "Rounding"),
('payment_term', 'Payment Term'),
('line_section', 'Section'),
('line_note', 'Note'),
('epd', 'Early Payment Discount'),
],
compute='_compute_display_type', store=True, readonly=False,
precompute=True, required=True,
)
-The display_type=False does not corresponds anymore to move lines
that are not Sections or Notes, but it corresponds to no move lines at
all.
The fix:
Will filter move lines that are not of type 'line_section' or
'line_note'.
Discussion:
Do I fix the traceback that we get when there a no move lines? This
'issue' is present since at least v14 and it seems like nobody ever
complained.
+:
I've applied the similar change to some lines in the code that also
check if 'display_type' is False for some 'account.move.line' records.
++:
The fix revealed an other issue in the function
'_inter_company_create_invoices' of the file
enterprise/account_inter_company_rules/models/account_move.py:
There's a call on a function that doesn't exist anymore
'line._set_price_and_tax_after_fpos()'. I've deleted the line.
opw-3064174
closesodoo/odoo#106452
X-original-commit: 8bfca5832adaf9e147f2443d0bf56cf921f9ff0c
Related: odoo/enterprise#34352
Signed-off-by: William André (wan) <wan@odoo.com>
Arnaud Sibille