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.

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.

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

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.

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

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.

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

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