Gabriel Bonzanini

Para a cidade de Bento Gonçalves/RS, ao consulta o lote através do método ConsultarLoteRps eu estava recebendo o erro 'List Index Out Of Bounds (0)', disparado na linha 1314 da unit ACBrNFSeWebServices.pas : Resolvi adicionando duas linhas de código, da seguinte forma: Se for útil para alguém, a unit está em anexo. Fico à disposição caso algum administrador queira simular o erro e precise de alguma informação. ACBrNFSeWebServices.pas

Muito obrigado @BigWings, não tinha notado a existência deste diretório. Problema resolvido! Grande abraço!

Olá @BigWings, muito obrigado pelo retorno. Puxa vida, pode ser isso mesmo... Não tenho nem o consCad_v2.00.xsd e nem o consCad_v4.00.xsd... Sabe onde posso obter as versões oficiais deles? Edit: os schemas que estou utilizando foram baixados de http://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=/fwLvLUSmU8= (primeiro pacote)

Boa tarde pessoal. Nos últimos dias, notei que a consulta ao cadastro de contribuintes estava falhando ao retornar os dados, mesmo nos casos em que tinha certeza absoluta de que o CNPJ em questão possuía inscrição estadual na UF informada. O xml de retorno era o seguinte: <retConsCad xmlns="http://www.portalfiscal.inf.br/nfe" versao="2.00"> <infCons> <verAplic>RSb20180817100600</verAplic> <cStat>239</cStat> <xMotivo> Rejeicao: Cabecalho - Versao do arquivo XML nao suportada </xMotivo> <UF>RS</UF> <dhCons>2019-12-12T14:53:31</dhCons> <cUF>43</cUF> </infCons> </retConsCad> Ao analisar o retorno, constatei que a versão do cabeçalho retornado é '2.00', e eu estava enviando '4.00' (versão atual da NF-e, configurada em ACBrNFe.Configuracoes.Geral.VersaoDF) : <ConsCad xmlns="http://www.portalfiscal.inf.br/nfe" versao="4.00"> <infCons> <xServ>CONS-CAD</xServ> <UF>RS</UF> <CNPJ>00428307000511</CNPJ> </infCons> </ConsCad> Em um debug, cheguei à um trecho do código do ACBr em que a versão do arquivo é definida: procedure TNFeConsultaCadastro.DefinirDadosMsg; var ConCadNFe: TConsCad; begin ConCadNFe := TConsCad.Create; try ConCadNFe.UF := FUF; ConCadNFe.IE := FIE; ConCadNFe.CNPJ := FCNPJ; ConCadNFe.CPF := FCPF; if UpperCase(FUF) = 'MT' then ConCadNFe.Versao := '2.00' else ConCadNFe.Versao := FPVersaoServico; ... ... Ao notar esta exceção para o estado do Mato Grosso, resolvi testar o mesmo para as outras UF's, e obtive êxito na consulta de outras 7, que são: AC BA PB PR RN RS SC Adicionei estas UF's ao teste que define a versão 2.00 de forma fixa, pois a property VersaoServico é ReadOnly. Se entenderem que a alteração é válida, a unit está em anexo. Porém, se houver uma outra forma de fazer este ajuste, gostaria de uma orientação. Obs: Não sei se a versão 2.00 é a vigente para todos os estados, por isso limitei o código às UF's nas quais consegui efetuar a consulta utilizando dados de clientes. Grato pela atenção. ACBrNFeWebServices.pas

Eu que agradeço @Italo Jurisato Junior ! É sempre um orgulho poder contribuir, mesmo que seja algo ínfimo.

Bom dia pessoal! Gostaria de sugerir uma melhoria na propriedade 'Items' da classe 'TConhecimentos' (unit ACBrCTeConhecimentos), definindo a mesma como default. Assim, podemos chamar automaticamente ACBrCTe.Conhecimentos[x] ao invés de ACBrCTe.Conhecimentos.Items[x]. A funcionalidade já existe na classe TNotasFiscais (unit ACBrNFeNotasFiscais). Em anexo, a última versão da unit com a alteração já efetuada, caso entendam que a mesma é viável. Grato pela atenção. Forte abraço, Gabriel. ACBrCTeConhecimentos.pas

Muito obrigado pelo retorno! Vou estudar e implementar o método alternativo mencionado neste outro tópico. Abraço e sucesso a todos.

Olá pessoal. Perdão pelos posts em sequência, mas é que já faz algum tempo e gostaria de encerrar este assunto... Alguém que tenha participado do refactoring poderia dar um retorno a respeito da alteração em si? Grato pela atenção.

Estamos criando uma lista fixa dos campos que podem ser alterados. Apenas para encerrar o tópico, e por curiosidade: algum dos programadores poderia comentar acerca das vantagens que motivaram a alteração da seção das propriedades (de published para public), removendo assim o RTTI das mesmas? Grato pela atenção.

Olá @everson.turossi! Obrigado pelo retorno. Tem razão, geralmente a correção gira em torno de algumas poucas tags. Porém, sempre tem aquele cliente que deseja alterar/corrigir uma informação relacionada à valores, documentos vinculados, etc., e restringir a utilização destas informações significa uma ligação de suporte a menos... Sem contar que fica mais transparente ao usuário, que seguidamente apresenta aquela dúvida "Posso corrigir isto?" (se estiver na lista, pode). Em últimos casos, vou ter que fazer o caminho inverso, listando tudo o que pode ser corrigido "hard coded", com a desvantagem de ter que lembrar de ajustar quando tags forem inclusas/modificadas no layout.

Aceito métodos alternativos... Como os colegas fazem para listar as tags para as quais a correção é permitida?

Bom dia pessoal. Primeiramente, gostaria de elogiar o refactoring efetuado há alguns meses atrás, deixando o código-fonte dos documentos eletrônicos mais limpo, organizado e estruturado. Apesar de todas as melhorias, acabei tendo uma pequena perda a partir dele: em nossa tela de emissão de Carta de Correção Eletrônica p/ CT-e, eu havia implementado uma forma dinâmica de obter todas as propriedades que podem ser corrigidas em um CT-e através da seguinte fução RTTI: var PropList: PPropList; begin GetPropList(pcteCTe.TCTe.ClassInfo, PropList); ... Essa função retornava todas as propriedades da classe e de todas as classes internas, restando apenas o trabalho de remover da lista as tags para as quais não é permitida a alteração (conforme pág. 225 do manual de integração 3.00): O que ocorre é que a maioria das propriedades dos componentes, inclusive desta classe, foram passadas de published para public, tornando-as invisíveis externamente via RTTI. O que vocês acham que eu poderia fazer neste caso? Gostaria de saber também se há muitas vantagens em tornar as propriedades public, motivando assim esta mudança no refactoring. Desde já agradeço a atenção. Abraço, Gabriel Bonzanini.

Parece que o webservice não está suportando a demanda... Os erros estão muito frequentes, o que está me fazendo cogitar uma solução alternativa, mesmo que o xml baixado não tenha validade jurídica. O que importa é que os clientes consigam lançar as notas de entrada e compor seu estoque. Estou analisando o método empregado por esta ferramenta (caso não descubra, implementarei a integração com a API deles): https://lite.arquivei.com.br/

Ah, detalhe importante: neste exato momento, a página antiga de consulta da Sefaz (https://www.nfe.fazenda.gov.br/portal/consultaResumoCompletaAntiga.aspx?tipoConsulta=completa&tipoConteudo=XbSeqxE8pl8=) que é utilizada como base para algumas ferramentas para "recortar" o html e transformá-lo em um xml, está fora do ar: Sites como Danfe Online (https://www.danfeonline.com.br/), Web Danfe (https://www.webdanfe.com.br/) e FSist (https://www.fsist.com.br/) deixam de funcionar nesta situação: Já o Arquivei (https://lite.arquivei.com.br/) permanece funcionando normalmente. Não imagino que possa existir outro meio de obter uma nota fiscal a não ser consultando o local para o qual a mesma foi enviada, ou seja, o SEFAZ. Também não acredito que alguns contribuintes possam ter acesso à algum serviço de forma exclusiva em detrimento de outros. Porém, nem faço ideia do método alternativo utilizado nesta última ferramenta.

Boa noite pessoal. Estou desenvolvendo um tratamento para os casos em que o serviço de distribuição de DF-e está fora do ar. Uma forma alternativa, para casos de exceção (que estão sendo bem recorrentes). Em minhas pesquisas, me deparei com este site, que pede apenas a chave de acesso e, a partir dela, efetua o download do arquivo: https://lite.arquivei.com.br/ A questão é: alguém tem ideia do método que possa estar sendo empregado por esta ferramenta? Ela não solicita certificado digital nem captcha, apenas a chave de acesso. E, segundo eles, o arquivo possui validade jurídica.

Obrigado pessoal, e desculpem o post duplicado... Na minha pesquisa, acabei não encontrando este tópico.

Bom dia @Juliana Tamizou Desculpe, mas não vejo relação alguma entre os temas...

Olá! Estamos recebendo este erro ao tentar aprovar notas fiscais de venda a consumidor no ambiente de homologação do RS: Pelo que notei, algumas alterações nesse sentido já foram efetuadas no componente, porém para outros estados. Fiz uma pesquisa a fim de encontrar a URL exigida pelo Sefaz para a Tag urlChave, porém não obtive êxito. Hoje, o arquivo ACBrNFeServicos.ini possui a URL http://www.sefaz.rs.gov.br/nfce/consulta configurada tanto para homologação quanto para produção. Grato pela atenção.

Olá Andrey. Vou anexar aqui as duas units atualizadas, pois a comunidade fez algumas alterações neste meio-tempo. ACBrTEFD.pas ACBrTEFDClass.pas

Eu que agradeço @hleorj... Se eu puder fazer algo pra ajudar, me avise. Bom trabalho.

@hleorj me avise caso precisem de mais alguma coisa para liberar a alteração.

Aqui no RS também não está funcionando... Anteriormente eu havia configurado o componente explicitamente para a versão 3.10 e estava funcionando, mas acredito que essa versão do webservice tenha sido desativada em definitivo.

Versão atual, sem o ajuste: Versão ajustada: Vou listar novamente as melhorias implementadas: Teste para que não seja reimpressa a quantidade do lote caso a mesma seja igual à quantidade total do item, o que subentende que há apenas um lote referenciado; Teste para que não seja impressa uma linha com o "código de agregação" caso o mesmo esteja em branco (seu conteúdo não é obrigatório de acordo com o layout da NF-e); Melhorias nas quebras de linha, pois em alguns casos está ficando uma linha em branco após o código da Anvisa, ou então um traço desnecessário. Segue a unit novamente, com mais uma pequena melhoria, e também os pdf's contendo as notas fiscais completas. ACBrNFeDANFEFRDM.pas Versão atual sem ajuste.pdf Versão Ajustada.pdf

@RickMao grato pela atenção. Entendi a lógica. Mas, sendo assim, quando cEANTrib estiver em branco, vai passar desnecessariamente pela validação, pois obviamente um texto em branco não é um código de barras válido, concorda? Vou efetuar mais alguns testes, tanto no ambiente de produção quanto no de homologação, e depois posto mais alguns detalhes aqui. Notei que as validações quanto a esse campo são diferentes (provavelmente pelo fato do ambiente de homologação já conter as alterações que entrarão em vigor no fim do ano). Obrigado novamente pela atenção.

Olá. Reparei que o teste que dispara a validação do campo cEANTrib através da função ValidarGTIN está assim: Ao meu ver, deveria estar assim: Em anexo o arquivo com a alteração, caso entendam que esteja correta. Grato pela atenção. pcnNFeW.pas