Painel de líderes

Olá pessoal! O envio do MDFe de forma assíncrona está com os dias contados, com a previsão de ser encerrado no dia 30/06/2024. O tópico abaixo tem mais detalhes a respeito. Mas fica então o questionamento, o que muda? Bem, antes de falar sobre isso, vamos responder a outra pergunta: Qual é a diferença entre o envio assíncrono e o envio síncrono? De maneira bem simples, a diferença entre essas formas de envio é a quantidade de conexões que é feita para com o web service da Sefaz. No envio assíncrono, primeiro sua aplicação envia o XML para o web service e recebe um número de recibo. Então, a aplicação faz uma nova requisição para o web service consultando o número de recibo para obter as rejeições ou em caso de sucesso o MDFe. Já no envio síncrono, em uma só requisição é enviado para o web service e na resposta já vem as rejeições ou o MDFe quando em caso de sucesso. Se você pensou: Isso se deve ao fato de que visando auxiliar os desenvolvedores que utilizam o componente, esse processo é automatizado, ou seja, a consulta já era feita automaticamente pela solução. Entendi a diferença entre os modos de envio, mas o que eu preciso mudar na minha aplicação? A primeira coisa que você deve se atentar é no comando que utiliza para fazer o envio do MDFe para o web service. Veja quais são os parâmetros do método Enviar no comando nativo. // Parâmetros do método Enviar: // ALote = Número do Lote // AImprimir = Se True imprime automaticamente o DAMDFE // ASincrono = Se True o envio é no modo Síncrono, caso contrario Assíncrono. ACBrMDFe.Enviar(Alote, AImprmir, ASincrono); Estes parâmetros são refletidos também nos comandos tanto da Lib: MDFE_Enviar(ALote, AImprimir, ASincrono, sResposta, esTamanho); Quanto do Monitor: MDFE.ENVIARMDFe(nXMLMDFe, [nLote], [nAssinar],[nImprimi],[nImpressora], [bAssincrono], [bEncerrado] ) Parâmetros: nXMLMDFe - Caminho do XML do MDF-e nLote - Número do Lote (opcional) nAssinar - Assinar o XML (opcional - informe 0 para não assinar) nImprimi - Imprimir MDF-e (opcional - informe 1 para imprimir) nImpressora - Nome da Impressora (opcional) bAssincrono - Por padrão o envio é Assíncrono, informa "False" para envio Sincrono bEncerrado - Imprimir Mensagem de "MDFe Encerrado", (opcional - informe 1 para imprimir) Então, a partir de 30/06/2024, será preciso informar corretamente o parâmetro que define o modo de envio, para que o mesmo seja feito de forma síncrona. No momento de ler o retorno, também serão necessárias mudanças. Caso utilize o componente nativo para Delphi/Lazarus, a classe que vai ler as informações não é mais a Retorno e sim a Enviar. //Ao invés de ler as informações de: ACBrMDFe.WebServices.Retorno.XXXX //Agora vai ler de: ACBrMDFe.WebServices.Enviar.XXXX Se você utiliza o Monitor ou a Lib, a principal diferença será no momento de ler as informações do MDFe. No envio assíncrono elas ficavam contidas na seção [MDFe + Número do MDFe], no entanto, na resposta do envio síncrono elas ficam em [MDFe+ Chave de Acesso do MDFe]. Mas eu não tenho a Chave de Acesso ainda, como vou conseguir ler? A chave de acesso de um documento fiscal deve ser montada seguindo uma regra estabelecida no MOC. Por isso, tanto a Lib quanto o Monitor possuem um método específico que se alimentado com as informações necessárias devolvem a chave de acesso montada. São eles: MDFe.GerarChave para o Monitor. MDFe_GerarChave para a Lib. Portanto, fazendo uso deste método é possível obter a informação que é precisa para realizar a leitura da seção.

Boa tarde @nildglan, Eu já tinha dito acima que se mesmo informando o ultimo NSU na próxima execução ainda retorna consumo indevido é indicio de que outra pessoa/empresa esteja fazendo essa consulta. Isso acontece bastante, pois as empresas fornecem uma cópia do certificado para o escritório de contabilidade e este começa a fazer essas consultas. Agora se você esta usando o seu certificado para consultar as notas emitidas contra o seu CNPJ e mesmo assim esta tendo esse tipo de rejeição, tem alguma coisa errada. Dentro da sua empresa só você esta fazendo esse teste ou mais alguém esta fazendo em outra maquina? A cada tentativa usando o seu certificado o ultNSU muda?

Veja que agora o ultNSU é 1719, se você não entendeu o processo vai continuar patinando. Seu ultNSU era 1718, você deveria utilizar o método passando ultNSU 1718 até receber pelo menos um novo NSU. Você recebeu um novo NSU, agora irá passar a consultar o 1719 e aguardar pelo menos 1h. Quando você receber 1 ou mais novos NSUs, irá identificar qual o ultNSU para a próxima pesquisa, enquanto não receber nenhum novo NSU, seguirá utilizando o 1719. Veja o tópico a seguir e o curso no nutror Implementando o serviço Distribuição DFe.

Olá pessoal, Foi publicado a NT 2024/002 que trata sobre o CT-e Simplificado. O que vem a ser o CT-e Simplificado: O CT-e Simplificado poderá ser utilizado nas prestações de serviços de transporte intermunicipal ou interestadual de mercadorias, que envolvam diversos remetentes ou destinatários, e um único tomador de serviço. O transportador poderá emitir um único CT-e referente a todas as prestações realizadas para este tomador, por veículo e por viagem. A forma de processamento do serviço de recepção é síncrona sem a formação de lotes. O contribuinte deve transmitir o CT-e simplificado através do Web Service de recepção exclusivo que atenderá esse leiaute e receberá o resultado do processamento na mesma conexão. O Layout do XML do CT-e Simplificado é bem diferente do CT-e (modelo 57) que estamos acostumados a ver. Sendo assim não da para expor nesse tópico os novos campos ou campos com novos valores, pois trata-se de uma estrutura de XML totalmente nova para o CT-e Simplificado.. Sobre os Prazos A previsão para implementação no ambiente de homologação é para o dia 02/09/2024 e produção para 07/10/2024. Mudanças no ACBr e/ou na Sua Aplicação A alteração no componente vai ser realizada em Julho e Agosto para que fique tudo pronto para a data prevista de implementação em ambiente de homologação. Dica de sempre, mantenham todos os fontes de todas as pastas atualizados, já se encontra no SVN a atualização dos Schemas que contempla o CT-e Simplificado

vamos esperar nosso amigo Italo para saber mais

Chegou a pegar os fontes e testar?

Combinado, ficamos no aguardo.

Mesmo havia enviado um e-mail para eles. Porque logo que vc me pediu o arquivo -soap, abri ele para verificar o conteúdo, e me deparei com Erro de "Duplicidade"... Com isso acessei o portal de homologação e fiz um filtro das NFse de um ano atrás e mostrou todas as NFSe do cliente ... Mas no meu ver, o ambiente de homologação deveria ser um ambiente zerado, sem NFSe alguma nele... O código 20146 é o registro do cliente na prefeitura. Bom, vou aguardar a resposta do suporte da IPM e lhe aviso.

Boa tarde! Fiz o teste com a unit e funcionou normalmente sim. Obrigado @Daniel Simoes

Bom dia. Efetuado os testes e tudo funcionando perfeitamente. Segue orientações para nível de documentação para os proximos usuários. [Formato 1 - Somente executando comandos] 1) Rodar comando NFe.SetCertificado(); 2) Rodar comando NFe.DistribuicaoDFePorNSU(). [Formato 2 - Alteração Arquivo INI] 1) Substituir o ACBrMonitor.ini conforme os dados do CNPJ que fará a consulta; 2) Rodar comando ACBr.lerini(); 3) Rodar comando NFe.DistribuicaoDFePorNSU(). Obs.: No meu caso deixei rodando somente executando o comandos. Pra mim nesse formato ficou menos código e o processamento mais rápido de executar. @Daniel InfoCotidiano obrigado pela ajuda.

Segue ajuste para voltar a linha pontilhada do corte no modelo carnê. Configurado RLBand3.AutoExpand para false. ACBrBoletoFCFortesFr.7z

Bom dia @Italo Giurizzato Junior, testamos em produção e funcionou tudo corretamente. Envio em anexo o schema atualizado disponibilizado pelo provedor. Pois mudaram a quantidade de caracteres para o campo OutrasInformacoes para 512. Muito obrigado, e pode encerrar o tópico. nfse.xsd

Bom dia, ACBrMonitor e ACBrLib já disponíveis também. At.

Bom dia! Se você está consultando os NSUs de acordo com a sequência que controla, mas ainda assim está recebendo um erro de consumo indevido com um novo número de NSU para a próxima consulta, então é um indicativo de que está havendo consulta paralela. Mais alguém esteja consultando.

Olá pessoal! No dia 04/04/2024 foi publicada a Resolução Sefaz Nº636, alterando novamente o artigo 9º da Resolução Nº578, dando ao mesmo a seguinte redação: Postergando novamente a entrada em vigor dessa obrigatoriedade para 01/05/2024. Um agradecimento ao membro de nossa comunidade @Bruno da Silva Pereira por compartilhar a informação em nosso fórum.

Bom dia Italo, o erro não apareceu mais. Muito obrigado

Está usando qual gerador? lembro que tem algo nos fast report que deve mudar o fr3 e algo no fortes também

Ambiente de homologação deles é instável e sim está com erro lá vai precisar esperar voltar ao normal para testar

Boa tarde @Italo Giurizzato Junior, pior que no e-mail anterior já tinha enviado em anexo os arquivos com soap já pensando que teriam a solicitar mais achou que nem olharam pela velocidade com que deram retorno, vou tentar novamente enviar um e-mail para eles com essa explicação e ver o que retoram.

@Clipeus, por favor teste com a Unit em anexo ACBrTEFPayGoWebComum.pas

Olá pessoal! Foi publicado pelo ITI novo FAQ sobre o fim do certificado A1: 01/2024 - Modernização da ICP-Brasil > Questionamentos mais frequentes

Atualizou os fontes? Se não me engano foi enviada uma correção pra esse problema.

Bom dia! Por ser usuário PRO, você tem acesso aos cursos disponibilizados pelo ACBr. Um deles é o Dominando o ACBrBoleto, um curso bem completo sobre a solução de boleto do ACBr, com explicações de conceito e demonstrações práticas. Este tópico também tem informações importantes: De forma simplificada, você envia o registro para a API, a mesma vai devolver no retorno a informação do EMV, você preenche a solução com esta informação e imprime o boleto que com o EMV preenchido gera o QrCode.

Estou trabalhando nele neste exato momento. assim q subir ja te aviso

Bom dia @phulano, Você poderia anexar o arquivo ENT.txt para que possamos analisar o problema?

Boa tarde, conseguimos resolver a consulta, como o provedor GINFES da prefeitura de Santos, quando você consulta a nota fiscal pelo Consultar NFse por RPS não está retornando a TAG de Cancelamento, mas quando consultamos pelo Consultar NFse por Numero a Tag de Cancelamento vem, conforme imagem abaixo (Amarelo). Importante continuamos usando o ACBRNFSe. Fica de aprendizado para quem precisar. Grato pela ajuda.

Rapaz, salvou eu em!

Pequeno exemplo da forma de envio... (extraído do Demo atual) ACBrMail1.From := 'seu_email'; ACBrMail1.FromName := 'seu_nome_opcional'; ACBrMail1.Host := 'smtp.gmail.com'; // troque pelo seu servidor smtp ACBrMail1.Username := 'seu_usuario'; ACBrMail1.Password := 'sua_senha'; ACBrMail1.Port := '465'; // troque pela porta do seu servidor smtp ACBrMail1.AddAddress('um_email','um_nome_opcional'); ACBrMail1.AddCC('um_email'); // opcional ACBrMail1.AddReplyTo('um_email'); // opcional ACBrMail1.AddBCC('um_email'); // opcional ACBrMail1.Subject := 'Teste de Envio'; // assunto ACBrMail1.IsHTML := True; // define que a mensagem é html // mensagem principal do e-mail. pode ser html ou texto puro ACBrMail1.Body.Text := '<html>'+#13+#10+ '<head>'+#13+#10+#13+#10+ ' <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">'+#13+#10+ '</head>'+#13+#10+ '<body text="#000000" bgcolor="#FFFFFF">'+#13+#10+ '<h1>Texto em HTML.</h1><br>'+#13+#10+ '</body>'+#13+#10+ '</html>'+#13+#10; ACBrMail1.AltBody.Text := 'Texto puro alternativo.'; ACBrMail1.AddAttachment('um_arquivo','um_nome_opcional'); ACBrMail1.Send; Lembrando que para o suporte a TLS ou SSL funcionar é necessária a presença das já conhecidas DLLs do OpenSSL: libeay32.dll e ssleay32.dll