Gabriel Fernando Lopes

Consegui resolver todos os problemas, o mais grave era esse: Error reading nfe.Configuracoes.Geral.SSLLib: Suporte a "xsMsXmlCapicom" disponível apenas em MSWINDOWS, e sem a diretiva de compilação {$DEFINE DFE_SEM_MSXML}. Resolvi mudando as diretivas de instalação do ACBr, desmarcando o que tirava o Capicom e o define. Depois o restante foi só alterando todos os pontos de mudanças no ACBr com relação ao código antigo. Já a mudança do NFSe para NFSeX será feito agora e não vi nenhum problema em realizar a mudança. Obrigado pela ajuda e apoio.

Voltei no instalador e vi que ficou desmarcado por estar descontinuado. Marquei ele e voltei a instalar e parou de dar esse problema na compilação nessa tela. No entanto eu vi que o DFM dessa tela ainda não abre, ele não esta corrompido, acho que é devido a componentes que não estão mais instalados do ACBr (que tinham na versão antiga). Agora a compilação para em outra tela, pois não acha uma outra unit: [dcc32 Fatal Error] udm_MDFe.pas(9): F2613 Unit 'pmdfeMDFe' not found. Eu vi que o pacote MDFe esta instalado, mas não vê essa unit, o que estou fazendo de errado?

Abri os arquivos e vi que nessa atualização que fiz do acbr tinha que mudar diversas UNITs. Achei no forum o que foi mudado nas trocas de unit, mas tem uma que o compilador diz não achar e eu não sei por que, é a ACBrNFSe: [dcc32 Fatal Error] udm_NFe.pas(9): F2613 Unit 'ACBrNFSe' not found. Não tem mais ela?

Eu fiz uma nova tentativa, executei o apagarACBR.bat no diretório do ACBR e fiz um novo update no tortoise. Reinstalei tudo e não deu erro agora, mas ao rodar a nossa aplicação principal voltou um erro que não acontecia anteriormente: Error reading nfe.Configuracoes.Geral.SSLLib: Suporte a "xsMsXmlCapicom" disponível apenas em MSWINDOWS, e sem a diretiva de compilação {$DEFINE DFE_SEM_MSXML}.

Por causa na recém mudança na URL de verificação do QR code. Tive de atualizar o ACBR, fiz o update do trunk2 pelo tortoise e executei o ACBrInstall_Trunk2.exe. Deixei o usual marcado e a instalação continuou, mas parou no ACBr_BoletoRL.dpk com o seguinte erro: Embarcadero Delphi for Win32 compiler version 30.0 Copyright (c) 1983,2015 Embarcadero Technologies, Inc. D:\install\Componentes\ACBr\Fontes\ACBrBoleto\FC\Fortes\ACBrBoletoFCFortesFr.pas(1427) Error: E2010 Incompatible types: 'TRLCustomPrintFilter' and 'TRLPDFFilter' ACBr_BoletoRL.dpk(39) Fatal: F2063 Could not compile used unit 'ACBrBoletoFCFortesFr.pas' Compilation failure Erro ao compilar o pacote "ACBr_BoletoRL.dpk". Abortando... Ocorreram erros na compilação dos pacotes. Tentei então reinstalar o Fortes, fui em https://github.com/fortesinformatica/fortesreport-ce e baixei o v4.1.0.3. Mas ao instalar, deu o erro anexo. Basicamente o arquivo mostra o que vai compilar, mas da erro e não mostra onde e terminando com: Compilation failure Onde estou errando? log_Delphi_10_Seattle.txt

Boa tarde Leandro, Eu já conhecia estes posts, sei que não devemos usar o DistribuiçãoDFe para buscar XML completo. O problema é que em nenhuma circunstância eu conseguia uma resposta que não fosse a "Rejeição: Consumo Indevido (Deve ser utilizado o ultNSU nas solicitações subsequentes. Tente após 1 hora)". E eu precisava saber se teria outra maneira para eu comprovar que o meu último NSU estava correto ou não. Depois de quebrar a cabeça novamente (sempre esperando 1 hora para cada teste), finalmente o servidor liberou a busca de um novo lote de NSU. Eu fiz os seguintes passos: 1 - Via depuração eu forcei o sistema a usar como ultNSU o zero; (ultNSU = '0';) 2 - Esperei o sistema executar "EnviarDados;" e testei as respostas; 3 - Esperei novamente 1 hora, e mandei buscar novamente usando o mesmo ultNSU que eu tinha e deu certo; Pelo que eu vi, realmente não existe outro caminho para saber qual o ultNSU, a não ser guardar ele ou iniciar novamente como zero. De qualquer forma, obrigado pelo retorno.

Desde fevereiro de 2022 não conseguimos baixar NSU pela função DistribuicaoDFePorUltNSU (utilizamos a função desde março de 2019 sem problemas). Sempre aparece a rejeição "Rejeição: Consumo Indevido (Deve ser utilizado o ultNSU nas solicitações subsequentes. Tente após 1 hora)". A principio achamos que era problema no sefaz e ficamos um tempo sem baixar NSU. No entanto, mesmo ficando uma semana sem tentar baixar, a mensagem de rejeição sempre é a mesma. Então suspeitamos que poderíamos ter perdido um bloco de NSU e portanto estaríamos usando o ultNSU errado. Tentamos essa semana enviar o ultNSU como 0 (zero) para receber o bloco mais antigo existente no ambiente nacional e também para sabermos qual o ultNSU e o maxNSU. No entanto a resposta foi a mesma, "Rejeição: Consumo Indevido (Deve ser utilizado o ultNSU nas solicitações subsequentes. Tente após 1 hora)". Existe alguma outra maneira de contornar esse problema?

Juliomar, pela documentação da DSF quando fazemos consulta por lote só temos de retorno um XML com estes dados (por RPS processado): InscricaoPrestador NumeroNFe CodigoVerificacao SerieRPS NumeroRPS DataEmissaoRPS RazaoSocialPrestador TipoRecolhimento ValorDeduzir ValorTotal Aliquota A minha dúvida é se o componente da ACBr guarda estes valores em propriedades ou eu realmente tenho que ler o XML através da função SeparaDados.

Boa tarde pessoal, Estou fazendo a consulta de RPS por lote, usando o seguinte comando notaNFSe.NFSe.ConsultarLoteRps(Lote, Protocolo), no entanto eu não tenho o XML da nota original para ler no componente assim como esta no exemplo da ACBr. A consulta acontece com sucesso e eu consigo retirar os dados que necessito no XML de retorno que eu leio em notaNFSe.NFSe.NotasFiscais.Items[0].XMLNFSe. Os dados são: InscricaoPrestador NumeroNFe CodigoVerificacao SerieRPS NumeroRPS DataEmissaoRPS RazaoSocialPrestador TipoRecolhimento ValorDeduzir ValorTotal Aliquota No momento estou usando a função SeparaDados para retirar as informações do XML. Gostaria de saber se estes dados estão somente nesse XML ou se tem alguma propriedade com estes nomes em algum lugar. Alguém pode me tirar essa dúvida? Obs.: Tentei usar notaNFSe.NFSe.NotasFiscais.Items[0].NFSe.Prestador.InscricaoMunicipal mas sempre esta vazio, se não me engano ele só carrega quando se faz o load do XML original.

Bom dia Italo, É verdade, realmente eu estava com o meu arquivo Cidades.ini desatualizado. Mas só a título de conhecimento, eu recebi novas informações no grupo de discussão de NFSe da DSF. Me parece que estava funcionando as duas URL, tanto com HTTP como HTTPS, mas após uma modificação na API o ambiente HTTP ficou com problemas e não conseguiram arrumar até o momento. Não sei se deixaram somente o HTTPS daqui para frente ou se vão restabelecer o ambiente HTTP novamente. Após o UPDATE do ACBrInstall_Trunk2 fiz os testes novamente tanto no exemplo como na aplicação do nosso ERP e esta tudo funcionando.

Segue anexo o arquivo. Alterei somente as linhas 1470 e 1471. Não sei se as demais cidades da DSF também sofreram alterações. Cidades.ini

Consegui fazer funcionar Juliomar, a DSF e a prefeitura de Uberlândia não tem um canal muito bom para comunicação de alterações. Através de um grupo de discussão descobri que os webservices mudaram na semana passada: Antes: http://udigital.uberlandia.mg.gov.br Agora: https://udigital.uberlandia.mg.gov.br Basta editar o arquivo cidades.ini e alterar. De qualquer maneira obrigado pela ajuda.

Tentei e não funcionou. Eu estou usando o libCapicomDelphiSoap por que é o SSLIB configurado para NFe e esta funcionando normalmente. O normal seria voltar qual valor para FpHTTPResultCode ? Tem mais algum teste que eu possa realizar aqui?

Quando o botão "Enviar Lote RPS (Enviar)" é acionado o sistema chama a modal para inserir a senha do certificado normalmente. Verificando o arquivo "1-env-lot.xml" (ver anexo) me parece assinado corretamente também. 1-env-lot.xml

Juliomar, o certificado esta configurado assim: