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.