Pesquisar na Comunidade

Olá comunidade ! Foi publicada a versão 2.7 do Manual de orientação ao desenvolvedor do Reinf. Esta versão remove as menções ao modo de envio síncrono.

Srs. boa tarde! Gostaria da ajuda de vocês para resolver um problema com NFe. A situação é a seguinte: Até 31/08/2025 funciona tudo ok! O Sistema enviava a nota da seguinte forma: ACBrNFeSaida.Enviar(StrToInt(vNumLote)); Devido a obrigatoriedade da forma de envio sincrona para 1 unica nota a partir de 01/09/2025, configurei para enviar da seguinte forma: ACBrNFeSaida.Enviar(StrToInt(vNumLote), false, True); Ai começou a msg de erro, conforme imagem em anexo. A nota vai para receita normalmente, mas alguma coisa mudou quando o componente recepciona o xml homologado, pois erro erro ocorre até quando faço uma consulta pela chave da nfe. ACBrNFeSaida.WebServices.Consulta.NFeChave := ChaveCte; ACBrNFeSaida.WebServices.Consulta.Executar; Quando eu consulto pelo XML homologado que baixei da receita, o erro não ocorre. ACBrNFeSaida.NotasFiscais.LoadFromFile(sCaminhoXml); ACBrNFeSaida.Consultar; Desde ja agradeço

Envio Para enviar uma NFe de forma síncrona usando o componente ACBrNFe nativo para Delphi e Lazarus faça conforme exemplo: //Para imprimir o DANFe automaticamente se autorizado... ACBrNFe.Enviar(NumLote, True, True); //Para NÃO imprimir o DANFe automaticamente se autorizado... ACBrNFe.Enviar(NumLote, False, True); Se você utiliza ACBrMonitor, use os comandos NFe.CriarEnviarNFe ou NFe.EnviarNFe: //Para imprimir o DANFe automaticamente depois de autorizado... NFe.CriarEnviarNFe(cIniNFe,nLote,1,1) //Para NÃO imprimir o DANFe automaticamente depois de autorizado... NFe.CriarEnviarNFe(cIniNFe,nLote,0,1) //Para imprimir o DANFe automaticamente depois de autorizado... NFe.EnviarNFe(cArqXML,nLote,,1,,1) //Para NÃO imprimir o DANFe automaticamente depois de autorizado... NFe.EnviarNFe(cArqXML,nLote,,0,,1) Se você utiliza ACBrLib, use o método NFe_Enviar: //Para imprimir o DANFe automaticamente depois de autorizado... NFE_Enviar(nLote, True, True, True); //Para NÃO imprimir o DANFe automaticamente depois de autorizado... NFE_Enviar(nLote, False, True, True); Retorno Para ler as informações de retorno de uma NFe emitida de forma síncrona usando o componente ACBrNFe nativo para Delphi e Lazarus leia as seguintes propriedades: //Informações de retorno relacionadas ao web service... ACBrNFe.WebServices.Enviar.tpAmb; ACBrNFe.WebServices.Enviar.verAplic; ACBrNFe.WebServices.Enviar.cStat; ACBrNFe.WebServices.Enviar.cUF; ACBrNFe.WebServices.Enviar.xMotivo; ACBrNFe.WebServices.Enviar.Protocolo; //Informações de retorno específicas a NFe... ACBrNFe.NotasFiscais[0].NFe.procNFe.tpAmb ACBrNFe.NotasFiscais[0].NFe.procNFe.verAplic ACBrNFe.NotasFiscais[0].NFe.procNFe.chNFe ACBrNFe.NotasFiscais[0].NFe.procNFe.dhRecbto ACBrNFe.NotasFiscais[0].NFe.procNFe.nProt ACBrNFe.NotasFiscais[0].NFe.procNFe.cStat ACBrNFe.NotasFiscais[0].NFe.procNFe.xMotivo Se você utiliza ACBrMonitorPlus ou ACBrLib: [Envio] CStat=100 CUF=13 DhRecbto=08...8 Msg=Autorizado o uso da NF-e NProt=1...0 NRec= TMed=0 VerAplic=AM4.00-NAC Versao=4.00 XMotivo=Autorizado o uso da NF-e tpAmb=2 [NFe1] Id=ID11...0 NomeArq=C:\ACBrMonitorPLUS\Arqs\DFes\... XML=<protNFe versao="4.00"><infProt>... cStat=100 chDFe=13...05 dhRecbto=08/07/2025 14:13:48 digVal=Q...= nProt=1...0 tpAmb=2 verAplic=AM4.00-NAC xMotivo=Autorizado o uso da NF-e Expandindo o conhecimento Veja o tópico Como funciona os modos de envio Assíncrono e Síncrono para uma explicação mais detalhada sobre os modos de envio síncrono e assíncrono, as principais diferenças entre eles e quais documentos fiscais usam cada modo.

Olá pessoal! Esta rejeição foi introduzida pela Nota Técnica 2025/001 e sua regra de validação é como segue: Como descrito na regra e na rejeição, está mensagem é devolvida quando é feito o envio de forma assíncrona de um lote de NF-e contendo apenas uma nota em seu conteúdo. Portanto, para evitar esta rejeição, sua aplicação precisa fazer o envio de forma síncrona caso haja apenas uma NF-e no lote ou fazer o envio de forma assíncrona com um lote contendo no mínimo duas notas. Veja mais sobre os envios síncrono e assíncrono no tópico abaixo:

Olá pessoal! Conferindo na página Sobre a NF-e consta um aviso informando que foi disponibilizado no ambiente de testes um autorizador síncrono para NF-e. Aviso reproduzido na íntegra: Síncrono... Assíncrono... que raios é isso?! Na transmissão de documentos fiscais, o envio para o web service pode ocorrer de duas maneiras. No envio assíncrono, o XML é enviado para o web service, que devolve um número de recibo. Em seguida, o emissor faz uma nova conexão com o mesmo web service para consultar o número de recibo e receber o resultado do processamento. No envio síncrono, o XML é enviado para o web service, que já devolve o resultado do processamento na mesma resposta, ou seja, tudo é feito em uma única conexão. E por que isso é importante? Apesar de existir as duas formas de envio, recentemente alguns documentos fiscais tem adotado exclusivamente o modo de envio síncrono e desativando o modo assíncrono. Isso aconteceu com a NFC-e: Com a versão 4.00 do CT-e: Com o MDF-e: E logo com a NF3e também: Para a NF-e especificamente, ainda existe ambos os métodos, com exceção de SP e BA que não aceitam o modo síncrono. Esse aviso indica que a Sefaz de SP está caminhando para que isso não seja mais o caso e ela passe a aceitar o envio síncrono também. O que pode ser um passo para que a NF-e também mude somente para o modo síncrono futuramente. Está edição do Papo PRO traz considerações sobre as formas de envio: Um agradecimento ao membro de nossa comunidade @Felipe Marianopor compartilhar a informação no canal #sefaz em nosso Discord.

Olá Pessoal, Muitos DF-e (Documentos Fiscais Eletrônicos) foram implementados para o seu envio ser em Lotes contendo de 1 até 50 documentos. Esse modo de envio em lote funciona no modo assíncrono. Outros DF-e já foram implementados com o modo de envio unitário, ou seja, só podemos enviar um documento por vez, consequentemente esse modo de envio funciona no modo síncrono. A primeira diferença que podemos notar é: No envio assíncrono podemos enviar um lote contendo de 1 até 50 documentos, já no envio síncrono podemos enviar somente um documento por vez. A segunda diferença diz respeito ao retorno: No envio assíncrono temos como retorno do webservice um numero chamado de Recibo que atesta que o webservice recebeu o lote enviado, por outro lado no envio síncrono não temos o numero do Recibo como retorno. A terceira diferença se refere ao resultado do processamento: No envio assíncrono devemos realizar uma consulta se utilizando do numero do Recibo. É o retorno dessa consulta que nos vai dizer se o(s) documento(s) enviado(s) para o webservice foi ou foram processado(s) com sucesso. Já no envio síncrono não temos no retorno o numero do Recibo, logo não temos como realizar a consulta pelo numero do Recibo, alias não se faz necessário uma vez que no retorno do envio síncrono o que temos de retorno já é o resultado do processamento, portanto já temos na resposta se o documento foi processado com sucesso ou não. DF-e que já nasceram com o modo de envio Síncrono: BP-e = Bilhete de Passagem Eletrônico BP-e TM = Bilhete de Passagem Eletrônico Transporte Metropolitano GTV-e = Guia de Transporte de Valores Eletrônico DC-e = Declaração de Conteúdo Eletrônica NFCom = Nota Fiscal de Comunicação Eletrônica DF-e que nasceram com o modo de envio Assíncrono e que mudaram ou vão mudar para Síncrono: CT-e = Conhecimento de Transporte Eletrônico (desde 06/2023 só funciona o modo Síncrono) CT-e OS = Conhecimento de Transporte Eletrônico Outros Serviços (desde 06/2023 só funciona o modo Síncrono) MDF-e = Manifesto de Documentos Fiscais Eletrônicos (Modo Assíncrono será desativado em 30/06/2024) NFC-e = Nota Fiscal ao Consumidor Eletrônica (desde 04/09/2023 só funciona o modo Síncrono) DF-e que possui os dois modos de envio Assíncrono e Síncrono: NF3-e = Nota Fiscal de Energia Elétrica Eletrônica Observação: Notem que nas listas acima não aparece a NF-e = Nota Fiscal Eletrônica, o motivo é que a NF-e nasceu somente com o modo Assíncrono de envio, depois passou a ter o modo de envio Síncrono, mas este modo não se encontra disponível na SEFAZ de São Paulo e Bahia. O Fisco já sinalizou que pretende acabar com o modo de envio Assíncrono da NF-e, deixando somente o modo Síncrono. A motivação para essa mudança é que por volta de 90% dos lotes recepcionados por todas as SEFAZ de todas as UF possuem somente um documento. Sendo assim não faz muito sentido consumir dois serviços (Recepção e Consulta) para apenas um documento, lembrando que no modo Assíncrono se faz necessário a Consulta pelo numero do Recibo para obter o resultado do processamento. Já que 90% dos contribuintes enviam as suas notas de forma unitária, ou seja, uma nota por vez, tanto a SEFAZ quanto o desenvolvedor do Software sairiam ganhando com essa mudança, pois a SEFAZ eliminaria o serviço de Consulta pelo numero do Recibo e o Software ficaria mais rápido pois não precisaria executar essa consulta. Quando vai ocorrer essa mudança não sei, o Fisco não disse quando, mas vai ocorrer. Codificação para quem utiliza os componentes: A titulo de exemplo será utilizado o componente ACBrMDFe, mas podemos replicar para os demais. O método Enviar possui 3 parâmetros: function Enviar(const ALote: String; Imprimir: Boolean = True; ASincrono: Boolean = False): Boolean; overload; ALote = Numero do Lote que contem os documentos a serem enviados para o webservice da SEFAZ. Imprimir = Se True (valor padrão) diz que o Documento Auxiliar vai ser impresso no final do processo, se False diz que não vai ser impresso. ASincrono = Se False (valor padrão) diz que o modo de envio é Assíncrono, se True diz que o modo de envio é Síncrono. Exemplo de Envio no modo Assíncrono (só deve ser utilizado pelos DF-e que ainda possuem esse modo de envio): ACBrMDFe1.Enviar(NumLote); ou ACBrMDFe1.Enviar(NumLote, False); Exemplo de leitura do retorno do envio no modo Assíncrono: with MemoDados do begin Lines.Add(''); Lines.Add('Envio MDFe'); Lines.Add('tpAmb: ' + TpAmbToStr(ACBrMDFe1.WebServices.Retorno.tpAmb)); Lines.Add('verAplic: ' + ACBrMDFe1.WebServices.Retorno.verAplic); Lines.Add('cStat: ' + IntToStr(ACBrMDFe1.WebServices.Retorno.cStat)); Lines.Add('xMotivo: ' + ACBrMDFe1.WebServices.Retorno.xMotivo); Lines.Add('cUF: ' + IntToStr(ACBrMDFe1.WebServices.Retorno.cUF)); Lines.Add('xMsg: ' + ACBrMDFe1.WebServices.Retorno.Msg); Lines.Add('Recibo: ' + ACBrMDFe1.WebServices.Retorno.Recibo); Lines.Add('Protocolo: ' + ACBrMDFe1.WebServices.Retorno.Protocolo); end; Exemplo de Envio no modo Síncrono (utilizado pelos DF-e que só possuem ou também tem este modo de envio): ACBrMDFe1.Enviar(NumLote, True, True); ou ACBrMDFe1.Enviar(NumLote, False, True); Exemplo de leitura do retorno do envio no modo Síncrono: with MemoDados do begin Lines.Add(''); Lines.Add('Envio MDFe'); Lines.Add('Chave: ' + ACBrMDFe1.Manifestos[0].MDFe.procMDFe.chMDFe); Lines.Add(''); Lines.Add('tpAmb: ' + TpAmbToStr(ACBrMDFe1.WebServices.Enviar.tpAmb)); Lines.Add('verAplic: ' + ACBrMDFe1.WebServices.Enviar.verAplic); Lines.Add('cStat: ' + IntToStr(ACBrMDFe1.WebServices.Enviar.cStat)); Lines.Add('xMotivo: ' + ACBrMDFe1.WebServices.Enviar.xMotivo); Lines.Add('cUF: ' + IntToStr(ACBrMDFe1.WebServices.Enviar.cUF)); Lines.Add('xMsg: ' + ACBrMDFe1.WebServices.Enviar.Msg); Lines.Add('Recibo: ' + ACBrMDFe1.WebServices.Enviar.Recibo); end; E para quem usa ACBrLib ou ACBrMonitorPLUS? Os diferentes modos de envio também são considerados e estão disponíveis em ambas as soluções. No que diz respeito ao envio, os comandos também possuem um parâmetro que define se o envio será síncrono ou assíncrono. Vamos ver o exemplo do MDFe: Para a ACBrLib: MDFE_Enviar(ALote, AImprimir, ASincrono, sResposta, esTamanho); ALote: Número do Lote a ser enviado. AImprimir: Se True, imprime DAMFDe caso o MDFe seja autorizado. ASincrono: Se True envia o MDFe em modo sincrono. sResposta: Usado pelo retorno, contem as informações retornadas pela consulta. esTamanho: Usado pelo retorno, contem o tamanho da string (sResposta). Então o comando ficaria: MDFe_Enviar(ALote, AImprimir, False, sResposta, esTamanho) ou MDFe_Enviar(ALote, AImprimir, True, sResposta, esTamanho) Para o ACBrMonitorPLUS: MDFE.ENVIARMDFe(nXMLMDFe, [nLote], [nAssinar],[nImprimi],[nImpressora], [bAssincrono], [bEncerrado] ) 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) Ficando: MDFe.EnviarMDFe(nXMLMDFe, nLote, nAssinar, nImprimi, nImpressora, True, bEncerrado) ou MDFe.EnviarMDFe(nXMLMDFe, nLote, nAssinar, nImprimi, nImpressora, False, bEncerrado) A hora de ler a resposta também muda um pouco. No envio assíncrono, temos uma seção [Envio], [Retorno] e [MDFe + Numero do Documento]. Já no envio síncrono, não existe mais a seção [Retorno] e a seção MDFe é concatenada com a chave de acesso. Resposta Assíncrona: [Envio] CStat= CUF= DhRecbto= Msg= NProt= NRec= TMed= TpAmb= VerAplic= Versao= XMotivo= Xml= [Retorno] CStat= CUF= ChaveDFe= DhRecbto= Msg= Protocolo= VerAplic= Versao= XMotivo= cMsg= nRec= tpAmb= xMsg= [MDFe1] Id= XML= cStat= chDFe= dhRecbto= digVal= nProt= tpAmb= verAplic= xMotivo= Resposta Síncrona: [Envio] CStat= CUF= DhRecbto= Msg= NProt= NRec= TMed= TpAmb= VerAplic= Versao= XMotivo= Xml= [MDFe12345678901234567890123456789012345678901234] Id= XML= cStat= chDFe= dhRecbto= digVal= nProt= tpAmb= verAplic= xMotivo=

Estou tentando fazer o envio do MDFe de forma síncrona, entretanto está gerando algumas dúvidas. Na função de enviar o MDFe, são 3 parâmetros que podem ser passados, ALote, Imprimir, ASincrono respectivamente. Sendo que o parâmetro ASincrono tem como valor default FALSE, ou seja entende-se que a forma de envio é Síncrona correto? Pois bem, ao debugar o código na função Envia da classe ACBrMDFeWebServices, tem se o código: FEnviar.Lote := ALote; FEnviar.Sincrono := ASincrono; Então neste caso assumindo o valor default de Asincrono, o valor de Sincrono também é FALSE. Essa propriedade implica na função TratarResposta da parte de RECEPÇÃO nesta mesma classe. Primeira pergunta: 1º Porque a propriedade FEnviar.Sincrono recebe ASincrono? Sendo que no TratarResposta na recepção, existe condição que Sincrono tem de ser verdadeiro para poder ser executado. if Sincrono then begin if pos('retMDFe', FPRetWS) > 0 then AXML := StringReplace(FPRetWS, 'retMDFe', 'retConsSitMDFe', [rfReplaceAll, rfIgnoreCase]) else AXML := FPRetWS; ... Código continua para baixo E a segunda pergunta ainda na função Envia da classe ACBrMDFeWebServices. if not ASincrono or ((FEnviar.Recibo <> '') and (FEnviar.cStat = 103)) then begin FRetorno.Recibo := FEnviar.Recibo; if not FRetorno.Executar then FRetorno.GerarException( FRetorno.Msg ); end; Sendo neste caso a condição verdadeira, irá ser executado uma consulta dentro do FRetorno.Executar. 2º Porque tem de ser feita uma consulta?. Sendo que, segundo o parâmetro ASincrono está com valor FALSE, ou seja teria de ser Síncrono, e uma vez sendo Síncrono não necessita de consulta. Se não me fiz entender, tento explicar de outra maneira. Desde já, agradeço a compreensão.

Bom dia. A Consulta de Situação do Lote pode ser realizada tanto em "servidores" de Envio Síncrono como em "servidores" de envio Assíncrono ?

Pessoal, como alguns devem saber, o município de Pelotas/RS trocou de provedor, era Ginfes e agora é GovDigital. No provedor GovDigital, existe o método de envio síncrono, que já retornar no envio do lote a lista de NFS-e gerada. Internamente no nosso ERP, sempre atualizamos no registro da nota o número da NFS-e fornecido pela prefeitura, então sempre após o envio de um lote processado com sucesso, fazemos uma consulta para buscar as NFS-e's desse lote e atualizar os dados no sistema. No caso do GovDigital, isso não é necessário, pois a lista de NFS-e já estará disponível no XML de retorno do lote. Entretanto, no envio assíncrono, no método TratarResposta o ACBr não carrega a lista de NFS-e oriundas desse retorno. Fiz um teste aqui, e dentro do método TratarRetorno da classe TNFSeEnviarSincrono, bem lá no final, passei a chamar o método ExtrairNotasRetorno. Pelos meus testes ficou OK, mas não sei se concordam que seja a melhor forma de fazer, então deixo aqui minha alteração para que analisem. Outra coisa: no arquivo de cidades, ajustaram parcialmente a cidade de Pelotas/RS, mas no campo NomeURL ficou errado. Está assim: NomeURL_H=div NomeURL_P=div Deve ser assim: NomeURL_H=pelotas NomeURL_P=pelotas ACBrNFSeWebServices.pas Cidades.ini

Olá, gostaria de saber se o envio de NFe em SP funciona de modo sincrono? Obrigado

Saudações, estou Gerando e Enviando Lote - Síncrono para o provedor Coplan, porem algumas vezes o XML de retorno tem a tag protocolo, no entanto o componente não retorna o protocolo. Alguém passou por esta situação? Há alguma forma de consultar o protocolo quando o envio é Síncrono?

Boa noite, Gostaria de saber se é possível fazer o envio de lote RPS síncrono pelo ACBRNFSe? Uso para a cidade de Santa Liza-MG com o provedor ISSDigital, alguem já conseguiu fazer o envio para essa cidade?