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

[14.0][IMP] l10n_br_fiscal: Melhoria no funcionamento dos impostos estimados #3373

Open
wants to merge 4 commits into
base: 14.0
Choose a base branch
from

Conversation

corredato
Copy link
Contributor

Esta PR substitui a PR #3152

@renatonlima Assim que puder, pode fazer a revisão? Fiz a melhoria com base na segunda solução que você propôs no PR #3152

Resumindo:

  1. Exclusão dos campos estimate_tax_national e estimate_tax_imported
  2. Refatoração do método _compute_amount para get_estimated_taxes e algumas mudanças no mesmo
  3. Exclusão do company_id do l10n_br_fiscal.tax.estimate e implantação do campo active no objeto

@corredato corredato changed the title [IMP] l10n_br_fiscal: Melhoria no funcionamento dos impostos estimados [14.0][IMP] l10n_br_fiscal: Melhoria no funcionamento dos impostos estimados Sep 19, 2024
@OCA-git-bot
Copy link
Contributor

Hi @renatonlima,
some modules you are maintaining are being modified, check this out!

@marcelsavegnago
Copy link
Member

@corredato se possível fecha então a PR #3152

@mileo
Copy link
Member

mileo commented Oct 7, 2024

@marcelsavegnago @antoniospneto @rvalyi @renatonlima podem revisar plz.

@antoniospneto
Copy link
Contributor

Pessoal, eu pretendo revisar essa PR com mais calma nos proximos dias.

@antoniospneto
Copy link
Contributor

Coloquei meu token do IBPT no runboat, mas dá esse erro ao tentar atualizar o valor aproximado do imposto:
image
Alguém pegou esse erro tbm?

@mileo
Copy link
Member

mileo commented Oct 7, 2024

Tem um system parameter que foi alterado uns meses atrás e não esta setado por padrão.

@corredato pode incluir isso no seu PR como uma melhoria? ibpt_request_timeout

@corredato
Copy link
Contributor Author

Tem um system parameter que foi alterado uns meses atrás e não esta setado por padrão.

@corredato pode incluir isso no seu PR como uma melhoria? ibpt_request_timeout

Sim, pode deixar

Comment on lines +46 to +64
active = fields.Boolean(string="Ativo", default=True)

def _deactivate_old_estimates(self):
for estimate in self:
domain = [
("id", "!=", estimate.id),
("state_id", "=", estimate.state_id.id),
"|",
("ncm_id", "=", estimate.ncm_id.id),
("nbs_id", "=", estimate.nbs_id.id),
]
old_estimates = self.search(domain)
old_estimates.write({"active": False})

@api.model_create_multi
def create(self, vals_list):
estimates = super().create(vals_list)
estimates._deactivate_old_estimates()
return estimates
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

O que motivou a criar esse campo de ativo? não vejo muita necessidade nisso.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Vi que isso foi proposto pelo @renatonlima aqui:
#3152 (comment)

Mas tem que ver melhor, da forma que tá sendo feito não tá fazendo diferença..

Copy link
Contributor

@antoniospneto antoniospneto Oct 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pessoal, o que eu acho que dá pra fazer, é manter apenas uma linha de imposto estimado para cada estado no NCM/NBS. não acho necessário fazer um controle de ativo ou desativo. Nem é interessante manter um histórico das taxas antigas, isso só geraria muito lixo no banco de dados, só de NCM temos 40 mil linhas.. pensa no quanto isso pode crescer.

Poderia até fazer uma validação para não permitir dois impostos aproximados para o mesmo Estado, mesmo NCM.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

talvez já daria para manter o histórico das mudanças no chatter apenas?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

acho que por a data de sincronização na linha do imposto estimado já seria o bastante, se não o chatter vai ficar monstruoso tbm, a configuração padrão é atualizar a cada 15 dias, acho que vai ser muito spam, opnião minha.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

concordo no módulo l10n_br_fiscal é melhor assim mesmo. Tem como logar isso num módulo extra se alguém quiser. Num projeto eu sobrecarreguei a logica do chatter para conservar apenas os ultimos N mensagens. Mas melhor guardar isso para um modulo extra do que acumular muito mais coisas nesse módulo.

Comment on lines +34 to +44
def get_estimated_taxes(self):
self.ensure_one()
object_field = OBJECT_FIELDS.get(self._name)
last_estimated = self.env["l10n_br_fiscal.tax.estimate"].search(
[
(object_field, "=", self.id),
("state_id", "=", self.env.company.state_id.id),
],
order="create_date DESC",
limit=1,
)
Copy link
Contributor

@antoniospneto antoniospneto Oct 8, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aqui eu ainda não consegui compreender qual vantagem de trocar compute por esse método..
Tem que ver se isso é o que o @renatonlima queria, talvez não era bem isso..

Eu penso que talvez não é o mais seguro buscar o estado de dentro da empresa ativa.
Acho que seria melhor o local que precisar dessa informação informar o estado, por exemplo na Fatura, seria pego o estado de dentro do company_id definido na fatura.

Copy link
Contributor

@antoniospneto antoniospneto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concordo na parte de remover o company_id.
Concordo em por o timeout padrão.

Quanto aos campos computados estimate_tax_national, estimate_tax_imported que foram substituidos por um método, precisa ser descutido melhor.

Quanto ao controle de estimativas ativas, tbm penso que tem que ser discutido melhor, não tá claro isso.

Copy link
Member

@mileo mileo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ValueError: Invalid field l10n_br_fiscal.tax.estimate.company_id in leaf ('company_id', 'in', [1])

Ta dando um erro estranho ao inserir um item, pode verificar?

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

Successfully merging this pull request may close these issues.

6 participants