=================================================
Variable quantity in contract recurrent invoicing
=================================================
With this module, you will be able to define in recurring contracts some
lines with variable quantity according a provided formula.
Configuration
=============
* Go to Sales > Configuration > Contracts > Formulas (quantity).
* Define any formula based on Python code that stores at some moment a
float/integer value of the quantity to invoice in the variable 'result'.
You can use these variables to compute your formula:
* *env*: Environment variable for getting other models.
* *context*: Current context dictionary.
* *user*: Current user.
* *line*: Contract recurring invoice line that triggers this formula.
* *contract*: Contract whose line belongs to.
* *invoice*: Invoice (header) being created.
Usage
=====
To use this module, you need to:
* Go to Sales -> Contracts and select or create a new contract.
* Check *Generate recurring invoices automatically*.
* Add a new recurring invoicing line.
* Select "Variable quantity" in column "Qty. type".
* Select one of the possible formulas to use (previously created).
* company_id was empty because an onchange, not inheritance nor visibility
* Added multi-company group to company_id fields
* Added multi-company access rule to contract templates
* Fix double %% in XML dates that was causing an error
* When creating a contract, recurring_invoices is set by default
* Correct domain attribute in field journal_id
Original domain includes unknown value company_id. Throws error when selecting the journal.
* Corregidos errores detectados por Lint
* Refactoring, DRY
* [FIX] Add missing field company_id to account_analytic_contract
* Small refactoring for company_id field
* [FIX+IMP] contract: Improve usability and don't fail on wrong data
* Cron create invoices masked for avoiding silent errors
* New constraints for assuring data consistency
* UI helps for entering consistent data
* Spanish translation
* Remove double company_id field on form
* Use SavepointCase for making the setup only once for all tests
* Make them inheritable, creating a base class with only the setup,
so that it can be inherited without the need of executing all tests
contained here each time you inherit it, and adding other class
in the same module that inherits from the base class that actually
performs the tests.
* Removed duplicated test method
Having a primary view that is not explicitly declared to be uses and w/o priority
makes Odoo to choose between one of them randomly (well, not exactly, but kind of),
so we put here which views to use.
I have also put tree view as primary and put a large priority for not being
selected on other actions that don't have this explicit views.
A friendly name in views is also assigned.
In order to get visibility on https://www.odoo.com/apps the OCA board has
decided to add the OCA as author of all the addons maintained as part of the
association.
