[14.0][FIX] l10n_br_nfse: state registration is EMPTY if in (isenta,isento,…

[marcelsavegnago]

Pessoal,

Quando na inscrição estadual está preenchido como ISENTO dá problema na hora de enviar NFSe para os provedores.

Acho que o código adicionado por esta PR pode ficar mais limpo.. se alguem tiver uma sugestão eu agradeço

[OCA-git-bot]

Hi @mileo, @luismalta, @gabrielcardoso21, some modules you are maintaining are being modified, check this out!

[mbcosta]

@marcelsavegnago não conheço profundamente esse implementação mas teria apenas uma sugestão de arquitetura, pelo o que lembro e talvez esteja enganado, mas no caso de um res.partner que é Isento de Inscrição Estadual, esse campo inscr_est simplesmente ficava vazio e dentro do programa se "entendia" que esse era o caso Isento ( isso é real? Podemos tratar esses casos dessa forma? Quer dizer o caso de um res.partner do Brasil que está marcado o campo is_company é sempre o caso da Inscrição Estadual Isenta? ), porque se for necessário validar o campo esse IF adicionado no PR por exemplo não considera o caso em que o usuário informa o campo com apenas a primeira letra em maiúsculo Isento(a) ( pode ser feito um UPPER ou LOWER na string antes para não ter esse problema ), é isso significa que vamos depender da correta digitação do usuário para identificar esse caso o que se puder ser evitado seria melhor.

[marcelsavegnago]

@marcelsavegnago não conheço profundamente esse implementação mas teria apenas uma sugestão de arquitetura, pelo o que lembro e talvez esteja enganado, mas no caso de um res.partner que é Isento de Inscrição Estadual, esse campo inscr_est simplesmente ficava vazio e dentro do programa se "entendia" que esse era o caso Isento ( isso é real? Podemos tratar esses casos dessa forma? Quer dizer o caso de um res.partner do Brasil que está marcado o campo is_company é sempre o caso da Inscrição Estadual Isenta? ), porque se for necessário validar o campo esse IF adicionado no PR por exemplo não considera o caso em que o usuário informa o campo com apenas a primeira letra em maiúsculo Isento(a) ( pode ser feito um UPPER ou LOWER na string antes para não ter esse problema ), é isso significa que vamos depender da correta digitação do usuário para identificar esse caso o que se puder ser evitado seria melhor.

@mbcosta começando de baixo pra cima.. o UPPER ou o LOWER acho uma boa e deixaria mais enxuto o código. Porém, de qq forma uma letra ou um mero ponto a mais já vai dar problema.

E agora falando do assunto como um todo. Concordo que é valido uma conversa para alinhar de vez esta questão. Eu entendo que o fato de não preencher a inscrição estadual em tese já significa que o cliente eh Isento. Porém, eu já passei por algumas situações com outros sistemas que seguiam esta lógica e isto afetava na hora de identificar quais clientes são de fato isentos e quais clientes estão apenas com cadastro errado devido a inscrição estadual. Este modelo apesar válido, dificulta um pouco a manutenção do cadastro dos parceiros.

@renatonlima @douglascstd A questão do cliente ser ou não contribuinte (definido na aba fiscal) poder ser utilizado para determinar se um cliente é isento ou não?

@mbcosta se a resposta a pergunta acima for negativa, uma possibilidade seria ter um boolean no cadastro do parceiro determinando se ele é Isento ou Não e com isso deixamos o campo Inscrição Estadual como readonly se este o booelan for true para isento. (não sei .. soh jogando ideias no ar :D )

Por ora vou deixar a PR em rascunho.

[marcos-mendez]

Retirado do Contabilizei

Nem todas as empresas que revendem em ambiente online necessitam ter uma IE. Se venda for realizada de forma online sem nenhuma entrega de produto físico ao cliente final, a empresa não precisará ter Inscrição Estadual. Por exemplo, vendas de cursos online e congressos.

Empresas que prestam serviços, tanto de forma online quanto offline, não precisam deste tipo de registro. Contudo, a empresa, então, terá que emitir uma Nota Fiscal de Serviço (NF-S).

Tanto cursos online quanto cursos presenciais não precisam de transporte e armazenamento. Por isso, não há sentido em pagar um imposto de circulação de mercadorias e também não precisará ter registro de Inscrição Estadual. Entretanto, se a empresa vende produtos digitais ou serviços, será necessário obter uma Inscrição Municipal

Ou seja.

Talvez definir que:

Se algum product estiver criado na tabela product.product e pode ser vendido igual true e ao mesmo tempo do tipo estocavel entao portando == a I.E passa a ser obrigatoria.

Agora se somente produtos do tipo serviço estao na table product.product e podem ser vendidos entao I.E = Isento

Outra forma de olhar poderia ser:

Ver se o CNPJ esta habilitado para ser isento e ou se ele posui I.E e qual e por uma api Tipo sintegraws

E isso q entendi Magno. Nao sei se ajuda em algo.

Em sex., 27 de mai. de 2022 12:22, Marcel Savegnago < @.***> escreveu:

@marcelsavegnago https://github.com/marcelsavegnago não conheço profundamente esse implementação mas teria apenas uma sugestão de arquitetura, pelo o que lembro e talvez esteja enganado, mas no caso de um res.partner que é Isento de Inscrição Estadual, esse campo inscr_est simplesmente ficava vazio e dentro do programa se "entendia" que esse era o caso Isento ( isso é real? Podemos tratar esses casos dessa forma? Quer dizer o caso de um res.partner do Brasil que está marcado o campo is_company é sempre o caso da Inscrição Estadual Isenta? ), porque se for necessário validar o campo esse IF adicionado no PR por exemplo não considera o caso em que o usuário informa o campo com apenas a primeira letra em maiúsculo Isento(a) ( pode ser feito um UPPER ou LOWER na string antes para não ter esse problema ), é isso significa que vamos depender da correta digitação do usuário para identificar esse caso o que se puder ser evitado seria melhor.

@mbcosta https://github.com/mbcosta começando de baixo pra cima.. o UPPER ou o LOWER acho uma boa e deixaria mais enxuto o código. Porém, de qq forma uma letra ou um mero ponto a mais já vai dar problema.

E agora falando do assunto como um todo. Concordo que é valido uma conversa para alinhar de vez esta questão. Eu entendo que o fato de não preencher a inscrição estadual em tese já significa que o cliente eh Isento. Porém, eu já passei por algumas situações com outros sistemas que seguiam esta lógica e isto afetava na hora de identificar quais clientes são de fato isentos e quais clientes estão apenas com cadastro errado devido a inscrição estadual. Este modelo apesar válido, dificulta um pouco a manutenção do cadastro dos parceiros.

@renatonlima https://github.com/renatonlima @douglascstd https://github.com/douglascstd A questão do cliente ser ou não contribuinte (definido na aba fiscal) poder ser utilizado para determinar se um cliente é isento ou não?

@mbcosta https://github.com/mbcosta se a resposta a pergunta acima for negativa, uma possibilidade seria ter um boolean no cadastro do parceiro determinando se ele é Isento ou Não e com isso deixamos o campo Inscrição Estadual como readonly se este o booelan for true para isento. (não sei .. soh jogando ideias no ar :D )

Por ora vou deixar a PR em rascunho.

— Reply to this email directly, view it on GitHub https://github.com/OCA/l10n-brazil/pull/1928#issuecomment-1139719411, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJEVVIAFNNQK5MAKJBDHGQ3VMDSD3ANCNFSM5XEMSHQA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[douglascstd]

Pessoal,

Quando na inscrição estadual está preenchido como ISENTO dá problema na hora de enviar NFSe para os provedores.

Acho que o código adicionado por esta PR pode ficar mais limpo.. se alguem tiver uma sugestão eu agradeço

Acredito que para ficar mais limpo seria melhor adicionar um checkmark de isento, isso garantiria que o campo fosse desprezado e que ele foi analizado e é realmente isento

Colocaria o nome de do campo "não se aplica" pois a inscrição pode ser desnecessária para o cadastro em determinadas situações

[mbcosta]

@marcelsavegnago entendo o ponto "eu já passei por algumas situações com outros sistemas que seguiam esta lógica e isto afetava na hora de identificar quais clientes são de fato isentos e quais clientes estão apenas com cadastro errado devido a inscrição estadual" eu acredito que por um tempo isso também foi necessário aqui mas como escrevi isso deixo de ser preciso, bom é preciso saber se existe a possibilidade de identificar se é Isento ou Não por outros campos sem a necessidade do usuário definir isso, acredito que o @renatonlima é a pessoal ideal para avaliar a questão

@marcos-mendez essa identificação precisa acontecer independente dos produtos porque isso é uma etapa anterior a venda ou compra de um produto é no momento do cadastro do Cliente ou Fornecedor, onde ele informa se é Isento ou não, o que acontece é que precisamos confirmar a necessidade de colocar algo no campo insc_est como um ISENTO ou não para isso, talvez exista.

@douglas-tabut sobre a necessidade de incluir um campo, eu acredito que menos é mais, isso é nesse caso se for desnecessário ter um campo porque temos como saber se um caso é Isento ou Não através dos outros campos ou mesmo através de um método ou mesmo um campo compute sem a necessidade do usuário informar eu penso que será melhor dessa forma, mas se não houver um campo Boolean pode resolver.

[renatonlima]

Olá pessoal,

Antigamente o campo IE era preenchido como ISENTO quando o contribuinte era isento e não tinha IE, com o passar do tempo foi criado o campo de indicação do contribuinte:

É utilizado o campo perfil fiscal de parceiro:

Ao selecionar o perfil fiscal do parceiro, é preenchido o campo contribuinte do ICMS e regime tributário

@marcelsavegnago Eu diria que caso o campo ind_ie_dest for 9 (Não Contribuinte) o campo deveria sempre ficar em branco ou permitir só números e não deixar ser preenchido caracteres porque antigamente antes do campo ind_ie_dest existir fazia sentido preencher ISENTO no campo IE, hoje não faz sentido.

[marcelsavegnago]

@marcelsavegnago Eu diria que caso o campo ind_ie_dest for 9 (Não Contribuinte) o campo deveria sempre ficar em branco ou permitir só números e não deixar ser preenchido caracteres porque antigamente antes do campo ind_ie_dest existir fazia sentido preencher ISENTO no campo IE, hoje não faz sentido.

Showww.. vou prototipar algo e envio uma PR para o lugar correto.

[mileo]

@marcelsavegnago pode dar um rebase?

[marcelsavegnago]

@marcelsavegnago pode dar um rebase?

Feito

[mbcosta]

Pessoal estou buscando unificar os métodos de validação do IE, CNPJ e CPF no PR https://github.com/OCA/l10n-brazil/pull/2730 , a minha opinião é que o campo deve ser vazio nesses casos o que parece ser a opinião do @renatonlima e do @antoniospneto e ao selecionar o campo "Contribuinte do ICMS" como "2-Contribuinte Isento do ICMS" deveria chamar um onchange para apagar o IE e deixar o campo invisível, mas é importante avaliar e ouvir a opinião dos outros desenvolvedores para saber sobre outros possíveis casos de uso, porque se for permitido o isento preciso alterar a validação para considerar as várias formas do isento como está sendo feito aqui:

self.inscr_est not in ("isento", "isenta", "ISENTO", "ISENTA")

[github-actions[bot]]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.