Assessor Público - Problemas ao fazer o Envio.

[João Vitor Bogo]

Boa tarde pessoal.

 

Eu fiz um tópico faz alguns minutos, relacionado a Inscrição Municipal / Código Imobiliario no Assessor Público. Sobre a parte da leitura do XML retornado da prefeitura 

Nesse tópico eu abordei (corretamente acredito eu) sobre a leitura dos campos que estavam erradas. Porém agora o problema que eu acredito que existe é no envio da requisição para o Assessor.

Como podem ver nessa print, é preenchido a tag 'INSCRICAO' com o campo "InscMun", até então, não deveria haver problemas, porém o próprio Assessor Público, não espera a Inscrição Municipal nessa tag, e sim o Código Imobiliario.

Tanto que fazendo os testes e preenchendo essa tag com a Inscrição Municipal de fato, eu tenho o seguinte retorno da prefeitura: 

Isso pois eles tratam de uma maneira equivocada como as tags são preenchidas.

A minha sugestão (caso o ACBR concorde que o preenchimento não deve ser feito assim) é a seguinte:

Criar na unit ACBrNFSeXConfiguracoes o campo "Codigo Imobiliario" e alterar na unit AssessorPublico.Provider a montagem do campo Emitente.InscMun para Emitente.CodigoImobiliario.

Caso queiram, aqui está as units com as modificações:

AssessorPublico.Provider.pas 

ACBrNFSeXConfiguracoes.pas

 

[Alexandre de Paula]

Boa noite,

Criada a TK-7432 para avaliação.

Obrigado pela contribuição.

[Italo Giurizzato Junior]

Boa tarde @João Vitor Bogo,

O problema de criar mais um parâmetro de configuração no componente é que temos que alterar o ACBrMonitor (tela de configuração) e na Lib também.

Um campo de configuração a ser usado por apenas um provedor, sendo que podemos usar a configuração existente (Inscrição Municipal) para conter a Inscrição Mobiliaria.

Se em algum momento o provedor precisasse das duas informações ai sim deveríamos ter os dois e não apenas um.

Mudar agora, faz com que muitos desenvolvedores parem de emitir suas notas, pois quem usa esse provedor com certeza esta informando a Inscrição Mobiliaria na propriedade de configuração InscMun.

Desculpe mais não vejo com bons olhos essa mudança.

[João Vitor Bogo]

40 minutos atrás, Italo Giurizzato Junior disse:

Boa tarde @João Vitor Bogo,

O problema de criar mais um parâmetro de configuração no componente é que temos que alterar o ACBrMonitor (tela de configuração) e na Lib também.

Um campo de configuração a ser usado por apenas um provedor, sendo que podemos usar a configuração existente (Inscrição Municipal) para conter a Inscrição Mobiliaria.

Se em algum momento o provedor precisasse das duas informações ai sim deveríamos ter os dois e não apenas um.

Mudar agora, faz com que muitos desenvolvedores parem de emitir suas notas, pois quem usa esse provedor com certeza esta informando a Inscrição Mobiliaria na propriedade de configuração InscMun.

Desculpe mais não vejo com bons olhos essa mudança.

Boa tarde

Gostaria de reforçar que a inclusão de um parâmetro específico não é um “trabalho à toa”, mas sim um investimento em clareza, robustez e manutenção futura.

É bom notar alguns pontos para reflexão sobre isso:

1. Clareza na configuração

   • Ter campos separados para Inscrição Municipal e Código Mobiliário evita ambiguidades e “gambiarras” futuras.

   • Facilita a leitura do código, o entendimento de novos desenvolvedores e a detecção de erros.

2. Manutenção e escalabilidade

   • Hoje apenas um provedor exige o Código Imobiliário mas amanhã outro pode precisar dele também.

   • Planejar para o crescimento do componente reduz retrabalho e dores de cabeça posteriores onde a emissão de determinadas prefeituras podem 'parar' por falta disso.

   • A adição de um parâmetro dedicado segue o conceito de clean code, onde cada elemento tem responsabilidade única e clara.

3. Esforço de implementação reduzido

   • No ACBrMonitor, basta adicionar um novo campo de configuração (não é algo complexo)

   • Na Lib, é possível usar exatamente a lógica sugerida, sem alterar o fluxo atual de quem já está em produção: Basta utilizar um IF no preenchimento da Tag com o campo novo, quem já está rodando não vai ter nada preenchido nele, e nesse caso, continua utilizando o que já estava antes.

Adicionar um parâmetro novo traz benefícios claros sem quebrar compatibilidade com quem já está em produção. Dessa forma, garantimos um componente mais organizado, preparado para o futuro e com impacto mínimo para os atuais usuários.

Um último ponto à respeito disso, é que até o momento ninguém que está utilizando pareceu se importar nem com a impressão da NFS desse Provedor, pois como eu cito no meu outro post relacionado à leitura do XML, o 'mesmo campo' está sendo lido como Inscrição Municipal, quando na verdade não é assim. Então eu acredito que essa modificação não terá impacto algum para quem já está utilizando.

[Italo Giurizzato Junior]

Boa tarde @João Vitor Bogo,

Fiz uma pequena alteração na sua colaboração e enviei para o SVN.