- Create a new company
- Connect your user to this company
- Do not choose a chart of accounts
- Go in accounting
- Select a step in the config bar (Fiscal Year, Chart of Accounts,
Initial balances)
A warning message is raised : "No miscellaneous journal could be found.
Please create one before proceeding."
However, we should be able to enter fiscal year step. Moreover, the
error message is unclear.
opw-804760
In multi company, when a user 1 creates a purchase invoice I in company A.
The responsible of the invpoice I is user 1. But if the user 1 changes his company from
company A to company B. Then it raised an access error when a user 2 in company A
tries to duplicate the invoice I because the responsible is in an other company.
Now the responsible is not duplicated to avoid access error.
opw:805573
When validate and invoice with analytic account on
some invoice lines, analytic entries are created
with the account move creation, after that the move
is posted (still in the invoice validation) and the
analytic entries are regenerated (meaning deleted
and recreated).
As consequence, performance are bad, but also, since
in vendor bills flow, the creation of AAL can create
a new sale order line, we will get 2 SOL (one empty).
This commit avoid creating the first analytic entries
(the ones deleted on move posting) when validating
an invoice.
Before this commit, in the event that the admin user has set the language
to english, but the COA's target company had a different language,
the admin user's language had been taken instead of the copany's one
for the translation of journals and other coa intialization stuff.
This is wrong as the CoA is more connected to the company, than to the
user, which could be a functional support user that just happens to prefer
the english version over the local one.
Now, we ensure in two neuralgic places, that the company's language is passed
to the context and therefore picked up by the translation's GetTextAlias.
Signed-off-by: David Arnold <dar@xoe.solutions>
The field `price_subtotal_signed` contains the price converted in the
company currency. However, we should make sure to use the exchange rate
of the invoice date for its computation.
An use problematic use case is the creation of a deferred revenue from
an invoice (commit 7fe89d08b3).
opw-702352
When changing the date of an account move, the method
`_onchange_amount_currency` is called manually on a recordset. If the
recordset length is > 1, it crashes.
- In an account move, change the date
- All debits and credits of the lines are reset
This is because the recomputation of the credits and debits should only
occur in case of currency rate change.
opw-801030
When reinitializing modules it is impossible to create partners if
account is installed because invoice_warn field has a required column
but no default value if the module does not depend from account. Use
case is trying to run test_mail tests with account installed.
As this field is not business critical it is now not required. As there
is a default value behavior should not change for users.
Commit 74e4130f5f makes sure to make the accounting date prevail on
the invoice date when it comes to currency conversion.
However, the choice of date is not universally recognized. Softwares
(and accountants) might use either the accounting date or the invoice
date.
Therefore, we provide a hook se the behavior of the software can easily
be changed if necessary.
opw-783372
When an invoice is paid, the button "Cancel" was not visible. For a better guidance, we now show that button.
Indeed, after having unreconcilied the invoice and the payment, the user should be able to cancel the invoice.
It also now allows to cancel wrongly encoded invoices with 0 as total (they were directly marked as paid, preventing
their cancellation)
Was PR #20470. Was task: https://www.odoo.com/web#id=34307&view_type=form&model=project.task&action=333&active_id=967&menu_id=4720
When using the fast_counterpart creation method to automatically
reconcile bank statement lines, there was no verification that the
account id was not set or that the statement was already linked to journal
entries. It was causing a traceback in some conditions when the
demo data were loaded because the fast_counterpart_creation was called
without the verification, using an XML function.
This commmit introduce the necessary verifcation.
Thanks @qdp-odoo for the review and some docstrings/comments
Main resource document to be found at https://www.economie.gouv.fr/files/files/directions_services/dgfip/controle_fiscal/actualites_reponses/logiciels_de_caisse.pdf
This document states that only business operations with partners not being subject to VAT should be inalterable and secure.
We adpat the module by differentiating between b2c and b2b journals and apply hashing on the former's moves
Protection against account_cancel is not necessary anymore
By default, this module considers a sales journal being a b2c, thus activating hashing on its move.
Since we can't afford to lose information, when a b2c journal contains hashed moves, its b2c characteristic cannot be changed
[ADD] l10n_fr_pos_cert: module to adapt the POS to the recent French regulation CGI art. 286, I. 3° bis.
The module adds following features:
- Inalterability: deactivation of all the ways to cancel or modify key data of POS orders, invoices and journal entries
- Security: chaining algorithm to verify the inalterability
- Access to download the mandatory Certificate of Conformity delivered by Odoo SA (only for Odoo Enterprise users)
[ADD] l10n_fr_sale_closing: module to store automatically the total of daily/monthly/annualy sales.
(both of the period and cumulative).
This fulfills another requirement brought by the recent French regulation CGI art. 286, I. 3° bis related to the storage of data
Was PR #20581. Was task 29922
Christophe Simonis