Skip to content
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

Merged
merged 1,806 commits into from
Apr 7, 2020

Conversation

renatonlima
Copy link
Member

Migration l10n_br_account and l10n_br_account_product modules

@renatonlima renatonlima changed the title 12.0 mig l10n br account product [12.0] mig l10n br account product Mar 20, 2019
@renatonlima renatonlima force-pushed the 12.0-mig-l10n_br_account_product branch from 1817d4b to 173d802 Compare April 14, 2019 05:47
@renatonlima renatonlima force-pushed the 12.0-mig-l10n_br_account_product branch from 2849d80 to a74f20d Compare April 30, 2019 17:40
@renatonlima renatonlima force-pushed the 12.0-mig-l10n_br_account_product branch 2 times, most recently from 680904b to 39b9548 Compare May 30, 2019 16:03
@renatonlima renatonlima force-pushed the 12.0-mig-l10n_br_account_product branch 2 times, most recently from db368c5 to 1e7aa53 Compare July 15, 2019 23:01
@renatonlima renatonlima force-pushed the 12.0-mig-l10n_br_account_product branch from 0ff24db to 84b51c9 Compare September 10, 2019 03:07
@rvalyi rvalyi changed the title [12.0] mig l10n br account product [12.0] mig l10n br account product - (l10n_br_fiscal and l10n_br_ nfe modules extraction) Sep 11, 2019
Copy link
Member

@rvalyi rvalyi left a 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?

@rvalyi rvalyi mentioned this pull request Sep 13, 2019
@renatonlima renatonlima force-pushed the 12.0-mig-l10n_br_account_product branch from 934f9bf to c6fadde Compare September 19, 2019 02:42
Copy link
Member

@rvalyi rvalyi left a 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)
Copy link
Member

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.


def post_init_hook(cr, registry):
"""Import XML data to change core data"""
from odoo.tools import convert_file
Copy link
Member

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

Copy link
Member

@rvalyi rvalyi left a 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.

@renatonlima renatonlima force-pushed the 12.0-mig-l10n_br_account_product branch 4 times, most recently from fb38a47 to fd4bdf8 Compare November 25, 2019 23:40
@renatonlima renatonlima force-pushed the 12.0-mig-l10n_br_account_product branch from 608c02b to 9a27aad Compare November 29, 2019 14:41
@renatonlima renatonlima force-pushed the 12.0-mig-l10n_br_account_product branch 2 times, most recently from d063648 to cac3836 Compare December 3, 2019 03:35
@renatonlima renatonlima force-pushed the 12.0-mig-l10n_br_account_product branch 3 times, most recently from 6865922 to baadcd6 Compare April 6, 2020 23:46
@renatonlima renatonlima force-pushed the 12.0-mig-l10n_br_account_product branch from baadcd6 to f975d4c Compare April 7, 2020 00:32
@mileo mileo requested a review from rvalyi April 7, 2020 01:05
Copy link
Member

@rvalyi rvalyi left a 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!!!

@rvalyi
Copy link
Member

rvalyi commented Apr 7, 2020

/ocabot merge

@OCA-git-bot
Copy link
Contributor

What a great day to merge this nice PR. Let's do it!
Prepared branch 12.0-ocabot-merge-pr-657-by-rvalyi-bump-no, awaiting test results.

OCA-git-bot added a commit that referenced this pull request Apr 7, 2020
Signed-off-by rvalyi
@OCA-git-bot
Copy link
Contributor

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

@hendrixcosta
Copy link
Member

Parabens pelo trabalho, pessoal

@rvalyi
Copy link
Member

rvalyi commented Apr 7, 2020

/ocabot merge

@OCA-git-bot
Copy link
Contributor

On my way to merge this fine PR!
Prepared branch 12.0-ocabot-merge-pr-657-by-rvalyi-bump-no, awaiting test results.

OCA-git-bot added a commit that referenced this pull request Apr 7, 2020
Signed-off-by rvalyi
@rvalyi
Copy link
Member

rvalyi commented Apr 7, 2020

So, all Ocabot tests are passing but for some unknown reason the merge does not occur despite 2 attempts.
I could find recent example of Ocabot merges that worked some 13 hours before our try:
OCA/purchase-workflow#886
and I could also find another example were the merge didn't happen in a similar way, 5 days before:
OCA/purchase-workflow#881

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.

@rvalyi rvalyi merged commit eafbc3e into OCA:12.0 Apr 7, 2020
@rvalyi
Copy link
Member

rvalyi commented Apr 7, 2020

Hum, so actually Travis and Runbot tests passed with Ocabot, but we had a .pot generation issue during the i18n msgmerge attempt:
https://travis-ci.org/github/OCA/l10n-brazil/jobs/671928547#L2273

2020-04-07 04:15:36,183 7009 ERROR openerp_test click_odoo.env_options: exception 
Traceback (most recent call last):
  File "/home/travis/virtualenv/python3.5.6/lib/python3.5/site-packages/click_odoo/env_options.py", line 214, in _invoke
    return self.org_invoke(ctx)
  File "/home/travis/virtualenv/python3.5.6/lib/python3.5/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/travis/virtualenv/python3.5.6/lib/python3.5/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/home/travis/virtualenv/python3.5.6/lib/python3.5/site-packages/click_odoo_contrib/makepot.py", line 122, in main
    commit_message,
  File "/home/travis/virtualenv/python3.5.6/lib/python3.5/site-packages/click_odoo_contrib/makepot.py", line 70, in export_pot
    raise click.ClickException("%d invalid .po file(s) found" % invalid_po)
click.exceptions.ClickException: 1 invalid .po file(s) found
Error: 1 invalid .po file(s) found

Hopefuly this is an easy fix.

It is also unclear to me what the exact status of the portal test:
https://travis-ci.org/github/OCA/l10n-brazil/jobs/671928547#L2070

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants