When creating a timesheet, several fields need to be recomputed:
- `currency_id`
- `group_id`
- `department_id`
- `is_timesheet`
- `validated`
When `validated` is computed before the other fields, the recomputation
will lead to an `AccessError` because of the rule
`hr_timesheet.timesheet_line_rule_user`.
Since the test `test_timesheet_validation_user` expects an
`AccessError`, the test succeeds. However, from time to time,
`validated` is computed last => the `AccessError` is not raised.
Actually, a `ValidationError` should be raised in this case (from the
`create` override in `timesheet_grid`).
This commit is a cherry-pick of 802339c12d
and dcca2e8b9d
Before this commit, a partner in a company could have a fiscal position belonging
to another company
Namely, the search view on the field property account position displayed every fiscal position
This could create problems afterwards, when managing an invoice from a restricted rights user
(with an access right error raising)
After this commit, we soflty constrain the choice of the fiscal position to the ones
belonging to the same company of the partner
OPW 1833848
OPW 1827831
closes#24056
When the `partner_id` is not set (it is not required at the model
level), we can still compute the default destination account based on
the company chart of account configuration.
This is necessary to allow creating "customer" or "supplier" payments without
selecting a specific partner.
We want to force the tax template to be blank always, because multiple companies can potentially use this template to create taxes. We want consistency company-wise.
This is needed to allow having a single bank statement validating 2 payments in case of our internal OGONE processing. An incoming commit in account_batch_deposit will explain more in-depth the use case covered
Commit b6d4cd5deb introduced the auto-reconciliation when reversing
an entry. However, we should make sure to only reconcile non-reconciled
entries. Such an entry can be generated from an exchange rate entry.
opw-1826024
Accounting entries made for invoices and stock valuation on the interim accounts (stock input/output accounts) are now reconciled together for both sales and purchases. This will definitively help to have those accounts zero-outed when all operations are processed.
The reconciliation is made as long as the stock valuation is set in real-time, whatever the costing method.
Note that change change also allow a particular use case to be solved: when a purchase is made in a foreign currency whose rate change between the incoming shipment reception and the bill validation (there will be an automated exchange rate entry created).
Was task 32331. Was PR #22483
Fixed use case:
When creating a new payment (not from invoice), the payment amount is zero and this value triggers an onchange method that set the first miscellanous journal_id as the payment journal_id and force the domain with only miscellanous journals.
This behavior was added in commit 3267e76 to be able to clear invoices by registering a 0 amount payment on it, but this has obviously only interest when registered from the invoices form view... To keep this functionality we only add a "AND" sentence to validate that the payment has invoices, if the payment has not any invoices the journal and the domain of this field will be for bank and cash.
Was task ID 1823023. Was PR #23609. Nice courtesy of Oscar Ulises Garza Córdova
function create_exchange_rate_entry() has been build to potentially receive several aml_to_balance (all sharing the same currency_id), hence aml_to_balance.currency_id would be failing in that case since the ORM is expecting a singleton there.
- Create manually an account move
- Add a line with a credit != 0
- Click on "Add a line" => crash
`line_ids` does not contain the credit since it was not filled in.
opw-782980
Steps to reproduce the bug:
- Create a bank statement with a blank name
- Reconcile any line statement with an invoice
- Review the payment that was made for this statement
Bug:
The payment had no name.
opw:182754
This commit prevent VAT and company name edition if an user has already at
least one document (SO or invoice) for his partner or his related company
partner.
Any module can override this feature to add their own condition to prevent
campany name/VAT edition.
task-33088
Closes#23420
Bug introduced by https://github.com/odoo/odoo/commit/cdca5d4751a979f6b694f02d88160843f81a77f5
There is two problems:
- The payment difference is the difference between what you need to pay and what you pay.
=> The compute does the opposite.
- When the payment type is outbound, the payment amount is never negative.
=> Need to inverse the payment amount in the compute in this case.
E.G.
Suppose A a customer invoice of 25 and B a vendor bill of 50:
Payment on A will compute:
payment_type = 'inbound'
amount = 25
If you pay 20, the payment_difference computed was 20 - 25 = -5
It should be 25 - 20 = 5 instead.
Payment on B will compute:
payment_type = 'outbound'
amount = 50 (not -50!)
If you pay 40, the payment difference computed was 40 - (-50) = 10
It should be -50 - (-40) = -10 instead.
- Create a SO for a customer of 100 $
- Create Invoice for the Sales Order and Register the payment
- Create a Refund Invoice, Validate it and keep it in "Open" state
- Create a second SO for 5 $
- Create an invoice for this order and validate it
- It will show you outstanding payments
- Apply the credit and the invoice will be fulfilled => Now you have a
credit left for 95 $
- Create a third Sales order for the same customer for 5 $
- Create an Invoice for it
- It will show you outstanding credit (95 $)
- Apply the credits
- Now 90 $ are left
- In the same invoice, the credit which you applied, Unreconcile it
- It should have shown you 95 $, but it shows you 100 $ which means it
removed the credit which we applied to second SO
The unreconcile process does not filter the partial reconciliations of
the selected invoice. All partial reconciliations on the AML are
removed instead.
opw-1819602
PR #16826 (rev fa3ff5b41a) added the
`company_id` field in the Journal Entry form.
Unfortunately that field was not marked read-only, so creating a move
would write to this field, triggering a useless and possibly very long
recomputation of many related fields based on the company of the
account. It must be read-only, its value solely driven by the value of
the account_id field.
Steps to reproduce the bug:
-Activate multi currency
-Set the receivable account with the same currency of the company.
-Create a customer invoice in the currency of the company
-Register a payment for this invoice
Bug:
The payment was not reconciliated with the invoice.
opw:1826121
The recent change (e130606602) broke the use case of an invoice/payment in the company currency without any secondary currency involved. Payment was recorded correctly but no full reconciliation was created (and it was not tested).
In order to fix that, we allow to test total_debit and total_credit also when currency has never been set (no secondary currency at all)
Along with new tests, 2 things have been changed:
1) amount_currency field is not written anymore when matching an amount paid in company currency against some invoice(s) in secondary currency (see changes in test_reconciliation.py)
This was previously made to help computing the exchange rate difference entry, but we now instead completelly rely on the amount_currency field set on the partial reconciliation. Besides being wrong from a purely functional pont of view (we never received money in secondary currency so why should the ORM act as if it was the case), it was the root cause of the problem related test_partial_reconcile_currencies_02, in test_reconciliation.py.
2) when registering a payment directly from an invoice, containing both an exchange difference and a write-off to force the full reconciliation, we now correctly create the accounting entries.
A weird behavior spotted in #21888 was introduced by 2093546, to deal with impossibility to full reconcile an invoice due to rounding errors. Fortunately, this use case (test_payment_and_writeoff_in_other_currency_3, in test_payment.py) can now be solved in the right way thanks to changes introduced in the previous point.
When setting a chart of account on a company, we have default taxes from
the default chart of account different from chosen one.
But if a chart of account is chosen, it should override them in the
onchange_chart_template_id function. This works as expected for a
truthy complete_tax_set chart of account template, but not for a falsy
complete_tax_set chart of account template.
The complete_tax_set indicates that we don't want to set default taxes
and the user should do it or modify the given tax rates himself.
opw-1824751
closes#23655
- Set 'Round Globally'
- Create an excluded tax of 10 %
- Create an invoice for a product costing 34.55, and apply the tax.
The tax on the invoice is 3.46, while the tax on the tax line is 3.45.
When rounded in `compute_all`, the tax amount is 3.455, which is the
value expected. However, the `create` method won't round this value
before storing, leading to the inconsistency.
We make sure to round the amount to the currency precision, so the
value 3.46 is recorded.
opw-1819902
Christophe Simonis