Eduardo Arantes

Boa noite, Senhores. Estamos enfrentando problemas para transmitir NFCe em Uberaba - MG. Gostaria de saber se poderia ter algo a ver com a recente mudança de URLs para consulta via QRCode. Mais alguma URL foi alterada, que poderia causar esses problemas? O ACBr foi todo reinstalado ontem novamente, mas mesmo assim o problema persiste. Obs: A consulta de StatusServico está retornando 107 - Servico em Operação na quase totalidade das vezes. Alguém mais está enfrentando instabilidade na NFCe em MG depois do dia 04/04/22 ? Obrigado.

Bom dia, Italo. A consulta também funcionou perfeitamente. A impressão apresentou o erro "Input is not proper UTF-8. Indicate encoding" quando vai fazer o loadfromfile da NFSe, mas como eu já tinha visto outras postagens sobre essa mensagem, que estava ocorrendo em outros servidores, e precisava de uma solução mais rápida, contornei a situação substituindo o loadfromfile do xml da nfse por uma ConsultaNfsePorRps antes d impressão. Dessa forma, o componente baixa um novo xml da nfse e já carrega para o componente, dispensando o loadfromfile. Já tem alguma solução para esse erro no Webiss? Vi que vocês estavam fazendo uma solução para cada servidor. Obrigado.

Boa noite, Italo. Fiz conforme você recomendou. Havia arquivos assinalados em vermelho, mas eram do Sped e do eSocial. Excluí tudo, conforme indicado, inclusive excluí todas as pastas, baixando tudo do zero. Em seguida reinstalei. Não havia arquivos espalhados. Agora sim, o protocolo apareceu após o Emitir, conforme mostrado abaixo: ACBrNFSeX1.WebService.Emite.Protocolo=65 'ACBrNFSeX1.WebService.Gerar.Protocolo= 'ACBrNFSeX1.WebService.ConsultaSituacao.Protocolo=65 'ACBrNFSeX1.WebService.ConsultaLoteRps.Protocolo=65 'ACBrNFSeX1.WebService.ConsultaNFSeporRps.Protocolo= 'ACBrNFSeX1.WebService.ConsultaNFSe.Protocolo= Consegui mover o protocolo e gravar no banco de dados. Agora, vou para a consulta. Assim que funcionar tudo, volto e coloco aqui, para finalizar o post. Muito obrigado pela ajuda, Italo. Bom trabalho a você e a toda a equipe.

Bom dia Italo, Conforme solicitado, fiz testes e salvei os xmls, inclusive já consegui até transmitir. Mas, como eu posso obter o número do protocolo após o Emitir? Já coloquei até mensagens mostrando o conteúdo e está tudo vazio, conforme mensagem anterior. Obrigado.

Apenas uma observação. Pesquisei no site do ProjetoACBr e vi que existem outros casos de falta de retorno após transmissão ou consulta, como o tópico "Retorno da procedure Emitir(NFSeX)", e outro tópico que não guardei o nome. Infelizmente, em ambos, a comunicação foi interrompida por parte dos solicitantes e não se chegou à apresentação de uma solução para o problema. Mas, parece que a questão dos conteúdos de retorno têm ocasionado bastante dor de cabeça, e talvez fosse interessante criar um tópico esclarecendo como fazer a obtenção correta das informações após o envio no ACBrNFSeX. Eu tenho vontade de ajudar, mas infelizmente, não tenho conhecimento suficiente sobre os componentes. Parabenizo a toda a equipe, que mesmo tendo seus compromissos, se esforça para trazer as soluções a todos os usuários.

Boa tarde, Italo. Consegui ter certeza de que está transmitindo. Pedi para um cliente fazer uma nota de teste em produção e consultar no site da prefeitura. Com isso, descobri que o campo CodigoTributacaoMunicipio estava sendo preenchido de forma errada. Uma vez que corrigi isto, a nota pôde ser transmitida e consultada no site da prefeitura como "Processada com Sucesso". Transmissão concluída, voltamos ao problema original. Depois da transmissão, preciso armazenar o número do protocolo, que não está retornando após o Emitir (Assincrono). Até coloquei mensagem para ver o conteúdo das propriedades Protocolo, e estavam todas vazias, como pode ver abaixo. Também anexo os xml soap (da nota que foi transmitida com sucesso) que você pediu. showmessage('ACBrNFSeX1.WebService.Emite.Protocolo=' + ACBrNFSeX1.WebService.Emite.Protocolo + chr(13) + 'ACBrNFSeX1.WebService.Gerar.Protocolo=' + ACBrNFSeX1.WebService.Gerar.Protocolo + chr(13) + 'ACBrNFSeX1.WebService.ConsultaSituacao.Protocolo=' + ACBrNFSeX1.WebService.ConsultaSituacao.Protocolo + chr(13) + 'ACBrNFSeX1.WebService.ConsultaLoteRps.Protocolo=' + ACBrNFSeX1.WebService.ConsultaLoteRps.Protocolo + chr(13) + 'ACBrNFSeX1.WebService.ConsultaNFSeporRps.Protocolo=' + ACBrNFSeX1.WebService.ConsultaNFSeporRps.Protocolo + chr(13) + 'ACBrNFSeX1.WebService.ConsultaNFSe.Protocolo=' + ACBrNFSeX1.WebService.ConsultaNFSe.Protocolo); Obrigado pela ajuda. 66403-env-lot-soap.xml 66403-rec-soap.xml

Boa noite, senhores. Após a migração para o componente ACBrNFSeX, quando faço a transmissão para o WebISS em Uberaba, executando o Emitir Assincrono (o Sincrono não está disponível para esse servidor), na execução do ChecarResposta(tmRecepcionar), obtenho o seguinte resultado: Método Executado: Enviar Lote Parâmetros de Envio Numero do Lote: 66375 Parâmetros de Retorno Data de Envio : 30/12/1899 Numero do Prot: Numero da Nota: Link : Código Verif. : Sucesso : True NFS-e Numero....: Cod. Verificacao: Prestador.......: EMISSOR DE TESTE LTDA Tomador.........: CLIENTE DE TESTE LTDA A princípio, eu achei que tinha conseguido transmitir, porque criou o xml do rps e o campo "Sucesso" está setado true no retorno, mas os outros campos do retorno não estão preenchidos (inclusive o Protocolo), e o default de Sucesso é true, então não deve ter ido mesmo. Obs.: O ConsultarLoteAposEnvio está setado true. Alguém tem uma dica sobre o porque não está trazendo o retorno após o envio? Agradeço deesde já.

Obrigado, Juliomar. Realmente estava faltando o LerCidades. Ele estava em outro ponto que eu não tinha copiado. Agora consegui gerar o RPs. Ainda está dando erro na consulta, mas agora já está encaminhado. Obrigado pela ajuda, a você e ao Italo. Vocês são feras. Parabéns.

Um complemento ao comentário acima: Verifiquei o conteúdo de edtCodCidade.Text antes de executar a linha ACBrNFSeX1.Configuracoes.Geral.CodigoMunicipio := StrToIntDef(edtCodCidade.Text, 0); e o valor está correto para Uberaba: 3170107 Existe algum procedimento para carregar os provedores, que eu possa ter esquecido de fazer, mesmo tendo copiado a lógica do programa exemplo? Obrigado.

Boa noite, Italo. Obrigado pelas dicas. Voltei a copiar a lógica do programa exemplo, para certificar que estaria tudo no padrão. Antes da transmissão, dentro do "ConfiguraComponente", quando vai setar o CodigoMunicipio: // A propriedade CodigoMunicipio tem que ser a ultima a receber o seu valor // Pois ela se utiliza das demais configurações ACBrNFSeX1.Configuracoes.Geral.CodigoMunicipio := StrToIntDef(edtCodCidade.Text, 0); Quando executa a linha acima, aparece a mensagem: 'pro' não é um valor TnfseProvedor válido. Verifiquei a unit ACBrNFSeXConversão, e o parâmetro da function StrToProvedor(const s: string): TnfseProvedor; parece estar chegando vazia. Como eu mantive o padrão do programa exemplo, estou sem saber o que está faltando. A linha que seta o CodigoMunicipio está no final da procedure, conforme foi orientado. Obrigado pela atenção desde já.

Boa tarde, Italo. Estou fazendo a migração para o componente ACBrNFSeX, como você me indicou, e estou com dúvida quanto a alguns campos/propriedades, que apresentaram "undeclared Identifier" na compilação e, mesmo analisando o programa exemplo, eu não consegui localizar para onde eles foram, ou qual o novo nome. São eles: 1 - ACBrNFSeX1.NotasFiscais.Items[qtdnf].NFSe.Protocolo Uso ele para obter o número do protocolo depois de enviar, e guardar no meu banco de dados. 2 - Como efetuar a consulta de status do serviço, assim como é feito no componente para NFE (abaixo). ACBrNFe1.WebServices.StatusServico.Executar; Desde já agradeço.

Obrigado, Italo. Por não entrar muito frequente nos fóruns, eu não estava sabendo do novo componente. Muito obrigado por me avisar. Vou seguir o link de migração que você me passou. Só uma pergunta: O componente já está operacional ou é necessário aguardar alguma alteração em andamento?

Boa noite, senhores. 1 - Estamos enfrentando um problema na transmissão de NFSe, que passou a acontecer depois de uma atualização de versão do ACBr. Usamos o WebISS na cidade de Uberaba. A mensagem que aparece é a seguinte: Método.....: Enviar Lote Código Erro: E1 Mensagem...: Assinatura do Hash não confere Correção...: Reenvie assinatura do Hash conforme algoritmo estabelecido no Manual de Instrução da NFS-e Provedor..: WebISS O interessante é que não parece ser um problema do provedor, uma vez que se rodamos um executável antigo, a nota é transmitida normalmente. A suspeita é de que algo aconteceu na atualização que provocou o erro. 2 - Gostaríamos de saber se existe uma lista de dicas para atualização do ACBr. Achamos que estamos fazendo algo errado ao atualizar os componentes, pois, além do erro acima, aconteceu problema em outra máquina, na qual, depois de uma atualização, um dos fontes de nosso sistema passou a apresentar problema ao compilar nessa máquina. Teria uma lista de boas práticas, ou um guia com dicas, para manter os componentes corretos em todas as máquinas da empresa? Aguardamos resposta e agradecemos desde já.

Bom dia, Senhores. No último dia das mães tivemos um problema que aconteceu em nossos clientes, que ocasionou a seguinte mensagem: O documento XML deve ter um elemento de nível superior. A mensagem aconteceu tantas vezes, devido ao grande movimento, que houve vários problemas de travamento. Verificamos na internet e, alguns dizem que esse erro é devido aos protocolos TLS mal configurados, outros dizem que ocorre devido a problemas no servidor. Chegamos a pensar que poderia ser devido a sobrecarga nos servidores da Receita. O fato é que, no mesmo dia, e acessando os mesmos servidores da Receita, clientes de outros sistemas, que não usam o ACBr, estavam conseguindo transmitir suas NFe e NFCe normalmente, sem receber essa mensagem. Posteriormente, com a redução do movimento, os erros pararam de acontecer, mas ficamos sem saber qual a natureza do problema, e isso nos impede de achar uma solução definitiva para evitar que aconteça novamente em outros dias de grande movimento. Alguém sabe o que causa esse problema e como ele pode ser resolvido? Obrigado.

Olá, Juliomar. Deu certo. Obrigado pelas instruções, e parabéns pelo trabalho de todos vocês.

Oi, Juliomar, Fiz a limpeza, rodando o ApagarACBr.bat, e apaguei a pasta lib também. Depois rodei o ACBrInstall_Trunk2.exe, e vi que a pasta lib foi reconstruída com todos os .bpl, .dcp e .dcu lá dentro, mas não funcionou. Os pacotes do ACBr que dependem do FastReport continuam desmarcados (imagem em anexo). Seria o caso de remover todos os pacotes do ACBr, limpar todo o library path e apagar toda a minha pasta C:\ACBRTRUNK2, criando uma nova pasta e baixando tudo novamente do zero?

Olá, Juliomar. Como você me recomendou, instalei uma versão mais atualizada do Fast Report (Enterprise) para ver se resolvo o problema do código de barras no boleto, que na versão antiga do Fast não tinha o componente frxBarCode. Fiz em uma máquina secundária, apenas para testar o procedimento todo. Creio que com a instalação do pacote novo do Fast, todos os pacotes do ACBR que dependiam do FastReport (Ex.: DCLACBr_BoletoFR.bpl) perderam suas ligações, e agora, no Component\Install Packages (Delphi 7) aparecem com os checkbox desmarcados. Tentei marcar, mas deu mensagem de erro. Lembro que antes de rodar o instalador do ACBr, já temos que ter instalado o FastReport, e dentro do instalador optar por FastReport ou FortesReport. Agora que já estou com a versão nova do FastReport, o que posso fazer para que os componentes FR do ACBr voltem a funcionar? Necessito apagar tudo e rodar o Instalador novamente? Obrigado.

Acho que vou ter que instalar mesmo a versão Enterprise, porque não localizei o componente frxBarCodeObject nas paletas de componentes. Só gostaria de saber se depois disso terei que fazer todo o procedimento do Instalador ACBr novamente ou não?

OK, Juliomar. Eu uso Delphi7 Enterprise (ainda). Você está falando do FastReport Enterprise? Depois que eu baixar ele, vou ter que desinstalar o FastReport que tenho, antes de instalar o novo. Depois disso, terei que fazer todo o procedimento do Instalador ACBr novamente ou não? Você teria o link para baixar o FastReport Enterprise?

Obrigado Juliomar Marchetti, funcionou direitinho. O boleto está imprimindo quase perfeito. Só que agora, no lugar do código de barra aparece a seguinte mensagem "Barcode must be numeric". Rodei no passo a passo, pois todos os campos parecia estarem preenchidos corretamente. ai apareceu a mensagem (só no passo a passo) :Clas TfrxBarCodeObject not found.

Bom dia, senhores. Estou começando a usar o ACBr boleto com fast report. No componente, selecionei o campo Tipo cobrança para escolher o banco desejado, preenchi os campos do cedente e outros dados. Quando disparo a impressão do boleto, aparece uma mensagem "caminho ou arquivo de impressão do boleto não assinalado". Procurei nas pastas do exemplo do ACBr e encontrei os arquivos.Fr3. Então, movi o caminho +nome do boleto.fr3 para ACBrboletoFCFR1.nomearquivo conforme abaixo: begin dirstr := Extractfilepath(Application.exename); ACBrBoletoFCFR1.NomeArquivo := DirStr + 'boleto.fr3'; Mas mesmo assim o erro persiste. Os componentes ACBrboleto1 e ACBrboletoFCFR1 estão conectados. Falta configurar mais alguma coisa? No exemplo do ACBr não fala nada sobre isso.

Bom dia, Senhores. Temos um cliente que é posto de gasolina, e deseja emitir uma NFC-e para consumo próprio, emitindo para o mesmo CNPJ, mas ele obtém a seguinte rejeição: Rejeição 220: Destinatário com identificação igual à identificação do emitente Como é possível contornar isso e qual seria o caminho mais indicado para ele efetuar essa operação? Obrigado.

Corrigido. Estávamos usando o DANFeNFCe4_20.fr3. Atualizamos para o DANFeNFCe5_00.fr3 e os campos apareceram no rodapé. Embora o layout do cupom tenha sofrido algumas alterações, decidimos manter o novo formato. Obrigado pela dica, BigWings.

Trabalhamos há muitos anos com Capicom, já usamos Trunk2 no Delphi 7, e ultimamente estão ocorrendo vários erros estranhos, Exemplos: 1- Quando vai transmitir um status da NFe, o programa trava, tendo que matar e chamar o programa novamente, e da segunda vez passa. O Windows avisa que o programa parou de funcionar. 2- Erro: "Inativo ou inoperante, tente novamente." Este erro começou a ocorrer no início de Junho/2017, e mesmo instalando a cadeia de certificados nova, em alguns clientes resolveu, em outros, continuou dando o problema. Seguimos os seguintes passos: Desligar o anti-virus, colocar a primeira cadeia de certificado, e depois colocar a segunda, que corrige todos os certificados, de todas as AC. Desligando as 3 opções finais do "Opções de Internet" e fazendo todas as opções possíveis com "SSL e TSL". Mesmo assim, em 2% das máquinas o erro continua acontecendo. Por isso, baseado em algumas pesquisas, vimos que poderia ser o Capicom do Windows que estava gerando este problema. Pensando no já comentado "Fim do Capicom", estamos procurando alternativas para a retirada do Capicom. Segue abaixo o que tentamos fazer, e o erro que ocorreu. Alteramos o parâmetro para ACBrNFe1.Configuracoes.Geral.SSLLib := libOpenSSL; (antes sempre utilizamos libCapicom). Mesmo sabendo que somente poderão ser usados certificados A1. PRIMEIRA TENTATIVA: Carregamos o número de série do certificado, movendo diretamente para a propriedade do componente: ACBrNFe1.Configuracoes.Certificados.NumeroSerie := Menu1.NumSerieCertEletProd; Apareceu o erro: "TDFeSSL não suporta carga de Certificado pelo número de série. Utilize "ArquivoPFX" ou "DadosPFX"." SEGUNDA TENTATIVA: Após isso, tentamos selecionar o certificado usando o seguinte método: (Menu1.NumSerieCertEletProd := ACBrNFe1.SSL.SelecionarCertificado;), mas aparece a mensagem "SelecionarCertificado não suportado em TDFeOpenSSL". O que devemos fazer para deixar de usar a libCapicom e passar a usar a libOpenSSL ? E como selecionar o certificado usando libOpenSSL ?

Olá, Isaque. Não existe registro F0010 e F0100. Eles ficaram assim por falta do delimitador. Na verdade são os registros F001 e F010. Veja abaixo: Geração sem delimitador: F0010 F01000757523000187 F01000757523000420 Geração corrigida: |F001|0| |F010|00757523000187| |F010|00757523000420| Concordo que não deve alterar, se não está dando erro para mais ninguém. Apenas informei porque aconteceu comigo e você pediu para anexar os fontes alterados. Fica registrado para o caso de acontecer com outra pessoa. Creio que não é erro no meu código, porque apenas alimento os campos do componente e depois disparo o comando abaixo, que também é do componente, e ele faz toda a geração do txt: ACBrSPEDPisCofins1.SaveFileTXT; Se vocês reproduziram o debug e nos pontos que eu marquei não perdeu o delimitador, então eu não tenho explicação, porque no meu debug eu vi o conteúdo do delimitador sumindo e a minha versão do componente é a original baixada, não tinha alterações até agora. De qualquer forma, obrigado pela atenção e disponibilidade. E parabéns pelo ACBr. Sem ele teríamos problemas infinitamente maiores.