Gabriel Bonzanini

Tens razão... Dá a entender que a tag poderá ser enviada somente a partir de 08/09, diferente do CT-e, onde a mesma já está no webservice de homologação: São tantas notas técnicas que acabamos ficando um tanto confusos kkkk Vou marcar sua resposta como solução. Grato pela ajuda!

Agradeço por avisar, Luciano. Apenas a título de curiosidade e complemento ao post: adicionamos a mesma tag na emissão de CT-e, e correu tudo bem.

Bom dia pessoal. Estamos migrando do componente antigo (ACBrNFSe) para o novo (ACBrNFSeX), e ocorre o seguinte erro no envio: X800 - Erro de Validação: The node is neither valid nor invalid because no DTD/Schema declaration was found. Debuguei para ter certeza de que o diretório dos schemas esteja correto, considerando a concatenação que o componente faz de acordo com o provedor e versão do layout (Configuracoes.Geral.MontarPathSchema := True). No caso, ficou assim: [Diretório raíz do sistema]\Schemas\NFSeX\Infisc\1.01\ NFS-e Caxias do Sul Outra coisa que gostaria de saber é se há alguma forma de validar a NFS-e com os schemas antes do método ACBrNFSeX.Emitir. Grato pela atenção.

Fiz a instalação, e na primeira simulação que tentei executar, recebi um aviso de que ainda não estava implementado o cálculo para a determinada CST/Class Fiscal. Desanimador.

Olá pessoal! Gostaria de saber se mais alguém está enfrentando este problema, tanto no envio de NF-e quanto de NFC-e, em homologação: Rejeicao: Falha no Schema XML da NFe (Elemento: enviNFe/NFe[1]/infNFe/det[1]/imposto/IBSCBS/gIBSCBS/vIBS/) Até sexta-feira (01/08/2025), estava aprovando normalmente, quando a tag passou a ser exigida (Nota Técnica 2025.002.v.1.20). Os componentes estão atualizados, bem como os schemas (na validação local, corre tudo bem - o erro é retornado pela SEFAZ). Imagino que seja algo pendente de ajuste lá na SEFAZ mesmo, mas resolvi perguntar aos colegas por descargo de consciência. Grato pela atenção.

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.