In the Account Tax Decalaration wizard,
Accounting > Reporting > Generic Reporting > Taxes > Taxes Report,
When not choosing the start/end period, but choosing
a fiscal year, the fiscal year was simply ignored,
the report took a fiscal year randomly.
In addition, if no fiscal year was chosen,
the fiscal year randomly chosen could even
not be a fiscal year of the right company,
in a multi-company environment.
closes#7219
opw-643194
Some tests (e.g. mail) have expensive and significant DB setup for a
number of small and cheap tests. Using a TransactionCase, the DB setup
far dominates the tests themselves, by up to 10x (mail unit tests take
~130s on my machine, the tests themselves take ~15s).
The SavepointCase introduced here is an hybrid of SingleTransactionCase
and TransactionCase: it uses a single transaction for all tests in a
class, but each test case is isolated by a rollbacked savepoint. This
allows a common DB setup (via setUpClass) while keeping independent
tests.
TransactionCase should remain the primary test case superclass, but
SavepointCase can be a fair optimisation when setup costs far dominate.
The computation of total_invoiced field was very slow when the size of
account.invoice.report grows. This is due to usage of the field
user_currency_price_total that requires to build the full view (generates query
(id in []) for function field).
Using temporary SQL view (inspired by caf333e), directly filter the needed
items and avoid building the full table.
Fixes#6654
- remove 2011 tax data
- remove unneeded tax account for 0% taxes
- TVA en amont moved under 421611 instead of 422611
- Fix issues with IB-PA, AP-PA, IP-PA and all taxes with children
- improve structure for tax codes
- fix account type (other -> view)
- add fiscal position mappings
- credit part of IC/EC taxes goes into account 461 instead of 421
- add missing template account for TVA en amont extracommunautaire
- fix a long standing issue with the reconcile flag on accounts
- use TRUE/FALSE instead of t/f in the csv
- added source XLS file with conversion script
Closes#5870
The paid status should be removed automatically once the membership is
expired. Previously, it would only be done when some other models fields
changed (invoice, membership_line, res.partner).
closes#6823
related to opw-640440
Field show_menu generates three menus Introduction, Location and Register on the
page of the event on the website.
Generating new menus requires the Technical Features groups so checking this box
would produce and error on non-technical users.
Moreover these menus are hardcoded, making it less useful and may produce
unexpected behaviour (replaces previous menus).
Hide the menus to non-technical users and add help message explaining the
effect of the field.
Fixes#7099
When a PO line is deleted, it sets the related procurements in exception.
This fix logs this action in the procurement chatter, for WMS administration
and maintenance purposes.
When a MO is cancelled, it sets the related procurements in exception.
This fix logs this action in the procurement chatter, for WMS administration
and maintenance purposes.
This decision comes from the following bug:
- Go to Sales -> Quotations, and open any existing quotation in form view (the
partner must have an address defined)
- Click on the partner
- Click on the stat button "Claims"
- You notice that the address of the partner is included in the search
This is due to the context property show_address which is set to 1 when a
quotation is open. Therefore, it is necessary to filter out this keyword.
Since the prefix "show_" is used for only few context variables, it was decided
to define this pattern as a standard pattern to filter out.
opw-642893
Required after e17844c946 which
enabled graceful shutdown of workers, including the cron worker.
The latter may typically be busy on long-running tasks that
will not be aborted by a simple graceful shutdown request.
A typical shutdown sequence initiated by a daemon manager such
as start-stop-daemon will involve multiple SIGTERM signals to
ensure the process really stops in a timely manner.
This was not possible after e17844c946
if any cron worker was busy.
If the transaction already exists, the amount total of the transaction must
be updated.
The case occured when:
[1] you put a product A in the cart
[2] click on "Process Checkout" and click "Confirm"
[3] select Adyen or Paypal as payment method
[4] click on "Pay Now"
[5] return in the cart instead of paying your order
[6] add a product B in the cart
[7] click on "Process Checkout" and click "Confirm"
[8] select Adyen or Paypal as payment method
[9] click on "Pay Now"
Now check the transaction payment linked to the order in backend, the total amount of the order is equal
to price A + price B and the total amount of the transaction payment is equal to price A.
This commit solves this problem.
opw:634119
The procurement created from a move has as source document[by priority]:
[1] move.rule_id.name
[2] move.origin
[3] move.picking_id.name
ps: the internal transfer is created with this procurement.
opw:641887
This allows to reset correctly the domain of UoM if the product is not set.
Without this patch, the domain used is the domain of the previous product in
the list.
opw-642074
Nicolas Bustillos
luc-demeyer
vrenaville
Xavier Morel
Denis Ledoux
Martin Trigaux
Wolfgang Taferner
Olivier Dony
Stéphane Bidoul
Nicolas Lempereur
Iris86
sve-openerp
Nicolas Martinelli
Odoo Translation Bot
Goffin Simon
gfcapalbo
Donka Lapunova
Vassil Toumbev
Valentin Chemiere
Bogdan Lisnenko
Christophe Simonis
Bartłomiej Wójcicki
Csaba Palankai
Will Earp
Matthieu Dietrich
Antonio Espinosa