-
-
Notifications
You must be signed in to change notification settings - Fork 246
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
base: 14.0
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
<?xml version="1.0" encoding="utf-8" ?> | ||
<odoo noupdate="1"> | ||
<record id="config_param_ibpt_request_timeout" model="ir.config_parameter"> | ||
<field name="key">ibpt_request_timeout</field> | ||
<field name="value">299</field> | ||
</record> | ||
</odoo> |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,8 @@ | ||
from openupgradelib import openupgrade | ||
|
||
|
||
@openupgrade.migrate() | ||
def migrate(env, version): | ||
openupgrade.delete_records_safely_by_xml_id( | ||
env, ["l10n_br_fiscal.l10n_br_fiscal_tax_estimate_rule"] | ||
) |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1,7 @@ | ||
# Copyright (C) 2012 Renato Lima - Akretion <[email protected]> | ||
# License AGPL-3 - See http://www.gnu.org/licenses/agpl-3.0.html | ||
|
||
from odoo import fields, models | ||
from odoo import api, fields, models | ||
|
||
|
||
class TaxEstimate(models.Model): | ||
|
@@ -43,8 +43,22 @@ class TaxEstimate(models.Model): | |
|
||
origin = fields.Char(string="Source", size=32) | ||
|
||
company_id = fields.Many2one( | ||
comodel_name="res.company", | ||
string="Company", | ||
default=lambda self: self.env.company, | ||
) | ||
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 | ||
Comment on lines
+46
to
+64
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Vi que isso foi proposto pelo @renatonlima aqui: Mas tem que ver melhor, da forma que tá sendo feito não tá fazendo diferença.. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
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.
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.