Alterar O Campo Aliq_Ipi No Registro C170

[Lucas Rutkoski]

Olá pessoal!

 

Atenção! Este post acabou ficando muito grande, mas preferi documentar bem minhas ideais para facilitar a discussão sobre o assunto. Me desculpem.

 

Despois de ter aberto tópico em agosto do ano passado, acabei sendo recolocado em diversos outros projetos da empresa, e não consegui dar a atenção devida a ele. Voltamos agora então à questão da alíquota de IPI para produtos tributados por quantidade e não por um percentual fixo;

 

No tópico referenciado acima, o Isaque Pinheiro havia dado a sugestão de alterarmos o método "WriteRegistroC170", de forma que o campo ALIQ_IPI chamasse a rotina "LFill()" passando o parâmetro "Nulo" como "True", para que o campo fosse enviado em branco sempre que estivesse preenchido com 0.

 

Acontece que existem situações onde o produto é tributado por um percentual fixo, mas em uma determinada situação deve ser enviado com a alíquota 0, pois a operação é isenta de contribuição ou o produto é tributado à alíquota de 0%. Desta forma, vimos que a solução proposta não atenderia a todas as situações de escrituração do registro.

 

Conversando com meus colegas de trabalho, chegamos a 3 modificações diferentes que poderão solucionar este problema, mas cada uma possui alguns pontos positivos e negativos que devem ser avaliados para decidirmos qual é a melhor implementação para o componente e a comunidade, ou se nenhuma das soluções propostas é a ideal e devemos voltar e analisar isto novamente.

 

1ª modificação sugerida: Alterar o tipo do field "fALIQ_IPI” de Currency para String

Nesta modificação, o tipo do field é alterado para que passe a utilizar o overload do método “LFill” para campos texto, sendo gerado em branco sempre que o field estiver em branco. Para manter o propósito do campo, escrevemos um método “Set” para a property ALIQ_ICM que trata valores brancos e inválidos, permitindo que o field esteja apenas em dois estados (Em branco ou preenchido com uma alíquota válida).

 

Ponto positivo:

Esta modificação é a que menos causa impactos no componente, pois apenas duas units são alteradas e as alterações são "cirúrgicas", não influenciando no comportamento do componente;

 

Ponto negativo:

O principal ponto negativo desta modificação é que, ao realizarmos esta alteração, o componente irá parar de funcionar para quem já gera o SPED Fiscal hoje, até que a equipe de desenvolvimento da empresa possa atualizar a rotina de geração do registro C170 e alterar o campo de Currency para String;

 

2ª modificação sugerida: Alterar o tipo do field “fALIQ_IPI” de Currency para Variant

Esta modificação é muito parecida com a sugerida acima, alterando o tipo do field para que se possa utilizar o método “LFill” para strings e validar quando o mesmo estiver em branco, mas com a grande vantagem de não alterar o funcionamento externo do componente nos projetos da comunidade.

 

Ponto positivo:

Quem já está utilizando a classe não terá de modificar o seu código fonte após atualizar o componente. O registro continuará sendo gerado da maneira correta;

 

Ponto negativo:

Um ponto negativo que levantamos para esta modificação é a compatibilidade do tipo "Variant" com usuários do Kilyx. Como nunca utilizamos, não temos como garantir aqui o funcionamento correto desta.

 

3ª modificação sugerida: Criar um novo field na classe "TRegistroC170" para controlar o campo “ALIQ_IPI”

Esta modificação prevê a criação de um novo field na classe para que o usuário possa indicar se um determinado produto tem o IPI tributado por uma alíquota específica ou por quantidade vendida. Desta forma, podemos criar uma validação específica dentro do método "WriteRegistroC170" para gravar 0 ou vazio neste campo do layout conforme a configuração deste novo campo.

 

Ponto positivo:

Com esta modificação, podemos garantir que o funcionamento do componente não será modificado para nenhum usuário, independente da plataforma utilizada.

 

Ponto negativo:

Não conseguimos encontrar algo que invalidasse esta sugestão, pois a criação de um novo field para controlar esta situação garante o isolamento da modificação.

 

 

 

E estas são as sugestões que conseguimos elaborar aqui na empresa para solucionar este problema. Anexo abaixo estão os fontes com as duas primeiras modificações implementadas, para que vocês possam baixa-las e verem como funcionam na prática. Acredito que até o final da semana conseguirei criar um exemplo da 3ª sugestão para avaliarem.

 

Novamente peço desculpas pelo tamanho que este post acabou ficando e agradeço a quem puder auxiliar!

 

Edição: Já consegui montar um exemplo da implementação da 3ª sugestão no componente, anexo abaixo;

1ª modificação sugerida.zip

2ª modificação sugerida.zip

3ª modificação sugerida.zip

Editado 27 Fevereiro, 2014 por Lucas Rutkoski

[Juliomar Marchetti]

Não seria somente este caso, existem outros nessa mesma situação!

que não se deve informar nada

Acho que a primeira solução seria a mais cabível, pois se olhar a estrutura do banco do sped

existe somente varchar, numeric e data onde alguns campos que são numérico estão como varchar!

 

aguardemos os demais colegas!

[Lucas Rutkoski]

Juliomar,

 

  Já conseguimos identificar alguns campos que precisam desta mesma modificação, mas como a lógica da alteração seria a mesma, focamos em apenas um deles primeiro. Me disponho a alterar os outros campos também após decidirmos qual é a melhor maneira de realizar a modificação.

[EMBarbosa]

Olá Lucas,

  Era pra eu ter analisado suas sugestões esta semana, mas aconteceram alguns imprevistos. Não estou ignorando suas sugestões, apenas não tive tempo de ver o código. Vou fazê-lo o quanto antes for possível, pois essa questão já é bem antiga...

 

  Enquanto não faço isso, gostaria de saber se você chegou a ver a sugestão do Isaque de um evento que permite ao usuário fazer as alterações sobre como ele quer que os campos sejam tratados? Veja esse tópico que fala de outro registro com um problema parecido e depois me diga o que acha.

[Lucas Rutkoski]

Bom dia Elton!

 

Na verdade eu é que devo pedir desculpas agora. Não recebi o e-mail do fórum avisando que o tópico havia sido respondido e acabei não lendo a sua interação antes.

 

Dei uma olhada por cima no evento criado pelo Isaque e acredito que ele irá resolver sim o problema deste registro e dos outros que precisam deste mesmo tipo de validação. Vou fazer alguns testes adaptando este evento para o registro C170 e vou postar aqui o resultado com os fontes depois, para discutirmos a inclusão destes eventos nos outros registros do componente.

[EMBarbosa]

Bom dia Elton!

 

Na verdade eu é que devo pedir desculpas agora. Não recebi o e-mail do fórum avisando que o tópico havia sido respondido e acabei não lendo a sua interação antes.

Não tem problemas. Espero que consiga configurar suas opções do fórum para atender seus objetivos.

 

 

Dei uma olhada por cima no evento criado pelo Isaque e acredito que ele irá resolver sim o problema deste registro e dos outros que precisam deste mesmo tipo de validação. Vou fazer alguns testes adaptando este evento para o registro C170 e vou postar aqui o resultado com os fontes depois, para discutirmos a inclusão destes eventos nos outros registros do componente.

 

Ok. Vou aguardar sua posição pois seria melhor termos mais programadores analisando essa questão. Ela vai afetar muito o modo como estamos trabalhando e assim, seria melhor uma decisão definitiva atendendo a todos os casos.

[Lucas Rutkoski]

Pessoal,

 

  Analisei as duas opções de eventos que poderiam ser incluídas no registro C170 do SPED Fiscal e, apesar das duas resolverem o problema, acredito que não são a melhor solução, pois irão deixar a geração do arquivo de exportação do SPED Fiscal mais lenta.

 

Explicação: Hoje, tanto o evento que já existe para o registro C170 "procedure(var ALinha: AnsiString)" como o registro criado pelo Isaque para o SPED Contribuições "procedure(var ANullVL_BC_PIS, ANullALIQ_PIS, ANullQUANT_BC_PIS, ANullALIQ_PIS_QUANT,  ANullVL_PIS: Boolean)" não são "saudáveis" para a geração do arquivo pois não há uma forma de identificar se o campo da alíquota de IPI deve ser enviada na própria linha, tendo o evento de consultar o banco de dados da aplicação para verificar a configuração do produto na nota que está sendo exportada para decidir como enviar o campo.

 

Isto significa que, caso eu possua 10 notas e cada nota possua uma média de 7 produtos, são 70 consultas adicionais ao banco de dados apenas para gerar o registro C170! Isto em uma configuração TCP/IP local ou pela Internet irá deixar a geração do arquivo muito mais lenta, independente da tecnologia utilizada.

 

Gostaria de verificar com vocês então se existe a possibilidade de analisarmos uma alteração na classe para que cada registro possa ter a sua configuração, indicando se os campos devem ser gerados nulos ou com zeros. Exemplo: A cada "RegistroC170New" se definiria as variáveis que são definidas no evento "OnBeforeWriteRegistroC481" criado pelo Isaque e, na hora de geração do registro no arquivo, a classe iria validar as variáveis do próprio registro, e não do evento, tornando assim cada linha independente.

 

Peço desculpas se minha explicação ficou confusa. Se precisar, posso tentar explicar de uma outra forma a minha análise.

[EMBarbosa]

Olá Lucas,

Peço desculpas se minha explicação ficou confusa. Se precisar, posso tentar explicar de uma outra forma a minha análise.

   Não, pelo contrário. Ficou muito boa.

   Veja, o Isaque parece que está fazendo algumas modificações nesse caso. Você pode conferir neste tópico:

   Não sei se vai sanar o problema pois eu não tive prazo ainda de analisar as mudanças.

[Lucas Rutkoski]

Boa tarde Elton!

 

Vi a alteração que o Isaque realizou no tópico que você mencionou e, depois de pesquisar na documentação do SPED Fiscal, acredito que esta solução não poderia ser aplicada neste caso.

 

Tentei encontrar algum campo no registro C170 ou nos "pais" dele que nos indicasse a forma de tributação do IPI, mas não consegui identificar uma forma clara. Existe um campo no registro C170 chamado de "COD_ENQ", onde se deve informar o código de enquadramento do IPI, mas como a tabela de códigos ainda não foi disponibilizada pela Sefaz, não temos como saber se este campo serviria para diferenciar um produto tributado por percentual de um tributado por unidade comercializada.

 

Não sei se outras pessoas/empresas também estão passando por este problema e como o estão resolvendo. Gostaria de escutar outras opiniões sobre este assunto para tentarmos encontrar uma solução que atenda a todos.

[Isaque Pinheiro]

Bom dia, Lucas entendi perfeitamente a necessidade e justificativa de demora no processamento, então como não existe ainda uma tabela para esse campo COD_ENQ, e não sabemos se quando ela existir teremos como saber se ela nos informará a tributação do IPI, podemos usa-la para identificar e fixa vazio no método Write do registro C170 ponto.

 

Agora uma pergunta a situação em que a percentual do IPI for tributado a ZERO, não se consegue identifica-lo por sua CST ? Por meu entendimento, a CST é quem deveria trazer esse tipo de informação CST 01 -Entrada, 51-Saída.

[Lucas Rutkoski]

Bom dia Isaque!

 

  No caso do IPI não temos como afirmar que ele é o responsável pela definição do tipo de cálculo do imposto, pois na minha visão a CST "50 - Saída tributada" pode ser utilizada tanto em produtos tributados por alíquota Ad Valorem como para produtos tributados à uma alíquota específica.

 

  Nestes últimos dias li novamente a documentação da TIPI disponível no site da Receita Federal (Link) e, pelo o que entendi, todos os produtos que possuem o gênero "22" ou o NCM "2105.00" e não possuem um código de exceção "EX" devem ser tributados por alíquota específica.

 

  Sabendo disto, se conseguirmos vincular o registro C170 ao registro 0200 do produto, podemos realizar esta validação dentro do método "WriteRegistroC170" para definir se o campo da alíquota deve ser preenchido ou não.

[Isaque Pinheiro]

Vou modificar o evento do componente ele mandar para ele um objeto que será o ResgistroC170 atual, dai vc alimenta a propriedade COD_ENQ, de forma que vc identifique se deve ser null e também  criar os parametros para cada valor

[EMBarbosa]

Lucas, veja esse tópico:

[Isaque Pinheiro]

Bom dia, Lucas como essa alteração foi também uma de suas sugestões, conto com seu apoio nos testes, desde já agradecemos a paciência e a colaboração nas idéias para resolvermos essa situação..

[Lucas Rutkoski]

Bom dia Isaque!

 

Desculpe a demora em atualizar este ticket, infelizmente estamos sempre correndo atrás do relógio...

Vou baixar os fontes que você postou no tópico indicado pelo Elton e acredito que até o final do mês consigo lhe dar um retorno sobre meus testes.

[Lucas Rutkoski]

Boa tarde pessoal!

 

Estou fora do tempo planejado mas com os testes realizados. Atualizamos os nossos fontes e o evento criado na geração do registro C170 atende perfeitamente nossas necessidades. Utilizando o campo "COD_ENQ" para indicar quando o produto é tributado por quantidade e, no evento, limpando o campo e ajustando o campo da alíquota.

 

Vou marcar a interação do Isaque como resposta e acredito que podemos concluir este assunto, pelo menos até a SEFAZ dar uma finalidade para o campo "COD_ENQ".

 

Peço desculpas pela demora entre as interações e agradeço o apoio da comunidade!