-
-
Notifications
You must be signed in to change notification settings - Fork 252
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[12.0] mig l10n br account product - (l10n_br_fiscal and l10n_br_ nfe modules extraction) #657
[12.0] mig l10n br account product - (l10n_br_fiscal and l10n_br_ nfe modules extraction) #657
Conversation
1817d4b
to
173d802
Compare
2849d80
to
a74f20d
Compare
680904b
to
39b9548
Compare
db368c5
to
1e7aa53
Compare
0ff24db
to
84b51c9
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are many things to rewiew. But may be something structuring I can already comment: I suggest to create 2 fiscal user groups:
- simples nacional
- regime normal
eventually the admin user belong to both groups by default (and this could be changed with some profile module later) so he can debug and see everything. Now the benefit would be that a fiscal manager would only see and configure what is important for him: simples or normal regimes.
Moreover is some data is heavy and is required only for the normal regime, then we can load it only when a chart of account for the normal regime is created.
Should we also create some group for users that will only emit NFSe and no NFe under the complex normal regime (to make it simpler then)?
What do you think?
934f9bf
to
c6fadde
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2 small changes asked for now.
|
||
document_type_id = fields.Many2one( | ||
comodel_name='l10n_br_fiscal.document.type', | ||
required=True) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
document_type_id is required however, below the field document_serie_id is required too and the document serie will also carry the l10n_br_fiscal.document.type through the document_type_id required field.
So the model is hyper-constrained. If document_type_id on document.serie is mandatory, then document_type_id on the l10n_br_fiscal.document object should be a related field.
l10n_br_fiscal/hooks.py
Outdated
|
||
def post_init_hook(cr, registry): | ||
"""Import XML data to change core data""" | ||
from odoo.tools import convert_file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's better to import outside of the method
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a problem with the required fields in l10n_br_fiscal.document:
- document_serie_id
- document_type_id
- key
- number
You have to think we will soon have in the l10n_br_account module:
class AccountInvoice(models.Model):
_inherit = 'account.invoice'
_inherits = {'l10n_br_fiscal.document': 'fiscal_document_id'}
So with non Brazilian and possibly existing invoices or even draft invoices this will clash!
So unless you have a good default to set for these invoices, then these fields should not be required at the model level. They should be required at the view level and have a python or SQL constraint instead (like when state='open' or only if some field has a certain value).
Note: it's okay to have partner_id required as invoice have it required too.
751440a
to
252ef7f
Compare
fb38a47
to
fd4bdf8
Compare
608c02b
to
9a27aad
Compare
d063648
to
cac3836
Compare
[ADD] Document event test
Feature/fiscal abstract events
[IMP] Fiscal Dashboard record rules [FIX] Demo data
6865922
to
baadcd6
Compare
baadcd6
to
f975d4c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kudos for this huge piece of work!!!
/ocabot merge |
What a great day to merge this nice PR. Let's do it! |
This PR has the |
Parabens pelo trabalho, pessoal |
/ocabot merge |
On my way to merge this fine PR! |
So, all Ocabot tests are passing but for some unknown reason the merge does not occur despite 2 attempts. So instead of keeping hunting for the problem with the Ocabot, I'll merge this manually then. All Ocabot tasks are expected to run nightly anyway. The merge command is really more of a guard to prevent from merging stuff that doesn't pass tests, specially when stuff is merged just before, which will not be our case here. Hopefully we find out later what the problem is. |
Hum, so actually Travis and Runbot tests passed with Ocabot, but we had a .pot generation issue during the i18n msgmerge attempt:
Hopefuly this is an easy fix. It is also unclear to me what the exact status of the portal test: |
Migration l10n_br_account and l10n_br_account_product modules