"total_invoiced" must only take customer invoices into account because
when you click on the button "invoiced" in the partner view form
you just see the customer invoices.
Adaptation for 8.0 of 9.0 fix made at 37569695
Closes#12044
The user performing reconciliations may not always
have the right to update the corresponding partners,
for example if a partner is also a system user.
Doing it as super-user after verifying that the
user is indeed allowed to reconcile journal items
works around the problem.
Fixes#11931
Properties depends on with which companies the records
are browsed.
When retrieving the fiscal position as sudo,
the company must therefore be enforced within the context,
to make sure to get the properties from the right
company.
This method can totally be accessed as sudo,
within the crons for instance.
Before this revision, the recurring invoices cron
could retrieve properties from the wrong company,
and therefore retrieve the fiscal position of another
company.
Closes#11039
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
contracts_count function field
&
journal_item_count function field
used for the "contracts" and "journal items" buttons
in the partner view are computed by the same
method.
But, this is possible that you have access to
one without having access to the other.
e.g., Project users not being salesman nor accountant
must have access to the contract counts,
but not to the journal items.
Besides, these buttons are added to the partner form
by two separated views, applied to analytic accounting group
& accountant group, respectively.
We therefore avoid to compute the journal items count when
not needed, when not loaded in the partner view.
We therefore prevent the access right issue, and provide
a performance improvment at the same time. Yay.
opw-632454
"Invoiced" stat button on the res.partner form view must not include cancelled and draft invoices.
The button triggered an action which shows a tree view with invoices where:
type in ['out_invoice'] and all states.
Now the button triggers a tree view with invoices where: type in ['out_invoice' , 'out_refund']
and state not in ['draft', 'cancel'].
opw:472318
The original tax should not be applied
if at least one destination tax was
applied. It should only be applied if
explicitly included in target taxes.
(Re-)Fixes #2261
(This is a regression in Odoo 8)
It should now work when a fiscal position replaces 1 tax with
several taxes (for example : Fiscal position "Intra-EU B2B" in l10n_fr)
Fixes#2261, manual merge of PR #3316
First match a fiscal position for the given country, then for a country
group containing the country. If none found, search a fiscal position
without country nor country group
Otherwise, if done with the superuser:
- The multi-company rules won't work, the user will have the amount of all invoices, cross-companies
- The amount currency will always be the currency of the superuser
Fixes#971:
File "/Users/keje/src/odoo/addons/account/partner.py", line 107, in get_fiscal_position
return part.property_account_position.id
NameError: global name 'part' is not defined
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
Add group of countries res.country.group
Add get_fiscal_position method a method to compute a fiscal position based on company_id, partner_id, delivery_id
The meaning of res.partner.fiscal_position is now a forced a fiscal position.
The default implementation should handle simple cases, like VAT in UE and sales
tax in the US, but the method can be overriden to handle more complex ficals
rules.
The field note on account.fiscal.position and account.fiscal.position.template should not be translatable in classic modules.
The l10n_multilang module is intendend to make chart of accounts multilang and is the place to set translate=True
improve the logic of _journal_item_count (removes try/except/pass, use search_count) and remove useless one2many field in res_partner (journal_item_ids)
bzr revid: ged@openerp.com-20140507121310-ya6m71fvs40rf90d
Fixes handling of accounting/invoicing-related fields on partners
that are not "commercial entities" (either marked as "is_company"
or parentless).
The corresponding fields are also hidden from form views on these
partners and replaced by a short sentence and a link to edit the
"master fields" on the commercial entity.
This corresponds to part B of the solution described on bug 1160365.
lp bug: https://launchpad.net/bugs/1160365 fixed
bzr revid: odo@openerp.com-20130407235013-j3tv4uxy46eej43i